用 AI 生成产品需求文档：从零到可评审 PRD

这篇教程带你走完一条可复用的流程：把一句模糊的产品想法，变成一份结构完整、带验收标准的 PRD（产品需求文档）初稿，再把它拆成能直接进看板的需求条目。全程会用到对话式大模型或大模型 API，具体可用模型与接口字段以你所选服务商的官方文档当前版本为准。

读完之后，你手上会有四样东西：

• 一份能直接拿去评审的 PRD 草稿，包含背景、范围、用户故事、优先级、异常场景和验收标准；
• 一套可复用的提示词模板，存在文件里，能像代码一样做版本对比；
• 一个把 prd.md 转成 prd.yaml 的脚本，方便导入项目管理工具；
• 一份人工评审清单，用来挡住 AI 常见的"看起来很全、其实没落地"的输出。

举个贯穿全文的例子：要给一个社区团购小程序加"拼团即将结束提醒"。这个想法一句话说完，但真写 PRD 时会冒出一堆问题——提醒谁？提前多久？用户关掉通知怎么办？拼团失败要不要提醒？下面逐步处理。

前置条件清单

• 一个支持长文本输出的对话式大模型工具，或一个大模型 API Key。模型选择与额度规则以官方页面为准。
• 一份 PRD 模板。可以自己写，也可以从团队现有文档里抽一个。
• 原始素材。哪怕很少也要有：一句需求描述、目标用户、业务目标、已知约束（例如"本期只做站内消息，不接短信"）。
• 一个 Markdown 编辑器，或任意支持 Markdown 的 IDE。
• 走脚本路线时：Python 3 运行环境、requests 库、把 Key 放在环境变量里。
• 合规意识：不要把未脱敏的用户手机号、订单明细、访谈原文直接贴给外部服务。

建议先建一个工作目录，素材和产出分开放：

```bash

mkdir -p prd-demo/{raw,prompts,docs}

touch prd-demo/raw/01-idea.md

touch prd-demo/raw/02-constraints.md

touch prd-demo/prompts/prd_v1.md

```

第 1 步：把"想法"整理成素材包

AI 输出的质量很大程度取决于你喂进去的上下文。先把零散信息写成几段大白话，不用讲究格式。

raw/01-idea.md 示例：

```markdown

需求：社区团购小程序里，拼团快结束时给用户发提醒，提高成团率。

目标用户：

• 已参团但还没付款的用户
• 已付款、等别人参团的团长

业务目标：本期目标是把"快到点却差 1-2 人"的团，成团率提上去。

已知约束：

• 本期只做小程序内的订阅消息，不做短信和电话
• 提醒内容要能被运营配置，但不能改代码
• 时间提醒依赖后端定时任务，目前任务每 5 分钟跑一次

```

注意最后一条：定时任务 5 分钟跑一次，意味着"提前 10 分钟提醒"实际可能是提前 5-12 分钟。这类约束如果不写进素材，AI 会编出一个精确到秒的方案，评审时才发现做不到。

第 2 步：先定骨架，别让 AI 自由发挥

直接说"帮我写个 PRD"，出来的东西通常章节飘忽、每次结构都不一样。先给模板。

prompts/prd_v1.md 里的模板部分：

```markdown

PRD：<功能名>

1. 背景与目标

• 现状问题：
• 本期目标（可量化）：
• 非目标（明确不做）：

2. 用户与场景

3. 用户故事

• 作为 <角色>，我希望 <行为>，以便 <价值>

4. 功能需求

5. 状态与流程

• 主流程：
• 状态机：

6. 异常与边界

7. 非功能需求

• 性能 / 安全 / 合规 / 可观测性

8. 数据与埋点

9. 验收标准

• 每条功能需求至少 1 条 Given-When-Then

10. 风险与未决问题

```

模板里"非目标"和"异常与边界"两节要保留。这两节是 AI 最容易糊弄过去、而评审时最容易被追问的地方。

第 3 步：写第一轮提示词

把角色、上下文、约束、输出格式一次说清。提示词可以直接写在对话窗口里，也可以存成文件。

```text

你是一位有 5 年经验的 B 端与 C 端产品经理。请根据我提供的素材，按给定模板输出一份 PRD 初稿。

规则：

1. 严格使用模板的章节顺序和标题，不要增删一级章节。

2. 素材里没有的信息，不要编造。写「未确认」并在第 10 节列出待确认问题。

3. 每条功能需求要有唯一编号，格式 FR-01。

4. 优先级只允许 P0/P1/P2，且 P0 不超过 4 条，每条要写一句"为什么是 P0"。

5. 第 6 节"异常与边界"至少写 5 条，包括超时、重复触发、权限不足、数据为空、并发冲突。

6. 数字（时长、次数、并发）如果素材没给，用占位符 <待定>，不要自己填。

7. 输出 Markdown，不要用代码块包裹整篇文档。

【模板】

（把第 2 步的模板粘在这里）

【素材】

（把 raw/01-idea.md 和 raw/02-constraints.md 的内容粘在这里）

```

第 6 条和第 2 条是重点。AI 默认喜欢把细节补全，写出一堆看似专业但没人确认过的数字，评审时反而增加沟通成本。

第 4 步：让 AI 先反问，再动笔

一次性生成之前，先加一轮澄清。这轮通常能问出你自己都没想到的边界。

```text

先不要写 PRD。请阅读上面的素材，列出不超过 10 个你认为必须先确认的问题，

按"影响范围从大到小"排序，每个问题后面写一句：如果答案是 A 或 B，PRD 会有什么不同。

```

针对拼团提醒，这轮可能返回：提醒触发时机以哪个时间为准、用户关闭订阅消息授权后是否降级、一个用户同时参多个团怎么处理、团长自己是否收到提醒、提醒频次上限是多少。回答完这些，再进入生成，返工次数会明显减少。

第 5 步：分节生成，避免"长文失忆"

一次性输出上万字，模型容易前后不一致，比如第 4 节写了三种提醒渠道，第 7 节又说只做站内消息。做法是按章节分批生成，每批结束把已确认内容回灌。

```text

请只输出第 1、2、3 节。输出后停下来，等我确认。

```

确认后再继续：

```text

以下是已确认的第 1-3 节内容（原文粘贴）。请保持术语与其中的结论一致，

继续输出第 4、5 节。如果与前文冲突，先指出冲突再写。

```

把"已确认内容"每次带上，相当于给模型一个滚动的记忆锚点。

第 6 步：用验收标准把需求钉死

功能描述容易含糊，验收标准难含糊。要求每条需求配 Given-When-Then：

```gherkin

场景：拼团剩余 10 分钟且还差 1 人，提醒已授权用户

Given 用户已参团且已完成支付

And 该团剩余时间小于等于 10 分钟且人数未满

And 用户已授权订阅消息

When 定时任务扫描到该团

Then 系统向该用户发送一条提醒，内容包含团名、还差人数、剩余时间

And 同一用户在同一团内的提醒次数不超过 <待定> 次

场景：用户未授权订阅消息

Given 用户未授权订阅消息

When 定时任务扫描到该团

Then 不发送消息，仅在团详情页展示倒计时提示

And 记录一次"因未授权未触达"埋点

```

写到这一步，很多含糊的地方会自己暴露出来。比如"不超过几次"这种参数，就自然落到第 10 节的未决问题里，由运营定，而不是由 AI 猜。

第 7 步：转成结构化需求，接入后续工具

评审通过后，把 PRD 拆成机器可读格式。先在 prompts/schema.md 里约定字段：

```markdown

每个需求条目包含：

• id：字符串，格式 FR-01
• title：一句话标题
• priority：P0 / P1 / P2
• user_story：作为……我希望……以便……
• acceptance_criteria：字符串数组，每条一个 Given-When-Then
• dependencies：字符串数组
• open_questions：字符串数组

```

再用脚本调用接口。模型名、接口路径、返回字段结构都以服务商官方文档当前版本为准，不要照抄下面示例里的占位内容。

```python

import os

from pathlib import Path

import requests

环境变量里读取，不要写死在代码里

API_KEY = os.environ["LLM_API_KEY"]

BASE_URL = os.environ["LLM_BASE_URL"] # 例如 https://<服务商域名>

MODEL = os.environ["LLM_MODEL"] # 具体模型名以官方文档为准

prd_text = Path("docs/prd.md").read_text(encoding="utf-8")

schema_text = Path("prompts/schema.md").read_text(encoding="utf-8")

prompt = f"""你是资深产品经理。请把下面的 PRD 拆成结构化需求。

规则：

1. 只输出 YAML，不要任何解释文字，不要用代码块包裹。

2. 顶层是 requirements 数组，元素字段严格按 Schema 说明。

3. 不允许新增 PRD 中不存在的内容；信息缺失写 null，并在 open_questions 里说明缺什么。

4. priority 必须与 PRD 表格中的一致，不要自行调整。

【Schema 说明】

{schema_text}

【PRD】

{prd_text}

"""

resp = requests.post(

f"{BASE_URL}/v1/chat/completions",

headers={

"Authorization": f"Bearer {API_KEY}",

"Content-Type": "application/json",

},

json={

"model": MODEL,

"messages": [{"role": "user", "content": prompt}],

"temperature": 0.2,

},

timeout=180,

)

resp.raise_for_status()

返回体字段路径随服务商不同而不同，请对照官方文档调整

content = resp.json()["choices"][0]["message"]["content"]

Path("docs/prd.yaml").write_text(content, encoding="utf-8")

print("已写入 docs/prd.yaml")

```

运行前设置环境变量：

```bash

export LLM_API_KEY="你的密钥"

export LLM_BASE_URL="https://<服务商域名>"

export LLM_MODEL="<按官方文档选择的模型>"

python split_prd.py

```

生成的 YAML 大致长这样：

```yaml

requirements:

• id: FR-01

title: 拼团剩余时间提醒

priority: P0

user_story: 作为已参团用户，我希望在团即将结束时收到提醒，以便及时邀请好友补位

acceptance_criteria:

• "Given 用户已参团且已支付 And 剩余时间<=10分钟 And 人数未满 When 定时任务扫描 Then 发送订阅消息"

dependencies:

• 订阅消息模板需在平台后台申请

open_questions:

• 单团单人提醒次数上限 <待定>

```

拿到 YAML 后，可以用脚本批量创建工单，或作为接口测试用例的输入。这一步建议加一个人工抽查：随机挑 3 条，回 PRD 里核对优先级和验收标准是否被改写。

第 8 步：评审与迭代

AI 出稿之后，按这份清单过一遍，能挡掉大部分问题。

迭代时把提示词文件也一起改，prd_v1.md、prd_v2.md 存下来，出问题时能回滚到上一版措辞。

常见坑与排错

输出很全但落不了地。 表现是每个章节都有内容，但读完不知道先做什么。处理办法是在提示词里限制 P0 数量，并要求每条 P0 写一句理由。

编造用户访谈和数据。 模型会写出"调研显示 68% 用户希望……"这类句子。处理办法是明确要求"素材中没有的信息写未确认"，并在评审清单里逐条核对数字来源。

术语漂移。 同一份文档里"团"和"拼团单"混用。处理办法是在提示词里附一张术语表，并要求"全文只用术语表中的词"。

长文前后矛盾。 一次生成太多章节时常见。处理办法是分节输出，每轮带上已确认内容。

接口调用失败。 常见原因有三类：密钥或额度问题、请求体字段与服务商不一致、返回体字段路径不同。先打印原始响应体再改代码，字段名对照官方文档，不要凭记忆写。

超时或输出被截断。 长 PRD 容易触发输出长度上限。处理办法是把任务拆成"每节一次请求"，或先让模型输出章节大纲，再逐节补全。

把初稿当定稿。 大模型不会替你承担需求决策。角色、优先级、范围取舍这些事，需要产品负责人拍板，AI 只负责把空白填成待确认项。

敏感信息外泄。 把用户手机号、真实订单号贴进外部服务存在合规风险。处理办法是脱敏后再喂，或改用本地部署的模型，具体能力与部署方式以官方文档为准。

下一步建议

把这套流程固化成三件小事，长期收益比较明显：

1. 建提示词库。按文档类型分目录，比如需求、竞品分析、评审纪要各一套，每套带版本号，改动用 diff 评审。

2. 让 PRD 和工单双向可追溯。YAML 里保留需求编号，工单标题带上同一编号，需求变更时能反查影响范围。

3. 加一轮"AI 挑刺"。初稿定稿前，用反向提示词让模型扮演测试和运营，各自列出 5 个"这份 PRD 上线后会出问题的地方"，再决定要不要补章节。

如果想再往前走一步，可以尝试把 PRD 模板和团队的接口文档、埋点规范一起作为上下文喂进去，让输出直接带上规范的字段名。第一步不用追求全自动，先把"素材整理—骨架—澄清—分节生成—结构化"这条链路跑通一次，比纠结用哪个模型更划算。