20个产品经理提示词， 把取舍摊开讲清楚
AI 几秒钟就能写出一份语气笃定的 PRD，靠的是编造用户、数据和范围。这些提示词让它只依据你的简报、笔记和数字来写，列出计算过程，并在工程开工前把未决问题全部摆出来。
把[方括号]里的内容换成你的简报、笔记、工单或数字。
01. 把杂乱的简报写成 PRD，并列出未决问题
你手里只有一串 Slack 讨论、一份通话记录和一个截止日期，没有任何规格文档。
把这份杂乱的简报整理成一份产品需求文档。 [粘贴简报、讨论串、通话记录或你手头的任何材料] 章节按以下顺序：问题以及谁遇到了这个问题、我们已有的证据、带可衡量结果的目标、范围内的内容、范围外的内容、用编号步骤写的用户流程、标注 MUST 或 SHOULD 的需求、对其他团队的依赖。 只使用简报里写到的内容。简报没有提到的地方，请写 [OPEN: 问题]，不要自行补全。 最后列出所有未决问题，按谁能回答来分组（我、设计、工程、法务、客户），并把阻碍开发的三个问题放在最前面。
02. 把一个功能拆成带验收标准的用户故事
明天就要做需求梳理，而这个功能还是一张大工单。
把这个功能拆成团队可以逐个开发、逐个上线的用户故事。 功能：[它做什么] 用户：[谁会用它，他们想完成什么] 约束：[平台、截止日期、已经做好的部分] 每个故事包含： 1. 作为[用户]，我想要[行动]，以便[结果]。 2. 用 Given / When / Then 格式写验收标准，每个故事三到六条，每一条都要让没参与编写的人也能测试。 3. 估算大小，用 S、M 或 L，并写出造成不确定的那一件事。 排列故事的顺序，要让第一个故事上线后真实用户就能用上，哪怕它很小。标出实际上是两个故事的那些，以及必须等另一个故事上线后才有意义的那些。
03. 找出你的 PRD 漏掉的边界情况
规格看起来已经写完，工程下周就要开工。
请以上线后要接手 bug 反馈的工程师的视角来阅读这份 PRD。 [粘贴 PRD 或规格文档] 列出它没有覆盖的边界情况，按以下类别分组：空状态和首次使用状态、错误和超时、权限和角色、极限值（超长、超多、零、重复）、并发（两个人同时编辑、连点、重试）、该功能上线之前的旧数据，以及无障碍。 每一条写明：一行场景描述、按现有规格推断会发生什么，以及我需要回答的问题。再按真实用户在第一个月内遇到的可能性，排出前五名。不要自行编造需求，请提问。
免费解锁其余 17 条提示词
订阅 Whizi 邮件通讯，即可阅读这套合集的全部内容。
- 用 RICE 给待办列表打分并展示计算过程
- 把访谈笔记整理成任务、痛点和原话
- 写一份只问“做过什么”而不问“想要什么”的探索访谈提纲
- 把客服工单归并成值得解决的产品问题
- 写一份工程师能直接据此开发的一页纸规格
- 选一个成功指标，再选一个让它保持诚实的反向指标
- 设计一个实验，并先回答样本量的问题
- 做一份发布清单，每个团队都有负责人
- 写出用户真的会读的发布说明
- 写一份先说“有什么变化”的干系人更新
- 写一份连“不做什么”都讲清楚的路线图说明
- 拒绝一个功能需求，并给出理由和下一步
- 在发布前做一次事前复盘
- 逐条拆解竞品页面上的说法
- 从一长串工单里提炼出一个迭代目标
- 把别人提出的解决方案还原成背后的问题
- 让第二个模型审查第一个模型写的 PRD