一个缺陷修好以后，最有价值的证据是同一输入再也触发不了它。把问题交给 Codex 时，先提供可重复的触发条件、预期结果、实际结果和运行环境。只有一张报错截图，通常还不足以定位代码路径。
把现象压成最小复现
先让 Codex 只读追踪入口、数据流和现有测试。删掉与故障无关的步骤，保留最短输入和稳定断言。若问题只在某个浏览器、时区、数据库状态或依赖版本出现，把这个条件写进测试名称或测试夹具，避免本地偶然通过。
新增回归测试后，先在旧代码上运行一次。它应该因目标缺陷失败，失败位置也应指向预期行为。测试因为路径写错、夹具缺失或网络波动而失败，不能证明它抓住了问题。
修复只碰根因所在
让 Codex 说明根因对应哪段状态、条件或边界处理，再修改最小范围。避免顺手格式化整片文件、改公共接口或清理邻近代码。差异越小，回归测试与修复之间的关系越容易审查。
修复完成后先跑新增测试，确认它从失败变为通过。随后跑同一模块的已有测试，覆盖正常输入、空值、边界值和错误分支。若修复改变了公开类型、API 响应或数据库行为，还要补上调用方验证。
再查一次没有误伤
完整测试、类型检查和构建都通过以后，查看 Git 差异和测试清单。Codex 的 /review 可以按未提交改动、提交或基础分支检查差异，并给出按优先级整理的发现。审查本身不会修改工作树，是否应用建议仍由当前任务和权限决定。
远端项目还要等 GitHub Actions 的必需检查结束。GitHub 的受保护分支可以要求状态检查通过后才能合并。这里的“通过”只说明当前提交满足已配置检查，未覆盖的行为仍要靠测试设计补齐。
检查这条测试会不会撒谎
把修复临时还原，再运行新增测试。它应当重新失败。这个动作能排除测试只验证常量、走错分支或根本没有执行的情况。恢复修复以后，连续运行目标测试几次，确认它不依赖执行顺序、真实网络、系统时间和前一次留下的数据。
断言要盯住用户可见行为。接口缺陷可以断言状态码和响应字段，排序缺陷可以给出固定输入并核对完整顺序，权限缺陷则用不同身份分别验证允许与拒绝。测试若只断言内部函数被调用，重构以后容易失效，也未必能保护原问题。
最后读一遍测试名称和注释。它们应当说明触发条件与期望结果，避免写入工单号之外再无信息。工单链接可能失效，测试本身仍要让维护者看懂。
测试数据也要尽量小。夹具越接近触发缺陷所需的最少字段，后续维护者越容易看出哪一个条件不能删。
交付时写清四件事。缺陷怎样复现，新增测试为什么能抓住它，代码改了哪里，哪些检查已经跑过。这样过几个月再看到这条测试，维护者仍能理解它守住的行为。