Day 18｜多模型派工：為什麼選型表要寫死在檔案裡

Day 17 最後留下一題：哪個位置該放哪個模型、憑什麼選。我手上的答案是一張選型表：每個位置用哪個模型、開多大的推理強度。這份選型表 Day 5 就寫出來了，一直躺在派工規則裡。可是回頭查派工稽核紀錄，2026-09-14 到 09-18 這五天，三種執行者共派出 421 筆，有 220 筆的推理強度與現行條文不符；2026-09-20 到 09-27，273 筆裡是 0 筆。中間發生了兩件事：條文把 Opus 執行者的推理強度從 high 改成 medium，以及檔位與路由從「寫給主控看的條文」，變成「送出前會被直接拒絕的檢查」。這篇要說的是為什麼第二件事不能省。

事故：條文寫了，派工照樣漂

先把口徑說清楚。那 220 筆在當時的條文下是允許的，不算當時違規：Day 5 的定義檔就把 Opus 執行者綁在 high，這 220 筆跑的是預設值。我是拿現在的尺去量過去的派工，看到的不是主控每次亂開檔位，而是一個沒人回頭檢查的預設，五天裡原封不動地被派了 220 次。

真正臨場的判斷在選角。派工那一刻，主控要決定派誰，每一次都是一個很小的判斷：「這題好像有點難，派 Opus 執行者。」單獨看每一次都合理，加起來就是 Opus 執行者與 Sonnet 執行者各占一半（全期 350 筆對 339 筆）；選了 Opus 執行者，就一併拿到它綁死的 high。選型表寫得再清楚，它也只是被讀進 context 的一段文字，跟其他幾百行指示一起競爭注意力。

而且這種漂移本身不會被察覺。每一筆派工事後都講得出理由，沒有哪一次看起來明顯是錯的；要等到把幾百筆攤開來數，才看得出一半都停在最貴那一檔。

第二幕其實早就留下一個更難堪的反例。當時有一支派工政策建議的 hook，程式寫好了、檔案也在，就是沒有註冊。結果稽核紀錄 564 筆裡，只有 1 筆的建議欄位有值。條文有、程式有，只差接上那一步，效果就是零。

真正讓我確定「寫在規則裡不算數」的，是檢查上線那幾天的紀錄。外包路由那道檢查在 2026-09-17 上線，第一天放行 0 筆、拒絕 5 筆——那一天主控照習慣送出、經過這道檢查的派工，都不符合當下的條文。這不是舊資料用新尺去量，是新條文已經生效、主控卻還照舊派。

推理強度那道檢查也一樣，上線後九天裡有七天仍擋下幾筆。也就是說，主控知道規則、讀過規則，送出時還是會偏。這個事實讓我放棄了「把規則寫得更醒目一點」這條路。

證據：數字從哪幾個點記下來

要說清楚「歸零」是怎麼來的，得先看數字是在哪裡被記下的。

選型表是條文；定義檔把模型與推理強度寫成角色的固定欄位；派工前檢查在工具呼叫送出前比對，放行與拒絕都寫進檢查紀錄，真正送出的派工再由派工稽核紀錄記下實際值。

先看全貌。2026-09-14 到 09-27 這段時間，派工稽核紀錄共有 1301 筆。依角色拆：Opus 執行者 350 筆、Sonnet 執行者 339 筆、外包到隔離環境的執行者 275 筆、中層經理 131 筆、審查員 121 筆、主控自己 67 筆，Haiku 執行者只有 14 筆，另有兩類零星角色合計 4 筆。選型表裡明明有 Haiku 這一格，實際派到它的只占 1.1%。

左圖是 2026-09-14 到 09-27 全部 1301 筆派工依角色的筆數；右圖只看三種執行者，依推理強度檢查上線前、當日、後分三段，標出推理強度與現行條文不符的筆數。

右圖直接回答開頭那個矛盾。上線前 421 筆中 220 筆不符，上線當日 9 筆中 1 筆，上線後 273 筆中 0 筆。

但「稽核紀錄歸零」本身不能證明大家學乖了。另一側的檢查紀錄顯示，2026-09-19 到 09-27，推理強度那道檢查放行 258 筆、拒絕 16 筆，拒絕率 5.8%，拒絕一直持續到最後幾天；不過拒絕原因多數是審查該走審查員那條路，因檔位被擋的只有 2 筆。我的判讀是：歸零主要來自預設改成 medium 並被強制寫回，檢查擋下的檔位錯只有 2 筆，它守的是出口。這個判讀有限制——檢查紀錄和稽核紀錄之間沒有共同的鍵可以逐筆對上，我只能依時間同步來推。

還有兩處要誠實揭露。第一，Haiku 執行者的推理強度在紀錄裡恆為空值，上線前 12 筆、上線後 2 筆都不計入「不符」，它算不算檢查沒涵蓋到的縫，我還沒下結論。第二，審查員 121 筆全部跑 high，它不在這個口徑內。

另一個不利的數字：同一時段有 587 筆派工沒有落任務類別，占 1301 筆的 45.1%。選型表的分類，有將近一半沒被記下來。

解法：三段式，最後一段必須會拒絕

修法拆成三段，前兩段是整理，第三段才是關鍵。三段各管一件事：條文說明理由，欄位決定預設，檢查守住出口。

第一段是選型表本身，仍然是條文，寫在派工規則裡，Day 5 講過它怎麼長出來的，這裡不重講。

第二段是定義檔，Day 5 就有了：每一種執行者都有自己的角色定義，模型與推理強度直接寫成那個角色的固定欄位，主控派工時選的是角色，沒有另一格讓它臨場填。這一段的問題不是沒寫，而是寫了也不算數：欄位本身可以被改掉，220 筆預設 high 也正是它給的。這次補的是每次啟動把欄位強制寫回條文的值（上線當日就寫回了 4 筆），讓定義檔只剩一個版本。

第三段是派工前檢查。工具呼叫送出之前，由 hook 比對這次派工：推理強度對不對得上角色、外包與審查類的工作有沒有走對路由、先前失敗過的派工是不是又原樣送出。對不上就直接拒絕，派工不會發生，主控只能改了再送。放行與拒絕各記一行。這幾支檢查本身的檔案，任何改寫都一律強制詢問，主控不能順手把門拆掉。

為什麼一定要拒絕，而不是提醒？第二幕那支沒接上的建議 hook 示範的是沒接上等於零；上線那幾天則示範了接上也不夠：規則生效了，主控照樣偏，只有拒絕擋得住。條文決定該怎麼做，機械層決定這條文算不算數。

新問題：規則會執行了，錢有沒有變少

到這裡，選型表終於從「我記得要這樣派」變成「不這樣派就送不出去」。但這一層只管住檔位與路由，管不到分類——那 45.1% 沒落類別的派工，照樣送了出去。

更大的缺口在錢。這段時間派工的等價成本紀錄值合計 4,443.92 美元（按官方 API 定價換算，訂閱制實際不按此計費）。這個數字出自派工稽核紀錄，每一筆的金額和 token 是從同一份執行者紀錄一起算出來的，Day 15 查到的那筆口徑落差不在這裡；但在本機跑的執行者，花費已經算進逐輪用量紀錄的紀錄值，外包那部分是否重疊我沒核對，兩邊都不能相加。帳對得上，也不等於錢變少了：推理強度鎖在 medium，也只是讓貴的模型少開一檔；Haiku 執行者全期 14 筆，最便宜的那一格幾乎沒進執行層。規則能被機械執行了，執行層的錢到底有沒有真的變便宜，得先讓便宜的模型真的接到工作才答得出來。

明日預告：Day 19｜把便宜模型塞進執行層：兩段式與外包