AI Code Review 的分水岭：编译级程序理解

智能体提供给大模型的信息，直接决定了大模型能够分析到什么。不同的AI Code Review 智能体方案，即使采用相近的大模型，在面对复杂商用代码时，审查效果仍可能存在明显差距。有的智能体方案仅靠代码检索补充源码，模型仍需自行判断条件编译、扩展语法和跨函数数据传播；有的智能体方案接入通用开源code graph，也往往只能获得非编译环境信息，难以适配复杂编译环境并提供完整的缺陷路径。而成为AI Code Review 的技术分水岭的，正是编译级程序理解，CodeHawk 在这方面有着绝对的优势。

软安AI Code Review工具CodeHawk 采用“LLM + SAST”协同架构。软安自研编译型静态分析引擎“软安静兮”既向大模型提供函数模型、调用图和真实编译语义，支持其主动发现业务逻辑等复杂问题；也输出候选缺陷及证据链，由大模型进行二次验证。两类结果最终统一形成 CodeHawk 的审查结论。

其中，编译型静态分析主要从两个层面增强 AI Code Review：

1. 还原真实程序语义，帮助大模型正确理解复杂、非标准的商用代码；

2. 追踪跨文件、跨函数的程序路径，提供修改点之外的深层缺陷线索。

软安静兮作为在C/C++技术能力最强的国产化静态代码分析工具，

决定了软安AI Code Review工具CodeHawk的上限很高。

---

一、还原程序语义，让大模型真正理解商用代码

商用软件中广泛存在宏定义、条件编译、厂商私有关键字、专用 DSL 和编译器扩展选项。这些代码可以被特定工具链识别，却未必符合标准 C/C++ 语法。若分析前端无法正确处理，影响的不只是一处语法解析，还可能导致后续调用关系和数据流分析中断。

案例一：规整厂商私有 DSL，提取有效业务逻辑

在 DSP、ASIP 等专用处理器开发中，Chess、Noodle 等工具链可能使用标准 C/C++ 之外的私有语法。例如：

promotion signed int mulh(signed int, signed int)    property(mulhs) = w32 mulh(w32,w32);

其中包含类型提升、指令映射等厂商私有描述。通用分析前端可能在此中断，大模型也可能将其误判为语法错误。

软安静兮原生适配了Green Hills，HighTec，Tasking，Renesas，TI 等几乎全部嵌入式编译器。可以对这类 DSL 进行针对性规整，提取出对程序分析有价值的标准函数、类型和调用关系；对与业务分析无关的底层指令描述，则在保留必要语义的前提下安全剔除。大模型由此看到的是清晰的程序结构，而不是难以解释的私有语法。

int mulh(int, int);

这一过程并非简单忽略语法错误，而是从厂商私有描述中提取对程序分析有价值的标准语义。经过处理后，代码才能继续参与 AST、控制流和调用关系分析，大模型也能够基于清晰的函数声明和程序结构理解后续业务逻辑。

案例二：适配真实编译选项，打通从工程解析到越界识别的分析链路

在真实 C/C++ 工程中，代码往往包含特定编译器支持的扩展语法。例如，部分 Windows 项目会使用 Microsoft 风格的 __int64 等非标准语法，Clang 等编译前端需要启用 -fms-extensions 兼容选项才能正确解析。

本案例的底层函数 write_buffer() 正是如此。如果分析工具不支持项目实际使用的编译选项，该函数便无法被正确解析，分析构建的调用图和数据流也会在这里中断。即使上层代码存在错误参数，工具也难以继续追踪它在底层产生的影响。

软安静兮适配 -fms-extensions 编译选项，能够按照工程的真实编译方式解析底层代码，并还原出完整的参数传播路径：

session_buf[32] → 调用 open_session() 时传入 buf_size=256 → 参数经 open_session()、process_config() 逐层传递 → write_buffer() 将 256 视为缓冲区容量 → 写入超过数组的实际边界 → 触发栈缓冲区溢出。

问题的根源在上层调用处：实际缓冲区只有 32 字节，传入的容量却是 256。真正执行越界写入的代码则位于多层调用之后的 write_buffer()。当写入位置超过 session_buf[31]，程序便开始破坏相邻的栈内存，可能导致程序崩溃或产生更严重的安全风险。

这个案例体现了真实编译配置对静态分析的重要性。支持 -fms-extensions 并不只是为了消除一处语法错误，而是为了让底层函数进入程序模型，从而构建正确的调用关系和参数传播上下文。基于这条完整链路，软安静兮引擎才能从上层错误的容量参数一路追踪到底层写入操作，形成明确的缓冲区溢出线索，再交由大模型结合代码变更进行验证和解释。

---

二、追踪程序路径，让大模型发现修改点之外的深层缺陷

完成程序语义还原后，编译型静态分析引擎还可以进一步构建 AST、控制流、调用关系和跨过程数据流。

这项能力对于 AI Code Review 尤为重要。真实缺陷往往不会直接出现在代码修改位置，而是由某个参数、返回值或宏定义经过多个文件和函数传播，最终在底层实现中触发。

如果只向大模型提供变更代码及其附近文件，模型需要自行搜索相关实现、判断有效编译分支并推测数据传播路径。路径越长、工程越复杂，遗漏关键关系的可能性就越高。

软安静兮编译型静态分析引擎可以先定位这些深层关联，再将缺陷触发条件、传播路径和关键代码作为高价值上下文提供给大模型。

案例三：结合真实宏配置，追踪跨函数除零风险

在该案例中，read_config_threshold() 的返回结果由条件编译宏 SOD 决定。

软安静态分析引擎可以读取该文件对应的实际编译命令，确认当前构建已经定义 SOD。预处理阶段据此排除不参与本次构建的代码分支，保留真实生效的实现，并生成与实际构建场景一致的 AST。

在当前宏配置下，read_config_threshold() 返回 0。这一结果继续经过多层函数调用传播，最终影响 calculate_aggregated_metric() 的返回值，使 aggregated_metric 可能为 0：