别再让 Skill 过度虚胖：Agent 只要小抄，不是教科书

很多开发者都习惯了把 API 文档、身份验证流程、SDK 模板、错误处理机制和版本信息等，全部都一股脑塞进同一个 Skill 里。这样一来 AI Agent 在调用时，确实能拿到全部上下文并生成代码，但结果呢？你只是白白烧掉了大量 Token。

模型其实早就会了

大语言模型（LLM）在训练阶段，其实早已经吞掉了不少官方文档、Stack Overflow 问答、GitHub 仓库，以及海量技术博客。默认的 Import 语句、标准的认证流程、常见的增删改查（CRUD）操作，模型早就内化好了。

当你的 Skill 只是在重复这些大模型早就掌握的常识时，你并不是在帮忙，而是在增加负担。Skill 每返回一个 Token，都会占用上下文窗口的有限空间，而这些 Token 的存在并非毫无代价：它们会把模型真正「不知道」的东西挤出去，比如本地工作区文件、历史对话记录，或是其他工具的输出结果。

大多数 Skill 都犯了同一个毛病：塞进了几千 Token 的文档，智能体调用时拿到「整包内容」，效果并没有变好，有时候甚至更差。原因也很简单：你在给模型塞它本来就不需要的东西。

怎么知道模型已经会了什么？

答案是：不做测试的话，你根本无法确定。而这恰恰是大多数人都会忽略的一步：从来不评估大模型在没有辅助的情况下，自身到底能做到什么程度。

如果大模型在 90% 的情况下已经能生成正确的代码，那你真正需要的，只是一个覆盖剩下 10% 盲区的轻量级 Skill：容易踩坑的认证细节、训练数据没覆盖到的最新破坏性变更、或是网上找不到先例的特殊配置模式。如果不先测出模型基线，你就根本不知道该把这 10% 锁定在哪里。

先测基线，再动手

先在不使用 Skill 的情况下跑一遍你的场景。用同一个模型、同一套测试环境、同一组提示词，看看 Agent 哪里做对了、哪里做错了——这就是你的基线。

如果模型本来就能正确处理 CRUD，Skill 里就不要再放 CRUD 示例；如果认证流程能开箱即用，就不用塞你的认证指南；如果它自己就能选对 SDK 版本，就别再浪费 Token 画蛇添足去告诉它该用哪个版本。

减去基线之后剩下的内容，就是大模型会犯错或完全不了解的模式。这才是你 Skill 应该覆盖的范围，仅此而已。

每一个多余 Token 都是拖累

上下文窗口是稀缺资源。如果一个 Skill 返回了 3000 Token 大模型早就心知肚明的文档，这就是在白白烧掉宝贵的上下文空间。这些空间本可以用来存放开发者的工作区文件、对话上下文，或是模型需要的其他工具输出。

当多个 Skill 组合使用时，情况会变得更糟。开发者可能同时安装了多个 Skill，每个技能哪怕只是被加载，也会挤占掉一部分 Token 预算。一个臃肿的技能不仅会拖累自身场景的体验，还会蚕食其他技能所需的空间。这不仅损害了自身的产品表现，还在增加整个系统的性能负担。

5 步精简 Skill

1. 定义场景：明确开发者会让 AI Agent 用 Skill 来完成哪些具体任务。
2. 裸机测试：在不加载 Skill 的前提下运行这些任务，并对输出结果进行评分。
3. 定位盲区：找出大模型出错的地方，这些失败案例才是 Skill 要覆盖的范围。
4. 精准填坑：开发一个仅针对这些盲区的 Skill。
5. 再次评估：重测一遍，验证 Skill 是带来了实际性能提升，还是纯粹的负担。同时还要留意 Token 消耗量：如果效果提升了，但 Token 用量翻了 3 倍，本质上还是血亏。

按照这个思路流程跑一遍，你最终会得到一个体积只有原来几分之一、效果却明显更好的 Skill。很多时候，模型需要的不是一本教科书，而是一张精准的「小抄」。