做AI编程和自动化工作流这两年我越来越觉得现在整个圈子讨论的核心已经悄悄变了。以前大家比的是谁的模型参数量大、谁的推理能力强现在身边人聊得更多的反而是“skills”——你给AI装了什么技能你的工作流里沉淀了哪些可复用的能力。这个变化挺有意思的从拼“脑子聪明”到拼“会不会干活”本质上是AI从聊天玩具走向生产力工具的一个标志性拐点。这篇文章我不打算写成一本正经的教程更想以一个实际折腾过的人的身份把skills是什么、为什么突然这么火、怎么手动装GitHub上的技能包、怎么自己写一个能用的技能以及我在实操中踩过的坑一次性讲透。1. 先搞清楚skills到底是个什么东西很多朋友第一次听到skills是在刷社交媒体或者逛开源社区的时候看到类似“superpower skills”“codex skills”这种词。第一反应多半是疑惑这不就是给AI写提示词吗换个马甲而已说实话我一开始也是这么想的。但实际用下来我得承认这还真不是换个名字这么简单。skills的本质是把AI在一类任务里需要知道的知识、需要遵守的规则、需要调用的工具封装成一个结构化的文件包。它跟散装提示词最大的区别在于提示词是一次性的是对话上下文里的一段“口头叮嘱”而skills是可复用的是沉淀下来的一份“岗位说明书”。用大白话打个比方。你雇了一个特别聪明但完全没工作经验的新人你每次让他干活前都得从头交代一遍公司制度、项目背景、输出格式。这就是没有skills的AI使用方式——每次对话都在重新培训。而skills就像是你给这个新人发了一本员工手册他上岗前翻一翻就知道遇到什么情况按什么流程处理输出什么格式的结果。你省了嘴皮子他也不会再自由发挥闯祸。所以现在开源的skills项目越来越多从代码审查、测试生成、论文排版到内容创作、AI漫剧脚本什么方向都有人在做。核心原因就是大家发现把“会做什么”这件事文件化之后AI干活的质量和稳定性都上了一个台阶。以前AI是在“听指令做事”现在是在“按标准执行”。这篇东西适合谁看我觉得只要你在用AI编程工具、在做内容创作、在搞数学建模或者任何需要AI稳定输出的场景都值得花几分钟把skills这套机制搞明白。哪怕你只是想知道“GitHub上那么多skills项目到底怎么装进Claude Code”这篇文章也给你捋清楚了。2. 为什么AI编程突然流行“技能”这套东西要理解skills为什么火得先看看没有skills的时候我们是怎么干活的。2.1 每次对话都在“重新发明轮子”以前我用各类AI编程工具改代码最常见的憋屈场景是这样反复告诉它“我们的项目用pnpm不要动package-lock.json”“后端接口都走/api前缀”“错误处理统一返回{code, message}”。这些项目规范明明写在文档里、散落在代码里但AI每次都是睁眼瞎你得一遍遍唠叨。效率低还是小事更要命的是不稳定。同一个任务今天问和明天问AI可能给出两套完全不同的方案。没有约束机制AI的自由发挥有时候是灵感更多时候是事故。2.2 把“会做的事”变成文件Skills做的事其实不复杂把你希望AI掌握的知识、遵循的规则、会用的工具打包成一个结构化的文件通常是一个SKILL.md加上配套脚本或模板。AI在需要的时候加载这个文件就能立刻获得对应的“肌肉记忆”。可以理解成给AI一本岗位手册新员工入职新会话开始不用重新培训直接发手册照着干活就行。手册里规定了流程、注意事项、输出标准甚至附带了常用工具。这就是为什么现在很多团队把项目规范、代码风格、测试要求都做成skills文件放进仓库AI一进项目就自动对齐。2.3 从“聊天的AI”到“干活的AI”Skills背后是整个AI使用范式的转变。以前AI是聊天机器人你问它答上下文一长就失忆。现在AI慢慢变成“数字员工”它需要的是长期记忆、专业分工、稳定输出。技能文件就是这种转变的关键载体。拿我自己举例。我不怎么写数学建模但我帮朋友调过用skills跑数模比赛的流程。往年他们组队建模光是统一论文格式、画图风格、公式排版就够吵三天架。今年他们直接用了一套数模skills包把排版规范、图表风格、建模步骤全部写进技能文件里三个人各干各的最后拼接出来的论文跟一个人写的一样。这个体验让我很受触动——skills的威力不在单点功能在于把松散的协作变成流水线。3. 手捋一次skills到底是怎么工作的理论说再多不如拆开看一个真实的技能文件。3.1 一个标准技能的文件结构社区里最常见的skills项目大概长这样my-skill/ ├── SKILL.md # 技能主文件AI主要读这个 ├── scripts/ # 可选的辅助脚本 │ └── process.py ├── templates/ # 可选的模板文件 │ └── report.md └── assets/ # 参考资料、示例 └── examples/核心就是SKILL.md一个Markdown文件。别小看这个纯文本文件它就是AI的“技能灵魂”。3.2 SKILL.md里面到底写什么我见过写得好的SKILL.md也见过写得跟流水账一样的。这里直接给一个比较合理的结构是我根据多个开源skills项目总结出来的--- name: code-review description: 对代码变更进行审查并输出结构化报告。适合在PR/MR阶段使用。 --- # 代码审查技能 ## 适用场景 - 检查未合入的变更是否存在逻辑错误、安全隐患、性能问题 - 输出可读性强的审查报告 ## 工作流程 1. 读取变更文件识别核心变更范围 2. 按优先级检查安全问题 逻辑正确性 性能 可读性 3. 输出审查结论按严重程度分级列出问题 ## 输出格式 必须使用以下结构 - 结论通过 / 需修改 / 有风险 - 严重问题无法合入的缺陷 - 建议可选优化方向 ## 注意规则 - 只审查本次变更不扩大到全仓库 - 不臆想不存在的调用关系 - 每条问题都要标注文件和行号看到区别了吗好的SKILL.md不是在“描述技能”而是在“约束行为”。它告诉AI什么时候出手、按什么顺序干活、输出长什么样、红线在哪里。这其实就是把团队里资深工程师的审查习惯沉淀成了一段可以复制给AI的指令。3.3 文件是怎么被加载的不同工具加载skills的机制不太一样但套路类似自动加载工具启动时读取特定目录下的技能文件按名字索引按需调用根据当前任务内容由模型自己判断要不要用某个技能显式调用用户直接指定“用某某技能处理”现在很多编程工具还在用“slash command”的方式也就是在对话框里输入斜杠加技能名比如/review、/test。这种方式最稳因为不会误触发。我在实际使用里也是优先用显式调用避免AI在不该出手的时候自作主张。注意skill的加载机制各工具实现差异较大如果你切换工具技能文件最好在原有结构基础上按新工具规范调整一下直接复制有时候会失灵。4. 手把手手动安装GitHub上的skills这是很多人卡住的地方尤其是看到“Claude Code怎么手动装skills”这种热搜时一脸懵。其实原理说穿了就三步找到、放下、指路。4.1 找到合适的技能包GitHub上搜skills搜出来的项目质量参差不齐。我的筛人标准是四条项目有README说明来历和用途不是凭空冒出来的有明确的SKILL.md文件且结构完整最近三个月有更新或者Star数证明了社区认可度有使用示例不是纯概念对应的搜索姿势也很简单直接搜awesome claude skills、codex skills、skills marketplace这类关键词基本能找到聚合列表。再具体一点的需求就搜“用途skills”比如数学建模就搜math modeling skills。4.2 克隆或下载到技能目录每个工具都有它默认的技能目录。拿Claude Code举例它通常会去读~/.claude/skills/下的技能文件。操作上就是# 创建一个统一放技能的目录 mkdir -p ~/.claude/skills # 把GitHub上的技能仓库克隆进来 cd ~/.claude/skills git clone https://github.com/xxx/some-awesome-skill.git如果你不想用git也可以直接下载仓库的zip解压或者只下载单个SKILL.md文件放进目录。具体哪种方式不重要重要的是最终目录结构要符合工具的识别规则——通常是技能文件夹里直接就放着SKILL.md。4.3 确认工具能“看见”它装完不代表立刻生效。我的习惯是重启正在运行的编程工具会话让配置重新加载在对话里输入技能名看能不能正常触发跑一个最简单的测试比如让技能处理一段小代码确认输出符合预期这一步看着简单但很多人会忽略。我见过有朋友装完技能没重启AI完全不理会气得差点把仓库删了。其实重启一下就好跟改完环境变量要重开终端一个道理。4.4 手动安装的三个常见翻车点目录套娃问题很多人clone下来发现技能不生效一看目录结构是skills/some-skill/SKILL.md被嵌套了两层。工具只认some-skill/SKILL.md这种结构遇到多层嵌套就得手动把文件移到正确层级。大小写和文件名搞错SKILL.md这个名字是约定俗成的你写成skill.md、Skill.md或者干脆叫README.md部分严格实现就识别不了。GitHub默认展示README很多小白把README当成了技能文件这是个经典坑。依赖脚本没装有些技能不止一个Markdown文件还需要配套的Python脚本或Node脚本。只拷贝了Markdown运行时报缺模块这时候要回头看看技能仓库的README把依赖补上。提示手动装的技能建议用git clone而不是手动下载压缩包。后续技能作者更新了你可以直接git pull拉新版本。手动下载zip的话每次更新都要重新来一遍。5. 进阶玩法自己写一个skills从“会用别人的”到“自己写”是玩skills的分水岭。自己写的过程也是重新梳理自己工作流的过程。5.1 什么时候值得自己写我的判断标准很朴素同样的说明你给AI重复讲过三次以上你的团队有明确的流程规范希望所有AI操作都按这个规范走你手头有高质量的输出模板想让AI每次稳定复现满足任何一条就值得动手写。比如我常写技术周报一开始每周都要调整格式后来我写了个“周报生成技能”把格式要求、数据来源、写作语气全部塞进去现在生成第一版就基本贴合要求省了大量来回修改的时间。5.2 从一份糟糕的SKILL.md开始写技能最忌讳一步到位追求完美。我的路径是先在对话里把需求跟AI讲一遍让它按你的要求干活把刚才的对话要点整理成草稿指令用草稿指令拼一个初版SKILL.md扔进技能目录启动技能跑一个真实任务看哪里不满意针对不满意的地方改SKILL.md再跑迭代三四轮后基本可用我管这个叫“先有后优”先让技能跑起来再慢慢打磨。如果你一开始就想写一个覆盖所有边角情况的完美技能大概率会卡在第三步写不出来。5.3 写SKILL.md的几个实战技巧技巧一示例比描述更有效描述性文字写得再详细AI在边界场景下还是会自由发挥。但如果你给一两个输入输出的示例模型很容易照着样例的结构走。我写技能都会放一个“输入示例/输出示例”区块效果立竿见影。技巧二明确“不要做什么”只写“要做什么”的技能容易出现过度发挥。我踩过的典型坑是让AI做代码审查它审查完顺手把代码改了一遍。后来我在技能里明确写“只输出审查报告不修改任何文件”问题就消失了。约束缺失是最常见的技能失控原因。技巧三可变量用占位符如果技能要复用在不同的项目上硬编码路径和项目名会让技能失去通用性。用占位符比如{{PROJECT_ROOT}}、{{LANGUAGE}}让使用者在调用时替换技能的生命力会强很多。5.4 一个最小的可用技能如果你想练手可以从这个“代码提交信息生成器”开始。这个技能看起来小但包含了“流程约束输出格式语气规定”三个要素非常适合用来理解技能的写法。--- name: commit-message description: 根据git diff生成符合规范的提交信息。 --- # 提交信息生成器 ## 输入 - git diff内容 ## 流程 1. 分析diff识别改动类型feat/fix/refactor/docs/style/test/chore 2. 提取核心变更点一句话概括 3. 根据类型生成提交信息 ## 输出格式 type(scope): subject body ## 规则 - subject必须小于50字符 - 不使用祈使句以外的语气 - 不添加Co-authored-by写到这个程度已经比很多我见过的SKILL.md要规范了。关键是这套结构可以直接套用到任何技能上。6. 哪些skills值得关注从入门到实战聊完怎么写再回头看看生态里那些值得装、值得抄的skills。这部分我会按使用场景分类方便不同需求的人对号入座。6.1 编程开发类这类是当前最成熟的。值得关注的方向代码审查技能让AI按团队规范审查PR输出结构化报告测试生成技能给定函数自动生成单元测试输出格式统一重构辅助技能规定重构策略避免AI乱改一气环境配置技能把“新项目怎么初始化”的流程固化其中代码审查我推荐每个团队都配一个。原因很简单人工审查的成本是客观存在的AI审查虽然不能完全替代人但能在第一时间挡住低级错误让人把精力放到真正需要判断力的地方。6.2 数学建模类“华为杯建模比赛好用的codex skills”这个搜索词说明真的有很多人在用AI打比赛。数模场景下我见过的实用技能包括论文排版规范技能统一公式、图表、参考文献格式数据预处理技能按固定流程清洗、探索、可视化模型选择辅助技能根据问题类型推荐候选模型数学建模的本质是“有限时间内的标准产出竞赛”而skills恰好能把那些重复性的规范工作压缩到几乎为零。团队用同一套技能产出的论文一致性会好很多。6.3 内容创作类AI漫剧、短视频脚本、公众号文章这些方向也有一批技能。核心套路是把“爆款结构”“语气风格”“敏感词清单”写进技能文件让AI每次产出都保持在同一个水平线上。如果你做内容矩阵这类技能能帮你把多平台风格统一起来。6.4 值得收藏的技能库GitHub上有不少聚合技能库搜索方式前面说过了。我个人的建议是不要贪多一次装三五个就够用。装一大堆技能的代价是AI在判断“用哪个技能”这件事上会消耗更多时间反而影响响应速度。技能在精不在多这是一条被反复验证的经验。7. 避坑指南让skills真正可用最后这部分我集中讲讲实操中的坑。文章开头说过的隐患这里展开说透。7.1 目录与命名的隐形坑技能不生效的第一大原因永远是文件放错位置或命名不对。每换一个工具先去翻官方文档确认技能目录的位置。我被坑过的一次是同时装了三个AI编程工具它们的技能目录各不相同我有一次全放进了同一个目录结果只有一工具认出来了。具体目录因工具而异比如有的读~/.config/下有的读项目根目录。装完技能先确认你的实际路径跟工具文档一致再开始怀疑技能本身写得不好。7.2 指令模糊导致的“伪成功”还有种情况更隐蔽技能确实被加载了但AI执行得跟你想的不太一样。这不是加载失败而是指令模糊。比如你写“高质量地写出周报”AI会努力但不知道标准是什么。改成“每个模块先写结论再补充数据总字数不超过800字语气客观不带感叹号”执行结果立刻可控。技能的本质是“把隐性预期变成显性指令”。如果你的技能文件自己都说不清楚标准就别指望AI能替你搞清楚。7.3 技能之间的打架问题装了三个以上技能后可能会出现互相干扰。比如某个技能要求“语言简洁”另一个又要求“对每个点展开不少于100字描述”AI同时加载时就会精神分裂。解决办法有两种技能文件里写清“仅当满足XX条件时使用本技能”在调用时显式指定技能名不让AI自己猜我倾向于第二种显式指定最可靠。毕竟AI的自主判断在复杂场景下仍不值得全信这也是“半自动”模式更适合生产力环境的原因。7.4 清理和迭代的必要性技能不是装完就一劳永逸的。我养成的习惯是每月花半小时做一次技能体检把明显不再用的删掉把用着别扭的按新经验改一版把类似的合并成一个。这个习惯让我的技能库一直处在“小而精”的状态而不是越来越臃肿。有个朋友关于清理skills的观点我很认同清理不是删除是重新排序优先级。你真正高频使用的技能应该很容易被找到而不是淹没在一堆“可能有用但从来没用过”的文件里。8. 最后说点实在的Skills目前还处在快速演进的阶段各种工具的实现方式并不完全统一今天是这个目录结构明天可能就换协议。但无论底层怎么变“用文件沉淀AI的行为规范”这个思路是明确的。我自己的体会是与其焦虑追新技术不如先把一个技能真正用好把一个工作流真正跑通。如果你刚开始接触建议从抄作业开始找一个成熟的开源技能按它的结构改成自己的版本装上跑一遍感受下“AI突然按规矩办事”是什么体验。有了体感再谈自己写、自己优化会顺手很多。这套东西会怎么演变我不去做空泛的预测但有一点我可以确定AI的使用方式正在从“每次从零开始”走向“积累复用”。“会用技能”和“不会用技能”的差距会随着时间越拉越大。早一点开始建立自己的技能库不是追新是在给未来的自己省时间。