Claude 和 Codex 在审计 Skill 上性能差异探究

1. 背景

现在所有的安全公司以及安全研究人员都在用 AI 协助进行代码审计与漏洞挖掘，哥们儿也不例外，也在干这个事儿：把代码审计的流程整理成 Skill，然后提供给大模型作为代码审计的指引。

那么在大模型进行代码审计这个领域，有一个绕不开的痛点，就是大模型处理大量代码时，由于上下文窗口容量不足容易出现幻觉或信息丢失的问题。所以在 Skill 的设计上约束了大模型获取代码方式：首先分析项目的业务流程，并按需获取在该流程中被调用的函数代码。

然而在后续的测试中发现，这套 Skil 在 Claude Code（Claude Opus 4.6 1M） 平台上的漏洞发现较少，在 Codex （GPT 5.4 xhigh）平台上的效果反而更好。为了探索同一套技能在不同大模型平台上使用的情况，对两者的分析思路与执行方法进行了了解。

2. 两个模型在分析思路与执行方法上的根本差异

根据已有的公开信息，对两个模型的特征进行对比展示。

2.1 执行架构与思维模式

两个模型在底层架构上的差异，直接塑造了它们面对审计任务时的认知风格。

Codex 更擅长从局部进行假设与验证，Claude 更擅长从全局开始理解与推理

2.1.1 Codex：强化训练训练的"完成任务直到通过"循环

根据 OpenAI 的 Unrolling the Codex Agent Loop 描述，Codex 的核心是一个 agent loop：分析意图 → 调用工具 → 获取结果 → 反馈到上下文 → 再次推理，循环直到任务完成。Codex 底层是 o3 系列模型，经过强化学习训练------目标函数是"迭代运行测试直到通过"。

这种训练方式产生了一个关键特质：Codex 天然倾向于把每个分析步骤当作需要"通过/不通过"验证的测试用例。当 skill 里的审计方法论说"枚举每个假设"时，Codex 的 RL 训练使它更倾向于真的逐个枚举然后逐个验证------因为它被训练成"如果跳过一步导致最终结果不通过，会得到负奖励"。

2.1.2 Claude：长上下文推理 + 交互式对话 + Extended Thinking

而 Claude Opus 4.6 的强项是 "structured, multi-step reasoning"------理解架构、追踪依赖链、在多文件间推理。它的 extended thinking 机制让它能在长推理链上保持连贯。

但这也带来了一个副作用：Claude 更擅长"理解系统如何工作"，而非"穷举系统如何被打破"。它会构建一个连贯的心智模型（"depositToken 有 balance check → 协议有 fee-on-transfer 保护"），然后基于这个模型做推断------如果模型是对的，推断也是对的；如果模型遗漏了一条路径，所有基于它的推断都会偏离。

2.1.3 对比总结

• Codex 更像"执行优先"的 agent。它的默认强项是：快速把任务落到 shell、测试、补丁、验证闭环里，尤其适合 fix/refactor/CLI/环境调试 这类**"目标明确、验收清晰"**的任务。
• Claude Code 更像"分析优先"的 agent。它的默认强项是：先吃上下文、建全局语义、跨文件保持一致性，尤其适合 多文件特性开发、复杂代码理解、长链路规划、语义一致性修复。

但这不是绝对的 GPT 5.4 和 Claude Opus 4.6 的"模型差异"，很大一部分其实是 Codex 和 Claude Code 的"产品执行方法差异"。

2.1.4 使用场景

• 如果任务是"找 bug、跑命令、修测试、反复验证"，公开证据更支持 Codex 偏强。
• 如果任务是"吃大仓库上下文、做多点位协调编辑、长时间保持语义一致"，公开证据更支持 Claude Code 偏强。

2.1.5 项目中的直接体现

在其中一个案例中，这种差异体现得非常直接。

以某案例中的 ammHandleTransfer 资金流分析为例：

• Claude 构建了一个全局心智模型："这个协议对所有入金做了 balance delta 验证"------然后用这个模型判断所有路径安全。实际上 fillOrder 路径没做验证，但这个路径不在模型中。

  把代码上下文限制为根据业务流程所调用的函数按需获取，可能会让 Claude 将某一条业务流程中得出的结论，扩大到整个协议中进行使用。对 Claude 的上下文进行约束，可能会限制了他全局思考的能力。

• Codex 没有构建全局模型------它逐路径检查，把 ammHandleTransfer 的 inflow 标记为 "assumed to already be sitting in the handler"。它不关心其他路径有没有保护，只关心当前路径有没有。

---

2.2 两个模型的认知模型

接下来深入讨论两种模型的优缺点

2.2.1 Claude: 心智模型驱动

Claude 的推理方式是先建模，再推断。面对一组合约，它会根据上下文构建一个连贯的模型------"这个协议是做什么的，各部分如何协作，安全机制在哪里"------然后基于这个模型判断每个函数是否安全。

这个策略的优势和代价：

• 优势：跨模块洞察。 模型能自然地看到"合约 A 的输出是合约 B 的输入"这种跨边界关系，因为它在心智模型中把整个协议当作一个整体。
• 代价：推断替代验证。 一旦心智模型中标注了"这个协议对 X 有保护"，所有涉及 X 的路径都会被推断为安全------即使某条路径上并没有这个保护。心智模型是对现实的压缩，压缩必然丢失细节。

EVMbench 数据印证：Claude 在 Detect 任务上得分最高（45.6%），因为检测需要全局理解；但在需要精确路径追踪的 Exploit 任务上弱于 Codex。

2.2.2 Codex: 指令执行驱动

Codex (GPT-5.4) 的推理方式是逐步执行，逐步验证 。它的 RL 训练目标是"执行操作序列直到任务完成"（参见 Unrolling the Codex Agent Loop）。面对同一组合约，它不会先建全局模型，而是按指令对每个函数逐步分析，对每个检查点产出结果。

• 优势：执行纪律。 如果你的方法论写了"对每个参数检查是否被签名覆盖"，Codex 更可能真的逐参数检查。它不会因为"看起来已经够安全了"而跳步。
• 代价：隧道视野。 Codex 在执行步骤 3 时不太会主动回忆步骤 1 的发现来做关联。除非你在指令中显式建立了这些连接。

EVMbench 数据印证：Codex 在 Exploit 任务上得分最高（72%+），因为利用需要精确的路径构造和迭代调试------这正是 RL 训练优化的能力。

Exploit 这种能够"验证"的任务更符合 Codex 的做事风格

2.2.3 Semgrep 研究的补充证据

Semgrep 的对比提供了互补视角：

• Claude 报告了 2 倍的发现（46 vs 21），但假阳性率更高（86% vs 82%）
• Claude 在 IDOR（需要理解业务语义）上更强；Codex 在 Path Traversal（需要逐路径追踪数据流）上更强
• Codex 跨多次运行的结果波动更大（非确定性更高）
  这与上述认知模型一致：全局理解 → 高召回、高假阳性；逐步执行 → 低召回、高精度。

---

2.3 总结：不同的认知策略各有优劣

特性	Claude Code（Claude Opus 4.6 1M）	Codex （GPT 5.4 xhigh）
核心能力	全局理解 + 长链推理	逐步执行 + 验证循环
方法论	理解为指南，自主判断是否执行	理解为指令，逐条机械执行
假设	构建全局模型进行推断	倾向逐个检验

Claude 更擅长"发现可能的问题"（更高的 recall），Codex 更擅长"验证问题确实存在"（更高的 precision）。在审计 skill 这种要求每一步都执行到位的场景中，Codex 的执行纪律性是关键优势。

---

3. Skill 设计指引

基于上述认知差异，skill 设计的核心思想可以归结为两条原则：

• 为 Claude 设计 = 指引 ：防止它跳过步骤，防止它用推断替代验证，防止它被干扰项吸引。
• 为 Codex 设计 = 连接 ：帮它看到步骤之间的关联，帮它把孤立的发现组合成攻击链，帮它理解全局上下文。

接下来根据代码审计的具体场景对 skill 的设计理念进行分析对比

3.1.1 项目模式识别

在先进行项目类型识别，后进行漏洞挖掘的模式中。业务分析产出的文档是所有后续漏洞挖掘 agent 的"世界观"。它不只是信息，它是框架------它决定了 agent 在后续分析中会提出什么问题、忽略什么问题。

关键洞察：如果业务分析阶段把一个未验证的假设描述为事实，后续所有 agent 都不会再去质疑它。

在 A/B 实验中，对同一个回调函数的资金流入：

• 一方描述为"协议收到 X 代币"（陈述语态）→ 所有 agent 视为已验证
• 另一方描述为"假定 X 代币已到账"（质疑语态）→ agent 主动验证实际到账金额

仅这一个措辞差异，就导致了一个 High 级别漏洞的发现与否。

• 对 Claude 的设计含义：Claude 天然倾向于用陈述语态描述系统（因为它在构建连贯模型），所以你的 Phase 1 指令必须强制使用质疑语态。对每个未在代码中显式验证的假设，要求标注为假设而非事实。
• 对 Codex 的设计含义：Codex 不太需要质疑语态（它不构建全局模型），但它需要业务分析阶段产出显式的连接信息------哪些函数共享状态、哪些函数构成交易序列、哪些不变量必须跨函数维持。否则每个函数会被孤立分析。

3.1.2 分析粒度必须匹配模型的自然停止层

每个模型在分析时有一个"自然停止层"------它倾向于在这个层次得出结论。

• Claude 的自然停止层是概念层。 它会得出"有 EIP-712 签名保护"、"有 reentrancy guard"、"有 balance check"这种概念级结论，然后停止深入。
• Codex 的自然停止层是步骤完成层。 它会完成指令要求的步骤，然后停止。如果指令只要求"检查是否有签名验证"，它会回答"有"然后停止------不会主动追问"签名覆盖了哪些字段"。

设计含义：你的 skill 必须把分析要求推到自然停止层之下。

• 对 Claude：提供一个明确的思路与质疑，让他帮你去深入分析。与其问"是否有签名保护"，不如问"签名覆盖了哪些参数，有哪些影响经济结果的参数不在签名中"。与其问"是否有 balance check"，不如问"这条特定路径上，记账金额的数据来源是什么------是实际余额测量还是名义参数"。

  这也就很好地说明了 claude 在与资深代码审计人员进行结对交流审计时的良好表现。审计人员为 claude 提供分析思路与质疑角度，而 claude 作为审计人员思考与行动的延伸，帮助其快速高效的解决问题。

• 对 Codex：提供一个详细可执行的任务列表。不要问"分析这个函数"，要分解为明确的子任务，每个子任务有明确的输出格式。Codex 会精确执行你定义的每个子任务，所以你对子任务的分解粒度决定了分析深度。

  而在与 codex 进行结对交流审计时，确实会产生很强烈的"踢一脚，动一下"的感觉。只是完成审计人员反馈的任务，不做过多的延伸和扩展。

3.1.3 执行指令

在设计一套智能合约审计 skills 时，我们需要设定一个框架和流程，然后在框架中编写指引大模型进行分析操作的执行指令。那么该如何设计合适的执行指令来引导大模型进行分析操作？

Claude 需要"不得不做"，Codex 需要"知道该做什么"

这是两个模型在面对方法论时的根本区别。

• Claude 理解方法论但选择性执行。 如果你的维度方法论说"构造重复攻击计算累积误差"，Claude 会理解这个要求，但如果它判断单步误差很小，它会自主决定跳过这一步。它把方法论当作指南，用自己的判断过滤哪些步骤"值得做"。

• Codex 执行方法论但不理解意图。 如果你的方法论说"分析这个函数"，Codex 会执行，但它可能不知道应该重点关注什么。如果你的方法论说"检查参数 A 是否被签名覆盖"，Codex 会精确检查------但它不会主动追问"还有哪些参数也应该被检查"。

  如果能够设计一个严谨，可具体执行的审计流程与方法论，那么可能在 codex 上执行会更加高效，可控。

3.1.4 多 Agent 信息共享

如果你的 skill 使用多 agent 并行挖掘，agent 的分工方式应该适配模型特点。

原则：把需要关联的信息放进同一个 agent 的上下文里。

• Claude 擅长关联，所以可以给每个 agent 更少的函数但更多的分析维度------让它在一个合约内自由地跨维度关联。拓扑倾向于按合约分组。

• Codex 不擅长自发关联，所以让每个 agent 专注于一个分析维度但看到所有合约------它可以在同一维度下对比不同合约的处理方式（"合约 A 做了这个检查，合约 B 做了吗？"）。拓扑倾向于按维度分组。

  在编写合约审计Skill时，我们常用的漏洞类型匹配或者checklist匹配的方法，似乎更适合codex的执行习惯

这不是绝对规则，而是默认偏好。如果你的协议中某两个合约有极强的状态耦合，即使对 Codex 也应该把它们放在同一个 agent 中。

3.1.5 漏洞 PoC 验证

• Claude 的天然优势是因果推理。 它擅长解释"为什么这是一个 bug"和"如果有/没有这个 bug 会怎样"。利用这一点：要求 Claude 的 PoC 同时包含"证明漏洞存在"和"证明正确行为"两个测试------它擅长构造这种因果对比。

  https://blog.katanaquant.com/p/the-bug-that-shipped

  这篇文章的核心发现：AI 编程代理在自我审查代码时只能发现 13% 的生产级关键 bug，但当你直接问"什么会出问题"时，它们 100% 能给出正确诊断。

• Codex 的天然优势是迭代调试。 它的强化训练让它擅长"运行 → 失败 → 诊断 → 修复 → 重试"的循环。利用这一点：把 PoC 验证设计成测试循环，允许多次修复尝试。更进一步：让 Codex 对每个 SAFE 结论也写一个测试------如果它认为"这里有 balance check 保护"，就让它写一个用 fee-on-transfer mock 的测试来证明这个保护真的存在。如果测试失败，SAFE 结论自动被推翻。

  这是 Codex 独有的优势：把静态分析转化为动态验证。Claude 很难做到这一点，因为它的思维模式是"推理得出结论"而非"测试验证结论"。

4. 后记

随着 AI 的能力以日计算地不断更新，业务流程 AI 化如浪潮般袭来。我们每个人都处于这股浪潮之中，一边用 AI 代替自己进行工作，一边担心自己会被 AI 取代。确实会让人焦虑，抵触，迷惘。但当你不知道未来路在何方时，恰恰应该保持随时应变的心态。在浪潮袭来的时候，我们要做到应该是投身浪中顺势冲浪，而不是死死抱住那块礁石。