如果你担心 Codex 改代码太快、范围太大，可以让它按测试驱动开发。TDD 的好处是把“应该发生什么”先固定下来，再让实现去满足它。
适合 TDD 的任务
- 修复一个已知 bug
- 给现有函数增加边界行为
- 新增一个小接口
- 调整计费、权限、状态流转等高风险逻辑
不适合的任务包括纯视觉探索、一次性脚本、没有测试环境的临时排查。
推荐提示词
请用测试驱动方式实现这个功能：
<功能描述>
流程要求：
1. 先写一个最小失败测试；
2. 运行测试，确认它因为目标功能缺失而失败；
3. 再写最小实现；
4. 重新运行测试；
5. 不做无关重构。怎么判断失败测试是有效的
失败测试应该满足三点：
- 失败原因和目标行为相关
- 不是因为语法错误或环境错误
- 实现完成后会变绿
如果测试一开始就通过，说明它没有测到新行为。你应该让 Codex 重写测试。
示例：修复边界条件
用户余额为 0 时，创建 API Key 应该失败并返回明确错误。
请先补一个失败测试，覆盖余额为 0 的场景。
不要先改实现。这样 Codex 会先把预期行为写进测试里，再改实现逻辑。
实现后继续要求解释
请说明：
- 测试覆盖了哪个行为；
- 实现改动为什么能让测试通过；
- 还有哪些边界条件没有覆盖。这能帮助你判断它是不是只为了通过一个测试而硬编码。
常见坑
不要让 Codex 一次写十个测试。先写最关键的一个。
不要接受只测 mock 的测试。测试应该尽量覆盖真实业务行为。
不要为了测试通过而改掉需求。测试描述错了就先改测试说明，而不是改业务目标。
官方来源
- https://developers.openai.com/codex/learn/best-practices
- https://developers.openai.com/codex/cli