date: 2026-08-16 tags:
- AI
- Skill
- 上下文工程
- 智能体工程 aliases:
- Skill 写满了怎么办
- 大型 Skill 重构
Skill 写满以后怎么办——从知识堆积到渐进式加载
最近我在用 AI 处理 报销时，遇到了一个很有意思的问题。
我明明已经把报销单的抬头字段、固定值和常用规则告诉过 AI，它却又开始问我：这个字段填什么？那个选项选哪个？
我当时的第一反应是：
你的 Skill 呢？怎么现在这么能问了？
往下检查才发现，问题不是 Skill 里没有知识，恰恰相反：知识太多了。
这个 expense-concur-ibm/SKILL.md 已经接近当前 100KB 的限制。PDF 分拣、报销单创建、滴滴录入、公司卡处理、退票、OCR、附件上传、DOM 定位、异常恢复……几乎所有细节都被不断追加进一个主文件。
它已经不再是一份使用说明，而像是一个没有索引的知识仓库。
文件变大，不只是容量问题
当 SKILL.md 不断变大时，最明显的后果是迟早会撞上文件或上下文限制。但比容量更值得警惕的，是 AI 的行为开始变得不稳定。
重要规则被细节淹没
“抬头字段有固定值，不要再问用户”是一条影响交互方式的核心规则。它如果与几百行 DOM 选择器、PDF 文件判断和异常处理混在一起，即使它真实存在，也不等于它能在正确时机发挥作用。
每次都加载了无关知识
当前任务可能只是录入一笔滴滴费用，AI 却同时读取了退票、公司卡、OCR 和所有异常处理规则。这些知识并非错误，只是没有必要在这一刻全部进入工作记忆。
新规则只能继续堆在尾部
当主文件没有清晰边界时，每次复盘的最快做法都是“再加一段”。短期看似在持续沉淀，长期却会形成规则重复、表述冲突和条件失效。
所以，“Skill 写满”并不是把上限调大就能解决的问题。它是一个架构信号：这个 Skill 承担的职责太多，知识已经失去了可导航性。
主文件应该是路由器
我更认可的结构，是把 Skill 分成三层。
第一层：触发元数据
YAML 头部只负责说清楚：什么情况下应该加载这个 Skill。
它不应该变成工作流的超长摘要。它的任务是帮助 AI 在正确的任务中找到这个 Skill。
第二层：SKILL.md 路由器
主文件保留六类内容：
- 核心原则；
- 全局硬规则；
- 统一工作流；
- 按任务类型加载知识的路由表；
- 安全、停止和确认边界；
- 验收要求。
读完主文件后，AI 应该知道“现在该做什么、要去哪里读细节、什么情况下必须停止”，而不是已经记住所有业务细节。
第三层：按需加载的 references
具体知识按完整主题拆分，例如 PDF 分类、滴滴录入、公司卡、退票、OCR、附件和 DOM 定位。
当任务是滴滴费用时，只读滴滴流程、字段映射和附件规则；当任务是退票时，再加载退票相关内容。
这才是渐进式加载：不是丢掉知识，而是让知识在正确的时候出现。
什么必须留在顶层
拆分大文件最容易犯的错，是把所有内容都移走，只留下一张看似整齐的目录。
这样虽然让主文件变小了，却可能让最重要的行为约束失效。
我的判断原则是：
凡是“每次执行都必须知道”的规则，留在主文件；只在某类任务中需要的细节，移到 reference。
例如，Concur Skill 顶层至少应保留这些规则：
- 提出澄清问题前，先查阅已有的用户偏好和默认规则；
- 已有固定值、能从材料提取、能从页面确认的信息，不得再询问用户；
- 创建或编辑费用明细时，必须加载抬头字段映射；
- 页面状态和 reference 冲突时，先检查 DOM 和上下文；
- 只有真正会改变结果、且无法通过现有证据确定的分支，才询问用户。
详细的九个字段值可以放在 report-header-fields-map.md 里，但“遇到抬头字段必须读它”这条指针必须留在主入口。
拆分是一次行为重构
如果只是按标题把大段内容搬到不同文件，最终可能只是得到一堆更难发现的碎片。
一次可信的 Skill 重构，至少需要完成五件事。
一、建立原内容清单
先记录主文件的字节数、行数和标题结构，再建立“原章节 → 新文件”的映射表，防止某条不显眼的规则在拆分中被静默删除。
二、先定义行为测试
在修改前，用几个具体请求记录 AI 当前会怎么做：它是否会重复询问固定值，是否能找到专项 reference，是否会在冲突场景中越界。
测试的不是文档语法，而是 Skill 最终有没有改变 AI 的行为。
三、按完整主题迁移
不要把每个小标题都拆成独立文件。一个 reference 应该能独立回答一类完整问题。
四、建立直接路由
主文件的加载表要直接说明“当前任务、必须读取、按情况读取”。所有重要 reference 都应该能从 SKILL.md 直接找到，不要依赖多层跳转。
五、用原场景做回归
重构后不能只看 SKILL.md 从 100KB 降到了多少。还要检查所有引用是否存在、原章节是否都有新归属、是否存在孤立 reference，以及最重要的用户场景是否仍然按预期执行。
文件变小只是手段，AI 行为变得更准确、稳定，才是结果。
不立即再造一个元 Skill
这次复盘还带来一个问题：要不要再写一个“专门解决 Skill 写满”的 Skill？
我的答案是：可以，但不必立即做。
如果一个方法只在当前 Concur Skill 上验证过，直接将它升级为全局 Skill，很容易把偶然经验误当成通用规则。
更稳妥的路线是：
- 先沉淀一份可复用的通用执行提示词；
- 在报销、数据模型、项目记忆等 2～3 个不同场景试跑；
- 记录哪些步骤稳定通用，哪些只适用于某种 Skill；
- 再把已验证的流程升级为精简的
refactor-large-skillsSkill。
这样可以避免一个有些讽刺的结果：为了治理 Skill 膨胀，又创建了一个继续膨胀的元 Skill。
真正要沉淀的是知识导航
过去我容易把 Skill 理解为一本持续补充的手册：每遇到一个新问题，就往里增加一条规则。
现在我更倾向于把它看成一个小型的知识系统。
知识系统的价值，不在于收藏了多少内容，而在于能否在正确时机，把正确规则送到正在执行的任务中。
当 Skill 写满时，我们不应该继续问“还能往哪里塞”，而应该问：
这些知识，是否还能在需要它的时候被准确地找到？
这才是从“知识堆积”走向“智能体工程”的分水岭。
关联阅读：[[如何把一个塞满的 SKILL.md 拆成路由器——可直接执行的教程]]、[[把塞满的 SKILL.md 重构成路由器——通用执行提示词]]
评论