Adversarial Review

对抗性审查引擎（Adversarial Review Engine · 行途版）

来源：原版 adversarial-review（tfm-ng + ctf-gitlab）+ 行途内容工厂五关 + PUB-017 多专家对抗审查 适配日期：2026-09-03 核心理念：单一视角的审查有固有盲区。 多角色从对立视角独立审查 → 脚本交叉验证（不用 LLM 法官）→ 仅保留高置信度发现。

〇、Token 纪律（对齐省 token 系列）

铁律：对抗审查的 token 消耗必须符合省 token 哲学。并行提升效率，但不能让 token 爆炸。

审查深度决策

一、行途自媒体四角色审阅模型

                    审查对象（封面 / 标题 / 正文 / 数据 / 方案）
                      │
       ┌──────────────┼──────────────┐
       ▼              ▼              ▼
  怀疑论者         优化者          审计员
  (Refuter)      (Optimizer)     (Auditor)

  找到漏洞         提出改进       验证数据和一致性
  "这结论站得住吗？"  "还能怎么优化？"  "数字对得上吗？"
       │              │              │
       └──────────────┼──────────────┘
                      ▼
              ┌──────────────┐
              │   过滤器      │
              │   (Filter)   │
              │  误报拦截     │
              └──────┬───────┘
                     ▼
              脚本交叉验证 → 置信度分级 → 写回

审计员位置定位规则

解决"AI 评论的行号对不上实际内容"的经典问题。文章审查用章节/字段定位，封面用数字+文案定位。

❌ 旧方式（位置漂移）:
  - 位置: S05 封面 第 3 行
  - 问题: 数字口径不一致

✅ 新方式（字段定位）:
  - 位置: 封面 S05 big 字段（HTML: <span class="big">）
  - 内容: "93.6%" → 正文主数字是 "8880万/30天"
  - 问题: 封面与正文口径不一致，读者会混淆

二、两轮流程

Round 1：独立并行审查（3-4 角色并行，精简输出）

每个角色收到相同的审查对象 + 角色定义，独立产出发现列表。

输出格式（每个发现）：

### [角色] 发现 #N: {一句话摘要}
- 位置: {封面/正文§章节/标题}
- 严重度: 🔴 严重 / 🟡 需关注 / 🟢 建议
- 证据: {具体引用或数据}
- 理由: {为什么这是问题}

Round 2：脚本交叉验证 + Filter 误报过滤

Round 1: Refuter + Optimizer + Auditor (+专家) 并行审查
                ↓
Round 2a: 脚本交叉验证（去重 + 置信度分级）
                ↓
Round 2b: Filter 误报过滤（拦截低质量发现）

置信度分级：

✅ 交叉验证 = ≥2 个角色独立报告了同一发现
🔹 单独     = 仅 1 个角色报告

Filter 角色职责：

• 对"单独"置信度的发现逐条检查——是否真正有价值？
• 过滤标准：没有具体证据的 / 纯主观偏好的 / 表述模糊的 → 标记为 [已过滤]
• 不新增发现、不修改发现内容——只做减法
• 目标：拦截 30-50% 的低质量发现

三、行途内容审查角色要点（豆包工作优化版新增）

怀疑论者检查要点（文章/封面）

• 标题是否 ≤13 字且核心词前置（PUB-014）？还是堆了纯数据钩子？
• 数字是否有来源？是"实测/官方/估算"哪种口径？
• 有没有遗漏的代价/反例？（如：压缩过头会丢关键报错）
• 数据脱敏是否符合 PUB-018（公司数字脱敏到量级）？
• 有没有编造数字？（对应用户"凭印象硬编是大忌"红线）

优化者检查要点

• 标题/封面 caption 读者能秒懂吗？（SignalDistilled：数字第一语言）
• 有没有更省 token 的写法？（对齐省 token 系列母题）
• 金句锚点（思想定调）够不够打动人？
• 实操命令读者能直接抄吗？（每篇至少 1 段）

审计员检查要点（必须用工具验证）

• 封面数字 = 正文主数字？（跑 check_cover_consistency.py）
• 数据来源真实吗？（cc-switch 库 / codemax API / 素材矿报告）
• 官方口径 vs 实测口径是否分开标注？（对齐 S05 三数口径对比）
• 文件路径/引用真实存在吗？（ls/test -f）
• 日期/版本号准确吗？

领域专家（按需激活）

四、执行指令（给 AI Agent 的标准提示词）

你是审查对象 [封面/文章/方案] 的对抗性审查员。请以 [角色] 的视角检查。

角色定义：[从 §一 角色表复制]
检查要点：[从 §三 角色要点复制]
审查范围：[指定封面HTML/文章md/方案]

输出要求：
- 每个发现：位置 + 严重度 + 证据 + 理由
- 精简输出（TKR-1）：不写"看起来不错"等无信息量文字
- 发现数量：3-7 条（TKR-3）

五、审查报告模板

# [审查对象] 对抗性审查报告

> Round 1: 3-4 角色并行 | Round 2: 脚本交叉 | 修复: N 项 | 接受: M 项

## 交叉验证发现（≥2 角色独立发现）

| # | 发现 | 严重度 | 报告者 |
|---|------|:--:|------|
| 1 | xxx | 🔴 | Refuter + Auditor |

## 全部发现

| # | 发现 | 角色 | 置信度 | 严重度 | 状态 |
|---|------|------|:--:|:--:|:--:|
| 1 | xxx | Refuter | ✅ 交叉验证 | 🔴 | ✅ 已修复 |

## 过滤统计

| 指标 | 值 |
|------|:--:|
| 总发现 | N |
| 过滤拦截 | M (M/N%) |
| 最终保留 | N-M |

六、自检清单

七、与其他 Skill 的关系

adversarial-review 是发布前的质量门禁——在 de-ai-flavor（去味）和内容定稿之后运行，数据问题交给 codemax-report 核实。

版本历史

豆包工作优化版：适配行途自媒体场景，原版已归档 .backups/skills_原版归档_20260903/。