L6-33：多模型对抗审查 —— 让两个AI互相攻击找出隐藏漏洞

🎯 学 gstack 的多模型对抗审查系统：不是只靠一个模型判断代码质量，而是引入外部模型（OpenAI Codex CLI）作为独立的"第二审查者"——用不同的训练数据、不同的推理模式、不同的偏见，弥合单一模型的盲点。模型越多，盲点越少。 ⏱️ 预计时间：25 分钟

💡 新手提示：多模型审查就像让两个互不相识的医生分别看你的体检报告。如果一个说没问题、另一个说有问题——这个分歧反而是最有价值的信号，说明边缘情况值得深入调查。

---

[!quote]- 📖 原Skill精要 技能名称：codex（对抗审查模式） 核心功能：与 [[L6-08-多模型交叉验证|codex]] 共享同一个 OpenAI Codex CLI 封装，本课聚焦其挑战模式——对抗模式尝试攻破你的代码。作为"200 IQ 自闭症开发者"提供第二意见，特别适合在常规审查后寻找遗漏漏洞。配合 Claude 主审查形成多模型交叉验证。 所属体系：gstack 虚拟工程团队 协作关系：在 [[L6-15-PR代码审查|review]] 的对抗审查阶段（Step 4.6 Red Team）中作为独立子 Agent 运行

§1 课程概览

codex 对抗审查是 gstack 的多模型安全验证系统。它不替代 Claude 的主审查——而是用 OpenAI Codex CLI 作为独立的"第二审查者"，以"攻击者视角"重新审查同一份 diff。核心洞见：每个 AI 模型有自己的"偏见"（训练数据不同、安全微调不同、推理风格不同），一个模型说"没问题"不等于真的没问题。两个独立模型都说"没问题"→ 置信度大幅提升；两个模型意见不一致 → 最有价值的信号（边缘情况需要人工判断）。三种协作模式（Sequential/Parallel/Confirmatory）覆盖不同规模的 diff 和不同层级的验证需求。本课通过电商秒杀系统的案例，展示 Codex 如何发现了 Claude 遗漏的致命竞态条件。

[!tip] 白话小课堂 让两个互不相识的 AI 分别审查你的代码。一个说没问题、另一个说有问题——这个分歧本身是最有价值的信号。单一模型的"偏见"就像眼镜的颜色，戴着红色眼镜看什么都偏红。Claude 和 Codex 训练数据不同、推理方式不同，它们互相填补彼此的盲点。最危险的场景不是你看到两个模型打架，而是它们都点头说"没问题"——那可能只是它们的盲点恰好重叠了。这节课教你三种协作模式：串行（先 Claude 后 Codex）、并行（同时审查）、确认（Codex 验证 Claude 的发现）。学完你会知道什么时候分歧值得深入调查，什么时候共识可以放心相信。

§2 为什么需要第二意见？——单一模型的盲点问题

每个 AI 模型有自己的"偏见"

单一模型审查的根本问题不是"模型不够聪明"，而是"模型有偏见"：

• 训练数据不同 → 对不同漏洞类型的敏感度不同。Claude 的训练数据中可能有更多 Web 安全案例，Codex 的代码训练数据中可能有更多系统级漏洞案例
• 安全微调不同 → 对同一代码的"安全判断"阈值不同。Anthropic 和 OpenAI 的安全微调策略不完全相同
• 上下文处理不同 → 可能忽视不同的边缘情况。即使处理同样的 diff，两个模型的"注意力"分布不同
• 推理风格不同 → Claude 倾向于结构化的多维度分析，Codex 在代码推理上可能更"直觉化"

多模型共识的统计学原理

一个模型说"没问题" ≠ 真的没问题（可能只是它的盲点）。两个独立模型都说"没问题" → 置信度大幅提升（两个模型的盲点重叠的概率远低于单个模型有盲点的概率）。两个模型意见不一致 → 需要人工判断（这正是最有价值的信号——揭示了边缘情况）。

Codex 在 gstack 中的四个角色

• 对抗审查：从"攻击者视角"审查 diff——以破坏系统为目标
• 结构化审查：对大型 diff（200+ 行）做系统化检查清单审查
• 独立审查：与 Claude 的结果交叉验证——标记共识和分歧
• 第二意见：当 Claude 的某个发现需要二次确认时

§3 Codex 对抗审查——攻击你自己的代码

Adversarial Review 的目标

不是"找 bug"，是"攻击"——以破坏系统为目标来分析 diff。这个思维转换是关键：正常审查问"这段代码有什么问题？"，对抗审查问"如果我是一个恶意攻击者，我会怎么利用这段代码？"

攻击者视角的检查清单

• "如果我是攻击者，我会从哪里打？"——找最脆弱的部分
• "这段代码最脆弱的部分是什么？"——输入边界、状态转换、权限检查
• "如果这部分失败了，最大影响是什么？"——爆炸半径分析
• "哪个假设一旦不成立，系统就会崩溃？"——找出代码中隐藏的假设

Codex 对抗审查的 prompt 结构

指令："像一个攻击者和混沌工程师一样思考"
读取完整 git diff
寻找：边缘情况、竞态、安全漏洞、资源泄漏、静默数据损坏
输出分类：
  - FIXABLE：知道怎么修（提供 diff 格式的修复）
  - INVESTIGATE：需要人的判断（标记出来）
结尾必须有：Recommendation: <action> because <one-line reason>

关键设计细节：

• 5 分钟超时：对抗审查应该快速和聚焦——不是全面的代码审计，而是针对性的攻击尝试
• 纯信息性：从不阻止 ship——Codex 的发现是信息输入，最终决策权在人
• 独立性：Codex 看不到 Claude 的审查结果（无偏见——避免"锚定效应"）

§4 Codex 结构化审查——大变更的系统检查

触发条件

DIFF_TOTAL >= 200 行（或用户手动指定）。200 行的阈值基于工程经验——超过 200 行的 diff，人类审查者会开始"跳读"，AI 也需要更系统化的方法。

结构化审查的执行

• codex review --base <base-branch> → 更系统化的检查清单
• 检查 [P1] 标记（高优先级发现）
• 发现 [P1] → GATE: FAIL → AskUserQuestion：A) 调查并修复 / B) 继续（接受风险）

与 Claude 审查的互补

• Claude 的 /review：7 个专家子 Agent 并行审查（Security、Performance、Architecture...）
• Codex 审查：独立的全量审查，不同的"偏见"
• 交叉验证：两个模型都标记的问题 → 高置信度（优先修复）
• 单一模型标记的 → 需要人工判断

跨模型综合（Cross-Model Synthesis）

• 多来源一致的发现（高置信度）→ 优先修复
• Claude 结构化独有的发现 → 列出（来自多维审查视角）
• Claude 对抗独有的发现 → 列出（来自安全专项审查）
• Codex 独有的发现 → 列出（来自不同模型的视角——最可能包含遗漏漏洞）

§5 Codex 与 Claude 的三种协作模式

模式 1: Sequential（串行——默认）

Claude 先审查 → 记录发现 → Codex 后审查 → 独立形成意见（看不到 Claude 的结果）→ 合并结果 → 标记共识和分歧。适用：标准 PR（< 200 行 diff）。Sequential 确保 Codex 完全不受 Claude 结果的影响——审查的独立性是关键。

模式 2: Parallel（并行——大型变更）

Claude 和 Codex 同时审查，互不干扰，独立上下文。合并结果时按"指纹"（finding fingerprint）去重。适用：大型 PR（200+ 行 diff）。Parallel 的优势是速度——两个模型同时工作，总时间 = max(Claude 耗时, Codex 耗时) 而非 sum。

模式 3: Confirmatory（确认——单问题验证）

Claude 发现了一个问题但不确定（如"这可能是误报"）→ codex exec "审查这个具体的代码片段: <snippet>" → Codex 独立判断：Bug / Not a bug / Uncertain。适用：高风险的单一发现需要二次确认。Confirmatory 减少 Claude 误报带来的"审查疲劳"。

§6 模型间分歧——最有价值的安全信号

四种分歧/共识场景

Claude 标记为 CRITICAL，Codex 说没问题 两种可能：a) Claude 误报（考虑了不存在的攻击路径）；b) Codex 遗漏（不同的训练数据导致对漏洞不敏感）。行动：人工审查——不能盲目信任任何一方。

Codex 标记为 CRITICAL，Claude 说没问题 最有价值的场景——被主审查者遗漏的漏洞。Codex 的"偏见"恰好捕捉到了 Claude 的"盲点"。行动：优先人工审查——这是引入 Codex 的核心价值。

两者都标记为 CRITICAL 置信度最高——两个独立模型一致同意。行动：优先修复，不需要人工判断。

两者都说没问题 不能 100% 放心——两个模型可能共享盲点（如果训练数据有重叠）。但相比单一模型，置信度大幅提升。

§7 结构拆解

§8 电商 Skill 案例：电商促销规则代码多模型对抗审查

🛒 实战案例：某电商平台开发"满减+优惠券叠加"促销引擎（计算订单最终价格），涉及多券叠加的计算顺序、满减条件判断的边界值、以及"满200可用"券在叠加时的价格判断基础（原始价 vs 折后价）。单一模型审查可能遗漏竞态或逻辑漏洞，使用Claude+Codex双模型对抗审查。

• Claude审查发现：审查src/pricing/promotion-engine.ts（约1200行）——确认3个PASS项（券面额从数据库读取防篡改、满减优先级按折扣率排序正确、过期券自动过滤逻辑正确）、2个WARN项（满减条件判断if (total >= threshold)中total是折后价还是原始价不够明确、多券叠加顺序有个隐含假设未文档化）、1个INVESTIGATE项（并发场景下同一张券是否可能被多次使用——checkCouponUsed()和markCouponUsed()之间无锁）。整体评价：代码逻辑正确，但并发安全和文档清晰度需改善。
• Codex对抗审查发现（"像一个攻击者思考促销系统"）：Codex发现了Claude标记为PASS的隐患——(1)满减条件判断在浮点数环境total >= threshold中，total累积自多个折后价浮点数，99.99 + 50.01 = 150.00000000000003 >= 150为true但实际是<150的边界→虽不影响正确性但隐藏了精度隐患；(2)更关键的是——多券叠加时某张券的"满200可用"中的200是原始价而非折后价，但代码在应用第一张券后将total更新为折后价，后端券判断total >= 200可能在折后价<200时错误拒绝用户→这是一个业务逻辑bug，在高比例折扣时触发（如第一张券打5折，200元商品→折后100元，后端"满200可用"的券被错误拒绝）。
• 跨模型综合与决策：Claude从"代码是否正确实现了业务逻辑"角度审查（代码结构正确），Codex从"攻击者/恶意利用"角度审查（捕获到业务逻辑假设错误）。跨模型交叉打分——发现1(满减浮点数边界) Claude PASS + Codex WARN/共识分歧→建议改进精度处理；发现2(多券叠加原始价vs折后价) Claude WARN + Codex FAIL/强烈共识→这是一个Bug，必须修复。修复方案：(1)促销规则文档化"满减条件判断基于原始价，券叠加后价格作为展示但不影响条件判断"；(2)在代码中添加显式注释和类型标记区分originalTotal和discountedTotal。修复后重新双模型审查→Claude PASS + Codex PASS一致通过。

🔑 启示：单一模型审查的可靠性取决于模型的"偏见覆盖范围"。Claude擅长逻辑结构审查（"代码写对了吗"），但在"攻击者会怎么利用这个逻辑漏洞"方面不如Codex的攻击性思维prompt。多模型对抗审查不是让两个模型"投票"——而是发现分歧：分歧点恰好揭示了代码中最有风险的设计假设。修复后的共识才是可靠的"安全认证"。

[!info] 参考来源 多模型对抗审查理念参考了 OpenAI's Codex CLI 的代码审查功能和 Anthropic's adversarial testing methodology。促销引擎并发安全参考了多个电商高并发场景的经典架构方案。

§9 掌握检验

Q1：在多模型审查中，"两个模型意见不一致"为什么被认为是最有价值的信号？

• A) 因为不一致可以减少代码合并的时间
• B) 因为分歧揭示了单一模型可能存在的盲点——需要人工判断的边缘情况，这是引入第二模型的核心价值
• C) 因为不一致可以自动选择更宽松的判断
• D) 因为不一致意味着两个模型都失败了

Q2：Codex 的结构化审查在什么条件下自动触发？

• A) 任何时候都触发
• B) DIFF_TOTAL >= 200 行（或用户手动指定）
• C) 只在安全相关的 PR 上触发
• D) 只在 Claude 审查失败时触发

Q3：Codex 的对抗审查（Adversarial Review）和结构化审查（Structured Review）的核心区别是什么？它们分别在什么场景下使用？对抗审查中为什么指令是"像一个攻击者一样思考"而非"检查代码质量问题"？

Q4：秒杀场景中，"WHERE stock > 0 + UPDATE"和"SELECT ... FOR UPDATE + UPDATE"在并发行为上有何本质区别？请描述 1000 个请求同时到达时，两种方案各自的执行流程和最终结果——并解释为什么"原子操作"（WHERE stock > 0）在数据库层面是原子的，但仍然不够。

Q5：在电商秒杀案例中，Claude 审查判断"库存原子操作 ✓ PASS"，但 Codex 对抗审查判断"FAIL——WHERE stock > 0 不足以防超卖"。这是一个典型的"主审查者 PASS，第二审查者 FAIL"的场景。请分析：Claude 为什么可能给出 PASS，Codex 为什么能看到 Claude 遗漏的问题？这个案例对"单一模型审查"的可靠性有何警示？

Q6：如果 Codex 不可用（API 密钥过期 / 网络不可达），/review 系统中哪些审查阶段会受影响？哪些阶段仍然独立工作？在 Codex 不可用的情况下，是否应该阻止合入（/ship）——还是应该降低审查完整度（记录"Codex 不可用"但允许合入）？请考虑以下场景：一个包含支付逻辑修改的 PR，Codex 不可用。

§10 答案

点击查看答案

Q1：B —— 两个独立模型的一致意见 = 高置信度（盲点重叠的概率低），两个模型的分歧 = 边缘情况值得人工深入调查。分歧本身不是答案——但它是"这里有问题需要看"的最强信号。

Q2：B —— 结构化审查在 DIFF_TOTAL >= 200 行时自动触发（或用户手动指定）。

Q3：核心区别：对抗审查的指令是"像一个攻击者和混沌工程师一样思考"——目标是破坏系统，寻找"如果我是攻击者我会从哪里打"。结构化审查的指令是"系统性检查代码质量"——目标是全面检查所有维度。对抗审查用于寻找漏洞（任何大小 diff），结构化审查用于大型 diff（200+ 行）的系统检查。为什么是"攻击者视角"？因为开发者审查自己代码时会自然地"善意假设"（假设输入是合法的、网络是可靠的），攻击者视角刻意打破这些假设——它能发现开发者"无意识信任"的漏洞。

Q4：本质区别——数据库隔离级别。WHERE stock > 0 方案：1000 个请求同时读取 stock=1 → 每个都通过 WHERE stock > 0 检查 → 每个都执行 UPDATE → 1000 个订单，库存变成 -999。WHERE stock > 0 和 UPDATE 各自是原子的，但"读取 + 判断 + 写入"这个组合操作不是原子的——这是典型的 check-then-act 竞态条件。SELECT ... FOR UPDATE 方案：请求 A 执行 SELECT FOR UPDATE → 锁住那一行 → 请求 B 被阻塞 → A 执行 UPDATE（stock 从 1 变 0）→ 提交事务 → 释放锁 → B 的 SELECT FOR UPDATE 返回 stock=0 → WHERE stock > 0 失败 → 不创建订单。关键区别：FOR UPDATE 将"读取 + 判断 + 写入"变成了一个受锁保护的原子序列。

Q5：Claude 可能给 PASS：在它的训练数据中，WHERE stock > 0 在低并发场景下是有效的（大多数应用不是秒杀级别）。Claude 从"代码是否正确实现了业务逻辑"的角度评估。Codex 能看到：训练数据可能包含更多"高并发下的数据库隔离级别"的讨论，且"攻击者思维"prompt 促使其思考"在极端条件下这个条件会不会失效"。警示：单一模型审查的可靠性取决于模型的"偏见覆盖范围"——Claude 擅长代码逻辑审查，但在极端并发场景的数据库行为判断上可能不够深入。第二模型填补了这个偏见空白。

Q6：受影响的阶段：/review Step 4.6（Red Team / 对抗审查）、跨模型交叉验证、结构化审查（大型 diff）。独立工作的阶段：/review 的 7 个 Claude 子 Agent 完全独立运行。支付 PR + Codex 不可用的决策：不应该阻止合入——Claude 的 7 个专家子 Agent 仍然提供了足够深度的安全审查。但应该：①在审查仪表盘上标记"Codex 对抗审查未运行"；②建议人工安全审查；③在 Codex 恢复后对已合入的支付代码运行回顾性对抗审查。核心原则：缺失一个审查层不应该阻止必要的业务进度——但应该显式标记风险的增加。

（5/6 通过）

---

延伸阅读

• [[L6-32-五层安全防护盾|上一课：五层安全防护盾]] —— 运行时安全的多层防护
• [[L6-34-AI工具自升级|下一课：AI工具自升级]] —— 让工具自己保持最新
• [[L6-15-PR代码审查|相关：PR 代码审查——Claude 的主审查流程]] —— Codex 在 review Step 4.6 中运行
• [[L6-08-多模型交叉验证|相关：Codex 基础用法]] —— Codex CLI 的通用封装