idea-to-plan

从想法到计划

将含糊不清的请求转化为：（1）一段问题陈述，（2）一份范围明确的规范，以及（3）一份分阶段实施计划——每一步都要展示给用户并获得确认后，才能继续。切勿根据模糊的提示词直接开始编写代码。

适用场景

• 请求描述的是目标，而不是规范（“构建一个仪表盘”“添加身份验证”）。
• 缺少或隐含了需求、约束或成功标准。
• 用户正在探索某件事是否值得构建。

不要将此流程用于规范明确的任务、复现路径清晰的 bug 修复或机械性改动——这些任务直接进入实施阶段。

流程

1. 重述问题（先于任何提问）

用一段话说明：谁遇到了什么问题，为何现在要解决，以及怎样才算“解决”。展示这段话。如果你写不出来，就说明你还不理解请求——这个差距就是你首先要问的问题。

2. 只问会影响决策的问题

一次提出 3–6 个问题；如果答案不同会改变设计，就值得问。对于有稳妥默认值的问题，略过并说明默认值，然后继续。值得询问的方面包括：

• 范围边界（明确排除哪些内容）
• 硬性约束（技术栈、截止日期、数据、合规性）
• 成功标准（如何判断任务已完成）
• 如果判断错误会造成最大返工的那一项假设

3. 编写规范

## Problem
## Goals / Non-goals
## Constraints
## Approach (1–3 sentences)
## Open questions

控制在一屏以内。展示规范，并在开始规划前，针对目标和非目标明确获得用户的“是”。

4. 编写分阶段计划

将计划拆分为多个阶段，每个阶段都应交付可验证的成果：

Phase 1: <smallest end-to-end slice that proves the approach> — verify by <X>
Phase 2: ...

每个阶段都要说明具体交付成果、涉及的文件或区域，以及验证方式。标明依赖关系和风险最高的阶段。优先处理风险。

5. 移交

将规范和计划作为最终产出。建议从第一阶段开始，然后停止——实施是单独的步骤，需由用户触发。

质量标准

• 问题陈述不超过一段，并明确指出真实用户。
• 明确列出非目标（没有非目标的规范就没有明确范围）。
• 每个阶段都能独立验证。
• 不问答案显而易见的问题。
• 在规范获得确认前，不编写任何代码。

反面模式

• 提出 15 个问题，而实际上 4 个问题就能决定设计。
• “第一阶段：搭建项目”，却没有可验证的成果。
• 把用户的提示词原样复述一遍，并当作规范。
• 在确定最小可行切入点之前，就设计功能齐全的豪华版本。