当AI写代码也制造Bug：来自百万次AI代码审查的反直觉发现

Graphite 联合创始人 Tomas Reimers 用真实数据讲述了一个反直觉的事实：AI 写代码越多，Bug 也越多。通过数百万次 AI 代码审查，他们不仅验证了“AI 能找 Bug”，更重要的是搞清楚了“哪些 Bug 值得让 AI 找、哪些评论人类根本不想看”。

AI 写代码的时代，Bug 不是意外而是必然

这场演讲从一个颇具自嘲意味的概念开始：AI powered entomology——用 AI 研究“虫子”。在这里，“虫子”不是昆虫，而是 Bug。Graphite 联合创始人 Tomas Reimers 解释说，Graphite 的核心产品 Diamond 是一个 AI 驱动的代码审查工具，可以直接连接 GitHub，在 PR 阶段发现问题。

项目启动一年后，他们观察到一个明显趋势：AI 生成的代码量在快速上升，但 Bug 的数量也同步增加。Tomas 的判断非常直接——这不是巧合，而是“part and parcel”，即同一件事的两个侧面。AI 大幅降低了写代码的成本，但并没有自动带来更高的正确性。

于是，一个关键问题摆在他们面前：如果 AI 正在制造 Bug，那它能不能也负责发现 Bug？这是 Graphite 最早的实验动机。他们做的第一件事非常朴素：把一个 PR 直接丢给 Claude，问一句，“你能找到这里的 Bug 吗？”

早期结果让他们“pretty impressed”。Tomas 分享了两个具体案例：一个是 AI 发现某些情况下返回了未实例化的数据库 ORM 类，会直接导致服务器崩溃；另一个是 Graphite 的机器人在 Twitter 上发现，前端在计算 border radius 时可能出现对负数做除法，从而导致页面直接 crash。这些都不是风格问题，而是真正会在生产环境出事的 Bug。Tomas 用一句话总结了这一阶段的结论：“So to answer the question， it turns out AI can find bugs.”

“我开玩笑的”：当 AI 评论开始让人抓狂

但紧接着，Tomas 就说了一句让现场笑出来的话：“I'm kidding.” 如果你真的用过 LLM 做代码审查，体验往往并不美好。

他们很快遇到了大量令人沮丧的评论，比如：建议把代码“更新成 authority 的做法”，而 CSS 根本不是这么工作的；或者“你应该把这段代码改回原来的样子，因为以前就是那样”。这些评论语法正确、语气专业，却在技术上站不住脚。

更糟的是，还有一类“政治正确型”评论：比如“你应该给这个类加个注释”“你应该把这段逻辑抽成一个函数”“你应该确保这里有测试”。Tomas 特别强调，这些话在技术上并没有错，但对开发者来说“really frustrating”。因为它们几乎可以出现在任何 PR 上，却并不真正帮助你判断这段代码有没有问题。

这一阶段带来的最大打击不是技术失败，而是信心崩塌。Graphite 团队意识到，问题可能不在于 AI 行或不行，而在于他们问错了问题。LLM 的本质是“模仿你让它做的事”。当你问它“一个代码审查里会出现什么评论”，它就会把人类写过的所有评论——包括有价值的和没价值的——一股脑吐出来。

于是，他们第一次明确提出了一个关键假设：代码审查评论本身是有类型的，而 LLM 对不同类型的评论，能力和可靠性完全不同。

用一万条真实评论，给代码审查“做分类学”

为验证这个想法，Graphite 做了一件很“工程师”的事：他们从自家代码库和多个开源项目中抽取了 10，000 条真实的代码审查评论，交给不同的 LLM，让模型尝试对这些评论进行分类。

结果显示，代码审查远比想象中复杂。除了明显的逻辑错误和 Bug，还有一大类评论被 Tomas 称为“tribal knowledge”——只有长期维护这个系统的人才知道的隐性规则。比如某个看似合理的改动，实际上会破坏一个历史兼容性约定。

另一大类，则是“代码整洁度和最佳实践”评论：加注释、补测试、抽函数、拆类型。这些正是开发者最容易被 AI 评论激怒的地方。Tomas 的判断非常坦率：这些评论“technically correct”，但并不等于“human that want to receive”。

经过多轮分析，他们逐渐收敛出一组结论：有些类型的评论，LLM 既能稳定生成，人类也确实愿意看到；而有些评论，即使人类经常写，也不意味着适合交给 AI 去自动化。

这是整场演讲中最重要的洞见之一：AI 代码审查的价值，不在于覆盖所有评论类型，而在于精准挑选“高信噪比”的那一部分。

一个残酷指标：只有一半的人类评论真的改变了代码

在对评论类型有了基本分类之后，Graphite 又引入了一个极其现实的衡量标准：一条评论，是否真的导致了代码修改。

他们统计发现，只有大约 50% 的人类代码审查评论，最终会引发实际的代码变更。这个数字本身就很残酷——意味着一半的评论，某种程度上都是“噪音”。

更有意思的是，当他们用同样的指标去评估 AI 评论，并不断优化提示词（prompt）后，结果逐步逼近人类水平。Tomas 提到，到 3 月份时，他们的系统已经达到了 52% 的修改触发率。“Which is to say，” 他解释道，“if you start to actually prompt it correctly you can get there.”

这并不是说 AI 已经全面超越人类审查，而是证明了一件更重要的事：在可量化的目标和合适的约束下，LLM 在代码审查这件事上是可以被工程化的。

Graphite 的更大愿景也在这里浮现：与其争论 AI 能不能取代人类，不如先搞清楚哪些 Bug 值得被系统性地捕获，哪些反馈真的能让代码变得更好。

总结

Tomas Reimers 的分享并不是一场“AI 万能论”的演讲，恰恰相反，它揭示了 AI 在软件工程中最真实的边界：AI 能发现 Bug，但前提是我们先理解什么是有价值的 Bug。通过对真实评论的分类、对结果的量化，以及对开发者体验的尊重，Graphite 给出了一个可落地的答案。对所有正在引入 AI 编程工具的团队来说，这个教训同样适用：不要问 AI 能做什么，而要先想清楚，人类到底想要什么。

关键词： AI代码审查， 大语言模型， Graphite， Claude， 软件工程

事实核查备注： 演讲者：Tomas Reimers；公司/产品：Graphite，Diamond；使用的模型：Claude；关键数字：10，000 条代码审查评论；约 50% 的人类评论会引发代码修改，AI 优化后达到约 52%；概念：AI powered entomology、代码审查评论分类、tribal knowledge