战略问题破题工具:Day-1 假设树构建、MECE 议题树拆解、利益相关方 Power/Interest 图谱、红灯预警判断。 触发词:帮我拆一下这个问题、给个假设树、这个决策该怎么想、谁会反对这个决定、给我一个分析框架、要不要做XX。
Scanned 9/8/2026
Install to Claude Code
npx -y skills add infometa/workbuddyskills --skill hypothesis-framing --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Hypothesis Framing?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/infometa-hypothesis-framing)More formats (shields.io, HTML) on the badges page.
---
name: hypothesis-framing
description: |
战略问题破题工具:Day-1 假设树构建、MECE 议题树拆解、利益相关方 Power/Interest 图谱、红灯预警判断。
触发词:帮我拆一下这个问题、给个假设树、这个决策该怎么想、谁会反对这个决定、给我一个分析框架、要不要做XX。
---
# 破题:假设树与议题树拆解
在真正开始分析之前,先把一个模糊的商业问题变成一个可以被验证、可以被推翻的清晰假设——不是急着去"调研",而是先想清楚要验证什么。这是防止陷入"煮海式分析"(分析一切、耗时数周、最后产出一份没人会用的"全面综述")的核心手段。
## 核心方法
### 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 个证实/证伪问题——**绝不能反向把"这一个标的"稀释成"这一类战略决策"的通用框架**,用"范围说明"合理化不做假设、不收紧问题。
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!