技能介绍

它解决什么问题

长会话里最危险的不是明显的错误，而是被悄悄"坐实"的假设。上下文越积越多，早期一个未经验证的推断——比如"这个缓存层在读重负载下是线程安全的"——会在后续推理中被当成事实反复引用，直到上线后才以竞态、脏数据或不可逆的迁移事故形式暴露。

质疑驱动开发（Doubt-Driven Development）针对的正是这一类 nontrivial 决策：分支逻辑变更、跨模块或服务边界、编译器和类型系统无法验证的属性（线程安全、幂等、顺序、不变量）、正确性依赖读者看不到的上下文，以及不可逆的变更（生产部署、数据迁移、公开 API）。它的纪律是：在任何这类输出定稿前，召唤一个全新上下文、偏证伪而非批准的评审者交叉诘问，趁纠偏便宜的时候把问题挡在出错之前。

它如何工作

核心是一个有界的五步质疑循环：

CLAIM：把决策显形为两三行的主张——写不出紧凑的主张，说明手里只有"感觉"，还没有可审视的决策。
EXTRACT：隔离出工件（diff/函数，而非整文件）与契约（必须满足的约束），剥离自己的推理。只交结论只会换回对自己结论的认可。
DOUBT：用对抗式提示召唤全新上下文评审者，且只传工件与契约，绝不传 CLAIM，让评审者独立判断工件是否满足契约。
RECONCILE：你是编排者，发现是数据而非裁决。逐条对照工件文本归类：契约误读（先修契约）、有效且可改（改工件重循环）、有效取舍（显式记录让用户看见）、噪声（记下该补什么上下文）。
STOP：下一轮只剩琐碎发现、或满 3 轮、或用户明说"发吧"即停止。3 轮仍有实质问题，说明工件本身可能未就绪，需呈报而非独自磨下去。

交互式会话中，单模型评审之后必须显式询问用户是否需要跨模型第二意见（Gemini CLI / Codex CLI / 人工外部评审 / 跳过），绝不静默跳过；调用外部 CLI 前要查 PATH、测可用性、确认调用语法，并仅传工件+契约+对抗提示。非交互上下文（CI/loop）则跳过跨模型，并明确声明。