Codex 能用来做 TDD 吗？红灯、绿灯、重构完整示例

大家好，我是 Codex 中文网的站长宇哥。

本文按 2026 年 8 月的 Codex 公开能力整理。Codex CLI、模型、Skill、Plugin 和第三方兼容接口更新较快，具体字段与可用能力请以你当前版本和官方文档为准。

“Codex 能用来做 TDD 吗”非常适合交给 Codex 协助，因为这类任务往往需要大量阅读、建立行为模型、生成测试或整理文档。但越是重构和质量工作，越不能只追求“改动看起来更漂亮”，而要有可验证的行为基线。

先决定测试要保护什么行为

测试不是按行数补齐。先找高风险路径：权限、金额、状态转换、并发、序列化、外部依赖、错误恢复。让 Codex 先列测试矩阵，再生成代码。对 Mock 要区分“隔离不稳定外部依赖”和“把所有内部实现都 Mock 掉”，后者会让测试失去重构价值。

安全重构的顺序

1. 记录当前行为和调用方。

2. 补足能保护核心行为的测试。

3. 一次只做一种结构变化。

4. 每个小步骤都运行测试。

5. 最后再统一命名、格式和文档。

不要把“功能改动 + 大规模重命名 + 依赖升级”混在同一个 Diff 里，否则 Code Review 很难判断行为是否改变。

推荐提示词

目标：Codex 能用来做 TDD 吗
范围：先阅读相关代码和配置，再提出最小改动方案。
约束：保持对外行为不变；优先增加验证证据；任何行为变化都单独说明。
验收：说明改了什么、为什么这样改，并运行能覆盖本次修改的测试或检查命令。
如果遇到不确定信息，先验证再修改，不要猜测项目结构。

Review 时重点看什么

• 测试是否真的会在错误实现下失败；
• 重构是否改变公开 API、事务或异常语义；
• 性能结论是否有前后对比数据；
• 文档里的命令、端口、路径是否能从仓库事实验证；
• Mermaid/架构图是否过度简化了真实依赖；
• 自动生成 Fixture 是否稳定、可重复、不会依赖当前时间或随机外部状态。

常见问题

这篇文章适合新手照着做吗？

适合。建议先按文章里的顺序理解问题背景，再在自己的项目里做最小验证，不要一次修改太多配置。

文章里的命令和配置需要完全照抄吗？

不建议完全照抄。Codex、模型接口和第三方工具更新很快，执行前要结合当前系统、项目目录、账号权限和官方文档再确认一遍。

总结

做好“Codex 能用来做 TDD 吗”的关键，是让 Codex 围绕行为基线和验证证据工作。先建立可以信任的测试/数据，再让 AI 做大规模阅读和机械化修改，才能真正把效率优势变成工程质量。

参考资料

• OpenAI：AGENTS.md
• OpenAI：Codex CLI

如果你通过第三方 API、中转站或兼容层使用 Codex，协议行为可能与 OpenAI 官方链路不同，排查时要把“Codex 客户端”和“上游接口”分开验证。