# Extraction Framework — 行业 OS 提炼方法论

> 从 6 轨调研笔记到可运行的行业 Master OS 的核心方法论。Phase 2 必读。

继承自 [nuwa.skill 的 extraction-framework.md](https://github.com/alchaincyf/nuwa-skill/blob/main/references/extraction-framework.md)（蒸馏个人思维框架），针对**行业级提炼**做了重要调整：行业的心智模型来自多人共识 + 流派分歧，不是一个人的反复表达；工具栈和工作流是行业特有的可提炼对象（个人 skill 不需要）；矛盾的核心形态是「流派之争」，不是「个人内在张力」。

---

## 一、行业心智模型识别的三重验证

### 第 0 步：候选清单准备（必做）

**先扫描 6 轨 research 笔记，列出 15-30 个候选论点**，再逐个走三重验证。不要边读边判断 —— 单论点判断会被前几个候选「锚定」，导致后面的判断尺度漂移。

候选来源（按权重）：
1. Track 01 (figures) 中标注为「核心思想关键词」且 ≥ 3 个 figures 都谈到的关键词
2. Track 03 (workflows) 中体现的「为什么这步必须在那步前」隐含逻辑
3. Track 04 (canon) 中反复被引的核心论点（≥ 3 个独立来源点过同一观点）
4. Track 01 中明确的 figures 间分歧 → 双方各自的核心主张都要进候选

输出：一份 `synthesis-candidates.md`（位于 skill 内 references/synthesis/ 下）。每个候选包含：论点摘要、出现来源（≥ 2 处具体引用）、是该行业的还是通用的（初判）。

候选 < 15 → 信号薄弱，要么补 research，要么进入冷僻领域协议。
候选 > 30 → 重复 / 雷同太多，先合并同类项再走三重验证。

### 一个论点要被认定为**行业心智模型**而非「这一行某人的随口一说」，必须通过三重验证：

### 验证 1: 跨场景复现

同一个思维框架出现在这个行业的至少 **2 个不同子场景 / 应用领域**，并且至少 **2 个独立的 figures** 都用过它。

例：「LLM agent infra」中的「framework 是临时的，能力是永恒的」——
- 出现在 framework 选型场景（Harrison Chase 谈 LangGraph 取代 Chains）
- 出现在 evaluation 工具选型场景（Lance Martin 谈 LangSmith 也在被原生 capability 蚕食）
- 出现在 multi-agent orchestration 场景（多个工程师吐槽 framework 抽象失效）
→ 跨 3 个子场景 + 4 个独立从业者都说过 → 真正的行业心智模型

**关键差别 vs 个人 skill**：个人 skill 只要这个人**自己**反复说就够；行业 skill 必须是**多人共识**——一个人单独的看法只能算「{某人}的视角」，不能上升到行业 OS。

### 验证 2: 有生成力

用这个模型可以推断这个行业的资深人对**新问题**的可能立场。

例：如果「framework 临时性」是真心智模型——
- 面对「2026 年新出的 ReAgent 框架要不要采用？」→ 业内人会先问「它能在一个周末被剥掉吗？」
- 面对「该不该自建 prompt 优化 pipeline？」→ 会先评估「6 个月后这个能力会不会被模型 native 化」
- 面对「应该投资哪个 agent SDK 创业公司？」→ 会先看护城河有没有跨过「能力 vs 抽象」的边界
→ 能生成跨场景推断 → 真正的行业心智模型

### 验证 3: 有排他性

这个模型**只在这一行（或这一行 + 临近行业）特别成立**，不是放之四海而皆准的通用商业道理。

反例：「关注用户体验」「先做 MVP」「数据驱动」这些是**所有行业**通用的商业道理，写进任何行业 master skill 都没用——它们没有揭示这个行业的独特性。

正例：「framework 临时性」对**正在被模型能力曲线快速吃掉的层**特别成立——LLM agent infra / prompt engineering tools / RAG framework 都适用，但对「医疗器械研发」「足踝外科」就完全不成立。**有特定的适用边界 = 有排他性**。

→ 不是所有聪明人都会这样想，这是**这一行**的视角。

### 评级规则

每个验证给一个状态：
- ✅ **PASS**：完整满足
- ⚠️ **PARTIAL**：勉强满足或附带条件（例：跨场景但跨人物只有 1 人；生成力存在但不区分行业；排他性仅在「程度」上成立而非「质」）
- ❌ **FAIL**：不满足

**PARTIAL 处理规则**（iter 4 新增）：
- 验证 1（跨场景复现）的 PARTIAL → 视作 FAIL 处理（多人共识是行业 OS 的最低门槛，不能让步）
- 验证 2（生成力）的 PARTIAL = 「能生成但不区分行业」 → 视作 FAIL（generic 商业道理冒充行业洞察是这一类）
- 验证 3（排他性）的 PARTIAL = 「行业放大版的通用道理」 → 进入心智模型节，但**描述必须明确捕捉「放大程度」+「在通用版本上的特化」**，否则会失去排他性。这是唯一可以 PARTIAL 通过的验证

| 三重组合 | 评级 | 处理 |
|---------|------|------|
| ✅✅✅ | 行业心智模型 | 进入 SKILL.md 心智模型节，3-7 个之内 |
| ✅✅⚠️（验证 3 PARTIAL） | 行业放大版心智模型 | 进入心智模型节，描述强制捕捉放大程度 |
| 任一 ❌ + 其他 ✅ ≥ 2 | 决策启发式 | 进入 playbook 节，作为「如果 X 则 Y」规则 |
| ≤ 1 ✅ | 行业八股 / 通用道理 | 不进入 skill，最多在 glossary 解释 |

---

## 二、标准 Playbook 的提炼

= 行业内的「快速决策规则」。表述为「**如果 {场景}，则 {行动方向}**」。

### 提炼来源

- **Track 03 工作流**：现成的 SOP 步骤里隐含着「为什么这步在那步前」——展开就是 playbook
- **Track 01 figures**：top figure 在长访谈中说过的「我做这种决定的标准是 X」
- **Track 04 canon**：经典著作 / 论文里反复被引的「{N} 条 rules」

### 质量门槛

每条 playbook 必须满足：

1. **场景具体**：不是「重要决定时...」，而是「**当你面对从 0 到 1 的工具选型且产品需求不稳定时**...」
2. **决策方向明确**：不是「考虑各种因素」，而是「**默认选 X，除非满足 Y 才考虑 Z**」
3. **至少 1-2 个具体案例**：从 research 笔记中能找到这条规则被实际应用的真实例子
4. **可被新情况触发**：不只适用于原始案例

### 数量约束

5-10 条。少于 5 条说明提炼不够；超过 10 条说明没区分主次 / 重复。

### 反模式

- ❌ 「先做 MVP 再迭代」（通用道理，不是行业 playbook）
- ❌ 「重要决策要谨慎」（无操作意义）
- ❌ 「我朋友说...」（个人轶事不是 playbook）

---

## 三、工具栈与选型决策树提炼

行业 skill 独有的提炼对象（个人 skill 没有）。

### 三层结构

| 层 | 标准 | 来源 |
|----|------|------|
| **必备**（≥80% 从业者用） | 至少 3 个独立 source 都点过 + GitHub stars / 行业 survey 数据印证 | Track 02 + Track 04 |
| **场景特化**（特定子方向用） | ≥2 个 source 提到「在 X 场景下 Y 优于通用方案」 | Track 02 + Track 01（figures 实际用什么） |
| **新兴 / 实验**（近 12 个月） | 必须标注「{date} 起出现」+ 「{N} 个早期采用者」 | Track 02 + Track 05 |

### 选型决策树的提炼方法

不要列「工具 A 适合 X，工具 B 适合 Y」这种没有比较维度的清单——那是**目录**，不是**决策树**。

**决策树**的形态：

```
你的核心问题是什么？
├── 快速验证一个想法（demo 阶段）
│   └── 用 {薄框架} — 理由：{1-2 句}，反例：用过 {厚框架} 的踩坑案例
├── 已有 PMF，需要 production-grade 稳定性
│   ├── 主要瓶颈在 {场景 A} → 用 {工具 A1}
│   └── 主要瓶颈在 {场景 B} → 用 {工具 B1}
└── 已经规模化，问题在 {特定瓶颈}
    └── 多数行业人选择 {工具 X} + 自研 {组件 Y}
```

每个分支必须能从 research 笔记追溯到证据（「Harrison 在某 podcast 说过...」/「3 个 YC 公司选 X 的 case study」）。

### 避坑清单

从 Track 04 / 05 / 01 中提取「业内人吐槽过的常见错误选型」。每条形态：「不要用 X 做 Y，因为 {原因}」。

---

## 四、工作流提炼

### 入门 SOP vs 资深路径的区分

Track 03 提供的工作流通常混杂了入门 vs 资深，提炼时分开：

- **入门 SOP**：完成一个最小完整任务的最少步骤。3-7 步走完。每步问「这步如果跳过会发生什么？」——必须有具体后果才进入 SOP。
- **资深路径**：业内 5+ 年从业者会跳过 / 优化哪些步骤，**为什么**。资深的判断力体现在「知道什么时候可以省」，不是「知道全部步骤」。

### 时效性标注（重要）

工作流是 **master skill 衰减最快的部分**。每个工作流模块必须标注：

```
[Workflow updated 2026-04 — driven by {model release / tool change / regulatory change}]
```

下次 update 大师 X 时，这个标签是判断「这一节要不要刷新」的锚点。

### 近期变化提取

从 Track 03 / 06 提取「近 12 个月内工作流变了什么」。常见触发：
- 新模型 / 新工具能力让某步骤可以省略 / 自动化
- 法规 / 标准变化让某步必须新增
- 行业事件让某种实践被证伪 / 被替代

每条变化标注：触发事件 + 变化前 vs 变化后 + 当前采用率（如果 research 里有数据）。

---

## 五、表达 DNA — 行业风格

行业 skill 的表达 DNA **不模拟某个具体的人**，模拟「这一行的资深人聚一起讨论时的 register」。

### 维度

| 维度 | 提取方法 |
|------|---------|
| 高频用语 | 从 Track 01 长访谈中抽 ≥ 5 个 figures 的话，找重叠的高频词（出现在 ≥ 3 人以上） |
| 黑话 / 缩写 | 从 Track 06 取 top 20，按出现频率排序 |
| 严肃 register | 看 conference talk / 长 podcast 的口气 — 不是 Twitter 短稿 |
| 内 vs 外沟通差异 | 内部（同行间）允许 X 缩写 / Y 隐喻，对外（解释给非从业者）会展开 |
| 外行破绽 | 从 Track 01 figures 吐槽 / Track 04 入门书反复纠正的 misconceptions 反推 |

### 关键约束

- **不要单一模仿某个 figure 的口气**——那是 nuwa.skill 的工作。master skill 是「这一行的资深人」，多人融合
- **不能太学术**：除非这是个学术行业（如「计算神经科学」）。多数行业的资深人在长 podcast 里口语化得很
- **不能太营销**：行业人之间互相讲话不会用「赋能」「闭环」「生态」这种 PPT 话术

---

## 六、矛盾处理 — 流派分歧

行业的核心矛盾形态是**流派之争**，不是个人内在张力。

### 三种行业矛盾

| 类型 | 例 | 处理 |
|------|----|------|
| **流派分歧** | LLM 范式：autoregressive vs diffusion；agent 框架：thin (PydanticAI) vs thick (CrewAI) | 在「智识谱系」节明确列出流派，标各自代表人物 + 核心主张 + 当前势力对比 |
| **代际分歧** | 老一代和新一代对同一个问题的不同看法 | 标注「{date} 之前」vs「{date} 之后」 |
| **未解争议** | 行业内还没共识的开放问题 | 在「诚实边界」节标注「这个问题尚无共识」，不假装有标准答案 |

### 错误处理方式

- ❌ 选一派忽略另一派（让 skill 变成偏见放大器）
- ❌ 编一个调和的解释（「其实大家都对」是没营养的废话）
- ❌ 用「平均值」掩盖分歧（行业人讨论时不会回避分歧）

---

## 七、信息不足时的处理

| 情况 | 处理 |
|------|------|
| 某 track 来源 < 5 条 | 在 SKILL.md 该节顶部标注「Track {N} 信息有限，本节为推测」 |
| 只有二手转述（无 primary source） | 降低置信度，每条标「据 {source} 报道」 |
| 流派之间无独立验证 | 并列呈现，让用户自行判断 |
| 行业刻意不公开（如对冲基金、军工） | 在「诚实边界」明确说「这一行的核心实践不公开。本 skill 仅基于公开材料，可能漏掉关键内容」 |
| 中文 / 英文圈 source 严重失衡 | 在「locale」字段标注实际覆盖度，建议补另一边 |

---

## 八、时效性维度

行业 skill 各部分**衰减速度不同**。Phase 3 写 SKILL.md 时给每段加 `last_updated` 锚点，Phase 0C 更新时按这张表决定刷哪几段：

| 模块 | 衰减速度 | 建议更新频率 |
|------|---------|------------|
| 心智模型 | 极慢 | 1-2 年 |
| 标准 playbook | 慢 | 6-12 月 |
| 智识谱系 | 慢 | 6-12 月 |
| 表达 DNA | 慢 | 6-12 月（除非行业本身在快速专业化） |
| 工具栈 | 快 | 3-6 月 |
| 工作流 / pipeline | 快 | 3-6 月 |
| 信息源（Track 05） | 中 | 6 月，主要是 newsletter/podcast 的存活率 |
| 知识正典 | 极慢 | 1-2 年（新经典出现的频率） |

诚实边界节必须明确写：「本 skill 的工具栈 / 工作流模块衰减最快，建议 3-6 月跑一次 `update 大师 {slug}`」。

---

## 九、Agentic Protocol 推导

Phase 2.9 的输出。Phase 3 SKILL.md 的核心可执行段。

### 核心问题

「这一行的资深人，面对一个**新问题**时，会按什么维度去做功课？」

### 推导路径（从心智模型反推）

每个心智模型隐含一组「这个模型让人**首先关注**什么」。把这些关注点凝结成研究维度。

例（LLM agent infra）：
- 心智模型：「framework 临时性」→ 关注「这个层会不会被模型能力 native 化」→ **研究维度：模型能力近 6 月迭代轨迹 + framework 抽象的对应位置**
- 心智模型：「production reality vs demo glamour」→ 关注「这个工具在真实生产用了没」→ **研究维度：production case studies + 工程师的 incident retrospectives**
- ...

### 维度数量

3-10 个，按行业复杂度调整：
- 简单行业（窄 + 工具少）：3-5 个
- 标准行业：5-7 个
- 复杂行业（宽 + 工具栈多 + 流派多）：7-10 个

### 每个维度必含

- **看什么** — 具体到能否被搜索动作触发
- **在哪看** — 具体 source 而非「网上搜」
- **输出格式** — 1-2 句结构化结论，便于 Step 3 调用

---

## 十、质量自检清单（Phase 4 用）

### 心智模型
- [ ] 数量在 3-7 个之间？
- [ ] 每个模型有跨场景证据 + 跨人物证据？
- [ ] 每个模型有明确的适用边界 + 局限？
- [ ] 模型之间有张力或互补，不是同一观点的复述？

### 标准 Playbook
- [ ] 数量在 5-10 之间？
- [ ] 每条是「如果 X 则 Y」的形式？
- [ ] 每条有 1-2 个具体案例？
- [ ] 不是行业八股 / 通用商业道理？

### 工具栈
- [ ] 必备 / 场景化 / 新兴 三层都有内容？
- [ ] 选型决策树有清晰分支 + 证据？
- [ ] 避坑清单 ≥ 3 条？

### 工作流
- [ ] 入门 SOP 和资深路径分开？
- [ ] 每个工作流节有 last_updated 锚点？
- [ ] 近 12 个月变化部分至少有 1 条？

### 表达 DNA
- [ ] 读 100 字盲测能识别为这一行的人写的？
- [ ] 没有过度模仿某个 figure 变成 caricature？
- [ ] 黑话使用恰到好处（不滥用 / 不刻意回避）？

### 矛盾处理
- [ ] 流派分歧明确列出（如果存在）？
- [ ] 没有为了「统一」而抹平实际分歧？

### 诚实边界
- [ ] ≥ 3 条具体局限？
- [ ] 信息源失衡 / 中英文覆盖差异已标注？
- [ ] 衰减最快的模块给了 update 建议？

### Agentic Protocol
- [ ] 维度数量按复杂度合理（3-10）？
- [ ] 每个维度有「看什么 / 在哪看 / 输出」三段？
- [ ] 维度从心智模型反推得来，不是通用「搜索相关信息」？

### 整体
- [ ] 用这个 skill 看一个新问题，能得到「这一行的视角」而非「通用 AI 视角」？
- [ ] 不是 figures 原话拼凑，而是行业 OS 的运行？
- [ ] 删掉 industry 名字后，还能看出这是哪一行？

---

## 附：版本演化建议

每次 `update 大师 X` 写 changelog 时，按以下分类记录变化：

- **NEW**: 新增的工具 / 流派 / 工作流变化
- **CHANGED**: 心智模型 / playbook 的修正（注明原因 + 证据）
- **DEPRECATED**: 已过时的工具 / 工作流，保留作为历史参考
- **REMOVED**: 完全错误或失效的内容（罕见，仅当原版有事实错误时）

避免无意义的 patch（「补错别字」「换排版」）混进 changelog。
