revision-adversarial

对抗式设计评审

目标

质疑现有的技术设计文档（TECH-DESIGN.md）及其 ADR，主动寻找缺漏、缺乏依据的决策和未考虑到的风险。本技能默认不会验证设计——它的职责是先提出异议，只有在未能发现实际问题后，才认可某项决策合理。

为何重要

让产出设计的同一段对话回答“你确定吗？”，往往得到的是辩护，而非批评——模型会表现出谄媚倾向（RLHF 训练会奖励认同）和自我偏好偏差（模型会更正面地评价自己先前的输出）。尽可能在全新对话中运行此技能，不要带入设计产出过程的历史记录。如果在生成 TDD 的同一段对话中运行，请在开始前明确告知用户，因为这种情况下评审力度较弱。

必需输入

• TECH-DESIGN.md 及其 adrs/*.md 文件——必需。
• PRD.md 和 Design.md（如果存在）——用于交叉核对，确保没有决策与明确的范围或 UI 要求相矛盾。运行评审并不需要这些文件，但跳过它们会缩小评审范围——请说明这一点。

工作流

1. 完整阅读 TECH-DESIGN.md 和每份 ADR。
2. 对照以下标准检查每份 ADR——只要有一项缺失或薄弱，就不达标：
   • 上下文是否真正支撑该决策（而非泛泛的套话）。
   • 所考虑的替代方案是否确实可行，而非伪选择（给同一事物起两个名字不算）。
   • 后果是否至少包含一项实际成本或权衡，而非只有收益。
   • 决策是否与项目的实际规模相称——过度设计和设计不足都要指出。
3. 跨文档检查：
   • 是否有决策与 PRD 的范围或明确的“No alcance”相矛盾？（如果有 PRD.md）
   • Design.md 中每个暗示数据的元素，是否都在数据模型中有所体现？（如果有 Design.md）
   • 是否完全缺少项目明显需要、但没有 ADR 涉及的决策领域——组件、数据模型、API 契约、技术栈、状态管理、弹性等？
4. 主动寻找缺失之处：未处理的故障模式、PRD 隐含但未说明的非功能需求（性能、并发、离线使用），以及决策带来的、其 ADR 未提及的次级影响。
5. 生成问题报告——不要直接修改 TECH-DESIGN.md 或任何 ADR。此技能负责报告；由人决定修改内容。

输出

按严重程度从高到低排列的问题报告：

• 严重——若不解决，设计很可能会失败或与明确的要求相矛盾。
• 警告——确实存在缺漏或依据薄弱，值得在实施前修正。
• 建议——较小的改进，不会阻碍实施。

每项问题都应指出涉及的 ADR 或章节、具体问题及其重要性——不要只含糊地说“建议重新审查”。如果经过充分审查，某个方面确实没有发现实际问题，就应明确说明，而不是为了显得全面而杜撰小问题。

质量门槛

返回前，在心中检查：

• 是否确实质疑了每份 ADR——没有跳过或不加审查地认可任何一份。
• 至少有一项问题指出原 ADR 遗漏的实际权衡；或者明确说明设计经受住了审查——绝不能只泛泛地说“看起来很扎实”。
• 没有为了凑数而捏造问题。