产品需求分析蓝图(Product Blueprint)

把一个模糊的产品想法,变成一份经过验证、可指导开发的需求分析。它不是文档模板,而是一套固定的思考顺序——先想清楚要不要做,再想清楚做成什么样,最后才是怎么落地。

核心理念

• 蓝图是决策系统,不是一次性模板。 每一步的产出都是决策,不是填空。
• 头脑风暴阶段的方案,在工程现实面前默认是悬空的。 所以本流程强制事实核查。
• 用户不是想要功能,而是想要完成某件事。永远先挖"真实目标",再谈功能。

执行纪律(违反任何一条即流程失败)

1. 逐步走,不跳步。 但允许某步结论是"不适用",写明理由即可。
2. 事实必须核实。 竞品能力、平台限制、政策约束:有搜索/联网工具就当场查证并附来源;没有工具就明确标注"⚠️ 需人工核实",禁止凭印象陈述为事实。工作量、耗时、成本这类无从查证的数字,一律标注"⚠️ 估算,非核查结果",不得与已核查的结论并列呈现——它们看起来一样确定,而其中一半是猜的。
3. 矛盾需求显式化。 用户描述中前后矛盾或含糊的地方(如既要"即用即走"又要"历史可搜索"),一律列成"开放问题"请用户拍板,不得自行择一带过。
4. 分阶段对齐,不一次性输出全文。 每完成一个阶段(见下),停下来把结论和开放问题给用户确认,再进下一阶段。能否追问,不以工具形态或调用方式判断——只要用户还可能回复,就默认停下对齐。"这是非交互环境/单轮调用/我没法收到回复"不是走例外的理由:单轮命令行调用同样可以续轮,你停下来的那些问题用户下一条消息就能回答。唯一例外:用户明确要求一次性产出(如"直接给我完整文档""一次写完""不用问我")。走例外时必须把各阶段的开放问题集中列出,并在文档状态中标注"未逐阶段对齐"。
5. 拍板记录留痕。 用户做出的每个决定,写进文档并标注日期。
6. 语言跟随用户。 本 skill 正文为中文,但对话与产出文档一律使用用户所用的语言。

前置纪律(第〇步)

1. 先搜再造:先查市面上有没有。已有且够好 → 建议直接用,流程结束;已有但差口气 → 差异化拷问(第 4 步)必须给出过硬答案;确实没有 → 继续。
2. 从用户角度出发:起点是"我在什么场景下被卡住了",不是"我能做个什么功能"。

十四步蓝图

阶段 A:要不要做(完成后停下对齐)

1. 一句话定义 格式:帮助【谁】,在【什么场景】下,用【什么核心能力】,更快地完成【什么事】。写不出 = 还没想清楚,继续追问用户,不往下走。

2. 用户真正的问题 区分表面诉求与真实目标(例:表面是"想传文件",真实是"想让另一台设备立刻拥有这个内容")。不写功能。

3. 需求验证 谁会遇到 / 一天几次 / 现在怎么凑合 / 为什么不满意 / 需求强度打星(1–5)。低频 + 有凑合方案 = 明确警示用户"慎做"。

4. 竞品分析 + 差异化拷问 逐家列:解决了什么、没解决什么——必须搜索核实,不得凭训练记忆;建议用户对最接近的竞品做实测。然后回答死亡问题:"剩下的差距,值得新做一个吗?为什么不是给现有产品提 PR / 做插件 / 做配套工具?" "为了练手/掌控体验"是合法答案,但必须明确写下。

阶段 B:做成什么样(完成后停下对齐)

5. 产品定位 用"不是 A,而是 B"句式写 3–5 条。排除法比描述法更防跑偏。

6. 产品原则 5–8 条不可违背的原则(如:操作 ≤ 2 步、默认最安全、不增加学习成本),外加一个功能一票否决问题(如"它让 X 更快了吗?"),之后所有功能讨论用它裁决。

7. 用户旅程 自然语言写"用户的一天":从触发到完成的最短路径。先压缩流程,再从旅程反推功能——顺序不能反。

8. 核心功能分层 四层:MVP 必须有 / 下一版 / 想法池(先记不做)/ 坚决不做(单独成列)。所有"不错但现在不做"的点子进想法池,防 MVP 膨胀,也防好点子丢失。

9. 硬约束事实核查 列出所有"产品体验赖以成立的技术/平台/政策假设"(平台后台限制、系统权限、API 配额、商店审核政策、协议可行性),逐条核实并附来源。任何一条被推翻,回到第 5 步重定形态。 同时在此复查矛盾需求清单是否已全部拍板。

阶段 C:怎么落地

10. 安全模型 怎么认证、怎么加密、怎么解绑/删数据、最恶劣环境下是否安全。默认值必须是最安全的那档。

11. 异常场景 断网/弱网、超大输入、目标不可达、并发冲突、脏数据……每条给"兜底行为",不给"不会发生"。

12. MVP 范围与 Roadmap 每一版都能独立发布、独立被真实使用、独立验证价值。不能发布的版本切分是错的。

13. 成功标准 先于开发定义,全部可测数值化(首次使用成功率、完成耗时、次周留存、对旧方案的替代率)。没有数值的指标不算指标。

14. 风险清单 技术 / 市场 / 运营(个人项目要包含"烂尾风险"),每条配应对策略,标高中低。

收尾:一句产品使命 + 一个最便宜的验证动作

产品使命:一句话,成为之后所有决策的最终裁判(例:"让跨设备传递内容像复制粘贴一样自然")。之后有人提新功能 → 问它是否服务这句话 → 不服务就进想法池。

下一步动作:不以"接着讨论"收尾,而是给出一个半小时到一周内用户能自己做完、且可能推翻本文档结论的动作(例:先把最接近的竞品真用一周;把要处理的真实数据导出来打开看一眼;拿三个最坏的输入手动跑一遍)。写明它验证哪条假设、被推翻会怎样。给不出这样一个动作,说明这份分析还停在纸面上。

产出约定

• 问用户想把文档放哪;无明确偏好则在当前目录建 <想法短名>/PRD.md(全部十四步 + 拍板记录 + 开放问题),调研证据多时另建 research.md 存放来源与核查记录。
• 文档头部标注:版本、日期、状态(草稿/评审中/已拍板)。
• 开放问题单独成节,每条标注"待拍板"或"已拍板 + 日期 + 结论"。

复盘回写(让蓝图产生复利)

产品(或功能)做完后,主动提醒用户复盘:哪些判断对了、哪些错了、当初想多/想少了什么。把结论追加到本 skill 所在目录的 retrospective.md(即 SKILL.md 的同级目录,视客户端而定,如 ~/.claude/skills/product-blueprint/、~/.agents/skills/product-blueprint/;没有该文件就创建;无法定位 skill 目录时,改放到产出文档同目录并告知用户)。如果教训是流程性的(某步该加检查、某步顺序不对),直接修改本 SKILL.md 对应步骤——蓝图因此越用越准,这比任何现成模板都值钱。