会议纪要，能直接变 PRD 吗？

会议不是同步动作，而是交付链路输入层

很多产品经理不是不会写 PRD，而是每天被会议切碎。需求评审、方案讨论、临时同步、研发对齐、业务反馈，每一场会都能产生很多信息。但会后最常见的结果是：群里丢一份会议纪要，大家说“收到”，然后真正要写需求时，PM 还是重新打开空白文档。

这件事很浪费。会议里本来就有大量需求原料：用户是谁，为什么现在要做，已经决定了什么，哪些地方还没想清楚，研发担心什么，业务最在意哪个结果。只是这些信息通常散在聊天里，没有被整理成能继续推进的结构。

所以看到 Zara Zhang 提到 "meeting transcript as PRD" 时，第一反应不是“AI 要替代 PM 写需求了”，而是：这个方向很适合拿来改造 PM 的日常工作流。

PRD 是 Product Requirements Document，产品需求文档。它不只是把想法写漂亮，而是把目标、用户、流程、边界、验收和责任关系讲清楚。如果会议转录能成为 PRD 的输入，PM 的工作重点就会变化：不再是会后从零回忆，而是在会议发生时，就有意识地把讨论变成可加工的材料。

一个很短的行业信号

这次来源很短，但信号很明确。Zara Zhang 在 X 上说，她尝试把会议转录当成 PRD：和同事讨论一个功能的实现，把 transcript 交给 Codex，然后 Codex 按讨论生成 prototype。她最后的判断是：会议就是 prompt。

Transcript 是转录文本，也就是会议录音、语音或对话被转换出来的文字。Prompt 是提示词，但放在工作流里，它不一定是一句“帮我写一个 PRD”。更准确地说，prompt 是你给 AI 的任务上下文、目标、约束和输出要求。Prototype 是原型。它可以是一个页面 demo、一个交互草图、一个代码雏形，也可以是一段帮助团队理解方案的可运行样例。

把这三个词连起来，重点不是“会议纪要自动变成完美文档”。重点是：会议可以从一次同步动作，变成后续文档、原型和任务拆解的输入层。这对 AI PM 很有价值。

因为 AI 产品经理经常卡在一个很具体的问题：讨论很多，信息很多，但交付物还是要手工补。AI 如果只帮你“总结会议”，价值有限；如果它能基于会议生成 PRD v0、prototype prompt、验收清单和待确认问题，会议才真正进入了交付链路。

会议纪要不是成品，是原材料

我会把这件事翻译成一句更产品化的话：会议纪要不是成品，它是需求生产线的原材料。

很多人使用 AI 处理会议纪要，第一步会让它“帮我总结一下”。这当然有用，但还是停在记录层。

更高一层的用法，是让 AI 做结构化抽取。同样一份会议转录，你可以让 AI 不只总结，而是抽出：

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

这一步做完，PRD 已经有了骨架。注意，是骨架，不是终稿。

会议转录通常有三个天然缺陷：口语很多、上下文缺失、讨论顺序不等于文档顺序。AI 可以帮你把它重排，但它不知道哪些信息是敏感的，也不知道组织里哪些默认规则没有被说出口。

所以 PM 不能把 transcript 直接丢给 AI，然后把生成结果复制给研发。更稳的方式是：把 AI 当成需求助理，让它先生成 v0；PM 再做判断、补边界、查事实、补验收。

一套 5 步工作流

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

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

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

比如可以在会议邀请或开场时说明：这次会的目标是确认某个功能的 v0 范围，会后要产出 PRD 骨架和 prototype 输入，不讨论排期。这句话很简单，但它会影响整场会议的信息质量。

第二步，会中刻意说出“决策语言”。会议转录能不能变成 PRD，取决于会议里有没有可抽取的结构。

如果大家只是说“这个可以优化一下”“这里再看看”“体验要更好”，AI 很难知道你们到底定了什么。

更好的表达是：

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

这些句子不一定优美，但很适合被 AI 抽取。

第三步，会后先抽需求骨架，不要直接要终稿。我会先让 AI 输出一个结构化版本，而不是直接写完整 PRD。

可以用这样的 prompt：

请基于下面会议转录，生成 PRD v0 骨架。

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

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

第四步，再让 AI 生成 prototype 输入。如果 PRD 骨架已经过了一轮人工 review，就可以继续把它变成 prototype prompt。

这里的 prototype 不一定要追求可上线。它的价值是帮助团队更快看见方案长什么样。

你可以要求 AI 输出：

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

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

第五步，PM 做最后的 human review。Human review 是人工审核。它不是形式动作，而是这套流程能不能进入真实工作的关键。

至少要检查五件事：

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

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

今天就能试的 checklist

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

会前：

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

会中：

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

会后：

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

这不是文档自动化

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

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

会议中说清目标、边界、权限和验收，会后 AI 才能把它们整理成可推进的材料。这也是 AI PM 很重要的一种能力：不是把所有工作交给 AI，而是把工作过程整理成 AI 能接住的输入。

当会议本身变得更结构化，PRD、prototype 和任务拆解才会自然变快。