# Adversarial Review

> 行途自媒体"多专家对抗审查"技能（豆包工作优化版）。对公众号封面/标题/正文/数据/方案 做多角色交叉对抗审查，消除单视角盲区。支持怀疑论者/优化者/审计员/过滤器四角色并行， Round 2 脚本交叉验证（不用 LLM 法官），仅保留高置信度发现。 触发词：对抗审查、交叉审查、多视角审查、审文章、审标题、审封面、审查方案、数据核查。 依据：RULES.md PUB-017（多专家对抗审查）+ 行途内容工厂五关 + 原版 adversarial-review。 版本：豆包工作优化版 v1.0（2026-09-03）；原版归档 .backups/skills_原版归档_20260903/adversarial-review_原版_{tfm-ng,ctf-gitlab}

- Skill: `xingtu1996/adversarial-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add xingtu1996/adversarial-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/xingtu1996/adversarial-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: xingtu1996 (https://skillmd.com/u/xingtu1996)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/xingtu1996/adversarial-review

---


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

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

---

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

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

| 原则 | 规则 |
|------|------|
| **TKR-1** | 审查角色输出精简，发现列表不写散文 |
| **TKR-2** | Round 2 交叉验证用**脚本**（grep/ls/diff/查库），**不用 LLM 当法官**（省一份法官的 token） |
| **TKR-3** | 每个角色发现上限 **7 条**——太少=草率，太多=噪音浪费 token |
| **TKR-4** | 领域专家（封面设计/数据/合规）**按需**激活——只在审查目标涉及对应领域时启用 |
| **TKR-5** | 轻量审查（单篇文章）→ 3 角色并行。标准审查（系列/方案）→ 4 角色并行。重量审查（付费/商业决策）→ +领域专家 |
| **TKR-6** | 审查结果直接写回被审文件的"审查记录"章节，不创建独立审查报告（除非用户要求） |

### 审查深度决策

| 级别 | 触发 | 角色数 | Round | Token 估算 |
|------|------|:--:|:--:|:--:|
| **轻量** | 单篇封面/标题 | 3 (Refuter + Optimizer + Auditor) | 并行 1 轮 | ~10K |
| **标准** | 单篇文章正文/数据 | 4 (全部) | 并行 1 轮 + 脚本交叉 | ~25K |
| **重量** | 系列规划/付费方案/合集策略 | 4 + 领域专家 | 并行 1 轮 + 专家审 + 脚本交叉 | ~50K |

---

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

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

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

| 角色 | 职责 | 问的核心问题 | 不看什么 |
|------|------|------------|---------|
| **怀疑论者** (Refuter) | 找到论证的薄弱点 | "这个结论的证据充分吗？""数字有来源吗？""遗漏了什么成本/反例？" | 不改建议、不优化格式 |
| **优化者** (Optimizer) | 找到可以更好的地方 | "标题能更抓人吗？""表述能更清晰吗？""有更省的写法吗？" | 不找逻辑错误 |
| **审计员** (Auditor) | 验证数据和引用 + 精确位置定位 | "封面数字=正文数字吗？""来源真实存在吗？""口径一致吗？" | 不做价值判断 |
| **过滤器** (Filter) | 误报拦截——过滤低质量发现，只保留高置信度 | "这个发现是真问题还是噪音？""置信度够高吗？" | 不新增发现、不修改发现内容 |

### 审计员位置定位规则

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

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

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

---

## 二、两轮流程

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

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

**输出格式**（每个发现）：
```markdown
### [角色] 发现 #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`）
- 日期/版本号准确吗？

### 领域专家（按需激活）
| 场景 | 专家 | 检查什么 |
|------|------|---------|
| 封面/视觉 | 封面设计专家 | SignalDistilled 哲学、行途蓝 VI、900×383 |
| 数据/账单 | 数据审计专家 | 数字口径、缓存命中率、成本核算 |
| 合规/脱敏 | 合规专家 | PUB-018 脱敏、雇主信息、隐私暴露面 |

---

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

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

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

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

---

## 五、审查报告模板

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

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

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

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

## 全部发现

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

## 过滤统计

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

---

## 六、自检清单

| # | 检查项 |
|---|--------|
| 1 | 是否用脚本（grep/check_cover_consistency/查库）验证过审计员的数据发现？ |
| 2 | 🔴 严重发现（数字不一致/编造/脱敏漏洞）是否立即修复？ |
| 3 | Round 2 是否用脚本而非 LLM 做交叉验证（TKR-2）？ |
| 4 | 封面数字与正文主数字是否核对过口径？ |
| 5 | 官方口径 vs 实测口径是否分开标注？ |
| 6 | Filter 是否拦截了 ≥30% 的低质量"单独"发现？ |
| 7 | 数据脱敏（PUB-018）是否过审？ |

---

## 七、与其他 Skill 的关系

| Skill | 审查维度 | 触发方式 |
|-------|---------|---------|
| **adversarial-review** | 逻辑 + 一致性 + 数据口径 + 脱敏 | 文章/封面/方案完成 / "审查" |
| **de-ai-flavor** | 去 AI 味 / 文案 | "去 AI 味" / 润色 |
| **codemax-report** | 数据核实 / 统计 | "核实数字" / "看账单" |

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

---

## 版本历史

| 日期 | 版本 | 变更 | 来源 |
|------|:---:|------|------|
| 2026-09-03 | v1.0 | 豆包工作优化版：适配行途公众号（封面/标题/正文/数据审查）+ PUB-017 对齐 + 领域专家表 + 数据核实联动 | 原版 tfm-ng + ctf-gitlab |

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