会议方法论提炼

---
name: 会议方法论提炼
description: 从会议录音转写稿中提炼关键人物（通常是老板/管理者）的方法论指导、工作标准和能力要求。为每个观点补充讨论背景（当时在讨论什么具体事项）和原话引用，输出结构化的 Markdown 文档到 Obsidian。当用户要求从会议记录中"提炼方法论"、"整理老板的要求"、"总结管理指导"、"提取工作标准"时使用。
---

# 会议方法论提炼

从会议录音转写稿中，提取关键人物的方法论指导和工作要求，为每个观点还原讨论背景，输出结构化文档。

## 适用场景

- 会议录音转写稿（已完成转写的 .md 文件）
- 会议纪要或文字记录
- 用户明确指定要提取某个角色（如老板、管理者）的方法论/指导内容
- 用户要求过滤掉其他人的汇报内容，只保留指导性发言

## 输入要求

1. **转写稿路径**：已完成转写的 .md 文件路径
2. **目标角色**：要提取谁的发言（通常通过 emoji 标识区分，如 🟥 = 老板）
3. **提取方向**：方法论指导 / 工作标准 / 能力要求 / 团队要求（可组合）
4. **输出位置**：默认输出到 Obsidian vault（遵循文档输出规则）

## 核心原则

### 区分方法论指导 vs 纯业务讨论

**要提取的（方法论指导）：**
- 可复用的工作方法（如"带假设做分析"、"谋定而后动"）
- 能力标准和要求（如"汇报三要素"、"产品经理三层能力"）
- 协作方法论（如"和业务沟通的正确起手式"）
- 思维框架和原则（如"量与质的取舍"）

**要过滤的（纯业务讨论）：**
- 具体的资源排期、版本时间、技术实现细节
- 对某个具体数据的追问和回复
- 纯粹的业务决策（如"这个功能先不做"）

**灰色地带的判断标准：** 如果一段话既涉及具体业务，又包含可复用的方法论，提取方法论部分，用业务内容作为"讨论背景"。

### 每个观点必须包含三层信息

这是本 Skill 的核心输出结构，**缺一不可**：

```markdown
### [观点标题]

**讨论背景：** [当时在讨论什么具体事项——谁在汇报什么、出了什么问题、
老板为什么要说这番话。2-4句话，让读者理解这个方法论是在什么场景下提出的]

> "[目标角色的原话引用，选最有力的1-2句]"

- [提炼出的方法论要点1]
- [提炼出的方法论要点2]
- [提炼出的方法论要点3]
```

**讨论背景的写作标准：**
- 必须具体到"谁在汇报什么业务/数据/方案"
- 必须说清楚"老板为什么要说这番话"（发现了什么问题、对什么不满、想强调什么）
- 不需要展开业务细节，只需让读者理解场景
- 2-4句话，简洁但信息量充分

## 执行流程

### 阶段一：识别角色和结构

1. 读取转写稿前 100 行，识别说话人标识（emoji）和角色分布
2. 确认目标角色的 emoji 标识（如果用户未明确指定，询问用户）
3. 统计转写稿总行数，规划分段策略

### 阶段二：并行分析（长文稿必须并行）

**分段规则：**

| 转写稿行数 | Agent 数量 | 分段方式 |
|-----------|-----------|---------|
| < 500 行 | 1 个 | 直接读取全文 |
| 500-1500 行 | 2 个 | 前半 / 后半 |
| 1500-3000 行 | 3 个 | 三等分 |
| > 3000 行 | 4 个 | 四等分 |

**每个 Agent 的任务 prompt 模板：**

```
读取 [文件路径] 的第 [起始行]-[结束行] 行。
这是一个会议录音转写稿，[emoji] 是 [角色名称]。

找出 [角色名称] 每段发言的讨论背景——即当时在讨论什么具体业务、
什么场景、什么问题时，[角色名称] 提出了方法论指导。

按时间顺序，对每段包含方法论指导的发言，输出：
1. 时间戳
2. 当时在讨论什么具体事项（2-4句话还原场景）
3. 原话中的关键方法论/要求（简要概括）
4. 最有力的原话引用（1-2句）

注意区分：纯业务讨论 vs 方法论指导。只需要方法论指导部分的背景。
```

**Agent 配置：**
- subagent_type: `analyst`
- 全部设为 `run_in_background: true` 并行执行
- 等待所有 Agent 完成后进入下一阶段

### 阶段三：归类与结构化

1. **合并**：将所有 Agent 的输出按时间戳排序，去重（不同分段可能在边界处重复提取同一段话）
2. **归类**：将方法论点按主题聚类，形成 3-8 个大类（如"数据分析方法论"、"汇报标准"、"业务协作"等）
3. **命名**：为每个大类起一个概括性标题，为每个观点起一个可独立理解的小标题
4. **排序**：大类之间按逻辑关系排序（通常：做事方法 → 汇报沟通 → 能力模型 → 协作要求）

### 阶段四：输出文档

**文档结构：**

```markdown
# [文档标题]

> 来源：[日期] [会议名称]（[时长]）
> 说明：[提取范围说明，如"仅整理老板的方法论指导和团队要求"]

---

## 一、[大类标题]

### 1. [观点标题]

**讨论背景：** [场景还原]

> "[原话引用]"

- [方法论要点]
- [方法论要点]

### 2. [观点标题]
...

---

## 二、[大类标题]
...
```

**输出路径：** 遵循文档输出规则，输出到 Obsidian vault 对应目录。

**文件命名：** 遵循 Markdown 命名规范（主题 + 内容类型，如 `产品团队工作方法论与能力标准.md`）。

## 质量标准

1. **背景不能缺失**：每个方法论点必须有讨论背景，禁止出现没有场景说明的孤立观点
2. **原话必须真实**：引用的原话必须来自转写稿原文，不能改写或编造
3. **过滤要干净**：纯业务讨论不应出现在最终文档中
4. **归类要合理**：同一主题的观点应归在一起，不同主题之间有明确边界
5. **可独立阅读**：每个观点段落应能独立理解，不依赖其他段落的上下文
6. **信息密度适中**：讨论背景 2-4 句话，方法论要点 2-5 条，原话引用 1-2 句

## 特殊处理

### 同一段话包含多个方法论

如果目标角色的一段长发言包含多个独立的方法论点，拆分为多个观点分别归类，而非堆在一个段落中。

### 方法论有递进关系

如果多段发言围绕同一个主题层层递进（如先讲原则、再举例、再总结），合并为一个观点，讨论背景覆盖完整的讨论脉络，原话引用选取最精华的部分。

### 转写稿质量不佳

如果转写稿中有明显的识别错误（如人名、专业术语），在引用原话时保留原文不修改，但在方法论提炼中使用正确的表述。