最近身边好几个搞前端的朋友都在折腾“skills”打开GitHub一搜跟AI辅助开发相关的skills仓库已经多到看不完。Claude Code、Codex、OpenCode这些主流AI编程助手也都在往同一套叫“skills”的能力体系上靠。很多人第一反应是这不就是插件吗我的看法是它比插件更轻但比提示词更重本质上是给AI编程助手配一套标准化的“作业指导书”。这篇文章想聊透一件事AI skills到底是什么、怎么从GitHub手动装、怎么写一个自己用的、哪些场景真正值得配以及技能包攒多了之后怎么收拾。适合正在用Claude Code或Codex写代码、参加数模竞赛、做AI内容生产的人也适合纯粹想搞懂这套新玩意的技术爱好者。1. Skills不是插件是给AI的生产力SOP先说概念。Claude Code、Codex这波工具里说的skills指的不是模型参数也不是什么可执行插件而是一个有固定格式的能力包以目录为单位里面放一个核心说明文件和配套的资源文件比如模板、脚本、示例。这个目录被放到指定路径后模型在对话过程中会根据任务内容自行判断“该不该读这份说明”读了就按说明里的流程干活。听起来是不是很像SOP标准作业程序我一直觉得这个类比最贴切。插件是给软件装外挂模块而skills是给一个“每次对话都像刚睡醒的重度失忆员工”准备的操作手册。AI模型本身很强但它不会记得你上周跟它说过的偏好也不会自动掌握一套复杂任务的固定动作。Skills的作用就是把那些“你希望它每次都能稳定做对”的事情写成一套它随时能翻到的作业指导书。它和普通提示词的区别在于调用逻辑。你把一套复杂规则贴在每次对话里既占上下文窗口模型也未必抓得住重点而skills文件放在一边只在任务匹配时被模型主动读取。换句话说普通提示词是你追着模型喊“记住这个”skills是模型自己需要时去查手册。这个区别在长会话里特别明显——指令不会随着对话变长而被稀释。跟MCP模型上下文协议这类工具相比skills也更轻。MCP适合接外部数据源和操作外部系统而skills几乎不需要什么基础设施一个文件加一个目录就能跑起来天然自带“人肉可读”属性随手改随手生效。要类比的话MCP像是给AI接了API接口skills更像是给AI做了入职培训。再往深一层说skills这套机制能火起来根本原因是它把“模型能力”和“业务经验”做了解耦。模型本体的能力升级不用等工具厂商只要你把经验沉淀成skills文件换一个更强的模型也能继续复用。这个特性在Codex、OpenCode这些开源方案里尤其有价值——因为你攒下的技能资产不会因为换工具而清零。2. 三分钟上手把GitHub上的skills装进主流编程助手现在实战。这里重点回答一个高热问题Claude Code怎么手动装GitHub上的skills。很多人的困惑是仓库里文件那么多到底要克隆哪些、放哪里、怎么让工具识别到。2.1 先摸清技能目录的存放规则手动安装的核心就是一条找到SKILL.md文件所在的那个文件夹把它整体放到工具能扫描到的地方。SKILL.md是技能包的入口文件你可以把它理解成说明书首页——YAML格式的开头定义技能的元信息后面的正文写具体操作流程。不同工具的扫描路径略有差异但大逻辑一致Claude Code项目级放到.claude/skills/用户级放到~/.claude/skills/Codex项目级.codex/skills/用户级~/.codex/skills/OpenCode通常在配置目录下的skills/子目录用户级和项目级的区别一句话说清用户级是你给所有项目配的通用技能适合放代码审查习惯、提交信息规范这类恒定规则项目级跟着特定仓库走适合放跟业务绑定的流程比如这个项目的架构约定、测试要求。团队协作时项目级技能可以直接提交到仓库里所有人拉到代码就自动拥有同一套规则。2.2 手动安装的标准动作假设你在GitHub上找到一个很想要的skill仓库手动安装分四步把仓库clone到本地或者直接下载ZIP。在仓库里找到包含SKILL.md的那个目录。注意看目录结构——有些仓库把几十个skill按文件夹分好了你要的不是整个仓库而是其中单个技能文件夹。把这个文件夹复制到目标路径。以Claude Code用户级安装为例就是把技能文件夹复制到~/.claude/skills/下复制完目录结构长这样~/.claude/skills/技能名/SKILL.md。记住这层关系技能文件夹的直接子级必须有SKILL.md否则扫描不到。重启会话或执行工具的重载命令然后直接测试用一句能触发该技能的话提问看模型是否表现出遵循了技能里的规则。我特别想提醒一个坑GitHub上有不少skill仓库是直接把整个项目打包发布的下载下来是嵌套目录层层套娃。你需要核对清楚SKILL.md是不是在技能文件夹的一级子目录下。我之前装一个documents转换skill明明放对了路径却一直不生效排查半天发现是文件夹套了一层仓库外壳SKILL.md被埋在了二级子目录。所以装完第一件事就是检查路径深度。2.3 验证装没装上别只看目录目录对了不一定代表能用。最简单的验证方式是直接对话测试。比如你装了一个“PR描述生成器”的skill就故意用“帮我写这个分支的PR描述”这种带触发场景的话开口。模型如果调用了技能回答风格和流程会明显按照SKILL.md里的规则来比如主动问你提交范围、按模板产出内容。想看得更细的话可以开启工具的输出追踪功能。Claude Code会用日志记录模型读取了哪些文件那里能看到技能文件是否真的被读取。这个方法比猜可靠一百倍。装完技能没反应九成是描述和触发场景写得不对或者放错了路径这两类问题靠日志一查一个准。顺带提一下superpower skills这类聚合包。网上很多人问“superpower skills怎么安装”这类聚合包通常以插件市场或安装脚本形式提供仓库README里会有明确的一键安装命令。但如果你不想一键脚本改变你现有的配置结构或者所处的网络环境不方便执行在线安装那就回到手动安装的老路子把它们拆解成一个个标准技能文件夹按上述规则逐个放进skills目录。手动装虽然麻烦点但每个技能都在哪儿、内容是什么你心里有数后续清理也方便。3. 手写第一个Skill规则、模板与描述的艺术说完了装现成的来聊聊怎么自己写。很多人在“AI skills怎么写”这个搜索词上卡住其实核心就一套格式套路一个SKILL.md文件 按需配套资源文件。3.1 框架SKILL.md的两段式结构一个标准的SKILL.md长这样--- name: pr-description-writer description: 当用户要求撰写或优化Pull Request描述、且提供了分支或提交信息时使用。输入是git分支名、提交记录输出是结构化PR描述。 --- # PR描述生成器 ## 角色与目标 你是一名资深代码审查者负责把git改动整理成清晰可读的PR描述。 ## 执行步骤 1. 先运行 git log 和 git diff 获取改动范围。 2. 按改动类型将提交归类功能新增、Bug修复、重构、文档。 3. 对每个类别用一行话概括核心改动不展开细节。 4. 最后生成模板化PR描述包含标题、背景、改动清单、测试建议。 ## 输出格式 markdown ## 标题 ... ## 背景 ... ## 改动清单 - ... ## 测试建议 - ...禁忌不要编造提交中没有出现的改动。不要使用Emoji。如果改动过大优先询问用户是否需要按模块拆分。frontmatter里最重要的字段是两个name 和 description。name是技能的唯一标识description则决定模型“什么时候该读这个文件”。读文件这个动作是模型自主判断的而判断依据就是description是否匹配当前任务。 ### 3.2 描述字段写得越具体命中率越高 我在刚学写skills时犯过一个极其典型的错误把description写成“用于生成PR描述”。这么写的作用约等于没说——因为模型面对“帮我把这些改动整理一下”这类真实口语触发时根本不会把这句话跟PR描述关联上。 一份好description要包含三个要素触发场景、输入来源、输出目标。拿上面那个示例来说触发场景是“用户要求撰写或优化Pull Request描述”输入来源是“提供了分支或提交信息”输出目标是“生成结构化PR描述”。模型拿到这个描述就能在杂七杂八的请求中精准判断“现在该调用这个技能了”。 这是一条很容易被忽略的经验description是写给模型的路由器不是写给人的摘要。你要去模拟用户在真实对话里会怎么拐弯抹角地表达需求把这些可能说法都自然地融进description里。比如除了“写PR描述”还可以补一句“或整理这次改动的提交信息”。多一个触发表达就少一次技能沉睡。 ### 3.3 正文设计把隐性经验显性化 正文部分要写的是“你希望模型每次都能稳定执行的完整流程”。有三个内容建议写进正文角色设定、执行步骤、禁忌清单。 角色设定给模型一个行为基调比如“资深代码审查者”这会影响它后续的用词和判断标准。执行步骤是主体要按顺序写清楚每一步做什么。这里有个关键原则步骤里涉及的每条规则都应该具体到不能有第二种理解。 禁忌清单也值得单独列一节。为什么强调这个因为模型对这类规则的记忆优先级是最高的。比如“不要编造提交中没有出现的改动”这条实测非常管用能有效抑制模型在PR描述里放飞自我。你踩过的经验教训都可以沉淀到这里让同一个坑不踩第二次。 如果是技能本身逻辑复杂需要示例、模板代码、参考文档这些内容不要全塞进SKILL.md。把SKILL.md保持在“可快速阅读理解”的篇幅其他内容放到同目录下的assets或references子目录用相对路径引用。否则说明文件太长模型读起来反而抓不住重点。 ### 3.4 调试循环跟模型一起调技能 自己写的第一个skill几乎不可能是完美的调试是必须的动作。这几步是我每次写新技能都会走的流程 1. 用真实任务触发技能观察输出是否符合预期。 2. 打开日志确认技能文件确实被加载。 3. 哪里失控就改哪里。大多数情况下问题出在正文规则表述模糊比如“按改动类型归类”没说清到底分几类——写清“功能新增、Bug修复、重构、文档”四类就能立竿见影。 4. 换一个完全不同的触发说法再测一次检验description的鲁棒性。 这套循环跑个两三轮技能基本就能稳定干活了。我个人的经验是花一小时写技能正文不如花半小时打磨description和边界规则前者决定下限后者决定上限。 ## 4. 哪些场景值得专门配Skill前端、数模、AI漫剧的实战拆解 skills不是万能的也不是所有任务都值得配一个。结合热搜里出现的高频场景聊聊我看来真正值得沉淀成skill的几类活。 ### 4.1 前端开发把工程规范变成肌肉记忆 前端是skills落地最密集的领域之一。常见的技能包括组件生成、代码审查、样式规范检查、依赖更新评估。这类场景有一个共同特点重复度高、规范性强、判断逻辑可文本化。 比如团队里有一套React组件的写法约定——函数组件、props用TS类型定义、样式用CSS Modules、必须导出memo版本。以前这些约定靠代码评审时人工盯现在写一个“React组件工厂”的skill让模型严格按照这套约定生成组件代码新成员也能写出老手风格的代码。这个场景里skills的价值不只是提效更是把团队隐性规范显性化。 前端技能设计时有一个特定策略值得提把项目的技术栈和目录约束写进项目级skill而不是用户级skill。因为不同项目的框架和约定不一样项目级隔离能避免规则串味。 ### 4.2 数学建模与竞赛复杂任务的流程管理器 数学建模场景能成为skills热门是因为竞赛流程极其固定、但每一步都不简单。华为杯这类数模比赛从赛题解读、模型选型、求解验证到论文撰写整个流程可以拆成几个skill节点 - 赛题解读技能把赛题要求拆成约束条件、目标函数、数据字段说明 - 模型选型技能根据问题特征推荐候选模型列出每个模型的适用假设和计算复杂度 - 论文结构技能按竞赛论文模板组织章节检查摘要是否覆盖关键结论 - 结果呈现技能规范图表命名和格式 这类技能的好处在于模型不必每次从零“思考”竞赛套路而是按既定流程推进关键节点还能主动提醒你“数据检查过了吗”“灵敏度分析做了吗”。参加过一次数模竞赛的人肯定都懂流程化是制胜关键而没有skill的裸模型在长时间多轮对话里几乎必然遗漏某个环节。这种场景下一个设计良好的skill等于给全队配上从不缺席的流程管理员。 ### 4.3 AI漫剧与内容生产把创意工作半标准化 “AI漫剧常用skills”这个热搜词很有意思。AI漫剧的生产链路通常是文案创作、分镜拆解、绘图提示词生成、脚本整合。这套链路横跨文案和绘画两个领域每个环节都有自己的专业规则。 比如“分镜拆解”技能要能读懂叙事文案并拆成镜头列表每个镜头有画面描述、景别、运镜方式、画面时长。这类规则高度专业化很难靠模型默认水平完成但又不值得为它单独开发一套工具。用skill封装恰恰合适——把分镜的格式规范和镜头语言规则写进SKILL.md模型按规则输出后期人工修改量能大幅下降。 内容生产场景还有一类很值得做的“反向技能”内容质检。比如AI漫剧生成后用技能检查分镜和文案是否匹配、是否有穿帮、角色一致性是否保持。这类技能本质上是给产出设立质量门禁价值不输于生成类技能。 ### 4.4 怎么判断一个场景该不该配Skill 综合上面三类案例我觉得判断标准可以压缩成三条 1. 流程是否可固定如果任务每次做法都不一样、高度依赖灵感那写进skill只会限制发挥反之如果步骤固定就适合。 2. 是否要反复执行一次性任务不值得沉淀每周都要干的活才值得。 3. 规则能否文本化规则能用文字讲清楚才写得进SKILL.md要是规则本身就是“看了才知道好”那就别硬写。 满足这三条配skill是值得的不满足直接用普通对话反而更自由。 ## 5. 攒了一堆Skill之后清理与沉淀的方法论 装技能一时爽技能库维护火葬场。热搜里提到“tibo关于清理skills的方法推荐”我深有感触。Skill库越攒越大之后会遇到几个典型问题目录混乱、技能互相冲突、模型“选择困难”。这里分享一套我自己在用的管理方法。 ### 5.1 冲突是怎么发生的又怎么排查 最常见的冲突是“同名不同内容”。GitHub上叫code-reviewer的skill可能有好几个版本你装了一个觉得不好用又从另一个仓库装了一个同名的后装的覆盖了先装的你以为自己在用B版本其实跑的还是A版本。 排查办法很朴素定期列目录按修改时间排序把长期没有触发记录通过日志看的技能拎出来审视。要么它的description写得不好导致一直没被触发要么它跟别的技能职责重叠了要么根本就是装完就忘了。三种情况只有一种值得留改成更好的description。 ### 5.2 我的清理三层法 我现在管理技能库用三步 1. 按来源和职责给每个技能加一个ID前缀。比如公司项目用 com-前端通用用 fe-数据处理用 data-。文件多的时候前缀本身就是导航。 2. 把技能分成“核心常驻”和“按需调用”两类。核心常驻放用户级目录比如代码风格、安全审查按需调用尽量下沉到项目级目录项目用完了删掉整个文件夹都不心疼。 3. 每两个月过一遍技能库。实测方法是看日志里各技能的读取次数连续两个月没有一次触发的技能直接进回收站。如果舍不得删至少标注为disabled或挪出扫描目录。 这套方法执行下来我的技能库从40多个瘦身到15个左右模型触发准确率肉眼可见地提升了。原因不复杂候选技能少了description匹配时的干扰项就少了。 ### 5.3 沉淀从“临时脚本”到“公用技能库” 清理不是只做减法更高一层是把临时解法沉淀成正式技能。我在项目里写代码时经常临时要求模型做某个特殊格式的校验后来发现这个校验几乎每次都要用于是把校验规则整理成SKILL.md补上description和示例放到项目级目录。熟练之后从一个临时想法到一个成熟技能可能只要半小时。 团队层面上会更值得做。当项目级skills累积一段时间后可以把其中通用的部分提取出来形成团队统一的技能库。新成员入职配置好工具后拉一下技能库就等于把团队过去半年踩过的坑、总结的规范一次性装进大脑——这个效率提升远比省几分钟写代码有价值。 最后分享一个小细节。不管你的技能库用哪种结构强烈建议在SKILL.md的改动历史里补一行changelog。我自己吃过亏某天发现一个技能表现明显变差改来改去都找不到原因后来才想起上周调整过正文里的一条规则。有了changelog十分钟就能定位到是哪个改动影响了行为。这行字用不了你一分钟但它在关键时刻能省下一下午。