1. 项目概述：当两个AI审计员意见相左时

最近在折腾一个老旧的C++项目，里面堆了二十几个模块，代码风格各异，历史包袱重得像座山。为了系统性地清理潜在的安全漏洞和代码坏味道，我决定不走寻常路，同时请来了两位“AI审计员”——Anthropic的Claude和OpenAI的Codex，让它们对全部26个模块进行一轮独立的代码审计。这个想法听起来很酷，但结果却出乎意料：这两位在业界都颇有声誉的“专家”，只在区区10个模块的审计结论上达成了一致。剩下的16个模块，它们要么一个报高危另一个说安全，要么对同一个问题的严重性评级天差地别。

这可不是简单的“1+1=2”的游戏。当两个智能体对同一段代码给出不同诊断时，作为开发者，我们该信谁？是Claude过于保守，还是Codex太过激进？又或者，这恰恰揭示了当前AI辅助代码审计工具在理解复杂上下文、识别逻辑漏洞方面的局限性？这次实验远不止是一次工具对比，它更像是一次对AI代码理解能力边界和协同工作模式的深度探索。如果你也在考虑将AI引入你的开发或安全流程，尤其是面对C/C++这类底层且易出错的系统时，接下来的内容或许能帮你避开不少坑。

2. 实验设计与环境搭建：构建公平的AI审计擂台

要让Claude和Codex同台竞技，首先得搭建一个可控、可复现的测试环境。核心目标就一个：尽可能消除外部变量干扰，让两者的差异只体现在模型本身的“认知”和“判断”上。

2.1 审计对象：26个C++模块的典型“症状”

我的目标项目是一个中等规模的网络服务后端，包含26个独立的动态链接库（DLL）或静态库模块。这些模块堪称C++项目“坏习惯”的博物馆：

• 内存管理混乱：手动new/delete与std::unique_ptr混用，部分地方甚至存在明显的所有权模糊。
• 输入验证缺失：大量用户输入、网络数据包解析函数缺乏边界检查和类型验证。
• 并发安全漏洞：多个全局或静态变量在多线程环境下被访问，但保护措施不一致，有的用std::mutex，有的用临界区，有的干脆没保护。
• 过时或危险的API：如使用strcpy,sprintf等不安全的C字符串函数，以及一些平台相关的非安全函数。
• 资源泄漏风险：文件句柄、网络套接字、GDI对象等在异常路径下可能未正确释放。

选择C++是因为它足够“危险”——手动内存管理、指针运算、缺乏运行时安全检查，使得它既是性能的利器，也是漏洞的温床，非常适合检验AI审计工具的深度。

2.2 工具链与提示词工程：统一审计标准

我并没有使用那些集成了AI的复杂IDE插件，而是选择了最“原始”也最可控的方式：通过它们的API进行交互。

1. 环境隔离：为Claude（我使用的是Claude 3 Opus API）和Codex（通过OpenAI的gpt-3.5-turbo模拟其代码补全和分析能力）分别创建独立的Python脚本。确保网络代理稳定，避免因网络抖动导致的分析中断或结果不完整。
2. 上下文窗口管理：C++模块大小不一，有的超过千行。我采用了“分而治之”的策略：对于大文件，按逻辑功能（如类声明、类实现、工具函数）进行切割，分次发送。每次发送的代码片段都附带清晰的上下文说明，例如“这是模块DataParser中负责解析网络报文的核心类PacketDecoder的定义和实现部分”。
3. 核心提示词设计：这是保证审计方向一致的关键。我设计了一套结构化的提示词模板：

   你是一名专注C/C++代码安全审计的专家。请分析以下代码片段，严格按以下格式输出： 1. **潜在安全问题**：列出所有你发现的安全漏洞或风险（如缓冲区溢出、整数溢出、空指针解引用、资源泄漏、竞态条件等）。对每个问题，请说明： - 风险类型（如CWE-ID） - 代码位置（行号或函数名） - 简要原理 - 严重性评级（高危/中危/低危） 2. **代码质量与可维护性问题**：列出代码坏味道、潜在bug或可改进点（如魔法数字、过时API、重复代码、复杂度过高等）。 3. **修复建议**：针对每个“潜在安全问题”，提供具体的代码修复示例。 代码片段：[此处粘贴代码] 模块名称：[模块名]

   这个模板强制AI进行结构化输出，便于后续的自动化解析和对比。注意：我明确要求了“CWE-ID”和“严重性评级”，这是将AI的定性判断向行业标准靠拢的重要一步。

2.3 结果收集与预处理

审计完成后，我得到了52份报告（26个模块 × 2个AI）。我写了一个Python脚本，将这些半结构化的文本报告解析成JSON格式，关键字段包括：模块名、问题描述、问题类型、位置、严重性、AI来源。

接下来，最棘手的一步来了：如何定义“共识”？我不能简单地进行字符串匹配，因为两个AI对同一个问题的描述可能用词不同。例如，Claude可能说“第45行存在可能的缓冲区溢出，因为strcpy的目标缓冲区大小未验证”，而Codex可能说“使用不安全的strcpy函数，可能导致内存越界写入”。在人类看来，这显然是同一个问题。

我的处理方法是：

1. 问题聚类：基于问题发生的代码位置（函数名和行号范围）进行初步分组。
2. 语义相似度判断：对同一位置下不同AI的问题描述，使用句子嵌入模型（如all-MiniLM-L6-v2）计算余弦相似度。如果相似度超过一个阈值（我设定为0.75），则认为它们在描述同一个问题。
3. 人工复核：对于聚类和相似度判断后的边缘案例，进行最终的人工裁定。这一步虽然费时，但保证了对比基准的准确性。

经过这一套流程，我才得以清晰地统计出，在哪些模块、哪些具体问题上，两位“AI审计员”是英雄所见略同，又在哪些地方分道扬镳。

3. 审计结果深度对比：共识、分歧与盲区

统计结果直观但震撼：在26个模块中，Claude和Codex对所有问题的判断完全一致的模块只有10个。在剩下的16个模块中，共发现了58个被至少一方标记的安全问题，其中仅有22个问题双方都认可（即在这10个模块之外，还有其他模块中存在部分共识）。这意味着，有36个安全问题（占比超过62%）只被其中一个AI发现，而另一个要么认为不是问题，要么给出了完全不同的评级。

3.1 “英雄所见略同”的10个模块：经典漏洞的共识区

双方达成共识的模块和问题，主要集中在以下几类“经典”且特征明显的漏洞上：

1. 不安全的C标准库函数：对strcpy、sprintf、gets等的使用，双方均能100%识别并标记为高危。这类问题模式固定，在训练数据中极为常见。
2. 明显的空指针解引用：在解引用指针前没有任何nullptr检查的代码，例如if (p) { ... }缺失的情况。双方都能准确识别。
3. 简单的资源泄漏：在函数中打开了文件或分配了内存，但在所有返回路径上（特别是错误处理分支）都缺少对应的关闭或释放操作。这类问题逻辑清晰，双方判断一致。
4. 整数溢出/下溢的典型模式：如对用户控制的整数进行算术运算（size = width * height）而未检查溢出，或循环中使用int i与size_t count比较。只要模式典型，双方都能发现。

注意：即使在共识区，两个AI给出的修复建议也常有细微差别。例如，对于strcpy，Claude倾向于推荐strncpy_s（微软安全版本）并详细说明缓冲区大小参数，而Codex可能更倾向于推荐C++的std::string或std::copy。这反映了它们背后训练数据源的差异。

3.2 “针锋相对”的16个模块：分歧背后的逻辑

分歧是更有趣的部分。我将主要分歧归纳为三大类：

3.2.1 漏洞存在性判断分歧这是最根本的分歧。典型案例如下：

• 模块ConfigLoader：有一段代码从配置文件中读取一个字符串列表，预分配一个固定大小的二维数组（char arr[10][256]）来存储。Claude认为这是“潜在的缓冲区溢出，如果配置文件行数超过10或某行长度超过255字节”。Codex则认为“代码逻辑正确，假设配置规模可控，不属于安全漏洞”。
  • 分析：Claude采取了防御性编程和最小信任原则的视角，不信任外部输入。Codex则更倾向于基于现有代码上下文进行字面推理，因为它没有看到动态分配或明显的越界写入，所以认为假设成立。这体现了AI对“潜在”风险容忍度的不同。

3.2.2 漏洞严重性评级分歧双方都认为有问题，但对问题严重程度的判断不同。

• 模块ThreadPool：一个工作线程在特定条件下会访问一个可能已被主线程析构的全局队列指针。Claude将其标记为高危（“可能导致段错误或未定义行为，影响服务稳定性”）。Codex则标记为中危（“在特定竞态条件下发生，概率较低，且可能仅导致线程崩溃而非整个进程”）。
  • 分析：Claude似乎更关注漏洞可能造成的最坏影响，而Codex则综合考量了触发条件和影响范围。这类似于安全专家中的“悲观派”和“务实派”之争。

3.2.3 问题类型归类分歧同一个代码缺陷，被归入了不同的弱点类别。

• 模块LogWriter：一个日志写入函数使用fprintf，但格式字符串部分由外部输入控制。Claude将其归类为**“不安全的格式化字符串（CWE-134）”。Codex则主要关注其可能导致的“缓冲区溢出（CWE-120）”**，因为过长的输入可能撑爆内部缓冲区。
  • 分析：这段代码实际上同时存在两种风险。这反映出AI在分析复杂漏洞时，可能会抓住其中一个最明显的特征进行归类，而忽略了其他关联风险。人类的审计员通常会更全面地列出所有相关CWE。

3.3 共同的“盲区”：AI审计的当前局限

更有意思的是，在我后续的人工深度审计中，发现了3个真实存在的中危漏洞，但Claude和Codex均未报告。这揭示了当前大语言模型在代码审计上的一些共性局限：

1. 跨模块数据流分析能力弱：一个模块A接收输入，进行初步检查后，将数据指针传递给模块B。模块B信任该指针，未做二次检查。这种跨模块的信任传递漏洞，需要理解整个项目架构和数据流图，而仅分析单个模块代码片段的AI很难捕捉。
2. 对业务逻辑漏洞不敏感：例如，一个支付校验函数，其逻辑错误可能导致金额计算错误。这类漏洞高度依赖业务上下文，而纯代码分析难以发现逻辑谬误。
3. 对现代C++安全特性的误判：有一段代码使用了std::shared_ptr的别名构造函数（aliasing constructor），其所有权语义较为复杂。两个AI都未能准确理解其生命周期，错误地提示了“可能的空指针解引用”或“内存泄漏”。

4. 分歧根源探究与技术反思

为什么会出现如此大的分歧？这不仅仅是模型差异的问题，更深层地反映了AI代码理解的本质。

4.1 训练数据与知识截止时间的差异

• Claude：由Anthropic训练，其训练数据可能更侧重于对话、推理和安全对齐，在代码安全模式上可能吸收了更多来自安全研究论文、CVE详情页、OWASP指南等“防御性”知识。其风格更谨慎。
• Codex/GPT系列：基于更广泛的GitHub代码进行训练。这既是优势也是劣势：优势是见过的代码模式极多；劣势是GitHub上本身就有大量包含漏洞的代码，模型可能学会了这些“坏习惯”，甚至将某些不安全模式视为“常见做法”而降低其风险评级。它的风格可能更“经验主义”。

4.2 模型推理机制与“注意力”的不同

即使提示词相同，不同的模型架构（如Transformer的层数、注意力头数）会导致它们关注代码的不同特征。一段复杂的指针运算代码，一个模型可能更关注指针的声明和初始化，另一个则可能更关注其使用和传递的路径。这种“注意力焦点”的差异，直接导致了问题发现的不同。

4.3 对“上下文”依赖程度的差异

一些分歧源于对“假设”的依赖。例如，如果代码注释里写着“调用者保证输入有效”，一个模型可能选择相信注释（Codex有时表现出这种倾向），从而放过检查；另一个模型（如Claude）可能坚持“从不信任输入”的原则，忽略注释仍报出问题。AI如何权衡代码文本、注释和通用安全原则，是一个复杂的未决问题。

4.4 提示词工程的极限

我的提示词已经尽可能详细，但依然无法完全统一两个模型的“思维框架”。例如，“严重性评级”本身就是一个主观判断。我无法通过提示词提供一个绝对客观的“高危/中危/低危”判定矩阵给AI，因为这需要结合具体的部署环境、数据敏感性等外部信息，而这些信息很难在提示词中完整传达。

5. 实践指南：如何有效利用AI进行代码审计

基于这次实验的经验和教训，我总结了一套将AI融入实际代码审计工作流的建议，核心思想是“AI辅助，人类决策”。

5.1 双模型交叉验证工作流

不要只依赖一个AI。建议建立如下流程：

1. 第一轮独立审计：分别使用Claude和Codex（或其他主流代码模型如DeepSeek Coder、GitHub Copilot Chat）对同一代码库进行审计。
2. 结果对比与聚类：使用前文提到的“位置聚类+语义相似度”方法，将问题分为三类：
   • 共识问题：双方都报告。优先级最高，几乎可以确定是真实问题，立即安排修复。
   • 单方报告问题：仅一方报告。需要人工重点复核的区域。这可能是某个AI的误报，也可能是另一个AI的漏报。这里是提升代码质量的关键。
   • 均未报告区域：不能认为安全。对于核心安全模块，仍需进行传统的人工审计或使用专业的静态分析工具（如Coverity, Klocwork）进行补充扫描。
3. 人工仲裁与根本原因分析：对于单方报告问题，人工分析时不仅要判断对错，更要思考“为什么另一个AI没报？”这能帮助你更深入地理解不同AI的思维盲区，从而在未来更精准地使用它们。

5.2 提示词优化技巧

• 提供更多上下文：不仅仅是代码片段，在提示词中加入该模块的职责说明、调用关系（如“此函数由身份验证模块调用，输入来自网络”），甚至已知的威胁模型（如“此服务暴露在公网”），能极大提升AI判断的准确性。
• 要求引用标准：在提示词中明确要求“请参考CWE Top 25或OWASP Top 10进行分类”，能让输出更规范。
• 分层次提问：先问“是否存在安全漏洞？”，再针对它指出的点，追问“这个漏洞的完整攻击链（Attack Vector）是怎样的？”或“在什么条件下会触发？”。迭代式提问比一次性大段提示更有效。
• 指定角色与场景：使用更强烈的角色设定，如“你是一个以发现零日漏洞为生的顶尖安全研究员，正在审查一个即将部署在关键基础设施上的C++服务代码。请用最苛刻的眼光审视以下代码。”

5.3 与传统工具的结合

AI审计不能替代传统静态分析工具（SAST）。二者应结合：

• 传统SAST（如SonarQube, PVS-Studio）：擅长基于规则的模式匹配，对于语法错误、简单的空指针、资源泄漏等检查速度快、误报率相对稳定（但仍有）。将其作为第一道自动化防线。
• AI审计：在SAST扫描之后，针对SAST报告的告警进行AI辅助研判（“这个告警是真的问题吗？如何修复？”），同时针对SAST可能漏掉的、更依赖上下文的逻辑漏洞和业务漏洞进行重点审查。AI擅长理解代码意图，这正是规则引擎的短板。

5.4 针对C++项目的审计要点提示

结合本次实验，给C++开发者一些AI审计时的关注重点：

1. 内存与资源管理：重点关注所有new/malloc和delete/free的配对，所有文件/句柄的打开与关闭。让AI检查所有异常抛出路径和早期返回路径上的释放逻辑。
2. 指针与引用：对所有指针解引用、数组索引操作，要求AI确认是否存在越界可能。特别注意指针算术运算。
3. 整数运算：对所有涉及用户输入或不确定来源的整数的算术运算（尤其是乘法、加法）、类型转换、循环边界检查，要求AI进行溢出/下溢分析。
4. 字符串处理：彻底废弃不安全的C字符串函数。即使使用std::string，也要注意c_str()返回的临时缓冲区的使用。
5. 并发与线程安全：标记所有全局、静态变量以及共享的类成员变量，让AI分析其在多线程上下文下的访问是否受到适当保护（互斥锁、原子操作等）。

6. 总结与未来展望

让Claude和Codex同时审计26个模块，结果只在10个上达成共识——这个结果最初让我有些沮丧，但深思后却觉得价值连城。它清晰地告诉我们：当前的AI代码审计工具，更像是一个拥有惊人知识储备但经验和视角各异的“初级安全顾问”。它们能快速发现教科书式的经典漏洞，但在需要深度推理、跨模块理解、业务逻辑判断的复杂场景下，会表现出显著的不稳定性和分歧。

对于开发者而言，最实用的策略不是寻找那个“唯一正确”的AI，而是学会利用这种分歧。将不同AI的审计结果差异，视为对代码可疑区域的“高亮标记”。共识区是必须修复的“明疮”，分歧区则是需要你亲自下刀探查的“暗疾”。这个过程本身，就是对你代码质量的一次高强度压力测试。

未来，我期待看到几个方向的发展：一是出现专为代码安全审计微调的大模型，在CWE分类、漏洞模式识别上更精准；二是开发能够协调多个AI模型、进行“委员会决策”的中间件，自动整合、去重、加权投票不同模型的输出；三是将AI审计更深地集成到CI/CD流水线中，不仅报告问题，还能自动生成修复补丁并进行验证。

无论如何，AI正在改变代码审计的范式。它无法替代人类专家的最终判断，但它无疑是一个强大的倍增器。学会与这些有时意见相左的“AI同事”共事，理解它们的长处与短处，是每一位关注代码安全和质量的开发者值得投入时间掌握的技能。这次实验对我而言，最大的收获不是那份问题清单，而是建立起了一套如何与AI协作进行深度代码审查的方法论。