将想法转化为设计与规格说明

概述

通过自然的协作对话，帮助把想法完善为完整的设计与规格说明。

先理解当前项目上下文，然后通过一次只问一个问题来细化想法。当你理解了要构建的内容后，将设计按小节呈现（每节约 200–300 个单词），并在每一节结束后确认是否对齐。

流程

1. 理解想法

• 先检查上下文：查看当前项目状态（代码文件、文档、最近的提交）。
• 一次只问一个问题：逐步细化想法。
• 使用选择题：尽可能优先使用选择题而非开放式问题。
• 单一焦点：每条消息只问一个问题；如果某个主题需要深度，将其拆分为多个问题。
• 关注领域：目标、约束、成功标准。
• 问题清单：对于复杂问题，创建一个 markdown 文件来跟踪子问题：

  📋 待确认子问题：
  - [ ] 谁是目标用户？
  - [x] 核心功能是什么？ → 已确认：用户认证
  - [ ] 技术约束有哪些？
  

2. 溯因推理与系统思考（内部推理 - 请勿输出）

你必须在思维链中内部执行以下检查，但绝不向用户展示此原始分析：

• 溯因推理：列出 2–3 个假设（包括 1 个低概率高风险假设）；确定验证最可能假设的最小行动。
• 系统思考：标记 1–2 个关键杠杆点和副作用通道；利用这些来约束解决方案的边界。
• 护栏：在被证伪之前不要丢弃低概率高风险假设；如果前提被否定，则回溯。

3. 探索方案

• 基于内部分析，提出 2-3 种不同的解决方案及其权衡。
• 以对话方式呈现选项，提供你的推荐及理由。
• 先陈述你推荐的方案，然后解释原因。

4. 呈现设计

• 仅当你有信心理解要构建的内容时，才开始呈现设计。
• 分块：将设计分成约 200–300 个单词的小节。
• 增量检查：在每节之后，询问目前为止是否符合预期。
• 覆盖范围：架构、组件、数据流、错误处理、测试。
• 回溯：如果在任何时候有不清楚的地方，立即停止并澄清。

进度透明度

在每次交互结束时，提供一个动态的“下一步”指示器：

📍 当前阶段：[理解需求 / 探索方案 / 呈现设计]
📋 下一步：[具体描述]
   (注：计划可能会根据你的回复进行调整)

关键原则

• 一次只问一个问题 — 不要用多个问题轰炸用户
• 优先选择题 — 在可行的情况下，比开放式问题更容易回答
• 严格遵循 YAGNI — 从所有设计中移除不必要的功能
• 探索替代方案 — 在定案前始终提供 2–3 个选项
• 增量验证 — 分块呈现设计并验证每一部分
• 保持灵活 — 如果出现歧义，立即回溯并澄清