滴滴面试官问我：你 SKILL.md 全塞进 context 了？

有个学员去面滴滴，前面聊得挺顺。他写过一个 Claude Code 的 Skill，讲得头头是道。

然后面试官问了一句看起来很基础的话。

「你这个 Skill 装上之后，那个 SKILL.md 文件，是一次性全部读进 context 的吗？」

学员想都没想：「对啊，装上就加载进去了，Claude 才知道这个 Skill 是干嘛的。」

面试官没接话，停顿了两秒，笑了一下，把笔放下。

「那我问你——我装 30 个 Skill，每个 SKILL.md 写两三千字，是不是开局还没说话，context 就被这些文件塞满了？」

学员愣住了。

他说那一刻他突然意识到，自己用了一个月的 Skill，居然从来没搞懂它最核心的机制是什么。

第一个误区：SKILL.md 不是一次性全塞进去的

面试官还没停，掏出手机翻到 Anthropic 官方文档，转过来给他看。

「人家不是全量加载的，是 Progressive Disclosure，渐进式披露。分三级，启动时只加载 metadata，正文按需加载，资源文件让模型自己用工具去读。你连第一步都搞错了。」

学员后背一凉。

说实话，我听完他的复盘，自己也愣了一下。因为我一开始也是这么以为的——Skill 装上就等于加载进上下文了。后来仔细看了文档才发现，Anthropic 的设计比这聪明得多。

它分三级。

第一级：Metadata。 就是 SKILL.md 最上面那段 YAML，里面就两个核心字段：name 和 description。这段东西有多大？每个 Skill 大约 100 token。你装 30 个，也就 3000 token，对于动辄 20 万 token 的上下文窗口来说，几乎可以忽略。

第二级：正文。 SKILL.md 的正文部分。这部分平时根本不在上下文里，停在硬盘上。只有当用户发来的请求命中了某个 Skill 的 description，Claude 判断「这个任务跟这个 Skill 相关」，它才会去把正文读进来。

第三级：资源文件。 references/、scripts/ 目录里的东西。这些更不会自动加载，是 Claude 主动用工具去读的——读到才进上下文，不读就不进。

坦率的讲，我第一次看到这个设计的时候，觉得这 TM 也太优雅了。

metadata 是常驻的、廉价的。正文是按需的、一次只进一两个的。资源是主动读取的、体积几乎没有上限的。三级各司其职，每一级只在恰当的时机花恰当的 token。

那 description 怎么写，Claude 才能准确触发

面试官接着追了第二问。

「metadata 里就 name 和 description 两个字段，Claude 凭什么靠这么点信息，就能决定要不要加载正文？」

这个问题问到点子上了。

Claude 在每次收到用户请求时，会拿这次请求去和上下文里所有 Skill 的 description 做语义匹配。description 写得准，它就触发得准。description 写得糊，它要么该触发不触发，要么在不相关的场景瞎触发。

官方给的公式是三个要素：做什么 + 何时使用 + 触发短语。

新手最容易漏掉的是中间那个「何时使用」。

我举个例子。

不好的写法：description: Helps with documents.——太泛了，Claude 根本不知道什么时候该用。

还是不好的写法：description: Creates sophisticated multi-page documentation systems.——只说了做什么，没说什么时候用。

好的写法是这样的：

description: Analyzes Figma design files and generates developer handoff docs.
  Use when the user uploads a .fig file or asks for "design specs",
  "component documentation", or "design-to-code handoff".

三个要素全在。做什么（分析 Figma 生成开发文档），何时使用（用户上传 .fig 或提到设计规格），触发短语（design specs、component documentation）。

还有一个很多人不知道的技巧。直接问 Claude「你什么时候会用这个 Skill？」 它会把它理解的 description 复述给你听。如果它复述出来的触发场景跟你预期的不一样，那就说明 description 没写到位。

说真的，这个技巧我后来自己试了一下，发现我写的 description 有一半都被 Claude 理解歪了。改完以后触发准确率高了一大截。

资源文件不是「注入」的，是「读取」的

面试官追了第三问。

「你 SKILL.md 里引用的那些脚本和资源文件，又是怎么进到 context 里的？也是自动塞进去的吗？」

不是。

很多人会想当然地以为，SKILL.md 触发后，它 references/ 和 scripts/ 目录里的文件也跟着一起被加载了。完全不是。

第三级资源的加载方式跟前两级有本质区别——它不是被「注入」的，而是被 Claude 主动「读取」 的。

什么意思。SKILL.md 正文被加载后，Claude 看到的只是文字。如果正文里写了一句「在编写查询前，请查阅 references/api-patterns.md」，Claude 此刻并没有把那个文件读进来。它只是知道「有这么个文件、在那个路径、讲的是这些内容」。

只有当任务真的推进到需要那份文档时，Claude 才会调用工具（Read 或 Bash），把文件内容读进上下文。而且读进来的也只是它当下需要的那一个文件，不是整个目录。

这个设计有两个巨大的好处。

第一，资源文件的体积几乎没有上限。 因为它们不常驻、不自动加载，你可以在 references/ 里放几百行的 API 文档、大段的错误码表。它们躺在那里不占任何上下文，只在被点名读取的那一刻才花 token。

第二，scripts/ 里的脚本是被「执行」的，不是被「理解」的。 对于确定性的逻辑，与其用自然语言在 SKILL.md 里描述一堆规则让模型去理解——语言解释是不确定的——不如直接写成一个脚本，让 Claude 去运行它。Anthropic 原话是「代码是确定性的，语言解释不是」。

面试怎么答这条追问链

好，三问拆完了。如果你面试被问到这条链，我建议按这个节奏答。

第一步，先纠正「全量加载」这个前提。 开口就说：「SKILL.md 不是一次性全部读进 context 的，Anthropic 用的是 Progressive Disclosure，渐进式披露，分三级按需加载。」一句话把基本盘立住。

第二步，讲清三级分别是什么。 Metadata 启动时常驻、每个约 100 token。正文在 Skill 被判断相关时才加载、建议 5000 词以内。资源文件由 Claude 主动用工具读取。顺手抛出结论：「所以装很多 Skill 也不会爆 token，常驻的只有那点 metadata。」

第三步，讲 description 怎么决定触发。 公式是「做什么 + 何时使用 + 触发短语」，第三人称写，列用户真实会说的话。能补一句「可以直接问 Claude 什么时候会用这个 Skill 来调试」，是加分项。

第四步，讲资源是「读」不是「注入」。 强调资源文件和脚本是 Claude 主动调用工具读取或执行的，所以体积没上限，确定性逻辑应该写成脚本而不是写进正文。

这四步答完，面试官基本就确认你是真做过了。

我想说的

回头看滴滴面试官那条追问链，它其实没有一个问题是刁难。

从「是不是全量加载」到「token 会不会爆」，到「description 怎么触发」，再到「资源怎么读取」——每一问都是上一问的自然延伸。你只要真正写过一个 Skill、被它的触发机制坑过几次，这四个问题是连在一起的、一口气能答完的。

答不上来，恰恰说明只是把 SKILL.md 当成了一个「写指令的文件」，没去想它背后那套加载逻辑。

说真的，我自己也犯过这个错。第一次写 Skill 的时候，我把所有东西全塞进 SKILL.md 正文里，description 写了一句「Helps with coding tasks」。结果 Claude 在完全不相关的场景反复触发这个 Skill，token 烧得飞快。

后来我把 description 按公式重写了一遍，把详细内容下沉到 references/，正文只留核心指令。触发准确率直接从「随缘」变成了「精准」。

背答案的人和真正做过的人，说话方式完全不一样。

前者说「SKILL.md 会按需加载，用了 progressive disclosure」。后者会说「我装了二十多个 Skill 实测过，常驻上下文的只有每个约 100 token 的 metadata，正文一次对话通常只触发一两个。有一次我的 description 写得太泛，Claude 在不相关的请求里反复误触发，我加了一句负面条件、把触发短语换成用户真实说法之后才收敛」。

面试官三句话就能听出来你是哪种人。

最近我把大家公认最容易翻车的 Agent 开发面试考点 整理成了一份 PDF。

我自己面了不少人，也被面了不少次，这些东西说实话，外面那些面经基本看不到。