Menü
对 AI 的结论、分析或建议进行系统性质疑和对抗性审查。当用户要求"质疑这个结论""帮我挑刺""挑战一下AI的说法""检查AI有没有胡说""doubt"时触发。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | ddev-doubt |
| description | 对 AI 的结论、分析或建议进行系统性质疑和对抗性审查。当用户要求"质疑这个结论""帮我挑刺""挑战一下AI的说法""检查AI有没有胡说""doubt"时触发。 |
任何 AI 结论都是可质疑的假设，不是事实。本 skill 派发独立子代理，以对抗立场系统性地拆解 AI 产出的结论、分析或建议。
⚠️ HARD GATE — 禁止主代理自审
加载本 skill 后，必须派发 General 子代理执行审查。主代理在任何情况下都禁止自行挑战自己的结论。 跳过派发 = 违规。无例外。不得因为"结论很简单""逻辑很明显"等理由绕过。
不适用于：
子代理必须覆盖以下六个维度：
| 维度 | 检查内容 |
|---|---|
| 假设审查 | 结论依赖了哪些隐含假设？逐一列出并检验是否成立。如果某个假设不成立，结论是否崩塌？ |
| 逻辑链审计 | 从前提 → 推理 → 结论的链条是否完整？是否存在跳跃、循环论证、因果倒置、虚假二分？ |
| 证据质量 | 支撑结论的证据是否充分？是否存在选择偏误（只举有利例子）、幸存者偏差、样本不足？ |
| 完备性检查 | 遗漏了哪些替代方案？哪些反对论据没有被考虑？边界情况是否覆盖？ |
| 信心校准 | 结论的确定性表述是否与证据强度匹配？是否存在过度自信（"显然""一定"用于不确定场景）？ |
| 可证伪性 | 什么条件下该结论会被推翻？能否构造一个具体的反例或反证场景？ |
主 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 产出的结论（分析、建议、判断、预测），不是代码或文档。
在当前会话里按已写好的实现计划顺序执行任务时使用
在已有规格或多步骤任务需求、且在动代码之前使用。若上游 ddev-pc-test 已产出测试用例，自动走 TDD 流程：先实现测试 demo 代码（红灯），再实现被测代码（绿灯），测试覆盖不到的部分直接开发。
文档审查技能。将文档审查任务派发给独立子代理，重点审查文档基于代码改动的合理性、说明正确性、前后一致性、错漏和逻辑谬误，以及 AI 实现过程中产生的决策记录（implementation-notes.md）。当用户需要审查技术文档、spec文档、设计文档、计划文档、API文档、README 或任何与代码改动相关的文档时使用。
代码修改场景下，spec 文档确认后，需要继续以图优先方式梳理结构体定义、数据流和流程时使用
在代码修改前需要编写 spec 文档且应优先用图表达边界、入口、流程和改动关系时使用（仅限代码改动场景，非项目级架构文档初始化）
在代码实现完成后、准备结束任务或进入发布前使用，用来核对代码实现是否与 spec 文档以及 detail 文档一致，并通过代码质量审查、清理、编码规范和注释审查后给出最终验收结论