# 让 Codex 在你睡觉时自己写代码
**作者**: 老金
**日期**: 2026-05-18T12:28:00.000Z
**来源**: [https://x.com/freeman1266/status/2056351092804297028](https://x.com/freeman1266/status/2056351092804297028)
---
我最开始用 Codex 做自动化时，有一个很朴素的幻想：
睡前丢给它一个需求，第二天早上醒来，代码写好了，测试跑完了，PR 也准备好了。
听起来很爽。
但真正跑了半年后，我的结论反而更克制：Codex 确实可以在你睡觉时帮你写代码，但前提是你不能把它当成一个通宵加班的资深工程师，而要把它当成一个不知疲倦、但边界感需要你提前写清楚的执行者。
这篇文章不讲概念，不念文档。只讲一件事：怎样让 Codex 在你睡觉时真的产出代码，而不是第二天早上给你留下一堆半成品、冲突和权限弹窗。
## 睡前任务，最怕一句“帮我优化一下”
很多人第一次尝试夜间自动化，都会这样写：
```
帮我优化一下这个项目。
```
或者：
```
帮我 Review 一下代码，看看怎么优化。
```
这类任务白天都不靠谱，晚上更不靠谱。
因为你睡着以后，它遇到任何一个模糊点，都只能自己猜：哪些文件能改？能不能装依赖？测试失败要不要继续？发现旧代码有问题要不要顺手重构？UI 风格按谁的标准算好？
第二天醒来，你看到的往往不是惊喜，而是一串很长的改动：一半有用，一半说不清为什么动。
真正适合睡前交给 Codex 的任务，必须满足三个条件：
1. 输入清楚；
2. 写入范围清楚；
3. 验收命令清楚。
换句话说，睡前不要许愿，要派工。
## 一个真实例子：让它夜里补 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 路由；
- 一个只读检查前端状态流；
- 一个只读找安全风险和缺测试点。
让它们并行探索，最后汇总报告。
真正写代码的部分，尽量串行。
## 第二天早上怎么验收
不要一醒来就看最终总结。
我的顺序是：
1. 先看 git diff --stat，确认改动范围有没有失控；
2. 再看测试命令和失败信息；
3. 再读关键文件 diff；
4. 最后才看 Codex 的总结。
总结是线索，不是事实。
如果它说“已完成”，但没有跑验证命令，这个任务就不能算完成。如果它改了 scope 之外的文件，也要先退回去问为什么。
自动化不是把 review 省掉，而是把 review 从“从零开始找问题”变成“检查一个已经收敛的补丁”。
## 最后
让 Codex 在你睡觉时自己写代码，这件事不是玄学，也不是神话。
它真正依赖的是工程管理里最朴素的东西：清晰的任务、清晰的边界、清晰的验收。
你给它一句愿望，它大概率还你一堆猜测。
你给它一张夜班工单，它才可能在你睡醒前，把一件具体的事做完。
Codex 能替你熬夜，但不能替你想清楚什么事值得熬夜。
## 相关链接
- [@freeman1266](https://x.com/freeman1266)
- [12K](https://x.com/freeman1266/status/2056351092804297028/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [8:28 PM · May 18, 2026](https://x.com/freeman1266/status/2056351092804297028)
- [12.2K Views](https://x.com/freeman1266/status/2056351092804297028/analytics)
- [View quotes](https://x.com/freeman1266/status/2056351092804297028/quotes)
---
*导出时间: 2026/5/19 09:15:30*