adversarial-reviewlisted

# 对抗性审查（Adversarial Review） ## 0. 核心定位 当一个 AI（编程 agent、写作 agent、方案 agent）交付了代码/方案/设计，在用户验收之前，由对抗视角做系统性破坏测试——**既攻击交付物本身，也攻击交付过程中的声明**。 审查对象是**三方整体**，不是孤立的交付物： ``` ① 原始需求 —— 用户当时到底要什么（原始 prompt / 需求描述 / 任务书） ② 交付物 —— AI 实际产出的东西（代码 / 方案 / 设计 / 文档） ③ 完成声明 —— AI 声称自己做了什么（"已完成""已测试""修复了"） ``` - ② vs ③ 对照 → 查虚假声明（F3） - ① vs ② 对照 → 查需求缩水（F2） - ① vs ③ 对照 → 查承诺落空 三方缺失时不臆测、不阻塞：相应检查项降级为「未覆盖」，在报告盲区段声明。 **四条边界（违反任何一条即跑偏）：** 1. **不替代验收决策**——输出风险清单，用户做最终判断 2. **不做建设性补全**——只攻击和暴露，附修复方向但不重写 3. **不审查「能力边界」本身，只审查「证据链」**——能力是运行时配置（模型×工具×connector×权限），动态变化；声称做过 X 就要拿出做 X 的中间产物，拿不出一律按「未验证声明」处理（详见 D0） 4. **不追求零问题**——价值在于把问题按风险显性化；找不到高等级风险就明说，**禁止凑数** ## 1. 触发判定 | 触发 | 不触发 | |---|---| | "对抗性审查""验收一下 agent 写的代码""这个方案靠谱吗""AI 写的这个能信吗""帮我挑刺""红队审查" | 「这个怎么样」「看看如何」类随口一问（重型流程不被无意激活） | | agent 完成任务后用户要求验收 | 用户自己写的东西要求 review 情绪/风格 | | 贴入其他 AI 工具的产出要求把关 | 用户明确只要夸奖或只要执行 | ## 2. 审查流程（七步，顺序不可乱） ### 第一步：三方输入收集 - 当前会话内的 agent 任务：直接从对话上下文提取三方输入 - 跨工具场景：要求用户贴入；用户只给交付物时如实标注"只有交付物" - 原始需求缺失时先问用户能否提供；不能提供则记录为盲区，继续 ### 第二步：建立攻击地图 列出四张清单： 1. 需求原子���目——**逐字引用用户原文，禁止改写式转述**（改写会把审查方自己的解读混入需求，同会话场景下这是 F2 漏检的主通道） 2. AI 的声明清单（所有"已完成/已测试/已修复"） 3. 外部依赖清单（API、库、文档、数据源） 4. 交付物结构与信任边界 **复杂对象（>500 行代码 / >3000 字文档 / 改动 ≥5 个文件）必须先展示攻击地图给用户确认火力点。** 歧义处理：同一原文存在两种合理读法时标「歧义」并**暂停，待用户裁决读法后再定级**。 ### 第三步：D0 交付真实性审查（先行，不过 D0 不进 D1-D4） 传统审查假设"作者想交付对的东西但可能疏忽"；AI 审 AI 必须先怀疑"交付声明本身可能不成立"。 **D0 动作 1：需求符合性矩阵** | # | 原始需求条目（逐字引用） | 状态 | 差异说明 | |---|---|---|---| 状态：已满足 / 部分满足（差异说明）/ 未满足 / 无法判断 / 歧义待裁决。 纪律：拟判「未满足」的条目必须回读原文二次确认。