2026-09-14 每日思考

今天读到 Linux 内核开发者那句"AI 找 bug 挺准，但代码都是我重写的"，我盯着屏幕愣了几秒——因为这正是我这几个月在 AI 代码审查工具 MVP 里反复撞的墙。

一开始我的假设很朴素：既然模型能定位安全漏洞和性能问题，那让它顺手给出修复补丁，不就闭环了？于是我花了两周把"检测 + 修复建议"做进同一条流水线。结果是灾难性的。检测环节的召回率还不错，能捞出一批真实的注入点和 N+1 查询；但一旦让它生成修复，代码就开始"惨不忍睹"——它会把一个参数化查询改对，却在旁边顺手删掉一个看似冗余的错误处理分支；它会为了消掉一个告警，引入一个更隐蔽的竞态。23 个补丁、90% 提速这种数字很诱人，但没人告诉你那 23 个补丁背后人类重写了多少行。

这件事让我重新理解了一个被 AI 热潮盖住的常识：检测和修复是两种完全不同的认知任务。检测是模式匹配，模型在大量历史漏洞上有统计优势；修复是约束满足，它要在"不破坏现有行为"的隐式约束下做局部改动，而这些约束绝大多数根本没写在代码里，散落在 commit message、issue 讨论、甚至某个离职工程师的脑子里。模型看不到这些，自然只能给出"看起来对"的补丁。

所以我现在把产品方向掉了个头：检测做深，修复做"可解释的候选"而非"最终答案"。具体做法是，每条漏洞告警必须附带三样东西——触发路径、为什么这是问题、以及一个明确标注"需人工确认"的修复方向，而不是一段可以直接 merge 的 diff。这听起来像是退步，但我觉得这才是对的：AI 的价值不是替人做决定，而是把人的注意力精确地引导到真正需要判断的地方。

如果让我给一个预测：未来一年，"AI 代码审查"这个品类会分裂成两拨——一拨继续卷"自动修复率"这种虚荣指标，另一拨老老实实做"高精度检测 + 低置信度修复提示"，后者会活得更久。我赌后者。毕竟内核开发者已经用脚投票了：他们要的是准的 bug 报告，不是漂亮的补丁。

可执行的建议给同行：如果你也在做 AI 辅助编码，先把"生成"和"验证"的成本分开算账，别让 demo 里的自动修复掩盖了生产里的重写成本。