需求启动
用户在前端以明确且低成本的方式做出决策，然后在经过审查的步骤中构建。一次性构建会固化猜测，用户之后不得不重新梳理。在纸上写下任何内容之前长时间缄默思考同样令人恼火（“不需要一次性完成，为什么思考那么久？让我们起草一个包含阶段的文档”）。因此，要快速将问题和计划写下来，并让用户来引导。
1. 收集，简要进行
- 阅读已提供的内容：文件、文件夹、链接、图片、之前的聊天记录和记忆笔记、仓库的 README。注意哪些已经决定，以免重复询问。
- 如果仍有输入缺失（“链接即将到来”、“稍后会有照片”），则仍开始提问，并标记哪些问题依赖于此。
- 不要编写代码或更改文件。不要长时间思考：问题本身就是思考工具。
2. 提出带编号的问题
- 一个编号列表，当问题很多时按主题进行分组。每个问题一行，列出你看到的选项和推荐的默认值，例如：
3. 安装位置：C:\ 还是 D:\？推荐：D:\，因为 C:\ 几乎已满。 - 用户通过编号简洁地回答（“1. 两者 2. 更新到最新 3. 可以”）。仔细映射每个回答。“可以”或“同意”表示接受你的默认值；“前者”和“后者”指的是你选项的顺序；跳过的编号表示“你决定，告诉我你选择了什么”。
- 覆盖对此工作重要的方面：目标和受众；范围和明确的不做事项；输入和输出（格式、位置）；约束（平台、允许或禁止的工具、许可证、离线使用、硬件）；质量标准和验收测试（“我们如何知道它有效”）；失败行为（当每个部分在任何时刻失败时会发生什么：崩溃、连接丢失、断电、多个节点中的一个节点宕机）；保真度（绝不能更改的内容）；内容的位置（仓库、路径、远程）；交付（谁接收什么，多久一次）。
- 仅针对那些引出了新问题的回答，进行第二轮更简短的问题。一旦剩余的不确定因素有了安全的默认值，就停止提问，并列出这些默认值。
3. 编写合同：REQUIREMENTS.md
将其放在项目根目录下，如果项目是新的则创建文件夹。保持简洁、简短并注明日期：
# <项目> 需求
于 <YYYY-MM-DD> 达成一致。此文件为合同；更改将在此处记录并附上日期。
## 目标
## 受众和用途
## 范围
## 不做事项
## 决策
- D-01 <决策> (<日期>)
## 功能需求
- FR-01 ...
## 约束和非功能需求
- NFR-01 ...
## 验证
每个需求一行：如何验证以及证据在哪里。
| ID | 方法 (测试 / 检查 / 分析 / 演示) | 证据 (测试用例、脚本、文件) |
## 未解决的问题
稳定的 ID（D-xx、FR-xx、NFR-xx）使后续的工作、提交和报告可以引用它们。使用用户自己的语言记录用户的回答；不要将其转述为更强或更弱的内容。
为每个需求提供验证方法和证据位置。四种方法是需求工程中的标准方法 (ISO/IEC/IEEE 29148)。优先使用测试。当一个需求只能通过检查或分析来验证时（“无直接 OS 线程调用”、“每个节点调度开销低于 100 微秒”），编写一个检查脚本，将其输出保存为证据，以便可以重新运行证明，而不是重新争论。
4. 编写计划：阶段
将其放在计划文件 PLAN.md 中，紧挨着需求，如果项目较小，则放在“阶段”部分。阶段 0 通常是设置，或是首先证明风险最高假设的试点。对于每个阶段，给出目标、步骤、可交付成果、如何验证以及它服务的需求 ID。保持阶段足够小，以便一次审查完，并说明计划将在过程中调整。
然后停止。用几行报告这两个文件，并推荐第一个阶段。
5. 按请求执行，一次一个阶段
- 只运行用户指定的阶段（“执行阶段 0”、“执行阶段 0 和 1”、“开始”）。
- 在每个阶段结束时，报告已完成的工作、证明其有效的证据（运行的命令、输出、测试结果）、与计划的偏差及原因，以及下一步是什么。在计划中标记该阶段已完成。
- “进度检查”表示：当前阶段、已完成的工作、正在运行的工作、受阻的工作。
- 改变范围的新需求在构建之前，需要写入 REQUIREMENTS.md 并注明日期。被推翻的决策记录为撤销；旧行保留。
- 如果用户已指示，则修复沿途发现的错误；否则列出它们。
- 当最后一个阶段完成时，或者当用户要求时，执行差距分析：对照代码、测试、文档和证据检查需求。报告每个差距及其需求 ID，按请求逐一修复，并重新运行证据脚本。
- 不要在每一步后提交或推送。当一个阶段完成时，提议进行一次提交；仅在要求时推送。
变体
- 无代码的决策（采购、工具选择）：相同的问题，然后针对商定的标准进行简短的比较，而不是两个文件。
- 他人的内容（作者的书、客户的数据、录音）：预先添加一项保真度需求。内容不得静默更改；每次更改都需提出、标记并报告以供批准。