产品需求文档（PRD）是产品经理日常工作中产出频率最高的交付物之一，但也是最容易消耗时间的环节。一份合格的PRD需要包含需求背景、用户画像、功能清单、交互流程、异常处理、数据埋点等大量细节，手工撰写往往需要两三天。而借助大模型配合精心设计的提示词，这个周期可以压缩到几个小时。关键不在于模型本身的能力，而在于你如何向它描述任务。本文将围绕如何构建高质量的PRD提示词展开，给出一套可直接落地的框架和多个实战示例。
一、为什么随手一句提示词写不出可用的PRD
很多人第一次尝试让大模型写PRD时，输入往往类似“帮我写一个电商App的PRD”。得到的结果通常是一份看起来结构完整、内容却空洞无物的文档：功能描述停留在“支持用户注册登录”这种颗粒度，没有业务规则，没有异常分支，更没有验收标准。造成这种结果的原因是大模型在没有约束的情况下，倾向于输出概率上最通用的内容。
PRD本质上是一份高度依赖业务上下文的文档。同一个“购物车功能”，在自营电商、跨境电商和社区团购产品中的规则差异巨大。如果提示词中不提供这些上下文，模型只能用最泛化的方式填补空白。此外，PRD对结构化程度要求很高，研发人员阅读时需要快速定位到具体字段的定义和边界条件，这就要求提示词必须明确指定输出结构，而不是任由模型自由发挥。
还有一点容易被忽略：PRD的撰写是分阶段的。需求澄清阶段、方案细化阶段、评审前自查阶段，每个阶段需要的文档颗粒度完全不同。一条提示词试图一次性解决所有阶段的需求，效果自然不理想。正确的做法是根据阶段拆分提示词，逐层递进。
二、一套可直接复用的PRD提示词框架
经过大量实践验证，一条高质量的PRD提示词通常包含六个要素：角色设定、产品背景、目标用户、需求范围、输出结构和约束条件。下面是一个通用的框架模板，可以直接复制后替换其中的占位内容。
# 角色设定
你是一位有10年经验的资深产品经理，擅长撰写结构严谨、
细节完整的PRD，服务过多家互联网公司。
# 产品背景
产品名称：{填写产品名}
产品定位：{一句话描述产品解决什么问题}
当前阶段：{从0到1 / 迭代优化 / 功能扩展}
本次需求目标：{希望达成的业务指标或用户价值}
# 目标用户
用户群体：{描述目标用户的特征}
核心痛点：{用户当前遇到的具体问题}
使用场景：{列举2-3个典型使用场景}
# 需求范围
本次包含的功能：{功能点1、功能点2...}
本次不包含的功能：{明确排除项，避免范围蔓延}
# 输出结构要求
1. 需求背景与目标
2. 用户故事（As a... I want... So that...格式）
3. 功能需求详述（每个功能包含：功能描述、
前置条件、业务规则、交互流程、异常处理、边界条件）
4. 非功能需求（性能、安全、兼容性）
5. 数据埋点需求
6. 验收标准（Given-When-Then格式）
7. 待确认问题清单
# 约束条件
- 功能描述必须细化到字段级别
- 每个交互流程需说明正常流程和异常流程
- 使用表格描述字段定义
- 语言风格：正式、无歧义，避免使用模糊词汇
这个框架的核心价值在于“输出结构”和“约束条件”两部分。输出结构相当于给模型下达了目录级指令，让它知道每一节该写什么；约束条件则控制颗粒度，要求细化到字段级别、要求区分正常和异常流程，这些是普通提示词最容易缺失的信息。实践中，仅加入“每个功能需说明异常处理和边界条件”这一条，生成内容的可用率就有明显提升。
需要注意的是，框架中的“待确认问题清单”是个小技巧。让模型主动列出它认为信息不足或存在歧义的地方，相当于让它做一次自我检查。你可以在下一轮对话中逐一补充这些信息，文档质量会随着多轮迭代持续提升。
三、不同产品类型的提示词实战示例
1. 工具类产品：强调交互细节和状态定义
工具类产品的PRD重点在于交互状态的定义，比如一个文件上传功能，需要说清楚上传中、上传失败、文件过大、格式不支持等各种状态下的界面表现。针对这类产品，提示词可以在输出结构中强化状态机描述。
请为「在线文档协作工具」的「评论功能」撰写PRD。 输出时为每个子功能补充完整的状态定义表， 包含：状态名称、触发条件、界面表现、用户可执行操作。 例如评论功能需覆盖：编辑中、已发布、被回复、 被编辑、被删除、被折叠等状态。
2. 电商类产品：强调业务规则和数据口径
电商产品的PRD离不开复杂的业务规则，例如优惠券的叠加逻辑、库存的锁定与释放、价格的计算顺序等。提示词中应明确要求模型把规则写成可执行的判定条件，并列出所有涉及的金额计算口径。
请为「优惠券功能」撰写PRD，重点要求： 1. 用判定表形式描述优惠券叠加规则， 覆盖满减券、折扣券、运费券三种类型的互斥关系 2. 列出金额计算的优先级顺序： 优惠摊平、运费计算、积分抵扣的先后关系 3. 描述库存超卖场景下优惠券的回退逻辑 4. 每条规则必须给出正反两个示例
3. B端SaaS产品：强调权限体系和角色矩阵
SaaS产品的PRD中权限设计是重头戏。让模型用角色权限矩阵的方式输出，可以避免大量遗漏。同时B端产品往往涉及多种组织架构形态，提示词中要主动说明这些差异。
请为「企业审批流功能」撰写PRD，补充要求： 1. 输出角色权限矩阵表，行为角色、列为操作， 单元格标注允许/禁止/本人数据/本部门数据 2. 说明单级组织与多级组织架构下的审批链差异 3. 描述审批人离职、部门撤销等组织变动场景的处理规则
四、提升生成质量的进阶技巧
第一是分阶段多轮对话。不要指望一次生成完整PRD，建议按“整体框架、功能详述、异常流程补全、验收标准”四轮推进。每轮聚焦一个层次，前一轮的输出作为后一轮的上下文。这样做的好处是每轮模型的注意力都集中在单一任务上，细节密度远高于一次性生成。
第二是提供反面示例。在提示词中加入一段你认为不合格的描述，并说明原因，例如“不要写成‘系统应支持良好的用户体验’这种无法验证的描述，所有需求必须可测试”。模型对负面约束的响应往往比对正面要求的响应更准确。
第三是引入评审角色。文档生成后，开启新的对话，设定模型为“挑剔的技术负责人”，让它对这份PRD提问题。这个环节能暴露出大量你自己视角下忽略的漏洞，比如并发场景、数据迁移、灰度方案等。两轮角色扮演下来，文档的完整度接近真实评审后的水平。
最后要提醒的是，大模型生成的PRD仍然需要人工把关，尤其是涉及合规、计费、数据安全的部分，模型给出的规则可能存在业务上的偏差。把模型当作一个不知疲倦的初稿撰写者和查漏助手，而不是最终决策者，才是正确的协作方式。掌握这套提示词方法后，你会发现PRD撰写中最耗时的骨架搭建和细节填充工作可以大幅外包，自己则专注于业务判断和方案取舍。