2026-10-12 每日思考

今天读到那项覆盖数百家公司的研究——"AI 编程智能体生成了更多代码，但并没有生成更多软件"——我盯着屏幕愣了一会儿，因为它几乎是我这几个月做 AI 代码审查工具时反复撞上的那堵墙的学术版本。

我的 MVP 做的是安全漏洞和性能问题检测。最初我以为难点在模型能力：能不能准确识别注入、越界、竞态。做到第二个月我发现，真正的瓶颈根本不在检测，而在"检测结果的处置"。一个中等规模仓库，一次全量扫描能报出几百条问题，其中大量是低置信度、上下文相关、需要人来判断"这里到底算不算问题"的条目。我把误报率从 40% 压到 15%，团队的实际处理速度并没有变快——因为剩下的 15% 每一条都需要人打开代码、读上下文、决定改还是忽略。审查吞吐没变，产量就不会变。

这和研究结论完全吻合：AI 把生成成本打到接近零，但审查成本是人力绑定的，它不随生成速度下降。更糟的是，生成越多，待审队列越长，审查反而成了新的拥塞点。QGIS 今天禁用 AI 贡献，表面是许可证和溯源问题，底层其实是同一个算术：维护者的审查带宽是有限的，无限制的 AI 生成贡献只会把成本转嫁给少数几个能合并代码的人。repowise 把代码健康评分做成 MCP 服务，思路是对的——把"判断"前置成机器可读的信号，减少人需要亲自读的代码量。但这也只是把审查前移，没有消除它。

所以我对自己的工具有了一个不太舒服的判断：如果它只是"报更多问题"，那它就是在给审查队列添堵。真正有价值的方向是反过来——不是多报，而是少报，且每条都带上足够的上下文和修复建议，让人能在一分钟内决定处置。也就是说，工具的 KPI 不该是"发现漏洞数"，而该是"人处理每条告警的平均耗时"。这个指标难测、不性感，但它才是产量公式里真正的那一项。

给同行的建议：如果你的 AI 工具在提升"生成量"，先问一句它把审查成本推给了谁。预测：未来一年，"审查吞吐"会取代"生成速度"成为 AI 编程工具的核心卖点，而能给出可解释、可批量处置结论的工具会赢。