如何让 AI 稳定生成 PRD：从提示词到 Rule、Skill 和模板
完成三层需求分析后，我让学员用 AI 生成 PRD。同样一份需求，有人几分钟拿到结构清楚的 Markdown，有人等了很久却得到格式混乱、内容泛化的文档。
差别往往不在模型，而在输入是否经过确认，以及有没有把稳定要求从临时提示词中抽出来。
PRD 之前先有真实需求
AI 可以把材料整理成一份看起来专业的 PRD，但“看起来完整”不等于需求正确。
开始生成前，至少要准备：
- 已确认的业务目标和 MVP 范围。
- 业务流程、页面流程和功能流程。
- 关键角色及其权限边界。
- 正常、异常和不做的场景。
- 可参考的现有系统、原型或标准文档。
如果这些信息缺失，AI 只能依据通用产品经验补齐。它补出的会员、推荐、优惠券可能很合理，却不一定属于这个项目。
提示词解决一次任务
对于偶发任务，一份明确提示词已经足够：提供需求材料，要求输出业务流程、页面说明、功能规则、验收条件和功能清单，并明确使用 Markdown。
还可以附上一份你认可的 PRD 作为少样本示例。相比抽象地说“写得专业”，模板会直接告诉模型标题层级、表格结构和细节深度。
提示词适合当前任务的具体背景，不应该承担所有长期规范。
Rule 解决长期约束
Rule 用于项目或个人长期遵守的要求，例如：
- 文档默认使用 Markdown，除非明确要求其他格式。
- 所有功能必须包含异常场景和范围外说明。
- 术语统一使用“用户”“订单”“核销”，不得自行替换。
- 接口示例遵守项目既有命名规范。
- 不虚构调研数据和业务指标。
把这些要求写进规则后，不必每次重复，也能减少不同会话之间的风格漂移。
规则越多不一定越好。过时、冲突或与任务无关的规则会污染上下文，因此需要定期清理。
Skill 解决重复流程
当“生成 PRD”成为高频任务，而且输入、步骤和验收都比较固定，就可以封装为 Skill。
一个合格的 PRD Skill 不只是藏了一段长提示词，而应该明确：
- 在什么请求下触发。
- 必须读取哪些需求材料和参考模板。
- 先检查哪些信息是否缺失。
- 按什么顺序生成业务、页面和功能内容。
- 输出文件放在哪里，使用什么格式。
- 完成后如何检查范围、追踪关系和术语一致性。
Skill 的价值是把个人经验变成可共享 SOP，让其他同学导入后也能从相近起点工作。
模板解决“长什么样”
模板负责稳定结构，但不要让模板反过来绑架需求。
我建议 PRD 至少包含：
- 背景、目标和范围。
- 用户角色与业务流程。
- 页面流程与页面说明。
- 功能清单与优先级。
- 每个功能的规则、异常和验收条件。
- 非功能要求、依赖和风险。
- 明确不包含的内容。
不同项目可以删减，不要为了填满模板编造信息。
一条稳定生成链路
训练营里更可靠的流程是：
- 学员先完成三层需求分析。
- 用模板和明确提示词生成 PRD 初稿。
- 逐项核对业务流程、页面和功能能否互相追踪。
- 删除 AI 自行扩展的范围外内容。
- 补上真实异常、依赖和验收标准。
- 把反复出现的规范沉淀为 Rule。
- 当流程稳定后，再封装为 Skill 分享。
这套顺序很重要。流程还没有跑通时就封装 Skill，只会把错误更稳定地复制给更多人。
质量检查清单
- PRD 中的每个功能都能追溯到用户目标。
- 主流程和异常流程都存在。
- MVP 与暂不包含范围明确。
- 页面、接口、数据术语一致。
- 没有未经证实的业务数据。
- 文档能被产品、开发和测试共同使用。
- AI 生成内容经过负责人确认，而不是直接进入开发。
讲师判断：稳定来自输入、结构与校验共同固定
模板只能固定版式，Rule 只能固定长期约束，Skill 只能固定执行流程；它们都不能替代真实需求。如果输入里缺少业务决策，再精致的自动化也只会稳定地产生空话。因此每次生成 PRD 前，我会先让学生标记已确认、待确认和假设三类信息，禁止 AI 把假设写成事实。
生成后还需要反向校验：随机选择一个用户目标，检查它是否落到页面、功能和验收；随机选择一个功能，检查它是否超出 MVP。把这两次抽查做成固定动作，才算真正建立了可复用的 PRD 生产流程。
课后练习
用同一份需求分别通过普通提示词、参考模板和 PRD Skill 生成三版文档。不要只比较排版，重点统计遗漏、越界、术语不一致和人工修改次数，再决定哪种方式真正更稳定。