评估AI产品想法是否值得投入时，用推荐画布产出可辩护提案

在需要判断AI产品/功能是否值得投资、向决策者提案或比较多个AI方案时，用结构化推荐画布评估成果、假设、风险和定位。

适用场景

解决思路

1. Step 1：收集上下文，确保已有问题理解，包括用户研究、痛点，可参考 `skills/problem-statement/SKILL.md`。
2. Step 1：明确 persona，确认谁经历该问题，可参考 `skills/proto-persona/SKILL.md`。
3. Step 1：补充市场上下文，包括竞争格局和品类定位。
4. Step 1：确认业务约束，包括预算、时间线和战略优先级。
5. Step 1：如果缺少上下文，先做 discovery 工作；画布是综合洞察，不是创造洞察。
6. Step 2：定义 Business Outcome，使用格式：[Direction] [Metric] [Outcome] [Context] [Acceptance Criteria]。
7. Step 2：Business Outcome 质量检查：可度量、有时间限制、有野心但现实。
8. Step 2：定义 Product Outcome，使用格式：[Direction] [Metric] [Outcome] [Context from persona's POV] [Acceptance Criteria]。
9. Step 2：Product Outcome 质量检查：以客户为中心，用用户视角写成“I”而不是“we”；写成果而非功能。
10. Step 3：框定问题，使用问题陈述叙事，可参考 `skills/problem-statement/SKILL.md`。
11. Step 3：编写 Problem Statement Narrative：用 2-3 句话从 persona 的 POV 讲 persona 的故事。
12. Step 3：问题陈述质量检查：有同理心、具体、经过验证，基于真实用户研究而非假设。
13. Step 4：定义 Solution Hypothesis，使用 epic hypothesis 格式，可参考 `skills/epic-hypothesis/SKILL.md`。
14. Step 4：编写 Hypothesis Statement：If we [action or solution on behalf of target persona] for [target persona] Then we will [attain or achieve desirable outcome]。
15. Step 4：定义 Tiny Acts of Discovery：设计轻量实验验证假设。
16. Step 4：Tiny Acts of Discovery 示例：用 5 个 freelancer 测试 AI reminder 原型；对 20 个用户 A/B test 手动 vs AI-timed reminders；2 周后调查用户感知价值。
17. Step 4：Tiny Acts of Discovery 质量检查：快，按天/周而不是按月；便宜，用原型/礼宾测试而非完整开发；可证伪，能证明你是错的。
18. Step 4：定义 Proof-of-Life：在 [timeframe] 内观察验证指标。
19. Step 4：Proof-of-Life 包括定量结果，例如 80% 用户通过 AI 系统发送提醒；和定性结果，例如 10 个用户中 8 个报告每月节省 5+ 小时。
20. Step 5：定义 Positioning，使用 positioning statement 格式，可参考 `skills/positioning-statement/SKILL.md`。
21. Step 5：编写 Value Proposition：For [target customer/user persona] that need [statement of underserved need] [product name] is a [product category] that [statement of benefit, focusing on outcomes]。
22. Step 5：编写 Differentiation Statement：Unlike [primary competitor or competitive arena] [product name] provides [unique differentiation, focusing on outcomes]。
23. Step 6：记录 Assumptions & Unknowns，列出假设和未知项及描述。
24. Step 6：Assumptions & Unknowns 质量检查：显式化隐藏假设；每条假设都可通过实验验证。
25. Step 7：识别 PESTEL Risks，分高优先级待调查和低优先级待监控。
26. Step 7：Risks to Investigate 高优先级：分别填写 Political、Economic、Social、Technological、Environmental、Legal 风险。
27. Step 7：Risks to Monitor 低优先级：分别填写 Political、Economic、Social、Technological、Environmental、Legal 风险。
28. Step 8：进行 Value Justification，先判断 Is this Valuable?，选择 Absolutely yes / Yes with caveats / No with suggested alternatives / Absolutely NO!。
29. Step 8：编写 Solution Justification，面向 C-level 高管，列出 3 条理由和描述来说服他们。
30. Step 9：定义 Success Metrics，使用 SMART 指标（Specific、Measurable、Attainable、Relevant、Time-Bound）。
31. Step 9：为每个成功指标写出具体目标，例如 3 个月内 80% 活跃用户采用 AI reminders；6 个月内支付跟进时间下降 50%；6 个月内发票功能 NPS 从 6 升到 8。
32. Step 10：定义 What's Next，列出战略下一步。
33. Step 10：下一步示例：和 10 个 beta 用户做 2 周原型测试；构建轻量 AI 模型优化提醒时机；对 GDPR 影响做法律审查；向 exec team 汇报发现以做 go/no-go 决策；如果验证通过则加入 Q2 roadmap。
34. 避坑：不要写模糊成果；用 [Direction] [Metric] [Outcome] [Context] [Acceptance Criteria] 公式并具体化。
35. 避坑：不要 solution-first；从用户视角框定问题，让 solution hypothesis 从已验证痛点中浮现。
36. 避坑：不要跳过 Tiny Acts of Discovery；先定义 2-3 个轻量实验，再投入工程资源。
37. 避坑：不要写泛泛的 PESTEL 风险；具体到可行动，例如“存储客户邮件时机数据的 GDPR 合规需要法律审查”。
38. 避坑：不要弱化 Value Justification；用数据，例如“用户研究中排名第 1 的痛点；减少 20% churn = $500k ARR；低技术风险”。

适用边界 · 注意事项

• 不要用于 trivial features，不要为小改动过度设计。
• 不要在任何 discovery 工作之前使用；需要先有用户研究和问题验证。
• 不要把它当作实验的替代品；画布用于指导实验，而不是反过来。