怀疑驱动开发

问题：自信的答案不等于正确的答案

在持续数小时甚至数天的会话里，上下文越积越厚。某个早期假设——比如「这个接口的返回顺序是稳定的」——在今天的上下文里已经没人记得它当时只是猜测，于是被当成事实继续传递。等到评审或线上事故时才发现，那个前提从未被真正验证过。

常规 /review 是对已完成产物的裁决，它只能告诉你「这里错了」，而代价已经付出。怀疑驱动开发把检查点前移：在非平凡决策定型之前，引入一个没有上下文包袱的全新评审者，其默认立场是反驳而非批准。此时纠正方向的成本最低。

什么时候该用

一个决策属于非平凡，只要满足以下任一条件：

• 引入或修改了分支逻辑
• 跨越了模块或服务边界
• 断言了类型系统或编译器无法验证的性质（线程安全、幂等性、顺序、不变式）
• 正确性依赖未来读者看不到的上下文
• 爆炸半径不可逆（生产部署、数据迁移、公开 API 变更）

典型场景：在不确定中做架构决策、提交非平凡代码、声称某个非显而易见的事实（this is safe、this scales、this matches the spec）、在自己不完全理解的代码里工作。

它如何工作

流程分步推进，其中第 3 步 DOUBT 是核心：物化一个全新上下文的评审者，把待审的 ARTIFACT 与 CONTRACT 交给它，要求其以证伪为默认立场逐项反驳。只有扛住反驳的产物才允许继续往前。

适用边界与注意点

不是每个键都需要怀疑——怀疑每一个键，就什么都交付不了。不要用于：机械操作（重命名、格式化、移动文件）、清晰无歧义的用户指令、阅读或总结现有代码、正确性显而易见的一行改动、纯工具操作（跑测试、列文件），以及用户明确要求速度优先于验证的时刻。

还有一条编排约束：本技能面向主会话编排者设计。不要写进 persona 的 frontmatter——persona 执行到第 3 步会拉起另一个 persona，这正是编排反模式所禁止的。若发现自己在子代理上下文里调用它（无法再嵌套拉起子代理），应向用户说明怀疑驱动流程无法嵌套运行、交由主会话处理；仅在别无选择时，才退化为把 ARTIFACT 与 CONTRACT 重写成一份全新的自我提示、并加一道硬性心理分隔的降级方案。