在跳向解决方案前，用 MITRE…

适用于新产品/新举措发现、重新框定现有问题或跨职能对齐问题定义时，通过 Look Inward、Look Outward、Reframe 三阶段避免确认偏误、遗漏干系人与解决方案优先思维。

适用场景

解决思路

1. 使用 workshop-facilitation 作为默认交互协议：会话开头给出 session heads-up 和进入模式（Guided、Context dump、Best guess）；每次只问一个问题并用平实语言；显示进度标签（如 Context Qx/8、Scoring Qx/5）；支持打断、暂停/恢复；在决策点给编号建议；常规问题提供编号快速选择选项（必要时含 Other (specify)）；若与本文件领域逻辑冲突，以本文件领域逻辑为准。
2. Step 0：先收集上下文。最好提供问题领域；也尽量提供你认为谁经历、目前证据，以及大家已锚定的解决方案。建议收集 Problem Context（初始问题陈述或干系人请求、已观察症状如支持工单/流失数据/用户投诉、现有研究如用户访谈/问卷/分析、你对问题的假设）和 Stakeholder Context（谁受影响如用户/客户/内部团队、谁要求解决如高管/销售/客户、谁可能被忽略）。可粘贴内容或简要描述问题。调用中已提供的内容视为已答，跳过覆盖部分，不要重复问；空手也可以，从 Look Inward 开始问「你对此问题有什么假设？」
3. 按三阶段流程推进，每阶段自适应提问：Look Inward、Look Outward、Reframe。
4. 使用 template.md 获取完整填写结构。
5. Phase 1 Look Inward Q1：问「你目前如何理解这个问题？描述症状」。提供 4 个编号选项：1) 客户痛点，如「客户难以完成[具体任务/结果]」；2) 业务指标问题，如「[指标]下降」；3) 干系人请求，如「干系人说我们需要[功能/变更]」；4) 观察到的行为，如「我们注意到[模式/趋势]」。也允许自定义描述。提取 Problem (initial framing)。
6. Phase 1 Look Inward Q2：问「为什么这个问题还没有被解决？」提供 6 个可多选编号选项：1) 它是新的；2) 它很难；3) 优先级低；4) 缺少资源；5) 缺少权限；6) 系统性不平等。也允许自定义。记录 Barriers to solving。
7. Phase 1 Look Inward Q3：问「你或你的团队可能如何成为问题的一部分？你带来了哪些假设或偏见？」提供 4 个编号选项：1) 假设我们知道客户想要什么（确认偏误）；2) 为自己而不是用户优化（内部偏见）；3) 忽略特定用户群体（幸存者偏差）；4) 解决方案优先思维（过早收敛）。也允许自定义。记录 Assumptions to challenge。
8. Phase 2 Look Outward Q4：问「谁经历这个问题？何时、何地经历？面临什么后果？」提示描述 Who（具体 personas、用户细分或角色）、When（触发事件或情境，如 onboarding、月末结账）、Where（物理或数字位置，如 mobile app、enterprise deployments）、Consequences（对用户的影响，如每周浪费 2 小时、错过截止、流失）。可适配上下文中的 personas（proto-personas、JTBD、客户研究）。记录谁经历、何时/何地、后果。
9. Phase 2 Look Outward Q5：问「还有谁有这个问题？（同事、竞争对手、其他领域？）谁没有这个问题？」提示：还有谁有；他们如何应对（workarounds、解决方案、适应方式）；谁没有（避开问题的用户/公司有什么不同）。记录 who else、who doesn't。
10. Phase 2 Look Outward Q6：问「目前谁被排除在对话之外？当问题存在或不存在时，谁受益？」提示：谁被排除（边缘化声音、边缘案例、被忽略的干系人）；问题存在时谁受益（谁从现状获益）；问题不存在时谁受益（问题被解决时谁受损）。例如「onboarding 坏掉时谁受益？」→「销售团队不必支持复杂工作流；工程不必构建引导流程」；「谁被排除？」→「非技术用户、国际客户（onboarding 仅英文）」。记录谁被排除、谁在问题存在时受益、谁在问题解决时受益。
11. Phase 3 Reframe Q7：根据 Phase 1-2 洞见重构问题陈述。使用模板：「The problem is: [Who] struggles to [accomplish what] because [root cause], which leads to [consequence]. This affects [specific segments] and has been overlooked because [bias/assumption from Phase 1]。」生成后问「这个重构是否抓住核心问题？需要细化吗？」让用户批准或修改。
12. Phase 3 Reframe Q8：创建 How Might We 陈述。使用模板：「How might we [action that addresses the problem] as we aim to [objective/desired condition]?」生成后问「这个 HMW 是否设定了正确的解决方案空间？需要调整吗？」让用户批准或修改。
13. 输出 Problem Framing Canvas + HMW Statement：以 Markdown 输出，包含标题「Problem Framing Canvas: [Problem Name]」和日期；Phase 1: Look Inward（What is the problem? (Symptoms)、Why haven't we solved it?、How are we part of the problem? (Assumptions & biases)、Which of these might be redesigned, reframed, or removed?）；Phase 2: Look Outward（Who experiences the problem? 含 Who/When/Where/Consequences/Lived experience varies；Who else has this problem? 含 Who else/How they deal with it；Who doesn't have it?；Who's been left out?；Who benefits? 含 When problem exists/When problem doesn't exist）；Phase 3: Reframe（Stated another way, the problem is、How Might We...）；Next Steps。
14. Next Steps：1) 用 skills/discovery-interview-prep/SKILL.md 与客户验证重构后的问题；2) 用 skills/opportunity-solution-tree/SKILL.md 探索解决方案空间；3) 用 skills/problem-statement/SKILL.md 将其正式化为 PRD/roadmap；4) 用 HMW statement 头脑风暴解决方案想法。
15. 避免 Pitfall 1：不要跳过 Look Inward 或假设团队中立；强制明确讨论假设和偏见（Q2-Q3），否则 groupthink 持续、假设未被挑战。
16. 避免 Pitfall 2：不要忽略 Who Benefits 问题；始终问「如果这个问题被解决，谁会受损？」（Q6），否则会漏掉政治动态和对变革的阻力。
17. 避免 Pitfall 3：不要让问题陈述过于泛化（如「改善用户体验」）；让问题具体（谁、什么、何时、后果、根因），否则 HMW 不可执行。
18. 避免 Pitfall 4：不要让 HMW 太窄（如「How might we add a mobile app?」）；保持 HMW 宽泛（如「How might we enable mobile-first users to access core workflows on any device?」），否则会把解决方案空间限制到一个想法。
19. 避免 Pitfall 5：不要独自填写 canvas；组织跨职能团队 + 客户输入的工作坊，否则偏见仍在、边缘化声音仍被排除。

适用边界 · 注意事项

• 当问题已被充分理解并验证时，不适用。
• 对战术性 bug 修复或技术债，不适用（无需深度框定）。
• 当干系人已承诺某个解决方案时，不适用，应先解决对齐；也不要把此技能当成解决方案头脑风暴、功能请求清单或单人练习。