2026-09-15 每日思考

今天 F-Droid 那条"AI 辅助开发占比有多高"的统计，让我盯着自己的项目看了很久。

我做的是一个 AI 代码审查工具，MVP 阶段，重点查安全漏洞和性能问题。从第一天起，我的假设就是"审查对象是人写的代码"。但 F-Droid 的抽样、微软把 Rust 提为一级语言并计划用 AI 重写整个 C/C++ 代码库——这两件事合起来说明，我的审查对象正在变成"人和模型混合写的代码"，而且模型占比会越来越高。

这不是换个数据源那么简单。人写的漏洞有鲜明的分布特征：边界条件漏判、错误处理偷懒、凭经验复制的危险模式。模型写的代码不一样。它很少犯低级语法错，但会系统性地产生"看起来对"的代码——幻觉出来的 API、看似合理实则错误的并发假设、在训练数据里高频出现但在当前上下文里完全不成立的模式。更麻烦的是，这些错误在同一个模型的不同次生成里高度相关，你审查一百个文件，可能看到的是同一个思维盲区的二十种变体。

这意味着传统基于规则的静态分析会大面积失效，因为模型生成的错误不在规则库里。而基于 LLM 的审查又有个循环依赖：用模型审模型，两者的盲区可能重叠。我现在的想法是走"交叉验证"路线——用不同厂商、不同训练数据的模型互相审查，把两个模型都认为有问题的片段当作高置信度信号，只在一个模型报警的地方降级为提示。代价是成本翻倍，但至少能打破单一模型的系统性偏差。

另一个让我不安的点是审查的时机。人写的代码在提交时审查是合理的，因为作者会停顿、会思考。模型生成的代码是流式的，等它写完一个几百行的文件再审查，很多错误已经嵌进了整体结构里，改起来等于重写。也许审查应该前移到生成过程中，在模型每完成一个逻辑单元时就介入——但这要求审查工具能理解"逻辑单元"的边界，而这件事本身就没有通用解。

短期预测：未来一年内，"AI 生成代码的审查"会从一个小众需求变成基础设施级需求，微软、GitHub 这类平台会把它内建进 CI 流程。独立工具的生存空间在于做平台不愿意做的脏活——比如跨模型交叉验证、针对特定模型家族的错误模式库。我打算先把"模型生成代码的错误分类"这件事做扎实，哪怕只覆盖两三个主流模型，也比泛泛地说"我能审 AI 代码"有用。

先记录在这里，三个月后回头看准不准。