AI 自己寫、自己審，為什麼反而改了 50 多輪？Claude Code 團隊的教訓

讓 AI 寫程式，再找另一個 AI 審查，發現問題就回去修改，應該能自己把工作完成吧？

Claude Code 團隊卻遇過一批修改來回審查超過 50 輪，整晚還沒結束，最後由負責的人喊停。

這個故事提醒我們：讓 AI 一直找問題，不等於工作會逐漸完成。交辦時除了說清楚要做什麼，也要安排何時重新評估，以及怎麼確認成果。

改了 50 多輪，為什麼還沒做完？

在團隊分享的工程經驗裡，審查者每輪都提出一些問題，修改者修完再送回去，卻又收到新的回饋。

團隊回頭追查，發現後來指出的問題，有不少在第一輪送審的版本裡就已經存在，只是沒有一開始就被找出來。

也就是說，後面發現的錯誤，不見得是上一輪修改造成的，也可能是前面漏查的。這裡的「早已存在」，指的是最初送審的版本就有，不代表一定來自這次修改之前的舊功能。

對交辦工作的人來說，難處就在這裡：程式一直改，審查一直有新發現，卻看不出還要多久才能結束。

如果每次收到回饋，就讓 Agent 照原樣再跑一次，很容易把「持續有事可做」誤認為「持續接近完成」。真正需要知道的是：每輪在修什麼，還值不值得繼續？

團隊後來加了一個重新評估的時機：審查與修改來回 3 輪後，就請負責這批修改的人退一步，重新考慮做法。

這不是第 3 輪結束就自動通過，而是先看看：需求有沒有說清楚？修改範圍是不是太大？有沒有需要人來決定的地方？

另一個調整是複查範圍。前幾輪檢查過後，後續集中看新一輪的修改差異，避免重複提出已經報過的問題。如果找到某一類錯誤，就把整類問題交代清楚，讓修改者一起處理，減少逐項來回。

一項安排決定「何時回頭看方向」，另一項決定「再次審查要看哪裡」，目的都是避免同一批工作無限延長。

至於原先漏掉的問題，團隊另讓審查 Agent 每晚檢查既有程式，把眼前修改的複查，和持續尋找其他錯誤分開安排，不必全部擠在同一個任務裡。

流程示意：釐清複查範圍、避免重複回報，並安排重新評估的時機，非產品實際畫面。

假設你想替網站表單加上必填檢查，這次需要確認的，就是空白能不能送出、錯誤訊息看不看得懂，以及正常填寫後能不能提交。

如果檢查時又發現別頁的版面不好看，可以另外記下來，不必順便請 Agent 把整個網站重新排版。其他發現仍然有價值，但不用全部塞進這次任務。

範圍畫清楚，才看得出原本要做的功能完成了沒有，而不是每次複查都變成新一輪改版。

官方審查規則文件也提到，可以寫清楚專案在意什麼，讓審查集中在值得處理的問題。例如已有工具檢查排版與縮排，就不必讓模型反覆提出相同的格式建議。

審查之外，還要確認程式到底有沒有實際跑過。Anthropic 的最佳實務文件建議，交辦時提供 Agent 能執行的檢查，例如測試、建置，或用來對照的畫面，讓它用結果判斷對錯。

以前面的表單來說，另一個 AI 讀過程式，可能看得出條件判斷有問題；實際打開網站送出空白資料，才能知道使用者會遇到什麼。

如果畫面顯示紅字，資料卻照樣送出去，這個功能就還沒達到目的。因此，交回成果時，可以附上正常提交與空白提交的操作結果，而不只是一句「檢查完成」。

也別把工具名稱當成保證：GitHub 上的託管 Code Review 服務會檢查程式與修改差異，但不會替專案執行測試或建置，也不會替人批准合併。審查完成後，仍要確認實際測試由哪個步驟執行。

不打算逐行讀程式的人，也能透過操作成果與測試結果，參與最後確認。原團隊同樣強調，負責交代修改的人，仍要對最後交出的變更負責。

如果 Agent 連續幾輪都卡住，先別只說「再仔細檢查一次」。請它整理四件事：

拿到這些資訊，再決定繼續修改、縮小範圍，或換一種做法。

例如表單的必填檢查已經通過，後續發現的是其他頁面的問題，就可以先記下來，另開任務處理；如果空白資料仍然能送出，則要繼續釐清原因。判斷依據應該是原本的目標有沒有達成，而不是審查跑了幾次，或回饋清單看起來有多長。

停下來重新評估，不是放棄品質，而是避免在沒看清楚卡點時，繼續用相同方式反覆重跑。

Claude Code 團隊的教訓，不是不要讓 AI 自己寫、自己審，而是別只安排它繼續工作，也要留一個能看清進度、重新決定方向的時機。

最後交回來的，應該是能操作的成果，以及足以判斷它是否符合目標的結果。這樣才知道，工作真的可以收工了。