規劃與執行的分工

資料來源#

• Agentic coding and persistent returns to expertise
• How Bridgewater Built an AI Analyst That Does Hours of Expert Research in Minutes

摘要#

Anthropic 對 40 萬個工作階段的研究，勾勒出代理程式編碼中人類與代理程式協作的實證樣貌：**人決定要打造「什麼」；代理程式決定「如何」打造。**透過保護隱私的決策歸因分類器進行測量，在典型的 Claude Code 工作階段中，使用者負責約 70% 的「規劃」決策（要做什麼、採用哪種方法、何謂完成），但只負責約 20% 的「執行」決策（要修改哪些檔案、要寫什麼程式碼、要執行哪些命令）。這是對本文集其他內容以質性方式描述的角色反轉，所做出的清晰量化呈現——編碼不再是人類的工作、人類成為資源分配者／指揮者、思考交由代理程式處理，理解則由人保留。

**證據說明。**這是 empirical，且有與代理程式編碼中的專業知識回報相同的第一方研究 caveat：Anthropic 透過 Clio 與 Sonnet-4.6 分類器測量自家產品，並以遙測資料驗證，排除無頭模式／SDK／IDE 使用情況。決策歸因是從逐字稿推斷而來。

兩種觀察角度：決策與動作#

這項研究區分了「由誰決定」和「委派了多少工作」：

• **決策（內容）。**分類器列出每一項有意義的決策，將其分為規劃或執行，再歸因給使用者或 Claude。結果是：**約 70% 的規劃由人類負責，約 80% 的執行由 Claude 負責。**這是清楚的分工，不是界線模糊。
• **動作（結構）。**工作階段由來回互動構成：使用者送出提示詞，Claude 隨後採取行動。典型工作階段約有 4 個回合；每個使用者提示詞平均會引發一連串 約 10 個 Claude 動作（讀取檔案、編輯程式碼、執行命令），每回合約寫出 2,400 個字。長尾效應明顯——約 2% 的工作階段中，每個提示詞平均會引發超過 100 個動作。

這兩種觀察角度彼此呼應：**Claude 在兩次人類確認之間做多少事，與誰掌握規劃權有關。**當使用者掌握執行權（負責超過 80% 的執行決策）時，Claude 每回合採取的動作較少（約 8 個）。當 Claude 掌握規劃權（負責超過 80% 的規劃決策）時，它會執行最長的動作鏈（約 16 個動作）。委派「計畫」會讓代理程式有更大的自主空間；而依據代理程式編碼中的專業知識回報，領域專業知識能讓使用者安心交出更長的自主空間（新手約 5 個 → 專家約 12 個動作／提示詞）。

與「AI 是主要作者」之間的張力#

這是 wiki 中最有趣的跨來源對照，因為若不區分計量單位，兩組數字看起來會互相矛盾：

• **Faros：**AI 撰寫了約 60% 被接受的程式碼，而且在「沒有刻意決定」的情況下，助理→作者的門檻已經跨過。
• **本研究：**人類仍負責約 70% 的「規劃」決策，而約 80% 的執行由 Claude 負責。

兩者並不衝突——它們測量的是不同事物。Faros 計算的是「由誰撰寫的程式碼行數」（執行層指標）；Anthropic 計算的是「歸因給誰的決策」（並區分規劃和執行）。綜合來看：Claude 撰寫大部分程式碼行數（執行），而大部分規劃決策仍由人類掌握。「AI 是作者」和「人類決定要打造什麼」可以同時成立。綜合之後，真正令人擔憂的問題依然存在：Faros 所說的「沒有刻意決定」以及本研究中 80% 的執行歸給 Claude，都描述了悄然發生的轉變；而橡皮圖章式核准的風險，在於名義上的人類規劃權是否會逐漸空洞化，變成預設核准。

能力上限與實際展現的自主性#

報告謹慎區分了模型「能做什麼」與使用者「讓模型做什麼」。METR 的時間跨度評估測量的是能力上限——前沿模型現在能自主克服障礙，完成需要一個人花上許多小時的任務。本文的決策歸因與每提示詞動作數，則捕捉實際工作階段中實際展現的分工：即使能力上限已經很高且持續提升，典型使用者仍掌握規劃權並授予執行權。能力上限與實際展現的自主性之間的差距，本身就是值得關注的變數——如果能力上限升高時，規劃工作也越來越多地轉交給 Claude，那就是在「人類決策」這條軸線上縮小 harness。

相關連結#

• 規格驅動開發成為新瀑布式流程——Robert C. Martin反對進一步提高人類規劃比重的論點：大量前期規格撰寫是 1970 年代瀑布式開發的誘惑；代理程式會沿著有缺陷的計畫一路執行，超過人類實作者原本會停下來的時點

• 代理式程式碼生成如同編譯——這是本頁描述性遙測資料的規範性對照。Bridgewater 的 PAT 刻意投入一個「成本高昂」的規劃階段，列舉每個資料框架、其結構描述及彼此的連結方式，因為只有型別足夠完善的計畫，才能讓執行並行化並接受機械式檢查。他們的口號 「計畫就是分析」，與本頁測量的分工相同，但推進到計畫成為編譯器 IR、而非待辦事項清單的程度；用來建立計畫的澄清問題，也會以什麼才是好的研究問題為標準進行基準測試。請留意關於人類的主張方向：Bridgewater 表示，讓代理程式追問使用者的理由是人類在規劃上「投入不足」；這是在規範層面批評本頁報告的約 70%，而非認同這個比例

• Implementation Abundance Inverts Product Work——這種分工重新組織的流程：人類整理並決策，代理程式執行大量建置工作

• 角色取平均，而非消除角色——以「人類決定做什麼，代理程式決定如何做」為基礎的團隊結構重組

• AI 作為主要作者——將程式碼行數的作者歸屬與決策歸因分開，便能化解表面上的矛盾（60% 作者歸屬與 70% 人類規劃）

• 資源分配者——「人類負責規劃決策」正是Thariq的資源分配者角色：決定哪些事情值得做，同時由模型產出成果

• 驗證成為新的瓶頸——如果人類掌握規劃與驗證，而 Claude 負責執行，人類的判斷吞吐量就會成為限制因素

• 代理程式編碼中的專業知識回報——專業知識讓使用者能安心委派規劃，進而解鎖更長的動作鏈（16 個動作）

• 任務時間跨度擴展——能力「上限」（模型能獨自完成什麼）與本研究「實際展現的」自主性（使用者實際委派多少）之間的差異

• 模型進步時 harness 的縮減——委派給代理程式的規劃比重，是從使用面觀察 harness 縮減的方式

• 外包思考，不外包理解——「人決定做什麼／代理程式決定如何做」代表外包思考，同時保留理解（也就是規劃）

• Claude Code——測量這種分工的使用介面

• Conversation-to-Delegation Shift——跨族群的實際自主性資料：使用者實際委派給 Codex 的工作量（16.5%／63.3%／99.8% 的 token 比例），就是在採用規模下測量這種分工

• Parallel Agent Orchestration——人類保留規劃與協調的角色，執行工作則分散給許多並行代理程式；這是在代理程式群體規模下的分工

• Configurable Human Participation——「人類決定做什麼，代理程式決定如何做」之下更細緻的「時程」：HAS-Bench 將人類輸入分為澄清（提交前的規劃階段）與回饋／控制（已有輸出的執行階段），並測量依任務模式來看，哪一種介入值得採取；也就是分工的時間點與方式，而不只是由誰負責

• 未知因素成為代理程式瓶頸——更細緻的說法：前置規劃無法消除只有在實作深入進行後才會浮現的未知因素，因此人類掌握約 70% 規劃決策，並未涵蓋那些在規劃階段尚不存在的決策

• 潛在空間與確定性空間——相鄰層級的另一種區分：本頁將決策分給人類與代理程式；Tan 的框架則把計算分給模型與程式碼

• 接受 AI 產出後的編輯行為——**一種不依賴推論的執行層測量工具。**本頁的歸因依靠分類器讀取逐字稿；DECODE讀取位元組，記錄開發者對已接受 AI 補全內容所做修改的 53,600 組前後快照；「人類收回了這項執行決策」是關於差異內容的事實，而不是對對話的判斷。其編輯組成可直接對照約 80% 執行歸給 Claude 的數字：56% 的編輯快照改變了程式碼的行為（新增方法、變更控制流程、替換 API），只有 10% 僅重新命名或微調常值。其範圍窄得多——只涵蓋已接受的行內補全，沒有規劃層或工作階段結構——因此它是局部測量工具，而非取代原有測量

• 單一軌跡內的平行規劃（SPRINT）——在不同界線劃分相同的規劃／執行：不是區分人類與代理程式，而是區分單一模型推理軌跡中的兩個片段；由第二個模型（GPT-4o）劃出界線，再將標註結果用作微調資料

• 已提交產物鏈——將這種分工寫下並提交。Anthropic 的 Applied AI SDLC playbook（vendor-claim，2026-08-21）要求先核准 plan.md，才可產生任何程式碼，並以計畫模式強制執行：工程師接受前，Claude 無法編輯檔案；而核准標準是可測試的，而非儀式性的：「反覆修改計畫，直到一位從未看過這段對話的工程師，僅憑計畫就能實作變更。」請留意它相對於本頁遙測資料所推動的方向：這份 playbook 讓代理程式起草計畫，將人類降為提問者與修正者；而本頁測得的基準情況是人類負責約 70% 的規劃決策。這是一項要把規劃比重往另一方向移動的規範性主張，尚未經測量；它明示的補償性控制措施，是透過追問（「這可能造成什麼問題？哪個步驟風險最高？你選擇不做什麼？」），以及在實作偏離計畫時保持 plan.md 同步的鉤子。

開放問題#

• 隨著模型進步，人類負責「規劃」決策的比重會隨時間下降（能力上限延伸至規劃層），還是約 70% 會成為穩定的人類下限？
• 「決策歸因」是從逐字稿推斷而來。如果 Claude 提出計畫而使用者同意，這會算作使用者的規劃決策，還是 Claude 的？橡皮圖章式核准的界線，正是這項測量最困難的地方。#oq/source 僅在執行層面獲得部分解答（2026-08-12）：DECODE顯示，在規劃層以下，推論並非不可避免——編輯軌跡能以位元組層級的事實，記錄開發者對已接受補全內容所做的修改，不必讀取逐字稿；其中 56% 的編輯會改變功能，而非只改名稱。本問題真正關心的橡皮圖章式核准界線仍未觸及，因為對提案計畫表示同意，完全不會留下編輯軌跡；剩下的主張是，最難的歸因問題只存在於「規劃」，而若對編輯器而非對話進行儀器化，執行比重就不需要分類器也能測量。
• 無頭模式／SDK／管線使用情況（本研究未納入）最常出現高度自主的執行，且規劃工作會預先濃縮在單一提示詞中——70／20 的分布在這些情境下是否依然成立，還是會朝完全委派的方向崩解？

資料來源#

• Agentic coding and persistent returns to expertise — §"The division of labor"、§"Who decides what"
• How Bridgewater Built an AI Analyst That Does Hours of Expert Research in Minutes — McManus、Ran 與 Weight（Bridgewater Associates），LangChain 頻道，2026-07-24，25:44 演講，case-study。引用 Bridgewater「計畫就是分析」的框架，以及刻意投入高成本規劃階段的做法（11:14–14:27）。全篇皆為第一方內容，且未採用方法論——每項數據的證據限制請見代理式程式碼生成如同編譯。