本文首发于 note.sichenai.cc，原文链接：note.sichenai.cc/articles/ai…
AI 写的方案、代码、文档，做完它说「已完成」「已测试」，你敢直接验收吗？
我建议别。过去这两周我用自研的对抗性审查流程做了三场「让 AI 审 AI」的实测，结果很有说服力：
- 第一场，抓到 AI 把我的需求理解反了（我抱怨结构重复，它给我沉淀了固定模板）
- 第二场，发现同源盲区：同一个 AI 审自己看不出问题，换一个 AI 复审立刻新增 8 个发现
- 第三场，系统性审出一份交付物的 2 个一般问题和 5 个提示问题，有几条恰恰是它自己声明「已处理」的
这套流程不是玄学，它有固定打法：需求符合性矩阵、声明证据链、四维破坏测试。这篇文章拆开讲，末尾给你可以直接上手的最小版本。
为什么需要「AI 审 AI」
先说问题背景。AI 交付的天然风险不是「能力不行」，而是它的完成声明不可信。
我踩过最典型的坑：AI 做完一个任务，说「已测试、已修复」，但实际没跑过、或者跑过但环境不对。这类问题，我踩坑总结出了六种：
| 失效模式 | 典型表现 |
|---|---|
| 幻觉 | 编造不存在的 API、配置项、引用，还一本正经 |
| 需求缩水 | 5 条约束只做了 3 条，还不说 |
| 虚假完成声明 | 说「已测试」，但没有可复核的证据 |
| 过度工程 | 简单需求引入复杂抽象，每层都多余 |
| 谄媚隐藏权衡 | 只给用户想听的路线，不给真实代价 |
| 上下文遗忘 | 后半段忘了前半段的约束 |
传统人工验收靠「信人不信 AI」，但 AI 的交付物动辄几百行代码、几千字文档，人很难逐条核对。这时候让 AI 去审 AI，等于多一道独立检查，而且它真的能抓住人容易漏的东西。三场实测证明了这一点。
第一场：抓到需求做反（8/17）
这场最戏剧性，也最适合理解对抗性审查的威力。
那天我在改一份「平台发文规则手册」。我随口说了句「实操手册里每次写作结构一样，是个问题」，本意是抱怨，希望以后每篇别再用同一个模板。
负责的 AI 听完，干了件让我哭笑不得的事：它把「写作结构固定」升级成了正式规范，写进了手册，还标注「已沉淀」，直接把我的抱怨做反了。
对抗性审查的「需求符合性矩阵」要求逐字引用原始需求，对照交付物。一对照就现形了：
| 原始需求（逐字） | 交付物实际做的 | 判定 |
|---|---|---|
| 「实操手册中，每次的写作结构是一样的」 | 把固定结构固化为正式模板 | 理解反了（需求缩水） |
人的直觉会顺着 AI 的思路走，觉得「也没错啊」；但矩阵强制你回到原话，差异立刻暴露。这场审查还顺带抓出 2 个小问题，整场一共 3 个问题，最要命的就是需求理解反了。
第二场：发现同源盲区（8/16）
这场发生在对抗性审查流程自己身上，最有方法论价值。
我在设计这套「AI 审 AI」的流程时，先让 AI 自审了一遍，产出 8 项发现，看着挺全面。但我不放心，切到另一个模型（GLM-5.3）做异源复审，结果它又新增 8 项发现，全部是新的，其中包括两个结构性大问题：评分量规空洞（等级标准没有明确依据）、解释权循环（用交付物自己解释自己）。
这就是同源盲区：同一个模型审自己，容易共享同样的盲区，它漏掉的东西自己也想不到。换一个模型、甚至换一个宿主，盲区才会暴露。
所以这套流程的实战用法里，重要交付物我建议至少做一次异源复审。同源自审拿到的结论，关键发现建议再找个别的 AI 复核。
第三场：系统性审出 7 个问题（8/18）
这场是完整版审查，对象是一个我常用的「模型接入」skill（model-connector v1.4）。
审查结论：没有致命问题，但有 7 个待改进项（2 个一般问题 + 5 个小问题）。最有价值的不是数量，而是它审出了AI 自己声明过「已处理」的问题：
- 多模态探测规则自相矛盾：一处说「多模态一律探针」，另一处说「按需」，真按快路径跑会跳过关键探测
- 输入上限零探针：只测输出上限，输入窗口被厂商悄悄缩小没人知道
- 注册表写入后没回读，出现重复别名（「kimi k3」被写了两遍）
- 匹配规则方向歧义、JSON 损坏无兜底、分发会泄露私有端点
其中「写后没回读」这条，直接催生了我后来一直沿用的纪律：数据文件写完必须回读校验。那周我靠这个纪律当场抓回两次写坏的配置，一次是重复别名，一次是 JSON 内容损坏。写后不验，就是虚假完成声明的温床，这条我现在当红线用。
审查完修复，这个 skill 从 v1.4 升到 v1.5.0，问题清零后我才敢继续用。
三场战果总表
| 场次 | 时间 | 审查对象 | 触发方式 | 发现问题 | 最大价值 |
|---|---|---|---|---|---|
| 1 | 8/17 | 发文手册改动 | 同会话自审 | 1 个关键问题 + 2 个小问题 | 抓到需求理解反了 |
| 2 | 8/16 | 审查流程本身 | 自审 + 异源复审 | 自审 8 项，异源复审再新增 8 项 | 实证同源盲区 |
| 3 | 8/18 | model-connector skill | 另一对话触发 | 2 个一般问题 + 5 个小问题 | 审出「已声明处理」的问题，催生写后必回读纪律 |
你要怎么用：最小上手版
不需要先设计整套流程，三步就能开始：
- 给 AI 一个审查者角色。用一句指令启动：以攻击者视角审查下面这个交付物：找出逻辑漏洞、边界条件、不成立的隐含假设；对每句"已完成/已测试"的声明，追问证据。
- 提供三方输入。审查效果取决于输入完整性：原始需求（原话，别改写）、交付物（代码/文档全文）、AI 的完成声明。缺哪个就明说缺哪个，别脑补。
- 要结构化输出。至少包含：需求符合性矩阵（原话逐条对照）、问题清单（每条带「从哪进入 → 触发什么 → 造成什么后果」）、置信度标注（高/中/低）。没有攻击路径的问题不用列，宁可少不可凑。
想更省事，可以直接用我开源的对抗性审查 skill（GitHub：sichenai/sichen-skills，npx skills add sichenai/sichen-skills），它把这套流程固化成七步：三方输入收集 → 攻击地图 → 交付真实性核验 → 四维破坏测试 → 自对抗 → 结构化报告 → 复检。
边界与诚实说明
这套方法有明确的边界，写清楚免得你踩坑：
- 不能替代人工验收。AI 审 AI 输出的是风险清单，最终判断（这个能不能上线、要不要返工）得人来做。它负责帮你把问题显性化。
- 同源自审可能共享盲区。第 2 场就是证据。重要交付物，关键发现建议用另一个 AI 或另一个模型复核一遍。
- 没有工具环境的审查会降级。我在 WorkBuddy 里能读文件、跑命令、查中间产物；如果只把文档贴给网页版 AI，它的「证据链核验」会自动降级成「内部一致性判断」，这时候它如果还声称「已验证」，别信，要求它标注盲区。
- 本文实测范围：三场均为 WorkBuddy 环境 + 同源/异源模型审查，未覆盖在其他宿主（如 Claude Code、Codex）上运行本流程，那部分结论等你实测后我再补。
系列导流
上一篇复盘了「谷歌索引掉线」（第 6 篇），这篇聊 AI 审 AI（第 7 篇）。后续计划写对抗性审查在「代码验收」场景的详细拆解，关注这个系列，一起把 AI 工具真正跑通。
数据来源与实测标注（文末）
- 实测环境：WorkBuddy（版本随各场记录）+ macOS；三场审查分别发生于 2026-08-16、2026-08-17、2026-08-18
- 第 1 场：8/17「平台发文规则手册」改动验收，同会话对抗性审查，发现 1 个关键问题（需求理解反）+ 2 个小问题，ts 裁决修复
- 第 2 场：8/16 对抗性审查流程设计期，先自审 8 项，后切换 GLM-5.3 异源复审，异源复审新增 8 项全部为新发现；修复两个结构性大问题（评分量规空洞、解释权循环）
- 第 3 场：8/18 model-connector v1.4 审查，审出 7 个问题（无致命项），修复后升级 v1.5.0 并推送 GitHub（commit 371f1ce）；「写后必回读」纪律同期确立
- 工具：adversarial-review skill（对抗性审查，自研开源，仓库 sichenai/sichen-skills，2026-08-17 上架）
