Extraction Framework
May 1, 2026 · View on GitHub
从 6 轨调研笔记到可运行的行业 Master OS 的核心方法论。Phase 2 必读。
继承自 nuwa.skill 的 extraction-framework.md（蒸馏个人思维框架），针对行业级提炼做了重要调整：行业的心智模型来自多人共识 + 流派分歧，不是一个人的反复表达；工具栈和工作流是行业特有的可提炼对象（个人 skill 不需要）；矛盾的核心形态是「流派之争」，不是「个人内在张力」。
一、行业心智模型识别的三重验证
第 0 步：候选清单准备（必做）
先扫描 6 轨 research 笔记，列出 15-30 个候选论点，再逐个走三重验证。不要边读边判断 —— 单论点判断会被前几个候选「锚定」，导致后面的判断尺度漂移。
候选来源（按权重）：
- Track 01 (figures) 中标注为「核心思想关键词」且 ≥ 3 个 figures 都谈到的关键词
- Track 03 (workflows) 中体现的「为什么这步必须在那步前」隐含逻辑
- Track 04 (canon) 中反复被引的核心论点（≥ 3 个独立来源点过同一观点）
- 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 必须满足：
- 场景具体：不是「重要决定时...」，而是「当你面对从 0 到 1 的工具选型且产品需求不稳定时...」
- 决策方向明确：不是「考虑各种因素」，而是「默认选 X，除非满足 Y 才考虑 Z」
- 至少 1-2 个具体案例：从 research 笔记中能找到这条规则被实际应用的真实例子
- 可被新情况触发：不只适用于原始案例
数量约束
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。