转载：滴滴面试官问我：你 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 在不相关的请求里反复误触发，我加了一句负面条件、把触发短语换成用户真实说法之后才收敛」。