01 / 从真实资源开始
原模板与适用场景
适合产品经理整理团队协作方式，也适合项目启动时对齐交付边界。模板包含需求收集、优先级、原型、评审、开发、验收和上线反馈；可以按照团队规模合并角色，但不要合并掉关键决策。
在这份模板里，你能找到
- 确定需求优先级
- 需求评审
- 验收通过？
- 线上验收，记录反馈问题，修改或者下一版迭代
上述节点来自原模板。下面的改图步骤包含新增建议；预览图不会自动同步这些修改。
02 / 动手改图
按照这四步整理你的版本
从需求来源开始
把用户反馈、运营反馈和其他来源汇总为需求收集，再经过有效性判断和优先级排序。不要让每条反馈直接进入开发队列，否则图中缺少取舍机制。
明确评审输入与输出
评审前准备原型和需求说明，评审后输出可执行的范围。将不通过路径连回修改原型或补充需求，避免箭头只写“否”而没有落点。
拆开实现和验收
开发完成后分别核对需求与设计结果。若团队还需要技术验证，可以新增相应节点；它是团队定制，不要暗示原模板已经定义了完整发布控制。
把线上反馈接回计划
上线后记录问题并判断处理方式：进入修复、进入下一版或暂不处理。图上注明决策角色和记录位置，防止上线变成没有回路的终点。
03 / 对照检查
节点与分支应该怎样表达
| 项目 | 表达方式 | 核对重点 |
|---|---|---|
| 需求评审失败 | 回到需求或原型修改 | 保存本轮修改项 |
| 设计评审失败 | 回到设计调整 | 区分需求问题和实现问题 |
| 验收不通过 | 回到对应实现环节 | 注明未通过的验收项 |
| 上线后反馈 | 修复或下一版迭代 | 不要自动把所有反馈变为紧急任务 |
04 / 让 AI 帮你起稿
可以直接复制的 AI 绘图提示词
先复制下方文字，再打开 AI 绘图入口粘贴；把角色、条件和节点替换为你的实际情况。这段示例不会自动导入模板。
请画软件产品研发协作流程图。主线：收集需求→确认有效性→排序优先级→原型设计→需求评审→设计实现与评审→开发→产品和设计验收→发布→线上反馈。需求评审不通过回到原型修改，设计评审不通过回到设计，验收不通过回到对应实现环节。线上问题按修复、下版迭代、暂缓处理分流。为每个评审注明输入和负责人，负责人未知时标注待确认，不自行编造。
生成后逐条核对文字、层级与连线；需要保留原模板版式时，可直接使用模板编辑入口。
05 / 交付前复核
这些问题容易被忽略
- 把“需求封版”画成永远不能修改，却没有变更入口。
- 所有不通过都退回最开始，团队无法知道究竟要补哪份材料。
- 图上写了产品、设计、研发、QA，但关键验收节点没有主责角色。
用一个正常案例和一个异常案例从起点走到终点，再保存你的版本。不要只检查配色和对齐。
06 / 常见问题
使用前还想确认
小团队需要这么多泳道吗？
可以把兼任职责合并到同一泳道，但保留评审和验收节点。泳道数量取决于责任交接，而不是照搬大团队的岗位数量。
这张图能直接当发布规范吗？
不能自动等同。模板是协作起点，团队仍需补充自己的发布条件、负责人和故障处理约定，再按实际工作验证。
从这张模板开始，做成你的工作图
先确认节点，再调整分支，最后统一排版。
使用这个模板在线编辑 ↗
