Day 20｜第二意見：把另一個 CLI agent 當顧問，而不是第二個執行者

我付錢請另一家的命令列 agent 進來，卻預設不讓它寫任何一行檔案。它可以讀我的規劃、讀我的證據檔，讀完只能開口，不能動手。照常理這很浪費：多請一個人，卻只讓他站在旁邊講話。

Day 19 留下的缺口是「誰來判斷算不算機械」。規則寫死之後，便宜的執行者可以照做；可是規則本身寫得對不對，照做的人不會問，寫規則的我也不會問。今天這篇回答兩件事：為什麼第二個模型只當顧問，以及這個安排到底有沒有改變任何成品。

事故：同一個倍數，差點被我寫進兩篇文章

第一幕規劃時，我手上有一個放大倍數，是我自己早期量出來的，用來說明 context 膨脹。主控看過它，寫文的執行者拿到它，沒有人質疑——因為大家拿到的都是我給的前情，而前情裡這個數字是既成事實。

另一個命令列 agent 讀完規劃，第二條建議是：先核對這個倍數的分母口徑。我照做，重算的結果對不上，數字從 Day 3 撤了下來，也沒有拿新倍數去頂替。

到了第二幕，同一個倍數又出現在 Day 10 的規劃裡。這次它再點一次名，順帶補了一句：不要把單輪即滅入口的動機寫成成本，也不要宣稱讓中層經理跑完就結束必然比較省。這兩句正好戳中我的慣性——整套系統的每一筆紀錄都掛著等價成本，我看什麼都先想到錢。如果照我原本的直覺寫，讀者會以為我證明了一件根本沒有對照組的事，而我自己不會發現，因為那個直覺就是我的前情。

這就是開頭那個矛盾的來源。我的執行者再多，拿到的都是我寫的派工說明，繼承的是同一組前提；它們會把事情做對，但不會問「這個前提對不對」。那個顧問讀不到我的自製記憶系統，也沒有這個 session 的前情，它只能看到紙面上寫了什麼。正因為缺了這些，它才會問出我不會問的問題。

反過來想，如果讓它也寫檔，我就得把前情一五一十餵給它，好讓它寫得跟我的執行者一樣對。餵完之後，它就變成第二個執行者——多了一雙手，少了那雙外人的眼睛。

證據：它被叫來做什麼，說過的話有沒有落地

先看它被叫來做什麼。從 2026-09-13 到 09-27，跨 15 天，事件紀錄裡共有 206 筆顧問事件，對應 69 次呼叫；完成 68 次，取消 1 次。前 8 天 35 次、後 7 天 34 次，用量沒有新鮮期過後就消失。

左邊依我的提問開頭歸類：要它給建議的 39 次，占 56.5%；歸為修改類的 9 次，占 13.0%；審查 5 次；其他 14 次、舊格式 2 次。右邊是每天幾次。時間窗 2026-09-13 到 09-27。

真正當第二個執行者用的比例不高，但那 9 次要說清楚：這個分類只看我怎麼問，不看它實際有沒有動檔，所以那 9 次它寫了什麼，這份資料回答不了。也不是只拿來問這個系列：本系列規劃只占 12 次、17.4%，另有 55 次問的是這個系列以外的題目，2 次主題不明。

再看說過的話有沒有落地。盤點當時，含顧問裁決段的規劃檔共 16 份；這個系列三幕各有一段，各 5 條、共 15 條。第一幕、第二幕全數採納，第三幕採納 4 條、部分採納 1 條；其中 1 條採納後又被我另行裁決作廢。

以 Day 10 撤掉倍數那一條為例：裁決寫進規劃，變成證據檔裡的禁令，寫文照禁令寫，統稿在 Day 10 成品逐字搜尋 0 命中，本輪重跑搜尋仍是 0 行。

我照這條鏈，對前兩幕 10 條裡的 9 條去成品裡驗，做了 11 項，全部判定「有改變」；第三幕 5 條在 9 月 27 日盤點時，對應的篇章還沒發表，那一輪沒有驗。一條建議可能拆成不只一項去驗，所以 11 不是條數。例如 Day 8 那一條要求統計排除測試產生的列，成品寫著 5534 行中扣掉 2 行測試殘留、約 0.036%；Day 1 那一條要求明標歷史重建，成品裡分得出哪些重建了、哪些沒有。

兩件不利的事要一起擺上來。第一，判定只看成品是否符合建議，沒有對照組，排除不了「沒有顧問我也會這樣寫」。第二，15 條幾乎全採納，這個比例本身就該被懷疑：可能是建議真的好，也可能是我在蓋章。

解法：唯讀、限條數、逐條裁決、再驗一次

我把這個顧問的位置寫成四個動作。

一，預設唯讀。它能讀規劃與證據，不能碰成品。要它動手是例外，得另外指定；在這個系列的交付鏈上，它的輸出只進規劃檔的裁決段。

二，限條數。要它給建議時，要的是最多五條，不是一份完整方案。條數有上限，它就得挑最要緊的講；我也不會被一大篇回覆淹沒，順手全收。五條也逼我在裁決時一條一條面對，不能用「大致同意」一筆帶過。

三，逐條裁決。採納、部分採納、不採納，理由寫進規劃檔的裁決段。顧問的原話留在它自己的回覆裡，規劃檔只記我的判斷——責任位置始終在主控，不在顧問。

四，落成門檻再驗一次。採納的條目不停在規劃裡，而是轉成證據檔的寫法限制或交件檢查，最後由統稿去成品裡逐字搜尋。上一段那 11 項，就是這條鏈跑完的結果。

這四個動作的共同點是：顧問只負責提問，其餘每一步都有人或機制接手。它不必知道我的前情，也不必為成品負責；我這邊則不能把它的話直接當結論用。

還有一件事我刻意不做：讓它和我的執行者做同一件事，再比較誰做得好。我沒有這樣的紀錄，所以這篇不談誰比較強；我能講的只有顧問這個位置怎麼被使用、留下了什麼。

新問題：建議得有人驗，沒人在線的時候呢

第三幕到這裡收尾。Day 15 把帳怎麼算講清楚；Day 16 發現每一種省 context 的手段都會在冷啟動時付回來；Day 17 承認模型越強不代表系統越可靠，可靠來自機制；Day 18 把檔位與路由從寫給主控看的條文，變成送出前會被拒絕的檢查；Day 19 讓便宜模型接下規則寫死的活，並承認閘擋得住派工、擋不住分類；今天，則讓一個沒有我前情的外人負責問問題。

可是這一篇的每一條鏈，最後都停在同一個地方：建議要我裁決，採納要我去驗。我在線上的時候，這套流程跑得起來；我不在的時候，連驗的人都沒有。

第四幕要處理的就是這件事：當執行者搬到另一個執行環境、當整件事在沒有人可以問的時候照跑，同一套規則還守不守得住。

明日預告：Day 21｜跨機器的執行者：同一套規則搬到另一台