需要向干系人推介方案、对齐团队时，用一页纸方案简报把问题…

在进入详细规格说明之前，用一页纸向干系人推介解决方案思路、对齐跨职能团队并记录方案意图。

适用场景

解决思路

1. 回顾问题：用最多 2-3 句话总结问题，不要重新解释完整的问题陈述，必要时引用它；让读者立刻明白该方案针对的痛点是什么。
2. 描述提议的解决方案：用清晰、非技术化的语言说明要构建什么，聚焦用户体验和核心价值主张，避免实现细节——只讲 what，不讲 how。
3. 列出关键功能：识别构成方案的 3-5 个必要功能，它们应是解决问题所需的最小集合，抵制加入 nice-to-have 的冲动，一页纸的限制要求聚焦。
4. 定义成功指标：把方案与可衡量的结果挂钩，说明如何判断方案是否奏效，引用问题陈述中的指标并设定目标值。
5. 明确权衡：记录你明确不做什么以及原因；好的方案简报会诚实说明范围限制和被否决的备选方案。
6. 识别风险与缓解措施：列出对成功影响最大的风险以及应对计划，以建立干系人信心并尽早暴露顾虑。
7. 列出后续步骤：给出 3-5 个推进方案的即时行动，明确说明谁做什么。
8. 使用 references/TEMPLATE.md 中的模板组织输出，完整填写每个模板章节：Problem Recap、Proposed Solution、Key Features、Success Metrics、Trade-offs Considered、Risks & Mitigations、Next Steps。
9. 定稿前校验：确认简报打印时能容纳在一页内（约 500-700 字）。
10. 定稿前校验：确认问题回顾简洁（最多 2-3 句话）。
11. 定稿前校验：确认方案描述避免技术术语。
12. 定稿前校验：确认功能限制在 3-5 个核心能力。
13. 定稿前校验：确认权衡被明确写出。
14. 定稿前校验：确认后续步骤具体且可执行。

适用边界 · 注意事项

• 干系人已经对齐、工程团队需要完整规格说明时——方案简报负责推介，完整规格应改用 deliver-prd。
• 问题尚未被框定或尚未达成一致时——应先用 define-problem-statement。
• 只是记录已经做出的决定时——技术决定用 develop-adr、设计决定用 develop-design-rationale；需要在整个业务模型层面比较战略选项时用 foundation-lean-canvas。