问题定义与拆解
一句话：在解题上花的所有力气，都建立在"问题问得对不对"上——问错了，后面全白干。
> 运营研究学者 Russell Ackoff 说过：我们失败，更多时候不是因为给出了错误答案，而是因为解决了一个错误的问题。Charles Kettering（通用汽车研究实验室）也有一句常被引用的话：一个被陈述清楚的问题，已经解决了一半。
本技能只做三件事：把问题问对、把问题拆准、把优先级排出来。它不负责解题本身——那是后续动作。
> 纯推理框架：不联网、不读写敏感路径、不执行系统命令、不需要任何密钥。
一、何时使用 / 何时不用
立即使用
- 问题模糊：用户自己也说不清到底要什么
- 问题庞大：涉及多个变量，一眼望不到边
- 问题反复：试过几次都没解决，怀疑方向就错了
- 用户直接给了方案，但没说清要解决什么问题（先退回定义阶段）
- 用户明确要求：怎么想 / 从哪开始 / 帮我拆解 / 理一下 / 问题是什么 / 先别给方案
不要用
| 场景 | 原因 | 应该怎么做 |
|---|---|---|
| 纯执行任务（"把这个文件改名"） | 没有歧义，定义问题纯属浪费 | 直接执行 |
| 用户已给出清晰的问题定义和约束 | 重复劳动 | 直接解题 |
| 事实查询或需要实时数据 | 不涉及结构化拆解 | 直接回答 / 先检索 |
| 紧急救火（线上故障正在烧） | 时间不允许做完整定义 | 先止血，事后用本技能做根因复盘 |
| 纯创意发散（"给我 20 个点子"） | 需要广度不是结构 | 直接发散 |
输入不足时的行为（可靠性要求）
禁止在问题都没听懂时就输出一座漂亮的逻辑树——那是幻觉，不是分析。
- 先判断三件事是否已知：这是谁的问题？ 什么叫解决？ 有什么约束？
- 三者缺一时，只问最关键的 1 个问题（一次只问一个，不要连珠炮），并且带上你的默认猜测让用户确认，例如：
> "我猜这件事的成功标准是「3 个月内获客成本降到 100 元以内」，对吗？"
——给用户一个可以点头的选项，比让他从零回答容易十倍。 - 若用户说"你自己判断"或不补充：显式列出假设清单再继续，并在输出顶部标注「本次建立在以下假设上，若假设错了请告诉我，结论需要重做」。
二、先判定：这是哪一类问题
不同性质的问题，拆解方式完全不同。跳过这一步很容易用错工具。
用 Dave Snowden 的 Cynefin 框架与 Ralph Stacey 的复杂度矩阵做快速判定：
| 类型 | 特征 | 怎么解 | 拆解是否有效 |
|---|---|---|---|
| 清晰（Simple） | 最佳实践明确，因果关系所有人都看得见 | 感知—分类—响应，照 SOP 做 | 不需要拆，直接做 |
| 繁杂（Complicated） | 需要专业分析，因果关系存在但需专家才能看出 | 感知—分析—响应，找专家给方案 | 拆解非常有效 |
| 复杂（Complex） | 因果关系只能在事后回顾，答案会自己演化 | 试探—感知—响应，先做小实验再放大 | 可拆，但必须配实验验证，不能一次定死 |
| 混沌（Chaotic） | 没有可辨因果关系，此刻必须先稳定局面 | 行动—感知—响应，先止血 | 不要拆，先行动 |
| 无序（Disorder） | 不知道自己属于以上哪种 | 先分解到上面四类再各自处理 | 先做本判定 |
Horst Rittel 与 Melvin Webber 的「抗解问题」（Wicked Problems）还要额外警惕——如果你发现以下特征，说明这是抗解问题，不存在"最终正确答案"，只能持续管理：
没有唯一的问题定义、没有停止规则、解没有对错只有好坏、每个问题本质上是另一个问题的症状、每个尝试都是不可逆的一次性操作、没有可穷举的解集。
> 遇到抗解问题，目标要从"解决它"改成"把局面推向更好的方向"。
三、第一步：把问题问对（问题定义卡）
借用 Charles Conn 与 Robert McLean《Bulletproof Problem Solving》中的问题定义做法，产出一张问题定义卡，八项逐一填清：
| # | 要素 | 要回答什么 | 反面例子 → 正面例子 |
|---|---|---|---|
| 1 | 谁的问题 | 谁被这个问题困扰？谁会为结果买单？ | "公司有问题" → "华东区销售团队无法完成季度指标" |
| 2 | 决策者是谁 | 最终谁拍板？谁能说"这就算解决了"？ | 不清楚 → "由 CRO 在 6 月 30 日前拍板" |
| 3 | 成功标准 | 什么时候算解决？用什么数字衡量？ | "提升效率" → "工单平均处理时长从 4.2 小时降到 2.5 小时以内" |
| 4 | 时间范围 | 起点、截止、评估时点 | "尽快" → "2026 年 Q4 结束前" |
| 5 | 约束条件 | 预算、人力、合规、技术、不可动的东西 | 未说明 → "不增加 HC，不更换现有 CRM" |
| 6 | 已有什么 | 现有数据、前人做过什么、哪些已知结论 | 从零开始 → "已有 3 个月工单数据，去年做过一次失败的分流试点" |
| 7 | 缺什么 | 关键信息缺口在哪 | 没想过 → "缺各渠道工单的复杂度加权数据" |
| 8 | 不在范围内 | 明确划走什么 | 没划 → "本次不涉及客服话术培训体系" |
所有要素必须可证伪：写完请自检——"如果这个定义是错的，会怎样表现出来？" 说不出来，说明写得还不够具体。
一个问题陈述的合格句式
> 在 [约束条件] 下，为 [谁]，在 [时间] 内，把 [指标] 从 [现状] 改善到 [目标]，同时不改变 [边界]。
用 Barbara Minto 的 SCQA 也能快速检验序言是否成立：
S 情境（读者已知的背景）→ C 冲突（发生了什么打破平衡）→ Q 疑问（因此必须回答什么）→ A 答案（你的问题陈述）。
如果冲突不痛，说明这不是个真问题；如果疑问不成立，说明问题定义跑偏了。
四、第二步：把问题拆准（逻辑树）
三条铁律
- MECE（Mutually Exclusive, Collectively Exhaustive）：同一层的子项相互独立、完全穷尽。这是 Barbara Minto 的要求，也是唯一不可妥协的一条。
- 先结构后细节：每一层不超过 5±2 个子项，超过就再分一层或重新归类。
- 从假设出发，而不是罗列：Conn & McLean 强调以假设为驱动——每个分支应当是一个可被验证或推翻的陈述句，而不是一个名词（"成本问题" 是名词，"成本上升主要来自外包单价上涨" 才是假设）。
四种拆解切法
| 切法 | 适用 | 例子 | 易错点 |
|---|---|---|---|
| 结构法 | 按组成部分切 | 收入 = 流量 × 转化率 × 客单价 | 漏掉某个组成 |
| 流程法 | 按时间/步骤切 | 获客 → 激活 → 留存 → 变现 → 推荐 | 步骤之间重叠 |
| 二分法 | 切成 A / 非 A | 可控 vs 不可控；内部 vs 外部 | 二分不彻底，出现第三类 |
| 矩阵法 | 两个维度交叉 | 紧急×重要；影响×可行性 | 两个维度不独立 |
切不出来时的三个备选视角：
- 利益相关方视角：涉及哪些人/角色，各自的问题是什么
- 时空视角：发生在哪个环节、哪个时间段、哪个地点
- 5W1H：What / Why / Who / Where / When / How
拆解深度：什么时候停
满足任一即可停止下钻：
- 这个子问题已经有明确答案或已有数据可用
- 继续拆下去不改变任何决策
- 验证它所需的成本高于它的潜在价值
五、第三步：把优先级排出来
拆完 20 个分支，不等于要做 20 件事。用三层筛子：
筛子 1：帕累托（80/20）。 找出那 20% 的分支——它们决定了 80% 的结果。问：如果只能做一件事，做哪件？
筛子 2：影响 × 可行性矩阵。
| 可行性高 | 可行性低 | |
|---|---|---|
| 影响大 | 立刻做（Quick Win / 主战场） | 拆解后再评估（战略议题） |
| 影响小 | 有空再做（填充项） | 放弃（感恩节火鸡） |
筛子 3：ICE 评分（Impact 影响 / Confidence 把握 / Effort 成本），每项 1-10 分：
得分 = 影响 × 把握 ÷ 成本。按得分排序，取前 3。
排序时强制问一句：哪些子问题必须先解决，否则其他分支的答案算出来也没用？ —— 这是依赖关系，优先级要服从依赖。
最后给每个进入计划的子问题配一句："要验证/解决它，我需要拿到什么？" 这就是最小工作计划。
六、输出模板
## 问题类型判定
- 属于：[清晰 / 繁杂 / 复杂 / 混沌]，理由是…
- 是否抗解问题：[是/否]，依据是…
## 问题定义卡
> 在 [约束] 下，为 [谁]，在 [时间] 内，把 [指标] 从 [现状] 改善到 [目标]，同时不改变 [边界]。
| 要素 | 内容 |
|---|---|
| 谁的问题 | |
| 决策者 | |
| 成功标准 | |
| 时间范围 | |
| 约束条件 | |
| 已有什么 | |
| 缺什么 | |
| 不在范围内 | |
## 逻辑树
- 根问题：（一句话）
- 分支 A（假设句，不是名词）
- A1 …
- A2 …
- 分支 B …
- 分支 C …
- MECE 自检：同层是否重叠？是否有遗漏的第四类？
## 优先级
| 子问题 | 影响(1-10) | 把握(1-10) | 成本(1-10) | ICE 得分 | 依赖 | 结论 |
|---|---|---|---|---|---|---|
| A1 | | | | | 无 | 立刻做 |
## 最小工作计划
1. **[子问题]** → 需要拿到 **[什么数据/事实]** → 通过 **[什么方式]** → 预计 **[多久]**
2. …
## 本次假设与边界
- 假设：（若错则需重做）
- 待用户确认：
- 本拆解不适用于：
七、质量标准（交付前自检）
| 维度 | 检查点 |
|---|---|
| 问题是否被真正定义 | 成功标准是否是一个可验证的数字或状态？ |
| 是否对问题分类 | 有没有做过 Cynefin 判定？有没有误把复杂问题当繁杂问题？ |
| MECE | 每一层的子项真的不重叠、不遗漏吗？能否想出"第四类"？ |
| 分支是不是假设 | 分支是陈述句（可被验证/推翻）还是名词堆砌？ |
| 是否收敛 | 拆完之后有没有排优先级，还是把 20 个分支原样丢回给用户？ |
| 是否可执行 | 每个入选子问题都配了"需要拿到什么"吗？ |
| 边界诚实 | 假设、待确认项、不适用情形都写了吗？ |
八、反模式（出现即视为失败）
- 名词堆砌树：把问题拆成"成本、效率、人、流程"四个词就交差。→ 每个分支必须是可验证的假设句。
- 拆完不收敛：树很漂亮，但没有优先级，用户更懵了。→ 必须有三层筛选。
- 跳步解题：用户问"怎么做"，你直接给方案，从没确认过成功标准。→ 先退回定义阶段。
- MECE 走过场：既按渠道又按时间混着分，子项互相重叠。→ 一层只能有一个切分维度。
- 无限下钻：拆到第五层还在拆，分支细到无法行动。→ 满足停止条件就停。
- 对混沌问题做复杂分析：线上事故正在烧，你还让人填问题定义卡。→ 先止血。
- 纸上谈兵的完美定义：成功标准写得很美，但根本拿不到数据。→ 检查可验证性。
九、与其他技能的配合
- 需要多位专家立场交叉检验这个拆解 → 用
expert-roundtable（专家圆桌） - 已有一个方案，需要攻击性检验 → 用
decision-red-team（决策红队） - 拆解中引用了别人的论证，需要验证是否成立 → 用
reasoning-audit（论证质检） - 拆解结论需要向上汇报或写进文档 → 用
pyramid-expression（金字塔表达） - 子问题涉及完全陌生的领域 → 用
rapid-domain-mastery（快速掌握陌生领域）
