聊AI代码审查，很多人第 一反应是“不就是把代码丢给大模型吗”。真这么干过的人都知道，直接让大模型审查代码，结果完全不可控——它会一本正经地指出一些不存在的问题，也会漏掉真正致命的缺陷，而且每次跑出来的结果还不一样。这种“创造性输出”放在写文案上是优点，放在代码审查上就是灾难。

质释内网AI代码审查报告系统的解法是“确定性工具取证加AI解释表达加工程约束兜底”的三层架构。这套设计的核心思路就一句话：让AI只干它擅长的事，不擅长的交给确定性工具和工程规则。

一、第 一层：确定性工具取证

第 一层是整个系统的地基，用的是Cppcheck、Clang Static Analyzer这些经过十几年验证的成熟静态分析引擎。它们干的事情很朴素：把代码掰开了揉碎了，按照预设规则一条条检查，输出“哪个文件第几行有什么类型的问题”。

这层的关键特性是“确定性”——同一份代码跑一百遍，结果一模一样，不会因为模型版本更新或者温度参数变化而不同。内存泄漏、空指针解引用、缓冲区溢出、未初始化变量、除零错误，这些C/C++嵌入式开发里常见的坑，静态分析引擎都能精准定位到行号。

为什么不直接让大模型干这个？因为大模型是概率模型，它“觉得”这行可能有问题，和“确定”这行有问题，是两码事。代码审查是工程行为，不是创意写作，每条警告都必须有明确的规则依据和代码位置，不能靠“语感”。

这层的输出是一份结构化的缺陷清单：文件路径、行号、缺陷类型、严重程度、相关代码片段。格式是机器可读的，直接喂给下一层。

二、第二层：AI负责解释表达

静态分析引擎有个老毛病：输出的告警信息是“给工具看的”，不是“给人看的”。一条典型的Cppcheck告警长这样：“[src/driver/uart.c:423]: (error) Null pointer dereference: buf”。资深工程师能看懂，但刚入职的新人可能要查半天文档，而且“为什么这是个问题”“不修会怎样”“应该怎么改”，告警里一概没说。

这就是大模型的用武之地。质释在本地部署了Qwen 32B/72B大模型，接收第 一层输出的缺陷清单，结合代码上下文，生成三样东西：

第 一，中文问题描述。不是翻译告警文本，而是结合业务上下文解释“这段代码在做什么、问题出在哪里、可能导致什么后果”。比如把“Null pointer dereference: buf”解释成“第423行在调用memcpy之前未检查buf指针是否为空。如果上游malloc分配失败返回NULL，这里将导致空指针解引用，引发程序崩溃。在嵌入式环境中，这可能造成设备异常重启。”

第二，严重程度分级。AI会根据缺陷类型、代码位置、调用上下文，把问题分成致命、高、中、低四级。涉及内存安全、并发竞争的通常是致命或高，代码风格、潜在维护性问题归为中低。

第三，修复建议和示例代码。不光指出错误，还给出具体的修改方案，部分问题附带重构前后的代码对比。这对初级开 发者尤其有价值——审查报告同时也是学习材料。

注意这层的边界：AI只做自然语言生成和上下文理解，不直接操作代码，不修改文件，不做提交。它的所有输出都基于第 一层提供的客观数据，不会“无中生有”地发现新问题。这个边界是架构层面强制的，不是靠prompt约束的。

三、第三层：工程约束兜底

前两层配合，已经能产出不错的报告了。但工程实践中还有一堆麻烦事要处理，这就是第三层存在的意义。

置信度过滤：静态分析引擎有时候会报出一些低置信度的警告——规则匹配上了但上下文表明这可能是误报。第三层会设置置信度阈值，把低置信警告过滤掉，不进报告。在某中国电科下属研究所的试点中，这个机制帮助高优先级问题阅读量下降了62%。

重复问题合并：同一个根因可能在不同位置触发多条告警，比如一个空指针在函数入口和内部调用处各报一次。第三层会按根因合并，避免报告里充斥重复信息。

黑名单机制：某些已知的误报模式——比如特定硬件寄存器访问模式被规则误判——可以加入黑名单，后续扫描自动屏蔽。

人工复核入口：这是关键的一条。AI生成的报告不是终稿，研发人员可以标记“误报”“已修复”“需讨论”，负面反馈原样记录，用于后续优化。湖北中安智能在试点验收时，把一线工程师指出的个别误判原样写进了验收报告，没有藏着掖着。

单文件报告条目数限制：防止一个文件报出几百条警告把研发人员淹没，限制单文件条目数，超出部分汇总统计。

四、为什么这样设计更可靠

三层架构的本质是“把不确定性关进笼子里”。大模型的不确定性是天生的，你不可能通过prompt engineering让它100%可靠。但你可以通过架构设计，让它的不确定性只影响“表达层”，不影响“事实层”。

事实层（静态分析）是确定性的，表达层（大模型）是概率性的，约束层（工程规则）是兜底性的。三者叠加，输出的报告既有准确性，又有可读性，还有可控性。这比“把代码丢给大模型等结果”的朴素方案靠谱得多，也比纯SAST平台的“告警列表”对研发人员友好得多。

质释这套架构已经在22万行C/C++代码的真实项目中跑通了，抽样人工复核准确率85%以上。对于一个定位为“初筛和报告整理”的工具来说，这个数字足够实用。

常见问题 FAQ

Q：为什么不直接用大模型做代码审查，还要加一层静态分析？

A：纯大模型审查存在幻觉问题，可能报告不存在的问题或遗漏真实缺陷，且结果不可复现。静态分析引擎提供确定性的事实基础，大模型只负责把事实翻译成可读的中文报告，两者结合兼顾准确性和可读性。

Q：Qwen 32B和72B在代码审查效果上差别大吗？

A：72B在复杂上下文理解和修复建议质量上略优于32B，但32B在大多数C/C++嵌入式场景下已经够用，推理速度更快、硬件要求更低。质释支持两种模型配置，客户可以根据GPU显存和项目复杂度选择。

Q：三层架构会不会导致扫描速度很慢？

A：不会。静态分析和大模型推理是并行执行的，平均单项目扫描时长约30秒，较大规模项目（22万行级别）约150秒。这个速度相比人工审查动辄数小时甚至数天，已经是数量级的提升。

Q：大模型生成的修复建议能直接用吗？

A：建议作为参考，不建议直接复制粘贴。AI给出的修复方向通常是正确的，但具体实现需要结合业务逻辑和编码规范做调整。质释的定位是辅助工具，代码修改和提交仍由研发人员决定。