面向程序员 · AI 产品需求实战课

AI 生成 PRD 实战

AI 生成 PRD 不是让模型直接写一篇漂亮文档，而是把“模糊需求”变成“有证据、有边界、贴合系统现状、能被研发评审”的产品方案。真正有价值的 PRD 生成流程，必须先问清楚、查清楚、对齐清楚，再动笔。

先澄清，不急着写 把口头需求拆成目标、用户、场景、约束和待确认问题。

先查证，不凭空编 从知识库、历史 PRD、接口文档、埋点和客服反馈里找依据。

先贴系统，再谈方案 理解现有模块、字段、权限、流程和技术限制，减少空中楼阁。

输出能评审 PRD 要包含范围、流程、规则、验收标准、风险和未决问题。

ai-prd-workflow intake / evidence / prd

模糊需求 “商品导入失败后，希望运营能看清楚失败原因，最好能下载。”

→

需求澄清 谁用、在哪看、失败原因从哪来、下载字段是什么、权限怎么控。

资料证据 历史导入 PRD、导入接口、错误码表、工单反馈、现有页面。

→

可评审 PRD 目标、范围、流程、字段、规则、验收、风险、引用来源。

Clarify
澄清问题

Evidence
资料引用

Scope
范围边界

Review
评审记录

01 · 先给定义

AI 生成 PRD，本质是需求工程工作流

好的 AI PRD 不是“文笔好”，而是能把业务问题、系统现状、决策依据和落地方案放在同一张桌子上讨论。

低质量做法

直接让 AI 写一份 PRD

输入一句话，输出一堆通用章节。看起来完整，但没有系统现状、没有来源、没有边界、没有待确认问题，研发评审时很快会被问住。

高质量做法

让 AI 按流程生成 PRD

先收集需求，再生成澄清问题；再查资料和知识库；再对齐现有系统；最后写 PRD 草稿，并附上假设、引用、风险和验收标准。

一句话面试版 可直接背

AI 生成 PRD 的关键不是让模型替产品经理写文档，而是把需求澄清、资料检索、系统现状分析、方案生成和评审迭代串成可追溯的工作流。模型负责提炼、补全和结构化，人负责确认目标、边界和最终决策。

02 · 需求录入

第一步不是写 PRD，而是把“口头需求”变成结构化输入

很多 PRD 写不好，不是因为不会写，而是因为输入太散。AI 要先把需求压成固定字段，后面才能稳定处理。

录入时要抓住 6 个点 Intake

1业务目标：这件事想改善什么指标，还是解决什么投诉。
2目标用户：运营、客服、商家、审核员、管理员分别要不要用。
3使用场景：用户在什么页面、什么时刻、因为什么问题进入功能。
4已知约束：上线时间、权限范围、现有模块、导入文件格式、数据权限。
5成功标准：怎样才算功能有效，不只写“提升效率”。
6不确定项：哪些信息还没确认，必须标成 open questions。

需求录入结构 intake.json

{
  "rawRequirement": "商品导入失败后，希望运营能看到失败原因，并支持下载失败明细。",
  "requester": "商品运营团队",
  "targetUsers": ["运营专员", "运营主管"],
  "businessGoal": "降低导入失败排查时间，减少客服和研发协助定位",
  "knownSystems": ["商品管理后台", "商品批量导入服务", "导入任务记录页"],
  "constraints": [
    "首版不改造导入解析引擎",
    "需要复用现有任务记录权限",
    "失败明细最多保留 30 天"
  ],
  "unknowns": [
    "失败原因字段是否已有标准错误码",
    "下载文件是否需要脱敏",
    "是否需要支持重新导入失败行"
  ]
}

03 · 澄清问题

AI 最有用的第一件事：帮你问出该问的问题

澄清问题不是拖慢进度。它能提前暴露范围、权限、字段、异常和验收口径，避免 PRD 写完才发现方向不对。

业务问题

为什么要做

导入失败现在造成什么成本？是运营排查慢、商家投诉多，还是研发经常被拉去查日志？

用户问题

谁来使用

只有内部运营看，还是商家也要看？不同角色能看到的失败原因和下载内容是否一样？

系统问题

数据从哪里来

导入服务现在是否保存行级失败原因？错误码是否标准化？失败文件有没有对象存储地址？

让 AI 生成澄清问题的提示词 clarify.prompt

你是企业后台产品经理。请基于以下需求，先不要写 PRD。
请输出 12 个必须澄清的问题，并按“业务目标、用户角色、数据来源、权限、安全、验收标准”分组。
每个问题后面补一句：如果不澄清，会导致什么风险。

需求：
商品导入失败后，希望运营能看到失败原因，并支持下载失败明细。

已知约束：
- 首版不改造导入解析引擎
- 复用现有任务记录页
- 失败明细最多保留 30 天

澄清维度	示例问题	不问清楚的风险
业务目标	首版要降低哪个环节的排查时间？有没有目标值？	PRD 写成“功能堆叠”，上线后很难证明价值。
数据来源	当前导入服务是否保存每一行的失败原因和原始行号？	方案可能依赖不存在的数据，研发评审会直接卡住。
权限安全	下载文件是否包含成本价、供应商信息、手机号等敏感字段？	容易造成越权查看或数据泄露。
验收口径	导入 10 万行时，失败明细多久能生成并下载？	性能和用户体验无法评估，测试也没有明确标准。

04 · 查资料和知识库

AI 不能只会写，还要会带着问题找证据

PRD 里最容易出问题的地方，是模型把“常见做法”当成“公司现状”。资料检索就是为了减少这种误差。

1 拆检索意图 把问题拆成业务、系统、字段、权限、历史方案几类。

2 找权威资料 优先找历史 PRD、接口文档、表结构、错误码、客服工单。

3 抽取事实 只提取和本需求有关的事实，不把资料整段塞进 PRD。

4 记录来源 每个关键结论绑定 sourceId、标题、更新时间和可信度。

5 识别冲突 资料互相矛盾时，不让 AI 自己拍板，列为待确认。

6 形成证据包 把可用事实、引用来源、缺口和假设交给 PRD 生成环节。

建议检索的企业资料 Evidence

文历史 PRD、评审纪要、产品说明、运营 SOP。
技接口文档、数据库字段、导入服务日志、错误码表。
客客服工单、用户反馈、常见问题、投诉记录。
数导入任务量、失败率、失败原因分布、下载量预估。
权角色权限矩阵、数据脱敏规范、审计日志要求。

检索计划结构 research-plan.json

{
  "researchQuestions": [
    {
      "question": "导入失败原因是否已有标准错误码？",
      "sources": ["错误码表", "导入服务接口文档", "历史导入 PRD"],
      "acceptance": "能找到错误码、错误文案、是否面向运营展示"
    },
    {
      "question": "失败明细目前保存在哪里，保留多久？",
      "sources": ["导入任务表结构", "对象存储说明", "运维配置"],
      "acceptance": "能确认存储位置、过期策略、下载链路"
    },
    {
      "question": "运营能否查看全部商家的失败明细？",
      "sources": ["权限矩阵", "商品后台角色说明"],
      "acceptance": "能确认角色、数据范围和审计要求"
    }
  ]
}

05 · 对齐企业系统现状

企业 PRD 最怕脱离系统，方案必须贴着现状长出来

面试里讲 AI 生成 PRD，要体现工程意识。你要说明 AI 不只是写页面文案，还会分析现有模块、接口、数据和权限。

现有入口 商品管理后台已经有“导入任务记录页”，运营能按任务查看导入状态。

→

新增入口 在失败任务行增加“查看失败明细”和“下载失败明细”。

现有数据 导入任务表有任务 ID、上传人、状态、总行数、失败行数、文件地址。

→

需要补齐 失败行号、原始字段、标准错误码、错误说明、可下载文件地址。

现有权限 运营按业务线查看任务，主管可查看团队任务。

→

新增控制 下载失败明细沿用任务查看权限，并记录下载审计日志。

系统要素	现状判断	对 PRD 的影响
页面入口	已有导入任务记录页，用户习惯从这里排查。	首版优先复用入口，不新增独立菜单。
错误码	导入服务已有部分系统错误码，但业务错误码不完整。	PRD 要定义运营可理解的错误文案和未知错误兜底文案。
存储成本	失败明细文件可能较大，不适合无限期保存。	定义 30 天保留期，过期后页面展示“文件已过期”。
权限审计	导入任务已有角色权限，但下载动作没有单独日志。	PRD 增加下载审计要求，记录用户、时间、任务 ID、文件类型。

06 · 范围和非范围

PRD 一定要写清楚“做什么”和“先不做什么”

AI 生成内容时很容易把功能越写越大。范围控制是把 PRD 从“理想方案”拉回“本期能上线”的关键。

本期范围

能支撑首版价值的最小闭环

查看失败明细、展示失败原因、下载失败明细、处理文件过期、记录下载审计、提供基础筛选。

本期不做

容易拉大工作量的能力

自动修复失败数据、一键重试失败行、跨系统导入模板治理、错误码平台改造、商家侧开放。

范围边界示例 scope.md

本期目标：
让运营在商品导入失败后，可以在任务记录页查看失败明细，理解失败原因，并下载失败明细用于修正数据。

本期范围：
1. 在失败任务行展示“查看失败明细”入口。
2. 失败明细页展示行号、商品编码、字段名、失败原因、建议处理方式。
3. 支持下载失败明细文件。
4. 失败明细文件保留 30 天，过期后不支持下载。
5. 下载动作记录审计日志。

本期不做：
1. 不做自动修复。
2. 不做一键重新导入失败行。
3. 不开放给外部商家。
4. 不重构导入解析引擎。
5. 不统一治理全部历史错误码。

07 · 用户流程和异常流程

只写正常流程不够，异常流程才是企业后台的重点

后台系统里的 PRD，经常因为异常状态没写清楚导致研发和测试反复追问。AI 生成时要强制补全异常分支。

运营上传商品导入文件 系统生成导入任务，显示处理中、成功、部分失败或失败。

进入导入任务记录页 失败任务展示失败行数、失败原因摘要和查看入口。

查看失败明细 用户查看行号、字段、错误原因、处理建议，可按错误类型筛选。

下载失败明细 系统校验权限和文件有效期，生成下载记录。

必须写的异常分支 Exception

A任务仍在处理中：入口置灰，提示“导入完成后可查看失败明细”。
B失败明细为空：展示空态，提示可能是系统错误或文件解析失败。
C文件已过期：不可下载，展示保留期说明和重新导入建议。
D无权限访问：隐藏或拦截入口，并提示联系管理员开通权限。
E下载失败：展示重试入口，记录错误码，避免用户误以为没有权限。
F错误码未知：展示“系统暂未识别该错误”，并允许复制原始错误信息。

08 · 字段、权限和业务规则

PRD 要能让研发知道“存什么、查什么、控什么”

对程序员来说，这一节最重要。只写页面功能不够，还要写字段、权限、状态、保留期、审计和错误码。

字段	说明	规则	来源
taskId	导入任务 ID	用于定位任务、权限校验和审计日志。	导入任务表
rowNo	原始文件行号	从第 2 行开始计数，表头不计入失败行。	导入解析结果
skuCode	商品编码	为空时展示“未识别”，但仍保留原始行号。	上传文件
fieldName	失败字段	使用业务字段名，不直接展示数据库字段名。	字段映射表
errorCode	错误码	优先使用标准错误码，未知错误统一归类为 UNKNOWN。	导入服务
errorMessage	运营可读错误原因	不能暴露堆栈、SQL、内部服务名和敏感配置。	错误码文案表
suggestion	处理建议	每类常见错误至少提供一条可执行建议。	运营 SOP

权限规则

谁能看

沿用任务记录页的数据权限。运营专员只能看自己业务线，主管可以看团队范围，管理员可查看全部。

保留规则

保存多久

失败明细和下载文件保留 30 天。过期后页面保留任务摘要，但下载按钮不可用。

安全规则

不能泄露

下载文件不得包含成本价、供应商联系人、手机号等敏感字段；错误原因不得展示内部异常堆栈。

09 · 生成 PRD 草稿

给 AI 的任务单越清楚，PRD 越像能落地的文档

生成草稿时，不要只给“写一份 PRD”。要把输入、证据、系统约束、输出格式、引用要求和禁止事项一次讲清楚。

生产级 PRD 生成提示词 prd-generation.prompt

你是企业后台产品经理，请基于“需求录入、澄清结果、资料证据、系统现状”生成一版可评审 PRD。

写作要求：
1. 不要编造公司没有确认的信息。
2. 关键结论必须标注来源 sourceId；没有来源的内容写入“假设与待确认”。
3. 范围要分为“本期做”和“本期不做”。
4. 必须包含正常流程、异常流程、字段规则、权限规则、验收标准、风险和埋点。
5. 文风面向研发、测试、产品和运营评审，不写营销语言。

输出结构：
- 背景和目标
- 用户和场景
- 本期范围 / 非范围
- 用户流程
- 功能需求
- 字段和业务规则
- 权限和安全
- 异常状态
- 数据埋点和效果指标
- 验收标准
- 风险、假设和待确认
- 引用来源

背景和目标

写清楚为什么做、现状痛点是什么、上线后要改善哪个指标。

功能需求

按用户动作拆，不要只写页面元素。每条需求都要能被研发拆任务。

规则和约束

写字段、权限、状态、保留期、下载限制、错误码和安全要求。

异常状态

处理中、无明细、文件过期、无权限、下载失败、未知错误都要有处理方式。

验收标准

用 Given / When / Then 或清单写清楚测试怎么判断通过。

来源和假设

每个关键结论要知道来自哪里；没确认的内容不能混进正式结论。

10 · 验收标准

验收标准要让测试不用猜，研发不用反问

PRD 最后不能只写“满足需求”。AI 生成 PRD 时，要强制输出可测试、可复现、可判断的验收标准。

验收标准怎么写 Given / When / Then

GGiven：给定前置条件，例如用户角色、任务状态、文件是否过期。
WWhen：用户执行动作，例如点击查看、筛选错误类型、下载文件。
TThen：系统应该出现什么结果，例如展示字段、拦截权限、记录审计。

好的验收标准像测试用例的骨架。它不替代测试用例，但能让研发、测试、产品在同一条判断线上。

验收标准示例 acceptance.md

场景 1：查看失败明细
Given 运营专员拥有该业务线导入任务查看权限
And 商品导入任务状态为“部分失败”
When 用户点击“查看失败明细”
Then 系统展示失败明细列表
And 列表包含行号、商品编码、失败字段、失败原因、处理建议
And 默认按行号升序展示

场景 2：下载已过期文件
Given 失败明细文件生成时间已超过 30 天
When 用户点击“下载失败明细”
Then 系统禁止下载
And 提示“失败明细文件已过期，请重新导入后查看”
And 不生成下载审计记录

场景 3：无权限访问
Given 用户没有该任务的数据权限
When 用户通过链接访问失败明细页
Then 系统拦截访问
And 提示“暂无权限查看该导入任务”

11 · 评审和迭代

AI 生成 PRD 后，还要让 AI 帮你做评审前自检

真正的工作不是“生成完就交”。要让 AI 扮演研发、测试、运营、安全四类评审者，提前找漏洞。

P 产品视角

目标是否明确，范围是否收敛，用户价值是否能被验证。

E 研发视角

数据来源、接口依赖、权限逻辑、异常状态是否写清楚。

Q 测试视角

验收标准是否可测，边界条件是否完整，状态组合是否覆盖。

S 安全视角

下载、脱敏、审计、越权访问、敏感错误信息是否处理。

PRD 自检提示词 review.prompt

请你作为评审委员会检查这份 PRD。
请分别以产品、研发、测试、安全、运营 5 个角色提出问题。

输出格式：
1. 阻塞问题：不解决就不能进入研发评审。
2. 高风险问题：需要在评审会上重点确认。
3. 可优化问题：不阻塞首版，但建议补充。
4. 缺失信息：需要补来源或列为待确认。
5. 修改建议：给出可以直接粘贴进 PRD 的改写版本。

评审原则：
- 没有来源的结论要标出来。
- 依赖不存在的数据要标出来。
- 验收标准不可测试要标出来。
- 范围膨胀要标出来。
- 安全和权限遗漏要标出来。

12 · 质量检查清单

判断 AI PRD 好不好，看这 10 项就够了

这份清单可以作为面试回答，也可以作为实际工作里的 PRD 出稿标准。

检查项	合格标准	常见问题
目标	能说明业务痛点、目标用户和成功指标。	只写“提升效率”，没有具体对象和指标。
来源	关键事实有 sourceId 或明确来自人工确认。	模型把行业常识写成公司现状。
范围	明确本期做什么、不做什么。	把长期规划混进首版，导致评审发散。
流程	正常流程和异常流程都能走通。	只写成功路径，没有处理中、过期、无权限等状态。
字段	字段含义、来源、展示规则和脱敏要求清楚。	页面字段写了，但数据从哪里来不清楚。
权限	角色、数据范围、操作权限和审计要求清楚。	只写“有权限的人可见”，没有具体角色。
验收	可以被测试复现和判断通过。	验收标准写成“体验良好”“数据正确”。
风险	列出数据、性能、权限、历史兼容和运营风险。	没有风险，或者只写“研发排期风险”。
假设	未确认内容单独放在假设和待确认中。	把猜测写成确定结论。
可读性	研发、测试、运营都能按文档讨论和拆任务。	章节很全，但每段都很泛，没人知道怎么落地。

13 · 完整案例

从一句需求生成“商品导入失败明细”PRD

这一段可以直接作为面试项目讲法：我如何用 AI 从需求录入走到高质量 PRD。

原始需求 运营反馈商品导入失败后排查困难，希望能看到失败原因并下载失败明细。

AI 生成澄清问题 确认用户角色、错误码来源、下载字段、权限范围、文件保留期和验收指标。

查知识库 找到导入任务记录页 PRD、错误码表、导入接口、权限矩阵和客服工单。

对齐系统现状 确认复用任务记录页，失败明细文件保留 30 天，下载需要审计。

生成 PRD 草稿 输出背景、范围、流程、字段、权限、异常、验收、风险和引用来源。

评审迭代 用研发、测试、安全视角检查，补上无权限、文件过期、未知错误等边界。

最终 PRD 片段 prd-excerpt.md

# 商品导入失败明细 PRD

## 1. 背景和目标
商品运营在批量导入商品时，经常遇到“部分失败”。目前任务记录页只展示失败行数，运营需要联系研发查日志或反复尝试修改文件，排查成本高。

本期目标：
- 让运营能在导入任务记录页查看失败明细。
- 让运营能下载失败明细，按错误原因修正数据。
- 降低导入失败排查对研发和客服的依赖。

## 2. 本期范围
本期做：
- 失败任务展示“查看失败明细”入口。
- 失败明细页展示行号、商品编码、失败字段、失败原因、处理建议。
- 支持按错误类型筛选。
- 支持下载失败明细文件。
- 下载动作记录审计日志。

本期不做：
- 不做自动修复。
- 不做一键重新导入失败行。
- 不开放给外部商家。

## 3. 权限和安全
- 失败明细查看权限沿用导入任务记录页权限。
- 下载文件不得包含成本价、供应商联系人、手机号等敏感字段。
- 下载审计记录包含用户 ID、任务 ID、下载时间、下载结果。

## 4. 异常状态
- 文件已过期：展示“失败明细文件已过期，请重新导入后查看”。
- 用户无权限：拦截访问并提示“暂无权限查看该导入任务”。
- 错误码未知：展示“系统暂未识别该错误”，保留原始错误摘要。

## 5. 待确认
- source: error-code-table-v2 是否覆盖全部业务错误码。
- 是否需要将失败明细下载入口开放给运营主管以外角色。
- 10 万行导入失败时，失败明细生成时间的性能目标。

14 · 面试问答

把这套方法讲清楚，比背概念更有说服力

面试官问 AI 生成 PRD，通常想看你是否懂 AI 落地、企业系统、需求质量和风险控制。

问题 1：AI 生成 PRD 的核心价值是什么？

核心价值不是替人写文档，而是提高需求工程的质量和效率。AI 可以把模糊需求结构化，生成澄清问题，检索历史资料，提取系统现状，辅助生成 PRD 草稿，并从研发、测试、安全等视角做自检。最终决策仍然由产品和业务负责人确认。

问题 2：怎么避免 AI 编造企业系统现状？

要把 PRD 生成和知识库检索绑定起来。关键结论必须有来源，例如历史 PRD、接口文档、表结构、权限矩阵、工单数据。没有来源的内容不能写成事实，只能放到假设和待确认。评审时也要检查引用是否支持结论。

问题 3：AI 生成的 PRD 如何保证研发能落地？

要让 PRD 包含工程需要的信息：入口、状态、字段、接口依赖、数据来源、权限、异常、性能、审计、验收标准和风险。只写用户故事和页面描述不够，企业后台尤其要把业务规则和系统边界写清楚。

问题 4：如果资料里有冲突，AI 应该怎么处理？

不能让 AI 自己选一个看起来合理的答案。正确做法是把冲突列出来，标明各自来源和更新时间，放入待确认问题，由业务、产品或系统负责人确认。PRD 中需要记录最终采用哪个口径。

问题 5：你会怎么评估 AI PRD 的质量？

我会看十个维度：目标是否清楚、来源是否可靠、范围是否收敛、流程是否完整、字段是否明确、权限是否可控、异常是否覆盖、验收是否可测、风险是否真实、待确认是否单独列出。只要这些维度不清楚，文档再完整也不能算高质量。

15 · 练习和速查

最后记住一条主线：输入、证据、现状、草稿、评审

这节课的目标不是背模板，而是能把模板用到真实需求里。

5 分钟练习 Practice

1任选一个后台需求，例如“导出订单列表增加字段”。
2把一句话需求写成 intake.json，至少包含目标、用户、约束和未知项。
3让 AI 输出 10 个澄清问题，并标出不澄清的风险。
4列出需要查的 5 类资料：历史 PRD、接口、字段、权限、数据。
5生成一版 PRD，然后让 AI 用研发、测试、安全视角评审。

速查口诀 Cheatsheet

输先把口头需求结构化，不要直接写文档。
问先生成澄清问题，把不确定项暴露出来。
查查知识库和系统资料，关键结论绑定来源。
对对齐现有入口、字段、权限、接口和数据限制。
写生成范围清楚、规则明确、可验收的 PRD 草稿。
审用多角色评审补齐风险、异常和待确认问题。

通用工作流模板 ai-prd-workflow.md

1. 需求录入
   - rawRequirement
   - targetUsers
   - businessGoal
   - knownConstraints
   - unknowns

2. 澄清问题
   - 业务目标
   - 用户角色
   - 数据来源
   - 权限安全
   - 验收标准

3. 资料检索
   - 历史 PRD
   - 接口和表结构
   - 权限矩阵
   - 工单反馈
   - 数据指标

4. 系统现状分析
   - 可复用模块
   - 需要新增的数据
   - 依赖和限制
   - 风险和假设

5. PRD 生成
   - 背景目标
   - 范围和非范围
   - 流程和异常
   - 字段和规则
   - 验收和风险

6. 评审迭代
   - 产品评审
   - 研发评审
   - 测试评审
   - 安全评审
   - 运营确认