让 Codex 在你睡觉时自己写代码

我最开始用 Codex 做自动化时，有一个很朴素的幻想：

睡前丢给它一个需求，第二天早上醒来，代码写好了，测试跑完了，PR 也准备好了。

听起来很爽。

但真正跑了半年后，我的结论反而更克制：Codex 确实可以在你睡觉时帮你写代码，但前提是你不能把它当成一个通宵加班的资深工程师，而要把它当成一个不知疲倦、但边界感需要你提前写清楚的执行者。

这篇文章不讲概念，不念文档。只讲一件事：怎样让 Codex 在你睡觉时真的产出代码，而不是第二天早上给你留下一堆半成品、冲突和权限弹窗。

睡前任务，最怕一句“帮我优化一下”

很多人第一次尝试夜间自动化，都会这样写：

帮我优化一下这个项目。

或者：

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

这类任务白天都不靠谱，晚上更不靠谱。

因为你睡着以后，它遇到任何一个模糊点，都只能自己猜：哪些文件能改？能不能装依赖？测试失败要不要继续？发现旧代码有问题要不要顺手重构？UI 风格按谁的标准算好？

第二天醒来，你看到的往往不是惊喜，而是一串很长的改动：一半有用，一半说不清为什么动。

真正适合睡前交给 Codex 的任务，必须满足三个条件：

• 输入清楚；

• 写入范围清楚；

• 验收命令清楚。

换句话说，睡前不要许愿，要派工。

一个真实例子：让它夜里补 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 存储（KV storage）的行为差异。

验证要求： 运行 npm run check；

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

这才是能放到夜里跑的任务。

它不要求 Codex “想清楚整个产品”，只要求它沿着你定义好的边界，把一组风险检查到底。

夜间自动化的 3 类好任务

不是所有代码任务都适合睡觉时跑。我目前最放心的，是下面三类。

第一类：只读扫描，第二天给你报告

这是成功率最高的。

比如每天晚上让 Codex 扫一遍仓库：

扫一下代码库里的 TODO、有风险的公开 Endpoint、漏掉的测试、Deprecated 的 API，还有 README 里前后矛盾的说明。不用改代码，出个优先级报告就行。

这种任务不改代码，不碰权限，不会制造冲突。它的价值是把第二天早上的注意力变得更集中。

在 ShipReady 这种项目里，它可以稳定提醒你：

• package.json 里的 npm run check 只是语法检查；

• /api/share 和 /api/rewrite 是付费状态相关路径；

• renderPublicReport 是公开 HTML 输出点；

• src/store.js 里 memory 和 KV 是两套存储路径；

• URL 抓取失败后依赖 manual paste fallback。

你醒来以后，只需要判断哪些问题值得动手。

第二类：小范围补测试

这是最实用的一类。

让 Codex 夜里补测试时，范围一定要窄。不要说“给项目补测试”，要说“只给这个模块补这几种行为”。

例如：

为 ShipReady 的审计流程添加针对性的测试。

覆盖范围：

• 未付费的审计无法创建公开报告；
• 已付费的审计可以创建一份公开报告；
• 公开报告在渲染时，必须对标题（title）、主视觉（hero）、证据（evidence）和建议（recommendation）等字段进行转义；
• URL 获取失败时，应返回手写/手动粘贴（manual_paste）的数据源，并附带一条有用的提示信息。

注意事项： 除非测试暴露出真正的 Bug，否则不要重构生产环境代码。 请运行 npm run check 以及新的测试命令。

这里的关键不是测试数量，而是测试目标。

Codex 最怕你让它“提高覆盖率”。它会为了覆盖率写一堆价值很低的测试。你要让它盯住会出事故的路径。

第三类：文档和工程卫生

这类任务非常适合夜里跑。

比如：

更新 README.md，方便新加入的开发者能够运行、验证和部署 ShipReady。

必须包含以下内容：

• 本地运行命令
• 校验命令
• Vercel 路由模型
• 内存存储限制
• KV / Upstash 环境变量
• 健康检查接口

注意事项： 不要修改任何应用程序代码。

文档任务的好处是：就算写得不完美，第二天也很容易 review。它不会破坏线上逻辑，也不会引入复杂合并冲突。

3 类任务，不要睡前交给它

夜间自动化真正翻车的地方，通常不是 Codex 太弱，而是你把不该无人值守的任务扔给了它。

第一类：产品判断很重的任务

比如：

提升 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 存储与内存存储的行为差异、付费/分享状态的流转，以及缺失的测试用例。
• 除非明确要求，否则请勿将确定性的审计引擎（Deterministic audit engine）替换为 LLM（大语言模型）调用。
• 除非任务明确要求修改产品文案或进行前端开发，否则请保持 UI 文案和样式一律不变。

Memory 可以记住偏好，但团队硬规则应该写在仓库里。

否则你以为 Codex 在遵守规范，实际上它可能只是在复现你某次赶进度时留下的坏习惯。

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

很多人听到子代理并行，会自然想到：

一个改前端，一个改后端，一个写测试，半夜一起干活。

听起来效率很高，实际很容易翻车。

真实业务工程里，前端、后端、类型、配置、测试经常共享文件。两个代理同时写同一个文件，后完成的覆盖先完成的，第二天你会先处理冲突，再理解逻辑。

我更推荐夜间这样用子代理：

• 一个只读梳理 API 路由；

• 一个只读检查前端状态流；

• 一个只读找安全风险和缺测试点。

让它们并行探索，最后汇总报告。

真正写代码的部分，尽量串行。

第二天早上怎么验收

不要一醒来就看最终总结。

我的顺序是：

• 先看 git diff –stat，确认改动范围有没有失控；

• 再看测试命令和失败信息；

• 再读关键文件 diff；

• 最后才看 Codex 的总结。

总结是线索，不是事实。

如果它说“已完成”，但没有跑验证命令，这个任务就不能算完成。如果它改了 scope 之外的文件，也要先退回去问为什么。

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

最后

让 Codex 在你睡觉时自己写代码，这件事不是玄学，也不是神话。

它真正依赖的是工程管理里最朴素的东西：清晰的任务、清晰的边界、清晰的验收。

你给它一句愿望，它大概率还你一堆猜测。

你给它一张夜班工单，它才可能在你睡醒前，把一件具体的事做完。

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