工作流

用 AI 工作一陣子的人，大概都遇過這件事：同一個錯，你講過了，規則也請它記下來了，過幾天它又犯一次。 而且我不是沒有防：規則寫進了它的記憶檔、違規有計數器、還有每月的定期檢視，該有的機制都在。但七月底，我看著我的 AI 助理第三次犯下同一個錯（最後兩次只隔一天），才認真面對一個事實：「記得」跟「會做」是兩回事。而更意外的是，後來的調查發現，問題甚至不在它不記得，是我們整套「記錯誤」的系統，量尺本身壞掉了。 這篇想分享的，就是我們最後長出來的一套「AI 自我糾錯系統」的設計，以及中間最有趣的一段：我讓 AI 自己調查自己，還特別交代它「不要相信寫交班單的那個 AI」。 事情是怎麼爆開的 這陣子我陸續把一些自己做的工具開源（工具箱總整理裡的那些）。發布開源軟體有一套禮儀：改了什麼要寫進更新紀錄（CHANGELOG）、打版本標籤（tag）、在 GitHub 上建立正式的發布頁（release）。這些規則早就寫在 Claude 的記憶檔裡。 七月底某天，我點開一個剛發布新版的 repo，首頁看起來什麼都沒有。我第一反應是「你沒寫 CHANGELOG」。它查了之後回報：CHANGELOG 其實寫了，tag 也打了，漏的是最後一步「建立 release」，而那恰好是訪客唯一看得到的一步。回頭一查，前兩個版本也都一樣。 隔天我請它把我全部十三個公開 repo 掃一遍，結果挖出十五個同樣的缺口。更妙的是，就在稽核到一半的時候，它又犯了第三次同型的錯。規則就寫在它的記憶裡，它也讀得到，然後照樣犯。 關鍵的一問:「你以後真的會用嗎？」 它的第一個提案很自然：寫一支腳本，把正確的發版流程整個包起來。 我問了一句：「你以後會固定呼叫這支腳本嗎？」 它想了一下，誠實地說：不會。腳本跟記憶檔的失效模式一模一樣，都要它先「想起來」才有用。這個答案讓我們改變了做法：與其多一個要記得的東西，不如加一道攔截（hook，上手系列第二篇講過的關卡概念）：只要它想手動跑發版指令，動作會在當下直接被擋下來，只剩包好的正確流程能走。從「請你記得」變成「你想錯也錯不了」。 讓它調查自己，但不准相信自己 前面說過，揪錯的零件一直都在。所以問題比「沒有機制」更刁鑽：零件都在，錯還是溜過去了，到底卡在哪？ 這裡我們用了一個我很喜歡的設計。當天犯錯的那個 AI session 把來龍去脈寫成一份調查交班單，但裡面明白寫著一條： 交班單裡的自我迴避條款 「不要把我的假設當成計畫——這份文件是犯錯者本人寫的，幾乎必然被它的立場影響。請先獨立驗證診斷，再決定要不要建任何東西。」 接著換一個全新的 session 接手調查，手上只有可以重跑的驗證指令，沒有前一位的結論。 做過品質改善的人應該覺得眼熟：根本原因分析（root cause analysis）的調查，本來就不該由事件當事人自己主導。當局者迷這件事，對 AI 一樣成立。 調查結果：推翻了兩個前提 獨立調查翻出來的東西，跟交班單猜的不一樣。 第一，AI 並沒有隱瞞錯誤。我原本合理懷疑：違規次數是它自己記的，它會不會少記？結果翻遍紀錄，低報只有零星幾筆，而且是「自首了但記錯地方」。其中一個規則檔裡，它老老實實記了十二次違規，好幾次我根本沒發現。誠實度不是問題。 第二，問題出在量測層。幾個具體的發現： 計數無法歸屬：違規次數記在「檔案」上，但一個檔案裡合併了十幾條規則。帳面上的「違規 4 次」，追不回是哪一條規則的 4 次，這個數字沒有行動意義。 偵測器本身有 bug：負責從歷史對話裡撈「使用者糾正過什麼」的程式，寫死了只看最近二十筆，而且漏看一整類訊息格式。回頭驗證時發現，最關鍵的那筆證據，它從結構上就不可能抓到。 記錯帳本：有三筆真正的違規，被寫進了另一本記「工具摩擦」的帳，正好躲過所有檢查。 還有一個反轉：交班單斷言「這些計數完全沒有版本紀錄，無從稽核」。錯了——記憶目錄其實一直有自己的 git 版本庫，一千多筆自動存檔，稽核軌跡從頭到尾都在，只是被上層設定蓋住，連 AI 自己都不知道。 換句話說：這個系統不缺零件，缺的是接線。計數器沒有人讀、偵測器壞著、帳本記錯棚。在量尺壞掉的情況下加更多自動化，只是把錯的數字算得更快而已。所以後面的修法幾乎沒有新建什麼大東西，都是把既有的零件接起來。 最後的設計：四條原則 修完之後，整套系統收斂成四條原則。它們不是 AI 專用的，你會發現每一條在醫院的品質管理裡都有對應物。 一、錯誤要記成「可歸屬的事件」，不是一個數字。每次違規記一行：日期＋哪一條規則＋一句事實。計數是用數的，不是用手改的。（對應：異常事件通報寫事件經過，不是只在統計表上加一。） ...

這是 AI 上手系列的第三篇。第一篇講怎麼裝起來，第二篇講怎麼跟它講話、怎麼設關卡。 第二篇的結尾我說：難的從來不是「怎麼問」，是「怎麼設計流程」。 這篇要把那句話收掉。答案可能跟你想的相反：流程不是設計出來的，是長出來的。 最常見的卡點：「我不知道要怎麼開始規劃」 我被問過很多次類似的問題：「你那套自動化好厲害，我要怎麼規劃我自己的？」 老實說，我從來沒有規劃過。我三月的時候只做了一件事：挑了一件每週都在重複的小事，叫它做一次。 今天回頭看，我的規則檔、十幾個 skill、一堆自動排程，沒有一個是事先設計的。每一個都是同一件事重複了幾次之後，才「升級」成現在的樣子。 所以如果你卡在「不知道怎麼開始」，好消息是：你不需要想清楚才開始，你只需要開始得夠小。 起手式：五件事講清楚，其他都不用 挑好那件小事之後，交代它的時候把這五件事講清楚。這不是我發明的，是把官方 best practices 濃縮成非工程師版本： ① 目標講清楚：你要什麼、給誰用、拿去做什麼。「幫我整理逐字稿」不如「整理成 SOAP 格式，這是要放進病歷系統的」。 ② 只補它不知道的：你們科的慣例、單位的格式、只有你知道的眉角。模型已經會的不用教：SOAP 是什麼不用解釋，你們科的 SOAP 長什麼樣才要講。每一句廢話都在稀釋它的注意力（原因寫在第二篇「為什麼它會越聊越笨」那節）。 ③ 界線先講：哪些檔案不准動、哪些事要先問過你。而且真正的紅線不要只用嘴巴講，第二篇的三層機制（hooks / permissions / CLAUDE.md）就是拿來放這個的。 ④ 訂「怎樣算做完」：這條是官方排第一優先的建議，也是我覺得投資報酬率最高的一條。給它一個它能自己跑的檢查： ❌「幫我整理這些逐字稿」 ✅「整理完自己檢查一遍：每一份都要有四段、每段都要有內容，缺的標出來給我」 ⑤ 先跑一個爛版本：不滿意再一句話改。迭代永遠比一次寫滿快。 就這樣。不用畫流程圖、不用寫規格書。 流程怎麼長大：重複第三次，就升一級 真正的重點來了。你的「流程」不是某天坐下來設計的，它是照一個很簡單的規則長出來的： 同一件事重複到第三次，就往上升一級。 你發現自己在… 升級動作 成本 同一句話講第三次（「回我繁體中文」） 寫進 CLAUDE.md 一行字 同一套多步驟流程做第三次（先轉檔、再整理、再歸檔） 包成 skill：跟它說「把剛剛這整套存成一個 skill」 一句話 發現某件事絕對不能出錯（改到原始檔、送出病人資料） 交給程式關卡（hook / permissions） 要動手設定，但一勞永逸 三層的差別在第二篇講過了，這裡只補一句：寫在規則裡是建議，做成機制才是保證。 界線越重要，就該住在越下面那層。 這個階梯還有一個隱藏的好處：每一級都是你已經驗證過的東西。你不是在憑空設計一個 skill，你是把一套「已經手動跑成功三次」的流程存起來而已。設計可能會錯，重複不會。 驗收的習慣：這篇最重要的一節 起手式的第④點（訂「怎樣算做完」）值得單獨拉出來講，因為它不是五件事之一而已。它是整套方法裡唯一「做與不做會決定你能走多遠」的習慣。 驗收有三個層次，照順序養成： 層次一：單次驗收。 每個任務交代時就附上檢查方法，讓它做完自己查（「每一份都要有四段、缺的標出來給我」）。這是起手式教的。 層次二：可重跑的驗收。 把檢查存下來，變成隨時可以再按一次的按鈕。差別很大：單次驗收保證「這次做對了」，可重跑的驗收保證「以後改東西也不會弄壞它」。工程師管這個叫回歸測試（regression test），但概念本身跟程式無關：哪怕你的檢查只是「數一數每份紀錄都有四段」，能重跑，就有資格叫驗收。 層次三：驗收先行。 這是官方 best practices 裡明講的工作流：先寫檢查、確認它現在會失敗，再叫 AI 做到通過。聽起來像工程師的儀式，翻成白話就是：開工前先給它看一個「做對了長這樣」的具體例子。它有目標可以自己迭代，你也不會做完才發現彼此想的不一樣。 ...

上一篇 《從零開始》 講的是怎麼裝、怎麼跑起來。 這篇講的是用得好，而這跟裝得起來，是完全不同的一件事。 我發現真正決定成效的不是你用哪個模型、不是你會不會寫程式，是你怎麼交代事情、怎麼設關卡。這篇的東西不綁特定工具，你用 ChatGPT 也適用（最後一節會講差在哪）。 三個心法 心法①：它像個很聰明、但記憶有限的新人 它知道很多，但它有一張有限的桌面。塞太多東西就會顧此失彼、會忘記你前面講什麼。 用交班來比喻最好懂：講重點、講清楚，別把整本病歷從頭念一遍。 所以你要主動幫它保持桌面乾淨：一個任務講清楚、講完就 /clear 重開，不要一路累積用不到的東西。 （為什麼會這樣、成本怎麼算，我在 AI Token 經濟學系列 寫了四篇，這裡先講結論。） 心法②：用機制管，不要只靠它自律 這是我覺得最多人做錯的一件事：大家都在 CLAUDE.md 裡寫規則，然後抱怨它不聽話。 問題是，那份檔案在官方的定位裡，是「參考資料」，不是「強制設定」。官方文件講得很白： Claude treats them as context, not enforced configuration. （Claude 把它當成脈絡，不是被強制執行的設定。） 真正能管住它的機制有三層，強度差很多： 層級 是什麼 強度 適合放什麼 ① hooks 在它要動手的那一刻，由你的程式攔下來檢查 ⭐⭐⭐ 程式性強制，模型無法忽略 「這件事絕對不准發生」 ② permissions settings.json 裡的 allow / deny / ask 清單 ⭐⭐ 硬性擋下，但只認工具與指令樣式 「這類操作要先問我 / 永遠不准」 ③ CLAUDE.md 一份它每次開工都會讀的文字說明 ⭐ 靠它自律，可能被忽略 「通常我們這樣做」的慣例與風格 ① hooks：把規矩變成程式 hook 是掛在它生命週期上的一段程式。最常用的是 PreToolUse：它要動手之前先跑你的檢查，你的程式回傳「拒絕」，這個動作就執行不了。 關鍵差別在這裡：被 hook 擋下來的動作，不會回頭讓模型去想替代方案。它不是「勸退」，是「做不到」。 ...