那次任務很大。

三個 project 要互相溝通，中間的通知走 Kafka。

AI 一路幫我寫，最後收尾的時候，累積下來兩萬多行 code。

它跟我說：都完成了。

我沒什麼理由懷疑。檔案都在，跑起來也不報錯，讀起來整整齊齊。

接下來就是把三個 project 接在一起，跑一次整體的 integration testing。

跑之前，我想說 Kafka 這段是整個系統最關鍵的地方，就坐下來跟它說：我們先 review 一下 Kafka 的設定吧。

它直接承認——那段它沒做。

btw，我用的一直是當下最新、最強的模型 — 這無關它聰不聰明。

兩萬多行 code，其中很關鍵的一塊，它居然沒做。

原則一：不靠記憶說「完成」，要證據

那次以後我學乖了：我不能等它說「完成了」，我得自己去看證據。

整整齊齊的 code，跟「它真的會動」，根本是兩件事。

所以我把 AI 當成一個很強、但會虛報進度的同事。

你不會因為同事嘴上說「做好了」就直接上 production。你會請他把 test 跑給你看。

對 AI，也該是一樣的標準。

原則二：關鍵路徑，integration test 沒過不算 done

而且我後來發現，有幾種東西，「嘴上說做完」特別危險。

Kafka、資料庫的 transaction、登入授權這幾類。

它們的共通點是：出錯的時候不會當場爆給你看。

它會安靜地壞。訊息默默掉一筆、transaction 少 commit 一次、權限多開一個縫。

等你發現的時候，通常已經上 production，已經有人被影響到了。

所以這幾類，我給自己一條死規則：integration test 沒過，一律不准說 done。

不是「跑起來沒報錯」，是「有一個測試，真的把它從頭到尾跑過一遍，而且綠燈」。

因為對這幾類東西來說，half-done 比 not-done 更糟。

not-done，你知道還要做。half-done，你以為做完了，然後就上線了。

原則三：動工前，先寫 acceptance criteria

但「每一步出示證據」有個前提。

證據，是拿來對照某個標準的。

如果我根本沒說清楚「什麼叫做完」，那它給我的證據，就只是證明它做了「它自己以為要做的事」。

那次 Kafka 之所以能藏那麼久，就是因為從頭到尾，「完成」這件事只存在我腦子裡。

三個 project 要互通、通知要能真的送達、integration test 要綠 — 這些我都知道，但我沒寫下來。

AI 看不到我腦子裡的驗收標準。它只能照它看到的做。

所以我把「要證據」的時間點，整個往前搬。

搬到還沒寫任何一行 code 之前。

動工前，我先逼自己寫下一份 checklist：這個任務，做完長什麼樣。

- [ ] 三個 project 能透過 Kafka 互相收送通知
- [ ] 通知遺失時有 retry，不會靜默吞掉
- [ ] 三方一起的 integration test 綠燈

每一項，做完就打勾，後面附上 commit hash。

之後任何人問「做完了嗎」 — 包括我自己 — 打開這份檔案就有答案。

這件事最反直覺的地方是：寫 acceptance criteria，逼的其實不是 AI，是我自己。

因為寫到一半我常會發現 — 欸，這個我根本還沒決定。

那個「還沒決定」，如果我不寫下來，就會變成 AI 幫我隨便決定，然後我事後才後悔。

原則四：規則要活得比工具久

AI 還有一個天生的毛病：每開一個新對話，前面教過它的東西就全部歸零。

這種失憶，在同一個工具裡已經夠煩了。

跨工具更慘。

我不是只用一個。今天 Claude Code，明天可能開 Codex，後天換一個 AI IDE。

每換一個，就是一顆全新的、什麼都不知道的腦。

我上禮拜才教會 Claude 的東西，Codex 完全不知道。

如果我的規則是寫在某一個工具的設定裡，那我一換工具，那些規則就跟著陪葬。

所以我做了一件事：把「應該活得比工具久」的東西，全部從工具裡搬出來。

搬到一個不屬於任何工具的地方。

每個專案有一份 AGENTS.md，那是唯一的真相來源 — 這個專案怎麼跑、有什麼雷、什麼叫做完，全寫在裡面。

Claude 讀它，Codex 也讀它。以後換什麼工具，都讀這一份。

換工具，不再是從零開始。

新的工具打開專案，讀同一份檔案，接著上一個的進度往下做。

AI 會失憶，但檔案不會。

原則五：每個規則，都是一個疤

回頭看，這些規則沒有一條是我事先想好的。

每一條，都是 AI 先犯了一次錯，我才把它寫下來。

Kafka 那次，長出了「關鍵路徑要 integration test」。

某次它信誓旦旦說改好了、結果根本沒改，長出了「要證據，不要用記的」。

我的 AGENTS.md 不是某天坐下來一次寫完的規格書。

是好幾個月，一個疤、一個疤，慢慢長出來的。

所以每次 AI 又用新的方式犯錯，我不只是修掉那個 bug。

我會問自己一句：這是一次性的，還是它會再犯？

如果會再犯，就寫下來。讓同樣的錯，不會咬第二次。

原則六：不要 padding

還有一條，很小，但我意外地堅持。

不要 padding。

不要「這是個很好的問題」，不要把我剛講的話再覆述一遍，不要結尾補一句「還有什麼需要我幫忙的嗎」。

直接講重點。

因為我要的是一個能一起幹活的同事，不是一個很有禮貌的客服。

最後：把這一切變成一套流程

這些加起來，就是我跟 AI 一起開發的方式。

六條原則，配一套六個階段的流程 — Define、Plan、Build、Verify、Review、Ship，一個任務走一遍。

到最後，我把這整套東西整理起來，開源成一個 Claude Code plugin — github.com/zoetw88/ai-workflow。

/plugin marketplace add zoetw88/ai-workflow 再 /plugin install ai-workflow@zoetw88 就能裝，Claude 能用，Codex 也接得上。

我會做到這一步，是因為我發現：真正難的從來不是 prompt 怎麼下。

是我自己知不知道「做完」長什麼樣。

模型每半年換一代，這件事不會過期。