比如一个英国留学规划App
比如一个AI导航App
PRD的意义
PRD，Product Requirement Document的简写。
即产品需求文档，是产品经理和团队沟通的桥梁。
需要清晰地描述产品要做什么、为什么做、怎么做。
帮助团队成员理解目标和方向。
一个好的PRD，不仅能让设计、开发、测试等角色快速对齐，还能减少沟通成本，避免返工。
最近测试了几个顶级大模型。
发现已经能写出言之有物的PRD，最方便的是还能直接出交互原型。
即使不直接用，也能给产品经理一些启发。
因为实现成本非常低。
只需一段提示词，稍微等几分钟。
马上就能生成一个PRD初稿，配上交互原型。
非常的爽！
希望在这段提示词的帮助下
让更多产品经理能把精力放在用户需求和产品创新上，而不是重复性的文档工作。
关于 PRD 评审和内容结构
2018年加入字节教育时，都是刚成立的团队。
每个产品经理都有自己的写作风格。
后来研发同学受不了，觉得应该统一规范。
好友「硕爷」，把他之前在猿辅导的1-5-9稿经验搬了过来。
其实，每个公司都有自己的产品评审机制，大差不差。
展开讲讲1-5-9稿评审机制
1 稿
讲清楚需求背景和目标，为什么要做，为什么现在做，需要什么资源，未来如何迭代等。
PRD 飞书文档标题尾缀加上 1-1
产品组内部评审，通过后升5稿，尾缀改成 5-1，并在文档中记录评审通过时间等相关信息。
如通不过，可能产品价值不高或思路没讲清楚。
要么放弃，要么继续迭代文档。
每次迭代评审，尾缀都累加，比如 1-2、1-3，1-4，直至评审通过。
5稿
这时，已经决定要做了。
PRD需补充两图一表格。
• 原型交互示意图（用户要如何用） • 产品流程图（系统如何设计） • 关键页面原型和交互描述（一般用表格呈现）
这阶段，评审会有研发、设计、测试、业务等相关同学参会，评估实现可行性，给修改建议等。
记录反馈建议，修改完善后升5-2，邀项目参与成员（研发、设计、测试）再次评审，通过后启动技术预研、UI/UE设计、埋点设计等工作。
9稿
这阶段需提供：UI/UE设计稿 + 相关细节方案等。
细节包括不限于边缘Case，上线计划，AB测试方案、埋点等。
评审需要拉上所有相关方，包括不限于研发、设计、测试、业务等。
如评审通过，进入正常排期开发。
当然，这时也可能会有一些问题反馈，升级迭代为9-2开发也行。
这套协作流程确实更清晰，且从文档标题就能看出PRD所处阶段。
一开始只是字节教育线普及。
双减后，很多教育线产品经理内部转岗。
加上很多业务线的PRD评审机制也是拉胯。
慢慢这套PRD协作实践开始在整个公司内传播。
覆盖有多大不好说。
但外界误认为这是字节的PRD原则。
比如：
这套方法源头是猿辅导。
讲真，他们的产品设计真的很强。
PRD 结构
PRD 其实没什么标准结构。
讲清楚需求就好。
下面是自己以前写的一个PRD文档，脱敏示意图：
如何用 AI 写PRD
以前写的原型生成提示词：
https://xiangyangqiaomu.feishu.cn/wiki/TAjywfsLCioktYk5f5MctRLNngb?fromScene=spaceOverview
这套提示词更多强调痛点挖掘、需求分析，设计思路说明。
对写PRD来说，针对性不够。
花了几个小时。
把以前的PRD结构，加上原型生成提示词组在一起。
重写了一套提示词。
效果：几分钟就能写一个5稿水平的PRD。
Demo示意
需求描述：一个AI工具导航App
真·一句话需求。
但生成内容效果如下：
需求背景相关问题AI自动回答了。
比如解决什么问题、覆盖多少用户、上线计划、资源准备等
还附带两图一表（非页面交互说明表）：
1. 业务流程图 2. 功能流程图 3. 需求列表
关于需求细节，AI生成的还不够详细。
需描述所有核心页面的数据来源，交互细节等信息。
但是，相比两年前，已经有巨大进步。
真的已经有很高的学习参考价值。
几分钟就让一句话需求生成高保证原型Demo。
还要啥自行车啊！
关注“向阳乔木推荐看”公众号，转发这篇文章。
回复截图和“PRD”，获取完整提示词。
后记
AI 能力越来越强。
以前不能完成的工作，不意味着现在也不行。
重要前提：需我们主动探索挖掘。
如果你觉得这篇内容有帮助，欢迎点赞、转发，让更多人受益。
一起见证AI赋能产品创新的新时代！