Claude与Codex在审计技能上表现差异，其性能优劣如何量化对比？

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"。