Claude Code与Codex CLI对比：AI代码审计共识率仅25%

最近我给一个老项目做集中式代码审计，12 个核心模块，分别让 Claude Code 和 OpenAI 的 Codex CLI 各跑了一遍。跑之前我预期这俩顶级编程智能体怎么也得有 8 成以上结论重合，结果现实直接打脸：12 个模块里，两个 AI 只在 3 个模块上给出了一致结论，剩下的要么发现的问题完全不同，要么连问题严重程度都吵得不可开交。这个结果让我意外，但也逼着我把两个工具的差异、定位、坑和正确用法完整摸了一遍。

这篇文章不是机械的“工具总结”，我把这次对比实验的设计、真实结果、差异原因、安装配置过程中的报错，以及我现在对“AI 代码审计”这件事的最终判断都写了出来。适合那些正在纠结选 Claude Code 还是 Codex、或者想用 AI 做代码审查但总感觉结论不靠谱的开发者。

1. 为什么我会同时用 Claude Code 和 Codex 做审计

1.1 两个工具到底有什么区别

先说清楚 Claude Code 和 Codex CLI 分别是什么。

Claude Code 是 Anthropic 官方推出的命令行编程智能体，安装后直接在终端里通过claude命令唤起。它的特色是能够读取整个项目的文件结构，在多文件之间跳转，适合做跨文件的重构、代码理解和整体性分析。我平时最常用它做“全局视角”的活儿，比如定位某个 bug 牵扯到哪些调用链、一个改动会影响哪些上下游模块。

Codex CLI 是 OpenAI 开源出来的终端编程智能体，装好之后用codex命令操作。它的优势在于执行能力更强，可以直接在沙箱里跑命令、运行测试、读日志，更像一个“会动手的实习生”。比如你告诉它“跑一下测试，然后把失败的修了”，它能自己在终端里操作，不需要你手动切来切去。

两者本质上是同一个赛道的产品，但背后的模型不同，使用场景侧重也不同。Claude Code 的上下文窗口和文件感知能力更强，Codex 的命令执行和自动修复链路更顺。正因为它们的“性格”差异明显，拿来对比才更有参考价值。

1.2 用 AI 做代码审计，选这两个工具的理由

我平时做代码审计基本都是靠人工过代码和静态扫描工具。静态扫描工具能抓空指针、SQL 注入这种模式化问题，但对业务逻辑漏洞、权限设计缺陷、状态流转异常这类需要理解业务的问题，基本无能为力。AI 编程智能体的出现，让“让 AI 读代码找问题”成了可能，而且它们不只是回答 prompt，而是真的会去翻文件、看引用关系。

为什么选这两个而不是直接用网页版？因为网页版聊天无法直接读整个仓库，你得手动把代码复制进去，既麻烦又容易截断。CLI 版能以项目为上下文，真正“审计”整个代码库，而不是对粘贴的片段做表面分析。

选择双模型交叉验证，是因为我清楚单个模型会有严重的“幻觉式误报”和“惯性漏报”。单一模型给出一份报告，你很难判断它是真发现了一个隐蔽问题，还是基于训练数据拼凑了一个看着像问题的结论。两个独立模型同时跑一遍，它们都指出来的问题可信度会高很多，给出矛盾结论的地方反而值得人工重点看。这个思路在代码审计里其实就是“双人复核”的翻版，只不过复核的人换成了 AI。

2. 审计实验全过程：从 12 个模块到只有 3 个共识

2.1 我定义的模块范围和审计标准

为了保证对比公平，我没有让两个 AI 随机发挥，而是把项目拆成了 12 个边界清晰的核心模块：

• 用户注册与登录
• 权限校验中间件
• 文件上传服务
• 订单状态流转
• 支付回调处理
• 消息队列消费逻辑
• 定时任务调度
• 数据导出服务
• 第三方 API 调用封装
• 缓存读写策略
• 日志脱敏处理
• 配置热更新机制

这 12 个模块覆盖了安全、性能、稳定性、可维护性这四个维度，而且每个模块的代码量基本在 300 到 2000 行之间，不至于让上下文爆掉，但足够考验模型的理解能力。

审计标准统一为四类问题：

1. 安全漏洞，包括认证授权、注入、敏感信息泄露等。
2. 性能瓶颈，包括循环里的慢查询、重复请求、内存无界增长。
3. 潜在 Bug 和异常处理缺失，包括空指针、并发问题、边界条件。
4. 可维护性问题，包括魔法数字、重复代码、缺失注释。

每类问题必须标注文件路径、行号、严重级别和建议修复方案，不允许模型说“可能有问题但不清楚在哪”这种模糊结论。

2.2 统一 Prompt 模板和两条执行命令

为了避免 prompt 偏差，我给两个 AI 用的是同一套模板，只替换了模块名：

请审计当前仓库中与 <模块名> 相关的所有代码。按以下维度输出： 1. 安全问题（按 OWASP 分类） 2. 性能问题 3. 潜在 Bug 和异常处理缺失 4. 可维护性问题 每个问题必须包含： - 文件路径和具体行号 - 严重级别（高/中/低） - 问题描述 - 修复建议 如果某文件与模块无关，不要输出。如果无法确定实际问题，不要编造。请基于项目代码的真实内容回答。

Claude Code 的运行命令用的非交互模式：

claude -p "<上方 prompt>" --output-format json > claude_audit.json

Codex CLI 我用了完整自动执行模式：

codex exec --full-auto --sandbox danger-full-access "<上方 prompt>" > codex_audit.md

注意--full-auto表示自动执行，不需要我逐条确认命令；--sandbox danger-full-access表示允许它读写文件。审计类任务只读代码就够了，但如果想让它跑测试验证问题，默认沙箱会受限。为了安全和稳定，我让两个 AI 都只读代码，不自动改文件。

2.3 结果汇总：共识率只有 25%

我把两个 AI 的输出按模块逐一比对，按“完全一致（至少有一个共同的高价值问题，且无重大矛盾）”“部分一致（有交集但各自也有重要发现）”“完全不一致（双方发现的问题基本不重叠）”三档归类，结果如下：

最终完全一致的只有 3 个：API key 硬编码、缓存穿透、日志脱敏。共识率 25%，比我预想的低太多。更关键的是，它们各自“独家发现”里有一半以上是有效问题，并不是在胡扯。这让我开始认真思考：为什么两个顶级模型，面对同一份代码，会得出完全不同的审计结果？

3. 同样一段代码，为什么两个 AI 的结论相差这么大

3.1 模型能力和知识截止的差异

最直接的原因是底层模型不同。我当时跑审计用的 Claude Code 是 Anthropic 的 Claude 系列模型，Codex CLI 背后是 OpenAI 的模型。两个模型在训练数据、知识截止时间、指令跟随风格上都有明显差异。

Claude 在处理“业务逻辑类问题”时表现更好，比如权限绕过、状态机异常、越权访问，这类问题需要模型对业务语义有较强的推理能力。而 Codex 在“工程实践类问题”上更敏锐，比如内存溢出、并发冲突、幂等性、接口防护，这些偏底层的工程问题它在训练数据里见过更多模板。

知识截止也有影响。两个模型学习到的“最佳实践”可能来自不同时期的代码库，对同一个模式有不同的判断。比如密码存储策略，一个认为使用 bcrypt 就算安全，另一个可能坚持必须加盐且使用 Argon2；这会造成结论分歧，但两种说法在各自语境下都不算错。

3.2 读取代码的路径和上下文策略不同

这是我在实际使用中观察到的最大差异。Claude Code 倾向于先看项目结构，再按依赖关系依次读取文件，它对“全局上下文”的建模能力很强，会先把相关文件都加载进来再统一分析，所以找到的问题往往跨文件、跨函数，例如“A 模块的过滤器没有处理 B 模块传入的特殊参数”。

Codex CLI 的读取策略更偏向“指令驱动”，它会先定位 prompt 里提到的模块文件，然后快速读入那些直接相关的内容。这种策略的优点是执行效率高，对局部问题很敏感；缺点是容易漏掉跨模块的复杂调用链，尤其是当“问题”藏在一个看起来毫不相关的公共工具类里时，它可能根本不会去读那个文件。

这个差异直接导致了两边审计覆盖面不均衡。Claude Code 的“广度”好，Codex 的“深度”好，但两个都不是完美的“全量审计器”。

3.3 输出格式和“审计风格”造成的差异

模型默认的输出习惯会严重影响审计结果的可读性和覆盖范围。Claude Code 在输出审计报告时非常喜欢分层，它会先按安全、性能、Bug、可维护性分类，再在每类下列出具体问题。这种结构有一点副作用：当某类问题过少或没有时，它可能会为了“填满结构”而勉强凑一个低严重级别的问题，偶尔会给你一些无关紧要的重复代码建议。

Codex 的输出更像“修复工程师”，它会直接列出最严重的问题，然后给出修复代码片段。这种风格的好处是直击痛点，坏处是容易忽略那些不严重但会积累成技术债的小问题。更麻烦的是，Codex 会在多个模块里给出相似的“优化建议”，比如“建议增加重试机制”，但并不会告诉你这个模块里的重试到底哪里缺失、什么情况下会触发问题。这种“模板化建议”会让结论看起来空泛，也增加了核验成本。

所以当我把两份报告并排对比时，发现有很大一部分“分歧”其实不是代码真的只有一边有问题，而是两个模型各自筛掉了自己不感兴趣的东西。AI 审计结果不是“客观结论”，更像是两个背景不同的资深工程师在各自凭经验画重点。

4. 从分歧里逼出来的真实问题和人工核验方法

4.1 两边的独有发现，哪些靠谱哪些是幻觉

双模型审计最大的价值，不是得到一个“共识列表”，而是让你从分歧里拿到两条独立的线索，然后逐一验证。

在我这 12 个模块里，Claude Code 独家指出的“文件上传类型校验可绕过”是真实存在的。它发现上传模块只校验了 Content-Type，而不是校验文件内容，攻击者可以直接改 Content-Type 上传可执行文件。这个我之前用静态扫描并没有抓出来。

Codex 独家指出的“订单状态并发错乱”也真实存在。它定位到了状态更新的updateById操作没有加乐观锁，高并发场景下两个请求会把订单从“待支付”同时改为“已支付”和“已取消”。这个问题的描述和行号很精准，我顺着它给的堆栈方向去查，果然看到了并发脏写。

但也有幻觉。Codex 在“定时任务调度”模块声称存在“任务超时无熔断”，可我翻遍了代码，发现已经有基于信号量的超时控制，只是它没读到那个工具类。Claude Code 在“数据导出服务”里声称“导出接口未做权限控制”，实际情况是权限校验在网关层完成，模块内部确实没有重复校验，但说“未做权限控制”属于误报。

AI 审计出来的每条结论都必须当“未证实线索”处理，不能直接写进修复工单。这是双模型审计的前提。

4.2 我的核验流程：怎么判断 AI 说的是真是假

我现在每拿到一份 AI 审计报告，都会走一套固定的核验流程，避免被 AI 带偏：

1. 定位文件与行号：先打开报告里提到的文件路径，跳到指定行，确认该行代码确实存在，且与描述的功能相关。这能过滤掉大量凭空捏造的问题。
2. 理解上下文：只看一行不够，必须向上向下多看 20 行到 50 行，确认这个代码在什么条件下执行，有没有前置校验、有没有兜底逻辑。很多误报都是模型只看了片段没看全貌。
3. 判断攻击路径或触发条件：安全类问题，我会尝试在本地写一个最小请求或调用脚本，看能不能真正触发；性能类问题，我会看数据量级和循环复杂度，判断是否真的会产生可感知的延迟。
4. 交叉验证：如果一个问题只有单个模型提出，我会抱着“可能存在”的态度，但不会着急修；如果两个模型都提出了同类问题，我会直接提升优先级。

以“文件上传类型校验可绕过”为例，我按流程走到第 3 步，用 Burp 改了一个 Content-Type 头重放请求，发现文件确实被保存了，这才确认是有效漏洞。这个例子也说明，AI 有时能找到真实问题，但最终“拍板”的一定要是人。

4.3 双模型审计的正确使用姿势

双模型审计不要简单地把两份报告合并去重，那样只会得到一份“更大但更乱”的问题清单。正确做法是：

• 把两份报告都标记为“候选问题”。
• 提取两个模型都提到的问题，人工优先核验，这类通常是共性 bug 或最有把握的修复点。
• 提取只有一边提出、但描述细节非常具体的问题（有明确行号、调用关系、触发条件），进一步人工验证。
• 把那些描述模糊、没有具体位置、明显是模板话术的结论，直接忽略或标记为低优先级。

我这次实验中，双模型共同确认的 3 个问题全部修掉后，项目的关键路径稳定性和安全性都有明显提升。这不是某个模型更聪明，而是“两个独立判断 + 人工复核”这个流程本身有效。

5. 实际操作中的安装报错与配置问题排查

实验过程中当然不是一帆风顺，安装和配置两个 CLI 工具遇到了不少报错，这里把最有参考价值的几个问题和解决思路记录下来。

5.1 安装环节的常见报错

“claude”或“codex”不是内部或外部命令

这个最常见，原因是 Node.js 的全局安装目录没有加入系统的PATH环境变量。安装完npm install -g @anthropic-ai/claude-code或npm install -g @openai/codex后，先执行npm config get prefix拿到全局目录，然后把该目录加入PATH。Windows 上常见的坑是安装到了%APPDATA%\npm，但终端没重启，导致命令找不到。

Windows 下 Claude 桌面版报 “failed to start Claude's workspace requires the virtual machine platform on windows”

这个报错主要出现在 Claude 的桌面客户端，而不是命令行版。原因是它依赖 Windows 的虚拟机平台功能来做代码执行沙箱。解决方法是打开“启用或关闭 Windows 功能”，勾选“虚拟机平台”和“Windows 虚拟机监控程序平台”，然后重启电脑。如果只是跑命令行claude，一般不需要这个功能。

Codex 报 “The 'gpt-5.6-sol' model is not supported when using codex with a ChatGPT account”

这个报错的意思是，当前用 ChatGPT 账号登录 Codex CLI 时，账号可用的模型和配置里指定的模型不匹配。用 ChatGPT 登录的免费或 Plus 账户只能用 Codex CLI 预设的模型，不支持自定义改成其他模型。解决方法是，要么把模型配置改回官方支持的默认值，要么改用 API key 方式认证，那样就可以通过model配置指定 API 支持的模型。

CC Switch 报 “cc switch local proxy failed while handling codex endpoint /responses”

CC Switch 是我用来在 Claude Code 和 Codex 之间快速切换 API 配置的小工具。这个报错是因为我在 CC Switch 里给 Codex endpoint 配置了一个本地代理地址，但那个代理服务并没有启动，或者地址写成了 HTTP 而服务监听的是 HTTPS。排查思路很简单：先确认本地代理进程是否在跑，再看 endpoint 的协议、IP、端口是否和实际服务一致。如果只是纯粹用官方 API，不需要配置本地代理，把这个配置项清空即可。

5.2 Codex 上下文溢出报错

用 Codex 审计长文件时，我踩到过这么一条报错：

error running remote compact task: codex ran out of room in the model's context

这句话的意思是，Codex 在执行过程中需要把之前的对话历史压缩（compact），但连压缩后的内容也超过了当前模型的上下文窗口。审计大项目时很容易触发，因为 Codex 会不断读取文件并把内容填进对话历史。

解决思路有三个：

1. 缩小任务范围：把 12 个模块分开跑，不要一次性塞给 Codex 一个“审计全部模块”的 prompt。
2. 清理历史会话：每次执行新审计前，用新的会话，不要让上一次审计的上下文残留。
3. 减少输出长度：在 prompt 里要求“只输出高严重级别的问题”，能显著降低 token 占用。

相比于 Codex，Claude Code 在长上下文处理上明显更从容，这也是我后续更倾向用 Claude Code 跑全局审计、用 Codex 跑定点修复的原因。

5.3 我的安装和配置清单（避坑版）

如果你也想复现这套双模型审计流程，可以直接按下面这个清单操作：

1. 安装 Node.js 18 或更高版本，建议 LTS。
2. 全局安装两个 CLI：

npm install -g @anthropic-ai/claude-code npm install -g @openai/codex

3. 检查安装是否成功：

claude --version codex --version

4. 认证：Claude Code 运行claude时会引导登录账户；Codex 首次运行codex或者codex login登录。
5. 验证基本功能：在一个小项目里分别让它们读一个已知有问题的文件，看看能否正确反馈。

这套配置本身不复杂，很多报错都出在环境变量和模型配置上。我的建议是：不要一上来就折腾各种切换工具，先让官方默认配置跑通，再根据自己的需求加自定义设置。

6. 关于“让 AI 审计代码”这件事，我的几条真实建议

6.1 AI 审计适合做什么，不适合做什么

经过这次实验，我对 AI 代码审计的边界有了更清醒的认识。

适合做的：

• 快速定位常见漏洞模式：硬编码敏感信息、缺少鉴权、路径穿越、注入风险、不安全的反序列化等，这些有明确模式的问题，AI 非常擅长。
• 跨文件调用链分析：让 AI 画出某个数据从入口到落地的完整链路，并指出链路中哪个环节缺少校验，比人工翻代码快很多。
• 代码规范和技术债扫描：重复代码、魔法数字、过长函数、缺失注释，这些“不算 bug 但让开发者难受”的问题，AI 能很全面地扫出来。

不适合做的：

• 代替人工安全测试：业务漏洞往往需要结合真实业务场景，AI 不理解你的业务闭环，很容易漏。
• 作为唯一结论依据：AI 的幻觉在这个领域依旧存在，而且代码审计这种任务天然给模型“编造细节”的空间，不核验就修会引入新问题。
• 处理复杂并发和数据一致性问题：这类问题需要复现和动态调试，AI 单靠读代码能发现问题，但给出的修复方案很可能忽略边界条件。

6.2 单模型 vs 双模型：投入产出比

有人可能会问：单模型审计不行吗？非得上两个？

我的感受是：单模型能用，但风险很高。如果只用 Claude Code，你可能会漏掉大量底层工程问题；如果只用 Codex，你可能抓不到跨模块业务漏洞。双模型的成本不仅仅是多跑一遍，还要花时间核验两份报告中不一致的部分，整体投入大约是单模型的 2 到 3 倍。

但代码审计这件事，漏掉一个高危漏洞带来的成本远远大于审计本身的投入。尤其对于支付、权限、用户数据这类高敏感模块，双模型交叉验证产生的“安全感”是单模型无法提供的。如果你的项目只是内部工具、无敏感数据，单模型足够；如果是核心业务系统，我强烈建议至少用两个互相独立的 AI 跑一遍。

6.3 后续我打算怎么继续用这两个工具

现在我的工作流基本固定了：大范围代码普查用 Claude Code，它有耐心读完整仓库，能输出一份分门别类的长报告。定位到具体问题后，我会让 Codex 去自动修复，它能跑测试、能根据报错反复调整代码，处理局部 bug 的效率比人工高得多。

这两个工具在我这边不是竞争关系，而是互补关系。Claude Code 像一个善于全局规划的架构师，Codex 像一个执行力很强的实现工程师。让它们各自做擅长的事，比强迫一个工具干所有事情要靠谱得多。

最后分享一个小技巧：审计完拿到报告后，不要直接让 AI 自己改问题。让 AI 先把所有发现的问题“打标签”（比如“高危漏洞”“低危规范”），再由人录入缺陷系统。这样可以防止 AI 在自动修复过程中夹带私货，把本来没坏的地方也重构成了它喜欢的样子。代码审计的最终责任人，永远是人。