Codex 说修好了却没有有效改动：把回复、差异与测试对齐

Codex 说“修好了”，需要与磁盘差异及可执行检查对齐后才能验收。自然语言回复是待核对的声明，不能替代产物。遇到回复很肯定、文件却几乎没变的情况，先整理证据表，再要求补做缺失步骤；不必立刻重跑整个任务。

把一句结论拆成可验证声明

假设任务是“空日期不再触发异常，非法日期显示提示”。工具回复“已修复日期校验并补充测试”，其中至少包含三项：空值有明确处理、非法值有明确结果、相关测试已经存在。每一项都应对应文件位置和独立检查，不能只找一个函数名就认为全部成立。

工具声明	文件或差异证据	可执行验证	当前结论
空值不报错	parser 中空值分支	输入空字符串	待运行
非法日期有提示	调用方错误映射	输入不存在的日期	待运行
已补测试	测试新增用例	定向运行该测试	待运行
旧行为保持	原有分支未被意外删除	运行正常日期用例	待运行

行号随修改会变，表中同时记录路径与函数名。若没有差异，先问是否已经有正确实现、生成到了另一目录或只写了建议。没有改动也可能正确，但必须展示现有逻辑为何满足需求。

先确认测试有没有真的检查问题

打开新增测试看输入、执行路径和断言。测试文件存在、测试进程退出为零，都不足以证明目标行为被检查：测试可能被跳过、没有被发现，或者只验证返回值不为空。查看运行摘要中的用例数量、跳过数量与目标用例名称，并保留命令原文。

对合成日期案例，可列出空值、正常日期、非法日期和缺失字段四个输入。期望应由需求先确定，不能照当前错误实现抄答案。若可以在独立目录应用修复前版本，确认对应反例原本会失败，再在修复后通过，证据会更强。不要为制造失败改坏共享工作区。

差异小不等于无效，差异大也不等于完成

一行条件判断可能就是完整修复；大规模重构也可能完全没碰触发路径。评审要沿输入到输出看调用关系：是否进入新分支，异常是否被上层吞掉，界面是否仍显示旧提示。对配置任务，则检查实际读取配置的进程是否重新载入，避免只验证文本文件里多了一个键。

用三个状态收尾最清楚：“通过”必须有执行证据；“失败”写实际输出与期望差异；“未验证”写缺少什么环境。工具无法访问数据库时，可以完成纯函数验证并留下集成检查步骤，但不能把它写成全链路通过。

给下一轮的指令要指出证据缺口

可以直接写：“日期空值分支已看到；非法日期测试没被发现，当前运行只执行三个旧用例。请确认测试发现规则，修复后给出用例名称、退出码和差异。”这样的反馈指向一个有限任务，减少工具根据“再检查一下”扩散修改。

最后确认此次修改没有夹带无关依赖、快照更新或注释改写。把最终表随提交保存，后续人能从具体声明追到产物，无需重新翻完整聊天记录。

常见问题

没有差异就一定是敷衍吗？ 不能这样判断，现有代码可能已经满足需求，需要展示证据。

工具贴了测试输出就可以吗？ 核对命令、时间、路径、用例数和退出状态，必要时在当前提交重跑。

截图能替代测试吗？ 截图可证明某个可见状态，通常不能证明异常分支和数据处理完整性。

继续处理相关问题

相关入口：Codex 远程压缩报错分流。

官方依据与核对日期

核对日：2026-10-23。Git diff 比较：可按路径查看工作区及暂存差异，用于核对产物。文中的流程、阈值和合成数据属于工程示例，不能代替当前账号、文件或运行环境的验收。