最开始用 Codex 做自动化，我脑子里有个挺幼稚的画面：睡前丢一个需求，第二天起床，代码写完了，测试过了，PR 也开好了。

跑了半年，这个画面基本没实现过。

Codex 确实能在你睡觉时帮你写代码，但它不是一个肯通宵的资深工程师。它更像一个不知疲倦的执行者，但边界得你提前画清楚，否则它就自己猜。

这篇只聊一件事：怎么让它在你睡着的时候真的产出东西，而不是第二天早上留给你一堆半成品、合并冲突和权限弹窗。

睡前最怕一句"帮我优化一下"

很多人第一次试夜间自动化，prompt 都长这样：

帮我优化一下这个项目。

或者：

帮我 Review 一下代码，看看怎么优化。

这种任务白天就不靠谱，晚上更不靠谱。你睡着以后，它碰到任何一个模糊点都只能自己拍脑袋：哪些文件能动？能不能装依赖？测试挂了要不要继续？看到旧代码不顺眼要不要顺手重构？

第二天醒来，等你的往往是一长串改动：一半有用，一半说不清为什么动。

睡前能交出去的任务，得同时满足三件事：输入清楚、写入范围清楚、验收命令清楚。睡前别许愿，得派工。

一个真实例子：让它夜里补 ShipReady 的安全检查

拿我手边的 ShipReady 举例。这是一个 SaaS 落地页审计 MVP：用户输入 URL 或者直接粘贴文案，系统出 12 项审计报告；回答 3 个定位问题后可以解锁 Hero 和 CTA rewrite pack；付费后能生成公开报告链接。

项目不大，但正好有几件事适合扔给 Codex 半夜做。/api/share 必须确认用户已经 unlock，不能让没付费的人生成公开报告；公开报告里会输出 title、hero、evidence、recommendation，HTML escape 不能漏；URL 抓取失败时前端必须能切回手动粘贴；默认 memory storage 在 serverless cold start 之后可能丢数据，README 里得把 KV / Upstash 的生产配置讲清楚；现在的 npm run check 只做了 Node 语法检查，业务测试还是空的。

每一条都有明确的风险点、文件范围和验收标准。

睡前我不会写"优化一下 ShipReady 的后端代码"，我会写：

审计 ShipReady 后端，确保公开报告的安全。

审计范围：
审查 src/app.js、src/audit.js、src/store.js、public/app.js、README.md。

修改限制：必要时仅修改测试用例或少量校验逻辑。
依赖限制：不要添加任何运行时依赖。
UI 限制：不要改产品文案或 UI 样式。

核心关注点：
- 未付费用户绝不能创建公开报告；
- 公开报告 HTML 必须对用户可控字段做转义（防 XSS）；
- URL 抓取失败时必须保留手动粘贴 fallback；
- 必须记录并说明 memory 与 KV 存储的行为差异。

验证：运行 npm run check。

总结发现的风险、修改的文件，以及仍需人工介入的事项。

这才是能放到夜里跑的任务。它不要求 Codex 想清楚整个产品，只要求它沿着我画好的边界，把一组风险查到底。

夜里我敢交出去的几类任务

只读扫描，第二天给我一份报告。 成功率最高的就是这一类。每天晚上让 Codex 扫一遍仓库里的 TODO、有风险的公开 endpoint、漏掉的测试、deprecated 的 API，以及 README 里前后矛盾的说明，不改代码，出个优先级报告。它不碰权限，不会制造冲突，价值是把第二天早上的注意力变得更集中。放在 ShipReady 上，它能稳定提醒我：package.json 里的 npm run check 只是语法检查、/api/share 是付费状态相关路径、renderPublicReport 是公开 HTML 输出点、src/store.js 里 memory 和 KV 是两套存储、URL 抓取失败之后依赖 manual paste fallback。我醒来只需要判断哪些值得动手。

小范围补测试。 最实用，但范围一定要窄。别说"给项目补测试"，要说"只给这个模块补这几种行为"。比如让它覆盖未付费审计无法创建公开报告、已付费审计可以创建一份公开报告、公开报告渲染时 title 与 hero 等字段必须转义、URL 抓取失败时返回 manual_paste 数据源并附带提示信息，并要求除非测试暴露真正的 Bug 否则不要重构生产代码，最后运行 npm run check 和新的测试命令。关键不是测试数量，是测试目标。让它"提高覆盖率"是最糟糕的指令，它真会为了数字写一堆没价值的用例。让它盯住会出事故的路径。

文档和工程卫生。 非常适合夜里跑。比如让它更新 README.md，把本地运行命令、校验命令、Vercel 路由模型、内存存储限制、KV / Upstash 环境变量、健康检查接口都补上，同时明确不要修改任何应用程序代码。文档任务就算写得不完美，第二天也容易 review，不会破坏线上逻辑，也不会引入合并冲突。

我不会睡前交给它的几类任务

产品判断很重的任务。 比如"提升 Onboarding 体验""提高定价页的转化率"。这类事不是不能交给 Codex，而是不适合在你睡觉时让它自己改。涉及产品判断、用户理解、视觉取舍、文案策略，让它出方案、列问题、做竞品归纳没问题，但别让它在无人值守状态下直接大改。

跨前后端的大重构。 比如"把 App 的架构重构一下"。一个看起来很简单的后端状态字段，可能同时影响 API、前端渲染、存储结构、公开报告、README 和部署说明。你睡着时让它跨层改，第二天大概率是在读 diff，而不是收成果。夜间任务尽量单层、单目标、少文件。

需要真实账号或生产权限的任务。 Computer Use 能开应用、点按钮、填表单、读屏幕，但这不代表你应该让它在半夜操作真实后台、个人邮箱、客户数据或者生产系统。我的规则：localhost 可以测，测试账号可以点，生产后台默认不碰，个人邮箱和聊天工具默认不碰，"Always allow"只给非常窄、非常确定的动作。代码写错最多回滚，权限给错，它可能替你做了不该做的操作。

我现在固定用的睡前任务模板

目标：
<一句话说明要完成什么>

上下文：
<项目背景、相关模块、为什么要做>

范围：
- 允许修改的文件或目录：
- 仅限读取的文件或目录：
- 明确排除在外的事项：

规则：
- 除非明确需要，否则不要添加任何依赖。
- 不要更改无关的 UI 或文案。
- 不要重写系统架构。
- 除非列出的 Bug 要求修改，否则保留现有所有行为。

验证：
- 运行 <命令>。
- 如果无法运行验证，请解释原因。

最终响应输出：
- 列出已修改的文件。
- 列出已运行的命令。
- 列出残留的风险或需要人工审查的决策。

模板看着啰嗦，但它省的是第二天早上的时间。你不是在写 prompt，你是在写夜班工单。

AGENTS.md：写给夜班 Codex 的员工手册

如果你真的想让 Codex 在你睡觉时自己写代码，仓库里最好放一份 AGENTS.md。它不是装饰品，是员工手册。

以 ShipReady 为例，我会这么写：

# AGENTS.md

- 这是一个基于 Node 18 的 SaaS 落地页审计 MVP，没有任何外部运行时依赖。
- 修改 JS 文件后，请运行 npm run check。
- 除非明确要求，否则请勿添加任何生产环境依赖。
- 优先围绕以下方面排查：公开 HTML 转义、URL 抓取失败的兜底机制、
  KV 与内存存储的行为差异、付费/分享状态的流转、缺失的测试用例。
- 除非明确要求，否则请勿将确定性的审计引擎替换为 LLM 调用。
- 除非任务明确要求修改产品文案或前端开发，否则保持 UI 文案和样式不变。

Memory 能记住偏好，但团队硬规则应该写在仓库里。否则你以为 Codex 在遵守规范，实际上它可能只是在复现你某次赶进度时留下的坏习惯。

子代理并行：适合夜里探索，不适合夜里乱改

很多人一听到子代理并行，自然就想到一个改前端、一个改后端、一个写测试，半夜一起干活。

听着效率很高，实际很容易翻车。真实业务工程里，前端、后端、类型、配置、测试经常共享文件。两个代理同时写同一个文件，后完成的覆盖先完成的，第二天你得先处理冲突，再理解逻辑。

我更推荐夜里这么用：一个只读梳理 API 路由，一个只读检查前端状态流，一个只读找安全风险和缺测试点。让它们并行探索，最后汇总报告。真正写代码的部分，尽量串行。

第二天早上怎么验收

别一醒来就直接看 Codex 写的总结。

我的顺序：先看 git diff --stat，确认改动范围有没有失控；再看测试命令和失败信息；再读关键文件的 diff；最后才看它自己写的总结。

总结是线索，不是事实。它说"已完成"但没跑验证命令，这个任务就不能算完成；它改了 scope 之外的文件，也得先退回去问为什么。

自动化不是把 review 省掉，而是把 review 从"从零开始找问题"变成"检查一个已经收敛的补丁"。

Codex 能替你熬夜，但替不了你想清楚什么事值得熬夜。