第 0 步：把「完成」寫成可驗證的條件

這是全場最難的一步。「把程式碼改好」太虛，「test/auth 全過且 npm run lint 乾淨」才夠用。

驗收單：四個欄位

把停止條件寫成驗收單，四個欄位盡量都補上：

欄位	說明	範例
通過條件	什麼命令跑過算成功	npm test 全綠、npm run lint 無錯誤
品質門檻	除了通過，還有沒有其他標準	測試覆蓋率 > 80%、LCP < 2 秒
邊界	不能動哪些檔案、不能改哪些 API	禁止修改 src/auth/ 目錄
上限	最多跑幾回合、花多少 token	最多 20 回合，或 $2 USD

agent 還是那個執行者，你寫的是它必須通過的那張驗收單。

好的 vs 壞的驗收條件

壞的驗收條件之所以壞，是因為 agent 沒辦法自己判斷有沒有達到：

壞：

• 「把程式碼改好」
• 「優化效能」
• 「整理文件」

好：

• 「test/auth 全過且 npm run lint 乾淨」
• 「LCP < 2 秒（用 Lighthouse 量）」
• 「每個公開函式都有 JSDoc，且 eslint 的 valid-jsdoc 規則無警告」

為什麼這步最難

因為它迫使你在動手之前就想清楚「我到底要什麼」。很多時候我們說「把這個功能做好」，其實心裡根本沒有一個清晰的完成圖像。

把驗收條件寫清楚，有兩個副作用：

1. 你會發現任務比想像中模糊——這是好事，早點發現比做完再改便宜
2. loop 不需要猜你的意圖，它只要對照驗收單

AI 協作：學了這個，跟 AI 怎麼配合？

寫驗收條件是人類最該做的部分，但 AI 可以幫你找漏洞。你寫一個草稿，讓 AI 扮演「執行者」，問它：「如果你是那個 agent，你怎麼判斷這條條件算達到了？」常常這樣問一輪，你就會找到自己條件裡的模糊地帶。

你的人類優勢：

• 你知道「做完」在業務上的真實意義，不只是技術層面的通過
• 你能設定邊界——哪些地方不能動，哪些是核心約束

可以這樣跟 AI 說：

我想讓 agent 幫我重構 src/api/users.ts 這個檔案，讓它符合我們的 API 設計規範。幫我把這個目標寫成一份驗收單，包含：通過條件、品質門檻、邊界限制、回合上限。然後指出這份驗收單有哪些地方仍然模糊，需要我補充說明。