怎么把 Codex 用在真实项目里，不把团队拖进“快而不稳”
把它当成变更流水线的一段，而不是一个更快的作者
很多人问“怎么用 Codex”，默认是在问快捷键、提示词模板、怎么让它多写点代码。
我后来发现，这个问题问错了方向。
Codex 最大的价值不是替你写出更多代码，而是让你更频繁、更便宜地发起变更。真正的风险也在这里：你把变更频率抬上去之后，团队原来的把关机制可能不够用了。
所以这篇我不讲“十个提示词技巧”。我只讲一条主线：把 Codex 接进一条可验收、可回滚、可追溯的变更流水线。
1. 先选对“适合 Codex 的工作单元”
最容易翻车的用法，是把一个模糊需求直接丢给 Codex：
- “把这个模块重构一下”
- “优化一下性能”
- “把这里改得更优雅”
它当然能给你一大坨改动，而且看起来都对。问题是你没法验收，也没法 review。
我把适合 Codex 的任务收敛成三类，每一类都有清晰的“完成条件”。
A. 可写成断言的行为变更
特征是：你能一句话描述输入输出。
- 给一个函数补边界处理
- 修一个明确的 bug
- 把一段逻辑迁移到新接口但语义不变
最好的验收方式是直接写测试，或者至少写一段可运行的断言脚本。
B. 可枚举的机械性改动
特征是：规则明确，覆盖面可控。
- 批量改命名
- 升级 API 调用
- 补全 nullability / error handling
这类工作 Codex 很强，但你必须让它输出“修改列表”和“可搜索的变更范围”，否则你会漏掉角落。
C. 有硬指标的局部优化
特征是：你能定义测量方法。
- 启动阶段减少一次 IO
- 某条链路减少一次序列化
- 某个页面减少一次不必要的重排
没有指标就别做优化，Codex 会把“看起来更快”当成“真的更快”。
2. 把需求写成“验收标准”，再写提示词
很多人写提示词像写愿望：
- “请写得优雅一点”
- “请遵循最佳实践”
这些都是不可验收的。
我要求每次让 Codex 动手之前，先写一段验收标准，写在同一个任务描述里：
- 这次改动要改变什么行为
- 不允许改变什么行为
- 失败时应该怎样表现
- 如何回滚
你会发现，一旦验收标准写清楚了，提示词反而变短了。
一个我常用的结构是：
- 背景（两三句，别讲历史）
- 目标（只写行为，不写实现）
- 约束（不能动哪些东西）
- 验收（测试点或脚本）
- 输出格式（先给计划，再给 patch）
3. 要求 Codex 先给“变更计划”，不要直接给最终代码
真实项目里最贵的不是生成速度，是“合并后发现语义变了”。
所以我让 Codex 的默认输出分两步：
- 第一步：列出将改哪些文件，为什么改，每个改动的风险点
- 第二步：再给 patch
如果它一上来就输出一整段代码，我会直接打回去，让它补计划。
原因很简单：
- 计划阶段能暴露它有没有理解边界
- 计划阶段你能及时砍掉过大的改动
4. 让 Codex 输出“可审阅的 patch”，不是一坨文本
你在 IDE 里复制粘贴几百行代码，是在把 review 变成体力活。
正确姿势是：让 Codex 以 diff/patch 的形式输出，或者让它只做最小可合并改动。
在团队里我会坚持两个约束：
- 单个 PR 不跨两个不相关的意图
- 单个 PR 的核心差异在 200 行以内（否则必须拆）
Codex 很容易越写越多，你必须用 PR 约束把它“关在小盒子里”。
5. 让测试成为“第一输出”，不是“最后补一下”
Codex 最常见的陷阱是：实现写得很完整，测试看起来也有，但测试只是在验证它自己写的实现。
所以我要求它按顺序输出：
- 测试用例列表（覆盖哪些边界）
- 关键测试代码
- 实现 patch
如果它给不出测试点，要么说明需求没写清楚，要么说明这次改动不适合交给它做。
6. 把“回滚路径”写进变更里
手写改动的人通常会下意识留后路。
生成改动的人很容易忘。
我会要求每个生成变更至少满足一个回滚策略：
- feature flag
- 配置开关
- 保留旧路径一段时间（双跑）
没有回滚路径的大改动，不管是谁写的，都不该上线。Codex 只是更容易让你做出“大改动”。
7. 把可追溯性当成使用 Codex 的“成本项”
如果你只统计“省了多少开发时间”，你会鼓励大家让 Codex 写得越来越多。
我更在意的是：出了问题能不能复现。
所以在流程里我会强制记录三样东西：
- 这次给 Codex 的任务描述（包含验收标准）
- Codex 给出的变更计划
- 最终 patch 与测试结果
这三样是事故复盘时的证据链。
你不记录，Codex 用得越多，你越像在运营一个不可复现的系统。
8. 一套“能直接拿去用”的提示词骨架
下面这段不是为了让它写得更像人，而是为了让它输出可上线的最小变更。
你可以直接复制，把中括号替换掉：
你要在一个真实项目里做改动。
背景：[两三句说明现状和问题] 目标（行为层面）：
- 必须做到：[列 2-4 条]
- 绝对不能改变：[列 2-4 条] 约束：
- 不允许引入新依赖/不允许改 public API/必须兼容旧数据（按需选择） 验收：
- 给出测试点清单
- 给出至少 [N] 个关键测试用例代码 输出格式：
- 先给变更计划（文件列表 + 风险点）
- 再给最小 patch（diff），不要夹杂解释性长文
适用边界
Codex 不适合的场景也很明确：
- 你自己都说不清要什么行为，只能“先试试”
- 这是一次涉及数据迁移、权限、资金的高风险变更，但你没有完整的验收环境
- 你依赖隐性知识（线上开关、灰度策略、历史事故）却没有文档化
这些场景里，Codex 会把不确定性直接固化成代码。
结尾
“怎么用 Codex”的答案不是一个提示词模板，而是一套工程约束。
你把它当成更快的作者，就会把责任推给 review 和线上。
你把它当成流水线的一段，用验收标准、测试、回滚和可追溯性把变更收敛住，它才会变成真正的效率工具。