# Hypothesis Framing

> 战略问题破题工具：Day-1 假设树构建、MECE 议题树拆解、利益相关方 Power/Interest 图谱、红灯预警判断。 触发词：帮我拆一下这个问题、给个假设树、这个决策该怎么想、谁会反对这个决定、给我一个分析框架、要不要做XX。

- Skill: `infometa/hypothesis-framing` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add infometa/hypothesis-framing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/infometa/hypothesis-framing/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: infometa (https://skillmd.com/u/infometa)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/infometa/hypothesis-framing

---


# 破题：假设树与议题树拆解

在真正开始分析之前，先把一个模糊的商业问题变成一个可以被验证、可以被推翻的清晰假设——不是急着去"调研"，而是先想清楚要验证什么。这是防止陷入"煮海式分析"（分析一切、耗时数周、最后产出一份没人会用的"全面综述"）的核心手段。

## 核心方法

### 1. Day-1 假设树构建

面对任何战略问题，第一步不是"去调研"，而是先给出一个具体、可证伪的 Day-1 答案，再拆成 2-3 个支撑性子假设，每个子假设配一个"能杀死它的测试"。

**流程**：
1. 把用户原始表述收紧成一句具体、有边界的治理性问题（例如"要不要进欧洲市场"收紧为"要不要在FY26 Q3以PLG方式进入英德中小企业市场"）
2. 索要或提出 Day-1 答案——如果用户能给出直觉判断，直接采用；如果说"不知道"，推他给一个哪怕是弱的猜测，没有猜测就无法设计出高效的验证测试
3. 拆解 2-3 个支撑性子假设——必须是"如果为真，顶层假设就成立"的载重命题，不是无关的话题分支
4. 为每个子假设分配置信度（高/中/低），优先验证低置信度分支——信息价值最高
5. 设定整体反转条件：什么样的综合结果会让人放弃 Day-1 假设

**输出格式**：

```markdown
## Day-1 假设树

**治理性问题**：[收紧后的问题]
**Day-1 假设**：[一句话，具体，可证伪]

├─ 子假设1 [置信度：高/中/低]
│  └─ 验证测试：[具体分析方法、数据来源、什么结果会杀死它]
├─ 子假设2 [置信度：高/中/低]
│  └─ 验证测试：...
└─ 子假设3 [置信度：高/中/低]
   └─ 验证测试：...

**优先验证**：[哪个子假设先测，为什么]
**整体反转条件**：[什么综合结果会让人放弃Day-1假设]
**红灯预警**：🟢 无预警 / 🟡 1个维度亮红灯需关注 / 🔴 2+维度亮红灯，建议不做
```

### 2. 议题树 vs 假设树的选择

议题树拆解的是"问题空间"（用于还不知道该看什么维度的阶段，穷尽列出所有可能相关的子问题，暂不下结论）；假设树承诺的是"一个答案"（用于已有强烈直觉、想高效验证的阶段）。

判断当前处在哪个阶段再选对工具：如果连方向感都没有，先做议题树；如果已经有倾向，直接上假设树。两者互补——通常先做议题树摸清问题的完整范围，再在某个分支上做假设树高效验证一个具体方向。跳过假设树、只停留在议题树阶段，是战略分析拖延数周却拿不出决定性结论的常见原因。

详细的 MECE 拆解流程与检验方法见 `references/mece-and-issue-trees.md`。

### 3. 利益相关方图谱

把决策相关的人放进 Power（能否否决这个决定）× Interest（在乎不在乎这个结果）四象限：

```markdown
## 利益相关方图谱

| 关键人 | 角色 | 象限 | 立场 | 关注点 | 本周行动 |
|--------|------|------|------|--------|---------|
| ... | ... | 高权力高关注/高权力低关注/低权力高关注/低权力低关注 | 拥护者/支持者/中立/怀疑者/阻力者/未知 | ... | ... |

**破局顺序**：先说服[谁]，才能推动[谁]，最后由[谁]拍板
```

立场标注要诚实——如果所有人都写"支持者"，说明没有认真盘点，不是真的一致。

### 4. 红灯预警判断

当多个关键假设同时指向负面信号时，直接说"不建议做"，而不是给一个模糊的"可以再评估看看"。

红灯判定标准（任意两条同时满足即亮红灯）：
- 需求不真实或优先级过低
- 缺乏切入路径（无关系人脉/甲方自己能做/竞争壁垒过高）
- 商业模式测算不成立（天花板太低/无法复制/定价困难）
- 时间窗口已过

## 注意事项

- **"我想调研一下欧洲市场"不是假设，是意图**。必须逼出一个具体答案才能继续。
- **子假设数量控制在 2-3 个**。超过 3 个说明顶层假设本身没想清楚，需要重新收紧治理性问题。
- **验证测试必须能"杀死"分支，不能杀死的不是测试**。"再多访谈几个客户"不是测试；"访谈10个客户，7个以上说价格是最大障碍就杀死该分支"才是测试。
- **不要因为情绪高涨就软化红灯判断**。如果证据指向"不该做"，就直说，附上唯一能翻转判断的具体条件。
- **"因未指明行业/标的，故只给框架+判断标准"是伪破题，等同拒绝立假设**。面对针对具体标的的治理性问题，正确动作是先用行业锚定基准（标 [E]/[A]）给出**带阈值的具体 Day-1 假设**（例："假设该供应商采购占我方营收 >30% 且近 3 年涨价超 CPI 2 倍，则收购 NPV 为正"），再配可杀死它的 3 个证实/证伪问题——**绝不能反向把"这一个标的"稀释成"这一类战略决策"的通用框架**，用"范围说明"合理化不做假设、不收紧问题。