doubt-driven-development

怀疑驱动开发（Doubt-Driven Development）

技能概述

怀疑驱动开发是一种软件开发方法论，通过在关键决策前引入对抗性审查来验证代码正确性，避免因盲目自信导致的生产环境错误。

适用场景

1. 高风险架构决策

当面临影响系统架构、服务边界或不可逆操作（生产部署、数据迁移）的决策时，怀疑驱动开发能帮助识别隐藏假设和潜在失败模式，在造成实际损害前发现设计缺陷。

2. 不熟悉代码库的关键提交

在处理不熟悉的代码或复杂模块时，通过 CLAIM-EXTRACT-DOUBT-RECONCILE 五步流程，系统地质疑每个非平凡决策，防止因上下文缺失导致的错误决策，特别适合线程安全、并发控制等类型系统无法验证的属性。

3. 安全敏感逻辑的开发

对于涉及用户数据安全、权限验证、资金计算等高风险逻辑，怀疑驱动开发通过对抗性审查和跨模型验证，确保代码在各种边界条件和异常输入下的正确性，比传统测试更早发现深层次的逻辑缺陷。

核心功能

1. 对抗性审查流程

提供结构化的五步审查流程（CLAIM 声明决策 → EXTRACT 提取工件 → DOUBT 对抗性质疑 → RECONCILE 协调发现 → STOP 有界循环），通过新鲜上下文的审查者专门寻找问题而非验证正确性，有效发现隐藏假设、边缘情况和共享状态问题。

2. 跨模型验证机制

支持通过 Gemini CLI、Codex CLI 等外部工具进行跨模型二次审查，突破单一模型的盲点，在交互式会话中自动提供选择，非交互式环境明确跳过，平衡审查质量与工具成本，提高关键决策的可靠性。

3. 智能审查分类系统

自动将审查发现分为四类优先级（合同误读 → 可执行问题 → 有效权衡 → 噪音），避免盲目接受审查结果或无差别质疑，帮助开发者在保持怀疑精神的同时维持开发效率，明确区分需要修复的问题和可以接受的技术权衡。

常见问题

怀疑驱动开发和传统的代码审查有什么区别？

怀疑驱动开发是在决策进行时的对抗性质疑，而传统审查通常是事后评估。怀疑驱动开发在代码提交前就通过新鲜上下文的审查者寻找问题，当发现错误时代码修正成本远低于 PR 阶段或生产环境。两者互补使用效果最佳。

如何判断哪些决策需要使用怀疑驱动开发？

并非每个按键操作都需要质疑。当决策满足以下任一条件时应使用怀疑驱动开发：引入或修改分支逻辑、跨越模块/服务边界、断言类型系统无法验证的属性（线程安全、幂等性）、正确性依赖未来读者看不到的上下文、影响范围不可逆（生产部署、数据迁移）。

使用怀疑驱动开发会不会显著拖慢开发速度？

这个技能仅应用于非平凡决策，对于机械性操作（重命名、格式化）和明确的用户指令不需要使用。虽然在短期内增加了审查时间，但避免了生产环境调试和紧急修复的巨大成本。通过限制每次审查在 3 个循环内，并仅对高风险决策使用，总体上能提高开发效率。