会议纪要变PRD：产品经理的AI工作流改造实战

痛点：会议切碎了PM的时间，却切不出PRD

产品经理的日常充满了各种会议：需求评审、方案讨论、临时同步、研发对齐、业务反馈……每一场会都能产生大量信息，但会后最常见的结果是：群里丢一份会议纪要，大家回复“收到”，然后真正要写需求时，PM 还是得重新打开空白文档，从零开始回忆。

这件事的浪费之处在于：会议里本来就有大量需求原料。用户是谁、为什么现在要做、已经决定了什么、哪些地方还没想清楚、研发担心什么、业务最在意哪个结果——这些信息散落在聊天记录和语音转文字里，却没有变成可推进的结构化文档。

当 AI 开始进入办公场景，一个很自然的想法是：能不能让 AI 直接把会议纪要变成 PRD？但现实是，直接让 AI “帮我写一份 PRD”，往往得到的是一份看起来完整、实则空洞的模板。真正的问题不在于 AI 写不好，而在于：会议纪要本身就不是成品，它是原材料。

核心思路：会议纪要是原材料，不是成品

很多人处理会议纪要的第一步是让它“帮我总结一下”。这当然有用，但还是停在记录层。更高效的用法，是让 AI 做结构化抽取——从同一份会议转录中，不仅提取摘要，而是抽出：

• 这次讨论的目标是什么
• 目标用户或使用角色是谁
• 当前问题是什么，为什么现在要解决
• 已确认的决策有哪些
• 未确认的问题有哪些
• 功能流程里有哪些关键状态
• 涉及哪些权限、数据、接口或风控边界
• 验收标准应该怎么写

做完这一步，PRD 已经有了骨架。

但这里需要注意：会议转录通常有三个天然缺陷——口语表达多、上下文容易缺失、讨论顺序不等于文档顺序。AI 可以帮你重排内容，但它不知道哪些信息是敏感的，也不了解组织内部那些“没有说出口”的默认规则。所以，PM 不能简单地把 transcript 丢给 AI，然后把生成结果直接复制给研发。更稳妥的方式是：把 AI 当成需求助理，让它先生成 v0；PM 再做判断、补边界、查事实、补验收。

一套5步工作流

第一步：会前先定输出

不是每一场会议都适合变 PRD。如果这场会只是泛泛同步，信息密度不够，AI 只能帮你写一份看起来很完整、实际上没什么用的文档。

会前最好先写清楚三个锚点：

• 这场会要解决什么问题
• 会后希望产出什么交付物
• 哪些问题必须留给人工判断

比如可以在会议邀请或开场时说明：“这次会的目标是确认某个功能的 v0 范围，会后要产出 PRD 骨架和 prototype 输入，不讨论排期。”这句话很简单，但它会影响整场会议的信息质量——当参会者知道会后要出结构化文档，讨论自然会更有针对性。

第二步：会中刻意说出“决策语言”

会议转录能不能变成 PRD，取决于会议里有没有可抽取的结构。如果大家只是说“这个可以优化一下”“这里再看看”“体验要更好”，AI 很难知道你们到底定了什么。

更好的表达方式是明确说出决策结论：

• “这个版本先支持 A，不支持 B”
• “这个入口面向运营角色，不面向普通员工”
• “如果用户没有权限，页面展示空状态，不展示数据明细”
• “验收时重点看 3 个结果：能创建、能编辑、能追踪状态”

这些句子不一定优美，但很适合被 AI 抽取。当你在会议中养成说“决策语言”的习惯，信息结构化就成功了一半。

第三步：会后先抽需求骨架，不要直接要终稿

建议先让 AI 输出结构化版本，而不是直接写完整 PRD。可以用这样的提示词模板：

请基于下面会议转录，生成 PRD v0 骨架。要求：
1. 只使用会议里明确出现的信息，不要补充未提到的事实
2. 按以下结构输出：背景、目标用户、问题、目标、用户流程、功能范围、非目标、权限/数据边界、异常情况、验收标准、待确认问题
3. 对来源不清或会议中没有定论的内容，标记为“待确认”
4. 不要写宣传口吻，不要把猜测写成结论

这段提示词的重点不是措辞，而是输出结构。AI 最容易出问题的地方是把话说得很完整，你要反过来要求它暴露不完整：哪里没来源、哪里没定论、哪里需要 PM 再确认。

第四步：让 AI 生成 prototype 输入

如果 PRD 骨架已经过了一轮人工 review，就可以继续把它变成 prototype prompt。这里的 prototype 不一定要追求可上线，它的价值是帮助团队更快看见方案长什么样。

可以要求 AI 输出：

• 页面结构
• 主要用户动作
• 关键状态
• 空状态和异常状态
• 假数据字段
• 不做的功能

对产品经理来说，这一步很适合做早期对齐。需求文档容易让不同人脑补出不同画面，一个粗糙的 prototype 反而能让问题暴露得更快：入口对不对、字段多不多、状态有没有漏、权限讲没讲清楚。

第五步：PM 做最后的 human review

Human review 是人工审核，它不是形式动作，而是这套流程能不能进入真实工作的关键。至少要检查五件事：

• 来源：这条需求是不是会议里真的说过
• 边界：哪些能力明确不做
• 权限：不同角色能看什么、做什么
• 异常：失败、空数据、无权限、重复提交怎么处理
• 验收：研发和测试怎么判断已经完成

AI 可以帮你把材料整理得更快，但 PM 要负责判断哪些内容能进入文档，哪些内容必须回到人那里确认。

今天就能试的 checklist

如果想今天就试一次，建议从一个小功能会议开始，不要从大型项目开始。

会前：

• 写清本次会议目标
• 写清会后希望得到 PRD 骨架、prototype prompt 还是待办清单
• 提醒参会人把关键结论说完整

会中：

• 对已确认的决策说“本轮先做 / 本轮不做”
• 对不确定的内容说“待确认”，不要让它混进结论
• 对权限、数据、异常状态多问一句

会后：

• 先让 AI 抽取 PRD 骨架，不要直接要终稿
• 把无来源内容标出来
• 补充非目标、验收标准和异常分支
• 再生成 prototype prompt 或任务拆解
• 人工检查后再进入评审

不是文档自动化，是工作流升级

这套方法不适合所有会议。如果会议本身没有结论，AI 只能生成一份“像 PRD 的总结”。如果讨论里混有公司内部敏感信息，要先脱敏再处理。如果团队还没有基本的需求模板和验收习惯，AI 生成得越快，返工可能也越快。

我更建议把它当成产品经理的工作流升级，而不是简单的文档自动化。真正的变化不是“AI 帮我写 PRD”，而是“我开始用 PRD 的结构开会”。

当会议本身变得更结构化，PRD、prototype 和任务拆解才会自然变快。这也是 AI 时代产品经理很重要的一种能力：不是把所有工作交给 AI，而是把工作过程整理成 AI 能接住的输入。

会议中说清目标、边界、权限和验收，会后 AI 才能把它们整理成可推进的材料——这才是让 AI 真正提升产品交付效率的关键。