1. 从AI写代码总差点意思说起Skill到底补的是哪块短板用AI编程工具写过几年代码的人大概都经历过同一个阶段一开始觉得惊艳随便描述个需求唰唰唰给你生成一大段能跑的代码用久了就发现它总是在某些地方差一口气——要么是项目结构不符合团队规范要么是生成的测试用例覆盖不到边界条件要么是让它改个老项目它上来就把人家精心设计的抽象层给推平了。这个差一口气的根源其实不在模型本身有多笨而在于通用模型缺少你所在场景的经验。它读过海量公开代码但没读过你们团队的代码规范文档没经历过你们踩过的那些坑不知道你们项目里那个叫utils/legacy的目录是绝对不能动的雷区。所谓Skill本质上就是把这类经验打包成模型可以调用的结构化知识。你可以把它理解成给AI助手配的一本岗位操作手册——不是教它怎么编程而是教它在我们这儿这件事应该怎么做。1500个现成Skill这个数字之所以有吸引力是因为它意味着大量常见场景已经被别人踩过坑、总结好了你不需要从零开始写。我自己的体会是Skill解决的核心问题有三个层次。第一层是格式对齐比如团队要求所有React组件必须用函数式写法加TypeScript泛型约束Skill里写清楚这个规则AI就不会再给你生成class组件。第二层是流程固化比如提交代码前必须跑哪几个lint命令、数据库迁移脚本必须放在哪个目录这些流程性的东西写进SkillAI执行任务时就会自动遵循。第三层是领域知识注入这一层最有价值也最难比如你们做的是量化交易系统那关于订单撮合、风控校验的领域规则通用模型根本不可能知道必须靠Skill补进去。注意Skill不是万能的。它补的是经验和规范补不了模型本身的推理能力上限。如果模型连基本算法都写不对再多的Skill也救不回来。理解了这一点后面关于怎么选Skill、怎么改Skill、怎么自己写Skill的讨论才有意义。很多人一上来就想着我要搞1500个Skill全装上结果发现装完反而更乱就是因为没想清楚每个Skill到底在补哪块短板。2. 1500个Skill不是让你全装的筛选逻辑与分类思路看到1500个现成Skill这个数字第一反应很容易是全都要。但我实测下来全装是灾难——AI的上下文窗口是有限的Skill太多会导致它在每次任务里都要花大量精力去判断该用哪个反而拖慢了响应速度还容易选错。正确的做法是先做场景分类再按需装载。我一般把Skill分成四大类这个分类方式不一定标准但用起来顺手。2.1 按触发时机分常驻型与按需型常驻型Skill是那些几乎每个任务都会用到的比如代码风格规范、提交信息格式、项目目录结构约定。这类Skill应该始终挂在配置里让AI形成肌肉记忆。按需型Skill则是特定场景才用的比如数据库迁移脚本生成性能压测报告模板国际化文案提取。这类Skill平时不加载等真正做相关任务时再临时挂上。判断标准很简单如果一个Skill在过去十次任务里一次都没触发过它就该被移到按需区。2.2 按作用对象分项目级、团队级、个人级项目级Skill只对当前仓库生效比如这个项目用的是Vue2而不是Vue3那相关的写法约束就属于项目级。团队级Skill跨项目通用比如整个团队都要求用Conventional Commits规范。个人级Skill则是你自己的习惯比如你偏好用async/await而不是Promise链。这个分层很重要因为不同层级的Skill优先级不同。当项目级Skill和团队级Skill冲突时项目级应该覆盖团队级——毕竟具体项目有具体约束。2.3 按内容形态分规则型、模板型、流程型规则型Skill是必须/禁止类的硬约束比如禁止使用any类型。模板型Skill提供代码骨架比如生成一个新的API路由文件时按这个模板来。流程型Skill描述多步骤操作比如发布新版本需要依次执行更新changelog、打tag、构建、上传。这三种形态的写法完全不同。规则型要写得斩钉截铁模板型要给出完整可替换的占位符流程型要写清楚每一步的输入输出和失败处理。2.4 一个实用的筛选表格筛选维度保留标准淘汰标准使用频率近一个月触发≥3次从未触发或仅触发1次维护状态最近三个月有更新超过一年未更新与现有Skill重叠度提供独特价值与已有Skill功能重复内容质量规则明确、示例完整描述模糊、缺少示例适配性匹配当前技术栈版本针对已废弃的框架版本按这个表格过一遍1500个里真正值得常驻的可能也就三五十个剩下的按需调用即可。我自己的常驻列表常年维持在40个左右超过这个数就开始互相干扰了。3. 把Skill装进Claude Code和Cursor配置路径与踩坑记录选好了Skill接下来是装。不同工具的装载方式差别挺大我分别说说Claude Code和Cursor这两个主流环境下的实操。3.1 Claude Code里的Skill目录结构Claude Code对Skill的支持是通过项目根目录下的特定文件夹实现的。我习惯的目录结构是这样的project-root/ .claude/ skills/ code-style/ SKILL.md api-template/ SKILL.md examples/ route-example.ts db-migration/ SKILL.md每个Skill一个文件夹核心是SKILL.md这个文件。文件名必须大写这是约定。SKILL.md里用Markdown写清楚这个Skill的用途、触发条件、具体规则。如果Skill需要附带示例代码或模板文件就放在同目录下在SKILL.md里用相对路径引用。这里有个坑我踩过Skill文件夹的命名不要用中文也不要用空格。我一开始图省事用了代码规范这种名字结果在某些终端环境下路径解析出问题AI死活读不到。改成code-style这种短横线连接的英文名之后就正常了。3.2 Cursor里的Skill配置方式Cursor的机制不太一样它更依赖.cursorrules文件或者项目级的规则配置。如果你想把Skill体系搬进Cursor有两种做法。第一种是把每个Skill的内容直接写进.cursorrules用分隔线隔开。这种做法简单直接但缺点是.cursorrules会变得非常长而且所有规则都是常驻的没法按需加载。第二种是建一个skills/目录存放各个Skill文件然后在.cursorrules里写一句当任务涉及XX场景时读取skills/xx/SKILL.md。这种做法更灵活但需要AI有读取文件的能力实际测试下来Cursor对文件读取的支持还算稳定。我个人的选择是常驻规则写进.cursorrules按需Skill放目录里靠引用加载。这样既保证了核心规范始终生效又不会让配置文件臃肿到无法维护。3.3 中文设置与界面适配关于Cursor的中文设置很多人第一次用会找不到地方。路径是打开设置快捷键CtrlShiftP或CmdShiftP搜索language选择Configure Display Language然后选中文。重启之后界面就变中文了。不过我要提醒一句界面语言和AI生成代码的语言是两回事。你把界面设成中文AI生成的代码注释和变量名默认还是英文。如果你希望AI用中文写注释需要在Skill里明确写代码注释使用中文否则它不会自动切换。Claude Code这边安装之后默认就是跟随系统语言不需要额外设置。如果你在VS Code里用Claude Code插件配置方式和独立版基本一致Skill目录放在项目根目录下就能被识别。3.4 一个容易忽略的细节Skill的加载顺序当多个Skill同时生效时它们的加载顺序会影响最终行为。我实测下来Claude Code大致是按文件夹名称的字母序加载的后加载的会覆盖先加载的冲突规则。这意味着如果你有两个Skill都规定了代码风格字母序靠后的那个会赢。利用这个特性你可以把项目级覆盖规则的文件夹命名成zz-project-override这种确保它最后加载优先级最高。这是个土办法但确实管用。4. 现成Skill不好用改造与自建的完整方法1500个现成Skill里真正拿来就能用的其实不多。大部分需要改造还有一些场景根本找不到现成的只能自己写。这一节说说改造和自建的具体方法。4.1 改造现成Skill的三步法拿到一个现成Skill我一般按三步走。第一步是通读并标注。把SKILL.md从头到尾读一遍用注释标出三类内容可以直接用的、需要改的、完全不适用的。这一步不要急着改先建立全局认知。第二步是替换具体值。现成Skill里通常有大量占位符或示例值比如使用/components作为组件导入路径你需要把它替换成你项目里的实际路径。这一步最机械但也最容易出错建议改完用搜索功能检查一遍有没有遗漏的占位符。第三步是补充边界情况。现成Skill往往只覆盖了正常情况缺少对异常情况的处理。比如一个生成API接口的Skill可能只说了正常返回怎么处理没说参数校验失败、权限不足、数据库连接超时这些情况怎么办。这些边界情况恰恰是实际开发中最容易出问题的地方必须补上。4.2 从零写一个Skill的模板自己写Skill我总结了一个还算好用的模板结构# Skill名称 ## 用途 一句话说明这个Skill解决什么问题。 ## 触发条件 描述什么情况下应该使用这个Skill。 ## 核心规则 1. 规则一要具体可执行 2. 规则二 3. 规则三 ## 示例 ### 正确示例 代码或操作示例 ### 错误示例 反例说明为什么错 ## 边界情况 - 情况一如何处理 - 情况二如何处理 ## 相关Skill - 与XX Skill配合使用这个模板的关键在于必须有错误示例。只告诉AI应该怎么做是不够的还要告诉它这样做是错的否则它很容易在边界情况下走偏。我写过的Skill里加了错误示例的比没加的实际执行准确率大概能高出三成。4.3 一个真实的自建Skill案例我们团队做的是一个数据可视化平台经常需要新增图表类型。每次新增都要改五六个文件而且改法很固定。我干脆写了个Skill叫add-chart-type。这个Skill的核心内容是列出需要修改的文件清单、每个文件的修改位置和修改模式、新增图表必须注册的三个地方路由、菜单、权限表、以及一个完整的示例以新增桑基图为例展示所有改动。写完之后新增一个图表类型从原来的半天缩短到二十分钟。AI会按照Skill里的清单逐个文件改我只需要最后review一遍。这个Skill大概花了我两个小时写但省下来的时间早就超过这个数了。4.4 Skill的版本管理Skill是要迭代的。我建议把Skill目录也纳入Git管理每次修改都提交commit message写清楚改了什么、为什么改。这样当某个Skill改出问题的时候可以快速回滚。另外Skill里最好加一个版本号和更新日期方便判断这个Skill是不是过时了。我见过太多团队Skill写完之后就扔在那儿没人管半年后技术栈都升级了Skill还在教AI用老写法反而帮倒忙。5. 让Skill真正生效提示词配合与Agent协作Skill装好了、改好了不代表就能高枕无忧。实际使用中Skill需要和提示词配合在Agent模式下还有额外的注意事项。5.1 Skill与提示词的分工一个常见的误区是把所有东西都塞进Skill。但Skill是静态知识提示词是动态指令两者分工不同。Skill负责的是不变的规则比如代码风格、目录结构、命名约定。提示词负责的是这次任务的具体要求比如给用户列表页加一个按注册时间排序的功能。我见过有人把这次要改哪个文件也写进Skill结果这个Skill就只能用一次完全失去了复用价值。正确的做法是Skill提供怎么做的框架提示词提供做什么的具体内容。5.2 Agent模式下的Skill触发在Agent模式下AI会自主决定调用哪些Skill。这时候Skill的触发条件描述就特别重要。如果写得太模糊AI要么该用的时候不用要么不该用的时候乱用。我的经验是触发条件里要包含具体的文件类型、任务类型、关键词。比如不要写当需要处理数据时而要写当任务涉及.csv文件读取或pandas数据处理时。越具体AI判断越准。另外Agent模式下Skill的执行是有顺序的。如果两个Skill都声称自己该触发AI会按某种优先级选择。这个优先级目前不完全可控所以我的做法是尽量避免Skill之间的功能重叠一个场景只对应一个Skill从源头上消除冲突。5.3 多Skill协作的编排技巧复杂任务往往需要多个Skill配合。比如新增一个API接口这个任务可能涉及api-template生成骨架、db-migration建表、test-template生成测试三个Skill。这种情况下我会写一个编排型Skill专门描述这个任务的完整流程并在里面引用其他Skill。编排型Skill不包含具体规则只负责串联。这样当某个子Skill更新时编排型Skill不需要改维护成本低很多。5.4 验证Skill是否生效的方法装完Skill之后怎么知道它真的生效了我一般用对照测试法同一个提示词在装Skill前后各跑一次对比输出差异。如果输出完全一样说明Skill没生效需要检查配置。还有一个更直接的方法在提示词里故意写一个违反Skill规则的要求看AI会不会纠正你。比如Skill规定禁止使用var你就在提示词里说用var声明变量如果AI坚持用let或const并提醒你规则说明Skill生效了如果它乖乖用了var说明Skill没被加载。6. 那些没人告诉你的坑Skill使用中的真实教训前面讲的都是应该怎么做这一节讲讲实际会怎么翻车。这些都是我和身边同行踩过的坑写出来希望能帮你省点时间。6.1 Skill太多导致的规则打架前面提过常驻Skill不要超过40个但即使在这个数量内规则冲突也时有发生。我遇到过最离谱的一次是一个Skill说所有函数必须写JSDoc注释另一个Skill说代码要保持简洁避免冗余注释。结果AI在生成代码时反复横跳一会儿加注释一会儿删注释最后生成的文件里注释加了一半。解决这类冲突靠的是定期做Skill审计。我现在的做法是每个月花半小时把所有常驻Skill过一遍找出互相矛盾的规则手动裁决哪个优先。裁决结果写进一个最高优先级Skill里明确声明当其他Skill与本Skill冲突时以本Skill为准。6.2 过时的Skill比没有更危险一个针对Vue2写的Skill在Vue3项目里会教AI用Options API和this.$set这些在Vue3里要么不推荐要么根本不存在。AI如果照着执行生成的代码看起来像模像样实际跑起来一堆报错。我的建议是每次技术栈升级第一件事就是审计Skill。把所有涉及被升级技术的Skill找出来要么更新要么禁用。禁用比更新快如果某个Skill暂时用不上先禁掉等有空了再更新。6.3 Skill里的示例代码会污染生成结果这是个很隐蔽的坑。Skill里的示例代码AI会当成参考风格来模仿。如果你在示例里用了某个特定的变量命名风格AI生成新代码时也会倾向于用同样的风格哪怕这个风格并不适合当前场景。我有一次在api-template的示例里用了handleUserRequest这种命名结果AI生成所有接口处理函数都叫handleXxxRequest包括那些根本不是请求处理的函数。后来我把示例里的命名改得更通用问题才解决。所以写示例的时候要小心示例要展示模式而不是具体值。能用functionName这种占位符的地方就别用具体的函数名。6.4 中文Skill的编码问题如果你的Skill文件里有中文要确保文件保存为UTF-8编码。我遇到过用GBK保存的Skill文件AI读出来全是乱码然后基于乱码内容生成了一堆莫名其妙的规则。这个问题在Windows环境下特别常见因为Windows默认编码有时候不是UTF-8。检查方法很简单用VS Code打开Skill文件看右下角显示的编码。如果不是UTF-8点一下改成UTF-8再保存。6.5 Skill不是写完就完事了最后这个坑最要命很多人把Skill当成一次性投入写完就不管了。但项目在变、团队在变、技术栈在变Skill如果不跟着变很快就会从帮手变成绊脚石。我现在给团队定的规矩是每次代码review发现AI生成的代码有问题先问一句这是不是Skill没写清楚导致的。如果是当场就把Skill改了。这样Skill就能跟着项目一起进化而不是慢慢腐化。7. 从1500到15我的Skill精简实践说了这么多最后分享一下我自己的Skill精简过程。一开始我也是贪多装了三百多个结果AI响应慢、选错Skill、规则打架各种问题。后来痛下决心做减法现在常驻的只剩15个按需调用的也就三十来个反而比之前好用得多。精简的核心逻辑是合并同类项。比如原来有五个Skill分别管React组件命名React Hook使用规范React状态管理约定React路由配置React样式方案我把它们合并成一个react-conventions内容按小节组织。合并之后AI只需要判断这是不是React任务不需要在五个Skill之间做选择准确率明显提升。另一个逻辑是砍掉低频Skill。我统计了过去三个月的Skill触发记录发现有将近两百个Skill一次都没被触发过。这些Skill要么是场景太窄要么是触发条件写得太模糊导致AI根本识别不到。对于前者我直接删了对于后者我尝试改触发条件改完还是不行就删。精简之后最大的感受是AI变聪明了。其实不是模型变了而是干扰少了。当AI不需要在几十个Skill之间纠结该用哪个时它就能把更多精力放在理解任务本身。这个道理跟人一样工具太多反而不知道用哪个顺手的那几件就够了。如果你现在正面对一堆Skill不知道从哪下手我的建议是先别管那1500个从你当前项目最痛的三个场景出发各写一个Skill用顺了再慢慢加。Skill的价值不在于数量而在于每一个都真正解决问题。