一個人帶一隊 AI：三層開發迴圈與多代理並行不翻車
用 AI 寫程式的人遲早會走到同一個轉折點：代理在跑任務，你在旁邊等得發慌，於是開了第二個視窗，讓另一個代理做別的事。恭喜，從這一刻起你不再是工程師，你是一個小型開發團隊的主管——只是團隊成員不睡覺、沒記憶、偶爾還會互相踩腳。
Gene Kim 與 Steve Yegge 在《Vibe Coding》第三部（第 13 到 16 章）處理的正是這個轉折。他們的框架很簡單：開發工作其實是同一套「寫、跑、驗、修」在三種時間尺度上重複，他們稱為內圈、中圈、外圈，每一圈都要做三件事——預防、偵測、修正。我重建 pbtw.tw 整個過程幾乎就是照這套框架跑的（雖然當時還沒讀到這本書），所以這篇我會把書的方法和我的實戰對照著講。
這篇文章拆解《Vibe Coding》的內圈、中圈、外圈三層開發迴圈，從 checkpoint commit、AGENTS.md、備忘錄法到多代理隔離，並對照我重建 pbtw.tw 的實戰經驗。適合已經開始用 AI 代理寫程式、正準備開第二個視窗的人閱讀。
三層迴圈白話版：同一套動作，三種時間尺度
內圈（秒到分鐘）是你和 AI 的每一次交手：下指令、看產出、驗證、存檔，幾分鐘轉一圈。中圈（小時到天）是工作階段之間的交接：今天收工、明天接著做，或這個對話塞滿了、開下一個對話接力。外圈（週到月）你幾乎不碰程式碼了，管的是架構、工作區邊界和自動化防線。三圈的失敗模式完全不同：內圈翻車你損失幾分鐘，中圈翻車你損失一個下午重建上下文，外圈翻車——書裡 Steve 兩個 repo 被代理混在一起，整整一天報銷。
內圈：checkpoint commit 是你的遊戲存檔
內圈的預防核心只有一招，但要練成反射動作：每完成一小段能動的成果就 commit 一次，把版本控制當遊戲存檔點。兩位作者用 AI 之後 commit 頻率暴增（Steve 說他變成原來的四倍），理由很實際：AI 弄壞東西的速度跟它寫程式的速度一樣快，出事時最好的逃生路線就是回到上一個存檔。而且存檔多了你反而敢冒險——書裡 Gene 用兩個 branch 並行試了兩種介面方案，試完砍掉輸家，睡得特別安穩。
有趣的是兩位作者對「讓不讓 AI 自己 commit」立場相反：Steve 允許代理在證明它真的理解問題之後自己提交，但每換一個任務就收回信任重新審查；Gene 則永遠不放行，堅持每個存檔點都親手建立。這不是誰對誰錯，是風險偏好——我自己偏 Gene 派，因為 commit 訊息是我事後追兇的主要線索，我會順手要求 AI 把「為什麼改」寫進去，回滾時才知道要退到哪一格。
中圈：AI 每天都失憶，你需要備忘錄法和一本工作手冊
重點：中圈最殘酷的事實是：AI 沒有隔夜記憶。
今天聊得再深入，明天開新對話就是一張白紙，所有脈絡、約定、踩過的雷，全部歸零。書中給了兩個互補的解法。
第一個是 AGENTS.md——寫給 AI 的工作手冊。把不可妥協的規則寫成文件，每次對話自動帶上：永遠不准把金鑰提交進版本庫、不准動既有模組介面、測試先寫再實作。重點是「精選」而不是「齊全」——規則清單越長，AI 越不遵守，就像牆上貼一張字越小的廚房守則，沒有人會看。只留黃金規則：永遠要做的，和永遠不准做的。這份文件還有個隱藏紅利：新的人類同事加入時，讀它就知道這個專案怎麼跟 AI 協作。
第二個是備忘錄法（書中直接用電影《記憶拼圖》命名）：主角無法形成新記憶，只能靠紙條和刺青把資訊留給下一個自己。對應到實務：當上下文視窗用掉一半左右，別硬撐到系統自動壓縮，主動叫 AI 停下來，把目前進度、計畫和卡住的點寫成一份 Markdown 交接文件，然後開新對話、餵這份文件接力。我重建 pbtw.tw 時每個工作階段收尾都做這件事，隔天的第一句話永遠是「讀進度筆記，從上次卡住的地方繼續」，省下的暖機時間以小時計。
多代理並行：分爐台、掛名牌、開看板
到了多代理，書的比喻是廚房的「髒砧板」：一個廚師剛切完生雞肉，甜點師接著在同一塊砧板上揉麵糰——兩個任務各自看起來都沒問題，共用了同一個資源就交叉污染。代理之間的共用檔案、共用 port、共用 branch，全是髒砧板。
預防靠三個隔離條件：分開（各做程式碼的不同區塊）、鬆耦合（別讓兩個代理同時改一條介面的兩端）、介面清楚（模組之間的契約先定好）。再加一層工作區紀律：目錄、repo、branch 全部明確命名，branch 名帶上代理或任務名稱，像維運老手用紅色終端機代表正式環境一樣，給每個工作區掛名牌。
但書裡最誠實的提醒是：並行的管理成本不是線性的。Steve 從兩個代理擴到四個，生產力理論上翻倍，協調工作卻暴增十倍——他記不住每個代理在做什麼，最後做了一個「指揮看板」：一份文件記錄每個代理的角色、任務佇列、所在 branch 和最新狀態，任務開始與結束都要更新，否則整鍋粥。
這段我有完整的對照經驗。重建 pbtw.tw 時我同時開了多個代理：文章頁模板、課程頁、建置腳本各一個。真正讓這件事沒有翻車的不是代理多聰明，是一塊子任務看板——每張卡片寫清楚範圍和驗收條件，代理領卡開工，我輪流到每個爐台前驗菜。中途還撞上一次書裡沒寫但你一定會遇到的狀況：多個代理同時打 API，直接觸發過載限流，全部卡住。我的解法很不浪漫——把並行改成分批串行，一批做完再放下一批。
我的經驗：並行是手段不是信仰，塞車的時候，排隊比硬擠快。
等待的時間別浪費：讓代理自我批評
多代理最常見的浪費，是代理做完了安靜地等你，而你正忙著看另一個爐台。書中的解法是準備一串「回鍋指令」，代理一閒下來就丟給它：把全部測試重跑一次並回報、替自己的程式碼找邊界案例、寫一個能弄壞自己方案的測試、清掉臨時檔案和殘留 log、寫一份交接摘要。背後的原理是 AI 審查比生成更拿手，Anthropic 自己的最佳實踐也說：第一版可以，迭代兩三輪之後通常好很多。Steve 估計這招替他多擠出一到兩成的有效產出。
流程總覽
常見問題
問：我一次該開幾個代理？
答：從兩個開始，而且最好是兩個不相干的專案，踩腳機率最低。書中的經驗是超過一手之數（四、五個）之後，沒有看板和命名紀律一定亂；我自己的上限訊號是「想不起某個代理在做什麼」，出現這個感覺就代表該收斂，而不是該更努力。
問：AGENTS.md 該寫多長？
答：寧短勿長。一頁以內的黃金規則遵守率最高；專案細節（慣例、目錄導覽、測試指令）可以分層放，但「永不/必須」等級的規則最多十來條。記得定期請 AI 幫你瘦身這份文件——規則也會過期。
問：commit 太頻繁，歷史會不會很髒？
答：會，但這是值得付的代價，事後可以整理壓縮。存檔的目的不是漂亮的歷史，是讓你敢放手讓 AI 衝——況且 Git 考古這種苦工，AI 本身就是專家，書裡 Steve 被刪掉的整套測試就是請 AI 從幾十個 commit 之前挖回來的。
問：並行撞到資源衝突（API 限流、port 占用）怎麼辦？
答：先降速再優化。我的做法是改分批串行，穩定後再評估要不要做真正的隔離（各自的環境、各自的金鑰）。書中的原則是一樣的：偵測到代理互相干擾，就回頭重切工作區，而不是叫代理「小心一點」——AI 不會小心，只有結構會。
三層迴圈的本質，是把「不放心」變成節奏而不是焦慮：內圈存檔、中圈交接、外圈劃界。想看這本書的整體脈絡，可以先讀我的總覽文〈連 DevOps 教父都下場了〉；如果你想用一個真實專案把這套節奏跑熟——從拆任務到多代理收斂——時程規劃可以參考〈四週用 AI 做出你的 MVP〉，或直接來我的 Vibe Coding 實戰課，我陪你帶你的第一隊 AI。
這篇文章的原始書摘整理在：/note-vibe-coding-kim-yegge/