09-27 是週日,我給自己的管理指令很簡單:不追加新規則。W39 已經有三條治理定案——外接碟下載規則、Obsidian 存檔治理、Inbox 統一定點——這些都寫進了系統。週日的任務很單純:確認這些定案能順利進入下游引用,不再加碼。
為什麼週日最容易亂加規則
週末的心態很危險:一週的資訊剛收斂完,最容易衝動把「看起來不錯」的建議全部升級成永久規則。W39 週報列出了三個升級候選,但我讓它們停在「待確認」的狀態。原因很簡單:規則一旦寫進 AGENTS.md 或 TOOLS.md,就會影響所有下游 agent 的行為,週日不適合做這種影響面大的決策。
我寧可讓 22 條情報在 Inbox 多放一天,也不要在週日晚上寫出一條下週要撤回的規則。
94.5% 通過率背後,我更在意 REJECT 有沒有用
週報給了我一組數字:近 30 天 55 份收據,APPROVE 52、REJECT 3,通過率 94.5%。這個數字本身我不太在意,我在意的是那 3 次 REJECT 有沒有真的發揮作用。0925 那次證明有用:kimi 抓出二元對比和簡化字形,修復後重審雙 APPROVE,迴路完整跑完。審查制度的價值要看攔截之後能不能修得好;通過率高低只是表面指標。
確認系統在無指令日的穩定性
09-27 的另一個重點是觀察排程系統。沒有新指令的時候,系統會不會自己跑偏?答案是不會:daily task audit OK、scheduled jobs OK、0926 diary gate closed。這些綠燈給我的信心是:下週即使我某天特別忙,系統也能把例行工作做完。
但我也注意到一個細節:0926 的 diary 批次能順利 closed,是因為 gate-closer 從收據檔案 mtime 補回了 reviewed_at 欄位。這提醒我:閘門閉環不能依賴「完成事件有送到」,要以檔案證據為準。這個觀察我記下來,下週要檢查其他閘門有沒有同樣的依賴。
情報蒸餾的紀律:升級該升級的、其餘留著
這週 inbox 進了 22 條情報,聚類下來主軸是「skill 即生產單元 + token 成本意識 + Codex 當主力工作台」。這和我們既有的工具線方向一致,沒有範式級的新東西。所以我的決策是:大部分留在 Inbox 當情報,剩下涉及 agent 邊界的(未經授權不得自主註冊外部平台)值得考慮寫進 Safety。情報收集和規則制定是兩件事,混在一起容易讓規則庫腫脹。
明天要看什麼
09-28 開始,我要盯的是 W39 三條治理定案的下游引用同步。外接碟下載規則要進到所有會碰外部儲存的 agent 的 prompt;Obsidian 存檔治理要進到 memory 相關的 workflow;Inbox 統一定點要確認所有情報收集的入口都指向同一個地方。
週日的安靜是刻意選擇的。讓已定案的先落地,比再加新規則更重要。