建议采用“四层存储、两阶段路由、一次编译”的结构

建议采用“四层存储、两阶段路由、一次编译”的结构
第一层：常驻宪法层

这里只放无论做什么都必须遵守的东西，例如：

安全边界；
文件不得丢失；
历史证据必须保存；
输出格式底线；
调用和权限规则；
什么时候必须停止、回滚或询问。

这层应该极小、稳定，而且只能放真正全局有效的规则。不要把“电影分镜的镜头规律”“小说对白优化技巧”这类领域知识放进来。

建议控制在几千 token 以内。这里宁可少，不要“感觉可能有用”就加入。

第二层：外部 Skill 注册表

七十个 Skill 全部保留，但不再把七十份描述交给主模型。每个 Skill 生成一条机器可读的 manifest：

id: novel-to-screenplay
domain: film_writing
task_type:
  - format_conversion
  - screenplay_adaptation

inputs:
  - novel
  - prose
outputs:
  - standard_screenplay

positive_triggers:
  - 把小说转成标准剧本
  - 保留剧情和对白
  - 输出场景标题和人物对白

negative_triggers:
  - 已经有剧本，只需改对白
  - 已经有剧本，只需生成分镜
  - 只分析剧情问题

preconditions:
  - source_text_exists

conflicts_with:
  - storyboard-generator
  - dialogue-polisher

dependencies:
  - screenplay-format-standard

runtime_core: core.md
references: references/
evidence: evidence/
version: 3.2.0
status: active

最重要的不是 description，而是：

它接收什么；
它产出什么；
什么情况下必须用；
什么情况下绝对不要用；
它和谁容易混淆；
它依赖谁；
它以前在哪些真实任务中成功或失败。

正例决定召回，反例和冲突组决定别选错。

第三层：Skill 执行胶囊

每个 Skill 不再只有一份巨大的 SKILL.md，而是拆成：

skill/
├── manifest.yaml       路由和版本信息
├── core.md             本次执行必须加载的核心规则
├── workflow.md         需要时才加载的完整流程
├── references/         专业知识、术语、标准
├── examples/           少量金标正例
├── evidence/           完整历史成功图、失败图、原始文件
├── scripts/            确定性代码和检查器
└── tests/              路由与执行测试

core.md 不是摘要，而是“最低可执行核心”。大多数任务先加载它；只有碰到对应步骤，才读取 workflow.md 或某个 reference。

这比“第一层简介、第二层摘要、第三层正文、第四层附件”更好，因为后者每次都要一层层询问和探索，增加多个串行步骤。Anthropic 也明确指出，运行时逐步探索虽然节省预加载上下文，但会比预计算检索慢；更合适的是混合模式：一部分提前检索，一部分按需读取。

第四层：历史证据仓库

成功图、失败图、补丁、旧版本、案例原文件都完整保存，但默认不参与普通路由，也不进入上下文。

它们只在以下情况启用：

当前任务匹配某个历史案件；
发生相同失败；
用户要求回溯；
验收模型需要寻找判例；
Skill 正在迭代升级。

这层就是你说的“U盘完整知识”，但它应该是证据仓库和回滚仓库，不能承担日常 Skill 路由。

四、路由器具体应该怎么跑

推荐按下面这条路径执行：

用户请求
   ↓
0. 精确命中与缓存
   ↓
1. 元数据硬过滤
   ↓
2. BM25 + 向量混合召回
   ↓
3. 正文级重排
   ↓
4. 置信度闸门
   ↓
5. 任务拆解与依赖排序
   ↓
6. 只加载选中的执行胶囊
0. 精确命中与路由缓存

重复任务根本不需要重新让模型思考。

例如用户最近十次说：

把小说转换成标准剧本格式，保留原对白。

前九次都命中了 novel-to-screenplay，第十次可以直接走路由缓存。只有输入类型、目标或限制发生变化时才重新检索。

缓存的不是最终答案，而是：

{
  "task_fingerprint": "novel_to_standard_screenplay_preserve_dialogue",
  "route": ["novel-to-screenplay"],
  "confidence": 0.98
}
1. 先做硬过滤，不要先做语义搜索

先根据确定性字段砍候选：

输入是图片、视频、文本还是压缩包；
输出是剧本、分镜、提示词还是审计报告；
当前属于分析、生成、验收还是打包；
Skill 是否支持当前模型和环境；
是否需要联网、图像工具或代码工具；
是否存在权限冲突。

七十个 Skill 经过硬过滤，通常可能只剩十来个。这个过程完全可以由普通代码完成，不需要大模型。

2. 混合检索，不要只用向量

剩余 Skill 同时跑两套检索：

BM25：擅长匹配“Seedance 2.0、人物替换、剧本格式化”这种精确词；
向量检索：擅长匹配用户换了说法但意思相同的任务。

然后融合结果，再送进重排器。Anthropic 的知识检索实验也发现，把上下文化向量检索与 BM25 结合，能显著降低检索遗漏；加入重排后效果进一步提升。

对 Skill 系统尤其重要，因为 Skill 名称往往很像，但正文中的具体工作边界、禁止事项和输入输出不同。

3. 用完整正文做精排，但只排少量候选

第一轮可以召回二十个，第二轮重排只读这二十个 Skill 的：

manifest；
核心正文；
正例；
反例；
冲突说明。

最后只留下前三个。

不要让重排器阅读所有历史附件和证据，那些属于执行阶段，不属于路由阶段。

4. 设置置信度闸门

不能永远固定 Top-3 全加载。

合理逻辑是：

第一名明显领先：
只加载第一名

第一、第二名非常接近：
加载两个路由卡，让执行模型裁决

任务明显包含多个阶段：
进入任务拆解

所有得分都低：
判定“现有 Skill 不足”，走通用模式

这样能防止系统为了保险，每次把三五个相似 Skill 一起塞进去，最后发生规则打架。

5. 多 Skill 任务先拆成原子任务，再组成 DAG

比如用户说：

把小说变成标准剧本，再出工业化分镜，最后编译成 Seedance 提示词。

不要把“影视创作全能 Skill”加载进来，也不要一次性打开所有电影类 Skill。应该拆成：

A 小说 → 标准剧本
        ↓
B 标准剧本 → 分镜脚本
        ↓
C 分镜脚本 → Seedance 提示词
        ↓
D 连续性与资产验收

每个阶段只加载自己的 Skill，阶段完成后保存结构化产物，下一阶段读取产物，而不是继承上一阶段所有规则。

2026 年一篇组合式 Skill 路由预印本就是“任务拆解—Skill 检索—依赖图组合”这条路线；它报告上下文消耗可下降 99% 以上，但同时发现任务拆解质量才是最大瓶颈。所以不能让模型无限自由拆解，最好有固定的输入输出类型和依赖关系约束