关于 problem-framing-canvas
通过 MITRE Problem Framing Canvas 引导产品经理审视假设、理解受影响者，并将发现整理为问题陈述和“How Might We”问题。它聚焦问题界定，而非方案构思。
主要功能
- 01审视团队假设与偏见
- 02识别受影响及被忽视群体
- 03分阶段自适应提问
- 04生成问题陈述与 HMW 问题
适用场景
- 01启动新项目的用户发现
- 02重新审视既有问题定义
- 03在提出方案前校准团队认知
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/problem-framing-canvas确认已加载。
附带文件examples/sample.mdtemplate.md
详细介绍
目的
引导产品经理完成 MITRE 问题界定画布流程，通过三个阶段提出结构化问题：向内审视（检查自身的假设和偏见）、向外审视（了解谁受到问题影响，谁没有受到影响），以及重新界定（综合洞见，形成可执行的问题陈述和“我们如何才能……”问题）。在着手寻找解决方案之前，先确保你解决的是正确的问题，避免确认偏误、忽略利益相关方，以及先入为主地寻求解决方案。
这不是解决方案头脑风暴，而是一种问题界定工具，旨在拓宽视角、挑战假设，并产出清晰且以公平为导向的问题陈述。
输入
最适合提供： 问题领域——无论你目前对它的理解有多粗略。 也有帮助： 你认为受到问题影响的人、目前掌握的证据，以及大家已经认定的解决方案（点明这一点有助于画布消除偏见）。
调用时提供的任何内容——技能名称后面的文字、粘贴的上下文内容，或附加的 ARGUMENTS: 行——都视为已给出的答案。请利用这些内容，并跳过其中已涵盖的问题，不要重复提问。
两手空空也没关系。 该技能会从“向内审视”阶段开始：你对这个问题有哪些假设？
调用示例： Frame this problem: field sales reps 'don't use the CRM' and leadership wants gamification.
核心概念
什么是 MITRE 问题界定画布？
问题界定画布（MITRE Innovation Toolkit，v3）是一种结构化框架，可帮助团队在提出解决方案之前，全面探索问题空间。它分为三个部分：
- 向内审视 — 检查自身的假设、偏见，以及自己可能如何成为问题的一部分
- 向外审视 — 了解谁受到问题影响、谁从中受益，以及谁被排除在外
- 重新界定 — 综合洞见，形成清晰、可执行的问题陈述和“我们如何才能……”问题
画布结构
┌─────────────────────────────────────────────────────────────────┐
│ LOOK INWARD │
│ - What is the problem? (symptoms) │
│ - Why haven't we solved it? (new, hard, low priority, etc.) │
│ - How are we part of the problem? (assumptions, biases) │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ LOOK OUTWARD │
│ - Who experiences the problem? When/where/consequences? │
│ - Who else has it? Who doesn't have it? │
│ - Who's been left out? │
│ - Who benefits when problem exists/doesn't exist? │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ REFRAME │
│ - Stated another way, the problem is: [restatement] │
│ - How might we [action] as we aim to [objective]? │
└─────────────────────────────────────────────────────────────────┘
为什么有效
- 拓宽视角： 促使你跳出自身假设看问题
- 以公平为导向： 关注边缘化群体的声音，并追问“谁被排除在外？”
- 挑战偏见： 在界定问题之前，要求明确审视假设
- 产出可执行的成果： 形成可用于探索解决方案的 HMW 陈述
反模式（本工具不是什么）
- 不是解决方案头脑风暴： 画布用于界定问题；解决方案留待之后探讨
- 不是功能需求清单： 关注潜在问题，而非表面症状
- 不是单人练习： 需要多元视角来挑战群体迷思
适用场景
- 为新项目启动发现工作
- 重新界定现有问题（怀疑自己解决的方向不对）
- 在构建解决方案之前挑战假设
- 帮助跨职能团队就问题定义达成一致
不适用场景
- 问题已得到充分理解并经过验证
- 处理战术性 Bug 修复或技术债务（无需深入界定）
- 利益相关方已承诺采用某个解决方案（先解决协同问题）
引导流程的权威来源
默认使用 workshop-facilitation 作为此技能的交互流程规范。
其中定义了：
- 会话预告和进入模式（引导式、上下文倾倒、最佳猜测）
- 每轮一个问题，并使用通俗易懂的提示语
- 进度标签（例如 Context Qx/8 和 Scoring Qx/5）
- 中断处理以及暂停／恢复行为
- 在决策节点提供编号建议
- 为常规问题提供编号快速选择项（适用时包含
Other (specify)）
此文件定义了特定领域的评估内容。如有冲突，请遵循此文件的领域逻辑。
使用方法
使用 template.md 获取完整的填写结构。
此交互式技能分为三个阶段，每个阶段都会提出自适应问题。
步骤 0：收集背景信息（提问之前）
Agent 建议：
在界定问题之前，我们先收集背景信息：
问题背景：
- 初始问题陈述或利益相关方的请求
- 你观察到的症状（支持工单、用户流失数据、用户投诉）
- 现有研究（用户访谈、调查、分析数据）
- 你对问题所做的假设
利益相关方背景：
- 谁会受到这个问题的影响？（用户、客户、内部团队）
- 谁在要求解决这个问题？（高管、销售团队、客户）
- 可能有哪些人被忽略了？
你可以直接粘贴这些内容，也可以简要描述问题。
阶段 1：审视自身
目标： 检视你自己的假设、偏见，以及你可能如何成为问题的一部分。
问题 1：问题是什么？（描述症状）
Agent 提问： “根据你目前的理解，问题是什么？请描述相关症状。”
提供 4 个编号选项：
- 客户痛点 — “客户在[特定任务或目标]上遇到困难”（例如：“客户找不到他们需要的功能”）
- 业务指标问题 — “我们发现[指标下降]”（例如：“上个季度的流失率上升了 15%”）
- 利益相关方请求 — “利益相关方认为我们需要[功能或变更]”（例如：“销售团队认为我们需要更好的报告功能”）
- 观察到的行为 — “我们注意到[某种模式或趋势]”（例如：“用户在引导流程的第 3 步退出”）
或者描述你的问题或症状。
用户回应： [选择或自定义]
Agent 提取：
- 问题（初步界定）： [用户描述]
问题 2：为什么我们还没有解决这个问题？
Agent 提问： “为什么这个问题至今还没有得到解决？”
提供 6 个编号选项（可多选）：
- 这是个新问题 — “问题最近才出现”
- 问题很棘手 — “技术上很复杂，或需要大量资源”
- 优先级较低 — “其他事项优先处理”
- 资源不足 — “预算、人手或时间不够”
- 缺乏决策权 — “无法做出决定或争取到支持”
- 存在系统性不平等 — “问题对边缘化群体的影响尤为严重，他们被忽视了”
或者描述你自己的原因。
用户回应： [选择或自定义]
Agent 记录：
- 解决问题的障碍： [原因列表]
问题 3：我们如何成为问题的一部分？（假设与偏见）
Agent 提问： “你（或你的团队）可能如何成为问题的一部分？你们带来了哪些假设或偏见？”
提供 4 个编号选项：
- 假设我们知道客户想要什么 — “我们尚未与真实用户验证”（确认偏误）
- 为自己而非用户进行优化 — “构建对我们来说容易、而非对用户来说有价值的内容”（内部偏见）
- 忽视特定用户群体 — “只关注多数用户，忽略边缘情况或边缘化群体”（幸存者偏差）
- 先入为主地考虑解决方案 — “还没弄清根本问题，就跳到‘我们需要[功能 X]’”（过早收敛）
或者描述你自己的具体假设或偏见。
用户回应： [选择或自定义]
Agent 记录：
- 需要审视的假设： [偏见列表]
阶段 2：审视外部
目标： 了解谁在经历这个问题、谁从中受益，以及谁被排除在外。
问题 4：谁会遇到这个问题？（何时、何地、后果）
Agent 提问： “谁会遇到这个问题？他们何时、何地会遇到？会面临哪些后果？”
Agent 提示用户描述：
- 谁： 具体的用户画像、用户群体或角色
- 何时： 触发事件或情境（例如“入职引导期间”“月末结账时”）
- 何地： 物理或数字场景（例如“移动应用”“企业部署”）
- 后果： 对用户的影响（例如“每周浪费 2 小时”“错过截止日期”“流失”）
适配方式： 使用上下文中的用户画像（初步用户画像、JTBD、客户研究）
用户回复： [详细描述]
Agent 记录：
- 遇到问题的人： [用户画像/群体]
- 时间/地点： [情境]
- 后果： [影响]
问题 5：还有谁会遇到这个问题？谁不会？
Agent 提问： “还有谁会遇到这个问题？（同事、竞争对手、其他领域的人？）谁不会遇到？”
Agent 提示：
- 还有谁会遇到： 有类似问题的其他公司、行业或领域
- 他们如何应对： 权宜之计、解决方案或调整方式
- 谁不会遇到： 能避开这个问题的用户/公司（他们有哪些不同之处？）
用户回复： [详细描述]
Agent 记录：
- 还有谁会遇到： [示例]
- 谁不会遇到： [反例]
问题 6：谁被忽略了？谁会受益？
Agent 提问： “迄今为止，谁被排除在讨论之外？当这个问题存在或不存在时，谁会受益？”
Agent 提示：
- 谁被忽略了： 边缘群体的声音、边缘情况、被忽视的利益相关者
- 问题存在时谁受益： 谁能从现状中获益？
- 问题不存在时谁受益： 问题解决后，谁会失去利益？
示例：
- “入职引导流程有问题时，谁会受益？” → “销售团队不用支持复杂工作流；工程团队不用构建引导式流程”
- “谁被忽略了？” → “非技术用户、国际客户（入职引导只有英文版）”
用户回复： [详细描述]
Agent 记录：
- 被忽略的人： [列表]
- 受益者（问题存在时）： [列表]
- 受益者（问题解决时）： [列表]
阶段 3：重新定义
目标： 综合洞见，形成清晰、可执行的问题陈述和“我们如何才能”问题。
问题 7：重新陈述问题
Agent 说： “根据我们探讨的所有内容，让我们换一种方式重新陈述这个问题。”
Agent 根据阶段 1–2 的洞见生成经过完善的问题陈述：
模板： “问题是：[谁]难以[完成什么]，因为[根本原因]，导致[后果]。这影响了[具体群体]，此前一直被忽视，因为[阶段 1 中的偏见/假设]。”
示例（SaaS 入职引导）： “问题是：非技术型小企业主在入职引导期间难以启用我们的产品，因为我们使用充满行话的 UI，且缺少引导式工作流，导致 60% 的用户在 24 小时内放弃。这对缺少技术支持的个体经营者影响尤为严重，而此前一直被忽视，因为我们的团队优先优化企业用户的体验，他们通常配有 IT 部门。”
Agent 提问： “这样的重新陈述是否抓住了问题的核心？我们需要进一步完善吗？”
用户回复： [批准或修改]
问题 8：创建“我们如何才能”问题
Agent 说： “现在，让我们用一个‘我们如何才能’问题，让问题变得可执行。”
模板： “我们如何才能[解决问题的行动]，以实现[目标/理想状态]？”
示例（SaaS 入职引导）： “我们如何才能通过通俗易懂的提示，引导非技术用户完成入职引导，以将启用率从 40% 提高到 70%？”
Agent 提问： “这个 HMW 问题是否为解决方案设定了合适的探索范围？我们需要调整吗？”
用户回复： [批准或修改]
输出：问题界定画布 + HMW 陈述
完成流程后，Agent 会输出：
# Problem Framing Canvas: [Problem Name]
**Date:** [Today's date]
---
## Phase 1: Look Inward
### What is the problem? (Symptoms)
[Description from Q1]
### Why haven't we solved it?
- [Barrier 1 from Q2]
- [Barrier 2]
- [Barrier 3]
### How are we part of the problem? (Assumptions & biases)
- [Assumption 1 from Q3]
- [Assumption 2]
- [Assumption 3]
**Which of these might be redesigned, reframed, or removed?**
[Reflection on biases to challenge]
---
## Phase 2: Look Outward
### Who experiences the problem?
**Who:** [Personas/segments from Q4]
**When/Where:** [Context]
**Consequences:** [Impact on users]
**Lived experience varies:** [How different users experience it differently]
### Who else has this problem?
**Who else:** [Examples from Q5]
**How they deal with it:** [Workarounds]
### Who doesn't have it?
[Counter-examples from Q5]
### Who's been left out?
[Marginalized voices from Q6]
### Who benefits?
**When problem exists:** [Beneficiaries of status quo]
**When problem doesn't exist:** [Who loses if solved]
---
## Phase 3: Reframe
### Stated another way, the problem is:
[Refined problem statement from Q7]
### How Might We...
**How might we** [action from Q8] **as we aim to** [objective from Q8]?
---
## Next Steps
1. **Validate with users:** Use `skills/discovery-interview-prep/SKILL.md` to test reframed problem with customers
2. **Generate solutions:** Use `skills/opportunity-solution-tree/SKILL.md` to explore solution space
3. **Create problem statement:** Use `skills/problem-statement/SKILL.md` to formalize for PRD/roadmap
4. **Identify opportunities:** Use HMW statement to brainstorm solution ideas
---
**Ready to explore solutions? Let me know if you'd like to refine the problem framing or move to solution generation.**
示例
完整的问题界定示例请参阅 examples/sample.md。
迷你示例摘录：
**Look Inward:** Churn spiked after onboarding change
**Look Outward:** New SMB users are most affected
**Reframe:** How might we reduce onboarding friction for first-time users?
常见陷阱
陷阱 1：跳过“向内审视”（假设自己是中立的）
症状： 团队未经审视偏见，就直接开始“向外观察”
后果： 群体思维持续存在，假设未经质疑
解决方法： 要求明确讨论假设和偏见（Q2-Q3）
陷阱 2：忽视“谁会受益”这个问题
症状： 完成画布时，没有探讨问题存在会让谁受益
后果： 忽视政治动态和变革阻力
解决方法： 务必询问“如果问题得到解决，谁会受损？”（Q6）
陷阱 3：问题陈述过于笼统
症状： 重新界定的问题含糊不清（“改善用户体验”）
后果： HMW 陈述无法付诸行动
解决方法： 明确具体问题（对象、内容、时间、后果、根本原因）
陷阱 4：HMW 陈述范围过窄
症状： “我们如何开发一款移动应用？”
后果： 将解决方案限制为单一想法
解决方法： 保持 HMW 的开放性：“我们如何让移动优先的用户能够在任何设备上使用核心工作流？”
陷阱 5：独自完成练习（缺少多元观点）
症状： PM 独自填写画布
后果： 偏见持续存在，边缘化群体的声音仍被排除在外
解决方法： 邀请跨职能团队并结合客户意见，组织画布研讨会
参考资料
相关技能
skills/problem-statement/SKILL.md— 将重新界定的问题转化为正式的问题陈述skills/opportunity-solution-tree/SKILL.md— 使用 HMW 陈述生成解决方案选项skills/discovery-interview-prep/SKILL.md— 与客户验证重新界定的问题
外部框架
- MITRE 创新工具包，“Problem Framing Canvas v3”（2021）——画布的起源，基于公平的设计思维
- Stanford d.school，“How Might We”陈述——可付诸行动的问题界定
Dean 的工作
- [如果 Dean 有问题界定资源，请在此添加链接]
技能类型： 交互式
建议文件名： problem-framing-canvas.md
建议放置位置： /skills/interactive/
依赖项： 使用 skills/problem-statement/SKILL.md