关于 pm-problem-statement
pm-problem-statement 是帮助产品团队撰写和检查问题陈述的技能，确保描述聚焦于用户遇到的具体困难，而非方案、症状或业务目标。它引导团队界定对象与情境、梳理原因，并以证据和可衡量结果支撑陈述。
主要功能
- 01区分问题、方案、症状与目标
- 02明确受影响用户和发生情境
- 03用追问梳理可能的根因
- 04以用户证据支持问题描述
- 05加入可检验的衡量要素
- 06按使用目的调整表述范围
适用场景
- 01把功能请求改写为用户问题
- 02为产品规格明确问题范围
- 03检查问题陈述是否有证据和可衡量结果
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/pm-problem-statement确认已加载。
详细介绍
问题陈述技能
此技能的工作方式（请先阅读）
这是一项生成式技能，而问题陈述正是大多数产品工作悄然出错的地方。Claude 默认会把请求复述成一个问题，然后继续推进——由此导致四种典型失败：伪装成解决方案的问题（“用户需要更好的搜索”）、含糊不清的问题（“用户体验很糟”“流程效率低”）、冒充问题的业务结果（“我们需要提高收入”），或把症状误当成原因（流失率上升 → “解决流失问题”）。每一种都会让团队非常有效地解决错误的问题。好的问题陈述应当是：真实用户在特定情境中遇到的差距，有证据支撑、可衡量，且不包含任何具体的解决方案名称。因此，此技能会把关以下事项：
- 明确你手头实际有什么——是已验证的问题，还是看起来像问题的提示词 / 信号 / 请求 / 指标。
- 应用始终适用的核心原则——将问题与解决方案 / 症状 / 目标区分开，找出真正的原因，使问题具体且可衡量，以证据为依据，并连接用户与业务。
- 呈现取决于具体情境的决策（使用哪种定义工具、现阶段需要多大程度的可衡量性、采用推理得出的原因还是经证据验证的原因、问题范围），并说明其中的权衡。
随后，它会将工作**交接给 pm-okr-metric-validity-audit（可衡量要素）和 pm-assumption-rigor-audit（假设的根本原因）**进行验证。
范围：此技能负责问题陈述这一交付成果。它将更广泛的问题发现流程交由 pm-discovery 处理，将假设 / 实验设计交由 pm-assumption-testing 处理，将问题陈述转化为完整规格说明交由 pm-product-spec 处理（由 pm-spec-quality-audit 审核），将待解决问题的排序交由 pm-prioritization-rigor-audit / pm-prioritization 处理，将用户画像的深度交由 pm-personas-jtbd 处理，并将用户故事交由 pm-user-story 处理。
步骤 0 — 撰写陈述前先明确情境
如果信息未知，请提问；如果在没有答案的情况下继续，请说明所采用的假设：
- 你手头实际有什么？ 一个波动的指标、一项功能请求（“添加 X”）或一项含糊的指示（“改进新手引导”）都是信号或解决方案，而不是问题。先用不涉及指标、工具或期望结果的方式重新表述。判断标准：经历这一问题的人，有可能会说出这句话吗？
- 这是谁的问题，发生在什么情境中？ 问题需要明确的群体、时刻和困难。“提高参与度”只有在表述为“新用户因必需步骤不清楚而放弃设置”后，才变得可处理。
- 有哪些证据支持它——原因是已知的还是假设的？ 区分已核实的内容与推断得出的内容。此阶段的根本原因通常是基于推理的判断，而非已证实的结论。
- 这份陈述将用于什么？ 规格说明、探索工作、OKR，还是面试 / 案例题回答——这决定了它需要达到何种可衡量程度和正式程度。
始终适用的核心原则（适用于任何问题陈述）
- 问题是差距，而不是功能。 从用户的角度描述当前状态与期望状态之间的距离，不提及任何解决方案。将“我们需要添加 / 应该构建 / 产品缺少……”转化为对困难、缓慢、令人困惑或有风险之处的中性描述。检验方法： 如果只有一种解决方案能解决它，那它就是伪装成问题的解决方案——真正的问题应该留有多种解决方案的空间。
- 将问题与症状、目标和约束区分开来。 变化中的指标（客户流失、采用率低）是症状；“提高留存率 / 收入”是目标或业务成果；预算和时间线是约束。问题在这些因素之下——是导致症状的用户困难。“我们需要提高收入”绝不是问题。
- 找到真正的原因，而非表面现象。 运用 5 Whys / 推理，从症状追溯到根因。原因必须能从逻辑上解释症状，并经得起质疑（“该功能已经在引导流程中展示过了，所以‘用户不知道它的存在’站不住脚——更可能是它出现的时机不对”）。将原因视为一种解释，它在受到质疑时必须始终自洽。
- 具体且以事实为依据。 “用户不满意”掩盖了原因和影响。明确指出谁受到影响、问题在何时 / 何处发生、具体障碍是什么，以及可衡量的后果。❌ “我们需要重新设计应用。” ✅ “由于商品页与结账页之间的导航不清晰，用户无法完成购买。”
- 让问题可衡量。 加入一项指标，让成功可以检验，并界定范围（“在一个月内将购物车放弃率降低 15%”）。可衡量的要素也可以作为未来的关键结果。没有它，你就无法判断是否成功——但要确保它代表真实成果，而不是虚荣指标。
- 以证据为基础，而非内部假设。 根据用户信号验证问题——访谈、支持工单、分析数据、会话回放——并归纳其中的模式。将定性反馈编码为定量发现（“45% 的报告提到了结账错误”），能让观点成为证据。仅基于团队看法构建的问题陈述，恰恰是失败所在。
- 连接用户与业务。 将用户困难与其业务影响（转化流失、客户流失、成本、风险）联系起来，让问题得到重视——但不要将用户需求与业务目标视为相互竞争。将业务问题转化为其背后的用户问题：“注册人数不足” → 用户为什么不注册（价值不明确？流程复杂？缺乏信任？）。
- 使用前先检验问题陈述。 设计、工程和领导团队是否都能理解谁受到影响、为什么重要以及出了什么问题——无需额外解释，也没有预先嵌入解决方案？如果它总需要重新诠释，就还没有写好。
可行的结构：问题 + 后果 / 影响 + 预期目标，包含谁 / 何时的情境 / 可衡量要素；也可以采用以用户为中心的 4 Ws（Who、What、Where、Why）。
依赖上下文的决策（呈现出来，不要自动应用）
逐项说明取舍，并给出与 Step 0 相关的建议；由用户选择。每个提示词都运行所有框架是错误做法——应选用能弥补具体缺口的工具。
| 决策 | 适用情况 | 避免／调整的情况 | 默认建议 |
|---|---|---|---|
| 使用哪种定义工具 | 根据缺口选择：角色画像／共情图（不清楚是谁、有什么感受）、旅程图（不清楚处于流程的哪个环节）、5 Whys／亲和图（不清楚原因）、假设映射（团队的信念未经检验） | 把运行所有框架当作惯例，这会让问题淹没在各种产物中 | 先进行一轮 5 Whys，再用 Who/What/Where/Why 梳理；仅在仍存在具体缺口时添加其他工具 |
| 现在需要多高的可衡量性 | 要提供给规格说明或承诺投入资源时——纳入一项指标，并将其关联到 OKR | 最早期的问题梳理阶段，此时任何数字都只是猜测 | 问题得到验证后再加入可衡量要素；确保它可证伪，而非虚荣指标 |
| 推理得出的原因，还是经证据验证的原因 | 用于访谈、案例研究或早期低风险的问题梳理时，推理得出的原因可以接受 | 基于从未向用户核实过的原因承诺实际开发资源 | 先推理，再在编写规格说明前用用户证据验证；验证严谨程度应与风险相匹配 |
| 存在歧义时：假设还是提问 | 只询问 1–2 个会改变问题梳理结果的问题；否则说明有依据的假设 | 对每个未知因素都提问（会造成停滞），或默默猜测（隐藏风险） | 明确说明假设；只询问会改变问题梳理结果的内容 |
| 范围／粒度 | 聚焦到具体群体和时刻，以便继续分析 | 范围过广（“改善 UX”）或任意缩小范围 | 明确一个群体、情境和困难——范围要足够广，允许多种解决方案；也要足够窄，便于采取行动 |
验证结果（编排）
交接时使用每个视角对应的可安装技能
name。仅当该技能已安装时才调用；如果未安装，此技能本身的核心内容已涵盖这些规则——继续处理，不要因此受阻。
产出或修订内容后，应交由审查视角检查，而不是直接宣布完成。这些都是候选视角——请遵循 docs/orchestration-policy.md 中的处理方式，或将整个产物交由 pm-product-review 审查。此处，assumption-rigor 是始终相关的视角（自动运行）；其他视角则是可选的，应根据产物的实际内容决定。如果用户调用此技能是为了处理某个特定事项，请遵守该范围。
pm-assumption-rigor-audit(自动运行) — 根本原因在验证之前都只是一个假设。是否如实指出了风险最高的原因主张？其背后的证据是否真实（多个来源呈现出某种模式），而非单一轶事或内部信念？pm-okr-metric-validity-audit(若包含可衡量要素，则提供此审查) — 这项可衡量要素是否确实反映用户的成功，是可证伪的结果，而非虚荣指标或可被操纵的数字？（这也是很可能会成为关键结果的指标。）
组合关系（参见 docs/orchestration-policy.md §9）： 如果探索尚未揭示潜在问题，那么这项工作（pm-discovery）属于上游输入；为该问题陈述设计的测试（pm-assumption-testing）和它将成为的规格说明（pm-product-spec）属于下游工作（可提议下一步产出，但不要自动生成）。如果审查发现冲突（例如，唯一可用的指标是虚荣指标，或原因无法用证据证实），应以目的为准作出调整：问题陈述旨在让整个团队聚焦于正确的问题——应保持真实、具体且可证实，而非仅仅图方便。 若要完成从构想到计划的全流程构建，pm-idea-to-plan 是组合式入口，它会按顺序编排此步骤与后续步骤，并确保在规格说明之前先提供证据。
常见的正确与错误模式
| ❌ 不要这样做 | ✅ 应该这样做 |
|---|---|
| “用户需要更好的搜索功能” | “新用户找不到相关产品，因为分类方式与他们的思维习惯不符，因此有 40% 的用户未购买就离开了” |
| “用户体验很糟糕”／“流程效率低下” | 明确指出涉及谁、发生在何时、具体障碍是什么，以及可衡量的影响 |
| “我们需要提高收入”（业务结果） | 将其转化为背后的用户问题（“用户在付款前放弃了结账”） |
| 把症状（用户流失）当作问题 | 通过 5 Why 追溯根因；症状是信号，而不是问题本身 |
| 把解决方案写进问题描述 | 描述差距，让多种解决方案都有机会解决它 |
| 不设定可衡量的指标 | 加入可证伪的指标；它会成为关键结果 |
| 根据团队的假设来制定 | 以用户证据为基础；将定性反馈编码为定量发现 |
| 把有理有据的原因当作已证实的结论 | 先推理，再验证，然后才投入实际资源 |
| 范围过广（“改进新手引导”） | 将范围缩小到具体的群体、时机和困难 |
| 不经检查就发布这项陈述 | 交由 okr-metric-validity + assumption-rigor 处理 |