Problem Statement - 从用户视角撰写问题陈述的技能

技能概述

problem-statement 是一个产品发现类技能，用"我是谁 / 想做什么 / 但被什么阻碍 / 根因是什么 / 感受如何"的同理心框架，帮你在动手做方案之前，从用户视角写出一份能对齐团队的问题陈述。

适用场景

1. 团队总是直接跳到解决方案：开会人人都在提方案，却从没人写下真正要解决的问题——用它先把问题框定清楚，再讨论怎么做。
2. 为 PRD 写一份高管愿意读的问题定义：需要一段简洁、可衡量、有同理心的问题陈述，让 skeptical 的干系人快速对齐"为什么值得做"。
3. 手里只有一堆功能请求，看不清背后的真实问题：用户说"要个仪表盘"，但没人说得清他们想达成什么——用它把功能请求还原成用户视角的问题。

核心功能

1. 问题框架叙事（Problem Framing Narrative）：按五段式结构展开——"I am（用户画像）/ Trying to（期望结果）/ But（现实阻碍）/ Because（根因）/ Which makes me feel（真实感受）"，每一段都配有质量自检（画像能否想象出具体的人？"Trying to"是结果还是任务？"Because"是根因还是症状？）。
2. 上下文与约束文档化：把地理、技术、时间、人群等真实约束单独列清，让问题陈述贴近现实限制，而不是理想化描述。
3. 一句话问题陈述提炼 + 反模式防护：用"[谁]需要一种方式[达成什么]，因为[根因]，目前[造成什么影响]"的公式收敛成一句话，并内置五类反模式检查——解决方案走私、把公司指标当用户问题、人群太泛、把症状当根因、编造用户情绪。

常见问题

问题陈述和 PRD、用户故事有什么区别？

问题陈述定义"要解决什么问题"，PRD 定义"怎么解决"，用户故事是把解决方案拆成可执行的条目。这个技能用在 PRD 之前：先确认问题值得解决，再进入方案。它不能替代用户调研，也不能当作 PRD 使用。

没做过用户研究，可以直接用吗？

不建议。技能明确要求"缺上下文就先去做访谈，不要凭空编造问题"。尤其是"感受"部分，应该来自真实用户语录（如"frustrated""stuck"），而不是营销式的"empowered and delighted"。

什么是"解决方案走私"（Solution Smuggling）？

指"问题是我们缺少某个功能"这类表述——把预设的方案包装成了问题。这个技能通过"Trying to"强制聚焦用户期望的结果（他们到底想达成什么），来规避这种偷换，确保先验证问题、再谈方案。