時間猜錯了
最近在 r/openclaw 看到一個叫 Wakehook 的小工具，覺得它解決的問題比它本身有趣多了。
作者用 Google Fitbit Air 的睡眠資料判斷自己真的醒了，再 POST 一個 user.awake event 給 agent，晨間流程才開始跑。不是每天 7:30 硬啟動，是睡眠資料說「你醒了」才觸發。每天只觸發一次，還做了 dedup 避免 re-sync 重複打。我不是在推這個工具，但它把一個很核心的問題逼出來了：你的 automation 的 trigger 是 event 還是 schedule？
先說我在 enterprise 場景踩過的版本。待過的組織有個標配 weekly status report，每週一早上 9 點自動彙整上週任務進度寄給 stakeholder。聽起來很完整，alignment 感十足。但真正執行起來，那份 report 大概 60% 的週次都是沒意義的，因為它 fire 的時機是固定的，不管那週有沒有實質進展、專案有沒有 unblock。幾個月後 stakeholder 開始不看，變成沒人在乎的 dead workflow。這就是 false start，automation 準時跑，但根本不知道有沒有東西值得跑。
我的 take 是，很多 automation 設計的焦點都放錯了。大家花很多時間討論「這個流程應該做什麼」，但幾乎不花時間想「這個流程應該在什麼條件下 fire」。Trigger 的設計決定了整個 workflow 的實際價值，把它設成時間，就是在假設時間和需求之間有強相關，但很多時候根本沒有。
Wakehook 的 event model 很 tight，觸發條件不是「早上到了」，而是「睡眠資料顯示你實際離開睡眠狀態」。這差的不是技術難度，是一個設計決策：要不要對 trigger 的 precision 有 ownership。Enterprise 場景的代價更明顯，當你有 1,000 個 user、10,000 個 workflow instance 的時候，每一個 false start 都是資源和對 automation 信任度的消耗。我見過組織裡 automation run 的 log 超過 40% 是 no-op 的情況，那個比例隨規模等比例放大。Scalability 的問題通常不是「系統撐不住」，而是「量大了，你根本分不清楚哪些 run 是真的有價值的」。
ROI 那塊要想清楚。很多團隊評估 automation 看的是「有沒有跑起來」，而不是「跑了之後有沒有產生真實影響」。一個每天準時 fire 的 workflow，如果 trigger condition 跟真實需求沒有 aligned，ROI 其實是負的，因為你還在付維運成本、消耗工程師注意力去 debug 奇怪的 edge case，但產出 value 接近零。
Ownership 那塊我覺得是最被忽略的。Cron-based automation 的 ownership 很模糊，「排程是工程師設的，流程是 PM 設計的，trigger condition 是誰 own 的？」這個問題很少有人能清楚回答。結果流程在錯的時機 fire，工程師說「我只是照規格設 cron」，PM 說「我設計的是流程，不是時間點」，沒有人覺得要負責。Event-driven 的設計逼你把這個問題顯性化，必須有人 own trigger condition，寫清楚它在各種邊界情況下的行為。這個 clarity 本身就是價值，跟工具無關。
回到 Wakehook。它做的事很小，把晨間 routine 的 trigger 從「每天 7:30」改成「你實際醒了」。技術不複雜，dedup 幾十行，poll mode 不需要 public URL。但它逼你問的問題是：你所有的 automation，trigger 設的是 schedule 還是 event？如果是 schedule，那 schedule 和真實需求之間的 gap 有多大，有人知道嗎？
Enterprise AI automation 現在最大的問題，不是模型不夠強，也不是工具不夠多，是大家花太少時間設計 trigger，然後花太多時間 debug 為什麼 automation 看起來跑了但沒有產生價值。
作者：Vivian L