产品功能优先级决策
使用场景: 产品经理，决定下个 Sprint 做哪些功能
在路线图上吗？
├─ 否 → 能解除关键客户阻塞？ → 是：加入 Backlog / 否：拒绝
└─ 是 → 有需求规格吗？ → 否：打回设计
└─ 是 → 预估工作量 < 3天？ → 是：排期 / 否：拆解
这样组织的原因: "解除关键客户阻塞"这个分支为高优先级例外留了一个明确的入口，同时不让它变成默认路径。
真实案例
客服工单分流
使用场景: 客服团队，标准化首次响应路径
账号是否在有效期内？
├─ 否 → 发送重新激活链接 → 解决
└─ 是 → 是已知 Bug？
├─ 是 → 提供临时方案 → 如果严重则升级
└─ 否 → 复现问题 → 提工单或关闭
这样组织的原因: 把分流流程文档化为决策树，让客服不再依赖口口相传，平均处理时长明显缩短。
招聘决策框架
使用场景: 招聘经理，和面试小组对齐候选人评估标准
候选人是否满足必要条件？
├─ 否 → 拒绝
└─ 是 → 文化契合度强？
├─ 否 → 暂缓（与团队重新评估）
└─ 是 → 背景调查通过？
├─ 否 → 拒绝
└─ 是 → 发放 Offer
这样组织的原因: 让招聘标准显式化，减少面试小组之间的判断不一致——每个人都按同一套分支逻辑走。
基础设施故障响应
使用场景: On-call 工程师，按手册处理线上故障
服务是否在响应？
├─ 是 → 错误率升高？
│ ├─ 否 → 监控10分钟
│ └─ 是 → 检查最近发布 → 如需回滚则回滚
└─ 否 → 检查健康检查接口 → 重启 Pod 或升级处理
这样组织的原因: 故障期间决策树手册能减少认知负担——工程师跟着路径走，而不是在压力下即兴发挥。
个人财务决策
使用场景: 学生或职场新人，决定如何分配一笔意外之财
是否有高息债务（>7%）？
├─ 是 → 先还清债务
└─ 否 → 有3个月应急储蓄吗？
├─ 否 → 先建立应急储蓄
└─ 是 → 投资指数基金或养老账户
这样组织的原因: 简单的决策树同样适用于个人决策。结构让优先级一目了然，避免选择困难。
内容发布审批流程
使用场景: 市场团队，标准化内容审核流程
内容事实是否准确？
├─ 否 → 退回作者
└─ 是 → 符合品牌规范？
├─ 否 → 要求修改
└─ 是 → 需要法务审核？
├─ 是 → 送法务 → 审批后发布
└─ 否 → 发布
这样组织的原因: 把模糊的"找人签字"流程变成明确的检查节点。团队可以准确看到内容卡在哪个环节。
使用技巧
- 每个判断节点只问一个是/否或多选问题——复合条件会让树变得难以跟随。
- 每条路径都必须以明确的可操作结果结尾，如果某个分支终点是"进一步讨论"，说明决策还没准备好文档化。
- 分支标签写条件，而不是结果——"预算已审批"比"是"更清晰，尤其是有多个分支时。
- 大多数场景控制在四到五层深度以内，更深的树通常应该拆成两棵更小的树。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=decision-tree
使用这个决策树模板