瓶頸從來不是打字

AI 不只是讓打字變快——它把瓶頸整個搬走了。學會平行運行代理的團隊，在那些還在一次等一個差異變更的團隊眼中，將會面目全非。

我和 AI 的開發迴圈第一版很簡單。請助理做事情 A。等待。審查差異。換到事情 B。助理是一個更快的結對程式設計夥伴。仍然是結對。仍然一次做一件事。

那個模式維持了大約三個月。現在我不是這樣工作的。

我現在的做法，是讓多個 AI 程式設計助理平行地在同一個程式庫上工作，各自在自己的 git worktree 裡、各自在自己的分支上、各自同時處理不同的問題。任何時刻，各存放庫加起來都有五到十個活躍分支。不同的代理同時推進引擎的不同部分。我做審查與合併，而不是撰寫與等待。

我的工作發生的轉變，就是這篇文章。

一個真實的週末長什麼樣

三月中的一個週末。橫跨五個存放庫，從週六早餐到週日晚餐之間落地了 112 次提交。66 次的正式作者是 AI。47 次是我。其餘是合併與審查驅動的收尾。

這些工作不是一個專案，是五個。九種遊戲類型的 WASM 移植。iOS Metal 繪製器整合。一個讓二十一個素材通過七階段管線的內容包執行器。卡牌對戰類型的第五到第七關。Web 建置的效能最佳化。這一切都在同樣的兩天內、在平行分支上發生，並在每個下午和傍晚陸續落地。

沒有任何一個人類能在廚房餐桌前的一個週末打出 112 次提交。沒有任何一個人類能把五條平行工作流放進一顆腦袋，還為每一條寫程式碼。我三個月前的那個模式，產不出這個週末。

我現在的模式可以。

瓶頸移動了

當工作是循序的，瓶頸是打字。下一行程式碼在有人寫出來之前並不存在。AI 讓那一行變快了。但它沒有改變哪個步驟是慢的。

當工作是平行的，瓶頸是篩選。四個代理帶著四個差異變更回來。其中兩個是好的。一個方向正確但需要加工。一個根本不該被寫出來。慢的步驟是判斷孰是孰非，並合併存活下來的那兩個。

那和我受訓練從事的工作完全是兩回事。少一點打字。多一點分流。少一點合成。多一點篩選。

這個週末的形狀：

• 週六早上：定義問題。哪四個問題值得四次平行嘗試。每一個的成功標準是什麼。可接受的答案大致長什麼樣。
• 兩天全程：抽查。代理們在正軌上嗎？有沒有哪一個在前三十分鐘就信心滿滿地產出了錯誤的東西？有人卡住了嗎？
• 兩天的傍晚：審查與合併。差異變更陸續進來。帶著成功標準讀每一個。合併達標的。重跑或關閉沒達標的。記下失敗的嘗試教了我什麼關於這個問題的事。
• 週日結束時：寫下這個週末交付了什麼，以及下一批四個問題是什麼。

這更像是帶著四人團隊的技術主管，而不是配著副駕駛的資深個人貢獻者。它用的是不同的肌肉。而它用到的那些肌肉，在各領域之間出奇地通用。

這如何與 .raku 檔案結合

我們引擎執行的體驗檔案是 .raku 檔案：JSON、有結構描述版本、可驗證、可以像程式碼一樣審查。這個格式在設計時就考慮了這種平行代理工作流程。

當一個代理編輯 .raku 檔案時，差異變更的呈現方式和程式碼差異一模一樣。第二個代理可以審查第一個代理的工作。我可以再跑第三個代理抽查前兩者。合併的決定權在我。整件事都放得進我用在執行環境上的同一套 pull request 紀律。

如果 .raku 是二進位素材，這一切都行不通。格式的選擇和工作流程的選擇，是同一個架構決策的下游產物：體驗是程式碼、開發工作是程式碼審查、代理能參與這個迴圈，因為這個迴圈接受程式碼。

檔案格式是承重結構。它讓團隊得以透過代理而不是人頭數來擴張。

實務上行得通的做法

我固定下來的三個模式。

第一：讓代理成對處理一個問題。當某件事並非平凡瑣事時，兩個訓練不同的助理往往會產生有建設性的分歧。我用相同的提示讓它們在不同分支上跑，然後比對它們的答案。分歧之處正是真正需要投入審查注意力的地方。

第二：指定一個代理專職審查。任何一天，我都會讓四個助理之一維持在只做審查的角色。它從不寫初稿。它只批評其他代理產出的差異變更。運行一個專職審查者的成本很小。抓蟲率卻很可觀。

第三：讓代理的上下文保持窄小。一個代理、一個分支、一個問題，速度很快。一個代理面對蔓生的問題、帶著五小時的上下文，就會漂移並產出品質較低的工作。解法是把問題拆成更小的片段，並頻繁輪換上下文。

會出問題的地方

誠實面對行不通的部分。

協調開銷是真的。兩個代理同時改同一個檔案，會產生我必須解決的合併衝突。每次衝突的成本很小，但會累積。緩解方式：盡可能讓代理處理不同檔案，並接受收斂步驟是工作流程的一部分。

審查疲勞是真的。在每天結束時審查四個差異變更，比在四天內審查四個循序的差異變更更累。決策密度更高。在平行代理的日子裡，我比循序工作時更早收工。

什麼都想留下來的誘惑是真的。當兩個代理都產出了合理的東西時，偷懶的做法是兩個都合併。有紀律的做法是挑一個。兩個都合併會讓程式庫被同一件事的兩種做法污染，其代價比直接重跑落選者更高。

長時間平行工作階段的上下文漂移是真的。一個開了一整天的分支，會累積代理在起始時刻對程式庫所做的假設。到了傍晚，那些假設可能已經過時。解法是短命分支，毫不留情。

不是所有東西都能平行化。帶有微妙不變量的橫切式重構需要一次仔細的單獨處理，而不是四次平行嘗試。功力在於分辨哪些問題能乾淨地拆分、哪些不能。有些日子仍然是循序的日子。

這對工程主管的意義

如果你的團隊還在跑外掛了 AI 的循序模式，下一步的升級不是「用更好的模型」，而是「同時使用多個代理」。能力天花板更高。技能天花板也更高，而且它把資深角色從生產移向定義問題、驗證與篩選。這和我在其他每一個把 AI 用得好的領域看到的走向完全一致。

在接下來兩年內摸索出平行代理工作流程的團隊，在還跑循序模式的團隊眼中將會面目全非。改變的是工作的形狀。不是工具。

兩天 112 次提交。週日闔上筆電時，其中大多數都是綠燈。