| 概念 | 含义 | 为什么重要 |
|---|---|---|
| 名片机制 | 启动时智能体只扫 name ＋ description 判断调不调，选中了才读正文 | 触发词写全与否，直接决定技能的「生死」 |
| description 预算 | Claude Code 默认给所有 description 的总预算是上下文窗口的 2%，单条硬上限 1024 字符；扣子商店上限 200 字 | 装得越多越容易透支；实践上控制在 100 字左右、最多 200 字 |
| 上下文（context） | 智能体的工作台面，对话越长可用空间越少 | 按需加载既省 context，又防跑偏 |
把技能想成一场持续进行的招聘会：每个技能递上一张名片，智能体是只看名片就当场拍板的面试官。名片上功能写没写清、触发词覆没覆盖用户的实际说法，决定了这份「简历」会不会被翻开。而整个技能库的运转靠的是台面纪律——厨房台面就那么大，谁都别把整本菜谱摊开，先亮名片，被点到再翻页。
启动时智能体只扫 name ＋ description 判断调不调，选中了才读正文——触发词写全是关键。
这个模型还给出一条反直觉的推论：description 不是越精确越好，也不是越全能越好。太模糊等于名片上只印「资深人士」，太精确等于只印「周五下午有空」。好名片落在中间——功能一句话，场景列几个用户真会说出口的词。
| 评价 | description | 效果 |
|---|---|---|
| ✗ 太模糊 | 帮助用户完成工作 | 好像什么都说了又什么都没说，基本不触发 |
| ✗ 太精确 | 每周五下午写周报 | 只有「周五下午」精确命中才触发 |
| ✓ 刚刚好 | 生成结构化的工作周报。当用户要求撰写周报、工作总结、工作汇报等内容时使用 | 说到「周报／工作总结／汇报」都能触发 |
书中还给了反向触发词的范例——翻译技能与润色技能抢活儿时：基础版写 将文章翻译为目标语言。当用户需要翻译时使用；加上反向触发词后变成 将文章翻译为目标语言。当用户需要翻译文章、网页内容时使用。不用于润色已有中文内容。一句「不用于」，边界立现。
理解了工作记忆空间有限，你就能理解技能最聪明的设计——智能体是怎么找到当前任务需要的技能，又不会在装了一二十个技能的情况下把台面“撑爆”的。它靠的就是“按需加载”策略，官方的专业叫法是渐进式披露（progressive disclosure）：系统不会把所有技能文件一股脑儿塞进上下文，而是将其拆分成三层。智能体在接到你的指令后，会按需逐层追加。
当你说“帮我写周报”时，智能体的第一个动作是拿你的需求跟所有技能的 description 做比对匹配，判断该用哪个技能——鉴于 description 的作用类似于开关，我们又把它称为“触发开关”。因为名片早就加载好了，所以这一步不消耗额外的词元量。又因为名片的体量比较小，就算加载一二十个也不会轻易“撑爆”上下文窗口。
先说一个很多人可能不知道的底层事实：你安装的所有技能的 description，会在智能体启动的瞬间，直接被注入大模型的“系统提示词”中。前面我们管它叫“名片”。虽然这些名片藏在后台，你在聊天框里根本看不到，但事实上，智能体在还没跟你开口说话之前，就已经把它们全加载进上下文了。这就引出了一个有点儿反直觉的事实：description 的首要读者是 AI，不是人。大模型决定要不要调用一个技能，唯一的决策依据就是技能的 description。
新手常犯下面这个错：把“当用户说……时使用本技能”写在 SKILL.md 的正文里。这不会起任何作用——不管 SKILL.md 的正文写得多好，description 写得模糊就等于白写。正文属于第二层，智能体判断“用不用这个技能”只看第一层 description。正文是触发技能之后才读取的，那时候决策已经做完了。
这里还要特别注意大模型的“偷懒心理”：天生偏向“少用甚至不用技能”（专业叫法是“工具调用惰性”）。在“用不用技能”这件事上，大模型更倾向于不用，如果它觉得自己能搞定，就不会去查看技能。因此，description 必须主动把用户可能的高频说法覆盖到，而不是等着被精确命中。
请记住下面的极简公式（等式右边是 description 的两大核心要素）：description = 功能定义 + 触发场景 / 触发词。功能定义：这个技能是用来干什么的。触发场景 / 触发词：什么时候使用这个技能。description 需要贴合用户实际表述，且尽可能覆盖用户可能使用的关键词。避免模糊，如不用“处理数据”，而用“处理 CSV/Excel 数据，用户提及数据统计、报表生成时触发”。