产品经理怎么用 AI 写 PRD：一条从需求到文档的五步工作流

让 PRD 成为流程的终点，而不是起点——每一步的产物，都是下一步的输入。

PRD 不是写出来的，是流程"长"出来的

上一篇《为什么 AI 生成的 PRD 又臭又长？》的结论是：长不是目的，共识才是；文档膨胀，常与通用生成倾向、松散输入和缺少审核共同有关。

诊断做完，这篇给药方——一条我自己在用的五步工作流：从一句话需求，到一份开发（和 AI Agent）拿到就能开工的 PRD。它一共五步，每一步都按"目的 / 输入 / 动作 / 产物"来写，你可以直接照做，也可以直接转给团队照做。

先说这条流程的灵魂，再展开每一步。

一、核心思路：PRD 是流程的终点，不是起点

大多数人的用法是"坐下来写 PRD"——打开文档，从第一章憋到最后一章，AI 顶多帮忙填空。这条工作流正好反过来：让每一步的产物成为下一步的输入，让 PRD 成为前面所有工作的自然汇编。

概念文档锚定方向，方案图对齐认知，原型验证交互，批注固化规则，到最后一步生成 PRD 时，AI 做的是汇编，你做的是裁剪——文档里的每一句话，都在前面的步骤里真实发生过，而不是生成时的即兴发挥。

这也是 AI 时代写文档的分工原则：**AI 负责生成和组织，人负责决策和把关。**流程设计好了，两边都发挥到最大。

先把五步和每步需要确认的事放在一起，后面逐步展开：

图 1：每一步都留下可传递的产物；发现冲突，就回到对应步骤澄清。文中配图均可点击查看原图。

二、五步工作流：从一句话需求到 PRD

第 1 步：需求分析，产出需求概念文档

• 目的：把一句话需求变成有边界的问题描述。这是整条流程的锚，后面所有 AI 生成的质量都取决于它。
• 输入：原始需求——业务方的原话、数据反馈、或老板的一句话。
• 动作：与需求方对齐四个问题：解决什么问题、给谁解决、在什么场景下、不做什么；再约定用什么指标判断有效。可以让 AI 帮你追问盲区、列举边界情况，但结论必须由你拍板。
• 产物：一页纸的需求概念文档：问题定义、目标用户、核心场景、范围边界（做什么 / 不做什么）、成功指标与已知约束。

这一步最容易被跳过，也最不能被跳过。垃圾进，垃圾出，这条规律在 AI 时代只会被放大，不会被折扣。

这一步还有个常见的坑：把解决方案当成需求写了进去。"加一个定时发布功能"是方案，"作者想在写作高峰期提前排好内容、错峰发布"才是需求。概念文档先写清问题、目标和约束，解决方案留给后面几步去发散。

第 2 步：用生图模型快速产出方案图

• 目的：在展开详细 PRD 之前，先把"用户怎么用"画出来。
• 输入：需求概念文档 + 项目现有页面的实际截图 + 必要的上下文补充（比如目标用户的使用习惯）。
• 动作：把这三样一起交给生图工具，生成大致的操作流程图和使用方案图。方向不对，就调整描述重新生成；涉及分支和规则的地方，要逐项核对，不能只看画面是否顺眼。
• 产物：操作流程图、使用方案示意图——与业务方和团队对齐方向的视觉材料。

这一步的价值不在图精美，而在于让团队更早看到可讨论的方案。低成本草图可以减少等待正式设计稿的时间，但生成速度不能代替需求确认。记住一句话：这时的图是拿来讨论和否决的，不是最终交付承诺。

第 3 步：生成高保真原型，两条路线

• 目的：把确认过的方向，变成可以点、可以体验的界面。
• 输入：需求概念文档 + 方案图。
• 动作：在两条路线中选择，或组合使用：

| | 路线 A：全新生成 | 路线 B：已有项目 + Mock | |---|---|---| | 做法 | 让 AI 生成全新的 HTML 页面甚至小型项目代码 | 在已有前端项目里加页面和组件，用 mock 数据填充 | | 适合 | 探索期功能、全新模块、尚未成型设计系统的项目 | 成熟项目、增量功能、有既定设计规范的项目 | | 优势 | 速度快、无历史包袱、可以大胆尝试风格 | 还原真实样式与交互，开发可直接参考和复用 | | 风险 | 与现有产品风格脱节，返工成本高 | 受现有代码结构约束，改动需要先理解项目 |

• 产物：可以运行和演示的高保真原型。

两条路线没有优劣，判断标准只有一条：这个原型离最终代码有多远——探索期允许远，落地期必须近。

实践中更多是组合拳：探索期用路线 A 快速试方向，方向确认后再切到路线 B 落地——A 负责"快"，B 负责"真"。

第 4 步：验证原型，截图批注并确认规则

• 目的：验证第 3 步的可运行原型，把页面行为和业务规则确认清楚。
• 输入：第 3 步的代码化原型。
• 动作：把项目跑起来，对关键页面和交互状态截图，导入 Figma 或 Axure，用批注标出交互细节——点击哪里、跳转哪里、什么状态显示什么、异常时怎么提示。同时对照现有模型确认字段、权限与边界规则，补齐指标的采集口径；未确认项单独列出。
• 产物：带批注的页面截图组，以及已确认的规则、字段、指标口径和待澄清项，供开发与测试对照。

批注要落到可以验证的行为。以定时发布为例，不能只标一个"确认按钮"，还要说清触发条件、校验、提交后的状态与失败时的处理。

图 2：教学示例，页面与规则均用于说明批注方法，不代表现有系统。图中成功指预约提交成功，不等于文章已发布；实际规则需结合项目确认。

这一步的关键转变是：可运行原型帮助验证，确认后的批注固化规则。原型仍不等于生产系统；截图之外的权限、数据规则和异常处理，也不能靠开发猜。对齐得越具体，后续返工的空间就越小。

第 5 步：汇总生成 PRD

• 目的：让前面四步的产物自然汇编成文档。
• 输入：概念文档、流程图、原型与批注截图、已确认的规则字段和指标口径，以及过程中确认过的其他决策。
• 动作：交给 AI 汇编成 PRD 初稿；人做的是裁剪——删掉 AI 添油加醋的部分，核对每条规则是否是团队真实确认过的。
• 产物：一份短而准的 PRD。

注意最后一步里人的角色：重点是审。AI 负责把材料组织成文档，你负责保证每条规则有依据；发现材料缺失或相互冲突，就补充确认，不能让 AI 静默补成事实。

五步连起来，全景长这样：

| 步骤 | 关键产物 | 主要消费者 | |---|---|---| | 1 需求分析 | 需求概念文档 | 业务方、你自己 | | 2 方案图 | 流程图 / 使用方案图 | 业务方、团队 | | 3 高保真原型 | 可运行的原型 | 设计、业务方 | | 4 验证与批注 | 批注截图、确认规则与待澄清项 | 开发、测试 | | 5 汇总成文 | PRD | 开发、测试、AI Agent |

三、四个核心模块：先把这些写清楚

走完流程你会发现，需要独立撰写的内容很少。四个核心模块，素材全部来自前四步：

• 核心业务流程图（第 2 步产物）：用户怎么走完整个流程，主路径、分支、异常出口，一张图讲清楚。
• 核心页面交互与原型描述（第 3、4 步产物）：关键页面的元素、状态与跳转关系，配批注截图。
• 功能规则与字段定义：校验、权限、边界规则，以及字段清单——名称、类型、约束、默认值。依据第 4 步确认的规则和现有数据模型整理，必要新增仍需说明理由。
• 数据指标与埋点设计：功能上线后用什么指标衡量成败、需要埋哪些点。把第 1 步的成功指标与第 4 步确认的采集口径落到可执行定义。

图 3：概念文档约束整体范围；每个模块都有材料来源，缺失与冲突先澄清。

四个模块各有各的读者：流程图和原型描述给开发与设计看，功能规则和字段定义给开发与测试看，埋点设计给数据和未来的你看。心里装着读者，下笔才有取舍。

至于测试用例、异常流全量梳理、权限矩阵、版本规划——按风险与协作需要补充，而非默认堆全。关键异常和权限要求必须说清，是否独立成章看复杂度；测试用例可以让 QA 基于这份 PRD 用 AI 展开初稿。

**PRD 不是百科全书，而是开发与 AI 协作的输入接口。**接口的关键指标是准确和稳定，不是全面。

四、仍需重点审核：字段定义

五步走顺之后，功能规则与字段定义仍是需要重点审核的环节。冗余字段、自造实体、规范冲突，可能藏在文档里看起来最专业的那几页。它为什么会这样、审核四问和防范四招怎么用，我写在了上一篇《为什么 AI 生成的 PRD 又臭又长？》里，这里不再重复。

只提醒一句：**审核 AI 的字段设计，本质上是在审核你对自己系统边界的理解。**可以让 AI 辅助查漏，但仍需由产品、开发等相关负责人共同确认。

结语：从文档作者到流程导演

整套工作流，可以浓缩成一句话模板：

面向【用户与场景】，我们通过【功能】解决【问题】，用【指标】验证成效——概念文档定义它，流程图和原型展示它，字段定义落地它，埋点验证它。

下次开工前，用四个问题自检：

1. 这份需求的概念文档，边界（不做什么）写清楚了吗？
2. 方案方向，是否已用低成本草图与业务方确认，再进入详细设计？
3. PRD 里的每个字段，你说得出谁写入、谁读取、在哪里使用吗？
4. 你的生成规则里，有没有一条"新增必须说明理由"？

Agent 会越来越强，接手的环节会越来越多。但系统边界在哪里、共识对不对、质量关不关得住，仍然而且将长期是人的责任。产品经理的下一个身份，不是文档作者，是流程导演。