TL;DR老代码补测试的坑都在顺序上：先让 Codex 读懂并描述现状，再让它「测现状」而不是「测理想」，一批一批补、跑通一批再下一批。最后的关键判断——失败时该修代码还是修测试——给了明确规则。
来源信号 SOURCES
以下内容整理自社区公开讨论，本页只做拆解与核实，不搬运原帖；观点归属原作者。
OpenAI 社区 · AGENTS.md File Optimization（测试优先的架构-计划工作流）查看原帖 ↗Hacker News · Codex for almost everything（1001 pts · 工具链验证文化）查看原帖 ↗
事实性知识 FACTS
这些是讨论中被多方印证、或可对照官方文档核实的事实。
- Codex 可以运行项目测试命令并读取失败输出，迭代修复——这是补测试场景可以半自动化的前提。
- AGENTS.md 社区优化帖把「测试优先」列为对代理最有效的指令之一：写清测试命令与验收口径，代理产出质量显著提升。
概念性知识 CONCEPTS
社区讨论里的概念不全是事实——每条都标注了它的性质，读之前先看标签。
测现状个人观点
老代码补测试最容易翻车的点：让 Codex 按「应该有的行为」写测试，结果测的全是它猜的理想。正确口径是先让它描述「代码现在实际怎么表现」，把现状固化为测试。
修码还是修测个人观点
失败时的判断规则：行为符合业务预期 → 修测试（断言错了）；行为是明确的 bug → 修代码并记录。规则本身简单，纪律难。
场景 SOP STEP BY STEP
目标场景：一个没有测试、但稳定运行的老模块要动刀。目标：半天内给它建立第一批安全网测试。
前提项目能运行；知道模块的入口函数。
- 01让它先读懂
问：「阅读该模块，列出每个导出函数的输入、输出与副作用，不要写代码。」人工核对这份理解有没有明显错。
- 02确认测试基建
问：「项目用什么测试框架？如果还没有，推荐最小接入方案。」跑通一个空测试。
- 03第一批：核心路径
让它只给最常用的 2–3 个函数写「测现状」的用例（已知输入 → 当前实际输出）。
- 04跑通一批再下一批
全部通过后，再要边界情况一批。一次只加一批，失败立即处理，不积压。
- 05按规则处置失败
每个失败按「修码还是修测」规则处置，并在提交说明里记下修掉的 bug。
- 06沉淀进 AGENTS.md
把测试命令与「测现状」口径写进仓库的 AGENTS.md，下次所有代理自动遵守。
结果老模块有了第一层安全网，后续重构的底气来自测试而不是记忆。
看完之后 NEXT
想知道今天的重置判定？回到 首页实时雷达。