框架升 v2：类型闸 + 三 lane 对等 + 一帖多颗 + 组件颗

- 颗为单位，一帖 = N 颗（可混 how/what/why）
- 三条对等 lane：How(目标+steps)/What(界定+构成)/Why(主张+依据+影响)
- 先判类型闸再成形，别默认 how、别硬造假 how
- what/why 既可独立成颗，也可作 how 的「组件颗」单列并 cross-ref 回所属 how 第 N 步
- 标签按类型分流（创作阶段/动作仅 how；作用域 how 逐步、what·why 颗级）

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

创作知识拆解框架.md

@@ -2,201 +2,145 @@
 
 ## 目的
 
-本文件是研究如何从帖子或者视频里面，拆解出合理的"创作知识"。
+从一帖创作内容（图文 / 视频）里，拆出 **N 颗**可复用的「创作知识」，每颗**按自己的类型（How / What / Why）成形**，收敛成 `POST /api/v1/knowledge/ingest` 的请求体；前端**一页多颗、按类型渲染**。
 
-1. **创作知识**
-   是指能够指导用户按照知识的思路和顺序流程，去创作好一个内容框架的知识。
-2. **制作知识**
-   我们要把创作知识与"制作知识"区分开来。制作知识是指生产内容时的流程工序，或者是针对具体品类内容的特殊流程、环节及具体的制作步骤等。
-
-> 一句话：我们只收**指导"怎么想、怎么判断、怎么搭框架"**的知识（创作）；剔除**指导"怎么执行、怎么操作、怎么做出来"**的知识（制作）。
+> 一句话边界：只收**指导"怎么想 / 怎么判断 / 怎么搭框架"**的知识（创作）；剔除**"怎么执行 / 怎么操作 / 怎么做出来"**的纯工艺（制作）。
 
 ---
 
-## 一、一颗知识的粒度：一个完整创作框架
+## 一、单位：颗
+
+- **颗** = 一条独立可交付、能被下游**单独检索复用**的创作知识。
+- **一帖 → N 颗**（可混类型），N 颗共享同一个 `source.id`。
+- **每颗 → 一个 ingest payload**。
 
-**一颗知识 = 一个完整创作框架** = 一个 `purpose`（把某种输入一路做成一个可交付成品）+ 一条**不可跳步**的 `steps` 链。**一帖通常只出 1-2 颗。** 绝不把框架内部的步骤 / 要点拆成独立知识。
+---
 
-- **判 step（不单列）**：①产出半成品 ②被同帖另一块当输入消费 ③拿走则本颗成品残缺。
-- **判独立颗**：①有自己的 purpose 句 ②产出能独立交付 ③脱离本框架换题材照样跑通。
-- **清单 / 导图型帖子**：一堆并列要素（N 选 1）是"一个 step 内的菜单"，压进所属 step，不按项数拆颗。
+## 二、三种知识类型 —— 三条对等 lane（不再有二等公民）
 
-> 这条是我们踩过坑后收敛的：早期把一帖拆成 5-6 个碎片是错的，碎片其实是同一个框架内部的步骤 / directive 细节。
+| 类型 | 它是什么 | 成形模板 | dim_attributes |
+|---|---|---|---|
+| **How** 工序 | 不可跳步地把某输入做成成品 | `目标(purpose)` + 有序 `steps`（每步 目的 / 怎么做 / 产出） | `how工序` |
+| **What** 构成 | 界定 / 列举某创作对象由什么组成 | `界定` + `构成要素[{要素, 说明}]`（**要素表**，无步骤） | `what构成` |
+| **Why** 原理 | 解释某做法 / 判断背后的道理 | `主张` + `依据` + `对创作的影响`（**论点卡**，无步骤） | `why原理` |
 
 ---
 
-## 二、How / What / Why 的关系
+## 三、拆颗顺序 —— how 先抽，what/why 都单列（含组件）
 
-**How 是骨架，What / Why 多数是骨架上的"节点性质"，不单独入库。**
+```
+这帖有没有"不可跳步的工序(how)"？
+├─ 有 → 抽 how 骨架（可能 1-2 个）→ 出 How 颗（工序表）
+│        ① how 步骤里嵌的 what/why → 既显示在步骤里，又【各单列成一颗】，
+│           标注「<how> 的组件 · 来自第 N 步」。
+│           （它是这个 how 的零件，但本身也是一条可复用知识）
+│        ② how 没覆盖到的、独立的 what/why → 也单列成颗（orphan 颗）
+└─ 没有 → 它本来就是一颗 What(界定/清单) 或 Why(原理)
+```
 
-- 一颗 **How 知识 = 一个完整框架**（purpose + 有序 steps），是**顶层入库单位**。
-- 框架里每个**步骤 / 产出节点**自带一个类型：
-  - 产出"一个有**构成**的东西"（如 爆款标题 = 痛点 / 对比 / 爽感）→ **What**
-  - "**按步骤**做出某物" → **How**
-  - directive 里"**为什么这样选 / 原理 / 标准**" → **Why**
-- 所以 **What / Why 绝大多数时候活在 How 框架的 `content` 里**（某步的产出类型 + 指引里的判断依据），不单独成条。
+**所以一帖 = N 颗 = `How 颗` + `它的 what/why 组件颗`（挂在该 how 上）+ `orphan what/why 颗`（可混）。**
 
-**例外（纯 What / 纯 Why 帖）**：有的帖子没有"怎么做"的工序，只是**列举 / 界定**（纯 What）或**只讲原理**（纯 Why）。这种没有 steps，套不进 purpose+steps，单独成一颗，用 §4.2 的**简化格式**。实践里大多数创作教学帖都能归到**一个 How 框架**。
+> 关键修正：how 内部识别出的 what/why **不是只留在步骤里**——它同时**单列成一颗可复用知识**，只是标明它是某个 how 的组件。how 之外的当然也单列。
 
-**一帖 → 多颗**：通常 1 帖 → 1 颗 How；偶尔含两条独立闭环 → 2 颗 How，或纯清单 / 纯原理 → 1 颗 What/Why。多颗共享同一个 `source.id`。
+**铁律**：
+- 没工序就**别硬造假 how**（把"7 种叙事结构"硬掰成 how 选型框架就是这个病）。
+- 一颗 = 一个完整东西，绝不拆成碎片。
 
 ---
 
-## 三、最终输出格式 = Ingest Payload
-
-知识最终**收敛成 `POST /api/v1/knowledge/ingest` 的请求体**（见《ingest-api.md》）。**How 知识的形态已定死**；What / Why 用简化版。
+## 四、什么样的 what/why 值得单列成颗（判据）
 
-### 3.1 How 知识 → 完整 IngestPayload
+对每块（步骤里嵌的、或 how 之外的）what/why 问：
 
-| ingest 字段 | How 知识填什么 | 来源 |
-|---|---|---|
-| `source.id` | `xhs_<content_id>`（同帖多颗共享） | 帖子 |
-| `source.{source_type,title,author,source_metadata}` | post / 原帖标题 / 作者 / {platform,url,date} | 帖子 |
-| `title` | 框架名（如"撕裂共识选题框架"） | 提取 |
-| `content` | **目标（=purpose）+ 步骤N（目的 / 指引 / 产出）拍平全文** | 提取（purpose+steps） |
-| `dim_creations` | `["创作"]`（写死） | — |
-| `dim_attributes` | `["how工序"]`（知识类型 How + 形态 工序） | 提取 |
-| `scopes` | `[{scope_type, value}]` 五棵树**带值**，整颗 = 各步 scope 值去重并集 | 提取（+回扣树） |
-| `custom_ext` | `{key:"业务阶段"}×N` + `{key:"创作阶段"}×N` + `{key:"动作"}×N`（创作阶段固定 5 词、动作每步提炼具体手法，str 多值） | 业务阶段 + 创作阶段 + 各步手法 |
-
-**示例（撕裂共识选题框架）：**
-```jsonc
-{
-  "source": { "id":"xhs_699308fa0000000016009697", "source_type":"post",
-              "title":"真正能爆的选题…", "author":"…",
-              "source_metadata": { "platform":"小红书", "url":"…", "date":"…" } },
-  "title": "撕裂共识选题框架",
-  "content": "目标：按「列共识→定失灵场景→撕裂裂缝写选题→用羞耻感验收」4步…\n步骤1（目的：分析，锁定赛道里被反复重复的正确共识）\n  指引：…\n  产出：…\n步骤2…",
-  "dim_creations": ["创作"],
-  "dim_attributes": ["how工序"],
-  "scopes": [
-    { "scope_type":"substance", "value":"赛道共识" },
-    { "scope_type":"effect",    "value":"撕裂共识" },
-    { "scope_type":"feeling",   "value":"羞耻感/冒犯" },
-    { "scope_type":"intent",    "value":"引爆传播" }
-  ],
-  "custom_ext": [
-    { "key":"业务阶段", "type":"str", "value":"选题" },
-    { "key":"创作阶段", "type":"str", "value":"定向" },
-    { "key":"创作阶段", "type":"str", "value":"构思" },
-    { "key":"创作阶段", "type":"str", "value":"成文" },
-    { "key":"创作阶段", "type":"str", "value":"打磨" },
-    { "key":"动作", "type":"str", "value":"列赛道共识" },
-    { "key":"动作", "type":"str", "value":"定失灵场景" },
-    { "key":"动作", "type":"str", "value":"撕裂共识写选题" },
-    { "key":"动作", "type":"str", "value":"羞耻感验收" }
-  ]
-}
-```
+> **脱离这个 how，它还独立成立、能被单独检索复用吗？**
+> - **是 → 单列成一颗**（组件颗：cross-ref 到所属 how + 第几步；orphan 颗：独立）。如"叙事弧线的五要素"——是某 how 第二步的产出，但本身是可复用的 what 知识 → 单列，并标"<叙事弧线故事设计框架> 组件 · 来自第 2 步"。
+> - **否（只是这一步一次性的指令、没复用价值）→ 只留在步骤里**，不单列。
+> - **N 选 1 的并列清单**：清单整体若是可复用知识（如"7 种叙事结构"）→ 单列一颗 What；否则压进 step 菜单。
 
-### 3.2 What / Why 知识 → 简化版 IngestPayload（本项目自定义）
+逐帖判，判据就这一条。
 
-**用同一个 ingest 信封**，只有三处不同：①`content` 不是工序而是"构成 / 原理"；②`dim_attributes` 换成 `what* / why*`；③`custom_ext` 只有 `业务阶段`（无 `创作阶段` / `动作`，因为没步骤）。`source / title / dim_creations / scopes` 都和 How 一样。
-
-| | What 知识 | Why 知识 |
-|---|---|---|
-| `content` | `界定：<一句话这是什么>` + `构成：- 要素1：… - 要素2：…` | `主张：<核心观点>` + `依据：<原理/标准/平台逻辑>` + `对创作的影响：<取舍含义>` |
-| `dim_attributes` | `["what构成"]`（或 what清单 / what界定） | `["why原理"]`（或 why标准 / why心法） |
-| `custom_ext` | `[{key:"业务阶段",…}]` | `[{key:"业务阶段",…}]` |
-| 其余 | 同 How（source/title/dim_creations=["创作"]/scopes 带值） | 同 How |
-
-**What 示例：**
-```jsonc
-{
-  "source": { "id":"xhs_…", "source_type":"post", "title":"…" },
-  "title": "短视频脚本三要素",
-  "content": "界定：一份短视频脚本的内容骨架由三类要素构成。\n构成：\n- 人物：谁出镜、出镜形象\n- 场景：室内 / 室外\n- 事件：整条脚本的故事内容",
-  "dim_creations": ["创作"],
-  "dim_attributes": ["what构成"],
-  "scopes": [ {"scope_type":"substance","value":"脚本要素"}, {"scope_type":"form","value":"分镜骨架"} ],
-  "custom_ext": [ {"key":"业务阶段","type":"str","value":"脚本"} ]
-}
-```
+---
 
-**Why 示例：**
-```jsonc
-{
-  "source": { "id":"xhs_…", "source_type":"post", "title":"…" },
-  "title": "标题决定打开，与内容质量无关",
-  "content": "主张：标题的唯一作用是让人有欲望点开；点不点开，和内容好不好没关系。\n依据：信息流里用户先看到的是标题，内容再好没人点开等于零（平台分发逻辑）。\n对创作的影响：把"起标题"当成独立的、第一优先的创作决策，而非内容概括。",
-  "dim_creations": ["创作"],
-  "dim_attributes": ["why原理"],
-  "scopes": [ {"scope_type":"effect","value":"吸引点击"}, {"scope_type":"intent","value":"提升打开率"} ],
-  "custom_ext": [ {"key":"业务阶段","type":"str","value":"选题"} ]
-}
-```
+## 五、创作 vs 制作边界（剔除）
 
----
+**收**（创作）：普适的创作路径 / 方法 / 工序、垂类技巧、形式偏好与禁忌——能一步步指导创作、**产出因人而异**。
 
-## 四、分类维度与归属（谁定的 / 落到 ingest 哪）
+**剔**（写进 `dropped`，附理由）：
+- **制作 = 纯工艺执行**：器材 / 光圈ISO / 打光 / 收音设备 / 剪辑软件操作 / 调色参数 / 导出压制。
+- **具体素材 / 案例本身**、**太空泛**（"内容要有吸引力"）。
 
-| 维度 | 取值 | 谁定的 | 落到 ingest |
-|---|---|---|---|
-| **知识类型** | What / Why / How | 下游系统（means_knowledge） | `dim_attributes`（how工序 / what构成 / why原理） |
-| **业务阶段** | 灵感 / 选题 / 脚本（固定 3） | **你** | `custom_ext`（key=业务阶段，多值） |
-| **创作阶段** | 定向 / 构思 / 结构 / 成文 / 打磨（固定 5） | **建议（可改）** | `custom_ext`（key=创作阶段，每步一个，多值） |
-| **作用域** | 实质 / 形式 / 意图 / 作用 / 感受（**带值**） | **你**（5 棵分类树） | `scopes`（scope_type + value） |
-| **创作 / 制作** | 写死 **创作** | 项目共识 | `dim_creations`（恒 `["创作"]`） |
-| **动作（手法）** | **开放 · 从帖子内容提炼的具体创作手法**（撕裂共识 / 塑三维人物 / 套三幕结构…），不锁词表 | **你**（决定放开） | `custom_ext`（key=动作，str 多值；ingest 自动生成语义向量 → 可语义检索，聚成"手法库"） |
+**关键边界（按"设计决策 vs 工艺执行"判，不看词面）**：景别 / 角度 / 构图 / 字幕 / 配乐 / 结构 = 把创意翻译成镜头语言的**设计决策** → 保留为 step；只有"拿方案去操作设备软件"那层 → 剔。
 
-**业务阶段判断标准（你定，固定 3）：** 灵感 = 帮助发现方向 / 素材 / 切口 / 洞察；选题 = 帮助判断写什么 / 拍什么 / 从哪个角度切入（标题也算选题）；脚本 = 帮助组织表达顺序 / 文案 / 镜头 / 结构。整颗框架常跨业务阶段，可多值。
+---
 
-**创作阶段判断标准（固定 5，建议版）：** 定向 = 定主题 / 方向 / 受众；构思 = 生成核心创意 / 钩子 / 角度 / 冲突；结构 = 搭骨架 / 大纲 / 顺序；成文 = 把结构写成具体文字 / 镜头；打磨 = 修改 / 精炼 / 优化 / 定稿。**逐步标**（每个 step 一个），与「业务阶段」分工：业务阶段是粗的业务环节，创作阶段是框架内每步的细工序位。**固定不开放**——开放留给「动作」（动作=具体招式、创作阶段=粗类别，两轴互补）。
+## 六、标签维度 —— 按类型分流（谁有谁没有）
 
-**作用域 5 类判别（带值时各给一个具体词）：** 实质=讲什么 / 形式=怎么呈现 / 感受=勾什么情绪 / 作用=起什么表达功能 / 意图=创作者图什么。**值要回扣到 5 棵树的现有节点（对得上就复用，对不上才新建）**，避免同义词污染（详见下一步"提取流程"）。
+| 维度 | How | What | Why | 落到 ingest | 谁定 |
+|---|:--:|:--:|:--:|---|---|
+| 知识类型 | ✓ | ✓ | ✓ | `dim_attributes`（how工序/what构成/why原理） | 下游系统 |
+| 业务阶段（灵感/选题/脚本，颗级多值） | ✓ | ✓ | ✓ | `custom_ext` | 我们 |
+| 创作阶段（定向/构思/结构/成文/打磨，**逐步**） | ✓ | ✗ | ✗ | `custom_ext` | 我们 |
+| 动作（开放手法，**逐步**，从内容提炼） | ✓ | ✗ | ✗ | `custom_ext` | 我们 |
+| 作用域（实质/形式/感受/作用/意图，**带值·回扣**） | ✓ 逐步 | ✓ 颗级 | ✓ 颗级 | `scopes` | 我们（回扣树） |
+| 创作 / 制作 | 写死 `创作` | 写死 | 写死 | `dim_creations`（恒 `["创作"]`） | 项目共识 |
 
-**动作（手法）为什么放开：** 创作的价值就在那个"具体招式"（撕裂共识 / 凿裂缝 / 塑三维人物），锁成抽象 5 词（决策/撰写…）会把最有信息量的东西抹掉。所以 `动作` 从帖子内容提炼、用帖子自己的语言；ingest 对 str 自动 embed，等于建一个可语义检索的"创作手法库"。代价是失去精确 enum 过滤——但对手法，语义搜 > 精确筛，划算（"在哪步、干什么"的导航由 `业务阶段` + `创作阶段` + `intent` 已覆盖）。
+> `创作阶段 / 动作` 是步骤级，只有 How 有；`作用域 / 业务阶段` 三类都有（What/Why 在颗级给）。
 
 ---
 
-## 五、拆解原则：创作 vs 制作的边界
-
-**收**（创作知识）：该类内容普适的创作路径 / 方法 / 工序、垂类技巧、形式偏好与禁忌——能一步步指导创作、且**产出因人而异**。
+## 七、作用域 5 棵树 + 回扣
 
-**剔除**：
-- **制作知识 = 纯工艺执行**——器材 / 光圈ISO / 打光 / 收音设备 / 剪辑软件操作 / 调色参数 / 导出压制（"拿着方案去操作设备软件实现它"）。如 §一 的「即梦 · 指定姿势」示例。
-- **具体素材 / 案例**——"此类内容具体讲什么"的内容本身。
-- **过于宽泛**——如"内容要有吸引力"，无法约束某个具体创作决策。
+| scope_type | 中文 | 管什么 | 例 |
+|---|---|---|---|
+| substance | 实质 | 讲什么（题材/对象） | 赛道共识 |
+| form | 形式 | 怎么呈现（结构/手法） | 三幕结构 |
+| feeling | 感受 | 勾什么情绪 | 羞耻感/冒犯 |
+| effect | 作用 | 起什么表达功能（段内干的活） | 撕裂共识 |
+| intent | 意图 | 创作者图什么（最终目的） | 引爆传播 |
 
-**关键边界（按"设计决策 vs 工艺执行"判，不看词面）：** 景别 / 角度 / 运镜 / 构图 / 字幕 / 配乐 / 时长 这些**名字像制作、实为"把创意翻译成镜头语言"的设计决策**，写在脚本 / 分镜表上 → **保留为框架内 step**；只有"拿方案操作设备软件"那层才剔除。
+- **互斥边界**（最易串味）：实质=对象 / 作用=干的功能（"赛道共识"实质，"撕裂共识"作用）；作用=手段 / 意图=最终目的（"制造悬念"作用，"引爆传播"意图）；感受=观众情绪 / 意图=作者目的。
+- **带值 + 回扣**：每个值用火山 embedding 找分类树最近邻——≥~0.90 复用树原名，否则保留新值（顺手丰富树）。回扣是代码（最近邻），模型只负责"起词"。
+- 粒度：How 逐步给；What / Why 颗级给。
 
-<details><summary>典型制作知识示例（对照用 · 即梦人偶姿势，原始 JSON）</summary>
+---
 
-**例：指定姿势·人偶姿势**——用「即梦」把 人物参考图 + 3D人偶姿势图 + 背景图 + 一段写死提示词，生成指定姿势成品图。绑定具体工具 + 写死物料 + 产出收敛 → 制作，剔除。
+## 八、提取流程 —— 多 prompt（长 + 窄）
 
-```json
-{
-  "id": "p4", "name": "指定姿势·人偶姿势",
-  "purpose": "以人物参考图+3D人偶姿势图+背景图三图联合输入，精准控制人物姿态与场景合成",
-  "category": "产物创造",
-  "steps": [ { "id":"s1", "via":"即梦", "action":"生成/元素生成", "effect":"主体生成",
-    "directive":"大透视图角度，人物比例合理", "substance":"人物", "form":"写实、低饱和、自然光" } ],
-  "tools_used": ["即梦"]
-}
-```
-</details>
+| 步 | 干什么 | 谁干 |
+|---|---|---|
+| **① 读懂** | 图 / 视频 → 文字（忠实，不判断） | 视觉 LLM（基建 extractor） |
+| **②a 判颗 + 找 how 骨架** | 几颗、各颗类型；how 抽骨架并识别内部 what/why 组件；orphan what/why；无 how 则纯 what/why（**第三节那道闸**） | 判断 LLM |
+| **②b 按类型成形 + 轻标签** | How→目标+步骤(+逐步 创作阶段/动作)；What→界定+构成；Why→主张+依据+影响；颗级业务阶段；组件颗标 cross-ref | 判断 LLM |
+| **③ 作用域** | 5 类带值 + 互斥边界 + 回扣（How 逐步 / What·Why 颗级） | 判断 LLM + 回扣工具(代码) |
+| **⑤ 组装 + lint** | 拼 payload（content 按类型不同、scopes 并集），校验 | 纯代码 |
 
 ---
 
-## 六、下游怎么消费（背景 · 与我们打标无关）
+## 九、最终格式 = ingest payload（三类字段差异）
 
-提炼出的知识进库后，由**脚本构建主 Agent 的「Knowledge」取数 subagent** 检索使用（只读、给候选、不写创作表）。主 Agent 构建脚本创作表分阶段：
+| payload 字段 | How | What | Why |
+|---|---|---|---|
+| `content` | 目标 + 步骤(目的/怎么做/产出) 拍平 | 界定 + 构成清单 | 主张 + 依据 + 对创作的影响 |
+| `dim_attributes` | `["how工序"]` | `["what构成"]` | `["why原理"]` |
+| `scopes` | 各步作用域并集 | 颗级作用域 | 颗级作用域 |
+| `custom_ext` | 业务阶段 + 创作阶段 + 动作 | **仅业务阶段** | **仅业务阶段** |
+| `source / title / dim_creations` | 三类一样（`dim_creations` 恒 `["创作"]`；组件颗在 custom_ext 或 content 里标明出自哪个 how 第几步） | | |
 
-```
-起步（全局） → 产生脉络（段落骨架/主维度） → 产生元素（子元素/从维度） → 将元素填入脉络（full_description）
-```
+---
+
+## 十、前端 —— 一页多颗、按类型渲染
 
-> ⚠️ 这里的"全局 / 产生脉络 / 产生元素 / 填入脉络"是**消费侧的 scope**（这条知识在脚本构建的哪个阶段有用），**和我们提取时打标的"作用域（实质/形式/感受/作用/意图，5 棵树）是两回事**，别混。下游消费时会逐条照录 step 的 intent / directive，不省略、不改写、不补具体场景。
+- 选一帖 → 列出**它的全部 N 颗**（可混类型）。
+- 每颗按类型渲染：**How → 工序表**；**What → 要素表**（界定 + 构成清单）；**Why → 论点卡**（主张 / 依据 / 影响）。
+- **组件颗** cross-ref 到所属 how（标"出自 <how> 第 N 步"，可互相跳转）；**orphan 颗**独立列出。
+- 每颗都带：**作用域回扣 drawer**（候选 → 最近邻 top-K → 复用/新建）、**提示词溯源**（区块/表头点开产出它的那道工序的提示词）。
 
 ---
 
-## 七、下一步：怎么一道流程把它提取准（待设计）
+## 十一、下游怎么消费（背景 · 与打标无关）
+
+入库后由「脚本构建主 Agent 的 Knowledge 取数 subagent」只读检索使用。主 Agent 构建脚本分阶段（起步 → 产生脉络 → 产生元素 → 填入脉络）。
 
-提准的杠杆（按性价比）：
-1. **回扣分类树（scopes 值的命门）**：判 scope 值时先从对应树检索候选节点，"对得上用现有、对不上才新建"，复用 Pattern 回扣 / match-paths 基建，避免造同义词污染 5 棵树。
-2. **Few-shot 金标**：给提示词一个"创作知识 → 完整 IngestPayload"的样例（API 文档只有制作例子）。
-3. **拆成聚焦小步**：①出框架+步骤(content) → ②创作/制作筛 → ③类型/阶段标 → ④scopes 值(带回扣)。避免一个大提示词全干（曾因复杂 schema 死循环）。
-4. **受控词表 enum**：业务阶段 3 选 / 创作阶段 5 选 / scope_type 5 选 / dim_creations 写死，消灭乱标。（`动作` 例外——不锁，从内容提炼具体手法，靠语义向量检索）
-5. **自检 / 对抗一遍**：查粒度（1 颗非碎）、directive 忠实（不编原文没有的例子）、scope 值合理。
+> ⚠️ 下游消费侧的"阶段"是**消费 scope**（这条知识在脚本构建哪个阶段有用），和我们提取时打的**作用域（实质/形式/感受/作用/意图，5 棵树）是两回事**，别混。
 
-*本文件为创作知识拆解 + 入库的设计依据，后续提示词与提取流程以此为准。*
+*本文件为创作知识拆解 + 入库的设计依据；`创作知识提取-skill/` 是它的可执行化。*