讓 AI 上夜班：定時任務、彙報口徑和幾條規矩

我用 AI 最大的變化，不是提示詞寫得更好了，而是把它從「白天陪我對話」改成了「我不在的時候也在幹活」。

現在我的工作電腦幾乎不關機，上面跑着十幾個系統計劃任務：凌晨把主分支完整測一遍，清晨檢查依賴和上游接口有沒有變化，發現能修的就開一個隔離分支讓 AI 去修，上班前把一夜的結果彙總成一份簡報。我早上坐下來，第一件事是讀這份簡報，而不是打開對話框問「今天干什麼」。

下面是這套做法的完整樣子。

一、夜班怎麼排

一晚大致分四段：

階段	任務	產出
凌晨	主分支體檢：拉最新代碼，跑完整測試	紅/綠 + 失敗日誌
清晨	依賴安全審計、上游接口契約漂移檢查	只讀掃描，產出「修復候選」
清晨稍晚	自動修復（失敗會再重試一次）	隔離分支 + draft PR，或標記 blocked
上班前	性能指標、線上錯誤、業務指標、倉庫狀態等各類巡檢，最後彙總	一份簡報，餵給早上的工作安排

幾條排班原則：

掃描和修復分開。 檢測任務只讀，只寫一份「修復候選」文件；修復任務只接受完整、新鮮、基於當前主分支的候選。檢測錯了頂多是一份錯的報告，不會順手改壞代碼。

有依賴的任務錯開時間。 修復要等檢測跑完，彙總要等所有巡檢跑完。計劃任務開了「喚醒」和「錯過時間補跑」，同一實例運行中忽略新觸發，按日期去重——重複觸發不會重複幹活。

每個任務都是一次手工活變來的。 比如新頁面上線後，我手動跑過一次搜索引擎提交腳本，然後問了一句「怎麼做到以後發新頁面都自動提交」——於是多了一個任務：讀站點地圖裏的更新時間，只提交上次成功之後變過的頁面，漏跑一天由下一次補上。再比如漂移檢查，最初只能發現、不能修，我問「發現了卻沒有自動開修復 PR？」——於是有了自動修復。

我現在的判據很簡單：同一件事第二次手動做，就問它能不能進夜班。

二、自動修復：給夜班 agent 套籠子

讓 AI 無人值守地改代碼，最怕的不是它修不好，而是它「修好了」——用改測試、跳過用例、放寬門禁的方式讓自己變綠。所以這部分的設計全是圍繞「不信任」展開的：

• 主管不是 AI。 流程由一個普通腳本控制，只有「改代碼」這一步交給命令行 coding agent。什麼時候跑、跑哪些門禁、能不能開 PR，都由確定性代碼決定。
• coder 關在籠子裏。 每個問題一個全新 worktree、真實安裝依賴；coder 斷網、不掛外部工具，生產環境的配置始終不可見；明確禁止改 CI 流程、門禁腳本、測試配置、數據庫結構和構建腳本。
• 門禁比人還嚴。 全量本地 CI、改動文件的覆蓋率下限、端到端測試（空測試、跳過、靠重試掩蓋失敗都算不通過）、在乾淨目錄重新 clone、安裝、再跑一遍。最後由一個獨立的只讀 reviewer 看有沒有新增問題。
• 最多三輪。 代碼—測試—review 的反饋循環最多三輪，修不好就標 blocked 寫進報告，不硬湊。
• 終點是 draft PR。 全部通過才推一個固定命名的分支、開 draft PR。腳本里沒有 merge、沒有自動合併、沒有推主分支的動作。合併按鈕永遠在人手裏。

夜班自己也會壞。第一次真跑，就在主管腳本里抓出四個 bug：Windows 路徑的反斜槓在環境變量裏被吞掉；讀 git status --porcelain 時順手 trim()，把第一行的前導空格削了，文件名少了首字母；網絡守衞把進程之間的本地管道當成外網攔了；隔離配置文件時把示例配置也一起隔離了。另一次體檢停在第一步，原因是構建產物路徑超過 260 字符，git clean 直接報錯。

所以新上的定時任務，頭一週我每天早上都會看它的報告，像帶新人一樣——它不是裝上就能信的。

三、一天三擋：早簡報、午重排、晚日報

夜班的產出要有人消費。我把一天切成三個固定動作，各自做成一個 skill：

• 早上：當場重拉任務表（不讀過期快照），加上過去十幾個小時的提交、昨夜的簡報、昨天的日報，排出今天的 Top 5，再挑出最重要也最難的那一件，先攻它。
• 中途：代碼或任務狀態明顯變了，就按實際完成情況重排剩下的。
• 晚上：按「我的身份」——多台電腦、多個 git 郵箱——彙總一天的提交和 PR，生成日報。

早上的簡報和晚上的日報首尾相接：昨天收口的東西，就是今天的候選。

四、管住輸出：字數上限和彙報口徑

翻我最近的對話記錄，最常見的一類後綴是字數：「500 字內」「直接説結論，200 字內」「大白話 300 字左右講一下為什麼」。

原因很樸素：agent 默認會鋪陳，而長回答的成本不在它，在讀的人。我第一次讓它寫日報，出來幾百字，有總結、有明細、有明日計劃。我打回去兩句：「只説重點，200 字是上限」「不要明日計劃」。之後這兩條寫進了日報 skill 的輸出格式裏，再沒出現過。

比字數更重要的是口徑——告訴它哪些事不用報：

• 第三方服務的問題只報次數，不展開原因和樣本。我修不了，細節只佔注意力。
• 用户側原因導致的失敗不算故障，從巡檢彙報裏剔掉。
• 篇幅留給我們自己能修的問題。

還有一條：所有預覽一律只做本地文件，我用本地瀏覽器或開發服務看，不發佈任何在線預覽頁。

五、糾正一次，寫成規則

這套東西里最值錢的一條習慣：每次糾正 agent，都寫成一條帶理由的規則。

格式固定：一句事實，一行 Why（為什麼），一行 How to apply（什麼時候、怎麼用）。這些規則放在一個跨機器同步的記憶倉庫裏，任何一台電腦上的任何一個 agent 進來都能讀到。

幾個例子：

• 「全程中文回覆，長任務中途也不許切回英文」——同一個會話裏糾正了三次之後，從普通記憶升級為常駐規則。
• 「對外文案用正面句式説明能做什麼，不寫免責式的否定句。」
• 「規範文檔每類寫成一段話，不要編號。同一要求只寫一處。」

重複糾正的意思是：規則沒放在 agent 一定會讀到的地方。 所以能變成機器門禁的，就別隻留在記憶裏——日報字數寫進了 skill 的輸出格式；「合併前必須由第二個 agent 或獨立會話 review 一遍」寫進了提 PR 前的檢查流程。記憶靠 agent 自覺，門禁不靠。

六、交接：額度用完不是終點

長任務做到一半，額度用完、上下文爆了、要切到另一台機器，都是常態。我的固定指令是：「先停下，一段提示詞交接給其他 agent 繼續，500 字內。」

一份好交接詞只回答五件事：目標是什麼、做完了什麼、還剩什麼、代碼在哪個 worktree 和分支、踩過哪些坑。超過 500 字通常説明它在複述過程，而不是交代狀態。

更長的任務，狀態不放在對話裏，放在倉庫裏的一個 tracker 文件：優先問題、未完成任務、本地未提交的修改、已推送的內容、明確取消的項。對話會被壓縮、會斷，文件不會。

同時我常開兩個 agent 並行：一個改規範和文案，一個寫代碼。我在中間傳話——「隔壁 agent 改好了」——各自只碰自己的那一塊。

七、人只做三件事：選、看、合

把上面這些拼起來，我白天的角色收斂成三個動作：

• 選：從早上的簡報裏挑今天做什麼，決定哪些事不做。
• 看：不看過程，看結果。「先啓動開發服務給我 review」「結果直接給我看鏈接」。看的是頁面和產物，不是 agent 説它做了什麼。
• 合：本機的乾淨目錄 CI 當門檻——臨時 clone、按 lockfile 安裝、跑完整 CI，不碰我正在用的開發目錄。我的規則是「CI 過就開 PR，不用等」，全量端到端測試作為合併前的門檻補跑。合併永遠是我點。

收束

回頭看，AI 用得好不好，判據不是某一次對話有多聰明，而是三件事：

你不在的時候，它在跑；你在的時候，它只説重點；它犯過的錯，不犯第二次。

前一件靠定時任務和籠子，中間一件靠字數和口徑，後一件靠把每次糾正寫成規則。都不難，難的是每次都做。