这两年聊AI编程绕不开一个越来越热的词skills。不过很多新手容易把它误解成“给AI提需求的能力”其实它更接近于给AI助手配一套可复用的“工作手册工具包”。从Claude Code到OpenAI的Codex再到开源圈常见的opencode几乎每个主流AI编程工具都在用skills规范一套东西把过去用一长串提示词临时组织的碎片流程固化成一个带说明、带例子、带脚本的目录模块。我拿自己举例。去年我给身边同事推荐AI编程助手时听到最多的抱怨不是“模型太笨”而是“换个项目它又忘了上次怎么做的”。后来我把一批重复性工作写成skills比如“前端页面按项目规范生成代码”“对数据集做EDA并输出结构化报告”情况彻底变了用户第一句话还没说完模型已经开始按预设流程干活。这篇就把我看过的、用过的、踩过坑的经验都摊开聊一聊适合刚听说skills但不知道从哪下手的人也适合已经在装skills但总感觉不生效的朋友。1. 先弄明白AI编程里的skills到底是什么1.1 它不是简历上的技能是AI的“外挂能力包”在Claude Code、Codex、OpenCode这些工具里一个skill通常就是一个文件目录。目录里有几个要素一个SKILL.md说明文件、若干示例或模板有时还带一些脚本和配置。SKILL.md是技能包的说明书里面定义了这个skill的适用场景、操作步骤、输出规范甚至语气和边界。AI在接到符合描述的任务时会主动拉起这份说明书按里面的工作流执行。它很像给新员工配的SOP或者给实习生写的checklist——只不过这个新员工是一个大语言模型。Anthropic官方维护的skills仓库GitHub上的anthropics/skills把这种做法推成了带规范的“技能模块”。你可以直接在本地写一个也可以把别人写好的copy进技能目录。过去如果想让AI维护一套统一的代码风格每次对话都得粘贴一条很长的规则现在把规则写进SKILL.mdAI在对应场景会自动读取不用反复提醒。举个例子同样是“开发一个订单列表页”。没有skill时AI写出来的东西全凭当天心情边框颜色、间距单位、状态管理方式经常漂移有了skill之后模型会先检查项目规范、再按组件库生成、最后补上测试用例。前者是临场发挥后者是标准化交付差距肉眼可见。1.2 为什么skills今年突然成了高频词这里有个行业共识模型能力其实在快速拉齐真正拉开差距的是工作流。模型训练得再好如果使用者每次都把任务描述得支离破碎产出大概率时好时坏skills把“口头描述”变成“结构化文件”天然适合版本管理、团队共享、反复迭代。你搜“前端开发skills”“数学建模skills”“AI漫剧常用skills”会发现大家都在找别人的成熟方案这正是可复用性的力量。本质上skills并没有脱离提示词工程的范畴它更像是提示词的结构化升级。普通提示词是一次性消费聊完就扔skill是可沉淀的资产写一次能用无数次还能放到GitHub上让全世界帮你改进。这也是为什么现在GitHub上随便一搜就是一堆“awesome skills”“superpower skills”相关的索引仓库。维度普通提示词skills使用方式每次手动输入写一次按场景自动触发输出稳定性波动较大有约束、有模板稳定得多可维护性靠聊天记录独立目录可Git版本管理共享协作不方便可以开源、团队分发2. 拆一个实战案例数学建模的AI skill到底该写成啥样2.1 先定义边界别让AI自由发挥最近很多人问我“华为杯建模比赛有没有好用的codex skills”因为建模比赛时间紧、任务重用AI提效确实很香。但建模比赛和普通编程任务不一样它特别讲求逻辑闭环假设是否合理、模型是否有依据、代码是否能复现、结论是否对得上。与其让模型自由发挥不如给它一个流程清单让每一步都有据可查。一个好的数学建模skill重点不是告诉AI“你要会数学建模”而是把工作流拆成具体步骤先读题找出目标函数、约束条件和数据类型再解释变量和假设写明为什么要选这个模型然后选择模型并实现最小可行demo最后做敏感性分析并输出LaTeX报告。模型只有在每一步都被约束住的情况下产出的东西才真正能拿去参赛。2.2 SKILL.md的内容骨架可直接改着用下面是我写过的一个建模类skill的简化骨架你可以直接复制改造成自己的name: Math-Modeling-Battle description: 适用于数学建模竞赛题目分析、模型选择、代码实现和论文初稿生成。 当用户提到建模、赛题、目标规划、回归预测、优化问题、评价模型、国赛、美赛、研赛时优先使用。 工作流 1. 读题提取目标、变量、约束、数据特点。 2. 建模假设列出所有假设并说明合理性。 3. 模型选择基于题目类型匹配回归、分类、整数规划、层次分析、BP神经网络等。 4. 代码实现给出可运行的Python/R代码数据部分用最小样例验证。 5. 输出报告生成LaTeX初稿含问题重述、模型建立、求解、敏感性分析、结论。 输出标准 - 所有变量必须定义清晰 - 公式必须用LaTeX写 - 代码必须能一键运行 - 结论必须与计算结果一致。 限制 - 不编造数据 - 不确定的参数要显式标注“此处需要真实数据补全” - 不擅自选择复杂度明显过高的模型。这里最关键的是“输出标准”和“限制”两块。AI最擅长自由发挥你要不把边界画清楚它能给你吐十几页跑不通的代码。所以优秀的skill后面一定跟着一份验收清单让模型自己检查假设是否写明公式是否规范代码能否运行结论是否和数据对得上2.3 模型是怎么“触发”这个skill的很多人写了SKILL.md却感觉AI从不用问题多半出在description上。模型的调用逻辑并不复杂它根据用户的第一句话和上下文去匹配候选skill的description匹配成功了才加载正文。所以description不是写给别人看的是写给模型看的。坏写法description: 用于数学建模相关任务。这种说法太模糊模型很难判断什么时候该用。好写法description: 适用于数学建模竞赛题目分析、模型选择、代码实现和论文初稿生成。当用户提到建模、赛题、目标规划、回归预测、优化问题、评价模型、国赛、美赛、研赛时优先使用。一眼看过去全是动作词和触发词模型一碰到“赛题”“建模”就能立刻对上号。再补一个很容易踩的细节SKILL.md的前十行至关重要。模型上下文再长通常也只读开头几段就能判断要不要深入。触发场景、核心工作流、边界条件必须开门见山冗长的背景介绍放到中间别影响模型决策。3. 手把手写出第一个AI skill带通用模板3.1 从“每周重复三次”的任务里抢救时间写skill最大的误区是“为了写skill而写skill”。我的做法是先盯一周自己的工作流问自己几个问题哪些活儿每周重复哪些答案是同一个模子倒出来的哪些任务每次都要给AI解释半天背景按这两个标准打分——重复频率高、出错或返工率也高的任务就是最适合改造成skill的候选人。拿我身边常见的例子来说代码review、重构老项目、生成Git提交信息、写测试用例、整理数据、生成Dockerfile都是高价值目标。但我建议第一个skill别选大目标比如“让AI管理整个项目”那写出来大概率是一团浆糊。先选窄一点、边界清楚的比如“生成符合项目规范的提交信息”成功率会高很多你也能更快理解skill到底怎么运转。3.2 一个通用skill模板复制就能改下面这套模板我用了很久适合大部分“规范型”任务。所谓规范型任务就是已经有明确标准、只是每次都要重复执行的场景name: project-code-style description: 在用户请求开发新页面、重构旧组件、生成测试代码时使用。 触发场景 - 开发新页面 - 重构旧组件 - 生成单元测试 工作流 1. 识别当前项目技术栈React/Vue/TypeScript/其他。 2. 读取项目根目录下的设计规范文件如design-token.md。 3. 按组件库风格生成代码。 4. 在代码内附带关键注释说明数据流。 5. 补上最简单的测试用例。 输出标准 - 代码必须能直接运行 - 变量命名语义化 - 不改变无关文件 - 交互细节用中文注释说明。 限制 - 不引入新的第三方依赖 - 不随意删除原有功能 - 遇到不确定的业务逻辑时先停下来询问用户。这套模板的核心逻辑是触发场景告诉AI“什么时候用”工作流告诉AI“按什么顺序做”输出标准告诉AI“做到什么程度算完”限制告诉AI“哪些事打死不能做”。四个部分围起来AI的自由发挥空间就被压在了合理范围内。3.3 写skill时最容易被忽略的三个细节第一description一定要“会说话”。我见过太多人花两小时写正文随便两三行糊弄description结果AI根本识别不出来。建议把用户最可能说的几组词放进description里比如“生成页面”“写测试”“重构代码”这是提高命中率最便宜的办法。第二指令别堆太多。一个skill的正文如果超过两三千字模型很容易“忘掉开头”。我的经验是超过五条流程步骤的时候就要考虑拆成两个skill或者缩到必要的核心步骤。宁可精简不要贪全。第三别把权限写得太宽。尤其不要在SKILL.md里告诉AI“可以直接执行脚本”“可以访问任意路径”。你希望AI帮你干活但不希望它拿到整个系统的钥匙。skill里默认应该写“先询问再执行”。4. 从GitHub手动装skills的完整操作Claude Code / Codex通用4.1 为什么推荐手动装一遍现在很多工具自带市场或插件平台点一下就能装好。但我还是建议所有想认真学skills的人至少手动装一次。原因很简单手动装能让你看到skill的真实结构明白它往项目里放了什么文件、改变了哪些行为。以后遇到问题你才知道该去哪里改、改什么。手动安装还有一个实际好处你不会被平台的“一键安装”黑箱逻辑坑到。很多skill包其实很老官方市场可能早就不维护了但GitHub上的源仓库还活着。自己从源仓库拉代码等于直接掌握最新版本不受中间分发层拖累。4.2 四步安装流程第一步把目标仓库克隆到本地。先到GitHub上找到你想要的skills库复制它的clone地址然后在终端里执行克隆git clone https://github.com/你的来源/skills库.git cd skills库 ls -la skills/第二步找到具体的skill目录。大部分规范仓库会把多个skill按子目录存放比如skills/frontend-generator/。你需要的其实是这个带SKILL.md文件的子目录而不是整个仓库。第三步把skill目录复制到工具能扫描到的位置。以Claude Code为例个人全局目录通常是~/.claude/skills/项目级目录是./.claude/skills/cp -R skills/frontend-generator ~/.claude/skills/Codex、OpenCode这类工具的配置路径会略有差异有的用.codex/skills/有的在配置里指定skills目录。核心逻辑都一样把skill目录放到工具能读取的路径下。建议先去查一下对应工具的文档别凭感觉乱放。第四步重启工具会话确认配置生效。这一步很多人漏掉——即便在同一个终端里有些工具也要新开对话才会重新扫描技能目录。装完不重启就测试纯属给自己添堵。4.3 怎么验证skill真的生效了验证只有三步不复杂但很重要。先开启一个新会话直接提出目标场景的问题。比如你装的是前端生成类skill就问“帮我把订单列表页做一下”紧接着观察模型有没有主动引用SKILL.md中的术语比如“遵循项目规范”“输出标准”“变量定义”这一步能看出来它到底有没有加载技能文件最后让模型做一个很小的输出样本对照skill里写的规则逐条检查比如命名风格、注释格式、代码结构。特别提醒别拿超大任务去验证。任务越复杂中间变量越多你越难判断到底是不是skill在起作用。先跑一个小样本确认命中无误再做正经事。4.4 装任何skill之前先看这几个地方安全这件事情怎么强调都不为过。从GitHub装开源skill本质是让人家的代码在你机器上跑。我自己的习惯是不开箱直接用先打开SKILL.md通读一遍再看有没有.sh、.py等可执行脚本逐行确认它们在干什么最后检查权限范围如果skill要求“自动下载依赖”“自动执行命令”却说不清楚原因直接放弃别犹豫。要记住在本地开发环境里模型帮你执行的每一行shell命令都是真实命令。一个设计糟糕的skill完全可能包含“自动clone仓库并执行其中脚本”这种步骤风险不亚于你手动跑了一段来历不明的代码。安全底线守住了skills才是生产力否则就是给自己埋雷。5. 常备开源skills清单从前端到AI漫剧5.1 我常用的五类开源skills先分类聊一下我长期在用的几类开源skills不针对具体某个人而是按生态里最常见的套路来梳理前端开发类skills页面组件生成、组件库对齐、样式系统整理、响应式断点规范。这类skill最实用因为前端规范多、重复劳动多正好适合结构化封装。数据科学类skills数据清洗、EDA探索性分析、特征工程、数学建模。建模赛的选手尤其喜欢这一类能把“读题-建模-写报告”的流程固化下来省下的时间都用来打磨论文。内容创作类skillsAI漫剧脚本、分镜、配音标记、短视频结构。最近“AI漫剧常用skills”热度很高其实就是把小说改剧本、切分镜、生成配音提示词这套流程做成模块让AI批量产出风格统一的内容。工程效率类skills代码审查、老项目重构、Dockerfile生成、Git提交规范、CHANGELOG整理。适合团队内部统一工程习惯减少review时候的无效沟通。系统管理类skills日志清理、临时文件整理、依赖体积检查、端口占用排查。这类skill做起来简单但用起来很舒服属于“小工具大收益”的典型。5.2 几个值得长期关注的公开源第一是Anthropic官方skills仓库这是最稳妥的起步点里面覆盖了常用技能模板和最佳实践适合当“教材”来读。第二是GitHub上的各类awesome索引搜索awesome-claude-code、codex skills、opencode skills、claude skills github都能找到索引页再从索引页顺藤摸瓜就能挖到很多垂直细分的好skill。第三是工具自带的插件市场Claude Code的插件体系里已经出现了不少社区维护的skills集合像superpower skills这类聚合包也很值得留意。不过要提醒一句开源社区skill质量参差不齐有的只是作者随手丢出来的半成品。判断标准很简单——优先选有star、有issue反馈、有更新历史的仓库。那种三个月没动静、README写得云里雾里的直接跳过别浪费时间。5.3 装而不沉我给技能库定的三条规矩收藏癖是现在最大的敌人。很多人装了一堆skills结果每个都不熟模型反而被一堆互相冲突的规则搞糊涂。我给自己的技能库定了三条硬规矩第一条每月清理一次。打开技能目录问自己“这个月真的用过吗”没用过的直接删。删除不可惜需要的时候重新clone就是。第二条每个skill必须带版本和出处。我会在skill目录里放一个NOTES.md记录从哪来的、什么日期更新的、我改过哪里。这样AI读到这个skill时起码知道这是有版本的东西不会把新旧规则混在一起。第三条自己的私货单独放。凡是自己写的skill我放在另一个目录里和开源库分开管理。开源的更新了直接拉自己写的改起来也不怕被覆盖。6. 排查实录skill不生效时我按这个顺序debug6.1 常见失效症状对照表症状可能原因解决方向AI完全没反应skill没被加载路径放错description没命中检查路径和日志确认扫描目录有反应但不守规矩指令模糊规则太杂模型版本不兼容精简SKILL.md把流程拆小执行脚本报错缺依赖权限不足脚本本身过时检查运行环境回退版本乱调用skill触发条件写太宽多个skill互相冲突收紧description检查重复目录更新后失效skill仓库更新了本地还是旧版git pull清理缓存重开会话6.2 我的debug顺序亲测版碰到skill不生效别瞎改按下面的顺序来查第一步先确认到底加载没有。Claude Code和Codex这类工具都能在日志或调试模式里看到技能加载记录看一眼就知道skill有没有进上下文。第二步确认description有没有命中。你可以直接在会话里问模型“你现在有哪些可用的skills根据我的问题你为什么会优先选择这个skill”让模型把决策逻辑说出来一眼就能判断是不是description写得有问题。第三步验证内容是不是太多了。如果模型加载了skill却总是答得很散很可能就是SKILL.md太长模型读一半就乱了。把工作流砍到四步以内看看是否稳定。第四步更新或回退。去GitHub看这个skill最近有没有更新有时候是仓库维护者修了一个关键bug你本地却还在跑旧版反过来也一样最新版可能不兼容你当前的工具版本回退到上一个tag反而更稳。第五步剥离测试。把其他skills临时移走只留下出问题的那一个单独跑一次。很多“灵异问题”其实是两个skill的description互相覆盖造成的拖出来单练立刻水落石出。6.3 别让skill变成后门几个防御性习惯安全习惯要日常化。第一不执行不理解的命令哪怕它是skill里写好的第二尽可能不把网络访问、全局文件写入权限交给模型第三如果skill需要访问项目外的敏感路径直接拒绝第四对权限做最小化处理只给当前任务真正需要的空间。我见过一个“系统清理类”skill功能是把.git目录和node_modules整理一下听起来人畜无害但里面带了自动执行删除操作的脚本。在沙箱环境里跑没事放到真实项目里就要小心了。所以我现在坚持一个原则凡是要动文件系统的skill先读脚本再手动跑。AI可以当自动化引擎但安全决策必须留在人手里。7. 我现在怎么管理自己的AI技能库治理心得回到方法论层面。我现在更愿意把AI skills当成“第二大脑的API”来治理。一个正常API有什么输入、输出、版本、文档、错误处理。一个规范的skill也应该是这样清晰的输入触发场景稳定的输出格式带版本和来源信息以及写明白“不要做什么”的边界约束。它应该和我解决问题的思路一一对应而不是一股脑塞给模型的一团“魔法咒语”。落到实操上我现在只用单一目录管理所有技能用一个Git仓库维护版本每次改动都记录原因。每周抽一点时间做三件事看一遍本周用过的skill输出质量删掉两周没碰过的弱势项目给用得最顺手的技能包打个tag。这样整个技能库始终处于“可审计”的状态而不是越堆越乱的黑洞。很多朋友问我“skills怎么学”我的答案其实很反直觉别急着去学别人的几十个skill先把你天天重复的一条工作流写成自己的第一版。只有亲手写完、跑完、被坑过之后你再看别人的开源skill才能真正看懂哪些设计是精髓哪些只是看上去很美。技能的学习曲线不在安装而在运营不在收藏而在修改和迭代。如果你现在还没有自己的skill建议现在打开编辑器挑一个本周就要做的重复性任务照着上面的模板写一版。装是可以装的但真正值钱的是你自己打磨出来的那套工作流。