尧图网页设计 
1. 从“skills”这个热词说起它到底是什么为什么突然火了最近几个月不管是在技术社区还是各种开发者群聊里“skills”这个词出现的频率高得离谱。如果你只是偶尔刷到可能会以为它说的是“技能”这个泛泛的概念但只要你稍微往深里看一眼就会发现大家讨论的其实是Agent Skills——一种让 AI 编程助手比如 Claude Code、Codex 这类工具具备可复用、可组合、可版本管理的“能力模块”的机制。说白了以前我们用 AI 写代码每次都得把上下文、规范、项目结构重新喂一遍效率低不说结果还不稳定。而 Skills 的出现本质上是把“怎么做一个特定任务”这件事从一次性的对话里抽出来变成一个独立的、有结构的文件包。这个文件包里最核心的就是SKILL.md它用自然语言加少量元数据的方式告诉 AI 在什么场景下该调用什么能力、按什么步骤执行、注意哪些边界条件。我最早接触这个概念是在一个前端项目里当时团队想让 AI 帮忙统一处理组件的命名规范和目录结构。一开始大家都是把规则写在 prompt 里但每次新开一个会话就得重新贴一遍而且不同人写的 prompt 风格不一样AI 的输出也飘忽不定。后来有人提议把这套规则做成一个 skill放在项目根目录的.skills文件夹下结果整个流程一下子就稳了——不管谁用、什么时候用只要触发条件匹配AI 就会自动加载这个 skill按同样的逻辑干活。所以如果你问我 skills 解决了什么问题我的回答很直接它解决的是 AI 辅助开发中“重复劳动”和“一致性缺失”这两个老大难问题。适合谁来学我觉得只要你在日常工作中会用到 AI 编程工具不管是前端、后端、数据科学还是数学建模都值得花点时间了解一下。哪怕你暂时不打算自己写 skill至少要知道怎么安装、怎么用别人分享的 skill这已经能帮你省下大量重复沟通的成本。2. Skills 的核心机制拆解为什么是 SKILL.md而不是别的2.1 SKILL.md 的设计哲学让 AI 自己决定什么时候用很多人第一次看到SKILL.md的时候会有点懵——这不就是一个 Markdown 文件吗凭什么它能让 AI 变聪明这里面的关键不在于文件格式本身而在于它的内容结构和加载时机。一个典型的SKILL.md通常包含几个部分顶部的元信息比如 name、description、trigger 条件中间的步骤说明以及底部的示例和边界情况。AI 在运行时会先扫描所有可用的 skill然后根据当前对话的上下文判断哪个 skill 的 trigger 条件被满足了再把对应的内容加载进上下文。这个过程是按需加载的不需要你手动切换也不需要你把所有规则都塞进系统提示里。我打个比方以前的 prompt 就像你每次做饭都得把菜谱从头念一遍给厨师听而 skill 就像你把菜谱写好了放在架子上厨师看到你今天点了红烧肉自己就去把对应的菜谱抽出来照着做。这个“自己抽”的动作就是 skill 机制最值钱的地方。2.2 和传统 prompt 工程的区别从“一次性”到“可积累”传统 prompt 工程最大的问题是不可积累。你今天调好了一个很满意的 prompt明天换个会话、换个模型版本可能就失效了。而且 prompt 通常是写在对话里的没法版本管理没法 code review更没法分享给团队其他人复用。Skills 把这件事变成了工程化的。SKILL.md可以放在 Git 仓库里可以写 changelog可以打 tag可以像代码一样做 review。你改了一版 skill团队里所有人拉下来就能用效果是一致的。更重要的是skill 可以被组合——一个 skill 可以依赖另一个 skill就像函数调用一样。这种可组合性让复杂任务的拆解变得非常自然。2.3 触发机制与上下文管理AI 是怎么“想起”某个 skill 的这里涉及一个很多人忽略的细节skill 不是越多越好。如果你在项目里塞了几十个 skillAI 在判断该用哪个的时候反而容易出错因为 trigger 条件之间可能会打架。我实测下来一个项目里同时激活的 skill 最好控制在 5 到 8 个以内超过这个数量AI 的调用准确率会明显下降。触发机制一般有两种一种是关键词触发比如 skill 的 description 里写了“当用户提到组件命名规范时使用”那 AI 看到相关关键词就会加载另一种是显式调用比如你在对话里直接说“用 xxx skill 来处理这个任务”。前者更自然后者更可控。我的建议是两者结合——日常用关键词触发关键任务用显式调用兜底。3. 从零开始写一个自己的 Skill完整实操流程3.1 环境准备你需要什么工具和目录结构先说清楚写 skill 本身不需要什么特殊环境一个文本编辑器加一个 Git 仓库就够了。但如果你想让 skill 真正跑起来得确保你用的 AI 编程工具支持这个机制。目前 Claude Code 对 skills 的支持比较成熟Codex 这边也在跟进具体版本要求建议看官方文档的最新说明。目录结构方面我习惯在项目根目录下建一个.skills文件夹里面每个 skill 一个子目录子目录名就是 skill 的标识符。比如.skills/ component-naming/ SKILL.md examples/ good-example.tsx bad-example.tsx api-error-handling/ SKILL.md每个 skill 目录里至少有一个SKILL.md如果有示例文件或者辅助脚本可以放在同级目录下在SKILL.md里用相对路径引用。3.2 写好 SKILL.md 的五个关键部分我写过的 skill 不算多但踩过的坑不少。总结下来一个能稳定工作的SKILL.md应该包含以下五个部分第一部分是元信息头。通常用 YAML front matter 的格式写在文件最上面包括 name、description、version、trigger 这几个字段。description 要写得具体但不啰嗦trigger 要覆盖你希望 AI 自动加载这个 skill 的典型场景。第二部分是目标说明。用一两句话讲清楚这个 skill 是干什么的解决什么问题。这部分是给 AI 看的也是给以后维护这个 skill 的人看的。第三部分是执行步骤。这是核心内容要按顺序列出 AI 应该怎么做。每一步都要具体到可执行的程度不要写“优化代码结构”这种模糊的话而要写“检查每个组件的文件名是否以 PascalCase 命名如果不是重命名为 PascalCase”。第四部分是示例。给一两个正例和反例让 AI 知道什么算做对了什么算做错了。示例不用多但要有代表性。第五部分是边界和禁忌。明确告诉 AI 在什么情况下不要用这个 skill或者执行过程中有哪些绝对不能做的事。这部分很多人会忽略但实际用起来能避免大量误操作。3.3 一个真实案例前端组件命名规范 skill下面是我实际在用的一个 skill 的简化版你可以直接参考这个结构来写自己的--- name: component-naming description: 统一 React 组件的文件命名和导出规范 version: 1.2.0 trigger: - 用户提到组件命名 - 用户要求整理组件目录 - 新建组件文件时 --- ## 目标 确保项目中所有 React 组件的文件名、导出名和目录结构保持一致。 ## 执行步骤 1. 扫描 src/components 下所有 .tsx 文件 2. 检查文件名是否为 PascalCase如果不是重命名 3. 检查默认导出名是否与文件名一致如果不一致修正 4. 检查每个组件是否放在以组件名命名的子目录中 5. 如果组件有配套的样式文件或测试文件确保它们在同一目录下 ## 示例 正例src/components/UserProfile/UserProfile.tsx 反例src/components/user-profile/index.tsx ## 边界 - 不要修改 node_modules 下的任何文件 - 不要重命名已经被其他文件引用的组件除非同时更新所有引用 - 如果组件名和文件名冲突无法自动解决停下来询问用户这个 skill 写完之后我们团队里不管谁用 AI 整理组件输出都是一致的。以前每次都要在对话里重复一遍规则现在完全不用了。3.4 调试和迭代怎么知道 skill 写得好不好写完一个 skill 只是开始真正花时间的是调试。我的做法是先在小范围试比如拿一个具体的任务让 AI 跑一遍看它有没有正确加载 skill、有没有按步骤执行、有没有在边界情况下停下来。如果发现 AI 没加载 skill通常是 trigger 写得不够具体或者 description 和实际对话的匹配度不高。如果加载了但执行不对多半是步骤写得太模糊或者示例不够有代表性。如果 AI 在边界情况下乱来那就是禁忌部分没写清楚。我一般会迭代三到五版才觉得一个 skill 比较稳。每次改完都记一下改了什么、为什么改这样后面维护的时候不至于忘了当时的思路。4. 安装和使用别人分享的 Skills少走弯路的实操建议4.1 从哪里找现成的 skill现在网上分享 skill 的地方越来越多GitHub 上搜SKILL.md或者agent-skills能出来一大堆。比较活跃的仓库通常会有分类目录比如前端开发、数据处理、数学建模、文档写作等等。我建议优先找star 数高、最近有更新、有实际使用案例的仓库不要随便下一个来路不明的 skill 就往项目里塞。另外有些 skill 是跟特定工具绑定的比如专门给 Claude Code 用的或者专门给 Codex 用的。下载之前看清楚兼容性说明不然装上去可能根本不生效。4.2 手动安装 skill 的完整步骤假设你在 GitHub 上找到了一个想要的 skill手动安装的流程大概是这样的把仓库 clone 到本地或者直接下载 zip 包解压找到里面包含SKILL.md的目录通常一个 skill 一个目录把整个 skill 目录复制到你项目的.skills文件夹下检查SKILL.md里的 trigger 条件是否和你的项目场景匹配不匹配就改一下重启你的 AI 编程工具让它重新扫描 skill 目录在对话里测试一下看 AI 能不能正确加载注意有些 skill 会依赖外部脚本或者特定的环境变量装之前一定要看 README 里的依赖说明不然跑起来会报错。4.3 常见安装问题排查我遇到过几次装完不生效的情况排查下来基本是这几个原因问题现象可能原因解决方法AI 完全不加载 skill目录结构不对SKILL.md 不在正确位置确认 skill 目录直接放在 .skills 下不要多套一层加载了但执行报错缺少依赖或环境变量看 SKILL.md 里的依赖说明补齐缺失项多个 skill 冲突trigger 条件重叠精简 trigger或者改成显式调用改了 skill 不生效工具缓存了旧版本重启工具或者手动清除缓存目录4.4 使用别人 skill 的注意事项别人的 skill 再好也是为别人的项目场景写的。直接拿来用之前我建议至少做三件事读一遍 SKILL.md 的每一步确认没有你不希望 AI 执行的操作检查示例是否符合你的项目规范不符合就改掉在测试分支上先跑一遍确认没问题再合到主分支。还有一点很重要不要同时装太多功能重叠的 skill。比如你装了两个都是处理代码格式化的 skillAI 在触发的时候就会犹豫甚至可能两个都加载导致指令冲突。我的做法是同类功能只保留一个其他的要么删掉要么改成手动调用。5. 进阶玩法把 Skills 组合起来解决复杂任务5.1 Skill 之间的依赖和调用单个 skill 能解决的问题是有限的真正有意思的是把多个 skill 组合起来。比如你可以有一个 skill 负责代码规范检查另一个 skill 负责生成测试用例第三个 skill 负责更新文档。当你说“帮我重构这个模块”的时候AI 可以依次加载这三个 skill按顺序执行。实现这种方式的关键是在 skill 的步骤里显式引用其他 skill。比如在重构 skill 的最后一步写“调用 test-generation skill 为修改后的代码生成测试”。这样 AI 就知道该去加载哪个 skill 了。5.2 用 skill 做数学建模和数据分析我看到不少人在讨论数学建模比赛里怎么用 skills。说实话这个场景特别适合。数学建模的流程通常是固定的理解问题、选择模型、写代码求解、分析结果、写论文。你可以把每个阶段做成一个 skill比如“模型选择 skill”里写清楚什么类型的问题该用什么模型“论文写作 skill”里规定好摘要、假设、符号说明的格式。这样不管题目怎么变AI 都能按同样的流程帮你推进不会因为换了个题目就完全不知道从哪下手。我试过用这种方式辅助写代码效率提升很明显尤其是那些重复性的数据预处理和可视化部分。5.3 团队协作中的 skill 管理如果是团队一起用 skill我强烈建议把.skills目录纳入 Git 管理并且制定一个简单的 review 流程。谁想加新 skill提个 PR其他人看一下 trigger 条件有没有冲突、步骤有没有歧义、禁忌有没有遗漏。合并之后所有人拉下来就能用同一套能力。另外skill 也要写 changelog。每次改了什么都记一下这样当 AI 的行为发生变化时你能快速定位是哪个 skill 的哪次改动导致的。6. 我踩过的坑和总结出来的经验6.1 不要试图用一个 skill 解决所有问题我一开始写 skill 的时候总想写一个“万能 skill”把所有规范都塞进去。结果就是 trigger 条件写得特别宽泛AI 动不动就加载它加载之后又因为步骤太多太杂执行到一半就乱了。后来我学乖了一个 skill 只做一件事做精做透。需要多个能力的时候用组合的方式解决而不是堆在一个文件里。6.2 trigger 要具体但不要过于狭窄trigger 写得太宽skill 会被频繁误加载写得太窄又可能该加载的时候不加载。我的经验是用具体的动作词加对象词比如“当用户要求重命名组件文件时”就比“当用户提到组件时”好得多。同时可以留一两个稍微宽泛的 trigger 作为兜底但不要超过三个。6.3 示例比描述更有用AI 对示例的敏感度远高于对抽象描述的理解。与其写“代码要整洁”不如直接给一段整洁的代码和一段不整洁的代码让 AI 自己去对比。我后来写 skill 的时候示例部分花的时间比步骤部分还多但效果确实好很多。6.4 定期清理不再使用的 skill项目在变skill 也要跟着变。有些 skill 可能半年前很有用但现在项目结构改了它已经过时了。如果不清理这些过时的 skill 会干扰 AI 的判断。我一般每个月花十分钟过一遍.skills目录把不再用的删掉把需要更新的更新一下。6.5 不要忽略安全边界最后说一个容易被忽略的点skill 里一定要写清楚AI 不能做什么。比如不能自动提交代码、不能修改生产环境配置、不能删除文件而不询问。这些边界看起来是常识但 AI 在执行复杂任务的时候如果没有明确限制真的可能会做出你意想不到的操作。我在禁忌部分通常会写三到五条硬性规则实测下来能避免绝大多数误操作。关于 skills 这个话题能聊的还有很多比如怎么给 skill 做版本管理、怎么在 CI 里自动校验 skill 的格式、怎么把 skill 和现有的 lint 工具结合起来。但上面这些是我觉得最核心、最实用的部分。如果你刚开始接触建议先从写一个最简单的 skill 开始跑通了再慢慢加复杂度。别一上来就搞大而全的东西那样很容易受挫。 Agent Skills 实战：从 SKILL.md 到可复用 AI 能力模块
1. 从“skills”这个热词说起它到底是什么为什么突然火了最近几个月不管是在技术社区还是各种开发者群聊里“skills”这个词出现的频率高得离谱。如果你只是偶尔刷到可能会以为它说的是“技能”这个泛泛的概念但只要你稍微往深里看一眼就会发现大家讨论的其实是Agent Skills——一种让 AI 编程助手比如 Claude Code、Codex 这类工具具备可复用、可组合、可版本管理的“能力模块”的机制。说白了以前我们用 AI 写代码每次都得把上下文、规范、项目结构重新喂一遍效率低不说结果还不稳定。而 Skills 的出现本质上是把“怎么做一个特定任务”这件事从一次性的对话里抽出来变成一个独立的、有结构的文件包。这个文件包里最核心的就是SKILL.md它用自然语言加少量元数据的方式告诉 AI 在什么场景下该调用什么能力、按什么步骤执行、注意哪些边界条件。我最早接触这个概念是在一个前端项目里当时团队想让 AI 帮忙统一处理组件的命名规范和目录结构。一开始大家都是把规则写在 prompt 里但每次新开一个会话就得重新贴一遍而且不同人写的 prompt 风格不一样AI 的输出也飘忽不定。后来有人提议把这套规则做成一个 skill放在项目根目录的.skills文件夹下结果整个流程一下子就稳了——不管谁用、什么时候用只要触发条件匹配AI 就会自动加载这个 skill按同样的逻辑干活。所以如果你问我 skills 解决了什么问题我的回答很直接它解决的是 AI 辅助开发中“重复劳动”和“一致性缺失”这两个老大难问题。适合谁来学我觉得只要你在日常工作中会用到 AI 编程工具不管是前端、后端、数据科学还是数学建模都值得花点时间了解一下。哪怕你暂时不打算自己写 skill至少要知道怎么安装、怎么用别人分享的 skill这已经能帮你省下大量重复沟通的成本。2. Skills 的核心机制拆解为什么是 SKILL.md而不是别的2.1 SKILL.md 的设计哲学让 AI 自己决定什么时候用很多人第一次看到SKILL.md的时候会有点懵——这不就是一个 Markdown 文件吗凭什么它能让 AI 变聪明这里面的关键不在于文件格式本身而在于它的内容结构和加载时机。一个典型的SKILL.md通常包含几个部分顶部的元信息比如 name、description、trigger 条件中间的步骤说明以及底部的示例和边界情况。AI 在运行时会先扫描所有可用的 skill然后根据当前对话的上下文判断哪个 skill 的 trigger 条件被满足了再把对应的内容加载进上下文。这个过程是按需加载的不需要你手动切换也不需要你把所有规则都塞进系统提示里。我打个比方以前的 prompt 就像你每次做饭都得把菜谱从头念一遍给厨师听而 skill 就像你把菜谱写好了放在架子上厨师看到你今天点了红烧肉自己就去把对应的菜谱抽出来照着做。这个“自己抽”的动作就是 skill 机制最值钱的地方。2.2 和传统 prompt 工程的区别从“一次性”到“可积累”传统 prompt 工程最大的问题是不可积累。你今天调好了一个很满意的 prompt明天换个会话、换个模型版本可能就失效了。而且 prompt 通常是写在对话里的没法版本管理没法 code review更没法分享给团队其他人复用。Skills 把这件事变成了工程化的。SKILL.md可以放在 Git 仓库里可以写 changelog可以打 tag可以像代码一样做 review。你改了一版 skill团队里所有人拉下来就能用效果是一致的。更重要的是skill 可以被组合——一个 skill 可以依赖另一个 skill就像函数调用一样。这种可组合性让复杂任务的拆解变得非常自然。2.3 触发机制与上下文管理AI 是怎么“想起”某个 skill 的这里涉及一个很多人忽略的细节skill 不是越多越好。如果你在项目里塞了几十个 skillAI 在判断该用哪个的时候反而容易出错因为 trigger 条件之间可能会打架。我实测下来一个项目里同时激活的 skill 最好控制在 5 到 8 个以内超过这个数量AI 的调用准确率会明显下降。触发机制一般有两种一种是关键词触发比如 skill 的 description 里写了“当用户提到组件命名规范时使用”那 AI 看到相关关键词就会加载另一种是显式调用比如你在对话里直接说“用 xxx skill 来处理这个任务”。前者更自然后者更可控。我的建议是两者结合——日常用关键词触发关键任务用显式调用兜底。3. 从零开始写一个自己的 Skill完整实操流程3.1 环境准备你需要什么工具和目录结构先说清楚写 skill 本身不需要什么特殊环境一个文本编辑器加一个 Git 仓库就够了。但如果你想让 skill 真正跑起来得确保你用的 AI 编程工具支持这个机制。目前 Claude Code 对 skills 的支持比较成熟Codex 这边也在跟进具体版本要求建议看官方文档的最新说明。目录结构方面我习惯在项目根目录下建一个.skills文件夹里面每个 skill 一个子目录子目录名就是 skill 的标识符。比如.skills/ component-naming/ SKILL.md examples/ good-example.tsx bad-example.tsx api-error-handling/ SKILL.md每个 skill 目录里至少有一个SKILL.md如果有示例文件或者辅助脚本可以放在同级目录下在SKILL.md里用相对路径引用。3.2 写好 SKILL.md 的五个关键部分我写过的 skill 不算多但踩过的坑不少。总结下来一个能稳定工作的SKILL.md应该包含以下五个部分第一部分是元信息头。通常用 YAML front matter 的格式写在文件最上面包括 name、description、version、trigger 这几个字段。description 要写得具体但不啰嗦trigger 要覆盖你希望 AI 自动加载这个 skill 的典型场景。第二部分是目标说明。用一两句话讲清楚这个 skill 是干什么的解决什么问题。这部分是给 AI 看的也是给以后维护这个 skill 的人看的。第三部分是执行步骤。这是核心内容要按顺序列出 AI 应该怎么做。每一步都要具体到可执行的程度不要写“优化代码结构”这种模糊的话而要写“检查每个组件的文件名是否以 PascalCase 命名如果不是重命名为 PascalCase”。第四部分是示例。给一两个正例和反例让 AI 知道什么算做对了什么算做错了。示例不用多但要有代表性。第五部分是边界和禁忌。明确告诉 AI 在什么情况下不要用这个 skill或者执行过程中有哪些绝对不能做的事。这部分很多人会忽略但实际用起来能避免大量误操作。3.3 一个真实案例前端组件命名规范 skill下面是我实际在用的一个 skill 的简化版你可以直接参考这个结构来写自己的--- name: component-naming description: 统一 React 组件的文件命名和导出规范 version: 1.2.0 trigger: - 用户提到组件命名 - 用户要求整理组件目录 - 新建组件文件时 --- ## 目标 确保项目中所有 React 组件的文件名、导出名和目录结构保持一致。 ## 执行步骤 1. 扫描 src/components 下所有 .tsx 文件 2. 检查文件名是否为 PascalCase如果不是重命名 3. 检查默认导出名是否与文件名一致如果不一致修正 4. 检查每个组件是否放在以组件名命名的子目录中 5. 如果组件有配套的样式文件或测试文件确保它们在同一目录下 ## 示例 正例src/components/UserProfile/UserProfile.tsx 反例src/components/user-profile/index.tsx ## 边界 - 不要修改 node_modules 下的任何文件 - 不要重命名已经被其他文件引用的组件除非同时更新所有引用 - 如果组件名和文件名冲突无法自动解决停下来询问用户这个 skill 写完之后我们团队里不管谁用 AI 整理组件输出都是一致的。以前每次都要在对话里重复一遍规则现在完全不用了。3.4 调试和迭代怎么知道 skill 写得好不好写完一个 skill 只是开始真正花时间的是调试。我的做法是先在小范围试比如拿一个具体的任务让 AI 跑一遍看它有没有正确加载 skill、有没有按步骤执行、有没有在边界情况下停下来。如果发现 AI 没加载 skill通常是 trigger 写得不够具体或者 description 和实际对话的匹配度不高。如果加载了但执行不对多半是步骤写得太模糊或者示例不够有代表性。如果 AI 在边界情况下乱来那就是禁忌部分没写清楚。我一般会迭代三到五版才觉得一个 skill 比较稳。每次改完都记一下改了什么、为什么改这样后面维护的时候不至于忘了当时的思路。4. 安装和使用别人分享的 Skills少走弯路的实操建议4.1 从哪里找现成的 skill现在网上分享 skill 的地方越来越多GitHub 上搜SKILL.md或者agent-skills能出来一大堆。比较活跃的仓库通常会有分类目录比如前端开发、数据处理、数学建模、文档写作等等。我建议优先找star 数高、最近有更新、有实际使用案例的仓库不要随便下一个来路不明的 skill 就往项目里塞。另外有些 skill 是跟特定工具绑定的比如专门给 Claude Code 用的或者专门给 Codex 用的。下载之前看清楚兼容性说明不然装上去可能根本不生效。4.2 手动安装 skill 的完整步骤假设你在 GitHub 上找到了一个想要的 skill手动安装的流程大概是这样的把仓库 clone 到本地或者直接下载 zip 包解压找到里面包含SKILL.md的目录通常一个 skill 一个目录把整个 skill 目录复制到你项目的.skills文件夹下检查SKILL.md里的 trigger 条件是否和你的项目场景匹配不匹配就改一下重启你的 AI 编程工具让它重新扫描 skill 目录在对话里测试一下看 AI 能不能正确加载注意有些 skill 会依赖外部脚本或者特定的环境变量装之前一定要看 README 里的依赖说明不然跑起来会报错。4.3 常见安装问题排查我遇到过几次装完不生效的情况排查下来基本是这几个原因问题现象可能原因解决方法AI 完全不加载 skill目录结构不对SKILL.md 不在正确位置确认 skill 目录直接放在 .skills 下不要多套一层加载了但执行报错缺少依赖或环境变量看 SKILL.md 里的依赖说明补齐缺失项多个 skill 冲突trigger 条件重叠精简 trigger或者改成显式调用改了 skill 不生效工具缓存了旧版本重启工具或者手动清除缓存目录4.4 使用别人 skill 的注意事项别人的 skill 再好也是为别人的项目场景写的。直接拿来用之前我建议至少做三件事读一遍 SKILL.md 的每一步确认没有你不希望 AI 执行的操作检查示例是否符合你的项目规范不符合就改掉在测试分支上先跑一遍确认没问题再合到主分支。还有一点很重要不要同时装太多功能重叠的 skill。比如你装了两个都是处理代码格式化的 skillAI 在触发的时候就会犹豫甚至可能两个都加载导致指令冲突。我的做法是同类功能只保留一个其他的要么删掉要么改成手动调用。5. 进阶玩法把 Skills 组合起来解决复杂任务5.1 Skill 之间的依赖和调用单个 skill 能解决的问题是有限的真正有意思的是把多个 skill 组合起来。比如你可以有一个 skill 负责代码规范检查另一个 skill 负责生成测试用例第三个 skill 负责更新文档。当你说“帮我重构这个模块”的时候AI 可以依次加载这三个 skill按顺序执行。实现这种方式的关键是在 skill 的步骤里显式引用其他 skill。比如在重构 skill 的最后一步写“调用 test-generation skill 为修改后的代码生成测试”。这样 AI 就知道该去加载哪个 skill 了。5.2 用 skill 做数学建模和数据分析我看到不少人在讨论数学建模比赛里怎么用 skills。说实话这个场景特别适合。数学建模的流程通常是固定的理解问题、选择模型、写代码求解、分析结果、写论文。你可以把每个阶段做成一个 skill比如“模型选择 skill”里写清楚什么类型的问题该用什么模型“论文写作 skill”里规定好摘要、假设、符号说明的格式。这样不管题目怎么变AI 都能按同样的流程帮你推进不会因为换了个题目就完全不知道从哪下手。我试过用这种方式辅助写代码效率提升很明显尤其是那些重复性的数据预处理和可视化部分。5.3 团队协作中的 skill 管理如果是团队一起用 skill我强烈建议把.skills目录纳入 Git 管理并且制定一个简单的 review 流程。谁想加新 skill提个 PR其他人看一下 trigger 条件有没有冲突、步骤有没有歧义、禁忌有没有遗漏。合并之后所有人拉下来就能用同一套能力。另外skill 也要写 changelog。每次改了什么都记一下这样当 AI 的行为发生变化时你能快速定位是哪个 skill 的哪次改动导致的。6. 我踩过的坑和总结出来的经验6.1 不要试图用一个 skill 解决所有问题我一开始写 skill 的时候总想写一个“万能 skill”把所有规范都塞进去。结果就是 trigger 条件写得特别宽泛AI 动不动就加载它加载之后又因为步骤太多太杂执行到一半就乱了。后来我学乖了一个 skill 只做一件事做精做透。需要多个能力的时候用组合的方式解决而不是堆在一个文件里。6.2 trigger 要具体但不要过于狭窄trigger 写得太宽skill 会被频繁误加载写得太窄又可能该加载的时候不加载。我的经验是用具体的动作词加对象词比如“当用户要求重命名组件文件时”就比“当用户提到组件时”好得多。同时可以留一两个稍微宽泛的 trigger 作为兜底但不要超过三个。6.3 示例比描述更有用AI 对示例的敏感度远高于对抽象描述的理解。与其写“代码要整洁”不如直接给一段整洁的代码和一段不整洁的代码让 AI 自己去对比。我后来写 skill 的时候示例部分花的时间比步骤部分还多但效果确实好很多。6.4 定期清理不再使用的 skill项目在变skill 也要跟着变。有些 skill 可能半年前很有用但现在项目结构改了它已经过时了。如果不清理这些过时的 skill 会干扰 AI 的判断。我一般每个月花十分钟过一遍.skills目录把不再用的删掉把需要更新的更新一下。6.5 不要忽略安全边界最后说一个容易被忽略的点skill 里一定要写清楚AI 不能做什么。比如不能自动提交代码、不能修改生产环境配置、不能删除文件而不询问。这些边界看起来是常识但 AI 在执行复杂任务的时候如果没有明确限制真的可能会做出你意想不到的操作。我在禁忌部分通常会写三到五条硬性规则实测下来能避免绝大多数误操作。关于 skills 这个话题能聊的还有很多比如怎么给 skill 做版本管理、怎么在 CI 里自动校验 skill 的格式、怎么把 skill 和现有的 lint 工具结合起来。但上面这些是我觉得最核心、最实用的部分。如果你刚开始接触建议先从写一个最简单的 skill 开始跑通了再慢慢加复杂度。别一上来就搞大而全的东西那样很容易受挫。