problem-framing-canvas
作者 deanpetersproblem-framing-canvas 技能会引导团队通过 MITRE 的 Problem Framing Canvas，在进入方案设计前先把模糊需求厘清。适合用于决策支持：当干系人意见不一致、假设不清楚，或者你需要更准确的问题陈述和 How Might We 问题时，都可以用它。
该技能评分为 84/100，说明它很适合作为目录收录项，面向那些需要结构化问题框定流程、而不是泛泛头脑风暴提示的用户。仓库提供了足够的操作细节，方便 agent 正确触发技能并按清晰可辨的流程执行；不过，相比更成熟的包，它在生态支持和面向安装的元数据方面还偏少。
- 触发条件明确：frontmatter 直接说明，当需要在解决方案之前先形成更清晰的问题陈述时应使用它，并给出了 onboarding 流失、干系人需求等具体场景。
- 工作流清楚：技能正文定义了三个阶段——Look Inward、Look Outward、Reframe，附带的模板和示例也展示了预期输出与提问顺序。
- 安装决策价值高：较长的正文、有效的 frontmatter 和示例文件，已经足以让用户判断是否适配，而不必猜测该技能应该如何使用。
- 没有安装命令或配套的元数据文件，因此接入时可能需要手动配置；与目录用户通常预期的相比，仓库提供的打包指引也更少。
- 现有证据表明这是一个内容丰富的方法论，但缺少脚本或参考来源，因此可信度更多依赖作者定义的工作流，而不是外部验证或自动化。
problem-framing-canvas 技能概览
problem-framing-canvas 能解决什么问题
problem-framing-canvas 技能会带团队走一遍 MITRE 的 Problem Framing Canvas，先把问题定义清楚，再急着想解决方案。它最适合需求模糊、利益相关方意见不一致，或者你怀疑团队正在优化错误结果的时候使用。
谁应该使用它
如果你是 PM、设计师、研究员或 facilitator，需要一种结构化方法把杂乱的需求整理成共同的问题陈述，那么就该用这个 problem-framing-canvas skill。当团队需要的是“接下来该做什么”的证据，而不只是更多点子时，problem-framing-canvas for Decision Support 尤其有用。
它为什么不一样
这个技能是交互式的，而且带有一种“有主见但很有用”的引导方式：它会推动你完成三个阶段——Look Inward、Look Outward 和 Reframe。相比通用 prompt，这种方式更适合你需要做偏差检查、覆盖各类利益相关方，并输出一个最终的 “How Might We” 表述，用来支持 workshop、roadmap 或 discovery 计划的时候。
如何使用 problem-framing-canvas 技能
安装并定位核心文件
进行 problem-framing-canvas install 时，请使用 skill directory 里显示的 repo 路径，并从 skills/problem-framing-canvas/SKILL.md 开始。然后阅读 template.md 了解输出结构，再看 examples/sample.md 参考一个高质量完成版 canvas 应该是什么样。
给技能一个真实问题，而不是一个话题
problem-framing-canvas usage 在你提供具体症状、背景和决策压力时效果最好。好的输入应该像这样： “为企业 SaaS 的首次管理员降低 onboarding 流失，支持工单显示他们在第 2 步就开始困惑。” 不好的输入只是：“改善 onboarding。”
使用三阶段工作流
一个好的 problem-framing-canvas guide 输入，能帮助技能按以下三步推进：
- Look Inward： 团队默认了什么、偏向什么，或者可能忽略了什么
- Look Outward： 谁正在感受到这个问题、它在什么时候发生，以及谁被排除在外
- Reframe： 一个更准确的问题陈述，以及一个可直接使用的 HMW 问题
通常有效的 prompt 格式
一次性要求输出完整 canvas，并补充所有重要约束，比如受众、业务目标或已知证据。例如：“请用 problem-framing-canvas 帮我们梳理新 SMB 客户的流失问题，前提是我们只有 support logs 和 product analytics。” 这样能给技能足够信号，让它保持扎实，而不是泛泛而谈。
problem-framing-canvas 技能 FAQ
这个比普通 prompt 更好吗？
通常是的，尤其当你的问题本身就很模糊时。普通 prompt 可能会过早产出点子，而 problem-framing-canvas 会先强制定义问题——这正是团队卡在症状争论时最有价值的部分。
什么时候不该用它？
如果问题已经定义得很清楚，而且你需要的是执行计划、文案写作或方案构思，那就不要用 problem-framing-canvas。它是一个 framing 工具，不是交付计划，也不是优先级排序框架。
对新手友好吗？
友好。canvas 结构很简单，但质量取决于输入。新手在提供一个具体问题、一个目标用户，以及至少一个已知约束或证据时，能拿到最多价值。
它和其他产品工作流怎么配合？
它最适合放在 discovery synthesis、roadmap 讨论或方案头脑风暴之前。先用它为问题建立共同语言，再在框架清晰后进入研究问题、实验设计或创意发散。
如何改进 problem-framing-canvas 技能
提供证据，而不只是观点
质量提升最大的地方，是加入具体输入：支持主题、漏斗流失、客户原话、丢单原因或观察到的行为。problem-framing-canvas 能更准确地区分症状和根因时，输出会明显更清晰。
明确边界条件
如果团队有约束，请一开始就说明：目标细分市场、时间线、平台、法律限制或业务目标。这些细节能帮助技能避免“什么都想解决”的宽泛 framing，并产出一个你真正能用的 HMW 问题。
留意最常见的失败模式
最常见的失误，是把问题写成了解决方案的样子，比如“我们需要更好的 dashboard”或“我们需要 AI 自动化”。改进 problem-framing-canvas skill 输出的方式，是先重述用户痛点和上下文，再追问到底是什么被阻塞了，或者哪里被误解了。
用一个更收敛的追问继续迭代
第一次 canvas 完成后，如果陈述还是太宽泛，就继续要求它收窄。一个有用的追问是：“把它只针对首次使用者重写一版”，或者“只使用本季度能验证的证据来重写这个问题。” 这种收敛通常比继续要更多点子，更能提升决策质量。