在动手开发前评估产品与功能风险：识别最高风险假设并确定最小验…

当准备构建新产品、MVP、落地页、SaaS、内部工具、Agent 工作流或重大功能时，先做一次紧凑的预演失败审查，判断需求、定位、变现、留存、信任、分发和采用风险。

适用场景

解决思路

1. 在实现开始前运行一次紧凑的预演失败（pre-mortem）审查，目标不是阻止构建，而是找出最高风险的假设、最小的验证步骤，以及应推迟到证据改善后再做的构建范围。
2. 按以下风险维度审查想法：需求（是否有证据表明特定买家或用户迫切想要它）、定位（目标用户能否用一句话理解它是什么以及为什么重要）、变现（是否有可信的付费、预算或战略价值路径）、留存（用户首次尝试后是否有理由回来）、信任（产品是否需要可信度、数据访问、集成或用户可能抗拒的行为改变）、分发（是否有可重复触达目标用户的方式）、功能采用（对于功能工作，该功能会改变用户行为还是只是增加界面面积）。
3. 如果结论不明显，使用 references/risk-checklist.md 获取更深入的问题。
4. 保持回复简短且面向决策，按以下格式输出：1）风险判定：低、中或高风险，并用一句话解释原因；2）主要假设：最可能让项目失败的那个单一假设；3）首先需要寻找的证据：在继续构建前最小的有用信号；4）下一步行动：一个具体的验证步骤或缩减后的构建范围；5）推迟：暂时不要构建什么。
5. 对薄弱证据要直接，但避免否定用户的想法。
6. 优先选择更小的验证步骤，而不是大型研究计划。
7. 将产品风险与工程难度分开。
8. 如果想法已被验证，说明哪些证据使其风险更低，并建议最小的实现切片。
9. 如果缺少事实，指出缺失的证据，而不是编造市场论断。

适用边界 · 注意事项

• 当任务是狭窄的实现修复、重构、测试修复、依赖更新时，跳过此技能。
• 当变更已被验证且具有明确验收标准时，跳过此技能。