GPT 不是停不下來,是看不見停止線:Review 隧道視野與停止條件治理

一段由 GPT-5.6-sol 驅動、跨日無人值守的工作結束後,我拿到了一份規模超出預期、方向也偏離原始目標的成品。

工作執行時,我看不到 agent 如何在 review 與修正之間前進,直到結束才看見結果。等很久只是表面問題。拿回來的東西跟當初要它做的事對不上,才是真正難受的地方。

Review 找到的不確定性,被當成新需求

事後回頭檢查這整段執行過程,問題的形狀才浮出來。

回頭看這段紀錄,我發現 review 反覆占用大量時間。它抓出來的安全疑慮、邊界案例,以及為了讓某些結果必然成立而新增的保證機制,沒有停在風險清單裡,而是順勢變成下一輪新增程式碼的目標。

新寫出來的防禦程式碼,又增加了下一輪需要檢查的程式碼範圍;下一輪 review 再抓出新的疑慮,它就繼續填補。review finding 持續成為下一個實作目標,卻沒有重新確認原始驗收是否早已成立。消除不確定性的過程,就這樣逐漸取代了最初的完成條件。

在先前的〈聽話,不代表懂你〉裡,我寫過它對明文規則的服從;在另一篇談需求膨脹的文章裡,也寫過模型很會深挖,但放在錯的工作階段會讓需求膨脹。這次的狀況不太一樣:它沿著自己的 review finding 一步一步走進隧道視野。

更早使用 Codex 時就演過同款戲碼

另一段更早的紀錄裡,OpenAI Codex 也把一個簡單任務做大。這段不能證明同一個 review 迴圈;它的作用是顯示另一種相同偏移:推演中的風險被逐項做成實作。

當時原本只是清理本機資料,結果它把工作當成正式環境的資料庫遷移來做,額外長出狀態清單,以及中斷後仍能接著執行回退流程的機制。

兩個情境真正相同的地方,是把原本只存在於推演中的風險與邊界,逐項轉成新的程式碼,最後把原始需求擴成另一個專案。

另一名開發者也在 Reddit 描述相似困擾:GPT-5.6-sol 很會找邊界與風險,一個簡單任務卻逐漸長成治理、測試與假想問題修正。這只證明同型個案存在,不代表問題普遍存在。

試著給它一條粗暴的停止線:只修 P0

review 產生的 finding 很具體,停止理由當時卻不存在。我先在 prompt 裡寫下一條停止線:自我 review 之後只修 P0 等級的嚴重錯誤,其他非阻斷項目不追。

後續紀錄裡,低價值項目沒有再被逐條追修,但這只能證明「停止逐條追修」與這條 prompt 同時出現,不能證明前者由後者造成。同一批紀錄也暴露出另一個坑:只看嚴重度標籤,會讓真正該修的東西留下。

只看嚴重度標籤,會把功能缺陷放跑

其中有些 finding 已能用程式碼或測試重現:原始需求的核心行為沒有執行、輸出錯誤,或驗收是假綠,也就是測試顯示通過,實際卻沒驗到該驗的行為。它們因為沒有被標成 P0,而被原本的規則放過。

這等於為了防止過度工程,反而留下已確認的功能性缺陷。「只修 P0」不能再單獨承擔停止決策;它只保留為預設煞車,已有功能性證據的 finding 是明文例外。

停止理由必須像下一個 finding 一樣明確

現在的規則會逐條寫下 finding 的處置理由。它不再只問「是不是 P0」或「finding 清空了嗎」:

當原始驗收已成立、剩餘 finding 都有具名處置理由,而且沒有仍可在原始範圍內最小修正的功能性缺陷時,這輪 review 就結束。

這裡說的「明確」,指每個 finding 都要有具名的處置理由;它跟客觀分數無關。

提示型 hook 只負責把判準送到模型面前,不會硬性阻擋動作,也不保證模型遵守。

「看不見停止線」講的是 GPT 在 review 裡的預設行為。規則就算送達,它仍可能不照做。

治理是給判準,不是求乾淨

以上觀察只來自我使用 GPT-5.6-sol 的經驗。社群案例能證明存在同型問題,但不代表所有場景或所有模型都有相同規律。

規則有沒有送達是一回事,實際工作紀錄裡有沒有照規則分流是第二回事,最後交付是否更接近原始範圍又是第三回事,三者不能混為一談。

我的目標放在讓每一條 review finding 都有可檢查的處置理由,不追求清空清單:該修的只做最小修正;該停的留下不修理由;會改變範圍的,交還給使用者決定。