软件发布流水线
使用场景: 开发者或 DevOps 工程师，负责管理代码部署流程
代码合并到主分支
|- 运行 CI 测试
| |- 失败 → 通知作者，终止
| |- 通过 → 构建产物
|- 部署到测试环境
|- 冒烟测试通过？
| |- 否 → 回滚，提 incident
| |- 是 → 部署到生产
这样组织的原因: 每个分支都明确写出失败时怎么处理，团队不用每次发版都重新讨论同一个决策。
流程图示例
下面这些案例展示了不同岗位的人怎样用流程图解决实际问题：有人用它规范审批，有人用它消除流程歧义，也有人用它让复杂的技术步骤变得可以共享。找一个接近你场景的版本，直接改就行。
真实案例
客服工单升级流程
使用场景: 客服 Team Lead，负责规范工单在不同层级之间的流转
收到工单
|- 一线客服能解决？
| |- 是 → 关闭工单
| |- 否 → 升级到二线
|- 二线能解决？
| |- 是 → 关闭 + 记录解决方案
| |- 否 → 升级到技术团队
这样组织的原因: 把升级路径画出来，避免"这个该谁处理"的反复沟通，平均解决时间明显下降。
新员工入职流程
使用场景: HR 经理，负责建立可复用的入职 SOP
Offer 接受
|- 发欢迎邮件 + 提 IT 需求
|- 入职当天设备是否到位？
| |- 否 → 反馈给 IT 负责人
| |- 是 → 开始入职培训
|- 岗位需要访问财务系统？
| |- 否 → 标准权限开通
| |- 是 → 先完成合规培训
这样组织的原因: 设备和系统权限的判断分支让同一张图可以覆盖不同岗位，不需要每个岗位单独维护一份 checklist。
预算审批流程
使用场景: 财务或运营团队，负责制定采购审批规则
提交采购申请
|- 金额 < 5,000 元？
| |- 是 → 部门主管审批
|- 金额 < 50,000 元？
| |- 是 → 总监审批
|- 金额 ≥ 50,000 元
| |- 需要 CFO 审批
|- 生成采购订单
这样组织的原因: 按金额分层的分支让申请人一眼就知道找谁审批，不需要每次询问行政或 HR。
用户注册流程
使用场景: 产品经理或开发者，设计用户认证页面
用户点击注册
|- 邮箱已注册？
| |- 是 → 提示"已有账号，去登录"
| |- 否 → 创建账号
|- 发送验证邮件
|- 24 小时内完成验证？
| |- 否 → 重新发送或过期
| |- 是 → 激活并跳转
这样组织的原因: 在写代码之前把重复邮箱、链接过期这类异常路径画出来，能提前发现 PRD 里的遗漏。
内容发布审核流程
使用场景: 内容策略师或编辑，负责管理多人协作的审稿环节
草稿提交
|- SEO 审核通过？
| |- 否 → 修改后重新提交
| |- 是 → 法务审核
|- 法务放行？
| |- 否 → 修改标记内容
| |- 是 → 安排上线时间
|- 内容上线
这样组织的原因: 线性 checklist 无法表达"审核不通过时从哪里重来"，流程图把返工路径画出来，写作者一眼就知道稿子卡在哪一步。
使用技巧
- 每个节点的文字控制在五个字以内，超过了说明这一步可能做了两件事，考虑再拆一个节点。
- 所有分支都要接到有名字的结束点，不要留悬空的箭头，否则读图的人会不确定流程到哪里结束。
- 统一图形语义：矩形表示操作，菱形表示判断，圆角矩形或椭圆表示开始和结束，不要混用。
- 异常路径旁边加一句短注释，说明为什么走这条路，否则读图的人不知道这是正常流程还是错误处理。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=flowchart
使用这个模板