让 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 用得好不好，判据不是某一次对话有多聪明，而是三件事：

你不在的时候，它在跑；你在的时候，它只说重点；它犯过的错，不犯第二次。

前一件靠定时任务和笼子，中间一件靠字数和口径，后一件靠把每次纠正写成规则。都不难，难的是每次都做。