一個人管一隊 AI：我的派工規則
文 / Coolkid發布：2026-08-08閱讀約 8 分鐘
短答給趕時間的人：AI 分身(subagent，另開的獨立對話)好用之後，真正的門檻不是技術，是管理。我的派工制度三條：①派工單三要素，也就是目標與動機、驗收條件、回報格式，缺一不派 ②模型分級，機械活用快的便宜的、預設用主力、卡關才上最貴的 ③同一個方法最多試兩次，第二次還失敗就換方法或升級模型，不准原樣試第三次。外加一條鐵律：自己做出來的東西自己檢查等於沒檢查，驗收要交給沒參與過程的新分身。
這篇是 Subagent 教學的續集。
上一篇講分身是什麼、怎麼派。用了一陣子之後我發現，問題跟帶人一模一樣。
交辦不清楚，做出來的就不能用。
不驗收，你不知道能不能用;失敗了拗著同一個方法重試，燒掉的是你的額度。
所以我把派工規則寫成一份守則檔，放在 AI 每個對話都會讀到的地方，叫 AI 照著做。
這篇把那份守則白話拆開。附一個實測：2026 年 7 月 19 日，我用這套讓兩個分身同時改同一個專案的不同角落，零衝突，全程我只讀了兩份回報。
第一條：什麼該派出去，什麼該自己做？
先講一個限制：AI 的「工作記憶」(context window，也就是一個對話能記住的內容量)是有限的。
你在主對話裡讓 AI 讀十個檔案、貼五段錯誤訊息，那些過程中冒出來的東西會一直佔著記憶。
塞得越滿，AI 越容易忘東忘西。
派工制度的第一條就是保護主對話。什麼該派出去？費工又占地方的雜事派出去做，主對話只收結論。
| 一律派分身 | 主對話自己做 |
|---|---|
| 要讀 3 個以上檔案才能回答的調查 | 讀 1-2 個已知位置的檔案 |
| 掃整個專案找「某東西在哪」 | 單檔小修改 |
| 查網頁、讀外部文件、做研究 | 跟你確認事情、做決策 |
| 照同一個模式批次改一堆檔案 | 看狀態、存檔這類一步動作 |
判準一句話：這個動作過程中冒出來的東西，會不會佔掉主對話的腦容量？會就派出去，只收結論。
第二條：派工單三要素，缺一不派
- 要素 1，目標與動機。做什麼，加上為什麼要做。動機不是廢話：分身遇到你沒料到的狀況時，知道動機才能自己取捨，不用停下來回頭問你。
- 要素 2，驗收條件。可以逐條打勾的完成定義。我的經驗是，寫不出驗收條件通常代表你自己還沒想清楚要什麼，這時先想清楚，比先派工省時間。
- 要素 3，回報格式。規定回什麼、多長。我的固定格式是先講結論，證據附出處位置，超過 30 行的產出寫進檔案只回報路徑，禁止把整份檔案貼回來。
這三件事寫起來大概多花兩分鐘，省下的是「做出來不能用、整個重派」的整輪時間。
跟交辦同事一樣，一開始講清楚，後面才不用一直來回問。
第三條：模型分級，同一個方法最多試兩次
| 情境 | 派哪級 | 理由 |
|---|---|---|
| 模式已知的機械活：批次套用、格式轉換、簡單搜尋 | 快的便宜的 | 快又省，錯了成本也低 |
| 預設：實作、研究、初審、一般搜尋 | 主力等級 | 不確定就選這級 |
| 卡關：重試兩次仍失敗、架構決策、高風險判斷要第二意見 | 最貴的 | 貴的智力用在刀口上 |
原則一句話：省錢不是重點。
重跑一次的成本，比一開始就用對模型高得多。
不確定該不該用便宜的？就往上選一級。
不確定該不該直接上最貴的，先讓主力跑一輪，主力那一輪的失敗過程整理起來，就是給最貴模型最好的輸入。
升降級規則：同一個子任務、同一個方法，最多執行兩次(第一次加重試一次)。
第二次還失敗呢？禁止原樣試第三次。
必須換方法、升一級模型，或停下來問人。
便宜等級是例外：失敗一次就直接升級，不給重試。為了省錢重試便宜模型，通常反而省不到。
升級時要帶著完整的失敗紀錄，包括每次試了什麼、錯在哪、當時的假設。
不帶紀錄的升級，等於讓貴的模型把冤枉路重走一遍。
反過來，難題一旦解出模式，就把解法寫成明確步驟，降回便宜模型批次套用。
難的部分讓貴的模型解一次，剩下的重複工作交給便宜的做完。
鐵律：派出去的工作，誰來驗收？
自己做出來的東西，自己檢查等於沒檢查。
分身當初就是覺得對才那樣寫的，再看一次還是覺得對。
所以驗收一律派一個沒參與過程的新分身：給新分身驗收條件的原文，叫它讀成品逐條對照，回報缺漏的地方。
程式類的更簡單。跑起來，以執行結果為準。
「看起來對」不是驗證。
前面提到的那場實測是這樣。2026 年 7 月 19 日，我讓兩個分身同時改同一個開源專案。
分身 A 實跑工具掃我的網站(當時 123 頁，1.42 秒)產出範例報告，分身 B 讀程式碼確認設定檔格式，再寫一份範本。
兩個分身各拿一份專案的平行副本(git worktree，同一專案的多份獨立工作目錄)，同時動手、互不干擾，合併時零衝突。
我全程只做三件事：開副本、派工、讀兩份回報然後合併。
這就是「指揮官不下場」的樣子。
- 不寫驗收條件就派工。這是最常見也最貴的一個：做出來的東西方向不對，整輪重來，比當初多花兩分鐘寫清楚貴十倍。
- 拗同一個方法重試第三次。同樣的方法第三次成功的機率，低到不值得那些額度;會失敗兩次，通常是方法錯了不是運氣差。
- 讓分身把整份產出貼回主對話。腦容量被塞爆，後面的對話開始忘東忘西。長產出一律寫進檔案，只回報路徑。
新手的起手式很簡單。下次要 AI 查三個以上的檔案，忍住別在主對話做。
開一個分身，派工單寫齊三要素，只跟它要結論。
你會發現主對話乾淨很多，而「寫驗收條件」這個動作本身，就會逼你把需求想清楚。
AI 分身的門檻不是技術是管理，我的派工制度：①指揮官不下場，主對話只做拆解、派工、讀回報、決策，過程中會佔腦容量的活一律派出去，只收結論 ②派工單三要素缺一不派，也就是目標與動機(邊界情況能自行取捨)、驗收條件(寫不出來代表還沒想清楚)、回報格式(先結論、長產出寫進檔案給路徑) ③模型分級，機械活用快的、預設用主力、卡關才上最貴的;省錢不是重點，重跑一次的成本更高 ④同一個方法最多試兩次，失敗要帶完整紀錄升級，解出模式再降級批次套用 ⑤驗收不能自己來，交給沒參與過程的新分身對照驗收條件。實測：2026-07-19 兩個分身用 git worktree 平行副本同時改同一專案，零衝突。
名詞解釋
- Claude Code
- Anthropic 推出的 AI 寫程式工具，裝在自己電腦的終端機裡，能直接讀寫你的檔案、跑指令，把你用中文描述的需求做成真的網站或工具。
- subagent（子代理）
- AI 派出去的分身：主對話把一件事外包給另一個獨立的 AI 執行，做完只回報結果，不佔用主對話的記憶空間。
- context（上下文視窗）
- AI 一次能「記在腦中」的內容上限，包含你說的話、它讀的檔案跟對話紀錄。塞滿了就會忘掉前面的事，這就是長對話後 AI 開始恍神的原因。
- git worktree（平行工作目錄）
- git 的功能：同一個專案同時開好幾份獨立的工作目錄，各改各的、互不干擾，最後再合併。想讓多個 AI 分身同時動同一個專案，靠它就不會互相踩到。
如果內容對你有用就太好了
隨喜斗內
相關文章
▸ 常見問題
什麼工作該派給 AI 分身，什麼該在主對話做？
判準一句話：這個動作過程中冒出來的東西，會不會佔掉主對話的腦容量？要讀 3 個以上檔案的調查、掃專案找東西、查資料研究、批次改檔，這些派分身，只收結論。讀一兩個已知檔案、單檔小修改、跟你確認事情，這些主對話自己做，派工反而多繞一圈。
AI 模型等級怎麼選才不浪費錢？
機械活(模式已知的批次套用、格式轉換)用快的便宜的;預設情境(實作、研究、初審)用主力等級;卡關(重試兩次仍失敗、高風險判斷)才上最貴的。關鍵心態：省錢不是重點，重跑一次的成本比一開始就用對模型高得多。猶豫時選上一級，便宜模型失敗一次就直接升級，不給第二次機會。
派出去的工作怎麼驗收？
鐵律是「驗收不能自己來」：產出的那個分身自己說做完了不算數，要派一個沒參與過程的新分身，給它驗收條件原文，叫它讀成品逐條對照回報缺漏。程式類以執行結果為準，跑測試、實際觸發一次，「看起來對」不是驗證。
AI 失敗了要重試幾次？
同一個任務、同一個方法，最多兩次(首次加重試一次)。第二次還失敗就換方法、升一級模型，或停下來問人，原樣試第三次幾乎都是浪費。升級時把失敗紀錄(試了什麼、錯在哪)整理給更強的模型，它就不用重走一次冤枉路;這份紀錄常常比重試本身值錢。
看完這篇之前先確認:
- 分身(subagent)用過幾次，開始覺得「越用越亂」的人
- 想知道什麼事派便宜模型、什麼事值得用貴的人
- 常常覺得 AI 做出來的東西不能用、要重來的人
- 還沒用過分身 (先看 Subagent 那篇，這篇是它的續集)
- 只做單檔小修改的輕度使用 (主對話自己做就好)
- 想找「全自動不用管」的方案 (派工制度的前提是你要管)