三臂受控實驗｜現況報告
派工到底省了什麼——三臂實驗報告（n=4 定版）
Claude 新鮮 token，以獨力為 1.00
完成度 12/12 筆（A 4／B 4／C 4）
左右滑動或按方向鍵換頁
一、這個實驗在問什麼（白話版）
派工兵這件事，直覺上是「找人幫忙比較省」。實際上不一定。
主 session 自己動手做完一件事，吃掉的是一份 Claude 額度。改成寫一張施工卡、 把工作發包給子代理，額度會變成幾份：施工卡要寫、工兵的回報要讀、 成果要驗收，而工兵自己也在燒同一本帳。所以「發包」可能比「自己做」還貴。
巴哲 2026-08-20 已經量過這件事，結論是委派吃掉 5.268 倍 token、2.368 倍成本， 而且沒有減輕主模型的脈絡負擔（1.200 倍），要任務放大到 1.50 倍以上才划算。
但他的實驗有一個我們用得上、他卻量不到的缺口：他的工兵全是 Claude 自家的子代理， 帳記在同一本上。本環境 2026-08-19 起的預設是派 mini-agent（MiniMax M3）， 那是另一本帳、另一份月費。他的 5.268 倍講的是「總 token」， 對我們而言大半根本不落在 Claude 額度上。
所以本實驗把同一份契約跑三種做法：
| 臂 | 做法 | 白話 |
|---|---|---|
| A | 主 session 獨力做完 | 自己做 |
| B | 主 session 出施工卡，發包給 Claude 自家子代理 | 找同事幫忙，錢從同一個口袋出 |
| C | 主 session 出施工卡，發包給 MiniMax M3 工兵 | 找外包，錢從另一個口袋出 |
要回答的一句話：把工作移到別本帳上，Claude 這邊真的省下來了嗎，代價是什麼。
⚠️ 兩邊都是月費吃到飽（MiniMax 那本 NT$1,500／月），所以錢不是決策變數。 真正稀缺的是那個六條 LINE 線共用的 Claude 額度視窗——報告裡的美金是照 API 價目表換算的名目價，不是實付。
二、兩種跑法：Windows 原版與 macOS 港版
同一份契約有兩個版本，因為原版綁死 Windows。
| 巴哲原版（win） | 我們的港版（mac） | |
|---|---|---|
| 技術棧 | C# WinForms on .NET 8（net8.0-windows） | Python 3 標準庫，GUI 用 tkinter |
| 建置檢查 | dotnet build -c Release | python3 -m compileall -q . |
| 命令列進入點 | BatchRenameStudio.exe | python3 batch_rename_studio.py |
| 契約規則 1–16 | 原文 | 逐字不動 |
輸入 rules.json／輸出 plan.json | 原格式 | 逐字不動 |
| 封存測試集與評分器 | holdout/score.py | score_lifeos.py，只改兩處平台綁定，G1／G2／G3 判定逐字未動 |
| 臂數 | 兩臂（C1 獨力／C3 委派） | 三臂（多一個 MiniMax 外包臂） |
| 每臂筆數 | n=4 | n=4（已跑滿，2026-08-22 00:30 收工） |
改動只有四處，全在外殼：GUI 框架、建置指令、進入點、regex 引擎語法轉換。 之所以損失比看起來小，是因為封存測試打的是工具吐出來的 plan.json， 判定對象是資料不是語言——真正綁死 Windows 的只有殼。
代價要講清楚：換棧之後工作量不完全等價，我們的 A／B 與他的 C1／C3 關係由「可直接對照」降為「同量級參考」。但本實驗的主問題（C 相對 A、B 的位置） 完全落在我們自己三臂之間，不受這件事影響。
還有兩個平台差異值得記：
- 脈絡視窗實測 1,000,000（
modelUsage.contextWindow），不是 200,000。 「怕爆脈絡才要委派」這個直覺在這個環境不成立——委派的門檻是分工經濟，不是容量。 - 移植時抓到一個評分器缺口：G3 原本檢查有沒有
.csproj檔，Python 專案永遠不可能滿足， 每一臂會固定少一分。已改成等價問法（有沒有原始碼真的在用 tkinter 做 GUI）。 這個改動由技術棧決定，不是看了成績才調的。
三、目前跑到哪
跟巴哲並排：委派比自己做貴幾倍
三組共用同一把尺，所以棒子長度可以跨組直接比。虛線＝獨力 1.00×，落在線左邊的做法比自己做便宜。
他量的是總 token（含子代理），我們量的是與額度直接相關的新鮮 token——同方向但不是同一把尺。
兩邊都照 API 價目表換算的名目價，訂閱制下都不是實付金額。
兩邊問的是同一件事：委派有沒有減輕主模型的脈絡負擔。
並排不等於可直接對照：巴哲跑 C# WinForms、每臂 n=4 已完成；我們跑 Python 港版、三臂各 n=4 已跑滿。並排的倍數是同量級參考，不是同一把尺量出來的。
四張圖：同一份工作，三種做法的代價
每張圖以當下最大值為滿格；切到本頁才長出來，每臂目前的筆數標在名字後面。
跟額度視窗直接相關的那一份——這條實驗真正在省的東西
照 API 價目表換算的名目價，訂閱制下不是實付
從開跑到收工的實際時間，含子代理跑的那一段
主 session 吃到最滿的那一刻——委派本來被期待能壓低它
逐筆結果（每補完一筆就重跑本表）
| run | 臂 | 做法 | Claude 新鮮 token | 名目 US$ | 牆鐘 | 請求數 | 子代理請求 | 主線峰值脈絡 | 契約分 |
|---|---|---|---|---|---|---|---|---|---|
| A-01 | A | 獨力 | 205,129 | 4.79 | 18.1 分 | 36 | 0 | 127,463 | 100% |
| A-02 | A | 獨力 | 207,016 | 5.12 | 18.5 分 | 41 | 0 | 129,781 | 100% |
| A-03 | A | 獨力 | 162,977 | 3.81 | 12.5 分 | 33 | 0 | 104,073 | 100% |
| A-04 | A | 獨力 | 190,330 | 4.58 | 16.8 分 | 37 | 0 | 120,548 | 100% |
| B-01 | B | 自家子代理 | 488,917 | 10.88 | 15.5 分 | 121 | 66 | 122,728 | 100% |
| B-02 | B | 自家子代理 | 1,150,863 | 22.09 | 62.1 分 | 179 | 130 | 146,307 | 100% |
| B-03 | B | 自家子代理 | 1,158,685 | 28.21 | 27.8 分 | 250 | 117 | 202,001 | 100% |
| B-04 | B | 自家子代理 | 1,456,654 | 30.58 | 56.9 分 | 300 | 250 | 150,105 | 100% |
| C-01 | C | MiniMax 工兵 | 224,867 | 7.25 | 62.4 分 | 71 | 0 | 150,603 | 100% |
| C-02 | C | MiniMax 工兵 | 152,806 | 3.59 | 29.4 分 | 36 | 0 | 105,649 | 100% |
| C-03 | C | MiniMax 工兵 | 154,720 | 3.97 | 42.9 分 | 45 | 0 | 109,114 | 100% |
| C-04 | C | MiniMax 工兵 | 275,547 | 8.80 | 72.4 分 | 78 | 0 | 174,854 | 100% |
← 左右滑看其餘欄位（第一欄固定不動）
完成度：12/12 筆。未跑完的格子寫「待跑」不寫 0——空目錄評出來的 0 分會被讀成「這一臂做不出來」，那是假資料。
分臂彙總（以 A 臂為 1.00）
| 臂 | n | Claude 新鮮 token 平均 | 相對 A | 名目 US$ 平均 | 主線峰值脈絡平均 | 契約分 |
|---|---|---|---|---|---|---|
| A／獨力 | 4 | 191,363 | 1.00× | 4.57 | 120,466.25 | 100% |
| B／自家子代理 | 4 | 1,063,779.75 | 5.56× | 22.94 | 155,285.25 | 100% |
| C／MiniMax 工兵 | 4 | 201,985 | 1.06× | 5.90 | 135,055 | 100% |
← 左右滑看其餘欄位（第一欄固定不動）
四、看到的三件事
第一，發包給自家子代理最貴。 B 臂在 Claude 額度上吃掉 5.56 倍， 名目成本 5.02 倍。方向與巴哲的結論一致（他量到 token 5.268 倍、成本 2.368 倍）， 倍率比他更陡——量到的東西不同（他算總 token，我們算與額度直接相關的新鮮 token）， 而且我們的施工卡把工作切給多個子代理，切得愈細、複述契約的次數愈多。 兩邊都指向同一件事：在自家池子裡發包，帳單會膨脹一倍以上。
第二，發包給 MiniMax 幾乎不花 Claude 額度。 C 臂只比獨力多 6%。 那 6% 是施工卡與驗收的成本——主 session 還是得寫卡、讀回報、驗收， 只是工兵那一段的算力搬到別本帳上了。
第三，代價出現在時間與脈絡，不在錢。 C 臂跑了 51.8 分鐘， 是獨力（16.5 分）的 3.14 倍；主線峰值脈絡 135,055， 反而比獨力（120,466）還高——因為工兵的產出要讀回主線驗收。 B 臂也一樣（155,285，1.29 倍）。所以「派工兵可以減輕主線脈絡」這個直覺， 兩種發包方式都不成立，跟巴哲在委派上量到的 1.200 倍是同一個現象。
五、統計檢定（每臂 n=4，精確 Mann-Whitney，雙尾）
n1=n2=4 時分割方式只有 C(8,4)=70 種，所以精確檢定的 p 下限就是 2/70 = 0.0286—— n=4 是「p<0.05 在組合上有可能」的最小值，不是預算選擇。以下窮舉全部 70 種分割算出， 不用常態近似。U=0 或 U=16 代表兩組完全分離（一組的每一筆都比另一組的每一筆極端）。
Claude 新鮮 token（頭條）
| 臂 | 四筆值 | 中位數 |
|---|---|---|
| A／獨力 | 162,977, 190,330, 205,129, 207,016 | 197,730 |
| B／自家子代理 | 488,917, 1,150,863, 1,158,685, 1,456,654 | 1,154,774 |
| C／MiniMax 工兵 | 152,806, 154,720, 224,867, 275,547 | 189,794 |
| 對比 | U | 精確雙尾 p | 中位數比 |
|---|---|---|---|
| A vs B | 0（完全分離） | 0.0286 | 5.840× |
| A vs C | 8 | 1.0000 | 0.960× |
| B vs C | 16（完全分離） | 0.0286 | 0.164× |
牆鐘（秒）
| 臂 | 四筆值 | 中位數 |
|---|---|---|
| A／獨力 | 748, 1,009, 1,089, 1,109 | 1,049 |
| B／自家子代理 | 929, 1,665, 3,417, 3,728 | 2,541 |
| C／MiniMax 工兵 | 1,761, 2,576, 3,747, 4,344 | 3,161 |
| 對比 | U | 精確雙尾 p | 中位數比 |
|---|---|---|---|
| A vs B | 3 | 0.2000 | 2.423× |
| A vs C | 0（完全分離） | 0.0286 | 3.015× |
| B vs C | 4 | 0.3429 | 1.244× |
主線峰值脈絡
| 臂 | 四筆值 | 中位數 |
|---|---|---|
| A／獨力 | 104,073, 120,548, 127,463, 129,781 | 124,006 |
| B／自家子代理 | 122,728, 146,307, 150,105, 202,001 | 148,206 |
| C／MiniMax 工兵 | 105,649, 109,114, 150,603, 174,854 | 129,858 |
| 對比 | U | 精確雙尾 p | 中位數比 |
|---|---|---|---|
| A vs B | 2 | 0.1143 | 1.195× |
| A vs C | 6 | 0.6857 | 1.047× |
| B vs C | 10 | 0.6857 | 0.876× |
名目 US$
| 臂 | 四筆值 | 中位數 |
|---|---|---|
| A／獨力 | 3.81, 4.58, 4.79, 5.12 | 4.68 |
| B／自家子代理 | 10.88, 22.09, 28.21, 30.58 | 25.15 |
| C／MiniMax 工兵 | 3.59, 3.97, 7.25, 8.80 | 5.61 |
| 對比 | U | 精確雙尾 p | 中位數比 |
|---|---|---|---|
| A vs B | 0（完全分離） | 0.0286 | 5.369× |
| A vs C | 7 | 0.8857 | 1.198× |
| B vs C | 16（完全分離） | 0.0286 | 0.223× |
⚠️ 多重比較的誠實邊界：頭條指標做了三組兩兩比較。若把這三組當一個家族做 Holm 校正， 最小的 p 是 0.0286，乘 3 得 0.0857，已經高於 0.05。工單當初沒有預先寫明三臂要怎麼 處理多重比較，這是設計上的缺口。所以本節穩健的部分是完全分離與效果量（B 臂的 Claude 額度是 A 臂的 5.8 倍、C 臂是 B 臂的 0.16 倍），不是 p 值本身。
品質那一欄（契約層自動評分）12 筆全部 100%，三臂在自動評分層分不出高下； GUI 層未評分，需人工 UAT（各臂 MANUAL_UAT.md）。所以「省額度會不會換來品質下降」 這個問題，本實驗在契約層的答案是「沒有」，在 GUI 層還沒有答案。
六、限制（讀這份報告前必須知道）
- 筆數剛好踩在下限。 每臂 n=4 已跑滿，這是精確 Mann-Whitney 讓 p<0.05 成為可能的 最小值（下限 p=2/C(8,4)=0.0286），不是充裕。三組兩兩比較未預先寫明校正方式， Holm 校正後最小 p 是 0.0857（見 §五）。在人工 GUI 篩檢補上、且伊森裁示之前， 不得拿去改
rules/model-dispatch.md的派工預設。 - 品質那一半還沒做。 契約層目前三臂都是滿分，但巴哲研究裡最重要的限制就是 「契約層滿分、GUI 層卻交出連資料夾都載不進去的介面」。每一筆都要人工開一次 GUI 才算數。
- MiniMax 側量不到 token。 CLI 不回報、log 沒有計數器、額度表那兩個
*_time欄位 實測是倒數毫秒不是餘額。C 臂只量得到請求數。 - 美金是名目價，訂閱制下不是實付金額。
- 共用額度池與共用機器是兩回事。三臂跑在服役中的帳號店面上（伊森 2026-08-21 13:22 核可）， 那是額度軸；另外它們與五條 session 同住一台 M2，那是機器資源軸—— 2026-08-21 15:45 全線被砍是後者，與額度無關。
七、下一步
- ~~補完剩下的筆數~~ 12/12 已到齊（2026-08-22 00:30:38 收工）。本報告的表格與 §五 的檢定都是從
results-lifeos/現算的，之後補跑或重跑仍會自己更新。 - 還沒做：人工 GUI 篩檢。 契約層三臂都是滿分，但巴哲研究裡最會出事的就是這一層 （契約滿分、GUI 卻連資料夾都載不進去）。12 筆各開一次 GUI 才算把品質那一半補上。
- 還沒做：多重比較的處置方式要補寫進工單，並決定頭條的主要對比是哪一組—— 這件事本來該在跑之前寫明。
- 這三件齊了、且伊森裁示之後，才動
rules/model-dispatch.md§4／§4.5。