Day 2 留下的是容量與總用量問題，Day 3 拆開了 context 重讀機制。這篇接著處理工作交接：哪些事由主控決定，哪些事交給 worker，結果又怎麼收回來。
分工當時已經開始，但用量拆解讓我注意到主控仍在做不必要的執行工作：主控在做的事，有很大一部分根本不需要主控。
2026-09-01 我做過一次用量拆解，結論寫成一份用量拆解筆記，存在自製記憶系統裡。其中一條是：同一場 session——Day 2 用字母代號稱為 session X 的那一場——主控自己跑了 140 次 Bash，輸出總量只有 111K 字元。
Day 2 引用過這組數字，那時問的是「回報怎麼會這麼長」。這篇問的是另外半邊：那 140 次呼叫，為什麼會發生在主控手上？
可優先檢查的機械工作例如：逐檔跑一次檢查、把一批輸出抓下來看格式、同一條指令換個參數再跑——這類工作規則寫死、沒有判斷空間，也不需要知道前面幾十輪講過什麼，但未必等於那 140 次呼叫的實際內容。
這組數字出自當時的筆記，該場 session 的對話紀錄檔已經不存在，無法重跑驗證。它能說明我當時看到什麼，不能當成可重現的量測。
左：session X 的彙總值——140 次 Bash 呼叫、111K 字元輸出（來源：2026-09-01 用量拆解筆記；原始對話紀錄檔已不存在，無法重跑）。右：同日第二輪用量拆解筆記量到的每輪計費 context 基底，session X 為 48K token／輪、另一場 session Y 為 55.9K token／輪；session Y 沿用與 Day 2 相同的字母代號體系，指另一場不同的 session。左右單位不同、樣本不同，不共軸也不相減。
右半邊那兩根柱子是我當時真正在意的東西。第二輪拆解筆記記的是「每一輪固定要帶的那份底稿」有多大：system prompt、規則檔、工具定義這些東西，不管這一輪要做什麼都得先付一次。兩場 session 量到的是 48K 與 55.9K token／輪。
Day 3 講的是重讀量會隨輪次長大，這裡補上的是這兩場設定下的固定基底。同一筆記錄當時下的判讀是「turn 數是第一槓桿，回報長度是第二槓桿」——這句話是當時的結論，不是對照實驗的結果。
兩件事擺在一起，問題就變成：如果每一輪都有固定入場費，而其中一大類輪次做的是不需要脈絡的事，那這類輪次應該換個位置發生。
而且主控多跑一輪，付掉的不只是那一輪。Day 3 那份逐輪資料裡，重讀量會波動、後段普遍高於前段；在這種形狀下，一輪的內容會留在後面每一輪都要重新帶上的那份底稿裡。這是我當時推導「把機械工作移出主控」的理由，屬於機制推論，不是我拿同一個任務跑過兩次量出來的差額。
我起初把派工理解成把動作搬走，卻沒有同樣清楚地規定回報要包含什麼。結果是動作搬走了，判斷還是全部回到主控，而且回來的是一大段沒有格式的敘述——Day 2 的歷史筆記已記下長回報問題，這裡不重算那份帳，只看交接需要補哪些條件。
我目前有一份寫給主控的派工規則檔，要求三件事：用固定欄位的正規化表格回報、收到後實際核對而不直接採信、發現缺漏時一次列清楚哪一列、哪個欄位、要補什麼；退回上限為一次。這些條文能證明目前如何規定交接，不能證明早期每次派工都曾遵守，也不是節省成本的實測。
依派工規則現行條文畫出的交接路徑：設計預期，未量測。圖中沒有任何前後對照數字，因為我沒有同任務分工前後的實測。
照這張圖，派工時主控交付任務範圍、執行規則與驗收條件；worker 完成後交回「單元／狀態／觸及檔案／已驗證／待裁決」表格，已驗證欄要列出親自跑過的指令與結果。主控據此核對，有缺漏就一次列清楚，讓下一次往返有明確目的。
這樣安排的設計預期，是減少主控親自處理機械步驟，以及無格式回報帶來的閱讀負擔。worker 仍會消耗自己的用量，派工與驗收也仍有成本；我沒有同任務分工前後的對照實測，不能宣稱主控自己跑的機械呼叫已從 140 降到 2，或總成本必然下降。
還有一件分工做不到的事要先說清楚：右邊那兩根柱子代表的固定基底，換誰來跑都要付一次。搬給 worker 的是「帶著整場脈絡去做機械事」的那部分，不是每輪的入場費——worker 自己也有一份自己的入場費。worker 也有自己的固定基底，但大小未必相同。
目前盤點到的分工記錄早於成本筆記，因此這裡用現行條文呈現交接方式，不把後來的規則倒寫成當時已完整實施的流程。
把執行交出去後，主控仍要決定範圍與驗收條件。下一個問題是：誰負責收齊回報、檢查缺漏，又由誰決定退回或放行？
分工回答了誰來做，權責還要回答誰決策、誰執行、誰驗收。這三件事在一個人身上的時候不必分開講，交出去之後就得一個一個指定。多個 worker 各自回報，主控仍得逐份接收與核對。明天看這三個位置如何形成。
iThome鐵人賽
看影片追技術