怀疑驱动开发 是做什么的？
对每个非平凡决策进行全新环境下的对抗性审查，然后再定案。适用于正确性比速度更重要的情况，比如处理不熟悉的代码、高风险场景（生产环境、安全敏感逻辑、不可逆操作），或任何自信的输出现在验证比以后调试更划算的时候。
动机
在软件开发中，许多错误源于过度自信——我们以为自己的推理是正确的，直到后来才发现缺陷。传统的“快速出结果”方法更注重速度而非正确性，这在处理复杂或高风险决策时可能带来高昂的后期成本。怀疑驱动开发（DDD）通过引入结构化的怀疑主义来缓解这一问题：在每个重要决策定案之前，强制进行对抗性审查，从相反角度寻找漏洞。
工作原理
- 识别非平凡决策：任何可能影响正确性、安全性或稳定性的决策（如算法选择、API设计、权限逻辑、数据处理流程）都应标记为“可疑”。
- 生成对抗性审查：系统提示AI助手扮演一个“挑剔审查者”角色，以全新视角审视当前方案。审查内容包括：
- 逻辑谬误
- 边界情况遗漏
- 安全弱点
- 性能陷阱
- 可维护性问题
- 基于审查结果决策：根据审查反馈调整方案或接受原方案（如果审查未发现实质性缺陷）。
使用场景
- 生产环境代码变更
- 安全敏感逻辑（如认证、授权、加密）
- 数据库迁移或数据操作
- 货币或财务计算
- 多线程/并发处理
- 第三方集成逻辑
- 不熟悉的代码库或技术栈
- 任何“简单改动”可能导致级联故障的情况
提示模板示例
## 对抗性审查请求
**待决策事项**：[描述具体的决策或代码片段]
**审查角色**：我是AI助手，现在扮演“怀疑开发者”。我将严格审查此决策，寻找潜在缺陷。
**审查过程**：
1. 重新陈述决策目标，确保我理解正确。
2. 列出所有假设前提，逐一质疑其有效性。
3. 识别边界情况：输入值、状态、并发等。
4. 检查安全影响：注入、权限泄漏、数据暴露。
5. 评估性能影响：时间复杂度、资源消耗。
6. 提供改进建议或替代方案。
**输出格式**：首先给出“审查报告”，然后基于审查结果给出最终建议的代码或决策。
最佳实践
- 不要跳过小决策：即使是看似简单的if-else分支，也可能隐藏错误。
- 保持审查简短：专注于关键风险点，避免无限怀疑。
- 记录审查结论：对于高风险决策，保留审查过程和结论以供后续参考。
- 结合自动化测试：对抗性审查不能替代测试，但可以指导测试用例设计。
相关资源
贡献
欢迎通过Issue或PR提交改进建议。请确保你的变更符合本技能的核心原则：对每一个非平凡决策，都给予它应得的怀疑。