WorkBuddy 写 PRD 别再一稿到底：我把它拆成对齐、生成、评审三步

我觉得吧，产品经理最容易被开发骂，往往是因为需求太虚。

评审会上我张口就来，这个需求很简单。开发接着问，入口在哪，异常怎么办，权限谁给，数据从哪来。我当场卡住。最近在反思自己话太多这件事，后来发现关键在话没有结构。

刷到一篇 prd-writer 的分享，说 AI 写 PRD 别再一稿到底。它把流程拆成先对齐方向，再写细节，还带评审和增量更新。

prd-writer 的核心做法是先对齐方向，再写落地细节，带评审和增量更新。

我觉得这个思路挺对。但我没直接用那个 Skill，我这边更熟 WorkBuddy。WorkBuddy 是我用来处理文档、表格、会议记录这些办公杂事的 AI 办公效率工具。我用了大概一个月 WorkBuddy 自动周报，最近两周又试 AI 生成 PRD 工具，最后发现真正稳的做法，是让 WorkBuddy 先把需求拆成一张能跑的输入表。

第一步，别急着写 PRD，先建输入契约

PRD 就是产品需求文档。输入契约是我给它的一圈边界，必须填的字段和必须标明的来源都写清楚，没确认的内容不能编。

我现在的做法是打开 WorkBuddy，左侧点新建文档任务，我这边叫这个，不同版本可能名字不一样。顶部选从文件导入，把企业微信文档里的会议记录、腾讯会议转写、口头需求笔记一起丢进去。企业微信文档我用了一周，腾讯会议转写也刚用一周，好处是原文都在，WorkBuddy 不用靠我脑补。

导入后，在任务规则里粘贴固定字段，目标用户、使用场景、入口、核心流程、异常分支、权限角色、数据字段、验收标准、待确认问题。结构化字段就是把需求拆成一格一格，不让 AI 自由发挥成小作文。

点运行后，WorkBuddy 会在右侧生成一张字段抽取表。每个字段后面有来源，比如会议记录第 12 行，企业微信文档第 3 段。如果找不到来源，它会写待确认。这一步很关键。以前我让 AI 直接写 PRD，它能把生鲜 App 写成生鲜帝国，功能一个比一个响，研发一问落地就傻。

这里有个坑。我一开始让它把 Axure RP 和墨刀里的原型说明一起总结，结果它把页面名称当成需求，输出了一堆按钮名。后来我学乖了，刚上手 Axure RP 这几天，原型只作为附件，不作为事实来源。需求以会议结论为准。

第二步，分三段生成，不要一稿到底

分三段生成是我现在最推荐的配置。

WorkBuddy 里建三个子任务，或者同一个任务分三轮。第一轮只生成一页纸方向摘要，包含用户问题、业务目标、不做什么。第二轮生成流程与字段，只写主流程和异常。第三轮生成验收与待确认，给研发和测试看。

具体路径是，输入表生成后，选中表，点生成文档，模板选摘要，提示词写不要扩写，只输出以下字段，缺信息就提问。生成后复制摘要，再回到 WorkBuddy，把摘要作为上下文，让它生成流程图文字版和字段表。最后让它输出 PRD 初稿。

这样出来是一版能被评审的需求。我觉得吧，AI 写 PRD 最大的问题是幻觉。把问题拆开，每一轮都有输入，幻觉就少了。

权限上也别乱。我把企业微信文档设成三类人，产品能编辑输入表，研发和测试只读，老板只能评论。

WorkBuddy 生成的 PRD 初稿先不直接发群里，我手动贴到企业微信文档的个人草稿区，评审通过后再同步。小团队不需要很重的系统，一个轻量审批和评论就够了。

第三步，日常维护，别让 PRD 变成新坑

WorkBuddy 处理简单文本还行，复杂表格格式保持确实不稳。上周我用它搭口径台账时就遇到过，字段多了会吞格式。所以 PRD 里的表格不要一次生成太复杂。

我每周会做三件事：每次评审后，把新增结论丢回 WorkBuddy，跑一次增量更新，不让旧文档继续骗人。每周五检查待确认问题，超过 3 条就标红，说明需求还没真对齐。导出给研发前，手动核对异常分支和权限字段，这两块 WorkBuddy 最容易漏。

你听我说，如果你下周也要用 AI 写 PRD，别直接丢一句帮我写个 App 需求文档。先用 WorkBuddy 把会议记录、企业微信文档和腾讯会议转写整理成输入表。需求简单不简单，得字段填完才知道。