腾讯二面被问：如何设计 Skill 来降低 Token 消耗？我说“渐进式加载“。面试官：就这一个？还有呢？我当场卡壳了。
前段时间有个粉丝面腾讯二面，岗位是大模型应用开发。前面聊得都挺顺利，RAG链路、Agent编排、Prompt工程基本都答上来了。面试官看起来挺满意，最后随口追问了一个问题：“你平时写 Skill，怎么控制 Token 消耗的？”
他想了想，说：“用渐进式加载，按需加载内容。”
面试官点点头，又问：“就这一个策略？还有呢？”
他愣住了。渐进式加载是他唯一能想到的答案——把东西拆开，用到再加载，听起来没什么毛病。但面试官显然觉得不够，追问的眼神一直没移开。
他挠了挠头，说了一些零散的想法，比如"控制正文长度"“少写点内容”，但都没说到点子上。面试官最后笑了笑，说：“回去再想想，这个东西比你想的要系统一点。”
他面完回来找我复盘，我帮他梳理了一下——其实 Skill 的 Token 管理是一整套分层设计，不只是"按需加载"一句话能概括的。今天把这个体系讲清楚。
1. 善用三层加载结构这件事
Skill 这个系统呢，它其实有一个天然的机制，就是所谓的"渐进披露"机制。什么意思呢，就是说它不是一股脑把所有东西都丢出来，而是分层来加载的。
| 层级 | 具体内容 | 什么时候去进行加载 |
|---|---|---|
| 元数据 | 就是 name 加 description 这些东西 | 一直在上下文里面待着的，大概是100词左右的样子 |
| SKILL.md 正文 | 也就是核心的那些指令内容 | 等到 skill 被触发的时候才会去进行加载操作 |
| 捆绑资源 | 比如说参考文件啊、脚本啊这些 | 按需去读取就行了，不会自动加到上下文里面去 |
这里有个比较关键的地方，就是说你要把那些只有在特定情况下才需要用到的内容，给它拆到 references 这个文件夹里面去。不要把所有东西都一股脑塞进 SKILL.md 的正文里面，那样的话就太臃肿了嘛。
面试官当时追问"还有呢"，其实就是在等这个——你不能只知道"按需加载"这一个点，你得知道哪些东西是永远在上下文里的，哪些是触发才加载的，哪些是用到才读的。三层搞清楚了，Token 消耗自然就可控了。
2. 要去控制 SKILL.md 正文的长度
这个的话呢，目标就是把它控制在500行以内，大概就这么个范围。
如果说超过了怎么办呢，那就在正文里面写清楚，告诉它"什么时候去读哪个参考文件"，而不是把那些内容都内联进来。这样子的话，正文就不会显得太长了。
举个例子来说吧，大概就是这样的一个结构：
500行这个数字不是随便定的——你想想看，Skill 被触发的时候，整个正文是要加载进上下文的。如果正文动不动就上千行，那每次触发的 Token 成本就很高了。面试官问"还有呢"的时候，控制正文长度就是第二层答案。
3. 要按照场景来分割参考文件
如果你的技能是那种多域的，就是说它支持好几个框架或者平台的话，那就应该按照变体来拆分文件。这样的话，Claude 就只需要去读取相关的那一份就行了，而不是把全部内容都给加载进来。
cloud-deploy/references/├── aws.md├── gcp.md└── azure.md在 SKILL.md 里面写上判断逻辑，大概就是说"根据用户选择的平台，只去读取对应的参考文件"这么一个意思。
这个点其实很容易被忽略。很多人写 Skill 的时候，把所有平台的文档都堆在一起，想着"反正用到哪个读哪个"。但问题是，如果你不拆开，Claude 可能把所有内容都读进去了——这不就浪费了嘛。
4. 要学会用脚本来替代大段的说明文字
对于那些确定性的、重复性的操作，比如说格式转换啊、文件处理啊这些，你直接提供一个可执行的脚本，比在 SKILL.md 里面去写那些长篇的指令要省 token 得多。
为什么呢，因为脚本这东西它可以直接执行，而不需要把内容加载进上下文里面。这样一来的话，你就不用把"如何操作"的那些详细步骤写成文字了，直接变成"执行这个脚本"一句话就搞定了，多省事啊。
5. Description 要精简但也要精准
Description 这个东西它是始终在上下文里面的，所以说你要做到以下几点：
首先呢，只去描述"什么时候触发"和"做什么"就行了，不要去写那些实现的细节。其次呢，避免那些冗余的举例，举个两三个触发词就足够了。
反面的例子是什么呢，就是把整个工作流程都写进 description 里面去，那样的话就太啰嗦了。正面的例子呢，就是用一段话把触发场景和功能给说清楚就行了。
这个是最容易犯的错误——description 是永远在上下文里的，你多写一句话，每次对话就多消耗一点 Token。很多人没意识到这一点，把 description 当成 README 来写，结果每次对话都在为那些根本用不上的信息付费。
总结一下这个原则吧
其实说白了就是一句话：不需要的时候不要去加载，加载的时候只加载够用的就行了。
你可以把这个 skill 想象成是一种"懒加载"的机制。元数据这东西永远都是很便宜的，正文呢是按需来付费的，资源文件呢是用的时候才去取的。按照这样子去设计的话，那些高频触发的 skill 对 token 的消耗基本上就没有什么太大的影响了，嗯，就是这么个道理。
所以到现在你应该知道，答案不是一个点，是一套分层设计。三层结构、500行上限、按场景区分文件、用脚本替代文字、description 精简——这五件事做好了，Token 消耗自然就降下来了。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～