逻辑树状图
Logic tree
把复杂问题拆成层级分支，使问题结构清晰可讨论。
复杂问题有多个部分，需要明确拆分口径和调查顺序时使用。分别整理原因、方案或指标，不把不同问题混在同一层。
一个明确的顶层问题、拆分规则，以及各分支的记录或未知项。
问题结构、证据缺口和可执行的调查任务。
先理解，再动手
使用步骤
先确定中心问题与拆分口径，再逐层拆解原因或解决路径。同一层尽量互不重叠、覆盖完整；原因树和行动树不要混用，每个叶节点给出证据或验证问题。
- 01
把核心问题写在顶端
- 02
按同一拆分标准展开第一层分支
- 03
继续拆到可分析或可行动的层级
- 04
检查分支是否重叠、遗漏或层级混乱
树形结构本身不能证明因果或完整性。同层分支检查重叠、遗漏与粒度；若统计数量，说明每条记录如何归类。
看清框架结构
从一份空白提纲开始
复制到你的文档，填入真实的业务事实与判断。
查看空白提纲
逻辑树状图 · 空白提纲 什么时候用：复杂问题有多个部分，需要明确拆分口径和调查顺序时使用。分别整理原因、方案或指标，不把不同问题混在同一层。 需要准备：一个明确的顶层问题、拆分规则，以及各分支的记录或未知项。 预期产出：问题结构、证据缺口和可执行的调查任务。 使用边界：树形结构本身不能证明因果或完整性。同层分支检查重叠、遗漏与粒度；若统计数量，说明每条记录如何归类。 工作问题： 期望结果： 已有证据与假设： 未知项与下一项核查： 填写说明：写一个明确的问题或目标。 1. 中心问题： 填写说明：每行一条路径，用 > 分层，不重复中心问题。例如：交付 > 拣货 > 库存差异；支持多条路径。 2. 分支路径： 填写说明：逐条对应叶节点记录事实、假设与下一步核查。 3. 证据与验证： 检查清单 □ 树状结构围绕一个明确主题展开。 □ 同层分支分类口径一致。 □ 末端节点能转化为调查、判断或行动。 考虑下一个框架 五问法（5 Whys）: 已经选定一个有事件记录的原因分支时，再用原因分析逐层核查解释，得到证据和未验证假设。 https://bizthinkframe.com/zh/frameworks/the-5-whys BizThinkFrame · https://bizthinkframe.com/zh/frameworks/logic-tree
跟着案例走一遍
虚构教学案例按首个记录阻碍拆解20单迟发
组织、人物、数据和结果均为虚构，仅用于说明框架用法。
背景与问题
原创虚构案例：门店一周承诺发出100单，20单错过承诺发出日。每单只按首个记录阻碍分类一次；同一订单仍可能有其他原因。
20单迟发有不同阻碍，需要整理调查方向，不能把部门名称和原因混在同层。
手头有哪些材料
- 20单的首个记录阻碍：库存确认8单、地址澄清5单、截止时间理解4单、揽收变化3单。
- 依据为订单日志、库存查询、地址字段、客户消息、时间戳与承运通知；均为虚构教学记录。
如何使用这个框架
- 使用同一分类规则，每单只计一次，8+5+4+3=20。
- 将每条分支连接到可追查记录，不把首个阻碍当成唯一根因。
- 库存分支数量最多，可作为调查起点；仍结合紧急性和影响选下一项核查。
得到四条范围清楚的调查分支，数量合计20；尚未完成原因验证或改善。
正文和图形均使用同一组20单迟发记录：8+5+4+3=20，每单按首个记录阻碍计一次。该规则不表示每单只有一个原因，分类也不证明根因。
什么时候先不要继续画分支
复杂问题有多个部分，需要统一调查结构时可以用逻辑树。顶层问题要让每个子项都能回答其中一部分。“新用户在激活前停在哪里”与“激活率为什么下降”不同；状态拆分可以定位差距，还不能解释进入这个状态的原因。
三种情况先暂停：顶层把诊断和偏好的方案混在一起，例如“怎样加提醒来解决激活”；同层数量重叠，却说不清每条记录如何归类；分支只有部门名称，没有可观察的问题。这时先修问题和分类规则，增加层级只会把模糊放大。
画得整齐仍可能遗漏重要路径。计数分支要写出别人可以复用的归类规则；无法归类时保留未知项。定性分支写清包含与不包含什么，不假装穷尽。数量小但影响严重或时限紧的分支也可能优先，不自动选择最大的一枝。
拆分不等于解释
按尚未解决的问题选择方法。箭头向下并不使一棵树自动成为因果模型；它可以只是调查安排。
| 方法 | 回答什么 | 需要守住什么 |
|---|---|---|
| 逻辑树 | 哪些部分需要调查 | 同层规则一致，缺口明确 |
| KPI树 | 指标怎样组合 | 等式、单位和窗口成立 |
| 5 Whys | 一个事件分支怎样解释 | 每层连接有证据 |
| 用户旅程图 | 体验过程中发生什么 | 用户范围明确，观察与猜测分开 |
完整案例：定位激活差距，不先指定原因
这是独立的虚构产品案例，与上方延期订单图形不同。W0和W1是两批不同的新账号，各120个，均已观察完整七天。激活定义为七天内建立工作区并保存第一个任务。两批资格与事件定义不变，虚构练习包中全部记录都能归类。真实数据使用前必须重新核实这些前提。
每个账号只按第七天的最终状态归类一次：未验证账号；已验证但没建立工作区；已建立工作区但没保存首个任务；已激活。在本案例给定的顺序下四类互斥，不是页面浏览或点击的分项次数。W0依次为12、12、24、72；W1为24、18、24、54，两批各合计120。
先问期末状态分布在哪里不同。W0激活率72/120＝60%，W1为54/120＝45%，下降15个百分点；相对W0下降25%，不是相对下降15%。两批人不同，分支差额不能说成同一批用户从漏斗里倒退。
| 第七天最终状态 | W0 / W1账号数 | W1减W0及下一项核查 |
|---|---|---|
| 未验证 | 12 / 24 | +12；查送达与验证记录，不先认定送达失败 |
| 已验证、无工作区 | 12 / 18 | +6；查进入路径与错误记录 |
| 有工作区、无首个保存任务 | 24 / 24 | 0；仍需比较体验，不能直接说路径没变化 |
| 已激活 | 72 / 54 | −18；确认结果差距，不解释原因 |
| 全部合格账号 | 120 / 120 | 0；先核对资格与窗口完整性 |
把分支差异变成可以复查的调查
算术上，多出的18个未激活账号可由未验证增加12个、验证后无工作区增加6个对应起来。但这不能证明邮件送达或工作区设计造成下降。渠道构成、需求不同或测量缺陷都可能影响状态分布；24对24也不能证明底层体验完全相同。
建议先核对事件完整性，再比验证时序与工作区入口记录。调查表保留批次归属、事件定义和观察终点。后续若发现账号重复或窗口未满，应重建数量，而不是保住原来漂亮的树。没核查实际阻碍与适用同意条件之前，不把“多发提醒”当作既定解法。
拉通会里，每个叶子写一个问题、要查的来源、拟负责人和复查条件；负责人和日期要实际确认。支持、反证与未解释记录分开追加。某类事件足够具体后再用5 Whys追查，若用户材料指向体验顺序，就转旅程图。能指向可观察的下一项核查，树就有价值，不必提前给出最终原因。
检查你的思考
再问自己几个问题
- 第一层分支采用的分类标准是什么？
- 每个分支之间是否互相独立？
- 拆到哪一层才足以支持行动或判断？
完成前的检查清单
- 树状结构围绕一个明确主题展开。
- 同层分支分类口径一致。
- 末端节点能转化为调查、判断或行动。