代码修复 Agent 如何评判修复是否正确？

核心回答

代码修复 Agent 的结果，要同时满足原缺陷消除、相关功能不回归、符合业务要求和修改范围合理。我会先保存原问题的复现条件与失败证据，再在当前补丁上独立运行原失败用例、相关回归和必要的静态检查，并检查实际业务状态与代码差异。

Agent 声称“代码和测试都通过”还不够：要确认跑的是哪份代码、什么命令、覆盖了哪些行为，是否真正执行，以及有没有改测试或跳过失败。最后交付应能对应到补丁、环境、原始测试输出和未覆盖条件，而不只是模型的总结。

展开说明

原问题需要修复前后对照

例如重试请求导致重复建单，先用相同业务请求标识构造重试，保存重复订单的失败结果。修复后既要证明重复请求只得到同一业务结果，也要确认不同请求仍能分别创建。只测“一次请求成功”，不能证明重试缺陷消失。

环境、测试数据和配置应尽量一致。修复前就无法复现的偶发问题，可以保留日志、并发条件和推断，但不能把一次不再出现当成已经证明根因。

回归范围按依赖和影响选择

先跑直接复现用例，再覆盖相邻分支、调用方和重要不变量。例如增加幂等控制后，检查失败重试、并发重复、事务回滚以及幂等标识的作用域。涉及公共接口或数据结构时扩大到对应集成测试；局部文案调整则不需要整套重型评测。

构建、类型检查和静态扫描能发现另一类问题。它们与运行测试互补；代码可编译不能证明金额、权限或时间归属正确。

独立验证要减少共同盲点

修复 Agent 写的新测试可以保留，但预期应由需求、历史行为或可信业务样例确定。另设一组 Agent 未据此反复调参的验收输入，检查边界和反例。审查补丁是否硬编码样例、删除校验、扩大修改面，或把问题藏到其他路径。

执行过程需要区分“测试失败”和“环境没跑起来”。记录实际应用的补丁、依赖环境、命令、退出码、断言输出和最终状态；使用有结果缓存的评测器时，确认结果没有复用旧补丁的缓存。

可能的追问

测试全过，能否说明修复完全正确？

它能证明当前环境中这些用例满足预期，不能证明所有输入和隐含需求都正确。继续按变更影响核对业务规则、端到端行为和安全边界；高影响改动由熟悉业务的人审阅。

批量评估修复 Agent，用什么指标？

以任务为单位统计原问题解决率和回归情况，补充无关修改、危险操作、人工接管、耗时与成本。环境失败单独标记并说明分母；不能把“评测进程没崩溃”当作“问题已解决”，也不能把公开基准分数直接当成自己业务的成功率。

参考资料