AI生成的测试为何会让代理改错代码

AI生成的测试可能让编码代理改错方向。补丁让新测试全绿，不等于守住了原有约定。更麻烦的是，测试会把下一次修改引向错误目标。用一个订单过滤器例子可以看清。 需求有三条。不传过滤条件或传 None，返回全部订单。传空列表，返回空结果。传状态列表，只返回匹配订单。Python 里 None 和空列表都是假值，但业务含义不同：前者是没有限制，后者是限制为空。 报告缺陷是省略过滤条件时返回空。提议修复：只要过滤条件为假值，就返回全部订单。两条检查通过，两个分支都走到，症状消失。补上第二条要求的检查，它失败：传空列表时返回了全部订单。修复抹掉了两种假值的区别。问题不在语法，而在合同解释。 当检查决定代理下一步怎么做，后果会放大。坏测试不只是漏缺陷，它会给下一次编辑错误目标。假设加上断言：传空列表应返回全部订单。错误补丁通过，正确实现失败。把失败喂给自动修复循环，循环就有理由破坏正确行为。断言越多，错误解释越被加固。 连“修复前失败、修复后通过”也要多看一眼。原始实现会让默认过滤条件的断言失败，并通过提议补丁。它能发现最初缺陷，却无法发现新缺陷。完整修复要显式处理 None，把它和空列表分开。额外检查的价值在于，它能区分早先检查都认为可接受的实现。 有些对比实验值得关注。ExecCritic 的一项预印本研究固定 Qwen-3.5-35B-A3B Repair 代理，在 SWE-bench Verified 上比较测试质量。较弱的测试让解决率下降 3.9 个百分点，更好的测试则提升。比率平均了三次修复运行，并复用生成的测试；最终解决由独立官方评估器判定，反馈环节还增加测试生成和修订工作，计算预算并不对齐，基线也不禁止仓库测试。这些是研究者结果，不是独立复现，但指向一个风险：测试质量会改变代理行为方向。 把问题带到测试审查时，先问：这个测试会拒绝哪一种合理但错误的实现？对订单过滤器，候选错误可以命名：完全忽略过滤条件，把缺失都当空，把空都当缺失。能分开这些情况的测试，比多写几个已支付订单示例更有信息量。 变异测试也能帮忙。对实现做小改动，看套件是否发现。检查存活变异，理解它们改变了什么；有些对当前输入是等价的。把 None 改成和空列表一样，在这里是有用的手动变异，因为它对要求行为有已知、可观察的影响。 代理工作流可以试四个改动。写补丁评审前先写预期行为，包含普通情况、报告失败的情况、最容易混淆的邻近情况。None 和空列表应分属不同行。如果问题描述没说明区别，在把任一解释变成测试前，应拿到产品决定。 像审查生产代码一样审查预期值。断言是对产品的声明，要追溯到需求、兼容承诺或独立核对的例子。把当前输出复制成预期值，可能正好保留你本来想质疑的行为。 修复期间让已接受的回归检查保持稳定。代理改实现，单独运行器用审查过的测试评估。测试命令和配置也要保护：测试文件没变，如果补丁能跳过执行，帮助也不大。测试本身错了，就明确修订并审查，再重新评估候选。 要求代理修复前先看失败类型。断言显示错误订单，是可操作的行为证据。缺少依赖、导入失败、命令没选中测试，需要不同处理。记录运行了什么和为什么失败。 ExecCritic 把测试创建和修复分开，在原始仓库上确认测试资格，并在修订期间保持不变。这限制了修复器改变目标的能力。不过，分离上下文和权限仍不能保证两个代理都正确理解问题。 这些步骤不需要训练模型，可以在现有项目试。价值由暴露的缺陷和错误预期判断。下一次让 AI 辅助修复，保留原始代码、补丁和新测试，找一个违反需求的合理替代实现，对它运行测试。如果两个实现都得到绿色结果，说明套件还回答不了一个具体问题。添加能区分它们的检查，并在信任下一次修复前审查预期结果。