1. 从“Skill 越堆越臃肿”说起为什么该给 Skill 减肥了如果你最近半年一直在折腾 Claude Code、Codex、Cline 这类 AI 编程代理工具大概率会有一种相似的体感一开始只装了两三个 Skill用着挺爽过了两个月~/.claude/skills或者项目里的AGENTS.md已经膨胀到几十个条目每次对话模型都要先“读一遍说明书”响应变慢、token 飙升、行为还开始互相打架。这就是“该给 Skill 减肥了”这个标题背后最真实的痛点。所谓 Skill本质上就是给 AI 代理看的一份“能力说明书 操作手册”。它可能是一个SKILL.md也可能是一段写进AGENTS.md、context.md的规则或者是一个带脚本的插件目录。它的作用是告诉模型遇到某类任务时应该调用哪些工具、遵循什么流程、注意哪些坑。Skill 越多模型在启动时被塞进上下文的“前置知识”就越多这跟人上班前要先读 30 页员工手册是一个道理——读得越多真正干活的时间就越少。这篇内容我想聊的不是“怎么装 Skill”而是反过来怎么判断哪些 Skill 该留、哪些该删、哪些该合并、哪些该拆成按需加载。适合已经用过一段时间 Claude Code、Codex、Cline手里攒了一堆 skill 插件、agent skill、skill 脚本感觉“越用越卡、越用越乱”的中级用户也适合刚入门、正准备大规模收集“好用的 skill 推荐”的新手提前建立正确的组织观念少走我踩过的弯路。核心关键词会贯穿全文Skill、Claude Code、plugin eval、OpenAI、AGENTS.md。我会把“减肥”拆成四个层面——认知层Skill 和 Agent 到底啥区别、评估层怎么量化一个 Skill 值不值得留、执行层合并、拆分、懒加载的具体做法、维护层长期不反弹的机制。全程按我自己的实操记录来讲参数、目录结构、判断标准都会给到能直接抄作业。先说结论方向免得你读到最后才发现跑偏Skill 减肥的目标不是“越少越好”而是让每一次对话加载的上下文恰好等于这次任务真正需要的那部分能力。这跟数据库索引、微服务拆分的思路是一模一样的——不是删功能是让功能在正确的时机出现。2. 先搞清楚 Skill、Agent、Plugin 到底谁是谁2.1 Skill 和 Agent 的区别别再用混了热词里高频出现“skill和agent的区别”说明这是绝大多数人的第一道坎。我用一句话概括Agent 是“谁来做”Skill 是“怎么做”。Agent 是一个有自主决策能力的执行主体它有自己的目标、循环、工具集能自己规划步骤、自己调用工具、自己判断是否完成。你在 Claude Code 里让它“帮我把这个 bug 修了”它去读代码、改代码、跑测试这一整套自主行为就是 Agent 在干活。Skill 则是一份被动的知识包。它不会自己启动只有当 Agent 判断“当前任务匹配这个 Skill 的描述”时才会被加载进来当参考。比如你写了一个“数学建模 skill”里面规定了建模题应该先做数据清洗、再选模型、最后做敏感性分析——这份流程本身不会执行任何东西是 Agent 读了它之后照着做。这个区别直接决定了减肥策略Agent 是常驻的数量必须极少Skill 是按需的理论上可以很多但前提是加载机制要支持“按需”。很多人把一堆本该做成 Skill 的东西硬塞进 Agent 的 system prompt结果就是每次对话都背着几十斤行李跑步。2.2 Plugin、Skill 脚本、AGENTS.md 三者的关系再理一下工程结构。以 Claude Code 为例常见的组织方式有这么几层AGENTS.md / context.md项目级的“总纲”描述项目背景、技术栈、通用规范。它几乎每次都会被读所以必须精简。Skill 目录如~/.claude/skills/xxx/SKILL.md每个 Skill 一个文件夹里面是SKILL.md加可选的脚本、模板、参考文档。Plugin更重的封装可能包含多个 Skill、命令、钩子甚至带plugin eval之类的评估逻辑。Skill 脚本Skill 里真正干活的.py、.sh、.js被 Agent 在需要时调用。我见过最典型的“肥胖症”就是把所有东西都写进AGENTS.md项目规范、代码风格、部署流程、数据库 schema、API 文档、历史决策……一份文件干到 8000 字。模型每次对话都要吞下这 8000 字token 成本先不说关键是注意力被稀释——真正重要的那三条规则淹没在 200 条无关信息里。正确的分层应该是AGENTS.md只放“每次都必须知道”的东西比如项目是干什么的、用什么语言、禁止改哪些目录其余全部下沉到 Skill靠描述字段触发按需加载。2.3 为什么“Skill 越多越慢”不是错觉这里补一点原理解释为什么减肥是刚需而不是洁癖。大模型的上下文窗口虽然号称几十万 token但有效注意力是有限的。业界有个被反复验证的现象叫“lost in the middle”当上下文很长时模型对中间部分的召回率明显下降开头和结尾的信息更容易被记住。你把 50 个 Skill 的描述全塞进去模型很可能只记得前 5 个和后 5 个中间 40 个形同虚设——但它们照样占着 token、照样花钱、照样拖慢首 token 延迟。更麻烦的是指令冲突。Skill A 说“提交前必须跑 lint”Skill B 说“紧急修复可以跳过 lint”模型读到两条矛盾指令时行为就变得不可预测。我实测过当 Skill 数量超过 20 个且存在语义重叠时模型“选择性忽略某条规则”的概率会显著上升。这不是模型笨是你给的信息本身就在打架。所以减肥的第一性原理是减少常驻上下文把能力变成可检索、可按需加载的资源。下面进入具体怎么评估。3. 给每个 Skill 做一次“体检”量化评估该不该留3.1 四个维度打分别凭感觉删拍脑袋删 Skill 很容易删错。我总结了一套四维打分法每个维度 1-5 分总分低于 12 分的就进入“待处理”名单。这套方法我在自己的 30 多个 Skill 上跑过一遍砍掉了 11 个合并了 6 个效果立竿见影。维度说明1 分5 分触发频率过去一个月被实际调用多少次几乎没用过每天多次独占性内容是否与其他 Skill 重叠高度重叠完全独有上下文成本加载它要吃掉多少 token超过 2000 token低于 300 token失败代价没有它时任务出错概率无所谓必错无疑打分时有个技巧触发频率不要靠记忆去看日志。Claude Code 和 Cline 一般都会在会话记录里留下 Skill 调用痕迹翻一下最近两周的记录比回忆靠谱得多。我当初以为“部署 skill”用得很多一查日志发现一个月才触发两次果断降级。3.2 plugin eval把评估这件事自动化热词里的plugin eval值得单独说。手动打分适合 Skill 少的时候一旦超过 20 个就得靠脚本。我的做法是写一个评估脚本扫描 Skill 目录输出每个 Skill 的元信息统计import os import re from pathlib import Path SKILL_ROOT Path.home() / .claude / skills def estimate_tokens(text): # 粗略估算中文约 1.5 字/token英文约 4 字符/token chinese len(re.findall(r[\u4e00-\u9fff], text)) others len(text) - chinese return int(chinese / 1.5 others / 4) def scan_skills(): rows [] for skill_dir in SKILL_ROOT.iterdir(): if not skill_dir.is_dir(): continue skill_file skill_dir / SKILL.md if not skill_file.exists(): continue content skill_file.read_text(encodingutf-8) # 提取 frontmatter 里的 description desc_match re.search(rdescription:\s*(.), content) desc desc_match.group(1).strip() if desc_match else rows.append({ name: skill_dir.name, tokens: estimate_tokens(content), desc_len: len(desc), has_script: any(skill_dir.glob(*.py)) or any(skill_dir.glob(*.sh)), }) rows.sort(keylambda r: r[tokens], reverseTrue) return rows for r in scan_skills(): print(f{r[name]:30} tokens{r[tokens]:6} desc{r[desc_len]:5} script{r[has_script]})跑一遍就能看到谁最“胖”。我当时的输出里排名第一的 Skill 光SKILL.md就 4200 token内容是一份完整的 API 文档——这种东西根本不该常驻应该拆成按需读取的参考文件。提示token 估算不用追求精确量级对了就行。目的是找出“异常胖”的那几个而不是做财务级核算。3.3 判断“该删”还是“该藏”评估完会得到三类结果处理方式完全不同高频 独占 低成本保留甚至可以强化。这是核心资产。低频 独占 高成本不要删改成按需加载。把内容拆到独立文件SKILL.md里只留一句“需要时读取reference.md”。低频 重叠 高成本直接删或合并。这类是纯粹的负担。很多人舍不得删觉得“万一以后用得上”。我的经验是删掉的东西如果真需要你会重新写一遍而且写得更好。留着不用的 Skill 唯一的作用就是拖慢每一次对话。4. 实操把臃肿的 Skill 拆开、合并、懒加载4.1 拆分一个 Skill 只干一件事先看一个反面案例。我早期写过一个“全栈开发 skill”里面塞了前端规范、后端规范、数据库迁移、部署流程、日志排查五大块SKILL.md有 3000 多 token。问题是我改前端样式的时候模型也要读一遍数据库迁移规则纯浪费。拆分的标准很简单如果两块内容从不会在同一次任务里同时用到就该拆。按这个标准上面那个 Skill 被拆成了五个skills/ frontend-style/SKILL.md backend-api/SKILL.md db-migration/SKILL.md deploy-flow/SKILL.md log-troubleshoot/SKILL.md拆完之后每个SKILL.md控制在 300 token 以内只写“什么时候用、核心步骤、注意事项”详细内容全部外链到同目录的reference.md。这样模型只在真正需要时才读细节。4.2 合并语义重叠的 Skill 要归一拆分是减法合并也是减法。我发现自己有三个 Skill 都在讲“代码提交规范”一个叫commit-msg一个叫git-flow一个叫pr-checklist。三者内容 60% 重叠模型每次都要读三遍相似的东西。合并的原则是按触发场景归并而不是按内容主题。这三个都属于“代码提交与协作”场景合并成一个git-workflow内部用小节区分 commit、branch、PR。合并后 token 从 1800 降到 600触发准确率反而提高了——因为描述字段更聚焦了。合并时要注意不要为了合并而合并。如果两个 Skill 触发场景完全不同硬合并只会让描述字段变得模糊模型反而不知道该不该加载。判断标准是它们的 description 能不能用一句话同时概括能就合并不能就分开。4.3 懒加载让 Skill 学会“按需现身”这是减肥的核心技术。Claude Code 的 Skill 机制本身支持渐进式加载SKILL.md的 frontmatter 里有个description字段模型先看所有 Skill 的描述判断哪个相关再读那个 Skill 的正文。所以描述字段的质量直接决定了加载效率。我踩过的坑是描述写得太笼统比如“用于处理各种开发任务”。结果模型一遇到开发任务就把这个 Skill 拉进来哪怕这次只是改个错别字。后来我把描述改成“当需要修改 React 组件的样式或布局时使用”触发精度立刻上来了。一个高质量的 description 应该包含三个要素触发条件什么时候用、能力范围能做什么、排除条件什么时候别用。举个例子--- name: db-migration description: 当需要新增或修改数据库表结构、编写迁移脚本时使用。仅处理 schema 变更不处理数据查询优化。涉及生产库操作时必须先确认备份。 ---这种描述模型一看就知道边界在哪。相比之下“数据库相关 skill”这种描述就是灾难。4.4 把重内容外置成参考文件对于确实需要保留但内容很长的 Skill比如一份完整的 API 规范做法是正文只留索引细节放外部文件skills/ api-reference/ SKILL.md # 200 token只写需要查 API 时读取 endpoints.md endpoints.md # 3000 token完整接口列表 errors.md # 1500 token错误码对照SKILL.md里明确写“当需要查询具体接口参数时读取同目录endpoints.md的对应章节。”这样模型只在真的要查接口时才读那 3000 token平时零成本。这跟查字典是一个逻辑——你不会把整本字典背下来只在需要时翻到对应页。5. AGENTS.md 瘦身项目总纲只留“每次都要知道”的5.1 AGENTS.md 该写什么、不该写什么AGENTS.md以及配套的context.md是最容易被写胖的地方因为它看起来“什么都能往里塞”。我的判断标准只有一条这条信息是不是每一次对话都必须知道必须知道的比如项目是干什么的一句话技术栈和主要目录结构绝对不能碰的目录或文件通用的代码风格底线比如“禁止 any 类型”不必每次都读的比如详细的 API 文档 → 下沉到 Skill历史架构决策 → 下沉到docs/decisions/部署步骤 → 下沉到 Skill测试用例清单 → 下沉到 Skill我把自己项目的AGENTS.md从 6000 字砍到 800 字只保留了上面四类。砍完之后最直观的变化是模型开始“听话”了。以前它经常忽略某条规则现在因为规则少而精遵守率明显提升。5.2 context.md 和 AGENTS.md 的分工热词里同时出现agents.md和agents.md context.md说明很多人搞不清这俩的分工。我的用法是AGENTS.md稳定的、跨会话不变的规则。相当于“公司章程”。context.md当前任务的临时上下文。相当于“本次会议纪要”。比如我在做一个特定功能时会把“本次要改的三个文件、当前已知的 bug 现象、临时约定的接口格式”写进context.md任务结束后清空或归档。这样AGENTS.md保持干净context.md随用随弃不会污染长期上下文。注意context.md用完一定要清理。我见过有人把半年前的任务上下文一直留着模型每次对话都以为还在做那个任务行为完全错乱。5.3 用引用代替复制避免多处维护AGENTS.md里如果需要提到某个 Skill 的内容不要复制粘贴用引用。比如## 数据库变更 涉及 schema 变更时遵循 skills/db-migration/SKILL.md 中的流程。这样规则只有一份改的时候不会漏。复制粘贴是上下文膨胀的头号元凶——同一份内容在三个地方各存一份改一处忘两处最后模型读到三个版本直接懵。6. 常见问题与排查减肥路上的那些坑6.1 删了 Skill 之后模型变笨了怎么办这是最常见的恐慌。删完发现模型不再遵守某条规则第一反应是“删错了”。但多数情况下真正的原因是那条规则本来就该保留在AGENTS.md里而不是 Skill 里。排查思路问自己“这条规则是不是每次对话都需要”如果是它就不该是 Skill应该回到AGENTS.md。Skill 的定位是“特定任务才需要的能力”不是“通用规则仓库”。我当初把“禁止提交 console.log”写进了一个 Skill删掉后模型就开始乱提交——正确做法是把它放进AGENTS.md的代码风格底线里。6.2 Skill 之间互相打架怎么排查症状是模型行为不稳定同一类任务有时这样做有时那样做。排查步骤列出所有可能被触发的 Skill看它们的 description 是否有重叠。检查是否有两条规则直接矛盾比如一个说“必须写测试”一个说“快速修复可跳过测试”。用plugin eval脚本统计各 Skill 的 token 占比找出“话最多”的那个。解决方法是建立优先级。在AGENTS.md里明确写“当 Skill 规则冲突时以AGENTS.md为准。”或者给 Skill 加优先级字段让模型知道谁大谁小。6.3 怎么防止 Skill 数量再次反弹减肥容易保持难。我给自己定了三条规矩新增 Skill 前先问能不能并进现有的能并就不新建。每月跑一次评估脚本把触发频率为 0 的 Skill 标记出来连续两个月为 0 就删。Skill 的SKILL.md硬性限制 500 token超了必须外置内容。这三条执行下来我的 Skill 数量稳定在 12 个左右没有再膨胀过。常见问题典型症状排查方向解决动作删后变笨规则不再被遵守规则是否该常驻移回 AGENTS.mdSkill 打架行为不稳定description 重叠建立优先级数量反弹越攒越多缺乏新增门槛先问能否合并加载变慢首 token 延迟高找出最胖的 Skill拆分或外置触发不准该用的没用description 太笼统补触发条件6.4 一个容易被忽略的坑脚本类 Skill 的依赖带脚本的 Skill比如skill脚本里那种.py减肥时要注意删 Skill 前先确认脚本有没有被别的地方引用。我有一次删了一个“数据清洗 skill”结果发现另一个 Skill 的脚本里import了它的工具函数直接报错。后来养成习惯删之前全局搜一遍 Skill 名字确认没有交叉引用再动手。7. 长期维护让 Skill 体系保持“轻”的机制7.1 建立 Skill 清单和生命周期我维护一份skills/INDEX.md记录每个 Skill 的名称、一句话用途、上次触发时间、token 成本、负责人如果是团队。这份清单每月更新一次相当于给 Skill 做体检报告。有了它谁该退休一目了然。生命周期可以简单分三段试用期新建 1 个月内、稳定期持续被触发、观察期连续 1 个月零触发。观察期的 Skill 进入待删队列给两周缓冲还没触发就删。7.2 团队协作时的 Skill 治理如果是多人共用一套 Skill比如团队里的 Claude Code 配置减肥就更重要因为每个人都会往里加东西。我的做法是Skill 的新增和删除走轻量评审至少一个人 review。每个 Skill 的SKILL.md顶部标注 owner 和创建日期。定期比如每季度做一次集体清理把没人认领的 Skill 直接删。这跟代码库治理是一个道理没有 owner 的东西最后都会变成垃圾。7.3 把“减肥”变成习惯而不是运动最后分享一个心态上的体会。我一开始把 Skill 减肥当成一次性的“大扫除”删完就完事。结果三个月后又胖回去了。后来我把它变成每次新增 Skill 时的一个动作新建之前先花 30 秒问自己“这个能不能并进现有的”“描述能不能写清楚触发条件”。这个 30 秒的习惯比每季度大扫除有效得多。Skill 体系的健康度本质上反映的是你对“什么信息该在什么时候出现”的理解深度。减肥减的不是功能是噪音。当每一次对话加载的上下文都恰好是这次任务需要的模型的表现会好到你怀疑它换了个人。我在实际使用中发现把 Skill 从 30 多个精简到 12 个之后同样的任务模型的一次通过率大概提升了三成首 token 延迟也肉眼可见地降了。这个投入产出比值得你花一个下午认真做一遍。