• 兩輪 UAT 合計準備 13 個功能情境。第一輪檢查跨角色流程，第二輪讓申請人操作。
• 這一階段的開發工作都交給指揮中心管理。它負責分流、檢查檔案衝突與安排 Agent，讓修正可以連續進行。
• 每一項回饋都要留下上線決定：納入、帶著已知限制納入，或排到下一版。
• UAT 收口後，我得到一個可以說明範圍與風險的 Release Candidate。

兩輪 UAT 帶回兩種視角

兩輪 UAT 合計有 13 個功能情境，涵蓋當時準備上線的 13 項功能。原始紀錄只確認兩輪總數，本文沿用 13 個的口徑，不另外拆出各輪數量。

兩輪找的人不同，帶回來的問題也不同。

第一輪找到的問題比較接近流程斷點。單據走到最後回傳 500、既有成員沒有正確帶入、部門欄位出現空值，這些問題會直接影響申請結果。

第二輪更接近日常操作。申請專案與申請原因缺少填寫位置、PROD URL 的用途不清楚、回上一步後已選人員消失、專案名稱前綴沒有自動帶入，都是使用者真的填過一次才會碰到的問題。

Day 22 已經談過回饋內容，Day 23 也排好了五個工作天的修正順序。這一篇往下看結果：哪些修改進入上線版本，哪些需求留在版本外。

這一輪改得很快，因為開發都進了指揮中心

第一輪 UAT 開始後，修正也同步進行。

這次我把確認過的開發工作都交給指揮中心管理。每一筆回饋先寫成明確任務，接著由指揮中心判斷它要走 Bug Fix、文字調整或完整 Spec 流程，再檢查會修改哪些檔案、哪些工作可以平行、哪些需要排隊。

任務排好後，前端、API、QA、Security 與 Documentation Agent 各自處理負責範圍。原本需要我逐項追蹤的開發細節，改由指揮中心集中管理。我把時間放在業務規則、Plan 確認與最後定版。

這套分工讓 UAT 回饋可以很快回到程式裡。它也保留了兩個人工卡控點：Plan 完成後，我先確認方向；開發與驗證完成後，我再確認結果。

單據詳情加入流程關卡與處理權移轉。待處理清單重新整理母單與子單的階段，流程步驟條也跟著校正；同一天再把使用者看到的「母單、子單」改成「申請單、工作單」，並拆開統計卡與頁籤。

到了第二輪，回饋繼續送回同一套流程。同時處理 EDB 權限申請購物車、回上一步還原、審核主管、部門規則與專案名稱前綴。這一個 commit 異動 30 個檔案，裡面包含 Spec、Plan、Scenarios、Tasks、程式與文件。

這 30 個檔案代表一項使用者回饋會沿著多個產物往下走。畫面改完後，驗收情境、文件和共用狀態也要一起更新。

回饋進來後，我先確認規則與版本優先順序。後面的分流、影響分析、Agent 派工與進度收斂都由指揮中心接手。開發速度拉起來後，我就能把注意力移到上線範圍。

四項回饋，形成四個版本結果

我把兩輪 UAT 的結果放回上線版本，留下四種有代表性的處理方式。

前三項都改了程式，第四項改的是版本範圍。

多 repo 的需求有使用價值。當時的使用情境、自動化能力與剩餘時間，還不足以支撐這次開發。我保留原始需求與延後原因，讓下一次評估有上下文。

這個決定也保護了上線版本。新增多 repo 會一路影響表單、申請資料、後端自動化與後續維運，驗證範圍遠大於多一個輸入欄位。七月底的版本先守住已經走過兩輪 UAT 的路徑。

用 Release Candidate Decision Board 收口

# Release Candidate Decision Board

| UAT 回饋 | 影響情境 | 版本處理 | 實作證據 | 驗證證據 | 上線狀態 | 已知風險 | 責任人 |
| --- | --- | --- | --- | --- | --- | --- | --- |
|  |  | 修正／新增／說明限制／延後 |  |  | 納入／帶限制納入／延後 |  |  |

這張表要回答三件事：

1. 這一項最後改了什麼。
2. 我用什麼證據確認結果。
3. 它會不會進入這次上線版本。

延後項目同樣留在表裡。它需要延後原因、重啟條件與追蹤者，後續才能重新判斷當時的限制是否已經解除。

UAT 的最後產物是一個發布決定

ISTQB 將 Acceptance Testing 的重點放在驗證系統是否符合使用者的業務需要，並提供部署準備度的資訊。理想情況下，驗收由預定使用者執行。(ISTQB, Certified Tester Foundation Level Syllabus v4.0.1)

Microsoft 的部署準備指南也把收集修正結果、升級失敗項目，以及決定是否繼續部署列為明確責任。(Microsoft Learn, Define readiness criteria)

這和我在兩輪 UAT 後做的事很接近。Agent 可以整理 diff、Scenario 與文件，指揮中心可以安排修正；上線範圍、已知限制與風險接受由我和流程負責人確認。

7 月底，我第一次拿到完整的上線候選版本

Day 20 的 13 項 JSON 比對先守住輸出，兩輪 UAT 再把跨角色流程與申請人的操作帶進來。到了這裡，回饋已經有修正結果，新增功能有驗證範圍，延後項目也留下原因。

使用者測試，是在系統上線前一個重要的環節，可以提前知道系統是否有需要及時調整，做預先處理。

這份 Release Candidate 讓我知道 7 月 31 日準備上線的是哪一個版本，也知道哪些功能還留在下一段路上。

程式與流程已經接近定案。下一步要盤點資料怎麼移轉、什麼時候停止舊系統寫入、搬完後怎麼核對，以及失敗時怎麼恢復。

Day 25，進入正式上線前的流程與資料移轉盤點。