我让 Claude 和 Codex 同时审计 26 个模块，它们只在 10 个上达成共识
TL;DR: 用 Claude Opus 4.6 和 GPT-5.3-Codex 对同一个 C++ 遗产项目做独立审计，26 个模块一致率仅 38.5%。Claude 偏向"功能覆盖度"（13 个核心基石），Codex 偏向"实现质量"（只认 2 个），且独立发现了 13 个 Claude 完全漏掉的 Bug。结论：重要审计至少用两个 AI 交叉验证。
SWE-bench Verified 排行榜上，Claude Opus 4.6 拿了 80.8%。GPT-5.3-Codex？OpenAI 直接不交卷了------他们认为这个榜单存在训练数据污染，分数已经不能反映真实能力。
有意思。两家最强的编程 AI，一个考了高分，一个拒绝参考。
那我换个考法：让它们干同一件活------审计我手里这个十几年的 C++ 遗产项目------看看实战结果差多少。
结果差了十万八千里。
注：截图中 Agent-2 显示为 "o4-mini" 系报告渲染时的模型标识错误，实际调用的是 GPT-5.3-Codex。
26 个模块，两个 AI 只在 10 个上达成了共识。一致率 38.5%。
更离谱的是：Claude 说有 13 个模块是"核心基石、质量过关"，Codex 只认 2 个。剩下 11 个，Codex 全给降了级------理由是它们虽然能跑，但藏着没爆的雷。
这篇文章不是要告诉你"谁更好"。而是要告诉你：为什么两个号称最强的编程 AI，面对同一份代码会给出截然不同的判断------以及这对你使用 AI 工具意味着什么。
实验怎么做的
项目背景：一个积累了十几年的 C++ 音视频基础库，26 个模块，几万个源文件。典型的"老同事走了新同事不敢动"的遗产代码。
我用 repo-scan 的交叉扫描功能，对这个项目做了一次双 Agent 审计：
- Agent-1：Claude Opus 4.6，执行全量扫描------逐模块分析代码结构、依赖关系、质量问题，给出四级判决
- Agent-2：GPT-5.3-Codex，执行独立验证------在不看 Agent-1 结论的前提下，对同一批模块做独立审计
四级判决体系：
| 判决 | 含义 | 行动 |
|---|---|---|
| 🟢 核心基石 | 质量可靠 | 直接保留，作为新架构基础 |
| 🔵 提纯合并 | 有价值但冗余 | 提取核心逻辑，合并同类模块 |
| 🟡 重塑提取 | 部分可用 | 大幅改造，仅保留算法/协议层 |
| 🔴 彻底淘汰 | 不值得修 | 删除重来，用现代方案替代 |
两个 Agent 独立跑完之后，我把结果摊在一起对比。
最明显的表现：一致率 38.5%
26 个模块，两个 AI 给出完全相同判决的只有 10 个。
下面这张截图是交叉扫描报告里的判决对比视图。左右两列分别是两个 Agent 的评级，颜色不一致的就是分歧模块：
不一致的 16 个模块里，有一个惊人的规律：所有分歧中，Codex 的判决都比 Claude 更严格。
没有一次例外。
Claude 说"核心基石"的，Codex 最多给"提纯合并"。Claude 说"提纯合并"的，Codex 可能降到"重塑提取"。
最夸张的对比：
| 维度 | Claude 判定 | Codex 判定 |
|---|---|---|
| 评为"核心基石"的模块数 | 13 | 2 |
| 评为"提纯合并"的模块数 | 11 | 16 |
| 评为"重塑提取"的模块数 | 2 | 8 |
Claude 认为半数模块质量过关可以直接用，Codex 觉得只有两个能放心用。
另一个关键发现：13 个 Claude 完全漏掉的 Bug
这才是真正让我后背发凉的。
Codex 在独立审计中，发现了 13 个关键问题是 Claude 完全没有提到的。不是"分析角度不同"，是"Claude 看了代码但没发现问题"。
挑几个最有代表性的：
mp4_parser：定点数算术腐败
模块里有一段写 MP4 tkhd box 的代码，宽高字段用的是 16.16 定点数格式（高16位整数 + 低16位小数）。
Codex 发现：代码写入了一个 16 位的值，但指针往后跳了 4 个字节。
结果就是高 16 位写对了，低 16 位被后面的数据覆盖。 生成的 MP4 文件在大多数播放器上看着正常------因为播放器容错能力强。但如果下游工具严格按规范解析，宽高就是错的。
Claude 看了同一段代码，给出的评价是"MP4 封装模块功能完整"。
video_encrypt：形同虚设的"加密"
这个模块声称对视频流做加密保护。
Codex 一看：整个加密逻辑就是 4 字节 XOR。
这不叫加密，这叫安慰剂。任何人用十行脚本就能逆向。更要命的是里面还藏着一段时间炸弹代码，以及一个 ReadFrame 的空指针解引用。
Claude 对这个模块的评价？"视频加密模块，功能可用，建议优化。"
protocol_gb28181：God Class
GB28181 协议模块里，Server 和 Client 的代码 60% 重复。三组配对对象（Server/Client、SipDevice/Link）都在各自内部重新实现了"SIP 会话 + RTP 媒体 + 业务控制"。
Codex 指出：这是教科书级的 God Class------一个类干了三件不相关的事，改任何一件都可能影响另外两件。
Claude 说这个模块"协议支持完善，是核心基石"。
其他 Codex 独立发现的问题
| 模块 | Codex 发现的问题 | 后果 |
|---|---|---|
| capture_device | COM 初始化顺序错误 | 多线程随机崩溃 |
| record_play | ThreadStart() 被注释掉 | 磁盘清理失效，无限吃盘 |
| web_wasm_player | 未声明全局变量 + signal 未传递 | 浏览器内存泄漏 |
| nserver | TLS 1.0 残留，接口对不上 | 安全隐患 + 运行时报错 |
这些不是什么"代码风格问题"或"最佳实践建议"。是真的会在生产环境炸的 Bug。
下面是交叉扫描报告中，某个分歧模块的详情页面。左右并排展示两个 Agent 各自的分析，红色高亮的就是分歧点：
为什么同一份代码，两个 AI 的判断差这么多？
分析完所有 16 个分歧模块后，我找到了规律。
Claude 的审计逻辑偏向"功能覆盖度"。 它的思路是：这个模块声明了哪些接口？实现了没有？能编译能跑吗？如果答案是"能"，就倾向于给高分。
Codex 的审计逻辑偏向"实现质量"。 它的思路是：这段代码的每一个分支是否正确？有没有隐藏的资源泄漏？有没有过时的 API 调用？即使能跑，实现是否健壮？
老实讲，两种视角都有道理。
如果你的目标是"快速理解一个陌生项目的架构和模块边界"，Claude 的功能覆盖视角更高效------它能在几分钟内告诉你这个项目有哪些模块、各自干什么、依赖关系是什么。
如果你的目标是"评估这份代码能不能上生产、有没有定时炸弹"，Codex 的实现质量视角更靠谱------它会钻进每个函数的每个分支去找隐患。
问题在于：如果你只用一个 AI 做审计，你根本不知道自己漏了哪个视角。
Claude 给你的报告看起来很完整，26 个模块全覆盖，有判决有理由有建议。你看完之后心想"还好嘛，半数以上是核心基石，剩下的重构一下就行"。
直到 Codex 告诉你：那 13 个"核心基石"里，有 11 个藏着你不知道的雷。
跑分高不等于适合你的场景
回头看跑分这件事。
Claude Opus 4.6 在 SWE-bench Verified 上拿了 80.8%。OpenAI 拒绝提交 GPT-5.3-Codex 的成绩，理由是数据污染。在更抗污染的 SWE-bench Pro 上，GPT-5.3-Codex 拿了 56.8%，目前领先。
但即使是 SWE-bench Pro，也只是在测"给一个 GitHub Issue，能不能生成正确的 Patch"。这和"审计一个 26 模块的遗产项目、判断哪些代码有隐患"是完全不同的任务。
跑分衡量的是"做题能力"。代码审计需要的是"怀疑一切的能力"。
我的 dual-scan 实验恰好说明了这一点：Claude 做题可能更稳，但 Codex 更会"找茬"。
订阅价格和使用体验
说点实际的。
| 维度 | Claude Code | Codex CLI |
|---|---|---|
| 基础订阅 | Pro $20/月 | Plus $20/月 |
| 高级订阅 | Max $100-200/月 | Pro $200/月 |
| 默认模型 | Opus 4.6 | GPT-5.4 Thinking（可切 5.3-Codex） |
| 上下文窗口 | 200K（Max 含 1M） | 256K（Pro 400K） |
| 安全机制 | 应用层 Hooks | 内核级沙箱隔离 |
基础价格一样，都是 20 刀。体验上的核心差异：
- Claude Code 更像一个谨慎的高级工程师：理解力强、文档写得好、重构一致性好，但有时候"太客气"------倾向于给你一个积极的评价
- Codex CLI 更像一个较真的 Code Reviewer：实现导向、关注细节、善于挑刺，但有时候"太悲观"------可能把正常的工程权衡也标记为问题
两个 20 刀加起来 40 刀/月。说实话，同时用两个，比花 200 刀只用一个的高级版性价比高得多------因为你获得了两个不同视角的交叉验证，这是单个 AI 用再多 token 也给不了你的。
你应该怎么用这个发现
三条建议，不需要任何特定工具就能执行：
1. 重要代码审计，至少用两个 AI 交叉验证。
不需要什么复杂工具。把同一段代码分别丢给 Claude 和 Codex（或任何两个不同家族的模型），对比它们的输出。如果两个 AI 对同一段代码的评价一致，可信度大增；如果不一致，那个分歧点就是你需要人工仔细看的地方。
2. 了解你用的 AI 的系统性偏差。
我这次实验的结论是：Claude 偏向"功能覆盖"，Codex 偏向"实现质量"。这不是 Bug，是它们训练数据和优化目标的差异。
知道这个偏差之后，你就能更聪明地使用它们：
| 你的场景 | 推荐 | 原因 |
|---|---|---|
| 接手陌生项目，快速建立全局认知 | Claude | 功能覆盖视角，几分钟出全景 |
| 代码准备上生产，找隐患 | Codex | 实现质量视角，逐分支挖雷 |
| 两者结论冲突的模块 | 你亲自看 | 分歧点 = 最值得人工审查的地方 |
3. 不要迷信跑分。
SWE-bench 上的分数，在真实的代码审计场景下毫无参考价值。选工具，看它在你的具体任务类型上的表现，别看它在标准化考试上的分数。
这次交叉扫描用的是我的开源工具 repo-scan。如果你手上也有大型遗产项目需要评估，可以自己跑一个看看------一次扫描大约 10-15 分钟，不需要任何配置。
坦白说，做完这次实验之后我最大的感受不是"哪个 AI 更好"，而是：我们对 AI 的信任边界需要重新校准。
跑分各有所长，给同一份代码打的分却天差地别。如果你把 AI 的代码审计结论当成最终判断而不是参考意见，你迟早会被它漏掉的那些雷炸到。
一个 AI 的审计，做了一半。两个 AI 的交叉验证，才是完整的。
作者：10年+码农，曾任某互联网大厂技术专家。常年专注于原生应用和高性能服务器开发、视频传输和处理技术以及AI个人生产力研究。热爱健身，情商为零
公众号：海滨code | 交流请加WX：hbstream（个人主页：https://haibindev.github.io/），转载请注明作者和出处