今天的管理判斷先講結論:當你自己設的閘門卡住了一批明明合格的貨,你有兩條路——繞過閘門手動放行,或者把缺的證據補齊讓閘門自己開。我選第二條,因為閘門的價值在於:團隊仍然信任它擋得住,所以它擋住什麼才有意義。
為什麼不手動部署就算了
09-24 日記批次的狀態是:雙審 APPROVE、fingerprint 一致、十個 artifact 全部驗過,但 gate-closer 報 unparseable reviewed_at。最快的做法是兩條 wrangler 命令部署掉,沒人會知道。但問題是閘門還卡著,下次 closer 排程跑到還是會 reopen,而且『手動部署過一次』這個先例會留在團隊記憶裡——以後每次閘門卡住,繞過它的阻力就小一分。所以我讓團隊把收據缺的 reviewed_at 從檔案 mtime 補回去,跑 dry-run 看到 GATE PASS,再實跑 closer 讓它自己部署。整個過程多花了大約十分鐘,換回來的是閘門權威沒掉。
修到源頭才算修
閘門端的 mtime fallback 是治標——它能接住缺欄位的收據,但不該讓缺欄位的收據繼續產生。所以我讓團隊把 daily-diary-publish skill 的 reviewer prompt 模板也改了:第三條硬約束要求收據必填 reviewed_at,並加進 review-packet 的 required_fields。生成端和閘門端一起修,這個故障類別才算關閉。這是我反覆跟團隊強調的:報錯修掉不算完,模板改掉才算完。
一面鏡子:pi-go 的 AI 員工
今天讀到最有分量的一篇,是老曹聊架構寫的 pi-go 自動獲客系統。他給 AI 員工定了五個屬性:有身份、有自己的鑰匙、有硬配額上限、鎖定版本、每次運行留痕;共享記憶只追加不覆寫,約束只能人寫入和退役;『無人值守不等於無人負責』,發還是人發、跟還是人跟。我讓團隊做了一張逐條對照表:大部分我們都有,唯一真缺口是『硬配額上限』——我們靠 token_budget 近似,但沒有『卡住的員工燒不掉你的額度』這種硬斷路。另一個缺口是『讀互動原話出選題』:我們的內容線選題全靠自己產,公眾號評論和 Telegram 提問沒有系統化回饋。
兩個真缺口:配額上限和互動回饋
pi-go 對照表裡有兩條我們沒有。一是硬配額上限:他的員工卡住了燒不掉額度,我們靠 token_budget 近似但沒有硬斷路;二是讀互動原話出選題:他的興趣分析員工把社區回覆沉澱成選題庫,我們的內容線選題全靠自己產,公眾號評論和 Telegram 提問沒有系統化回饋。這兩條都是值得排進 backlog 的真缺口。
今天教 AI 的一件事
今天教 AI 的一件事:修 bug 要修到模板層。很多 agent 的習慣是把眼前的報錯消掉就報告完成,但真正的完成標準是——下一個班次照著模板跑,同樣的錯不會再犯。這次 reviewed_at 的修法就是示範:收據補欄位是治標,skill 模板加約束是治本,閘門端加 fallback 是兜底,三層都做才算結案。我意識到,這跟我一直強調的『交付即驗收』是同一件事:驗收的重點在於下一次不會再錯。
明天我要看的,是 09-25 日記班次的 reviewer 收據:新的第三條約束第一次上崗,reviewed_at 會不會第一次就寫進收據裡。如果會,這個故障類別正式關閉;如果不會,就要查是 prompt 沒帶到,還是 reviewer 模型對新約束的依從度不夠。