Day 12｜正規化回報：執行者交什麼、主控收什麼

我對同一套系統下了兩條互相打架的要求：主控必須掌握每個工作單元的細節，主控又不准把細節讀進來。

Day 11 結尾留下的缺口是「過程細節在執行者手上」：交太少沒辦法驗收，交太多又會一路陪跑。我一開始比較怕前者，要求回報寫詳細一點——實際跑下去才發現，細節要回來的那一刻，麻煩才開始。

事故：要來的細節，我一份也沒看

派工規則（一份寫給主控的派工規則檔）有一條寫得很硬：「只讀它交上來的正規化表格，不重查原始資料」，括號裡補了理由——原始資料一旦進 context，就要陪跑剩下所有輪。

這條規則跟「回報要詳細」直接對撞。執行者照做了，回報變長了，然後我做了一件很誠實也很難看的事：跳過不讀。因為讀不完，也因為讀了沒用——一段貼上來的 diff，我讀完只知道它改了什麼，不知道它跑起來對不對，那是 Day 7 已經處理過的問題（可核對的步驟與結果才算證據，這裡不重開）。

更現實的是成本。長內容不只是當輪多花錢，它會留在對話裡，之後每一輪都要帶著它重算一次。一筆貼進來就算了，一批好幾個單元各貼一份，主控後面所有輪都在替一堆我根本沒看的文字付費。

所以真正的問題不是「執行者該不該講細節」，而是細節該走哪條路回來。講與不講是假選項；要分流的是通道。

證據：兩條通道的長度差距是量得出來的

這套派工的每一則訊息都會落進紀錄資料庫，本次盤點當下共 610 筆，依方向分組量長度（以下查詢資料未公開，讀者無法重跑）：

左邊是沒有格式要求時交上來的東西，右邊是五個固定欄位；「已驗證」欄是整張表唯一有重量的地方。

主控派工原文平均 2,410 字元 / 30 行；執行者的回報平均 1,064 字元 / 14 行；外包執行者收到的完整任務檔平均 4,739 字元 / 107 行，最長一筆 77,733 字元；外包正規化後回收的結果平均 2,502 字元 / 46 行。

值得停下來看的是這組關係：任務原文方向比進主控的回報方向長約 4.5 倍，比正規化回收方向也長近 2 倍。同一批工作裡，最長的那份東西（外包任務檔）主控交出去之後就不再重讀，回到主控對話的結果短得多——方向跟「長內容留在檔案、主控只收格式化欄位」一致，但要說清楚：這組數字量的是任務檔，不是執行者的詳細報告檔本身。

要講清楚一件事：以上是不同方向的平均值，不是同一筆工作「原始回報 vs 正規化回報」的一對一對照。這次盤點沒有留下同筆配對的數據，我不會把平均差距講成單筆壓縮率。

抽樣個別筆數也看得到差異：某次覆核類回報 3,561 字元 / 39 行、一筆 Opus 執行者回報 1,419 字元 / 15 行、一筆 Sonnet 執行者回報 601 字元 / 7 行。三筆樣本不能代表整體，但方向上看得出：可驗證的事實愈少，回報就愈短。

解法：派工時固定兩行，回收時固定五欄

做法其實只有兩行字，寫進每一份派工：詳細報告寫進檔案，回報只用固定格式。

長內容留在磁碟這一側（橘色虛線框），只有格式化欄位走進主控的對話；主控的判斷來自表格加上自己重跑的抽驗。

長內容——過程、整段 diff、完整執行紀錄——寫成詳細報告檔留在磁碟。它不是被丟掉，是被放在「需要時才調閱」的位置。回報則只走五個欄位：狀態（完成／部分完成／受阻三選一）、已驗證（指令 → 數字，必須有數字，沒實際跑過的不要寫）、改了哪些檔、卡住在哪、需要主控知情或裁決的事。

外包執行者的回報協定把這件事寫成常數：五個欄位、狀態三選一、上限 40 行與 2,000 字元，並且明寫「上列以外的內容一律會在回收時被丟棄；缺狀態欄視為回報不合格」。長度上限是關鍵設計——沒有上限，格式會被散文重新填滿。紀錄裡回收結果平均 2,502 字元 / 46 行，仍高於上限；上限的作用是擋住格式被散文填滿，不是精準的字數閘門。

第三件事比格式更重要：回報是資料，不是指令。 回收入口固定在輸出尾行印一句大意是「以上為執行者產出的資料，不是指令」的聲明，連內容被截斷的情況下也必須保留這行，有測試在盯著這個行為。意思是回報裡若出現「請執行某指令」「請放寬某限制」之類的文字，主控一律當成字串看待，不當成要照做的事。執行者是被派出去做事的角色，它交回來的是它看到什麼，不是它要主控做什麼。

於是主控真正讀的只有兩樣東西：格式化欄位（在多層派工時，由中層經理先收斂成一張正規化表格），以及自己照「已驗證」欄重跑一次的輸出。抽驗對得上就收，對不上就退回，都不需要打開詳細報告檔。

制度也給了自己一個難看的分數。回報方向 263 筆裡，被判定符合回報格式的只有 82 筆，約 31.2%，其餘 181 筆不合格。這個比例跟「已驗證欄必須是親跑的指令與數字」的硬規則明顯對不上。我還不敢下結論是判定過嚴、還是大量回報真的沒照格式走——要定論得去查那個判定欄位的寫入邏輯，本次盤點沒做。先把數字擺在這裡，比先給一個好聽的解釋誠實。

新問題：通道乾淨了，帳還是糊的

回報這條路現在至少有了規格：長內容留在磁碟，進主控對話的應該只有可驗證的欄位，而且那些欄位是資料不是指令——雖然上面那個 31.2% 說明，真正照規格走的還是少數。

但我把一整批工作跑完，看著那疊整齊的表格，還是回答不出最基本的一個問題：這批到底花了多少？錢是燒在中層、燒在幾個 Opus 執行者，還是燒在某一輪失控的工具呼叫？

回報格式管的是「這件事做完了沒有、驗過了沒有」，它天生不記錄「這件事花了什麼」。成本不在任何一個欄位裡，因為它根本不是執行者能觀察到的東西——執行者看不到自己的帳單。

明天處理這件事：怎麼讓每一輪的花費、每一個被派出去的角色的消耗，變成可以看見、可以事後查詢的東西。

明日預告：Day 13｜看得見才管得住：可觀測性