problem-statement

problem-statement skill 概览

problem-statement skill 帮你把模糊的产品诉求，转成以用户为中心的问题陈述，说明是谁被卡住了、他们想完成什么、为什么这件事重要，以及这件事带来的感受。它最适合在方案讨论之前先对齐认知：需求探索、优先级排序、PRD 和利益相关方评审。

problem-statement 的用途

这个 problem-statement skill 的定位是“问题框架”，不是“功能设计”。它帮助你从用户视角描述问题，让团队在讨论实现方案之前，先判断这件事值不值得做。

最适合的使用者

如果你会写产品 brief、技术规格、研究总结或路线图备注，并且需要把问题叙述写得更清晰，这个 skill 很适合你。对于 Technical Writing 工作流来说，当你需要把杂乱输入整理成一句简洁、共情的问题陈述时，它尤其有用。

它的不同之处

这个 skill 以问题框架为核心：I am、Trying to、But、Because 和 Which makes me feel，再加上上下文和约束条件。相比通用 prompt，这种结构更有助于做决策，因为它会强迫你同时抓住功能性阻碍和人的影响。

如何使用 problem-statement skill

安装并查看这个 skill

使用以下命令安装：

npx skills add deanpeters/Product-Manager-Skills --skill problem-statement

然后先看 skills/problem-statement/SKILL.md，再看 template.md 和 examples/sample.md。这是最快理解预期结构、最终输出形式，以及一份合格 problem statement 长什么样的方法。

在 prompt 里要提供什么

想把 problem-statement 用好，就要给这个 skill 一个粗略但具体的输入：用户类型、他们想完成的任务、卡点，以及任何约束条件。如果你只给功能需求，输出就会偏向解决方案语言，而不是一个真正的问题。

更强的输入可以这样写：

• Persona: “new support agents on mobile”
• Goal: “resolve tickets without switching tools”
• Blocker: “they lose context between CRM and chat”
• Constraints: “high volume, low training time, remote-first team”

建议的工作流

先写一个短草稿，再把它收紧成五段式叙述。把 template 当成检查清单来用：如果 Because 听起来像解决方案，就回头追问到底是什么在制造痛点；如果 Which makes me feel 太泛，就换成和工作流直接相关的真实用户情绪。

先读哪些文件

优先看 SKILL.md、template.md 和 examples/sample.md。其中示例文件尤其有价值，因为它同时展示了一个好的框架和一个反例，能帮助你避免把解决方案伪装成问题陈述。

problem-statement skill 常见问题

problem-statement 只是一个 prompt 模板吗？

不是。problem-statement skill 是一种可复用的框架方法，不只是填空式 prompt。它的价值在于：在你写 PRD 或提出修复方案之前，先把用户、阻碍和根因讲清楚。

什么时候不该用它？

如果你已经有一份范围明确的需求文档，或者你要记录的是实现细节，就不要用 problem-statement。它也不适合拿来头脑风暴方案；这个 skill 的重点是先定义问题，而不是先想解法。

problem-statement 适合新手吗？

适合，只要你能用朴素语言描述用户和痛点。这个模板本身不复杂，但质量高不高，取决于你能不能把用户的问题和你偏好的解决方案分开。

它如何适配 Technical Writing 工作？

对于 Technical Writing 来说，当你需要澄清受众痛点、支持文档需求，或者在写作前先界定内容缺口时，这个 skill 很有用。它能帮助你把文档始终放在结果导向上，而不是跑偏成功能叙述。

如何改进 problem-statement skill

给 skill 证据，不要给口号

最好的 problem-statement 输出来自具体观察：用户做了什么、卡在哪里、他们转而用了什么替代方案、哪些地方出了问题。说“用户很困惑”太弱；“第一次使用的管理员因为 UI 把必填的 API key 字段藏起来，导致无法完成设置”就具体得多。

把问题和解决方案分开

一个常见失败模式是偷偷塞进修复方案。如果草稿写的是“用户需要一个 dashboard”，就改写成“用户无法跨服务比较账户健康状况，因为状态信号分散在不同地方”。这样可以让 problem-statement 保持聚焦在真实障碍上。

加入会改变答案的约束条件

把任何会影响问题形态的信息都加进去：设备、团队规模、时间压力、合规要求、经验水平，或者平台限制。这些细节会让问题陈述更可信，也能帮助最终输出更好地支持优先级判断。

从草稿迭代到可决策版本

拿到第一版输出后，检查这段陈述是否具体到足以通过利益相关方评审。如果不够，就收紧 persona，把 Because 写得更有因果关系，并确保最后一句在没有额外解释的情况下也能直接读懂。