「AI 說它做完了，可是東西是壞的」｜Agent 排障三層地圖，先修環境再修反饋，流程最後才畫

這篇在講什麼

讓 AI 自己跑一段工作，最難抓的出包，是它回報「做完了」，東西卻是壞的，而且畫面上沒有任何失敗訊號。這篇把我自己踩過的六次這類事故攤開，按駕馭、迴圈、圖譜三層重新歸類。看到症狀，先知道該查哪一層，再決定要修什麼。

一、我遇過的「做完了」，有六種長相

六次有一個共同點：沒有一次是 AI 或系統自己跳出錯誤。

修法卻各不相同。有的要改權限，有的要改驗收方式，有的要改好幾個 AI 之間怎麼分工。所以出包的第一步，是先分清楚壞在哪一層。

二、三層：駕馭、迴圈、圖譜

這三個詞我之前各寫過文章。這篇把它們當成出包時要分開檢查的三層。這裡講的先後只是排查順序，跟哪一層比較進階無關。

三、駕馭層：它站的地方對不對

這一層壞掉的時候，AI 通常沒有做錯事。它在一個不對的環境裡，很認真地把事情做完了。

手動跑可以，排程跑就讀不到

九月初花東參訪期間，有一個每小時自動整理筆記的排程。紀錄裡看得到成功。

實際上，由系統排程起的程式沒有讀 iCloud 知識庫和語音備忘錄的權限，每一輪都回「Operation not permitted」（沒有權限），十輪全部靜默失敗。紀錄裡那幾筆成功，全是從有權限的視窗手動觸發的。

同一支程式，換一個身分來跑，拿到的權限就不一樣。後來的驗收標準改成：排程器自己起的那一輪有寫入，才算建好。手動跑通不算。

設定檔上的名字，跟線上活著的不是同一個

8 月 31 日整理 LINE 助理那條線。設定檔寫的服務名稱是一個，線上實際存在的是另一個。

照設定檔部署不會報錯，它會另外建一個新的服務，而 LINE 送訊息過來的那個入口（webhook）還是指著原本那個。結果是改動靜默不生效，畫面卻顯示部署成功。

那天之後的規則：改名、部署、接手既有系統之前，先查三件事。

1. 本機設定檔怎麼寫
2. 線上真的存在什麼
3. 正式入口（網址、webhook、排程）指著誰

三者不一致就先停下來，釐清誰在承接真實流量，再動手。也不能直接「以線上為準」，因為線上的東西也可能是殘留或建錯的。這一點是另一家 AI 審的時候抓出來的。

背景叫另一家 AI，白等 57 分鐘

7 月 25 日跨家審稿，Claude 從背景呼叫 Codex。它停在「等使用者輸入」，輸出檔 0 bytes，程式卻還活著。

看起來完全像 Codex 沒反應，或模型很慢。實際上它根本還沒開始跑。指令補上一行、明講沒有輸入之後，一次就回來了。

路徑寫死帳號名，換一台 Mac 就斷

我在幾台 Mac 之間切換，每台的使用者帳號名不一樣。規則檔、腳本裡只要寫死某一台的完整路徑，換機就失效。8 月 11 日修了 12 個檔，8 月 16 日又清出 176 處。後來改成機器攔截：寫進檔案的路徑含帳號名就擋下來。

駕馭層要問的四題

• 它讀得到嗎？要用它實際跑的那個身分去讀，不是用我手上這個視窗
• 設定檔、線上、正式入口，三個指的是同一個東西嗎
• 它是不是卡在等什麼（輸入、登入、授權）
• 換一台機器、換一個時間點跑，它還在嗎

四、迴圈層：它怎麼知道自己做完了

駕馭層確認沒問題，接著看它判斷「做完」的依據。我遇過的四次，依據不是它自己說的，就是一行成功訊息。

子代理把 170 個檔案打爛，回報完成

我把一批標籤改名交給子代理。它跑了幾分鐘，回報五組全部完成、零殘留。

我沒有直接信，讓另一個檢查點用最笨的方式自己再數一次，才發現它某一步替換的指令寫錯，把 170 個檔案的中文全拆成亂碼。最後零遺失，靠的是三道防線：

1. 動手前做了完整備份，而且驗證過真的能還原
2. 損壞有規律，我先拿一個有乾淨備份的檔案試反向還原，逐字相符才套用到全部
3. 請另一家 AI 獨立再驗一次復原結果

叫它請 Claude 修，它沒叫

我請 Codex 叫 Claude 來修一篇文章。它回了一版文字，乍看像照做了。

我追問「你有叫 Claude 出來嗎」，它才承認沒有。再請它真的去叫，回來的是一個登入失敗的錯誤。有呼叫就說有，沒呼叫就說沒有，失敗就說失敗原因，這個比假裝完成重要。

從那之後，AI 說它完成了某件事，我會先問這幾句：

成功訊息照樣印出來

8 月 27 日，一段改檔指令沒有執行成功，但後面接的「已更新」訊息和檢查 PASS 照樣印了出來。三個成功訊號同時出現，檔案一個字都沒改。

確認的原因只有一半：好幾段指令用分號串在一起時，前一段失敗不會擋掉後一段。另一個疑點後來重測沒有重現，所以沒有把它當成已經排除。

不管根因是哪個，做法一樣：驗收看檔案內容，不看畫面訊息。改完回頭讀檔，確認新內容真的在、舊內容真的不見。

push 成功，正式網址卻打不開

9 月 11 日官網上線，流程被誤判成中斷，改用手動 push（把改好的檔案直接送上雲端）收尾。網站平台顯示新版本已經建好（READY），正式網址卻有五分鐘打不開。

原因是正式網址要靠上線腳本裡的一步切換，手動 push 不會做這一步，也不會報任何錯。規則改成：流程中斷就從頭再跑一次，不自己手動收尾；回報完成之前，要驗到正式網址指向這一次的建置而且打得開。

迴圈層要做的三件事

第一，開跑前先寫三行。

「完成條件」要寫成看得見的東西：檔案存在而且內容對、網址打得開、數字對得上。「它回報完成」不算。

第二，設圈數上限。迴圈的規則是沒過就修，一直沒過它就會一直修，中間不會停下來問你。我自己的預設：

停下來的時候要交一份說明：卡在哪一步、試過哪些做法、判斷缺的是什麼。我規定回報第一行只能三選一：「完成」、「失敗：一句原因」、「卡住：在等什麼」。

第三，不讓同一個 AI 審自己。我常用一個比喻：一個超級愛吃辣的廚師，比賽時煮最辣的那道，當評審也給辣的最高分。他不是故意偏心，他做的跟他評的，用的是同一把尺。

所以我的迴圈是一家跑完，換另一家審。ChatGPT 寫的用 Claude 或 Gemini 審，反過來也一樣，重點是換一家公司，換對話視窗不算。有一次 AI 幫我寫價格比較，年費 8,744 元、月費 729 元，729 乘 12 其實是 8,748。我沒看出來，寫的那個 AI 也沒看出來，換一家審才指出矛盾。

五、圖譜層：線跟線之間有沒有接好

前兩層管的是一條線。只有一條線在跑的時候，這一層可以先跳過。好幾個 AI、好幾條工作流同時在跑，而且彼此要接力的時候，才輪到這一層。

兩篇文章互卡，根因是共用一張桌子

我的官網由好幾個 AI 分頭維護。有一天，B 的新文章檢查全部通過，只差推送，卻停下來排隊，因為 A 還在同一個資料夾裡施工。

這不是第一次。更早還發生過一方為了發布，動到另一方還沒完成的檔案；也發生過正式網域被舊版本蓋回去。每出一次事就多立一條規則，排隊越排越長。

挖到最後，根因只有一個：所有 AI 共用同一個本機資料夾。排隊規則解的是症狀。後來的解法是三件套：

這套設計完，我先給另一家 AI 審，它抓出三個串起來才看得到的洞。其中一個是：好幾條線同時在上線時，看到「線上有新版本」不代表那是自己的版本。所以驗收要核對是不是自己這一版，對得上才算數。

同一篇文章的進度，記在三個地方

8 月 23 日盤點知識庫的工作流時，發現官網文章的狀態有兩套詞彙：看板欄位一套、技能包裡的定義一套，各五個狀態、名稱不同。再加上已上線清單，同一篇文章的狀態有三個地方在記。隔天收斂成一套。

同一次盤點還找到一本沒人寫的交接本：一組給 AI 查人物與專案的索引檔，一個月沒更新，規則卻還指著它當查詢入口。AI 照規則去讀，讀到的是一個月前的快照。

規則表貼了，沒人執行

7 月我盤過自己寫給 AI 的規則，大約 220 條，真的有機制在執行的大約 24 條。代價最高的 60 條裡，有 48 條完全靠 AI 自己記得。

放在圖譜層看，這就是「規則表貼在牆上，沒有人照著喊下一個」。畫得出來、講得出來，跟真的有東西在跑，是三件事。

圖譜層什麼時候才動

那次盤點我用的判準，三條要同時成立：

1. 狀態真的被多方共用：不只一個 AI、一台機器要知道「現在到哪了」
2. 下一步真的會分岔：過了走 A，沒過走 B
3. 已經為此出過事

盤了 11 條工作流，真的有缺口的 3 條、觀察 1 條，建議不動的 7 條。沒出過事的不動。

六、為什麼順序是先駕馭、再迴圈、圖譜最後

七、症狀對照表：看到什麼，先查哪層

八、排障清單，可以直接複製

九、放手的是執行，驗收不放手

這篇講了很多讓 AI 自己跑的前提。最後補一段不放手的。有四類事，我到今天仍然要求 AI 停下來問我，而且寫進規則裡：

• 不可逆的動作：刪除、覆寫、搬移
• 對外送出：發文、寄信、送出表單、公開上線
• 牽涉金錢：付款、報價、承諾價格
• 改規則本身：規則檔、技能包、攔截程式

這四類的共同點是錯了救不回來，或救回來的成本很高。其他的事可以交出去跑。只是它說做完了，我會自己去確認產物真的存在、內容真的對。

這篇的誠實邊界