前几天我把手头项目的 12 个业务模块完整打包同一份提示词、同一批代码分别丢给 Claude Code 和 Codex 做代码审计。折腾了整整两天拿到两份报告的时候我一度怀疑它们读的是两个不同的仓库——12 个模块里两个模型只在 3 个模块上得出了完全一致的结论。剩下 9 个全是各说各话有的问题一个狠抓不放、另一个完全无视有的一个标严重漏洞、另一个直接写无风险。这篇文章把整次实验的原始记录整理出来包括实验设计、提示词模板、逐模块结果对比、分歧原因拆解以及把这套玩法固化到团队流程里的具体做法。想用 AI 辅助代码审计、又担心它不靠谱的开发者看完应该能少走不少弯路。1. 实验背景为什么我会拿两个 AI 去审同一批代码1.1 项目情况与审计动机这次被审计的是一个中等规模的电商后台服务Go MySQL Redis 的技术栈模块之间靠内部 HTTP 接口通信。整个工程不算特别大但业务模块拆得比较散核心的业务域有 12 个用户认证、订单中心、支付回调、库存扣减、商品管理、文件上传、消息通知、缓存管理、定时任务、日志采集、报表服务、对外 Webhook。触发这次审计的真实原因有两个。第一是上线前安全自查我们之前出过一次接口越权的事故老板要求所有核心模块在上线前完成一轮代码安全 review。第二是下半年要动一次比较大的重构需要一份哪里埋着雷的摸底清单免得重构的时候把老问题带进新代码。按常规做法这 12 个模块的人工 review 要让两个 senior 干差不多一周。时间不够我就决定先让 AI 做第一轮扫描把可疑点全部标注出来人再去复核。这个思路本身没问题但我没想到的是AI 扫出来的结果会乱成那个样子。1.2 为什么选 Claude Code 和 Codex而不是直接用网页版这次实验选工具的时候我其实没怎么纠结。网页版对话模型虽然也能看代码但每次都要把代码复制粘贴进去面对 12 个模块几十个文件根本不现实。Claude Code 和 Codex 都是命令行形态的编码助手能直接读工程目录、跨文件理解调用关系也方便用脚本批量驱动。更重要的是这两个模型背后的底座差别够大。Claude 在长上下文理解和推理链上的口碑一直不错Codex 则是 OpenAI 围绕在真实代码库上工作这个场景专门训练的。我当时想的是两个模型一个偏推理派、一个偏工程派交叉出来的结果应该比单模型更稳。这个判断方向是对的但实际结果给了我一记闷棍——差异大得离谱是好事也是坏事好在能互相补充坏在你要花大量精力去判断到底谁是对的。选择双模型交叉还有一个核心理由任何单模型都有系统性盲区。如果只用一个模型它漏掉的问题你根本不会知道。两个模型同时漏报的概率远低于单个模型漏报的概率这跟代码 review 里双人复核的逻辑一模一样。2. 环境搭建与审计方案设计2.1 两个工具的安装与基础配置环境准备这部分没什么玄学按官方文档走就行。Claude Code 目前是 npm 包安装命令一行搞定npm install -g anthropic-ai/claude-codeCodex 也一样装完以后在项目根目录跑codex就能进入交互式终端。两个工具都需要在第一次启动时完成账号授权登录登录成功后会在本地生成凭据文件后续调用就不用重复认证了。我强烈建议统一指定模型版本不要用默认模型。AI 工具的模型版本经常悄悄更新同一套提示词在不同版本上的表现差异非常大。我这次实验里Claude 侧固定了 claude-sonnet 系列Codex 侧固定了 gpt-5-codex 系列按当时的可用模型来选。这样至少能保证对比的是模型能力的差异而不是版本波动的噪声。2.2 提示词模板AI 审计的第一步是管住嘴这次实验我最满意的一步是提前写好了一份结构化的审计提示词。很多人用 AI 审代码上来就一句帮我看看这个模块有没有漏洞模型就开始自由发挥了——想到哪写到哪严重级别乱标格式五花八门。两份报告根本没法对比。我用的模板是这样的你是一名资深代码安全审计专家。现在请对指定模块做一次完整审计。 项目背景电商后台服务技术栈 Go MySQL Redis模块间通过内部 HTTP 接口通信。 审计范围仅限本次提供的目录和文件不要臆测外部系统的行为。 输出要求 1. 严格按以下分类输出安全漏洞、可靠性问题、性能问题、代码质量问题 2. 每个问题必须包含文件路径:行号、严重程度严重/高/中/低、问题描述、修复建议 3. 判断为严重的问题必须同时给出可利用路径或影响范围 4. 某个分类没有发现问题请明确写无 5. 无法确定的问题标注存疑并说明需要人工确认的点 6. 最后用 JSON 数组汇总所有问题字段为 file、line、category、severity、title、description、suggestion这份提示词的核心不是让模型认真审而是给它上规矩。限定范围是防止它脑补外部系统要求行号是为了拿到可定位的证据分级标准是为了让后续的优先级排序可行强制 JSON 输出是为了方便程序化处理。2.3 审计维度与严重度定义提示词里提到的四个分类不是随便写的。在让 AI 动手之前我先给团队内部定了一套审计维度保证审出来的东西能直接用于决策分类关注点典型例子安全漏洞越权、注入、敏感信息泄露、认证缺陷缺少鉴权、硬编码密钥、路径穿越可靠性问题错误处理、并发安全、资源释放空 catch、竞态条件、连接泄漏性能问题查询效率、阻塞调用、无界增长N1 查询、锁粒度太粗、大事务代码质量可维护性、重复代码、反模式魔法数字、超长函数、注释撒谎严重级别我也做了明确的锚定严重 可能导致数据泄露、任意代码执行或资金损失高 特定条件下会出故障大概率影响线上中 存在隐患当前未必触发低 质量问题不直接影响功能。这里有个关键经验如果你不把严重的含义说清楚AI 会把一个风格问题标成高危把真正能打穿系统的漏洞标成中风险报告的参考价值直接归零。3. 同题异构两轮审计结果全量对比3.1 Claude 的报告画像先说 Claude 这边。它的报告整体风格是重推理、轻清单。对于每个模块它都会先写一段对这个模块职责的理解然后按它自己的逻辑推导风险点。好处是当它发现问题时往往能把调用链讲得比较完整比如这个接口缺少权限校验而它又被 X 服务和 Y 服务调用所以攻击者可以通过 Z 路径绕过去。这种带有攻击链描述的报告人工复核起来特别舒服。坏处也很明显慢而且啰嗦。12 个模块跑完Claude 生成了将近 9000 行的分析文本里面大量内容是这个模块的功能是什么我认为这里存在潜在风险这类描述性文字。真正能落成缺陷条目的大概只占三分之一。另外它对代码质量问题特别敏感经常把命名不规范函数太长这种风格类问题塞进报告里需要额外花时间过滤。Claude 在这次审计里最有价值的一个发现是在日志采集模块——它指出敏感数据明文手机号和订单金额被直接写进了操作日志而且没有脱敏。这个是我们之前一直没意识到的合规隐患后来确认是真实问题已经在修了。3.2 Codex 的报告画像Codex 这边完全是另一个路子。它的报告风格是清单式打击结构极其整齐每个问题都规规矩矩地按文件、行号、分类、严重度输出几乎没有废话。JSON 输出的格式稳定性非常好解析起来零负担。这在批量处理场景下是巨大的优势我后来写的合并脚本基本就是为它量身定做的。但清单式输出的代价是Codex 的模式匹配倾向非常明显。它特别容易套用已知漏洞模板有些问题它其实是靠看着像判断的而不是真正理解了代码逻辑。最典型的是商品管理模块它报了一个SQL 注入我拿去复核的时候发现那句查询用的是参数化写法注入根本不可能成立——这就是一个典型的模式误判false positive。不过 Codex 也有独门发现。库存扣减模块里的并发竞态条件它准确报出来了描述里甚至提到了先查后扣不是原子操作高并发下会出现超卖。这个 Claude 完全没提。人工复核后确认是真实存在的严重问题而且比我们预想的触发条件还容易。3.3 逐模块核对唯一共识的 3 个模块为了对比我把两份报告按模块拆开、逐条对齐结果一看就愣住了。完整对比如下模块Claude 结论Codex 结论是否一致用户认证JWT 硬编码密钥、越权JWT 硬编码密钥、弱口令策略核心一致支付回调签名校验缺失、重放风险签名校验缺失核心一致文件上传路径穿越、无大小限制路径穿越核心一致订单中心状态流转无幂等分布式锁粒度问题完全分歧库存扣减未发现严重问题竞态条件超卖完全分歧商品管理无 SQL 注入SQL 注入完全分歧Codex 误报消息通知Token 泄露到前端无风险完全分歧Claude 误报缓存管理缓存穿透可接受缓存穿透高风险严重级别分歧定时任务无问题Cron 周参数写错完全分歧日志采集敏感信息明文落日志无问题完全分歧报表服务N1 查询性能问题无问题完全分歧对外 Webhook重放攻击风险无问题完全分歧两份报告完全重合的只有 3 个模块用户认证、支付回调、文件上传。有意思的是这三个模块的问题恰恰是安全领域最经典的教科书漏洞——硬编码密钥、签名校验缺失、路径穿越。这类问题在训练语料里出现频率极高所以两个模型都认识它们。这也给了我一个重要提示AI 审计对高频、经典的漏洞模式很敏感但对业务定制、需要上下文推理的漏洞它的表现就非常不稳定。3.4 分歧最大的几个模块案例还原我挑三个典型的展开说给大家一个直观感受。库存扣减模块是这次最打脸的一个。Codex 准确报出了竞态条件Claude 居然写的是未发现严重问题。事后复盘Claude 给出的判断依据是这个模块使用了数据库事务应该能保证一致性——它看到了事务但没有深入去想先 select 再 update这个非原子操作在并发下的真实行为。这就是单模型的盲区要不是有 Codex 的交叉验证这个超卖漏洞就带着上线了。消息通知模块正好反过来。Claude 报了一个Token 泄露到前端理由是前端代码里出现了 API Token 的引用。可我仔细顺着调用链查了之后发现这个模块根本不是给浏览器用的它是个纯后端推送服务那个前端变量实际是后端 mock 客户端。Claude 因为没看清调用关系把一个内部服务误判成了暴露面。这类误报特别消耗人工精力因为你必须逐个去核实它的推理前提。报表服务模块则是一方漏报的典型。Claude 报了一个 N1 查询问题循环查数据库、一次报表生成要打几百次 SQL这个在数据量上来之后必然是事故。Codex 完全没发现推测原因是它只扫了入口文件没有往深处的 repository 层走。这说明 Codex 在处理跨层性能问题时容易失明。4. 分歧拆解AI 审计为什么会各说各话4.1 训练语料与风险判断标准的差异两个模型对同样代码做出完全不同的判断最底层的差异在训练语料和微调目标上。Codex 的训练数据里高质量的 GitHub 代码和漏洞修复补丁占了很大比重它天然更熟悉什么样的代码长着漏洞的样子所以它倾向于按已知漏洞模式做快速匹配误报率高一些。Claude 的训练更侧重长文本推理和逻辑一致性它会先构建一个对系统的理解再下判断所以漏报率低但误判前提的风险高。这本质上不是谁比谁强的问题而是两个模型对风险这个词的定义不同。Codex 看到像漏洞就报Claude 觉得在既定业务逻辑下不构成风险就不报。在没有统一评分标准的情况下同一段代码在它们眼里是两种完全不同的东西。4.2 幻觉与漏报的常见形态大模型生成式的本质决定了它会在信息不足时填空。AI 审计里最典型的幻觉有三种一是引用不存在的行号它给出的位置在文件里根本对数不上二是把安全的代码判成漏洞比如把参数化查询说成 SQL 注入三是编造根本不存在的调用关系为了让自己编的漏洞听起来合理。我的经验是只要要求它必须贴出代码片段作为证据幻觉数量会明显下降——能贴出真实代码的幻觉更容易被识破。漏报则恰恰相反模型因为某种原因没看到问题可能最后会为了报告的完整性写一句无问题。最危险的就是确定性漏报模型对一个问题给出了自信的安全结论如果你不去复核就真的放过去了。4.3 上下文窗口与管中窥豹效应这次实验里让我最头疼的一个坑是长文件的上下文截断问题。我们的报表服务有个核心文件接近 3000 行两个模型在处理它的时候都出现了前面审得细致、后面草草带过的现象。后来我确认了当文件超过模型的上下文限制工具会做截断模型等于只看了文件的前半段。它在不知道后半段的情况下依然会给出已审计完毕的结论。对付这个问题没有捷径只能对文件做切片。按函数或按业务子块把大文件拆成若干部分分别跑审计最后合并结果。虽然麻烦但至少不会漏掉大段代码。4.4 提示词对结果的放大作用我还做过一个小实验把提示词里请重点检查安全漏洞改成请检查所有潜在风险结果两个模型的输出都会发生剧烈变化而且变化方向基本不可预测。这提醒我一件事——用 AI 做审计提示词就是审计范围定义。同一个模型、同一段代码换个问法就是两份完全不同的报告。所以这次实验里我特意保持提示词完全一致就是为了让模型差异成为唯一变量。如果你要对比工具这一步绝对不能省。5. 把 AI 审计变成可落地的流程5.1 双模型交叉 人工复核的标准动作整个实验折腾完之后我把这套方法固定成了团队里可复用的标准审计流程核心就是双模型交叉 人工复核第一步准备模块清单和代码切片。每个模块控制在 2000 行以内超了就按子模块拆。第二步给两个模型并行发同一份提示词得到两份结构化报告。第三步用脚本合并去重把两个模型的输出汇成一张总表。第四步人工复核优先从双方共识项开始再处理单方高危和存疑项。第五步修复后复测把修复结果反馈回去确认问题消失。这个顺序不是随意排的。双方共识项大概率是真实问题先解决性价比最高单方高危项需要人判断谁更可信因为这时候没有参照物只能靠经验存疑项和低级别项可以往后放甚至先不进迭代。5.2 结构化输出与自动合并要让两个模型的输出可以合并必须强制 JSON 输出。我在提示词里要求的 JSON 字段是 file、line、category、severity、title、description、suggestion拿到以后用一个很简单的 Python 脚本就能对齐import json def load(path): with open(path) as f: return json.load(f) claude load(claude_report.json) codex load(codex_report.json) merged {} for item in claude codex: key (item[file], item[line], item[title]) if key not in merged: merged[key] { claude: [], codex: [] } source claude if item in claude else codex merged[key][source].append(item) for key, entry in merged.items(): tags [] if entry[claude] and entry[codex]: tags.append(双方共识) else: tags.append(单方发现) print(key, tags)这个脚本也就 20 行但解决了一个核心问题把两个模型说人话的报告变成了可去重、可排序、可追踪的缺陷清单。我强烈建议所有做 AI 审计的人都走这一步不要肉眼看两份报告再手动合并。5.3 把审计做成不用思考的流水线到这一步这套东西已经从一次性实验变成团队基建了。我把模块清单、提示词模板、合并脚本全放进了工程目录下的audit/文件夹之后每次跑审计只需要执行一个统一的入口脚本# 1. 对每个模块生成切片清单 python audit/slice_modules.py # 2. 调用 Claude Code 逐模块审计 claude -p $(cat audit/prompt.md) --output-format stream-json audit/claude_report.json # 3. 调用 Codex 逐模块审计 codex exec --full-auto -c $(cat audit/prompt.md) audit/codex_report.json # 4. 合并、去重、生成缺陷总表 python audit/merge_reports.py现在团队里做线上发布前的安全自查不再需要专门拉两个人坐一起翻代码了。先跑一遍流水线拿到总表之后相关模块负责人只需要对自己负责的那部分做人工确认。整个流程从原来的一周压缩到一天以内而且每一步都有记录出了事能追溯。5.4 一个我实测有效的排险顺序拿到合并后的缺陷总表人工复核顺序我建议按这个来先看两个模型都报的双方共识高危这种基本可以直接确认并进入修复流程再看单方高危重点分析报出方是谁——如果是 Codex 报的先怀疑误报如果是 Claude 报的认真读一遍推理链它误报少但如果漏报了你也很难发现最后才是中低级别和存疑项这些可以攒着一起处理。这套排险顺序我实测下来效率很高。它不是一个简单按严重程度排序的过程而是把模型的可靠性差异也纳入了优先级判断。6. 常见问题与避坑实录6.1 问题速查表把这次实验里遇到的典型问题整理成速查表方便大家直接对号入座症状原因对策报告里引用了不存在的行号模型幻觉强制附代码片段人工抽检 10%同一问题两个模型级别相反判断阈值不同统一评分标准以人定级长文件越审到后面越潦草上下文截断按函数/子模块切片分批审计把参数化 SQL 报成注入模式匹配误判让模型引用实际代码不只看表面只报代码风格不报安全风险提示词缺优先级明确安全优先并给出分级定义两个模型都没发现的问题系统性盲区增加第三人复核或换一个模型再跑报告格式五花八门没有约束输出强制 JSON 输出用脚本合并改了代码之后反复报同样问题模型读的是缓存清空会话重新启动审计6.2 用真金白银换来的几条实操心得第一不要让 AI 直接改代码。这次实验我试过让 Claude 顺手修复它自己报的问题结果它改出来的代码引入了两个新问题而且都是它自己报告过的同类问题。AI 审计的价值在发现问题修复还是要落到人手里改完再交给 AI 复测。第二对 AI 的无问题结论保持警惕。我给 12 个模块分别配了一位AI 独立审计员之后发现凡是涉及跨文件调用链的问题AI 的漏报率会显著升高。如果一个模块逻辑复杂、调用链深哪怕 AI 写了无问题我也建议至少让一个不同模型再跑一遍或者直接人工翻关键文件。第三审计结果一定要留档。我现在每次跑完审计都会把两份原始报告、合并后的缺陷总表、人工复核记录完整存档标记好对应的代码 commit 号。这样做的好处是下次跑审计可以直接对比上次的问题是否已修复、有没有新增问题也让整个审计过程对团队和领导可解释、可追溯。第四也是最核心的一点AI 审计真正适合干的角色是第一道粗筛子它负责在人工介入之前把可疑点全部捞出来而不是充当最终的裁判。你把它当裁判它就会用幻觉和不稳定判断坑你你把它当筛子它是这个时代效率最高的一把筛子没有之一。我个人用得越久越确认一个体会这类模型在代码审计里的价值不是替代人而是把人从通读全部代码这件事里解放出来。它们俩吵得越凶恰恰说明这一行代码越值得人去看一眼。如果你现在正准备把 AI 审计引入团队我的建议是从小范围开始先选两三个模块跑通双模型交叉 人工复核的闭环把提示词、切分规则、合并脚本都固化下来再逐步扩大到全量模块。等这个流水线跑顺了你就知道两个 AI 吵一架这件事到底能帮你省下多少时间。