# Ddev Doubt

> 对 AI 的结论、分析或建议进行系统性质疑和对抗性审查。当用户要求"质疑这个结论""帮我挑刺""挑战一下AI的说法""检查AI有没有胡说""doubt"时触发。

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

---


# 对抗性审查

任何 AI 结论都是可质疑的假设，不是事实。本 skill 派发独立子代理，以对抗立场系统性地拆解 AI 产出的结论、分析或建议。

> ⚠️ **HARD GATE — 禁止主代理自审**
>
> 加载本 skill 后，**必须派发 General 子代理执行审查**。主代理在任何情况下都**禁止**自行挑战自己的结论。
> 跳过派发 = 违规。无例外。不得因为"结论很简单""逻辑很明显"等理由绕过。

---

## 何时使用

- 用户要求"质疑这个结论""帮我挑刺""挑战 AI 说法"
- AI 给出了重要决策建议，用户想先过一遍对抗审查
- 技术方案、架构选择、技术选型等有长期影响的结论
- 数据分析、性能诊断等容易被确认偏误污染的结论
- 用户本能觉得"AI 说得太顺了"但说不上哪里不对

**不适用于：**
- 纯事实查询（"这个 API 叫什么"）—— 直接验证即可
- 代码语法、格式等有明确对错标准的事项
- 用户已明确表示"就这样，别审了"

---

## 核心流程

1. 主 agent 整理待审查的结论上下文（AI 原始输出 + 问题背景 + 用户关切）
2. ⚠️ 主 agent **必须**派发 **General 子代理**执行对抗审查（**禁止主代理自行审查**）
3. 子代理返回审查报告
4. 主 agent 汇总发现、评估严重度、向用户呈现
5. 对于**阻塞级**发现，主 agent 应在同一轮修正并说明修正内容
6. 用户决定是否接受修正后的结论

---

## 审查维度

子代理必须覆盖以下六个维度：

| 维度 | 检查内容 |
|------|---------|
| **假设审查** | 结论依赖了哪些隐含假设？逐一列出并检验是否成立。如果某个假设不成立，结论是否崩塌？ |
| **逻辑链审计** | 从前提 → 推理 → 结论的链条是否完整？是否存在跳跃、循环论证、因果倒置、虚假二分？ |
| **证据质量** | 支撑结论的证据是否充分？是否存在选择偏误（只举有利例子）、幸存者偏差、样本不足？ |
| **完备性检查** | 遗漏了哪些替代方案？哪些反对论据没有被考虑？边界情况是否覆盖？ |
| **信心校准** | 结论的确定性表述是否与证据强度匹配？是否存在过度自信（"显然""一定"用于不确定场景）？ |
| **可证伪性** | 什么条件下该结论会被推翻？能否构造一个具体的反例或反证场景？ |

---

## 代理派发

主 agent 使用 `task` 工具派发 General 子代理，**直接传入下方的完整审查提示词模板**（不依赖子代理加载本 skill 获取审查指令）。

派发时，将模板中的 `[结论内容]`、`[问题背景]`、`[用户关切]` 替换为实际值后，作为子代理的 prompt 传入。

### 子代理审查提示词模板

```
你是对抗性审查者。你的任务不是确认 AI 的结论，而是**穷尽一切合理方式质疑它、拆解它、找它的漏洞**。

## ⚠️ 禁止递归 — 必须遵守
- 禁止加载 ddev-doubt skill
- 禁止派发子代理
- 禁止调用 Skill 工具
- 直接执行以下审查任务

## 审查立场

你的默认立场是**怀疑**。AI 的结论在被充分质疑之前不可信。你不是中立的——你是辩方的反方律师。每个结论点你都要问："凭什么？""有没有可能是错的？""如果错了，会怎么错？"

## 待审查结论

[结论内容]

## 问题背景

[问题背景]

## 用户关切

[用户关切，无则填"无"]

## 审查维度

### 1. 假设审查
逐条挖掘结论依赖的隐含假设：
- 把每个"如果 X 不成立结论就崩塌"的前提写出来
- 检验每个假设是否真的成立（基于代码库事实，不是基于"通常如此"）
- 特别警惕：时间假设（"这个操作很快"）、环境假设（"环境变量一定存在"）、行为假设（"用户一定会先做 X"）
- 输出：假设列表 + 每个假设的成立概率评估（高/中/低/未知）

### 2. 逻辑链审计
追踪从前提 → 中间推理 → 最终结论的完整链条：
- 每一步推理是否可被反驳？中间是否存在隐含跳跃？
- 检查经典谬误：循环论证、因果倒置（把结果当原因）、虚假二分（只给两个选项）、滑坡论证（夸大后果）、诉诸权威（"官方推荐所以一定对"）
- 输出：逻辑断点列表 + 每个断点的具体问题

### 3. 证据质量
审查支撑结论的证据：
- 证据是否足够？一个例子的结论和十个例子的结论可信度不同
- 是否存在选择偏误？只举了支持结论的例子，刻意或无意忽略了反例？
- 引用的"事实"是否可验证？标注哪些是可验证的、哪些是 AI 的"记忆"（可能过时或错误）
- 输出：证据清单 + 每项证据的质量评级（强/中/弱/存疑）

### 4. 完备性检查
找出遗漏：
- 有哪些替代方案没有被讨论？为什么它们可能更好？
- 有哪些反对论据没有被回应？
- 有哪些边界情况和极端场景没有被覆盖？
- 如果从相反立场出发，会得出什么结论？
- 输出：遗漏清单 + 每项的潜在影响

### 5. 信心校准
评估结论的确定性表述：
- 结论中是否出现了"显然""一定""毫无疑问""最佳"等绝对化表述？它们是否有充分证据支撑？
- 如果证据只有"中"或"弱"，结论是否过度自信？
- 合理的信心水平应该是什么？
- 输出：过度自信的具体语句列表 + 合理的信心水平建议

### 6. 可证伪性
尝试推翻结论：
- 什么条件下这个结论是错的？给出具体、可检验的证伪条件
- 能否构造一个具体的反例？
- 如果无法构造任何可想象的证伪条件，这个结论本质上是不可证伪的——标记为"伪科学级结论"
- 输出：证伪条件列表 + 反例（如果能构造）

## 判定标准

**只标记实质性缺陷。** 措辞偏好和风格瑕疵不算问题。
但**逻辑错误、事实矛盾、遗漏关键替代方案、过度自信——永远是有意义的问题**。

## 输出格式

## 对抗性审查报告

**审查结论：** [一句话概述被审查的结论]

**审查背景：** [问题背景摘要]

---

### 问题清单

| # | 严重度 | 维度 | 问题描述 | 具体说明 |
|---|--------|------|---------|---------|

严重度定义：
- **阻塞**：结论依赖不成立的假设、存在事实错误、逻辑链关键环节断裂——结论不可信
- **重要**：遗漏关键替代方案、证据明显不足、过度自信——结论需要大幅修正
- **建议**：补充考虑边缘情况、弱化确定性表述、增加限缩条件

---

### 各维度详细分析

#### 1. 假设审查
[逐条列出假设 + 成立概率 + 如果不成立的影响]

#### 2. 逻辑链审计
[逐条列出逻辑断点 + 具体问题]

#### 3. 证据质量
[逐条列出证据 + 质量评级 + 理由]

#### 4. 完备性检查
[逐条列出遗漏 + 潜在影响]

#### 5. 信心校准
[逐条列出过度自信的具体语句 + 合理水平]

#### 6. 可证伪性
[列出证伪条件 + 反例]

---

**审查结论：** 可信 / 需修正 / 不可信

- 可信：无阻塞或重要问题
- 需修正：存在重要问题，结论方向可能正确但需要限定和修正
- 不可信：存在阻塞问题，结论根基有问题

若结论为"需修正"或"不可信"，须逐项列出必须修正的内容。
```

---

## 适用范围

本 skill 审查的是 **AI 产出的结论**（分析、建议、判断、预测），不是代码或文档。

- ✅ 技术选型建议、架构方案推荐、问题诊断结论、性能分析判断
- ✅ 代码审查意见、重构建议、"最佳实践"推荐
- ✅ 任何 AI 声称"这是最好的做法""问题出在 X""应该用 Y"的断言
- ❌ 纯事实查询结果（用验证替代审查）
- ❌ 代码正确性（用测试替代审查）

---

## 约束

- ⚠️ **主代理禁止自行审查**——必须派发子代理，任何情况无例外
- ⚠️ **防递归**：主代理派发子代理时**必须**传入上方内嵌的完整审查提示词模板（含递归禁令），禁止让子代理加载本 skill 自行获取审查指令
- 子代理必须是独立对抗视角，默认立场是怀疑而非确认
- 发现结论依赖不成立假设或存在事实矛盾时，必须标记为阻塞
- 不允许用"基本合理""整体没问题"等模糊表述放行——必须有具体的维度分析