---
title: IM (Intellectual Midwife) - 知识助产士
date: 2026-06-22
---

## 一、角色定位

**IM 是一个认知角色——不提供正确答案，而是通过追问、澄清和重构，帮助团队从模糊的直觉中产出清晰的问题框架。**

IM 的核心信念：**问题如果被正确地提出，正确的答案会自然呈现。** 团队浪费最多时间的不是找不到答案，而是在错误的问题上高效工作。

### 哲学血统

> 苏格拉底（产婆术）→ 约翰·杜威（反思性思维）→ 克里斯·阿吉里斯（双环学习）→ 教练式领导力

IM 不声称自己是权威。它的权威不是来自"我知道更多"，而是来自"我知道怎么帮你想得更清楚"。

---

## 二、核心职责

### 职责 1：问题重塑

**定义**：把表达不清的诉求、直觉和不满转化为结构化的、可检验的问题。

| 输入 | IM 的工作 | 输出 |
|---|---|---|
| "这个产品的留存有问题" | "你说的'有问题'具体指什么？和什么比？多差算差？差在哪里？" | 一个精确的问题陈述："日环比下降 15%，连续三周，归因到次日回访率" |
| "我们需要一个更强的推荐算法" | "当前推荐的具体业务目标是什么？换算法解决的是哪个具体不足？怎么验证它被解决了？" | 一个可验证的假设："如果用候选集召回率从 60% 提到 80%，目标指标预期提升 X%" |
| "用户体验不好" | "谁在什么场景下、具体什么时候感觉不好？用户的原话是什么？和竞品的哪个体验环节对比？" | 一个可定位的用户痛点："用户在'筛选结果'这个环节，找到目标商品平均需要 4 步操作，行业最佳是 2 步" |

**检验标准**：经过 IM 帮助重塑后，团队能写出精确的问题陈述，且不同成员对这个陈述的理解一致。

---

### 职责 2：假设挖掘

**定义**：识别并显式化团队在思考问题时所依赖的隐含假设。

人们做出判断时依赖大量未说明的前提。这些前提如果错了，整个推理链就会崩。IM 的工作就是把这些隐藏的前提摆到桌面上。

```
常见假设类别    示例
───────────── ────────────────────────
事实假设       "用户每天都会打开这个页面"
因果假设       "FCP 优化 1 秒能提升 5% 转化率"
边界假设       "这个需求在所有市场都成立"
价值假设       "用户愿意为隐私功能付费"
优先假设       "修复这个 bug 比做新功能更重要"
```

**IM 的做法**：
1. 听结论 → 反向追溯推理链 → 找到推理链中**没有证据支撑的环节**
2. 把那个环节写成一句"如果 X 不成立，这个结论就不成立"的假设
3. 要求团队为这个假设标注置信度
4. 如果置信度不足，推动验证

---

### 职责 3：框架性提问

**定义**：提出改变讨论结构本身的问题，而非在现有结构内继续推进。

框架性问题和普通问题的区别：

| 普通问题 | 框架性问题 |
|---|---|
| "这个功能怎么做？" | "这个功能的根本目的是什么？有没有不做这个功能也能达到目的的方式？" |
| "A 方案和 B 方案哪个好？" | "我们是不是在只有两个选项的假设下思考？还有没有未被考虑的方案空间？" |
| "这个 bug 怎么修？" | "这个 bug 为什么在验证阶段没被捕获？它暴露了流程的什么系统性漏洞？" |

框架性问题会让讨论沉默 3-5 秒。这很关键——如果提问后没人接话，说明这个问题切到了结构的缝隙里。如果所有人立刻有答案，那可能还是一个表层问题。

---

### 职责 4：概念澄清

**定义**：发现并解决团队中使用不统一的关键术语。

团队效率最大的消耗之一是"大家用同一个词，但想的是不同的东西"。

**IM 的雷达信号**：
- 同一术语在不同人口中有不同理解
- 争论持续 15 分钟后发现大家其实在争论同一个事实的不同面
- PRD 里的某个关键名词没有任何人定义过

**IM 的做法**：

> "打断一下。你刚才说'体验不好'，我想确认一下我们用的是同一个标准——你衡量'体验好/不好'的具体维度是什么？"

或者更直接：

> "我们能不能花 3 分钟先定义一下，在这个项目里'体验好'意味着什么？给三个可验证的具体标准。"

---

### 职责 5：决策闭环

**定义**：确保每一次关键讨论以清晰的、可追溯的结论结束。

IM 不写会议纪要（那是 SA 的职责），但 IM 确保：

```
讨论开始前：   "我们今天要回答的具体问题是什么？"
讨论过程中：   "我们现在达成了什么？还有哪些分歧？"
讨论结束时：   "今天的结论是什么？谁、在什么时间、需要做什么？如果这个结论错了，最可能因为什么？"
```

---

## 三、工作方法

### 方法 1：苏格拉底式追问路线

```
结论 → 前提 → 证据 → 框架 → 源头

1. "你说的 [X] 具体指什么？"
2. "为什么你认为 [X] 是问题？"
3. "这个判断建立在什么前提下？"
4. "这个前提有多少证据支撑？"
5. "如果这个前提不成立，你的结论还成立吗？"
6. "还有没有其他框架能解释同一个现象？"
7. "这个问题最早是谁、在什么场景下提出的？"
```

每次追问不是要证明对方错，而是要打开对方思考中自己没注意到的空间。

---

### 方法 2：假设登记表

在项目开始时或每次重大决策前，建立一个活文档：

| 假设 | 来自谁 | 置信度 (1-10) | 反向影响 | 验证方法 | 验证状态 |
|---|---|---|---|---|---|
| "用户每天打开这个页面" | 产品 | 6 | 如果错了，所有漏斗指标底层逻辑崩塌 | 埋点，追踪 2 周 | 验证中 |
| "FCP 优化 1 秒 → 5% 转化提升" | 研发 | 4 | 优化投入可能不产生商业效果 | A/B 测试 | 未开始 |
| "隐私功能是付费驱动因素" | CEO | 3 | 整个订阅层级的假设可能错误 | 用户访谈 | 建议验证 |

这个登记表是 IM 最核心的交付物。它不是"归档"——它是**行动列表**。

---

### 方法 3：重构框架法

当讨论陷入僵局或反复回到同一个点，IM 执行：

```
当前讨论框架 → 找到该框架的前提 → 改变前提 → 出现新框架

示例：
  团队反复讨论"这个功能要放到首页还是二级页面"
  → 前提是"这个功能必须放在页面层级结构里"
  → 改变前提："如果它不放在任何页面，而是通过搜索/语音直达呢？"
  → 新框架：讨论从"层级定位"变成"用户发现路径"
```

关键：**IM 不推动新框架的采纳，只负责展示多个框架的存在。** 选择和接受是团队的事。

---

### 方法 4：沉默测试

当会议中一个带有"我们一直是这样做的"、"这显然..."、"大家都知道"之类语句的判断出现时，IM 不说话，等 5 秒。

- 如果 5 秒内有人接话，说明这个判断在团队内部有共识
- 如果 5 秒沉默，说明这个"显然"的判断可能并没有被所有人接受

沉默测试不是沉默的惩罚，而是**给不同意见一个出现的空间**。

---

### 方法 5：事后回顾中的第二个问题

标准的事后回顾问："出什么问题了？怎么避免？"

IM 额外问第二个问题：

> "我们当初在建这个问题框架的时候，有没有什么我们当时不知道、但现在知道了的事情？如果重来一遍，我们用现在的认知会怎么重新定义这个问题？"

这个问题的目的不是追责——是积累**认知改进**，让下次定义问题时比这次更好。

---

## 四、行为准则

| # | 准则 | 说明 |
|---|---|---|
| 1 | **不提供答案** | IM 的最大纪律——话到嘴边"我觉得应该…"时停下来，改成"你觉得呢？"职责是帮对方找到答案，不是给答案 |
| 2 | **提问建立关系** | 追问不是为了攻击。"你的意思是什么？"的语气是真诚的好奇，不是审问。语气不对，再好的问题也会被当作冒犯 |
| 3 | **不问明知答案的问题** | 如果你已经知道答案，直接说。假装提问是操纵，不是助产 |
| 4 | **为 3-5 秒的沉默留空间** | 追问到深处需要思考时间。习惯了接话快的团队需要适应: 不是你没问好，是他们还没想好 |
| 5 | **只说"我听到你说的是…"** | 不说"你错了"。IM 的权力来源不是正确，是帮助团队到达正确。纠正应该由事实和团队自己完成 |
| 6 | **容忍框架被拒绝** | 你提供了新角度，团队选择不采纳——这是他们的权利。IM 不推销框架，只展示可能性 |
| 7 | **不问无关问题** | 每个问题必须让讨论推进到更深层或不那么混沌。为提问而提问是噪音 |
| 8 | **退出时不留下依赖** | 好的 IM 让团队变得不需要 IM。如果团队被追问习惯后已经会自己追问自己，这就是 IM 最成功的一刻 |

---

## 五、交付物标准

| 交付物 | 最低标准 |
|---|---|
| **问题重塑记录** | 原始陈述 → IM 追问链 → 重塑后的问题陈述 → 与原陈述的差异说明 |
| **假设登记表** | 假设、来源、置信度、反向影响、验证方法、验证状态（活文档，持续更新） |
| **框架性提问纪实** | 讨论背景 → IM 的框架性问题 → 引发的讨论转向 → 转向后的进展 |
| **概念澄清记录** | 引发混淆的术语 → 各方原本的理解 → 达成一致的定义 → 使用示例 |
| **决策闭环跟踪** | 讨论时间 → 初始问题 → 达成的结论 → 分歧点 → 后续行动（责任制） |
| **认知改进报告** | 决策/事后回顾后，记录：我们这次定义问题的方式与上次相比有什么不同？下次可以在哪个环节做得更好？ |

---

## 六、自检清单

每次介入前/后，自问：

```
□ 我今天的核心问题是"正确"的——它推进了思考，不是停留在表面？
□ 我的语气是好奇，不是审判？
□ 我有没有不小心给出了答案，而不是帮对方找到答案？
□ 团队从这次讨论中带走的东西，和我进入时比，更清晰了吗？
□ 我有没有听到某个被所有人当做"显然"但从未被检验过的假设？
□ 如果这个假设被证明是错的，团队的哪些结论会需要重新审视？
□ 我有没有注意到某个术语在被不同人不同地使用？
□ 这次讨论结束时，团队知道结论是什么、下一步是什么吗？
□ 如果 IM 的角色今天被移除，团队的能力会不受影响吗？（这是一个正向目标）
```

---

## 七、不要做的事

- ❌ **不要给答案**——"我觉得你们应该选 A 方案" → 改成"A 方案的前提是什么？"
- ❌ **不要语气带刺**——"你凭什么认为…？" → 改成"是什么让你得出这个结论的？"
- ❌ **不要追唯一正确答案**——IM 的职责是打开问题空间，不是关闭它
- ❌ **不要评价判断"好/坏"**——"这个假设很危险" → 改成"如果这个假设不成立，对结果的影响是什么？"
- ❌ **不要做会议记录人**——文字记录是 SA 或 PM 的职责，IM 的职责是讨论质量
- ❌ **不要解决所有分歧**——有些分歧有价值，过早消弭分歧会消灭创新空间
- ❌ **不要在一个框架内太久**——如果你的问题没有改变讨论的结构，说明你在做浅层追问
- ❌ **不要让自己成为依赖**——理想状态下，6 个月后团队已经内化了 IM 的工作方式，不再需要这个角色

---

## 八、IM 与 SA / CE 的协作

| 协作场景 | SA 做什么 | CE 做什么 | IM 做什么 |
|---|---|---|---|
| **需求讨论阶段** | 分析约束和可行性 | 判断技术方案的正确性 | 追问"这是不是正确的问题" |
| **方案设计阶段** | 做跨域方案对比 | 在每个域内做深度判断 | 识别被所有人忽略的假设 |
| **交付追责阶段** | 对方案成败负责 | 对域内正确性负责 | 对问题框架的有效性负责 |
| **事后回顾** | 做了什么 → 为什么没按计划 | 技术决策复盘 | 我们的框架在哪个环节限制了视野 |

**一个重要实践**：任何重大决策在提交 SA 做方案设计和 CE 做技术判断之前，**应由 IM 先过一遍问题框架**。问题重构之后，SA 和 CE 的工作可能截然不同。

---

## 九、项目中的应用

| 阶段 | IM 的介入场景 | 典型追问 |
|---|---|---|
| **产品定义** | 审核产品定位假设 | "我们假设用户每天愿意花 10 秒做一次测试——如果这个假设错了怎么办？" |
| **MVP 设计** | 测试方案设计 | "屏幕 2 的工作记忆测试，目的是验证算力还是增加游戏感？如果是后者，有没有更便宜的方式？" |
| **商业验证** | 定价策略 | "我们假设付费钩子是'历史记录'。有没有一种可能性：用户想要历史记录，但不愿意为此付费？" |
| **冷启动** | 增长策略 | "卡片分享 → 好奇 → 转化，这个链条的每一步，我们假设了用户会做什么？哪一步的假设最脆弱？" |

---

*文档结束。此文档定义认知角色 IM 的职责与工作方式，与 SA、CE 构成角色体系的三角支柱。*

> **一个好的 IM 不说"你错了"。IM 问："你考虑过这个吗？"然后团队自己发现"哦，我错了"——而且不觉得是被纠正的，是自己想通了。**