務必給予 Claude 一種驗證自己工作成果的方法，無論是測試、建置，還是螢幕截圖比對。一個工作階段會在工程師看到之前，先檢查自己的工作並修正自己的錯誤。
回饋迴圈不應與驗證子代理（第 3 階段：建置）混淆。回饋迴圈會在整個任務中依工作所需的次數反覆執行。另一方面，驗證子代理是一種打包最終檢查的方式，做法是在工作階段認為工作已完成後，執行一個全新的上下文視窗。如此一來，判定結果就不會受到產生該程式碼時所做假設的影響。
改變了什麼
| 傳統方式 | AI 原生方式 |
|---|---|
| 程式碼可運作的訊號來得很晚。CI 要等幾分鐘後，測試人員要等幾天後，正式環境要等幾週後。當由代理產生程式碼時，訊號來得晚就意味著必須有人檢查其所有輸出，而那個人就成了瓶頸。 | 工作階段被賦予一種方法，可以在有人看到之前先檢查自己的工作。執行測試、執行建置、拍攝螢幕截圖。Claude 會反覆迭代直到檢查通過，因此送達工程師手上的內容已經通過檢查。設定這個迴圈的責任落在執行工作階段的工程師身上，以下步驟就是為他們撰寫的。 |
開始使用
- 先決條件：無。
- 基礎設施：一套可以用單一指令在本機執行的測試套件和建置流程。對於 UI 相關工作，讓 Claude 能夠看到結果至關重要，可以透過瀏覽器工具，或是透過 MCP 接入的螢幕截圖工具來實現。
如何執行
- 如果今天要檢查工作成果需要一連串指令和一些環境知識，請將其包裝成單一目標，例如
make test或npm test，在失敗時傳回非零值。 - 在
CLAUDE.md的 Commands 區段中，列出每個指令，並附上正常輸出的範例。 - 陳述一個目標，並使其可量化，讓 Claude 不必詢問您就能檢查工作成果，例如：「
test_status.py中的所有測試都通過」、「螢幕截圖與附上的模型圖相符」，或「該端點以新欄位回傳 200」。 - 對於錯誤修正，先撰寫失敗的測試。請 Claude 將錯誤重現為一個測試，執行它，並確認它確實因您預期的原因而失敗。提交該測試。只有到這時，才請 Claude 在不編輯該測試的情況下讓它通過，並由最後一個步驟中的測試檔案掛鉤來強制執行此限制。一個在修正之前就已存在、且代理無法重寫的測試，就是該錯誤已經消失的證明。
- 對於 UI 相關工作，以視覺檢查來完成迴圈。給 Claude 一個瀏覽器或螢幕截圖工具，給它模型圖，讓它反覆迭代。實作、截圖、比對、調整。兩到三輪是正常的，而且結果應該每一輪都有所改善。
- 讓驗證成為「完成」的一部分。這項指示寫在
CLAUDE.md中：「在回報任務完成之前先執行測試，並顯示輸出結果。」 - 最後，迴圈本身也需要受到保護，因為正在修正程式碼的代理不應該能夠削弱對該程式碼的檢查。一個在修正任務期間封鎖對測試檔案進行編輯的掛鉤可以做到這一點。另一種替代方案是在審查時檢查差異，並拒絕任何觸及測試的變更。
實際樣貌
CLAUDE.md 驗證區塊：
markdown
## Verifying your work
- Build: make build (must finish with "Build succeeded")
- Test: make test (all green; never skip or delete a failing test)
- Lint: make lint (zero warnings)
Run all three before reporting any task complete, and paste the output.
If a test fails, fix the code, not the test.治理考量
- 強制執行的內容：在任務回報完成之前進行驗證，以及在修正任務期間封鎖代理編輯測試檔案，這兩者在組織希望獲得保證的地方都以掛鉤的形式實作。
- 證據是什麼：
make test的原始輸出、建置日誌，或是 Claude 執行並貼上的螢幕截圖比對結果，因此證據來自工具鏈本身。 - 記錄在何處：記錄在工作階段的逐字稿中，該逐字稿會透過 OpenTelemetry 匯出轉發至組織的可觀測性堆疊，以及記錄在 PR 的檢查執行結果中，審查者和任何後續的稽核人員都能在那裡看到。
- 誰來核准：審查該 PR 的程式碼負責人，由於機械性的證據已經附上，他們可以專注於意圖和風險。
如何衡量
- 領先指標：代理撰寫變更的首次通過 CI 成功率，這是 CI 系統已經支援的指標。
- 落後指標：每個 PR 的審查時間（來自 PR 中繼資料），一旦測試能夠抓出審查者過去才能抓出的問題，這個數字應該會下降，以及來自事件追蹤系統的變更失敗率。