最近这一年AI编程助手的热度一直没降而“skills”这个词被提得越来越频繁。无论你用的是Claude Code、Codex还是OpenCode只要想让AI真正融入自己的项目、按团队规范干活最后基本都会绕回到skills上。说白了skills就是给AI助手装上一份可复用的“操作手册”让它遇到特定场景时知道先做什么、后做什么、产出什么格式不再张嘴就是一套通用回答。这篇文章我会从“是什么、怎么装、怎么写、怎么选、怎么清理、常见坑”六个维度展开通篇都是我自己在真实项目里折腾出来的经验。适合正在用AI写代码但觉得它“差点意思”的朋友也适合想在数学建模、AI漫剧这类具体场景里用AI干活的人参考。1. AI编程助手的Skills到底是什么1.1 一个场景看懂Skills的运行逻辑先说我踩过的一个典型坑。我让Claude Code帮忙重构一个前端组件它很快给出了改动代码也能跑。但当我追问“为什么类名没用我们项目的BEM规范”它才老老实实说“抱歉我没有看到规范文件”。问题在于你不主动提醒AI就不会主动去翻项目规范也不会按你团队的验收清单检查。Skills要解决的就是这个。我给它装了一个叫“frontend-fix”的技能包之后行为立刻变了每次接到前端改动任务它会先读CSS规范再按“目录结构确认、命名规范、依赖影响、测试补充”这个顺序执行最后给出改动清单。我不需要每次重复叮嘱。它的本质是一个目录里面通常有一个SKILL.md文件作为总指挥再加上脚本、模板、示例等辅助文件。AI在对话过程中会扫描这些技能目录一旦发现描述匹配当前任务就主动加载对应步骤。1.2 Skills目录长什么样一个标准的技能包可以长成这样.skills/ ├── frontend-fix/ │ ├── SKILL.md │ └── checklist.md └── pr-description/ ├── SKILL.md └── scripts/ └── get_diff.pySKILL.md是入口最前面是一段YAML元信息写着技能名称、描述、使用场景后面是正文告诉AI具体怎么一步一步做。辅助文件用来承接模板、脚本、数据AI需要时就去读、去执行。这里有个关键点description写得好不好直接决定技能会不会被正确触发。写得太泛AI什么都想调用它写得太窄该用的时候又无动于衷。后面我会单独展开讲。1.3 Skills和MCP、全局规则到底什么关系很多人会把Skills、MCP、CLAUDE.md三样东西搞混其实它们解决的问题不一样。MCPModel Context Protocol更像给AI接上的“手臂”用来连数据库、调API、访问外部工具核心是扩展AI的触达能力。Skills更像给AI注入的“行为方式”解决的是“它到底该怎么干活”的问题。至于CLAUDE.md这类全局规则文件我习惯把它理解成公司制度手册常驻且影响所有对话而Skills是岗位专用的细碎SOP按需触发。举个例子CLAUDE.md可以规定“所有代码必须补测试”而一个“bug-reproducer”技能则告诉AI怎么把复现步骤写成脚本。两者可以共存但别把所有内容都堆进全局规则否则每次对话都要背着沉重的包袱。2. 从GitHub手动安装一套现成Skills2.1 该去哪里找SkillsGitHub是目前最集中的来源搜awesome-claude-skills这类聚合列表能一次看到几十个项目。比较典型的有两类一类是官方示例仓库比如Anthropic的skills示例结构规范、适合学习另一类是社区合集比如superpowers作者把大量经过实战打磨的技能包集中管理。还有一个source是开发者的个人博客或个人仓库经常有人针对某个领域沉淀出非常细的技能比如专门做React组件代码审查专门做Git提交信息规范。这些大而全的项目和小而精的个人项目我建议都关注但别急着全装。有些技能库还提供网页版目录可以在浏览器里先浏览每个技能的说明、触发描述、目录结构再看值不值得下载。这个环节我称之为“装前调研”能省下后面不少清理时间。2.2 Claude Code手动安装步骤我最早接触的是Claude Code的Skills机制安装路径分两种项目级和用户级。项目级放在当前项目根目录的.skills/下跟随项目走用户级放在~/.claude/skills/下所有项目都能用。手动从GitHub装一个技能包流程就三步。第一步把仓库拉下来我一般用一个临时目录存放git clone https://github.com/example/example-skills.git ~/tmp/example-skills第二步看仓库结构找到目标技能目录复制到指定位置。如果只想给当前项目用mkdir -p .skills cp -r ~/tmp/example-skills/skills/frontend-fix .skills/如果想全局生效就换成mkdir -p ~/.claude/skills cp -r ~/tmp/example-skills/skills/frontend-fix ~/.claude/skills/第三步是验证。我习惯直接在对话里问AI“你现在有哪些可用的skills”如果它能列出刚安装的名字说明扫描成功。要是它答不上来先确认目录名称没有拼错再确认SKILL.md的存在和格式。2.3 Codex和OpenCode的安装差异Codex里Skills的概念也在快速演进。大体上也是把技能目录放到它扫描的路径再靠description触发但具体配置项和全局配置文件名不一样。OpenCode则更像是把Skills当成插件体系的一部分安装后可以在配置文件中启用或禁用。我自己有个建议不要因为工具不同就重复造轮子。技能内容本身用SKILL.md这种通用结构来描述真正迁移时改的只有目录位置和触发层面的配置。很多技能包换一个工具之后只是路径变了、格式微调核心逻辑可以继续复用。在我个人经验里先从Claude Code把机制和写作方法跑通再迁移到其他工具是最顺的路线。3. 开发属于自己的AI Skills3.1 SKILL.md的骨架写Skills没有太多玄学核心就是SKILL.md。文件最上方是YAML元信息--- name: pr-description description: 当用户需要生成或优化Pull Request描述时使用。适用于GitHub工作流包含diff分析和风险提示。 ---然后是正文正文一定要按步骤写让AI能一步步执行。我写过不少技能最大的体会是给AI写SOP要像给新同事做交接文档一样把前置条件、执行顺序、输出格式、禁区通通写清楚。一个合格的正文骨架大致包含任务目标、执行步骤、输出模板、注意事项。步骤用有序列表每步控制在几行以内关键地方加粗强调。别写长篇大论AI真正执行时偏好简洁明确的指令内容太长反而会稀释关键信息。3.2 description如何精准触发description是整个技能最容易“翻车”的地方。我早期写过一个代码审查技能description写的是“帮助用户进行代码审查”结果写前端、写脚本、写SQL时它都跳出来抢活特别烦人。后来我把description拆成“什么时候用”和“什么时候不要用”两部分“当用户要求审查代码、关注bug、性能、安全隐患时使用进行风格讨论或单纯重构时不要触发。”这下触发准多了。触发写清楚比写一大堆执行逻辑更管用因为错过触发条件执行逻辑写得再好也白搭。3.3 实测一个PR描述生成器我拿自己最近在用的pr-description技能做个完整示意。它的目标是每次打开Pull Request时自动产出结构清晰的描述文本。SKILL.md正文我会这样写# PR描述生成器 执行步骤 1. 读取当前分支相对于主分支的完整diff变化。 2. 按文件类型归类本次改动推断改动的业务目标。 3. 按下面模板生成描述 - 背景与目的用两三句话解释为什么有这次改动。 - 主要变更按模块列出每条不超过一行。 - 影响范围标注涉及页面、接口、数据库表等。 - 风险与回滚列出可能受影响的点以及回滚方式。 - 测试建议给出应该执行的测试命令或手工验证路径。 4. 如果diff里出现TODO、调试日志、临时注释单独列出一节“待清理项”。 5. 不使用模糊形容不用“若干优化”这种话全部落到具体文件和行为。配套脚本get_diff.py会负责把diff拉出来、按文件类型做个初步分类AI再在这个基础上组织语言。整个技能只有几十行指令加一个脚本但效果比我手动写PR模板稳定得多。实际操作中有一个很关键的参数调整把“影响范围”写得太宽时AI会把所有改动都标成“可能有影响”等于没写。我后来在技能里加了一句规则——只有明确关联的模块才写进影响范围没把握的字段写进“待确认”。语气强硬一点AI输出质量立刻上去。4. 按场景选Skills前端、数学建模、AI漫剧4.1 前端开发场景前端是Skills最容易见到效果的方向之一。原因很简单前端规范多、实践杂、反馈路径清晰。我目前保留的高频技能有代码审查、样式语义化修复、性能排查和依赖升级这几类。以性能排查为例技能会把“先看Network加载瀑布、再查主包体积、再检查渲染次数”这个顺序固定下来并且要求给出具体数值不许只说“性能可能有问题”。以前我手动排查一次要半小时现在技能把路径固定住AI几分钟就能给出候选清单我再人工复核一遍就行。代码审查类技能也值得装。它会要求AI在审查时按“正确性、可维护性、性能、安全”四层依次过每一层都给出结论和证据。这种结构化输出比单纯让AI“看看有没有问题”专业得多。4.2 数学建模比赛场景华为杯这类数学建模竞赛特点是时间紧、任务重、环节多。比赛期间我见过太多团队把AI当成橡皮擦想到什么问什么最后一大堆垃圾代码和片段。真正管用的做法是提前给比赛场景写一套完整Skills。我是这样设计比赛技能包的它被拆成“赛题解析、数据清洗、模型选型、论文写作、图表规范”五个子技能由总控技能串起来。总控技能在比赛第一天做的第一件事是让AI输出一份作战日历第一天完成赛题拆解和初步模型选型第二天出结果并做敏感性分析第三天集中写论文和画图。模型选型子技能则规定上场先判断数据规模、特征类型、精度要求再决定用统计模型还是机器学习模型不许一上来就上最复杂的深度学习。用过一轮之后我感触很深Skills在数模比赛里最大的价值不是让AI替你做决策而是把团队过去踩过的坑固化成SOP避免AI在关键节点上带着你一起跑偏。4.3 AI漫剧制作场景AI漫剧是另一个讨论度很高的方向。和编程不一样制作漫剧的核心痛点是角色一致性、分镜连贯性和叙事节奏。这些正好都可以做成Skills。我给朋友搭过一套AI漫剧工作流其中最关键的是角色一致性技能。它会要求AI在生成任何角色画面之前先读取角色的设定文档再按设定里的外貌特征、服饰细节、表情基准去写生成提示词每次生成后还自动做一致性检查。没有这种硬性约束AI经常把同一个角色画得千变万化。分镜脚本技能也很实用。它规定每一集先产出分镜表列清楚景别、时长、台词、旁白、情绪目标再进入画面生成环节。有了这个流程整个团队在后期整合素材时不用来回返工。AI漫剧领域的Skills还比较新但它的底层逻辑和编程场景完全一致把不确定的AI行为约束成可复现的流程。4.4 场景对照速查我把几个常见场景和推荐技能方向整理成了一张表方便大家直接对照使用场景推荐技能方向核心价值前端开发代码审查、样式规范、性能排查减少人工审查成本输出结构化结论数学建模赛题解析、模型选型、论文写作把比赛时间节点固定住防止跑偏AI漫剧角色一致性、分镜脚本、旁白节奏稳定角色形象减少后期返工日常开发PR描述、提交信息规范、运行日志分析让协作信息更整洁少出沟通误会数据工程数据清洗检查、ETL流程生成、质量校验把脏数据问题提前暴露在流程中有一点想特别提醒装技能之前先问自己“这个场景我是不是至少每周遇到一次”。如果不是就先放着别为偶尔的需求增加AI的负担。5. Skills不是越多越好维护、更新与清理5.1 为什么技能装多了AI反而变笨Skill的触发机制是靠AI扫描description来判断的。技能数量多了之后每一次交互AI都要拿当前请求去匹配几十个description选择噪音会明显变大。还有一层隐形开销有些技能会在触发后把附带模板、脚本信息一起读进上下文token消耗也会上升。我做个不太严谨但很直观的比喻给AI塞50本岗位SOP它可能连该翻哪本都不知道塞3本和工作紧密相关的它翻起来很快执行也到位。所以技能库的精简不是省存储而是在帮AI降低决策成本。我自己的准则是一个项目里长期启用的技能控制在五个以内冷门技能放到归档目录真想用的时候再移回来。这样既不影响日常效率也不用频繁卸载重装。5.2 一套实测有效的清理方法之前看到tibo分享过skills清理思路我自己沿用并改了一版现在固定用这套方法。第一步让AI一次性列出它当前能识别到的所有技能把名字、描述、触发场景一起导出来。第二步把过去一周你主动使用过的技能打钩再看哪些技能是从安装到现在都没被触发过的。第三步最关键把没触发过的技能全部移到archive-skills/目录而不是直接删除。保留它们是为了防止哪天突然要用时找不到但移出主目录之后它们不再参与AI的日常扫描也就不会干扰判断。我每次清理完都会明显觉得AI回答质量回到正常水准。最后一步是收缩保留技能的description把一些过宽的描述改窄。这个动作看起来小效果却很显著。我试过把一个通用审查技能改成“只处理前端组件审查”之后误触发率直接降下来。5.3 更新与备份策略我从GitHub装技能时仓库经常在更新。我的做法是不轻易拉最新版先看更新说明如果只是修描述或加示例不一定需要升级但如果是修复了已知的触发错误就值得更新。更新之前先把当前版本复制成带日期后缀的备份目录万一新版不顺手随时回滚。自己的技能同样需要用Git管理。我每个技能对应一个独立仓库每次优化都写清楚commit message比如“调整PR技能的description减少在重构场景的误触发”。时间长了之后这些commit记录就是最好的技能演进日志比任何文档都有说服力。6. 实战问题实录装上Skills前后的那些坑6.1 技能装好了却不触发最典型的问题就是“明明把SKILL.md放进去了AI却像没看见”。我先排查路径项目级还是用户级放错地方就会失效。再排查文件名SKILL.md的拼写不能错大小写也有讲究。第三个排查点是frontmatter如果YAML格式解析失败整个技能目录会被AI跳过而且通常没有任何报错提示。所以我自己养成了一个习惯刚装完技能先不干别的直接问AI“你现在有哪些可用技能”。只要它能正常报出技能名字和描述就说明扫描正常。这一步永远是第一步不做的话后面全是白忙。6.2 两个技能互相打架当多个技能的description都匹配同一个请求时AI有可能会把两边的指令混在一起执行输出就会变得很奇怪。比如一个“代码审查”技能要求循序渐进另一个“快速重构”技能要求立即给出改动方案两者撞上时AI容易两头下注结论时左时右。解决办法有两个。一个是从源头避免把冲突技能的触发描述写得互斥明确限定各自的使用边界。另一个是在项目级目录下只保留真正需要的那一个其他技能移到用户级或者归档目录。项目级技能的优先级通常更高可以用这一点来控制大局。6.3 模型版本造成的兼容性问题就算一切都装对了模型本身对Skills的理解能力也有差异。越新的模型对复杂指令的分步执行越稳定。我遇到过一次情况技能内容完全没变升级模型之后输出质量突然大幅提升原因就是新模型更擅长按步骤执行长指令。如果你的技能在某个模型上表现不稳定先别急着改技能内容试试相同技能在不同版本模型下的表现。一次小规模对比就能避免你白改一大堆描述。这个问题常被忽视值得记在排查清单里。6.4 脚本依赖与工作目录当Skill通过脚本读取项目数据时最容易遇到两类问题。一类是python脚本依赖的第三方库没装脚本报错后AI可能会直接跳过脚本输出残缺结果。我现在的做法是在SKILL.md里写清楚前置依赖甚至让技能先检查依赖、缺失就给出安装命令而不是硬跑。另一类是工作目录问题。AI执行脚本时当前工作目录可能不是项目根目录导致相对路径全部失效。我会在技能里明确要求“先定位到项目根目录再执行脚本”并且脚本里都用相对项目根的路径不依赖bash启动时的目录。这些小细节往往决定了技能能不能在真实项目里稳定复现。6.5 一份快速排查清单我把常见问题压缩成一张速查表遇到问题直接按表查问题现象可能原因处理方式技能完全没有触发目录位置不对、SKILL.md缺失核对路径与文件名让AI列出技能验证触发太频繁、抢活description写得太泛给描述加上明确的触发边界输出结果混乱多个技能同时匹配写互斥描述或只保留一个技能脚本报错、输出残缺第三方库缺失、工作目录不对在技能里写前置依赖固定工作目录升级后表现变差模型或上游仓库变化备份回滚对比模型版本后再调整这份清单陪我躲过了很多莫名其妙的问题。现在每遇到一个奇怪现象我都会先问自己它到底是被哪一层影响到的是路径、描述、脚本还是模型本身逐层排除技能最终都能稳定下来。我个人的体会是Skills这个东西价值不在于“装得多”而在于“用得好”。我从见啥装啥的阶段一路走过来最后保留在常用清单里的也就不到十个。真正让AI能力上一个台阶的是把少数几个技能打磨到极致让它在每次触发时都输出稳定、可预期的结果。最后再分享一个小技巧调完技能后让AI在回答末尾加上一句“本次遵循了技能里的哪些步骤”这样一眼就能看出技能是真正生效还是在假装工作。这个习惯帮我减少了很多无效调试也希望大家能从中得到帮助。