腾讯二面被问：如何设计 Skill 来降低 Token 消耗？一套分层设计讲透这个问题

腾讯二面被问：如何设计 Skill 来降低 Token 消耗？一套分层设计讲透这个问题

前段时间有位粉丝面试腾讯大模型应用开发岗位，前面 RAG 链路、Agent 编排、Prompt 工程都答得很漂亮。最后面试官随口追问了一个问题：“你平时写 Skill，怎么控制 Token 消耗的？”

他想了一会儿，回答：“用渐进式加载，按需加载内容。”

面试官点点头，又问：“就这一个策略？还有呢？”

他愣住了。渐进式加载是他唯一能想到的答案，但面试官显然觉得不够。面完回来复盘才发现——Skill 的 Token 管理是一整套分层设计体系，不只是"按需加载"一句话能概括的。

01 善用三层加载结构：渐进披露的核心机制

Skill 这个系统，它其实有一个天然的机制，就是所谓的**“渐进披露”（Progressive Disclosure）**机制。什么意思呢？就是说它不是一股脑把所有东西都丢出来，而是分层来加载的。

我们可以把它理解成三层结构：

这里有个比较关键的地方：你要把那些只有在特定情况下才需要用到的内容，给它拆到 references 这个文件夹里面去。

不要把所有东西都一股脑塞进 SKILL.md 的正文里面，那样的话就太臃肿了嘛。

为什么这个机制很重要？

想象一下，如果你把一个完整的 Skill 比作一本工具书：

• 元数据就像是书脊上的标签——它始终在那里，告诉你这本书是干什么的
• 正文就像是目录和核心章节——只有当你真正需要用到这本书时，才会翻开它
• 参考文件就像是附录和参考资料——只有在你需要查阅具体细节时，才会翻到那一页

面试官当时追问"还有呢"，其实就是在等这个——你不能只知道"按需加载"这一个点，你得知道哪些东西是永远在上下文里的，哪些是触发才加载的，哪些是用到才读的。

三层搞清楚了，Token 消耗自然就可控了。

02 控制 SKILL.md 正文长度：500 行的红线

这个的话呢，目标就是把它控制在500 行以内，大概就这么个范围。

如果说超过了怎么办呢？那就在正文里面写清楚，告诉它"什么时候去读哪个参考文件"，而不是把那些内容都内联进来。这样子的话，正文就不会显得太长了。

举个例子来说吧，大概就是这样的一个结构：

# Cloud Deployment Skill 当用户需要部署云服务时触发。 ## 核心流程 1. 确认部署目标平台 2. 根据平台读取对应的参考文件 3. 执行部署脚本 ## 参考文件 - AWS 部署：读取 references/aws.md - GCP 部署：读取 references/gcp.md - Azure 部署：读取 references/azure.md

500 行这个数字不是随便定的

你想想看，Skill 被触发的时候，整个正文是要加载进上下文的。如果正文动不动就上千行，那每次触发的 Token 成本就很高了。

面试官问"还有呢"的时候，控制正文长度就是第二层答案。

03 按照场景分割参考文件：避免"全家桶"陷阱

如果你的技能是那种多域的，就是说它支持好几个框架或者平台的话，那就应该按照变体来拆分文件。这样的话，Claude 就只需要去读取相关的那一份就行了，而不是把全部内容都给加载进来。

cloud-deploy/references/ ├── aws.md ├── gcp.md └── azure.md

在 SKILL.md 里面写上判断逻辑，大概就是说"根据用户选择的平台，只去读取对应的参考文件"这么一个意思。

这个点其实很容易被忽略

很多人写 Skill 的时候，把所有平台的文档都堆在一起，想着"反正用到哪个读哪个"。但问题是，如果你不拆开，Claude 可能把所有内容都读进去了——这不就浪费了嘛。

正确的做法是：

• 每个平台一份独立的参考文件
• 在正文中明确说明什么时候读哪个文件
• 让模型在需要时才加载特定的参考文件

04 用脚本替代大段说明文字：执行的效率

对于那些确定性的、重复性的操作，比如说格式转换啊、文件处理啊这些，你直接提供一个可执行的脚本，比在 SKILL.md 里面去写那些长篇的指令要省 token 得多。

为什么呢？因为脚本这东西它可以直接执行，而不需要把内容加载进上下文里面。这样一来的话，你就不用把"如何操作"的那些详细步骤写成文字了，直接变成"执行这个脚本"一句话就搞定了，多省事啊。

对比一下两种方式：

实践建议：

• 文件格式转换、批量处理等操作，直接提供脚本文件
• 在 SKILL.md 中只需要写"执行 references/convert.sh"这样一句话
• 模型会直接调用脚本，而不是把整个操作步骤加载到上下文中

05 Description 精简但精准：永远在上下文的代价

Description 这个东西它是始终在上下文里面的，所以说你要做到以下几点：

首先呢，只去描述"什么时候触发"和"做什么"就行了，不要去写那些实现的细节。其次呢，避免那些冗余的举例，举个两三个触发词就足够了。

反面案例

把整个工作流程都写进 description 里面去，那样的话就太啰嗦了。

# 错误的 descriptiondescription:"这个技能可以帮助用户部署云服务，首先会询问用户想要部署到哪个平台，然后根据平台选择对应的配置模板，接着..."

正面案例

用一段话把触发场景和功能给说清楚就行了。

# 正确的 descriptiondescription:"当用户需要部署云服务到 AWS/GCP/Azure 时触发。提供多平台部署指南和自动化脚本。"

这个是最容易犯的错误

description 是永远在上下文里的，你多写一句话，每次对话就多消耗一点 Token。很多人没意识到这一点，把 description 当成 README 来写，结果每次对话都在为那些根本用不上的信息付费。

精简原则：

• 只说明触发条件（什么时候用）
• 只说明核心功能（做什么）
• 避免实现细节（怎么做）
• 避免冗长举例（最多 2-3 个触发词）

06 总结：Token 优化的分层设计体系

其实说白了就是一句话：不需要的时候不要去加载，加载的时候只加载够用的就行了。

你可以把这个 skill 想象成是一种"懒加载"的机制：

按照这样子去设计的话，那些高频触发的 skill 对 token 的消耗基本上就没有什么太大的影响了，嗯，就是这么个道理。

五层答案全解

所以到现在你应该知道，答案不是一个点，是一套分层设计：

1. 三层结构：元数据 → 正文 → 资源文件，搞懂什么时候加载什么
2. 500 行上限：控制正文长度，超出部分拆到参考文件
3. 按场景区分文件：多域技能按平台/框架拆分，避免全家桶
4. 用脚本替代文字：确定性操作直接用脚本执行，省上下文加载
5. Description 精简：永远在上下文的内容必须精简到极致

这五件事做好了，Token 消耗自然就降下来了。

觉得有用？点个在看再走吧 👍

转发给正在做大模型应用开发的技术朋友，一起聊聊！