1. 从skills这个模糊词说起它到底指什么第一次看到skills这个词作为项目标题大部分人的反应是懵的——这词太泛了泛到几乎等于没说。但结合热搜词里高频出现的 Claude、Agent Skills、SKILL.md、Claude Code 这些词方向就清晰了这里说的 skills指的是围绕 AI 编程助手尤其是 Claude Code 这类命令行 Agent 工具构建的技能扩展机制。打个比方你就懂了。Claude Code 本身像是一个刚入职的聪明应届生通用能力强能写代码、能读文档、能跑命令但它不知道你们团队的具体规范不知道你们内部那套部署流程也不知道你司代码库里那些祖传约定。skills 就是给这个应届生发的岗位操作手册——你把某类任务的背景、步骤、注意事项、参考文件打包成一个技能包它下次遇到同类任务时就会自动加载这套手册按你的方式来干活。所以 skills 的本质是用结构化的文件核心是 SKILL.md把某类任务该怎么做固化下来让 AI Agent 在需要时按需调用。它不是插件不是 API更不是模型微调而是一种纯文本层面的知识注入手段。这个定位非常关键因为它决定了 skills 的门槛极低——你不需要写一行代码只要会写 Markdown就能造一个技能出来。这篇文章适合谁看三类人一是刚接触 Claude Code、搞不清 skills 和 prompt 区别的新手二是想给自己团队沉淀一套 AI 协作规范的技术负责人三是被数学建模 skillsAI 漫剧 skills这类垂直场景需求吸引、想自己动手做一个的实践者。我会从机制原理讲到目录结构再讲到怎么写第一个 SKILL.md最后聊几个我实际踩过的坑。2. SKILL.md 的加载机制为什么它能自动生效2.1 渐进式披露skills 最核心的设计哲学理解 skills 的关键在于理解一个叫**渐进式披露Progressive Disclosure**的设计。这个词听起来玄乎其实逻辑特别朴素AI 的上下文窗口是有限的你不能把所有技能手册一股脑全塞进去否则光手册就占满了真正干活的空间就没了。Claude Code 的做法是分三层加载第一层元数据name description。启动时只加载所有技能的名字和一句话描述这部分极短几十个技能加起来也就几百 token。AI 靠这层信息判断当前任务该不该调用某个技能。第二层SKILL.md 正文。当 AI 判断某个技能相关时才把完整的 SKILL.md 读进来。这里面是具体的操作步骤、规范、示例。第三层附属资源。SKILL.md 里引用的脚本、模板、参考文档只有在真正执行到那一步时才按需读取。这个机制解释了一个常见困惑为什么我放了几十个 skillsAI 也没变慢因为绝大多数技能平时只以一行描述的形式存在只有被命中时才展开。这就像你书架上摆了一百本书你不需要全部读完才能找其中一本看脊背上的书名就够了。2.2 description 字段为什么是生死线基于上面的机制你会发现一个残酷的事实AI 决定用不用你的技能几乎完全取决于 description 写得好不好。正文写得再精彩如果 description 没能让 AI 在第一层就判断出相关性那这个技能永远不会被加载。我见过太多人栽在这里。有人把 description 写成这是一个很有用的技能AI 看了完全不知道啥时候该用有人写成处理数据太宽泛跟别的技能撞车。正确的写法是把触发场景直接写进描述里比如当用户需要把 CSV 数据转换成可视化图表时使用支持折线图、柱状图、饼图。你看这句话里既有什么时候用CSV 转图表又有能做什么三种图AI 一比对当前任务就能精准命中。提示description 建议控制在 1-2 句话既要覆盖触发条件又要说明能力边界。写完后自己念一遍问自己如果我是 AI看到这句话知道啥时候该调用吗答不上来就重写。2.3 skills 和 prompt、和 MCP 的边界在哪新手最容易混淆的就是这几个概念我用一张表说清楚机制本质生效方式适合场景Prompt一次性指令你每次手动输入临时、一次性的任务skills可复用的知识包AI 按需自动加载反复出现的同类任务MCP外部工具协议连接外部服务/数据源需要访问外部系统一句话总结prompt 是这次你这么做skills 是以后这类事都这么做MCP 是给你接个外部工具用。三者不冲突可以叠加。比如你可以写一个 skill里面规定处理数据库任务时优先通过 MCP 连接查询然后按以下规范整理结果。3. 一个 skill 的目录长什么样从零拆解结构3.1 最小可用结构其实只要一个文件很多人以为 skills 很复杂其实最小可用的 skill 就是一个文件夹加一个 SKILL.mdmy-skill/ └── SKILL.mdSKILL.md 的头部是 YAML 格式的元数据用三个短横线包起来下面才是正文--- name: csv-to-chart description: 当用户需要把 CSV 数据转换成可视化图表时使用支持折线图、柱状图和饼图 --- # CSV 转图表技能 ## 使用步骤 1. 读取用户提供的 CSV 文件确认列名和数据类型 2. 询问用户想要哪种图表类型 3. 使用 Python 的 matplotlib 生成图表 4. 输出图片并说明关键数据点 ## 注意事项 - 如果 CSV 有中文列名注意设置字体避免乱码 - 数据量超过 1 万行时先做聚合再画图就这么简单。name是技能标识description是触发描述正文是给 AI 看的操作手册。你把这个文件夹放到指定目录重启 Claude Code它就能识别了。3.2 进阶结构附属资源怎么组织当技能变复杂就需要附属文件了。一个成熟的 skill 目录通常长这样data-analysis-skill/ ├── SKILL.md # 主文件入口 ├── scripts/ │ ├── clean.py # 数据清洗脚本 │ └── plot.py # 绘图脚本 ├── templates/ │ └── report.md # 报告模板 └── references/ └── field-guide.md # 字段说明文档关键在于 SKILL.md 里要明确告诉 AI 什么时候去读哪个文件。比如## 数据清洗 如果数据存在缺失值或异常值参考 references/field-guide.md 中的字段定义 然后运行 scripts/clean.py 进行清洗。 ## 生成报告 报告格式严格遵循 templates/report.md 模板。这样 AI 就不会一上来把所有文件都读一遍而是走到哪一步读哪个完美契合渐进式披露的设计。3.3 存放位置项目级还是用户级skills 的存放位置决定了它的作用范围这是实操中必须搞清楚的一点项目级放在项目根目录的.claude/skills/下只对当前项目生效适合团队协作时随代码库一起提交。用户级放在用户主目录的~/.claude/skills/下对你所有项目生效适合个人通用技能。我的建议是跟具体项目强相关的放项目级通用能力放用户级。比如我们公司 API 的调用规范放项目级Markdown 表格美化这种放用户级。这样既保证团队共享又避免污染全局。注意不同版本的 Claude Code 对 skills 目录的识别路径可能有细微差异如果放了技能没生效第一件事就是确认路径对不对别急着怀疑技能本身写错了。4. 动手写第一个 skill以数学建模场景为例4.1 为什么选数学建模这个场景热搜词里数学建模 skills华为杯建模比赛好用的 codex skills反复出现说明这是个真实高频需求。数学建模比赛的特点是时间紧、任务重、流程固定读题→建模→求解→写论文而且有大量可复用的套路。这简直是 skills 的完美应用场景——把建模的标准流程固化下来比赛时直接调用能省下大量重复沟通的时间。4.2 拆解任务先想清楚 AI 该做什么写 skill 之前先别急着敲字拿张纸把任务流程列出来。数学建模的典型流程是读题提取关键约束和目标判断问题类型优化、预测、评价、分类等选择合适的模型编写求解代码分析结果验证合理性撰写论文对应章节每一步里AI 容易犯的错是什么比如第 2 步新手 AI 容易上来就套复杂模型忽略题目实际第 5 步容易只报结果不做敏感性分析。这些容易犯的错就是你要写进 skill 的重点。4.3 完整 SKILL.md 示例--- name: math-modeling description: 当用户需要解决数学建模竞赛题目时使用覆盖问题分析、模型选择、代码求解和论文撰写全流程 --- # 数学建模全流程技能 ## 第一步问题分析 - 通读题目用一句话概括每个小问的核心目标 - 列出题目给出的所有约束条件和数据 - 判断每个小问属于哪类问题优化/预测/评价/分类/机理分析 ## 第二步模型选择 参考以下对应关系优先选择简单可靠的模型 - 优化问题线性规划 → 整数规划 → 非线性规划 → 启发式算法 - 预测问题时间序列 → 回归 → 神经网络 - 评价问题层次分析法 → 熵权法 → TOPSIS - 分类问题聚类 → 判别分析 → 机器学习 原则能用简单模型解决就不要上复杂模型评委更看重合理性而非复杂度。 ## 第三步代码求解 - 使用 Python优先 numpy/scipy/pandas - 代码必须包含注释说明每步在做什么 - 求解后输出关键中间结果便于验证 ## 第四步结果分析 - 必须做敏感性分析说明模型对参数变化的稳健性 - 与题目实际背景对照判断结果是否合理 - 如果结果异常回头检查模型假设 ## 第五步论文撰写 - 按问题重述→模型假设→模型建立→模型求解→结果分析→模型评价结构 - 每个公式都要有文字解释 - 图表要有编号和标题4.4 写完之后的验证方法skill 写完不是就完事了得验证它到底管不管用。我的做法是拿一道往年的真题去测把题目丢给 Claude Code看它是否自动加载了这个 skill加载后行为是否符合预期。如果没加载八成是 description 没写对如果加载了但行为不对那就是正文步骤不够明确。这个测试-调整的循环通常要跑两三遍才能稳定。别嫌麻烦一个打磨好的 skill 能反复用投入产出比极高。5. 那些没人告诉你但一定会踩的坑5.1 description 写太宽技能互相打架我一开始图省事给好几个技能都写了类似处理数据相关任务的描述结果 AI 经常调错技能或者干脆不调。后来才明白description 的核心是区分度不是覆盖面。你要让 AI 一眼看出这个技能和那个技能不一样。解决办法是给每个 description 加上独特的触发词。比如处理 CSV 数据和处理 JSON 数据就比两个都写处理数据强得多。如果两个技能确实有重叠就在描述里写清楚优先级比如当任务同时涉及 A 和 B 时本技能优先处理 A 部分。5.2 正文写成了教科书AI 反而不会用新手写 skill 正文容易写成知识科普比如花大篇幅解释什么是线性规划。但 AI 不需要你教它线性规划是什么它需要的是在这个具体场景下线性规划该怎么用、参数怎么设、边界在哪。所以正文的正确写法是操作导向多用第一步做什么、第二步做什么少用XX 是一种……的方法。把 AI 当成一个聪明但不懂你业务的新同事你要给的是 SOP不是教材。5.3 附属文件路径写错AI 找不到这个坑特别隐蔽。SKILL.md 里引用附属文件时路径是相对于 SKILL.md 所在目录的不是相对于项目根目录。我见过有人写scripts/clean.py但实际文件在my-skill/scripts/clean.py结果 AI 死活找不到。稳妥的做法是引用路径时统一用相对路径并且在写完后自己手动核对一遍目录结构。如果技能要跨平台用还要注意路径分隔符的兼容性。5.4 技能太多导致选择困难当你有几十个技能时AI 在第一层做选择时也会犯难尤其是描述相近的技能。这时候要做的是合并同类项把功能相近的小技能合并成一个大技能用内部分支来处理不同情况。宁可少而精不要多而杂。我个人的经验是单个项目下的技能控制在 10 个以内比较舒服超过这个数就要考虑重构了。6. 从能用到好用几个进阶思路6.1 让 skill 自己进化skill 不是写完就固定的。我习惯在 SKILL.md 末尾加一个已知问题小节每次用的时候发现 AI 哪里做得不对就顺手记进去下次迭代时修正。这样技能会随着使用越来越贴合你的实际需求相当于一个持续学习的知识库。6.2 组合技能用 skill 调用 skill复杂任务往往需要多个技能协作。你可以在一个 skill 的正文里写完成本步骤后调用 XXX 技能处理后续部分。这样 AI 会按顺序加载多个技能形成工作流。比如数据清洗技能处理完数据后自动触发可视化技能出图再触发报告技能写总结。6.3 团队协作把 skill 当成活的文档skills 最大的价值之一是它把团队隐性知识显性化了。以前老员工脑子里的那些我们这儿都这么干的规矩现在可以写成 skill 随代码库一起提交。新人拉下代码AI 就自动按团队规范干活省去了大量口头传授。从这个角度看写 skill 其实是在给团队写一份 AI 能读懂的规范文档。6.4 跨工具复用别把 skill 绑死在一个工具上虽然 skills 这个概念是围绕 Claude Code 火起来的但它的核心——用 Markdown 描述任务流程——是通用的。你写的 SKILL.md稍作调整就能用在其他支持类似机制的 AI 工具上。所以写的时候尽量把工具相关的细节抽象出来比如别写死用 Claude 的 XX 命令而是写调用命令行执行 XX 操作这样迁移成本最低。7. 关于 skills 学习路径的一点个人建议如果你刚开始接触 skills我的建议是别一上来就追求写一个完美的通用技能。先从一个你每天都在做的、流程固定的小任务开始比如每天整理工作日志或者把会议记录转成待办清单。写一个最简版的 SKILL.md用几天发现问题就改。等你对description 怎么写才准正文怎么组织才清晰有了手感再去挑战复杂场景。另外网上那些skills 推荐skills 技能库的资源可以看但别照搬。别人的技能是照着别人的工作流写的直接拿来用往往水土不服。正确的姿势是参考结构重写内容——看别人怎么组织 SKILL.md然后用自己的业务细节填进去。最后说个我自己的体会skills 这东西门槛低到几乎人人能写但写好用的 skills 需要的是对任务的深度理解而不是写作技巧。你对一个任务理解得越透越知道 AI 会在哪里犯错写出来的 skill 就越有价值。所以与其纠结格式不如先把你要解决的那个任务本身吃透。
Claude Code Agent Skills 实战：SKILL.md 机制与编写指南
1. 从skills这个模糊词说起它到底指什么第一次看到skills这个词作为项目标题大部分人的反应是懵的——这词太泛了泛到几乎等于没说。但结合热搜词里高频出现的 Claude、Agent Skills、SKILL.md、Claude Code 这些词方向就清晰了这里说的 skills指的是围绕 AI 编程助手尤其是 Claude Code 这类命令行 Agent 工具构建的技能扩展机制。打个比方你就懂了。Claude Code 本身像是一个刚入职的聪明应届生通用能力强能写代码、能读文档、能跑命令但它不知道你们团队的具体规范不知道你们内部那套部署流程也不知道你司代码库里那些祖传约定。skills 就是给这个应届生发的岗位操作手册——你把某类任务的背景、步骤、注意事项、参考文件打包成一个技能包它下次遇到同类任务时就会自动加载这套手册按你的方式来干活。所以 skills 的本质是用结构化的文件核心是 SKILL.md把某类任务该怎么做固化下来让 AI Agent 在需要时按需调用。它不是插件不是 API更不是模型微调而是一种纯文本层面的知识注入手段。这个定位非常关键因为它决定了 skills 的门槛极低——你不需要写一行代码只要会写 Markdown就能造一个技能出来。这篇文章适合谁看三类人一是刚接触 Claude Code、搞不清 skills 和 prompt 区别的新手二是想给自己团队沉淀一套 AI 协作规范的技术负责人三是被数学建模 skillsAI 漫剧 skills这类垂直场景需求吸引、想自己动手做一个的实践者。我会从机制原理讲到目录结构再讲到怎么写第一个 SKILL.md最后聊几个我实际踩过的坑。2. SKILL.md 的加载机制为什么它能自动生效2.1 渐进式披露skills 最核心的设计哲学理解 skills 的关键在于理解一个叫**渐进式披露Progressive Disclosure**的设计。这个词听起来玄乎其实逻辑特别朴素AI 的上下文窗口是有限的你不能把所有技能手册一股脑全塞进去否则光手册就占满了真正干活的空间就没了。Claude Code 的做法是分三层加载第一层元数据name description。启动时只加载所有技能的名字和一句话描述这部分极短几十个技能加起来也就几百 token。AI 靠这层信息判断当前任务该不该调用某个技能。第二层SKILL.md 正文。当 AI 判断某个技能相关时才把完整的 SKILL.md 读进来。这里面是具体的操作步骤、规范、示例。第三层附属资源。SKILL.md 里引用的脚本、模板、参考文档只有在真正执行到那一步时才按需读取。这个机制解释了一个常见困惑为什么我放了几十个 skillsAI 也没变慢因为绝大多数技能平时只以一行描述的形式存在只有被命中时才展开。这就像你书架上摆了一百本书你不需要全部读完才能找其中一本看脊背上的书名就够了。2.2 description 字段为什么是生死线基于上面的机制你会发现一个残酷的事实AI 决定用不用你的技能几乎完全取决于 description 写得好不好。正文写得再精彩如果 description 没能让 AI 在第一层就判断出相关性那这个技能永远不会被加载。我见过太多人栽在这里。有人把 description 写成这是一个很有用的技能AI 看了完全不知道啥时候该用有人写成处理数据太宽泛跟别的技能撞车。正确的写法是把触发场景直接写进描述里比如当用户需要把 CSV 数据转换成可视化图表时使用支持折线图、柱状图、饼图。你看这句话里既有什么时候用CSV 转图表又有能做什么三种图AI 一比对当前任务就能精准命中。提示description 建议控制在 1-2 句话既要覆盖触发条件又要说明能力边界。写完后自己念一遍问自己如果我是 AI看到这句话知道啥时候该调用吗答不上来就重写。2.3 skills 和 prompt、和 MCP 的边界在哪新手最容易混淆的就是这几个概念我用一张表说清楚机制本质生效方式适合场景Prompt一次性指令你每次手动输入临时、一次性的任务skills可复用的知识包AI 按需自动加载反复出现的同类任务MCP外部工具协议连接外部服务/数据源需要访问外部系统一句话总结prompt 是这次你这么做skills 是以后这类事都这么做MCP 是给你接个外部工具用。三者不冲突可以叠加。比如你可以写一个 skill里面规定处理数据库任务时优先通过 MCP 连接查询然后按以下规范整理结果。3. 一个 skill 的目录长什么样从零拆解结构3.1 最小可用结构其实只要一个文件很多人以为 skills 很复杂其实最小可用的 skill 就是一个文件夹加一个 SKILL.mdmy-skill/ └── SKILL.mdSKILL.md 的头部是 YAML 格式的元数据用三个短横线包起来下面才是正文--- name: csv-to-chart description: 当用户需要把 CSV 数据转换成可视化图表时使用支持折线图、柱状图和饼图 --- # CSV 转图表技能 ## 使用步骤 1. 读取用户提供的 CSV 文件确认列名和数据类型 2. 询问用户想要哪种图表类型 3. 使用 Python 的 matplotlib 生成图表 4. 输出图片并说明关键数据点 ## 注意事项 - 如果 CSV 有中文列名注意设置字体避免乱码 - 数据量超过 1 万行时先做聚合再画图就这么简单。name是技能标识description是触发描述正文是给 AI 看的操作手册。你把这个文件夹放到指定目录重启 Claude Code它就能识别了。3.2 进阶结构附属资源怎么组织当技能变复杂就需要附属文件了。一个成熟的 skill 目录通常长这样data-analysis-skill/ ├── SKILL.md # 主文件入口 ├── scripts/ │ ├── clean.py # 数据清洗脚本 │ └── plot.py # 绘图脚本 ├── templates/ │ └── report.md # 报告模板 └── references/ └── field-guide.md # 字段说明文档关键在于 SKILL.md 里要明确告诉 AI 什么时候去读哪个文件。比如## 数据清洗 如果数据存在缺失值或异常值参考 references/field-guide.md 中的字段定义 然后运行 scripts/clean.py 进行清洗。 ## 生成报告 报告格式严格遵循 templates/report.md 模板。这样 AI 就不会一上来把所有文件都读一遍而是走到哪一步读哪个完美契合渐进式披露的设计。3.3 存放位置项目级还是用户级skills 的存放位置决定了它的作用范围这是实操中必须搞清楚的一点项目级放在项目根目录的.claude/skills/下只对当前项目生效适合团队协作时随代码库一起提交。用户级放在用户主目录的~/.claude/skills/下对你所有项目生效适合个人通用技能。我的建议是跟具体项目强相关的放项目级通用能力放用户级。比如我们公司 API 的调用规范放项目级Markdown 表格美化这种放用户级。这样既保证团队共享又避免污染全局。注意不同版本的 Claude Code 对 skills 目录的识别路径可能有细微差异如果放了技能没生效第一件事就是确认路径对不对别急着怀疑技能本身写错了。4. 动手写第一个 skill以数学建模场景为例4.1 为什么选数学建模这个场景热搜词里数学建模 skills华为杯建模比赛好用的 codex skills反复出现说明这是个真实高频需求。数学建模比赛的特点是时间紧、任务重、流程固定读题→建模→求解→写论文而且有大量可复用的套路。这简直是 skills 的完美应用场景——把建模的标准流程固化下来比赛时直接调用能省下大量重复沟通的时间。4.2 拆解任务先想清楚 AI 该做什么写 skill 之前先别急着敲字拿张纸把任务流程列出来。数学建模的典型流程是读题提取关键约束和目标判断问题类型优化、预测、评价、分类等选择合适的模型编写求解代码分析结果验证合理性撰写论文对应章节每一步里AI 容易犯的错是什么比如第 2 步新手 AI 容易上来就套复杂模型忽略题目实际第 5 步容易只报结果不做敏感性分析。这些容易犯的错就是你要写进 skill 的重点。4.3 完整 SKILL.md 示例--- name: math-modeling description: 当用户需要解决数学建模竞赛题目时使用覆盖问题分析、模型选择、代码求解和论文撰写全流程 --- # 数学建模全流程技能 ## 第一步问题分析 - 通读题目用一句话概括每个小问的核心目标 - 列出题目给出的所有约束条件和数据 - 判断每个小问属于哪类问题优化/预测/评价/分类/机理分析 ## 第二步模型选择 参考以下对应关系优先选择简单可靠的模型 - 优化问题线性规划 → 整数规划 → 非线性规划 → 启发式算法 - 预测问题时间序列 → 回归 → 神经网络 - 评价问题层次分析法 → 熵权法 → TOPSIS - 分类问题聚类 → 判别分析 → 机器学习 原则能用简单模型解决就不要上复杂模型评委更看重合理性而非复杂度。 ## 第三步代码求解 - 使用 Python优先 numpy/scipy/pandas - 代码必须包含注释说明每步在做什么 - 求解后输出关键中间结果便于验证 ## 第四步结果分析 - 必须做敏感性分析说明模型对参数变化的稳健性 - 与题目实际背景对照判断结果是否合理 - 如果结果异常回头检查模型假设 ## 第五步论文撰写 - 按问题重述→模型假设→模型建立→模型求解→结果分析→模型评价结构 - 每个公式都要有文字解释 - 图表要有编号和标题4.4 写完之后的验证方法skill 写完不是就完事了得验证它到底管不管用。我的做法是拿一道往年的真题去测把题目丢给 Claude Code看它是否自动加载了这个 skill加载后行为是否符合预期。如果没加载八成是 description 没写对如果加载了但行为不对那就是正文步骤不够明确。这个测试-调整的循环通常要跑两三遍才能稳定。别嫌麻烦一个打磨好的 skill 能反复用投入产出比极高。5. 那些没人告诉你但一定会踩的坑5.1 description 写太宽技能互相打架我一开始图省事给好几个技能都写了类似处理数据相关任务的描述结果 AI 经常调错技能或者干脆不调。后来才明白description 的核心是区分度不是覆盖面。你要让 AI 一眼看出这个技能和那个技能不一样。解决办法是给每个 description 加上独特的触发词。比如处理 CSV 数据和处理 JSON 数据就比两个都写处理数据强得多。如果两个技能确实有重叠就在描述里写清楚优先级比如当任务同时涉及 A 和 B 时本技能优先处理 A 部分。5.2 正文写成了教科书AI 反而不会用新手写 skill 正文容易写成知识科普比如花大篇幅解释什么是线性规划。但 AI 不需要你教它线性规划是什么它需要的是在这个具体场景下线性规划该怎么用、参数怎么设、边界在哪。所以正文的正确写法是操作导向多用第一步做什么、第二步做什么少用XX 是一种……的方法。把 AI 当成一个聪明但不懂你业务的新同事你要给的是 SOP不是教材。5.3 附属文件路径写错AI 找不到这个坑特别隐蔽。SKILL.md 里引用附属文件时路径是相对于 SKILL.md 所在目录的不是相对于项目根目录。我见过有人写scripts/clean.py但实际文件在my-skill/scripts/clean.py结果 AI 死活找不到。稳妥的做法是引用路径时统一用相对路径并且在写完后自己手动核对一遍目录结构。如果技能要跨平台用还要注意路径分隔符的兼容性。5.4 技能太多导致选择困难当你有几十个技能时AI 在第一层做选择时也会犯难尤其是描述相近的技能。这时候要做的是合并同类项把功能相近的小技能合并成一个大技能用内部分支来处理不同情况。宁可少而精不要多而杂。我个人的经验是单个项目下的技能控制在 10 个以内比较舒服超过这个数就要考虑重构了。6. 从能用到好用几个进阶思路6.1 让 skill 自己进化skill 不是写完就固定的。我习惯在 SKILL.md 末尾加一个已知问题小节每次用的时候发现 AI 哪里做得不对就顺手记进去下次迭代时修正。这样技能会随着使用越来越贴合你的实际需求相当于一个持续学习的知识库。6.2 组合技能用 skill 调用 skill复杂任务往往需要多个技能协作。你可以在一个 skill 的正文里写完成本步骤后调用 XXX 技能处理后续部分。这样 AI 会按顺序加载多个技能形成工作流。比如数据清洗技能处理完数据后自动触发可视化技能出图再触发报告技能写总结。6.3 团队协作把 skill 当成活的文档skills 最大的价值之一是它把团队隐性知识显性化了。以前老员工脑子里的那些我们这儿都这么干的规矩现在可以写成 skill 随代码库一起提交。新人拉下代码AI 就自动按团队规范干活省去了大量口头传授。从这个角度看写 skill 其实是在给团队写一份 AI 能读懂的规范文档。6.4 跨工具复用别把 skill 绑死在一个工具上虽然 skills 这个概念是围绕 Claude Code 火起来的但它的核心——用 Markdown 描述任务流程——是通用的。你写的 SKILL.md稍作调整就能用在其他支持类似机制的 AI 工具上。所以写的时候尽量把工具相关的细节抽象出来比如别写死用 Claude 的 XX 命令而是写调用命令行执行 XX 操作这样迁移成本最低。7. 关于 skills 学习路径的一点个人建议如果你刚开始接触 skills我的建议是别一上来就追求写一个完美的通用技能。先从一个你每天都在做的、流程固定的小任务开始比如每天整理工作日志或者把会议记录转成待办清单。写一个最简版的 SKILL.md用几天发现问题就改。等你对description 怎么写才准正文怎么组织才清晰有了手感再去挑战复杂场景。另外网上那些skills 推荐skills 技能库的资源可以看但别照搬。别人的技能是照着别人的工作流写的直接拿来用往往水土不服。正确的姿势是参考结构重写内容——看别人怎么组织 SKILL.md然后用自己的业务细节填进去。最后说个我自己的体会skills 这东西门槛低到几乎人人能写但写好用的 skills 需要的是对任务的深度理解而不是写作技巧。你对一个任务理解得越透越知道 AI 会在哪里犯错写出来的 skill 就越有价值。所以与其纠结格式不如先把你要解决的那个任务本身吃透。