腾讯二面被问如何设计 Skill 来降低 Token 消耗一套分层设计讲透这个问题前段时间有位粉丝面试腾讯大模型应用开发岗位前面 RAG 链路、Agent 编排、Prompt 工程都答得很漂亮。最后面试官随口追问了一个问题“你平时写 Skill怎么控制 Token 消耗的”他想了一会儿回答“用渐进式加载按需加载内容。”面试官点点头又问“就这一个策略还有呢”他愣住了。渐进式加载是他唯一能想到的答案但面试官显然觉得不够。面完回来复盘才发现——Skill 的 Token 管理是一整套分层设计体系不只是按需加载一句话能概括的。01 善用三层加载结构渐进披露的核心机制Skill 这个系统它其实有一个天然的机制就是所谓的**“渐进披露”Progressive Disclosure**机制。什么意思呢就是说它不是一股脑把所有东西都丢出来而是分层来加载的。我们可以把它理解成三层结构层级具体内容什么时候去进行加载元数据就是 name 加 description 这些东西一直在上下文里面待着的大概是 100 词左右的样子SKILL.md 正文也就是核心的那些指令内容等到 skill 被触发的时候才会去进行加载操作捆绑资源比如说参考文件啊、脚本啊这些按需去读取就行了不会自动加到上下文里面去这里有个比较关键的地方你要把那些只有在特定情况下才需要用到的内容给它拆到 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.md500 行这个数字不是随便定的你想想看Skill 被触发的时候整个正文是要加载进上下文的。如果正文动不动就上千行那每次触发的 Token 成本就很高了。面试官问还有呢的时候控制正文长度就是第二层答案。03 按照场景分割参考文件避免全家桶陷阱如果你的技能是那种多域的就是说它支持好几个框架或者平台的话那就应该按照变体来拆分文件。这样的话Claude 就只需要去读取相关的那一份就行了而不是把全部内容都给加载进来。cloud-deploy/references/ ├── aws.md ├── gcp.md └── azure.md在 SKILL.md 里面写上判断逻辑大概就是说根据用户选择的平台只去读取对应的参考文件这么一个意思。这个点其实很容易被忽略很多人写 Skill 的时候把所有平台的文档都堆在一起想着反正用到哪个读哪个。但问题是如果你不拆开Claude 可能把所有内容都读进去了——这不就浪费了嘛。正确的做法是每个平台一份独立的参考文件在正文中明确说明什么时候读哪个文件让模型在需要时才加载特定的参考文件04 用脚本替代大段说明文字执行的效率对于那些确定性的、重复性的操作比如说格式转换啊、文件处理啊这些你直接提供一个可执行的脚本比在 SKILL.md 里面去写那些长篇的指令要省 token 得多。为什么呢因为脚本这东西它可以直接执行而不需要把内容加载进上下文里面。这样一来的话你就不用把如何操作的那些详细步骤写成文字了直接变成执行这个脚本一句话就搞定了多省事啊。对比一下两种方式方式Token 消耗适用场景文字描述操作步骤高每次都要加载到上下文需要解释原理的场景脚本执行低只需一行引用指令确定性、重复性操作实践建议文件格式转换、批量处理等操作直接提供脚本文件在 SKILL.md 中只需要写执行 references/convert.sh这样一句话模型会直接调用脚本而不是把整个操作步骤加载到上下文中05 Description 精简但精准永远在上下文的代价Description 这个东西它是始终在上下文里面的所以说你要做到以下几点首先呢只去描述什么时候触发和做什么就行了不要去写那些实现的细节。其次呢避免那些冗余的举例举个两三个触发词就足够了。反面案例把整个工作流程都写进 description 里面去那样的话就太啰嗦了。# 错误的 descriptiondescription:这个技能可以帮助用户部署云服务首先会询问用户想要部署到哪个平台然后根据平台选择对应的配置模板接着...正面案例用一段话把触发场景和功能给说清楚就行了。# 正确的 descriptiondescription:当用户需要部署云服务到 AWS/GCP/Azure 时触发。提供多平台部署指南和自动化脚本。这个是最容易犯的错误description 是永远在上下文里的你多写一句话每次对话就多消耗一点 Token。很多人没意识到这一点把 description 当成 README 来写结果每次对话都在为那些根本用不上的信息付费。精简原则只说明触发条件什么时候用只说明核心功能做什么避免实现细节怎么做避免冗长举例最多 2-3 个触发词06 总结Token 优化的分层设计体系其实说白了就是一句话不需要的时候不要去加载加载的时候只加载够用的就行了。你可以把这个 skill 想象成是一种懒加载的机制层级特点Token 成本元数据永远在上下文里但很便宜低~100 词正文按需加载触发时才付费中控制 500 行内资源文件用到时才读取低按需按照这样子去设计的话那些高频触发的 skill 对 token 的消耗基本上就没有什么太大的影响了嗯就是这么个道理。五层答案全解所以到现在你应该知道答案不是一个点是一套分层设计三层结构元数据 → 正文 → 资源文件搞懂什么时候加载什么500 行上限控制正文长度超出部分拆到参考文件按场景区分文件多域技能按平台/框架拆分避免全家桶用脚本替代文字确定性操作直接用脚本执行省上下文加载Description 精简永远在上下文的内容必须精简到极致这五件事做好了Token 消耗自然就降下来了。觉得有用点个在看再走吧 转发给正在做大模型应用开发的技术朋友一起聊聊
腾讯二面被问：如何设计 Skill 来降低 Token 消耗？一套分层设计讲透这个问题
腾讯二面被问如何设计 Skill 来降低 Token 消耗一套分层设计讲透这个问题前段时间有位粉丝面试腾讯大模型应用开发岗位前面 RAG 链路、Agent 编排、Prompt 工程都答得很漂亮。最后面试官随口追问了一个问题“你平时写 Skill怎么控制 Token 消耗的”他想了一会儿回答“用渐进式加载按需加载内容。”面试官点点头又问“就这一个策略还有呢”他愣住了。渐进式加载是他唯一能想到的答案但面试官显然觉得不够。面完回来复盘才发现——Skill 的 Token 管理是一整套分层设计体系不只是按需加载一句话能概括的。01 善用三层加载结构渐进披露的核心机制Skill 这个系统它其实有一个天然的机制就是所谓的**“渐进披露”Progressive Disclosure**机制。什么意思呢就是说它不是一股脑把所有东西都丢出来而是分层来加载的。我们可以把它理解成三层结构层级具体内容什么时候去进行加载元数据就是 name 加 description 这些东西一直在上下文里面待着的大概是 100 词左右的样子SKILL.md 正文也就是核心的那些指令内容等到 skill 被触发的时候才会去进行加载操作捆绑资源比如说参考文件啊、脚本啊这些按需去读取就行了不会自动加到上下文里面去这里有个比较关键的地方你要把那些只有在特定情况下才需要用到的内容给它拆到 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.md500 行这个数字不是随便定的你想想看Skill 被触发的时候整个正文是要加载进上下文的。如果正文动不动就上千行那每次触发的 Token 成本就很高了。面试官问还有呢的时候控制正文长度就是第二层答案。03 按照场景分割参考文件避免全家桶陷阱如果你的技能是那种多域的就是说它支持好几个框架或者平台的话那就应该按照变体来拆分文件。这样的话Claude 就只需要去读取相关的那一份就行了而不是把全部内容都给加载进来。cloud-deploy/references/ ├── aws.md ├── gcp.md └── azure.md在 SKILL.md 里面写上判断逻辑大概就是说根据用户选择的平台只去读取对应的参考文件这么一个意思。这个点其实很容易被忽略很多人写 Skill 的时候把所有平台的文档都堆在一起想着反正用到哪个读哪个。但问题是如果你不拆开Claude 可能把所有内容都读进去了——这不就浪费了嘛。正确的做法是每个平台一份独立的参考文件在正文中明确说明什么时候读哪个文件让模型在需要时才加载特定的参考文件04 用脚本替代大段说明文字执行的效率对于那些确定性的、重复性的操作比如说格式转换啊、文件处理啊这些你直接提供一个可执行的脚本比在 SKILL.md 里面去写那些长篇的指令要省 token 得多。为什么呢因为脚本这东西它可以直接执行而不需要把内容加载进上下文里面。这样一来的话你就不用把如何操作的那些详细步骤写成文字了直接变成执行这个脚本一句话就搞定了多省事啊。对比一下两种方式方式Token 消耗适用场景文字描述操作步骤高每次都要加载到上下文需要解释原理的场景脚本执行低只需一行引用指令确定性、重复性操作实践建议文件格式转换、批量处理等操作直接提供脚本文件在 SKILL.md 中只需要写执行 references/convert.sh这样一句话模型会直接调用脚本而不是把整个操作步骤加载到上下文中05 Description 精简但精准永远在上下文的代价Description 这个东西它是始终在上下文里面的所以说你要做到以下几点首先呢只去描述什么时候触发和做什么就行了不要去写那些实现的细节。其次呢避免那些冗余的举例举个两三个触发词就足够了。反面案例把整个工作流程都写进 description 里面去那样的话就太啰嗦了。# 错误的 descriptiondescription:这个技能可以帮助用户部署云服务首先会询问用户想要部署到哪个平台然后根据平台选择对应的配置模板接着...正面案例用一段话把触发场景和功能给说清楚就行了。# 正确的 descriptiondescription:当用户需要部署云服务到 AWS/GCP/Azure 时触发。提供多平台部署指南和自动化脚本。这个是最容易犯的错误description 是永远在上下文里的你多写一句话每次对话就多消耗一点 Token。很多人没意识到这一点把 description 当成 README 来写结果每次对话都在为那些根本用不上的信息付费。精简原则只说明触发条件什么时候用只说明核心功能做什么避免实现细节怎么做避免冗长举例最多 2-3 个触发词06 总结Token 优化的分层设计体系其实说白了就是一句话不需要的时候不要去加载加载的时候只加载够用的就行了。你可以把这个 skill 想象成是一种懒加载的机制层级特点Token 成本元数据永远在上下文里但很便宜低~100 词正文按需加载触发时才付费中控制 500 行内资源文件用到时才读取低按需按照这样子去设计的话那些高频触发的 skill 对 token 的消耗基本上就没有什么太大的影响了嗯就是这么个道理。五层答案全解所以到现在你应该知道答案不是一个点是一套分层设计三层结构元数据 → 正文 → 资源文件搞懂什么时候加载什么500 行上限控制正文长度超出部分拆到参考文件按场景区分文件多域技能按平台/框架拆分避免全家桶用脚本替代文字确定性操作直接用脚本执行省上下文加载Description 精简永远在上下文的内容必须精简到极致这五件事做好了Token 消耗自然就降下来了。觉得有用点个在看再走吧 转发给正在做大模型应用开发的技术朋友一起聊聊
