2026-10-28 每日思考
今天看到 Claude Code 团队那句"90% 代码由 AI 生成、合并量翻倍、回滚率下降 40%"，我盯着屏幕看了很久——不是因为数字漂亮，而是因为它把一件我一直含糊其辞的事说清楚了：AI 写代码的收益，不来自生成，来自闸门。
这半年我在做 AI 代码审查工具的 MVP，方向是安全漏洞和性能问题检测。说实话，做到现在最让我焦虑的不是模型识别不出漏洞，而是识别得太多。给一段两百行的业务代码，它能报出十几条"潜在风险"，其中真正值得修的可能只有两条。剩下的都是噪音——而噪音的代价不是浪费时间，是让人开始忽略告警。这在安全领域有个专门的词叫告警疲劳，我原以为那是 SIEM 系统的问题，没想到自己做的东西正在制造同一种病。
Claude Code 的回滚率下降 40% 这个数据，我猜它的来源不是"AI 写得更好"，而是"AI 写的代码被更严格地验证了"。多层 AI 审查加人工分级审批，本质上是把审查成本从人身上转移到了流程上。这给了我一个很实际的启发：我的 MVP 现在最大的问题可能不是检测能力，而是分级能力。一条 P0 的 SQL 注入和一条"这个循环可能可以优化"不该出现在同一个列表里，更不该用同样的视觉权重呈现给用户。我最近在试着给每条告警加一个"可复现性"维度——能不能给出具体的触发输入，能不能给出修复后的对比测试。凡是给不出的，直接降级或隐藏。宁可漏报，不可滥报，至少在 MVP 阶段是这样。
但我也在想另一面。Gartner 说只有 3% 的企业靠 AI 实现了降本增效，这个数字和 Claude Code 的成功并不矛盾——恰恰相反，它说明 Claude Code 是个例外，而例外之所以成为例外，是因为它有一整套 Harness。大多数团队买的是模型，缺的是 Harness。而 Harness 这种东西，恰恰是最难买、最需要自己长出来的。我做的审查工具，说到底也只是 Harness 里的一个零件，不是 Harness 本身。这个认知让我对产品的定位清醒了不少：不要卖"AI 帮你找 bug"，要卖"让你的 AI 生成代码能安全合入"。前者是功能，后者是流程。
一个可执行的建议给同样在做 AI 工具的人：先别急着提高召回率，先把告警的可信度做上去。用户对一个工具的信任，取决于它前十条输出里错了几条，而不是它总共能发现多少问题。至于预测——我猜未来一年内，"AI 代码审查"这个品类会从"检测工具"分化出"分级与仲裁工具"，因为当生成量翻倍之后，真正稀缺的不是发现问题的能力，而是判断哪个问题值得现在修的能力。