1. 一次双引擎代码审计实验的缘起

最近在做一个遗留的C++项目重构，代码库里有26个核心模块，历史包袱重，注释少，单元测试覆盖率也低得可怜。团队人手紧张，指望人工一行行去审计这些动辄几千行的模块，时间和精力成本都太高。正好手头有Claude和Codex这两个大语言模型的API权限，我就琢磨着，能不能让它们俩当一回“代码审计员”，帮我快速扫一遍这些模块，找出潜在的风险点和代码异味。

这个想法听起来挺美，但实际操作前我心里也没底。Claude和Codex虽然都顶着“代码生成/理解”的光环，但它们的底层模型、训练数据和设计侧重点完全不同。Claude（这里特指Claude 3系列模型，如Sonnet或Haiku）在长上下文理解和遵循复杂指令方面口碑不错；而Codex（作为GPT-3的后代，专精代码）在代码补全和语法理解上曾是标杆。让它们同时审计同一份代码，结果会高度一致，还是各有千秋？更重要的是，在它们意见相左的地方，我该信谁的？

于是，我设计了一个简单的实验：将这26个C++模块的源代码，分别提交给Claude（通过API调用Claude 3 Sonnet）和Codex（通过OpenAI的code-davinci-002端点，这是当时能用的最强代码模型），让它们针对每个模块输出一份审计报告，重点包括：内存管理风险（如指针使用、资源泄漏）、潜在的未定义行为、代码逻辑缺陷、性能瓶颈以及可维护性问题。然后，我将两份报告进行比对，看看它们在哪些问题上达成了共识，在哪些问题上产生了分歧。

结果出乎意料，又在意料之中。这26个模块，两个模型仅在10个模块的审计结论上达成了高度共识。剩下的16个模块，要么是其中一个模型发现了问题而另一个认为没问题，要么是对同一个代码段的风险等级评估截然不同，甚至对“这是否是个问题”都有争议。这个“共识率”远低于我的预期，也引发了我对当前AI代码审计工具现状、局限性以及如何有效利用它们的深度思考。下面，我就把这次实验的过程、发现和踩过的坑，毫无保留地分享出来。

2. 实验环境搭建与审计流程设计

要让实验结果有参考价值，首先得保证审计条件的一致性和可重复性。我可不希望因为提示词（Prompt）的细微差别或者上下文处理方式不同，导致结果出现偏差。

2.1 模型选择与API配置

我选择了当时（实验进行时）我认为最能代表两者能力的版本：

• Claude 3 Sonnet：通过Anthropic的官方API调用。选择Sonnet是因为它在能力、速度和成本之间取得了不错的平衡，并且支持长达200K的上下文，足以容纳大多数模块的代码。
• Codex (code-davinci-002)：通过OpenAI的API调用。这是OpenAI专为代码任务优化的模型，虽然现在有更新的GPT-4 Turbo等，但code-davinci-002在纯代码理解任务上依然非常扎实，且输出格式稳定。

注意：模型领域迭代极快。我实验时code-davinci-002尚可用，但现在OpenAI更推荐使用gpt-4o或gpt-4-turbo的代码理解能力。Claude方面，Opus可能比Sonnet更强大，但成本也更高。选择模型时，务必根据当前可用的模型、你的预算和任务需求来决定。

为了公平起见，我为两个模型设置了相近的API参数：

• 温度（Temperature）: 设置为0.1。这是一个很低的值，目的是让模型的输出尽可能确定和一致，减少随机性。代码审计需要严谨，不适合“创造性”发挥。
• 最大生成长度（Max Tokens）: 设置为2048，对于一份聚焦的审计报告来说基本够用。
• 其他参数：如频率惩罚（frequency_penalty）、存在惩罚（presence_penalty）均设为0，不做特殊调整。

2.2 核心：审计提示词（Prompt）工程

提示词是引导模型工作的“任务说明书”，它的质量直接决定审计的深度和广度。我花了大量时间迭代，最终固定使用下面这个结构化的提示词模板：

你是一个经验丰富的C++高级开发工程师和代码审计专家。请对以下C++模块代码进行全面的安全性和代码质量审计。 模块文件名：[此处替换为实际文件名，如 DataProcessor.cpp] 审计要求： 1. **风险分类**：请将发现的问题按以下类别归类： a) 内存安全（空指针解引用、内存泄漏、缓冲区溢出、使用后释放等） b) 并发安全（数据竞争、死锁、原子操作误用等） c) 逻辑缺陷（边界条件错误、循环错误、状态机错误等） d) 未定义行为（违反C++标准，行为不确定的代码） e) 性能瓶颈（低效算法、不必要的拷贝、重复计算等） f) 可维护性问题（过于复杂的函数、魔法数字、不清晰的命名、缺乏注释等） 2. **输出格式**：对于每个发现的问题，请严格按以下格式输出： - **问题类型**：[对应上述a-f类别] - **位置**：[函数名，行号范围，如 `processData(), lines 45-67`] - **代码片段**：[引用有问题的1-3行关键代码] - **风险描述**：[清晰描述问题是什么，以及可能导致的后果，如崩溃、数据损坏、安全漏洞等] - **修复建议**：[提供具体的代码修改建议或最佳实践] - **置信度**：[高/中/低，基于问题的明显程度] 3. **审计重点**：特别关注原始指针（raw pointer）的使用、资源管理（文件句柄、网络连接）、异常安全、以及标准库容器和智能指针的误用。 4. **如果未发现重大问题**：如果经过仔细审查，你认为该模块在以上类别中没有严重的或高风险的问题，请输出“**未发现高风险或严重问题**”，并可以简要列举1-2个可选的代码风格优化点。 以下是需要审计的C++代码： [此处粘贴完整的C++模块源代码]

这个提示词的关键在于：

• 角色定位清晰：让模型进入“专家”模式。
• 任务结构化：明确了审计的维度和分类，引导模型进行系统性思考，而不是零散地评论。
• 输出格式强制化：统一的JSON-like格式（虽然我用的是纯文本段落），极大方便了后续结果的自动解析和比对。
• 置信度评估：让模型自己对判断的把握度进行标注，这在处理分歧时尤为重要。
• “未发现问题”的出口：避免了模型在找不到问题时强行编造问题。

2.3 自动化流水线搭建

手动把26个模块的代码分别复制粘贴到两个平台是不现实的。我用Python写了一个简单的脚本，核心流程如下：

1. 遍历模块：扫描项目目录，找出所有.cpp和.h文件（将.h和对应的.cpp视为一个逻辑模块）。
2. 读取与清理：读取文件内容，移除UTF-8 BOM头等可能干扰模型的字符。
3. 调用API：将模块代码填入提示词模板，分别调用Claude和Codex的API。这里要处理好API速率限制和错误重试。
4. 结果保存：将每个模块的两个审计结果（原始文本）分别保存到以模块名和模型名命名的文件中。

踩坑实录：最初我试图让模型一次性审计整个文件列表，但发现当代码总长度超过模型上下文窗口时，模型会对后面的模块“视而不见”。后来改为每个模块独立调用一次API，虽然成本增加，但保证了每个模块都能获得完整的注意力。另外，API调用一定要做好异常处理和日志记录，网络超时、令牌超限都是常事。

3. 共识与分歧：26个模块的审计结果深度分析

审计报告全部生成后，真正的分析工作才开始。我手动（辅以一些文本处理脚本）对比了26个模块的两份报告，并将结果归纳为以下三类：

3.1 高度共识的10个模块：AI审计的“高光时刻”

在这10个模块上，Claude和Codex的审计结论高度一致，并且它们发现的问题，经我人工复核，绝大部分都是真实且重要的。这让我看到了AI辅助审计的巨大潜力。共识问题主要集中在以下几个经典场景：

1. 明显的资源泄漏：这是共识度最高的领域。例如，在一个文件处理模块中，两者都精准地指出了以下问题：

   FILE* fp = fopen("data.bin", "rb"); if (fp) { // ... 读取数据 ... if (error_condition) { return -1; // 错误返回，但没有 fclose! } fclose(fp); }

   共识结论：if (error_condition)分支直接返回，导致文件句柄fp泄漏。修复建议：两者都建议使用RAII对象（如std::fstream）或确保在所有退出路径上关闭文件。

2. 空指针解引用风险：对于未经验证就直接使用的指针解引用，两者几乎都能发现。

   void process(Data* data) { int value =>char buffer[64]; sprintf(buffer, "Result: %s", user_input); // 两者都警告：`user_input`过长会导致溢出。

   共识结论：使用sprintf存在缓冲区溢出风险。修复建议：使用snprintf或C++的std::string和std::ostringstream。

3. STL容器迭代器失效：在循环中修改容器（如std::vector）导致迭代器失效的经典错误。

   for (auto it = vec.begin(); it != vec.end(); ++it) { if (condition(*it)) { vec.erase(it); // 两者都警告：erase后，it失效，后续 ++it 行为未定义。 } }

   共识结论：在erase后未正确处理迭代器。修复建议：使用it = vec.erase(it)（C++11后）或使用remove-erase惯用法。

在这些共识案例中，AI审计的价值在于“查漏”。这些往往是开发者在紧张编码时容易忽略的、教科书式的错误。AI不知疲倦，能严格执行规则，非常适合做第一轮“地毯式”扫描。

3.2 存在分歧的16个模块：暴露AI的“认知边界”

分歧才是本次实验最有趣的部分。分歧主要分为两种：“有无”分歧和**“轻重”分歧**。

3.2.1 “有无”分歧：一个说有问题，一个说没问题

这种情况最让人纠结。例如，在一个网络通信模块中：

• Claude指出：某个使用recv的系统调用，返回值检查不完整，没有处理EINTR（系统调用被信号中断）的情况，在慢速或高负载网络环境下可能导致意外阻塞或数据接收不完整。
• Codex的报告：未提及此问题。

我查阅了代码和Linux手册页，Claude是对的。recv在阻塞模式下如果被信号中断，会返回-1并设置errno为EINTR，而原代码只简单判断了返回值是否小于等于0。这是一个隐蔽的健壮性问题。Codex可能因为它更侧重于“语法”和“常见模式”，对这种需要结合操作系统特定知识的边缘情况不够敏感。

另一个例子是关于异常安全：

• Codex在一个资源管理类中警告：构造函数中如果分配多个资源，其中一个失败，已分配的资源可能无法正确释放，违反了“构造函数不泄露资源”的原则。
• Claude的报告：认为该类设计基本合理，未将此列为严重问题。

经分析，Codex的警告是理论正确的，属于“最佳实践”层面的建议。但该类的实际使用场景中，资源分配失败概率极低，且项目当前的异常处理策略并未强制要求这种级别的安全。Claude可能更“务实”地评估了实际风险。

我的体会：当出现“有无”分歧时，提出警告的一方通常更值得深入审视。即使其警告过于严格（防御性编程），它也指出了一个潜在的改进点。而沉默的一方，可能意味着它“看不懂”更深层次的问题，或者其训练数据中缺乏类似案例。

3.2.2 “轻重”分歧：都发现了问题，但风险评估不同

更多的情况是，两者都发现了代码瑕疵，但对问题的严重性判断不同。

• 案例一：关于一个const正确性的问题。

  class Config { std::map<std::string, std::string> settings; public: std::string& getValue(const std::string& key) { // 返回非const引用 return settings[key]; // operator[] 是非const的，若key不存在会插入 } // ... };

  • Claude：归类为“可维护性问题”，置信度“中”。认为这破坏了const方法的语义，可能导致调用者意外修改配置，建议返回const std::string&并提供一个单独的setValue方法。
  • Codex：归类为“逻辑缺陷”，置信度“高”。认为这可能导致严重的状态不一致，如果调用者误以为这是一个只读操作，而实际上可能改变了settings映射表的内容。

  我认为Codex的评估更准确。这不仅仅是个风格问题，它引入了潜在的数据竞争风险（如果多个线程调用）和难以调试的状态变更。

• 案例二：关于一个循环中的效率问题。

  for (int i = 0; i < largeVector.size(); ++i) { // 循环体不修改 largeVector }

  • Claude：归类为“性能瓶颈”，置信度“低”。建议将largeVector.size()的调用提到循环外，避免每次迭代都调用（尽管对于std::vector，size()是O(1)的）。
  • Codex：未将其列为单独的性能问题，仅在“可维护性”中提及代码风格。

  在这个案例中，Claude的建议有些“教条化”。现代编译器优化下，这种写法通常不会产生额外开销。Codex的处理反而更贴合实际。

分歧的根源，我推测在于：

1. 训练数据差异：Claude的训练数据可能包含更多关于软件工程、设计模式和最佳实践的讨论；而Codex的训练数据更集中于GitHub上的实际代码，可能更“接地气”，但也更“容忍”一些常见的非最优写法。
2. 模型设计目标：Claude被设计为更善于理解和遵循复杂的指令，可能更倾向于给出全面、谨慎（有时偏保守）的分析；Codex的核心目标是代码补全和生成，其“理解”可能更偏向于代码的语法和常见模式，对深层次设计问题的敏感性可能稍弱。
3. 上下文理解深度：对于需要联系整个类、甚至多个模块的上下文才能判断的问题，Claude的长上下文能力可能让它看到了更完整的图景，从而做出不同判断。

4. 从分歧中学习：如何有效利用AI进行代码审计

这次实验让我明白，把AI审计结果当作“标准答案”是危险的，但完全忽视它又是愚蠢的。关键在于如何作为一个有经验的工程师，去驾驭和仲裁AI的输出。

4.1 建立你的“仲裁”流程

面对两份不同的审计报告，我总结了一套处理流程：

1. 优先处理共识问题：对于两者都指出的问题，除非你有非常充分的理由，否则应该优先修复。这是AI审计价值最确定的部分。
2. 深度审查“有无分歧”：
   • 对于AI报告了问题而另一个没报告的，重点审查。这往往是AI发现了你（或另一个AI）的盲点。仔细阅读其描述和推理，结合代码上下文和领域知识判断。
   • 对于复杂或模糊的问题，不要只看AI的结论，要追问。你可以把有分歧的代码片段，连同AI的质疑，重新组织成一个更具体的Prompt，去“询问”另一个模型，甚至换第三个模型（如GPT-4）来获得第三视角。例如：“关于这段代码中的recv调用，模型A认为需要处理EINTR，模型B未提及。请专门分析此处是否存在信号中断处理缺失的风险，并解释原因。”
3. 理性看待“轻重分歧”：
   • 将风险评估与你的项目实际情况结合。一个被AI标为“高”风险的问题，在你的特定业务逻辑和运行环境下可能并不关键，反之亦然。
   • 建立自己的风险矩阵。例如，对于安全关键系统，任何内存安全问题都必须视为“高”；对于内部工具，性能问题的优先级可以放低。

4.2 提升审计效果的实用技巧

1. 分而治之：不要一次性审计整个巨型文件。按功能、按类、甚至按函数进行拆分审计，给模型更聚焦的上下文，效果往往更好。
2. 提供更多上下文：有时AI误判是因为缺乏背景。在Prompt中，可以简要说明模块的职责、关键数据结构的意义，甚至提供调用示例。这能帮助AI做出更符合场景的判断。
3. 迭代式审计：第一轮审计后，对发现的问题进行修复，然后将修复后的代码再次提交审计。这不仅能验证修复是否正确，有时AI还能在“更干净”的代码基础上发现之前被噪音掩盖的更深层问题。
4. 结合静态分析工具：AI审计和传统静态分析工具（如Clang-Tidy, Cppcheck, SonarQube）是绝配。静态分析工具擅长基于规则的模式匹配（如检查未初始化的变量），而AI能理解一些更“语义化”的问题。让它们并行运行，取长补短。
5. 人工复核不可替代：AI是强大的助手，但不是法官。最终的决策权必须掌握在熟悉代码和业务的工程师手中。AI的产出是“疑点列表”，而工程师的工作是“调查取证”和“最终判决”。

4.3 当前AI代码审计的局限性

通过这次实验，我也清晰地看到了局限性：

• “知识”截止日期：模型训练数据有截止日期，对于C++20/23的新特性、新库，或者你们项目内部特有的框架和约定，AI可能不了解或理解有偏差。
• 缺乏运行时信息：AI只能分析源代码文本，无法获知程序的运行时状态、数据流的具体值、外部依赖的版本等。对于需要动态分析才能确定的问题（如某个条件是否真的可能触发），AI只能做出概率性猜测。
• 对业务逻辑的理解薄弱：AI很难判断一段复杂的业务逻辑是否正确。它只能检查出违反通用编程规则的部分，但无法判断“这个折扣计算算法是否符合商业规则”。
• 成本与效率的平衡：高质量模型的API调用不便宜，审计大量代码需要成本。需要权衡投入产出比，通常建议在关键模块、核心路径或重构前期使用。

让Claude和Codex同时审计26个模块，只在10个上达成共识，这个结果最初让我有些失望，但深思后却觉得无比真实。它恰恰反映了当前AI在代码理解领域的现状：强大但并非全能，敏锐但也存在盲区。

共识的10个模块，证明了AI在捕捉经典、模式化代码缺陷方面已经可以成为可靠的“第一道防线”。而那分歧的16个模块，则像一面镜子，既照出了不同AI模型认知的差异，也照出了我们作为工程师需要填补的空白——即运用领域知识、系统思维和工程判断力，去甄别、验证和决策。

这次实验之后，我调整了团队的工作流程。对于新提交的代码，我们会用静态分析工具做基础扫描，对于重构或历史核心模块，则会引入AI审计作为深度审查的补充。我们不再追求AI给出“标准答案”，而是把它看作一个拥有独特视角、不知疲倦的“超级实习生”。它的报告需要导师（也就是我们）的审阅和指导。

最终，代码的质量责任，依然牢牢地掌握在编写和评审它的人手中。AI工具的价值，在于放大优秀工程师的能力，而不是替代他们的思考。用好它，关键不在于寻找那个“最准”的模型，而在于建立一套如何与这些模型协作、如何批判性吸收其意见的工作方法。这条路，我们才刚刚开始探索。