很多产品经理不是不会写 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 和任务拆解才会自然变快。
