你的 AI 助手以平凡的方式出錯，這反而是好消息
助手回報成功了。工作「完成了」。接著你流程裡的下一步收到一片空，然後你花了整個晚上追這個謎團。 這裡有個大多數獨立開發者得付出代價才想通的解放性真相：你的代理人失敗幾乎從來不戲劇性——它們是機械性的，而機械性就意味著可以診斷。 問題只是少了一個右括號。解法只是讀了日誌裡的一個數字。這裡面沒有天才——而那正是好消息本身。 「無法理解」的失敗，是一則神話 當助手做錯事，直覺會讓我們去抓那些大解釋：模型產生幻覺、提示詞太模糊、模型「還不夠好」。於是你重寫提示詞、換模型、買更貴的級別。 與此同時，真正的失敗從頭到尾都躺在一行日誌裡，沒人去碰。 代理失敗的模式，絕大多數是那種不光彩的類型： 一個 JSON 欄位少了一個右括號，所以根本無效。 一個權限範圍少開了一層。 一個環境變數從頭到尾沒進到 shell。 一個檔案從錯誤的目錄讀取，所以它靜靜地拿到空字串。 一個「if」永遠不分支，因為條件拿字串去跟數字比較。 這些全都不需要更好的模型。其中任何一個，都對願意讀輸出、而不是讀摘要的人顯而易見。 為什麼人們跳過診斷 悲劇在於：診斷看起來像工作，感覺起來卻像什麼都沒做。讀日誌不是一個令人滿足的故事。「我換了更聰明的模型，然後就好了」是一個故事。「我找到一個漏掉的括號」不是——所以沒人拿它炫耀，而換模型的迷信就因此活了下來。 但那兩分鐘的日誌，是獨立團隊裡報酬率最高的習慣。這跟我們那篇談〈「完成」驗證儀式〉（done-is-a-claim）是同一套紀律——那篇靠強迫你「親眼見證輸出」來抓住失敗；這篇則是在失敗發生之後把它找出來。同時它也是〈認識你的代理模式〉（agent patterns）的另一面：模式告訴你失敗藏在哪裡，日誌告訴你究竟壞了什麼。 診斷紀律 當助手「離奇地失敗」，忍住把調查範圍放大的衝動。反過來，把它縮小。 先重現，再推論。 用完全相同的輸入重跑一次。如果每一次都以同樣的方式失敗，它就是確定性的——這代表問題在輸入、設定或接線，不在模型。非確定性（每次跑出不同的錯誤答案）才是模型本身、或它的 temperature 該被懷疑的唯一情況。 讀更原始的輸出，而不是診斷。 助手會樂於給你一個自信滿滿的、關於它自己失敗的解釋——而那個解釋往往是另一則穿上白袍的幻覺。跳過它。看它收到的輸入、它呼叫的工具、以及回傳的原始位元組。真相在 payload 裡，不在道歉裡。 找出錯得最小的那一個數字。 一個計數、一個 exit code、一個狀態、一個時間戳。找到現實與助手假設分岔的那一個點，你就找到了根本原因。代理的錯誤以驚人的規律性坍縮成一行。 修邊界，而不是修行為。 一旦看清，解法通常是一條規則或一道檢查，而不是更長的提示詞。「每次解析 JSON 並在格式錯誤時大聲失敗」，勝過「更努力地輸出合法 JSON」。你是在強化系統，不是在哀求它。 平凡失敗帶來的平靜 這種心態改變了獨立開發者的睡眠品質。「離奇」的失敗是焦慮——一個可能藏在任何地方的未知數。機械性的失敗是一個「已知的未知」，而已知的未知，是十分鐘的工作。 你不再伸手去換模型、而是伸手去讀日誌的那一天，你的助手就不再神秘，而是像你自己的程式碼一樣可讀。兩者的壞法一模一樣：一次一行，攤在眼前，等著你去讀。 你的助手沒有離奇地失敗。它以平凡的方式失敗。去讀那一行。 來源 Hacker News 與 Indie Hackers（2025–2026）上的多篇代理事故檢討。 反覆出現的特徵：代理回報成功，而底層動作卻以機械性的原因失敗（漏掉的括號、權限錯誤、空環境變數、錯誤的工作目錄）；這些失敗都是確定性的，並且在原始工具輸出裡可見，而不是在摘要裡。 代理可靠性與錯誤分類學文獻。 工具使用與反思的失敗模式（Zheng 等人，《AgentErrorTaxonomy》，arXiv:2509.25370）記錄了代理在被要求「自我回報」時如何捏造解釋；解藥是檢查實際執行的動作，而非代理的事後說法。 持續整合與可觀測性實務。 找出那一個分歧的計數、exit code 或狀態、作為根本原因錨點的紀律，正是 CI 系統所形式化的「找出錯的那一個數字」——日誌是真相，敘事是臆測。
