我把 45 支 AI 工作流查了一遍，發現它們在用我不知道的方式出錯
你把愈來愈多事丟給 AI 之後，省下來的時間，會慢慢換成另一種焦慮：它有沒有在我看不到的地方，悄悄做錯了什麼？我自己也是。我原本只想花半小時「確認一下沒有過時的設定」，結果在 45 支我自己建的自動化流程裡，挖出 14 個我完全沒察覺的錯誤。
問題其實不是「AI 夠不夠聰明」。它很聰明，聰明到出錯時也一臉自信。問題是：你有沒有一套「預設它會出錯、而且有辦法主動去抓」的機制。沒有的話，有可能你不是把工作做得更有效率，而是在用規模更大的方式，持續累積你自己察覺不到的錯誤——至少，我遇到的是這樣。
你以為改好了，但改的那一層根本沒被執行到
先講最讓我意外的一個。
我在 Claude Code 裡養了一套自己寫的 AI 技能（skill），目前 45 支，每一支就是一條固定工作流——把 PDF 翻成中文、寫文章、做品牌體檢、選工具，像一個個小部門各司其職。
我很早以前就在「總規則」那一層立過一條規定：寫社群貼文要走自家品牌規格，別套某些通用模板。我以為改了上層，下面就會跟著走。
結果不是。有 4 支技能的「內文」，還偷偷指向那些被我明令禁止的舊模板，照著舊指令繼續跑。不是 AI 不聽話，是「規則生效的那一層」和「工作流實際讀取的那一層」根本是兩回事——我改的是 A，但它們每天讀的是 B。就像公司改了規定，但第一線的作業手冊沒人去印新版：你以為改了上面，下面還是照舊版在做事。
這就是我想講的核心：無聲腐化（silent drift）——系統悄悄「漂移」到偏離你當初設定的狀態。它沒壞、沒報錯、繼續給你看起來很對的輸出，問題卻在你看不見的地方一點一點累積。你改了一條設定，但到底誰去確認過每一個執行端都真的更新了？多數時候，答案是沒有人。
AI 出包的時候，它不會舉手告訴你
這類錯誤之所以特別難抓，根本原因是：AI 愈有自信，你愈不會想去質疑它。
底下還疊著三個結構性的原因。
第一，大型語言模型（LLM）給你答案的時候不會亮紅燈。它不會說「這段我不太確定」，而是用一模一樣的語氣，把對的和錯的一起自信地交給你。
第二，你通常不會回頭去看「已經在跑」的流程。會被你盯著的，往往是還沒上線、還在懷疑的東西；一旦某個流程「跑起來了、看起來沒事」，它就從你的注意力裡消失了。
第三，規模愈大，盲點愈多。45 支技能，不是靠肉眼一支一支核對能顧得過來的數量。
這三點之上，再加一層信任偏誤：你會懷疑一個吞吞吐吐的人，卻不會懷疑一個對答如流的人——哪怕後者錯得更離譜。這讓你更難去懷疑「自己親手建起來的東西」。它愈順，你愈放心；而放心，往往讓問題最難被發現。
我實際怎麼查的：四個角度，加一個「不准自己查自己」
我用四個角度、再加一道「不准系統自己查自己」的對抗式覆驗（adversarial review），把全部 45 支掃了一遍。
四個角度是：
- 自相矛盾——同一支的內文前後打架。
- 過時——指向已經不存在的工具，或早就廢掉的流程。
- 彼此重複——兩支在做同一件事，卻互不知情。
- 索引斷掉——跨技能的指向失效，A 說去找 B，但 B 已經不在了。
只有這四個角度還不夠，因為有個盲點繞不開：我自己建的系統，跟我自己的判斷，共用同一套思維框架。我看不出來的東西，自己再查一遍，還是看不出來。
所以我加了對抗式覆驗：派一個獨立的、沒做過這份工作的 AI 去找碴，不准系統自己檢查自己。它會問出我問不出來的問題，因為它沒有我的盲點。
這裡得誠實講一段。這個查核流程本身，就出包了。
我本來想用多代理自動化來跑，結果它連撞三次伺服器流量限制（rate limit），整批掛掉，逼我退回去單線、一支一支手動跑。更值得警惕的是另一件事：我下的一個搜尋指令其實寫壞了，根本沒搜到東西，它卻安安靜靜回報「全部乾淨」。
那一刻才是重點。一個假陰性（false negative）——工具明明出了問題，卻一臉自信跟你說沒事——比它直接報錯危險得多。報錯你還會去修；回報「乾淨」，你只會放心地走開。連我用來抓錯的工具都會這樣，那它替我查的其他東西，我又憑什麼照單全收？
揪出來的 14 個問題，攤開給你看
先說一件事：我堅持「整套逐支深讀」，沒有抽查。原因很簡單——盲點的定義就是「你不會剛好抽到它」。如果我只挑幾支看起來最可疑的看，剩下的全憑運氣，這次大概會漏掉一半。
兩輪修正下來，總共揪出 14 個真問題、動到 15 個檔。分類是這樣：
- 4 支技能偷跑我早就禁掉的舊模板。
- 5 支殘留早就作廢的「兩台電腦同步」舊步驟（我老早改成單機作業了，它們卻還寫得像現成可用）。
- 2 支指向根本不存在的工具，格式完整、語氣自信，不深讀完全看不出來。
但我不想把這寫成一個「系統終於完美了」的結局。它不是。誠實的講法是：這一輪體檢之後，這套系統比之前安全一點，而下一次，很可能還會冒出新的漂移。這不是一勞永逸的修復，是一次例行保養。
三條可以帶走的原則，不只關於我那 45 支技能
把 45 支技能放一邊，這次真正可以遷移的，是三件事。
把 AI 當系統，不要當工具。 出錯的時候，先修產生錯誤的機制，不要只修這一次的輸出。同一個結構性問題，你今天手動改掉這一筆、卻不去動產生它的機制，它很可能改天以另一種形式再回來。
預設你的 AI 工作流會漂移。 規則改了，執行端不會自動跟上，這幾乎是常態，不是例外。所以「去核對每個執行端有沒有真的更新」是人要主動做的事——你不能把「把關」也外包給那個你正在把關的對象。
對抗式覆驗不是偏執，是規模化之後抓盲點最有效的辦法。 你和你建的系統共用同一個腦，天生找不到它找不到的東西。派一個沒做過這件事的外腦進來，才有機會打破這個迴圈。
說到底——建一套 AI 系統不難，現在門檻低到一個下午就能堆出一個能跑的流程。讓它半年後還有機會跑得準，才是真正的工作。
最後，一個你這週就能做的小動作
我不是要你也去養 45 支技能。那是我的情況，不一定是你的。
門檻最低的起手式是這樣：把你最常讓 AI 重複跑的那一條流程找出來——你的固定提示詞（prompt）、你存起來的某個指令、某個自動化——然後問自己一個問題：
如果它從某天開始悄悄跑錯了，我最近一次，會在哪裡發現？
如果你的答案是「我不確定」，那個「不確定」，就是你第一個該補上的查核點。
我平常就是這樣替自己管這套系統的：不追求一個全自動、再也不用管的完美系統，而是預設它會錯，然後留好抓錯的縫。
你上一次對自己的 AI 工作流做體檢，是什麼時候？
我是 Ray Kuo（raykuo.aiflow）——一個人 × 一套 AI 工作流的實踐者。我們下一篇見。
本文方法與案例為本人實作，草稿由 AI 協助整理。