我從 2023 年初就在用 AI 寫 code 了 —— 那時候連 vibe coding 這詞都不存在，就是把 code 貼給 ChatGPT 做 review 再 paste 回來的手工活。算是很早期就被丟進 AI 開發的人
後來 Cursor、Copilot 這些 IDE 內建的 AI 輔助出來，改用它們。到 2025 年中 Claude Code 出來，它漸漸變成我的主控台 —— terminal 裡直接跟 AI 對話、讓它讀整個 codebase、跑指令、自己修 bug。後來再加了 Codex 跑長任務、Kiro 跑多模型路由（Kiro 是 AWS 出的 coding agent，能切不同家的 model）
到現在，我同時用四個 AI coding agent，各自有自己的設定檔、自己的規則、自己的脾氣
我之前寫過《從 Prompt 到 Graph：AI Engineering 這兩年到底在演什麼》講五層演化。這篇是那篇的施工日記 —— 當你真的把那幾層蓋起來、多個 agent 同時跑，實際上會遇到什麼
你可能會問：為什麼不選一個就好？
老實說，我也問過自己這個問題。答案是 —— 我試過只用一個，但每個都有讓我受不了的短板。Claude Code 判斷力最強但用量大，容易撞到上限（token limit）；Codex 能跑整天不用盯但沒有判斷力，會照你說的傻做；Cursor 的 IDE 體驗最好但不能在背景自己跑（headless）；Kiro 能切不同 model 但不認識 Claude 的指令
所以我全都用了。然後問題就來了
AI coding 的三個世代，我在哪裡
回頭看，這兩三年 AI coding 工具的演化很清楚：
第一代（2023）— 手工期：ChatGPT 爆發，大家把 code 貼進去問問題再貼回來。沒有整合、沒有 context、每次都要重新解釋你的 codebase。我在這時候入場
第二代（2024）— IDE 期：Cursor、Copilot 把 AI 嵌進編輯器，能看到你正在改的檔案。Devin 喊出「AI 軟體工程師」的概念，大家開始想像 AI 不只是建議者。我在這時候不再手工貼 code，改用 IDE 裡的 AI 直接改
第三代（2025-26）— Agent 期：Claude Code、Codex CLI 出來。AI 從「給建議」變成「自己跑指令、改檔案、跑 test、iterate 到成功」。同時多 agent 平行（Agentmaxxing）變成可能。我在這時候開始搞「怎麼管理這些 agent」
多數人現在在第二代跟第三代之間。我這篇講的是第三代走到深處的問題 —— 不是「怎麼讓 AI 幫我寫 code」，是「當你有好幾個 AI 都能幫你寫 code，你怎麼不讓它們打架」
有趣的是，光是在 Claude Code 這一個工具上，我就把五層幾乎走過了 —— 從「怎麼下 prompt」→「怎麼給 context」→「怎麼用 hook 強制」→「怎麼讓它自己改善」→「怎麼管多個 agent 的關係圖」。最後一層我剛踏進去，目前只做到平行分工，還沒做到 agent 之間互相退件、形成真正的有向圖。第四個工具（Kiro）是我走到第五層才需要的，不是一開始就四個一起用
業界怎麼做？跟我的差別
我研究了一圈，2026 年中大家的做法大概分三派：
第一派：按「工作地點」分工
有人整理了一套蠻實用的分工法：Cursor 靠近 code、Claude Code 靠近 terminal、Codex 靠近 task 管理
流程是：Cursor 找 context → Claude Code 實作 → Codex review → 人在 Cursor 收尾
用白話說就是「一個讀、一個寫、一個改」
跟我的差別：我不用 Cursor 當入口。我直接在 terminal 工作，因為我的專案多到不可能一個一個開 IDE。而且我加了 Kiro 這個角色 —— 它當我的「半夜值班員」，這個後面會講
第二派：Agentmaxxing（暴力平行）
「Agentmaxxing」= 盡可能同時跑多個 agent，各做各的 task，你只負責 merge。聽起來很爽對吧？但實作上要嚴謹 —— 每個 agent 要鎖在自己的獨立工作資料夾（git worktree），有明確的 task 邊界 + 自動檢查關卡（automated gates），最後循序合併，不能讓兩個 agent 改同一個檔案
跟我的差別：我目前「平行」程度不高。多數時候是一個 session 跑到底，偶爾叫一個獨立 agent 出來做 review。真正的「三個 coder 同時寫三個 module」我還沒做到 —— 一方面是案子單人接，另一方面是我的 context 管理還沒好到能同時追蹤三條平行線。這是我下一步想改善的
第三派：雙 agent 互補
有人直接說「一個管 thinking，一個管 execution」—— Claude 想、Codex 做。不搞三四個，就兩個，角色清楚
跟我的差別：這最接近我的核心做法。但我多了 Kiro 和 Cursor 處理特殊情境，所以架構更複雜
補充：Stripe 怎麼解同樣的問題（但 4,000 人 scale）
最近 Stripe 的 Data & AI 負責人 Emily Glassberg Sands 分享了他們內部知識型 AI 平台 Kai 的做法。有趣的是，他們碰到的問題跟我一模一樣，只是 scale 完全不同：
- 他們也試過讓大家各自建 agent → 結果 4,000+ 個 micro-agent 品質參差、維護困難（我的版本：321 個 skill 在 context budget 邊緣）
- 他們也發現 coding agent 對非工程師不夠用、有資安風險
- 他們的解法：建一個三層平台（Surface API / AgentStudio 控制面板 / 共用執行環境）—— 概念上跟我的「CLAUDE.md / Skills / Hooks+Agents」是同一個思路
最讓我注意的是他們列出的未來方向：「Reflection and self-improvement — 讓 AI 能反思 trace、提出改進方案、測試、提交給 owner 審核」
這正是我這週剛建的東西（半夜 cron 跑反思 → 自動改規則 → 存追蹤檔等我審）。Stripe 4,000 人的團隊把這列為 roadmap，我一個人先做了一個窮人版。不見得做得比他們好，但方向一樣
我做得跟別人不一樣的地方
1. 我把 Claude Code 當「工頭」不是「工人」
業界多數人還是讓 Claude Code 自己寫 code。我用了一年多之後發現 Claude 判斷力 > 執行力，所以我設計成「Claude 只規劃 + 驗收，不自己寫 batch code」。寫 code 委派給其他 executor
具體怎麼做的：
我在主設定檔裡寫了一條委派規則：
≥2 個檔案的實作 / batch / 重構 / 翻譯 → 委派給 executor（Codex / Kiro subagent） → Claude 只負責：寫 spec、驗收結果、commit
每次委派時，我還要在 prompt 裡明寫紀律：
你必須遵守：
- 先寫一個失敗 test → 最小實作讓它 pass → refactor
- 沒有 failing test 不准寫 production code
- 完成時附證據（test output），不要只說 "tests passing"
代價是：這段紀律每次委派都要手寫一次。因為 executor 讀不到我的主設定檔。跟帶人一樣 —— 你腦袋裡的 SOP 不寫下來交接，新人就是不會照做
2. 我有一套「規則自動 sync」機制
業界的建議通常是「在 repo 放各工具各自的設定檔，各讀各的」。我嫌這樣要維護多份，所以設計了單一 SOT（source of truth）+ 自動繼承：
具體架構：
| 工具 | 怎麼繼承主設定 | 效果 |
|---|---|---|
| Kiro | agent 設定裡直接指向主設定檔的路徑（不是 copy） | 我改主設定，Kiro 下次啟動自動拿到最新版 |
| Kiro Skills | 用萬用字元（wildcard glob）掃整個資料夾 | 我新增一個 skill 檔案，不用去「註冊」它 |
| Cursor | hook 自動把主設定轉成 Cursor 格式 | 改一邊，另一邊自動跟 |
| Codex | hook 自動產出 AGENTS.md | 同上 |
一句話：我只改一個地方，四個工具都跟上
壞處：偶爾會不同步 —— 尤其是各工具的防護規則（hooks）格式不同，改了一邊忘了另一邊也要調。這就跟任何「不重複」（DRY）的架構一樣，抽象層省了重複但增加了「搞不清楚到底生效了沒」的 debug 成本
我踩過的坑：有一次我在 Claude 加了一個防護 hook（「跑自己寫的 test 要提醒用獨立 agent」），加完覺得搞定了。結果那個 hook 根本沒有註冊到設定檔裡 —— 檔案存在但系統不知道它在那裡。等於裝了鎖但沒上鎖。直到 review 時才被抓到
3. 我讓 AI 半夜自己反思
這個我在業界沒看到別人做。多數人的 AI 是「你叫它它才動」。我設了排程讓 AI 在半夜不開畫面自動跑「自我反思」—— 掃我糾正它的紀錄，自動改行為規則
具體怎麼做的：
- macOS 內建排程（launchd）設三個定時任務：週六 03:00 跑反思、週日 03:00 跑週回顧、每月 1 號跑月度分析
- 排程觸發 Kiro CLI 用
--no-interactive（不開畫面）模式啟動，餵一段自然語言指令：「掃描最近被糾正的紀錄，找出行為模式，寫一份改善規則」 - AI 跑完會自動把結果寫進一個追蹤檔（JSON），標記為「未讀」
- 下次我開 session 時，啟動程序會讀那個追蹤檔，跟我說：「你有 2 筆未讀的改善建議」
流程大概長這樣：
半夜 03:00（我在睡）
- 排程喚醒 AI
- AI 掃「我上週糾正它幾次、糾正什麼」
- AI 自己寫一條新規則（例如「pipeline 驗證必須三角交叉」）
- 存進追蹤檔（status: unread）
- commit + push 到 repo
隔天我醒來開 session
- 啟動時讀追蹤檔
- 提醒我：「AI 昨晚自己加了一條規則，你要看嗎？」
- 我看過標 read，或覺得不對改掉
關鍵設計：AI 能自動改「它自己的行為規則」（低風險、可逆、下次改回來就好），但不能自動改「客戶面的東西」或「花錢的設定」。我用這條線區分什麼讓它自己來、什麼要等我
聽起來很酷，但這是這週才建的，還沒跑過第一次。可能會有一堆問題。這些都是「設計時覺得很完美、跑起來才知道哪裡壞」的東西
還在磨合的事（自我檢討）
我不打算假裝這套已經很完美。幾個我還在摸索的地方：
1. 「自主推進」vs「停下來問」的邊界
我被自己的 AI 煩死了 —— 它每做完一步就停下來問「要繼續嗎？」。明明是低風險的事（跑個 test、sync 個檔案），它還是停。我加了一條規則「低風險可逆的步驟不要停」，但這條能不能真的在未來生效？靠的是 LLM 的 reasoning，不是硬性 guard
業界做法：各工具有 auto-apply 或 fire-and-forget 模式，但都是全開或全關，沒有「看情況判斷」
我想要的：AI 自己判斷什麼時候該問、什麼時候直接做。像一個有經驗的助理，不會每件事都來確認，但真正重要的事一定先問。這需要時間磨合 —— 就像帶新人一樣，你不可能第一天就說「你全部自己來」
2. subagent 的「去脈絡化」
這週出了一個 bug：我寫了一個 script，然後自己跑 test 驗證。結果 test 全綠。但我用一個獨立的 agent（沒有帶我的 context）去跑同一份 test，它找到 2 個 FAIL
原因是我的主 session 知道正確答案（我剛寫完 script），所以我的「驗證」其實是確認偏誤 —— 我不自覺地繞過了 bug，因為我「知道它應該怎麼跑」
業界有人提「coordinator + specialists + verifier」模型 —— verifier 必須是獨立 agent。跟我的教訓一樣。但多數人還是直接在同一個 session 跑 test 就當驗證了
3. context budget 爆炸
我的設定檔案量很大。幾百個 skill、數十個防護規則（hooks）、上百個 memory 檔。每次開 session 都在 AI 一次能讀的資訊量上限（context window）邊緣。業界的建議是「按 agent 載入不同 context」—— 不同角色只載它需要的規則，不包山包海
我目前用一個 catch-all agent 做所有事。下一步應該拆成專門分工的 agent（specialist agents）。但這是一個大工程，不是一天能做完的
4. 習慣養成需要時間
最難的不是設定工具，是改變自己的習慣：
- 我習慣在同一個 session 做所有事（而不是委派）
- 我習慣看到結果才相信（而不是信任 agent 的回報）
- 我習慣每件事都自己確認（而不是讓 AI 自主推進）
有調研說 43% 的 AI 改動需要 developer debug。所以不信任是合理的 —— 但「完全不信任」跟「完全信任」一樣有問題。信任的刻度要隨著磨合調整
這跟你有沒有用過 AI 工具的經驗有關。我從 2023 就開始用了，快三年，這些習慣還在調。如果你才剛開始，不用急，慢慢來
我搞混的事、做錯的事、以及改了之後才發現很有用的事
定義搞混：我以為我在做 Graph，其實只是 fan-out
我一直跟別人說「我在做 multi-agent graph」，直到有人問我：「你的 agent 之間有退件機制嗎？A 做完 B 檢查，不對退回 A 重做？」
沒有。我只是把五個 agent 平行丟出去各做各的，做完我自己收。這叫 fan-out（平行展開），不叫 graph（有向依賴圖）。真正的 graph 是 agent 之間有 edge —— 誰的輸出是誰的輸入、誰可以把誰退回去重做
這個誤解讓我意識到：你用了一個工具的某個功能，不代表你到了那個 engineering 層級。就像你會用 git branch 不代表你有 branching strategy
一直沒改但改了很有用的事：定期反思
我知道「定期回顧」很重要。每本管理書都講。但我從來沒有真的做到 —— 一忙就跳過，一跳過就三週沒回顧，然後同樣的錯一直犯
這週我終於把它自動化了：設排程讓 AI 每週六凌晨自己掃「我糾正它的紀錄」，自動改行為規則。我不用親自做「回顧」這件事了 —— 它在我睡覺時發生
但這裡有個 insight：從有意識 → 無意識 → 自動化，中間有一個危險的跳躍
有意識：我手動跑 /reflect，看報告，自己判斷要不要改
無意識：養成習慣，每次收尾自動掃一遍（嵌進流程裡）
自動化：排程讓 AI 自己跑，我不用在場
問題是：自動化之後，我怎麼知道它改對了？ 它掃到我說了三次「go」，就自己加一條規則「以後不要停」—— 但也許那三次裡有一次是該停的
人類要介入的點：抓大放小
我目前的判斷標準很粗暴：可逆的讓它跑，不可逆的一定停
但「可逆」跟「不可逆」之間有一大片灰色地帶。刪一個檔案是不可逆的，但 git 裡有歷史所以其實可逆。Push 到 private repo 是「可逆」的（可以 revert），但如果已經觸發了下游 CI 那就有副作用
我發現真正有用的不是定義一條完美的線，而是定期去翻「AI 自動做了什麼」的紀錄。就像主管不需要每件事都參與，但一定要定期翻報告 —— 不是為了挑錯，是為了校準自己的信任刻度
具體來說：
- AI 自動產出的 feedback memory → 我每週掃一遍標題，看有沒有離譜的
- AI 自動 commit 的東西 → 我看 git log 一眼，不逐行讀
- AI 跑完 retro 的 action items → 我只看「建議改什麼」那欄，決定做不做
抓大放小的關鍵是：你要知道什麼是「大」。對我來說：
- 改我的行為規則 = 小（錯了下次改回來）
- 改客戶面的東西 = 大（退件成本高）
- 砍案 / 接案 / 承諾 = 大（不可逆）
- 寫 memory / 整理檔案 = 小（隨時覆寫）
給你的思考
如果你也在用多個 AI 工具，我想問你幾個問題（也是我問自己的）：
你現在最痛的地方是什麼？ —— 是工具之間規則不一致？是每次都要重複說同樣的話？是不知道哪個結果能信？找到痛點再設計，不要先設計再找問題（我就是先設計再找問題的反面教材）
你能接受多少「失控感」？ —— 讓 AI 半夜自己跑、自己改規則，你 OK 嗎？還是你需要每一步都親眼看到？沒有對錯，是個人工作風格
你的案子量值得這套架構嗎？ —— 如果你只做一個產品，一個 Claude Code 加一份設定檔可能就夠了。四個工具的協調成本不低，要到一定 scale 才值得
最後
我最想知道的是：你怎麼決定什麼時候信任 AI 的判斷、什麼時候自己介入？
我自己的答案還很爛 —— 目前是「可逆的就讓它跑，不可逆的一定停」，但這條線我一週改三次