AI 找 bug ≠ 证明 bug 存在

Coding Agent 很擅长找出可疑代码。

给它一个代码仓库，它会愉快地花上一个小时追踪调用链、阅读测试、核对配置，然后给你列出一堆看起来有问题的地方。

麻烦的地方从这之后才开始。

假设 Agent 告诉我某段代码路径可能让应用程序处于非法状态。

这时候我真正知道的是什么？

我知道模型发现了某些值得检查的东西。

它可能是一个真正的 bug。也可能是在别处漏掉了某个 guard、理解错了代码的调用方式、假设了错误的配置，或者只是为一件根本不会发生的事给出了一个听起来很合理的解释。

我越来越不愿意把这两件事——发现一个可能的问题和证明问题确实存在——当作同一件工作来处理。

去问另一个模型并不是什么好答案。

如果 Claude 发现了一个 bug，另一个模型也同意 Claude 的看法，这确实有用。我可能会更早地去调查它。

但「同意」仍然不等于「证据」。

如果可能的话，我希望这个断言能经受住那些不在乎任何模型怎么想的东西的检验。

运行代码，复现行为，写一个因为被声称的原因而失败的测试，检查实际的配置。看日志，看依赖版本，看 Git 历史，看任何能直接回答这个问题的东西。

有时候这很容易。

如果 Agent 说某个函数在特定输入下会抛异常，那就用那个输入调用它。

有时候很难。架构问题和并发 bug 就是典型的例子。你可能只能验证这个断言的一部分，或者发现要复现它需要一些你无法确认的假设。

「无法验证」本身是有用的信息。

我宁愿把一个可疑的断言悬而不决，也不愿意因为一个模型听起来很自信就把它变成一个结论。

这也是我不认为静态分析和 Coding Agent 是竞争关系的原因。

当我们已经知道要找什么、并且能精确描述它的时候，静态工具非常好用。

Agent 有趣的地方在于它能注意到没人想过要写规则去捕获的东西。

这才是我想从它那里得到的。

让它去挖掘一个陌生的代码仓库，然后带着奇怪的问题回来。

然后让这些问题自己去争取进入 bug 列表的资格。

代码 Agent 能编写和检查的代码越多，这个区别就越重要。生成另外一千行代码已经非常便宜。仔细检查关于那一千行代码的某个微妙断言是否成立，则完全不是。

所以当一个 Agent 告诉我它找到了一个 bug，我想要的下一个问题不是：

「你有多自信？」

而是：

「我们怎么证明它？」