一句话结论：PRD 转流程图，是把文字需求变成可评审路径
PRD 通常包含背景、目标、用户故事、业务规则、页面说明、接口约束和异常处理。它适合完整记录需求，但不一定适合快速讨论流程。
流程图的价值，是把 PRD 里分散的角色、动作、状态、判断点和异常路径提炼出来，让产品、研发、测试、运营能围绕同一条路径讨论。
所以 PRD 转流程图不是把文档复制成图，而是把需求里的业务逻辑显性化。
第一步：先拆角色和场景
转流程图之前，要先明确这个流程发生在哪个场景里，涉及哪些角色。角色决定泳道，场景决定流程边界。
比如一个退款流程，可能涉及用户、客服、系统、财务、第三方支付。一个内容审核流程，可能涉及作者、系统、审核员、管理员。角色不清楚，流程图就会变成动作堆叠。
建议先从 PRD 里摘出这些信息。
- 用户是谁，触发动作是什么
- 系统自动处理哪些步骤
- 人工审核或运营介入在哪里
- 外部服务或第三方系统在哪里参与
- 流程结束时状态应该是什么
第二步：提炼动作，不要直接搬段落
PRD 里的文字通常不是标准流程描述。里面会有背景说明、原因解释、设计意图和业务约束。转流程图时，要把它们压缩成动作节点。
例如“当用户提交资料后，系统需要校验资料完整性，如果缺少身份证照片或授权书，则提示用户补充材料”，可以拆成三个节点：用户提交资料，系统校验完整性，资料不完整则提示补充。
节点要短，但不能短到失去业务含义。一个好的节点应该能说明谁做了什么，以及动作是否改变状态。
第三步：找状态变化和判断点
业务流程图最重要的是状态变化和判断点。例如订单从待支付到已支付，申请从待审核到已驳回，任务从待处理到已完成。
可以逐段检查 PRD：哪些动作会改变状态，哪些条件会产生分支，哪些失败情况需要兜底。判断点通常来自“如果”“当”“否则”“不满足”“失败”“超时”“驳回”等词。
这些判断点不要藏在节点备注里，应该成为流程图里的分支。
第四步：把异常路径单独处理
PRD 评审中最容易出问题的，往往不是主流程，而是异常流程。比如资料不完整、审核不通过、用户取消、支付失败、库存不足、权限过期、接口超时。
如果异常路径只有少量，可以放在主图旁边。如果异常路径很多，建议单独拆成异常流程图。主流程负责让大家看懂正常路径，异常图负责补齐风险。
第五步：流程图服务评审，但不能替代 PRD
流程图可以帮助团队快速理解业务路径，但它不能替代完整 PRD。字段规则、页面细节、权限说明、埋点、接口约束，仍然需要在 PRD 或附属资料里说明。
更好的方式是让流程图节点能回到原始需求。这样评审时看到某个判断点，可以快速追溯它来自哪一段需求、哪一次会议结论或哪条用户反馈。
NuromBoard 适合把 PRD、会议纪要、用户反馈和流程图放在一个项目里，流程图用于讨论，原始材料用于追溯。
常见错误：一张图承载所有需求
很多 PRD 流程图会失控，是因为一张图里同时放业务流程、页面跳转、接口调用、权限规则和异常处理。结果谁都看不清。
建议先画业务流程，再根据需要拆页面流程、异常流程和系统交互。每张图只解决一个层级的问题。
NuromBoard 适合什么样的 PRD 转流程图场景
NuromBoard 更适合需求还在整理和评审阶段的场景。它可以承接 PRD、会议记录、用户反馈和白板讨论，再辅助提炼流程。
如果你已经有清晰流程，只需要画规范图，普通制图工具就够用。如果你的流程还散在多份材料里，NuromBoard 的资料到结构工作流会更适合。
FAQ：PRD 转流程图常见问题
- PRD 转流程图一定要用泳道图吗？不一定。角色多、协作复杂时用泳道图；单角色流程用普通流程图即可。
- 流程图要画到多细？画到能支持评审、研发理解和测试用例拆分即可。
- 页面流程和业务流程要分开吗？建议分开。业务流程讲业务逻辑，页面流程讲界面跳转。
- AI 能从 PRD 生成流程图吗？可以生成初稿，但需要人工检查判断点、异常路径和状态变化。
- 流程图应该谁来维护？通常由产品经理维护，研发、测试、运营共同评审。
延伸阅读
- AI 流程图工具：看 AI 如何辅助提炼流程节点。
- PRD 转流程图：看 PRD 到业务流程图的具体路径。
- NuromBoard vs ProcessOn：继续比较制图工具和资料整理工作流。
