验证 AI 修复：同一测试先失败再通过

AI 编程 Agent 修完 bug、补上测试，再交出一片绿色，任务就算完成了吗？作者提出了一个容易被忽略的问题：新增测试在修复前的代码上，会不会也通过？如果答案是会，测试通过就不足以证明它覆盖了这次故障。

围绕这个缺口，作者开发了 AI Coding Agent Reliability Kit，把修改范围、回归验证、干净环境重放和人工审查串起来。它的价值不在于宣布代码可靠，而在于让审查者看清：Agent 交出的证据，到底能支持多大的结论。

测试全绿，为什么仍然证明不了修复有效

一次常见的修复流程是：Agent 修改实现，新增测试，执行 pytest tests/test_bug.py，命令成功退出，然后报告任务完成。

这里验证的是「最终版本通过了测试」，缺少的却是另一个问题：这个测试能不能识别原来的错误？

作者给出的判断标准很直接：同一份回归探针（regression probe），在已知有问题的基线版本上应该得到 FAIL，在修复版本上应该得到 PASS。这里的探针，可以理解为专门检查这次故障的测试。

回归测试需要证明自己能抓住旧 bug，最终通过才更有说服力。

原文用一个简单例子说明：calculate(a, b) 本应返回 a * b，旧实现却返回 a + b。如果测试只断言 callable(calculate)，修复前后都会通过。它验证了函数可以调用，却没有检查乘法行为。

Kit 把这种结果称为 non-discriminating，即证据没有区分力。这不等于源代码修错了，而是现有测试无法支撑「这个 bug 已被验证修复」的结论。

slug 函数的例子更贴近日常开发。旧实现 text.strip().lower().replace(" ", "") 会把 Hello World 变成 helloworld，需求却是 hello-world。

作者给出的修复通过拆分单词再连接，保留单词之间的连字符：

def slugify(text):
    return "-".join(text.lower().split())

关键是 split() 与 "-".join(...) 的组合，它改变了空白字符的处理方式。

对应的回归测试直接检查输出：

def test_slugify():
    assert slugify("Hello World") == "hello-world"
    assert slugify("Two Words") == "two-words"

要看的是两个具体的输出断言。把这份测试放回旧实现，它应该失败；运行在新实现上，它应该通过。两次结果放在一起，比单独展示修复后的绿色结果更有信息量。

不过，这也只覆盖了给出的输入。标点、非英文字符和其他 slug 规则，原文没有展开，不能顺手把结论扩大成「slug 功能已经完整正确」。

修改正确、没有越界、能够复现，是三件事

Kit 的另一个重点，是在 Agent 开工前定义任务和允许修改的路径，再生成带有边界的任务说明。

例如，任务只允许修改 src/formatter.py 和 tests/test_formatter.py。即便修复与测试都正确，只要最终还改了 README.md，工作流也应该单独报告。

这个设计解决的是审查范围问题。Agent 完成了目标，不代表附带修改就自动合理；自动化流程意外触碰的文件，也不能因为测试通过而被忽略。作者没有说所有越界修改都必然错误，而是要求把它们明确呈现给审查者。

复现又是另一层检查。有些测试通过，可能依赖工作目录里残留的生成文件、缓存、本地状态，或者其他未提交修改。干净重放（clean replay）要回答的是：摆脱当前目录里的这些状态后，同样的结果还能不能重现？

原文明确说，并非每项任务都需要完整重放。对复现要求较高的修改，它才是额外证据。

为减少审查者翻日志、拼上下文的成本，Kit 会生成结构化摘要，分别展示 Scope: PASS、Final verification: PASS、Broken baseline probe: FAIL、Fixed probe: PASS、Differential evidence: PASS，以及 Replay: REPRODUCIBLE 等结果。

这里最容易误读的是 Broken baseline probe: FAIL。旧版本上的探针失败，恰恰是预期结果；与修复后通过配对，才构成差分证据。

工具还可以导出证明材料并检查完整性，方便转交、归档和日后复核。这能帮助确认留存的材料是否变化，但作者没有详细介绍材料格式和校验机制，也没有把它定位为安全认证系统。

READY_FOR_REVIEW 只把结果交到审查门口

作者刻意限制了最终状态的含义：READY_FOR_REVIEW 表示配置好的机械检查关卡已经通过，可以交给人看。

机械检查通过，只能支持进入审查，不能替代工程判断。

它不保证代码一定正确，不保证安全，也不代表可以自动上线。审查者仍然要看实现是否符合系统需求，是否引入其他问题。

这套边界也体现在工具定位上。它不替代单元测试、集成测试、静态分析、安全审查和人工代码审查，也不会自动把一个弱测试变强。它能识别修复前后都通过这类弱证据，却无法理解所有项目的语义要求。

环境范围同样需要讲清楚：这是一个 Linux-first 的本地工作流，围绕本地项目仓库运行。Windows 和 macOS 不在已验证的 V1 环境内。原文没有给出这些平台上的兼容性结果，也没有提供可直接照抄的安装、配置或运行命令。

因此，它当前更像一个范围明确的验证工作流，而不是覆盖所有 Agent、平台和项目的通用可靠性承诺。

我的判断

我赞同作者把「测试是否有区分力」单独拿出来检查。日常审查里，大家很容易关注新增了多少测试、最终是否通过，却没有追问测试是否真的抓住了原来的行为错误。对 AI 编程来说，这个追问尤其有用，因为实现和测试可能由同一个 Agent 一起生成，两者可能一起偏离需求。

但「旧版失败、新版通过」也有前提：旧版失败必须来自目标 bug。

如果失败原因是依赖缺失、测试无法导入，或者环境配置不同，结果虽然也是 FAIL，却不能支持修复有效。原文没有交代 Kit 如何区分业务断言失败与环境失败，落地时需要核对这一点。

同样，同一份探针在两边运行，依赖、输入和配置也应具有可比性。否则，差异未必来自代码修复。差分验证让证据更强，却仍然需要人判断证据是否相关。

和常见的「先写失败测试，再修改实现」相比，这篇文章的测试思想并不新。它的实际贡献，是把这个要求连同路径边界、重放和材料归档，放进可检查的 Agent 工作流。团队如果已经严格执行测试先行和人工审查，新增收益可能主要来自流程留痕。

作者没有提供误判率、耗时开销或团队效率的对照数据。文中的收益判断仍属于实践经验和设计主张，不能据此断言采用 Kit 就能降低多少缺陷。

能拿来做什么

• 让 Agent 修复前端或 Node bug 时，在验收要求里写明：同一份回归测试需要在旧实现上失败、在新实现上通过，并保留两次结果及失败原因。不要只接收最终测试通过的截图或一句完成报告。
• 对范围明确的小修复，提前列出允许修改的源码和测试路径，审查时单独核对越界文件。如果 Agent 认为必须修改配置或其他包，应把原因说明白，方便判断范围扩张是否必要。
• 当验证可能依赖生成文件、缓存或未提交状态时，增加一次干净环境重放，并记录如何重现。测试通过和能够重现，应分别给出结论。
• 在 PR 审查中，把修改范围、最终验证、旧版探针结果和重放结果分开呈现。即使暂时不引入 Kit，也可以先采用这套证据结构，再由人检查需求覆盖和实现质量。