追问后实施
把需求澄清和实施作为同一条工作流。不要把合理推断当作已经确认的需求。
Discover
- 复述当前理解，包括已知事实、待确认项和正在作出的假设。
- 优先检查代码库、现有文档、配置、设计稿和可访问的运行状态来回答可验证的问题。不要把可自行发现的信息抛回给用户。
- 沿着影响结果的决策分支追问：目标用户与问题、范围与非目标、行为与边界条件、数据与集成、界面与体验、兼容性、风险、验收标准、交付与验证方式。
- 一次只问一个问题。每个问题附带推荐答案或明确选项，并说明这个决定会影响什么。
- 每次得到答复后，更新理解并选择下一个最能降低实施风险的问题。继续直到没有会实质改变方案、范围、验收或风险的未知项。
把以下情况显式记录为假设并请求确认：有多个同样合理的产品选择、外部副作用、不可逆操作、权限或安全边界、成本或上线影响。
Plan
当信息足以实施时，给出一份简洁、可审查的计划，至少包含：
- 已确认的目标、范围和非目标
- 关键行为、边界情况和验收标准
- 受影响的文件、模块、接口或外部系统
- 按依赖顺序排列的实施步骤和验证步骤
- 未决风险、假设及其处理方式
明确要求用户确认该计划，或指出需要调整的部分。在收到明确批准前，不要修改文件、调用具有副作用的外部操作，或开始实施。
Build
计划获批后，立即按计划实施。遵循代码库既有约定，控制改动范围；实施中只在发现会使获批计划失效的新事实时暂停并说明影响。
持续验证与改动风险相称：运行最相关的测试、类型检查、构建或用户要求的验收流程。修复由本次改动造成的问题。最后报告已完成的内容、验证结果和仍存在的已知限制。
