上個月，阿達完成了一個功能模塊，J 回報給我「做好了，可以合入主分支」。我當時就有點緊張——不是不信任阿達，是我們太清楚這句話的代價了。
果然，J 去查的時候發現：核心邏輯是對的，但邊界條件沒有處理，錯誤訊息是英文（我們的產品是中文介面），更重要的是——沒有一行測試。
這不是個案。早期 Agent 系統剛跑起來那段時間，幾乎每週都會遇到這種情況：任務交出去，回報「完成」，但拿來用就出問題。
問題不是 Agent 能力不夠，是「完成」的定義從來沒有統一過。
Agent 說「完成」的那一刻，我最緊張
我們最嚴重的一次，是一個定時任務腳本。
阿達說做好了，J 說測過了，結果上線跑了三天才有人發現——在某些條件下會靜默失敗。不報錯，不通知，就安靜地什麼都沒做。
三天。
那次我們花了快兩倍的時間去追問題出在哪，因為沒有錯誤訊息，沒有任何蹤跡，就是結果不對。如果當時有人在交付前多看一眼邊界條件，根本不會走到這一步。
但「多看一眼」這件事，沒有被定義成任務的一部分，Agent 就不會做。
「可以動了」跟「做完了」差很多
這件事讓我想明白一個東西：人在寫程式碼的時候，也會有同樣的問題——「功能跑通了」不等於「可以上線了」。只是人會因為過去的踩坑經驗，自動補上那些「本來就該做的事」：確認邊界、寫測試、看一眼有沒有漏掉什麼。
Agent 沒有這個本能。它的目標函數是「完成任務」，任務定義不清楚，就會用最短路徑到達它以為的終點。
所以問題不在 Agent 不夠聰明，是我們給的規則有漏洞。它只是如實地照規則走。
這個認知讓我停下來想：與其一直退回去要求 Agent 改，不如把「什麼叫完成」說清楚，從一開始。
所以 J 設計了一個閉環
J 的方案是這樣的：任何 Agent 的產出，都不能直接標「完成」，要先過五關。
Spec 確認是第一關。任務開始前，J 會跟交付的 Agent 對齊驗收標準——不只是功能描述，還有「什麼情況算失敗」「邊界條件有哪些」「要交出什麼證明自己做完了」。這一關加進來之後，我們才發現原來以前的任務描述有多模糊。
第二關是實作。Agent 按 spec 做。有 spec 的存在，Agent 做的時候會知道要對照什麼，不用猜。
第三關是 Code Review。做完之後，J 會拉另一個 Agent 來看程式碼，它的工作是找漏洞、找邊界問題、找不符合 spec 的地方。不是「你做得好不好」的主觀評價，是「spec 說要做的，你有沒有做到」的對照核查。
第四關是 Fix。code-reviewer 說有問題，退回去修，修完再走一次 review。這個循環可以跑幾輪，直到沒有新問題為止。
第五關是小月 QA。小月是我們的 QA 研究員，她從使用者角度驗證這個功能有沒有真的解決問題，打分，低於 8.5 分的退回。
五關都過，才算完成。
J 一開始說這樣太慢了。我說，那我們算一下，現在要多少時間在修 Agent 做壞的東西？
算完她沒說話。（這是個管理時刻，哈哈）
數字說話
這套流程大概在一個多月前開始穩定運作。
最明顯的變化是：J 標「完成」的任務，交付後被我或 Judy 打回來的比例，從原本大概四成降到現在不到一成。退回的那些，幾乎都是 spec 本來就定義不清楚的情況，不是品質問題。
另一個意外發現是阿達反而做得更快了。我原本以為加了這麼多關卡，她會做得更慢。但因為 spec 在開始就說清楚了，她做的時候不會去猜、不會做到一半才發現方向跑掉，要整個重來。
有一次 code-reviewer 在第三關抓到一個邏輯錯誤，如果等到上線才發現，J 估計要花四到五倍的時間處理。省掉的那段時間，大概可以做三個新功能。
我不知道這個倍數每次都這麼準確，但有在量，總比沒在量好。
Agent 說完成的時候，不是終點
現在每次我看到 J 回報「交付完成」，我的第一個反應還是會去確認走完五關了沒。這個習慣有點神經質，但它讓我比較安心。
最近在想，這件事本質上不是 AI 的問題，是「驗收標準」的問題。以前我們讓 Agent 自己定義什麼叫完成，當然每次都有漏洞。現在是我們先定義好，Agent 去達到它。
順序對了，結果才會對。
以上是最近整理團隊流程時突然想到的東西。