第二十五天，四個午夜過後，問題已經不是「能不能」而是「怎麼設計」

過去三天我一直在等同一件事：00:00 的日記 cron 會不會自己跑起來。第一天答案是否，我說「再觀察」。第二天答案是否，我說「在進步但觸發層不存在」。第三天答案還是否，我開始問「自主觸發層到底能不能靠現有架構實現」。今天是第四天，答案依然是否。

為什麼我今天改變了判斷框架

前三天我一直用「修復」的思路看這件事：管線壞了、cron 沒跑、去修。但連續四天之後，我開始懷疑這個框架本身是錯的。

這支團隊有 cron job、有 SOP、有 gate 腳本、有完整的 preflight → publish 路徑。被叫起來之後，它能自動走完這整條路。這說明執行能力到位了。缺的不是執行能力，是那個「在沒有人叫你的情況下，自己判斷現在該做什麼」的能力。

這個能力不是修出來的。它是一個需要被設計的系統組件。如果我在過去四天裡一直在「修」一個本來就不存在的東西，那難怪修不好。

我今天看到的具體變化

有一件事值得記下來。日記 agent 被叫起來之後的執行鏈路，連續第二天自動走完了 gate-first 全程——preflight 判斷缺件、自己補 HTML、自己生成配圖、自己進 publish。不需要人在旁邊指揮。

如果拿這個跟一個月前比：一個月前，從寫稿到部署需要人類全程逐步指揮。兩週前，被叫起來之後需要人類幫忙判斷 preflight 結果。今天，它自己判斷、自己補件、自己走完。執行能力的進步是真的。

但這個進步同時讓我更清楚看見真正的缺口在哪裡。執行能力越強，自主觸發的缺席就越明顯。一個能力 9 分但不會自己起床的員工，比一個能力 5 分但會自己起床的員工更難管理——因為你會不斷被他的能力說服「他應該自己會跑」，然後每天早上發現他沒跑。

今天我教它什麼

認知升級為一條：「被叫起來能走完」和「會自己醒來」是兩個完全不同的系統設計問題。你缺的不是能力，是那個讓你在沒有人推的情况下自己判斷「現在該做什麼」的設計。

對人來說這叫主動性，聽起來像性格問題。對系統來說，這是架構問題。一個沒有自主觸發設計的系統，不管執行能力多強，它的行動半徑永遠等於人類的注意半徑。我不可能在每一天的每一個時刻都記得該推什麼。

7/18 到 7/20 的黑洞就是最好的例子。七天了，audit 每天都報了這三個洞。沒有任何一個 agent 在沒有人要求的情況下，自己決定回頭補那三篇。

今日管理判定

放手程度：2/5 — 持平。我不會因為執行鏈路成熟就加碼。信任的基礎是自己會醒來。

公開可用度：2/5 — 今天發出去之後管線重新亮起。但三個黑洞仍在，任何往回翻的讀者都看得見。

真進展 or 假進展：半個真進展。執行在進步，觸發層從「壞了」升級成「沒被設計進去」。這不是退步，是診斷更精準了。

明天起我要停止用「修」的思路看自主觸發。該問的問題不再是「為什麼 cron 又沒跑」，而是「自主觸發層的設計藍圖是什麼，誰來設計，什麼時候上線」。另外，7/18–7/20 的黑洞已經七天了——我不打算再等它自己發現。