AI 编程助手用到现在我最大的感受是模型本身的智商在快速拉平真正拉开体验差距的是你能不能把“经验、规范、流程”系统地交给它。这就是最近圈子里被反复讨论的 skills——你可以把它理解为 AI 助手的“职业技能包”。同一个模型装上合适的 skills 之后再处理任务产出质量比我干巴巴地敲提示词要好得多。这篇文章我会从“skills 到底是什么”讲起然后重点分享我从社区里拿现成技能、自己动手写技能、再到日常维护清理的完整实操路线。如果你正在用 Claude Code、Codex 这类工具或者刚听说“技能库”这个概念想入门这篇文章应该能帮你省掉不少摸索的时间。我会用手记的形式写踩过的坑、验证过的细节都会放进来。1. 先理解 skills 到底解决了什么问题1.1 从“全能实习生”到“有专长的老师傅”讨论 skills 之前值得先想清楚为什么我们越来越需要它如果不装任何技能包直接用 Claude Code 或 Codex 对话它其实已经能写代码、能读文档、能执行命令。但问题是它处理任务的方式是“通用的”——就像一个刚毕业的全能实习生什么都懂一点但不知道你团队里的代码规范、不知道竞赛论文的评分重点、不知道你惯用的分镜节奏。skills 的作用就是给这个“全能实习生”装上一个个“专业模块”。装上数学建模技能包它批阅论文时就会主动检查模型假设、灵敏性分析、图表规范装上漫剧分镜技能包它生成脚本时就会自己带上镜头切换、节奏卡点、角色口癖。本质上skill 是“专家提示词 工作流约束 验收标准”的封装让模型在特定场景下表现得像个“老师傅”。这里我做一个类比把模型比作厨师通用对话是“会做家常菜”而 skill 是一本专门的“川菜菜谱 后厨 Checklist”不仅告诉厨师宫保鸡丁要怎么做还提醒他起锅前必须把花椒炸香、出锅后要撒葱花——甚至告诉他什么样的成品算合格。1.2 为什么现在突然火起来最近“skills 推荐”“superpower skills”“typesafe ai skills”这类关键词的热度涨得很快背后有几个原因。一是编程助手开始支持“可复用的技能目录”而不是只能靠用户每次手写一大段提示词二是社区沉淀了大量高质量的技能包从代码审查、数据库优化到论文写作、视频脚本覆盖面很广三是模型上下文窗口虽然变大了但塞太多临时指令反而会稀释注意力skill 这种“按需加载、任务结束即卸载”的设计更符合实际使用习惯。所以说skills 不是一个噱头它是“把个人经验沉淀为可复用资产”的载体。你写过的每一个好用的 skill下次一键就能调出来用还能分享给队友——这一点在团队协作和竞赛场景里尤其是刚需。2. 现成 skills 的获取与安装最实用的一套操作2.1 怎么去找靠谱的 skills 源搜索关键词里出现了一大堆“skills 源网站”“skills 下载”“常用 skills 源网站”说明很多人卡在了第一步去哪找。就我目前的经验最靠谱的渠道是 GitHub 上几个知名的技能仓库例如社区维护的 awesome-claude-skills 类列表、superpower 系列仓库、typesafe 团队维护的技能集合。这些仓库一般把每个 skill 放在独立目录里带说明文档你可以按需挑选不用整个仓库都拉下来。其次是可以多留意你所用工具有没有官方或社区维护的“市场/插件中心”。有些工具本身带内置市场图形化界面里就能浏览、安装适合不想碰命令行的朋友。找技能的时候我的选型标准有三条看说明文档是否清晰要有明确适用场景和验收标准看更新频率长期不维护的慎用看有没有使用案例或截图有实测记录比只写“功能强大”可信得多。2.2 手动安装 GitHub 技能包的标准流程热词里专门有一条“claude code 怎么手动装 github 上的 skills”这个需求我太理解了。不同工具的手动方式大差不差核心逻辑都是一样的把技能内容放到工具指定的技能目录然后重启会话让工具重新扫描加载。以最常见的目录式安装为例步骤是这样把仓库 clone 到本地或者直接下载某个技能包的压缩包。确认技能包目录结构。一个标准的结构通常包含 SKILL.md说明文件和可选的 scripts 目录、参考文档目录。将整个技能目录拷贝到工具的技能目录下。不同工具路径不一样如果你用的工具是 Claude Code一般可以放在项目的 .claude/skills 下其他工具通常会在启动时打印加载路径或者在官方文档里写明。重启交互会话。这里特别提醒不重启的话很多工具不会自动加载新技能我当时第一次装完没重启白白试了半天。测试加载是否成功。最简单的办法是直接问一句“你现在有哪些可用技能”或者输入技能名看模型是否按技能里的约束来回答。2.3 安装时容易踩的坑这部分算是我反复折腾后的经验总结。第一个大坑是路径放错。不少人在 GitHub 下载了一个“包含多个技能的仓库”结果把整个仓库直接塞进了技能目录导致工具无法正确识别子技能。正确做法是把仓库里每一个“独立技能目录”分别放到技能目录下而不是把仓库根目录整个扔进去。第二个坑是忽略依赖。有些技能包里带有 scripts 脚本运行时需要 Python、Node 等环境或者要 pip install 一些依赖。别看 SKILL.md 写得热闹缺了依赖一执行就报错。装完技能后建议先看一遍它的 requirements 或 install 说明把环境补上。第三个坑是版本不匹配。针对特定模型版本设计的技能换到另一个模型或工具上经常出现行为不一致。比如针对长上下文优化的技能在短上下文模型里就很容易“施展不开”因为技能里的指令可能要求模型先通读整个仓库而模型一次读不完。解决方法就是优先选那些明确标注了适用工具和模型范围的技能装完后小样本实测一下再正式用。3. 从零写一个自己的 skill其实没有想象中难3.1 先搞懂 skill 的文件结构和原理很多人一听到“开发 skills”就以为要写代码其实不完全是。最核心的文件是一个 Markdown 格式的说明文档里面用自然语言描述技能是什么、什么时候该用、怎么用、按什么流程工作、最后怎么验收。模型读取这份说明后会在对话中按它来调整自己的行为。也就是说写 skill 更像是“写给模型看的岗位说明书”而不是写程序。我习惯把技能包目录做成这样SKILL.md技能说明主文件必选。scripts/可选的辅助脚本用来跑特定流程、处理数据、格式化输出。references/可选的参考文档放行业规范、示例输出、代码风格指南方便模型按需查阅。SKILL.md 的内容我一般固定用几个区块name技能名称简洁、见名知意。description一句话描述说明技能适用场景和能做什么。这个字段特别重要因为它决定了模型在什么情况下会选择调用这个技能。很多模型是“看到描述和当前任务匹配才加载详细指令”所以 description 要写得像搜索引擎的摘要一样精准。instructions核心行为指令告诉模型接到任务后应该按什么步骤走、重点关注什么。acceptance criteria验收标准什么样算完成、什么样算合格防止模型“自由发挥跑偏”。可能有朋友会问不就是一个 Markdown 文件吗和直接粘贴提示词有什么区别区别在于两点一是结构化模型按区块理解更稳定二是可复用一个 skill 能在多个会话、多个任务里反复调用不用每次重写三是能附带脚本把可程序化的流程固定下来。3.2 一个可直接套用的 SKILL.md 模板下面是我自己写技能时用的一个精简模板你可以直接抄走改--- name: code-review-helper description: 用于对代码变更做系统化审查检查逻辑正确性、风格一致性、性能隐患和边界情况。适合在提交 PR、合并分支前使用。 --- # Code Review Helper ## Instructions 1. 先阅读 diff 或代码变更提取变更的文件和核心改动点。 2. 按优先级从高到低审查 - 逻辑正确性是否存在边界条件遗漏、死代码、明显逻辑错误。 - 性能隐患是否出现不必要的循环、大对象复制、N1 查询。 - 代码风格是否匹配项目既有命名和结构约定。 - 可维护性是否缺少注释、是否过度复杂、是否可拆分。 3. 对每个发现的问题给出严重级别blocker / major / minor / nit。 4. 最后输出审查总结按严重级别分组并给出修改建议。 ## Acceptance Criteria - 每一个问题都必须附上具体行号或代码片段。 - 必须区分事实问题和风格偏好不能把个人偏好当硬伤。 - 输出要简洁不重复粘贴整段代码。这个模板的核心是“分优先级、给结论、给证据”。模型如果按这套指令走产出的审查质量会稳定很多。你也可以在你自己的技能里加入更多个性化约束比如“评论用中文”“不要夸赞代码写得漂亮直接说问题”等这些约束越具体越好因为模型擅长具体执行而不是领会“你懂的”。3.3 写完之后的验证和迭代技能写完后一定要按 3.3 步验证第一步用最简单的测试任务触发它确认它有没有被加载、按技能套路工作第二步用真实任务测试效果看输出质量是否达到预期第三步根据失败案例回头修改 SKILL.md。很多第一次写技能的朋友都会发现技能写得“太宽泛”模型执行时抓不住重点或者步骤太多模型开头做得很细、后面开始偷懒跳步。这时候就要精简指令把最重要的约束放到前面并用“必须”“禁止”这类强指令而不是“注意”“可能的话”这种弱表达。我自己的经验是一个技能至少要迭代两三版才能稳定。核心原则就一条在“约束足够多”和“指令足够少”之间找平衡——太少模型会自由发挥太多模型会执行不过来反而忽略关键点。4. 两个真实场景里的技能实践数学建模与 AI 漫剧4.1 数学建模比赛里的“组合技能”打法“华为杯建模比赛好用的 codex skills”“数学建模 skills 推荐”这些词能上热榜是因为竞赛场景对技能的需求太明显了。一场比赛提交的论文、代码、图表是一套完整的工程靠临时对话很难保持全程风格一致、结构规范。我自己参加过的比赛里用得最顺手的是一套“组合技能”共三个论文结构写作技能约束摘要结构背景-问题-方法-结果-结论、正文逻辑链、图表编号和引用格式。模型按这个技能写出来的初稿基本不会缺关键段落。公式与符号规范化技能统一变量命名风格梳理符号表检查公式在上下文里的自洽性。代码审计技能检查求解核心代码里的物理约束是否满足、参数是否有硬编码、结果导出格式是否符合提交要求。这三个技能不是孤立的它们的配合方式是代码审计技能先跑通结果并导出数据论文写作技能再根据数据生成图表描述和结果分析公式规范化技能最后统一全文的数学表达。可以说竞赛论文的很多重复性劳动都被技能包接手了我只需要把精力集中在“建模思路”这种真正需要人的创造力的部分。4.2 AI 漫剧分镜脚本里的“风格一致性”技能另一个让我印象深刻的场景是 AI 漫剧。热词里“ai漫剧常用 skills”看起来冷门但实际做起来痛点非常具体连续生成几百张图必须先保证角色形象、场景风格、镜头语言的一致性否则画面一阵乱跳根本拼不成一个故事。为了应对这个问题我摸索过一个“分镜脚本技能”它的核心指令不是教模型生成画面而是约束它产出“供绘图模型理解的分镜脚本”。技能里包含了这样几条约束角色描述必须引用统一的人物设定表不允许在脚本里临时改发型、服装颜色。镜头描述要包含景别、角度、运动方向、情绪气氛缺一不可。台词要控制在每镜一两句避免大段独白导致画面信息过载。生成每张图的提示词时必须保留风格关键词和后缀参数保证画面统一。这个技能的实际效果是脚本产出的一致性好很多后期“改画风”的重绘工作量明显下降。很多做 AI 漫剧的朋友只关注了画图工具的参数却忽视了脚本阶段的一致性约束其实脚本做好后面能省一大半事。4.3 从这些场景里总结出的通用方法论跑完这两个场景我对“怎么用好技能”有了更具体的理解。第一个心得好技能不是“大而全”而是“小而专”。一个技能管一件事比如“写摘要”就是“写摘要”“查公式”就是“查公式”别把一整套论文流程塞进一个技能里不然模型很容易看不过来、执行走样。第二个心得技能之间可以通过约定输入输出格式来“接力”。比如代码审计技能的输出是 JSON 格式的数据摘要论文写作技能的输入预期就是这个 JSON。这样技能虽然各自独立组合起来却能形成流水线。第三个心得技能的定义要预留迭代空间。竞赛评分标准可能会变、模型版本会升级技能也应该按“版本号”维护。要给技能文件加版本信息每次更新都记录改动点这样出了问题才能回滚比较。5. 技能的日常管理与清理别让技能库变成垃圾堆5.1 什么时候该装技能什么时候不该装技能不是装得越多越好。我见过有人一口气装了上百个技能结果模型每次对话前都要扫描一遍技能列表不仅响应变慢还可能出现“技能串味”——明明是写作任务模型却因为某个技能描述相似调用了数据库优化技能的逻辑。我的经验是保持技能库精简每个工具或项目里只保留那三五个高频使用的技能。判断要不要新增技能先用一分钟自问这个技能对应的任务是不是每周至少出现一次是不是每次做的时候都要重复解释一遍规则如果答案是肯定的那值得做成技能如果只是极偶然的需求贴一段提示词就够了。技能的本质是“高频率 结构化”的劳动沉淀低频任务不值得占用技能位。5.2 清理和更新的有效方法热词里提到“tibo 关于清理 skills 的方法推荐”看来清理确实是很多人的刚需。我自己的清理策略是定期“技能审计”每两周或每个项目节点打开技能目录把那些一次都没被加载过的技能挑出来追问一句“当时装它是为了什么”。如果回答不上来就移到一个“archive”目录里而不是直接删。这样既能避免误删导致翻车也能让主技能目录保持清爽。更新技能方面一个细节值得说不要直接在原文件上改完就不管。我一般会在 SKILL.md 的头部加一个“更新记录”区域列出日期、版本、改动内容。因为模型是“按当前文件内容执行”的如果你改了指令但没记录下次出问题时根本不知道是哪个改动导致的。加了更新记录之后排查问题会清晰很多。另外要做好技能冲突的排查。如果发现两个技能描述高度相似模型可能随机加载其一这时应该考虑合并或删除一个。技能文件的命名也尽量用“领域-功能”结构比如 code-review-helper、write-paper-abstract避免用“通用助手”“超级工具”这类又大又空的词。5.3 用 Git 管理自己的技能库对我来说Git 是管理技能库最好的工具。所有技能放在同一个仓库里每次改动用 commit 记录需要的时候能回退。尤其当你参与团队合作时技能库共享的意义更大队友改了技能Git 记录里一目了然不用口头来回传文件。操作上也不复杂就是普通 Git 仓库的日常流程克隆、增删改、推送、拉取偶尔处理一下合并冲突。如果你是单人使用也不必把所有技能都放到同一个仓库。按项目分仓库会更清晰数学建模技能放一个仓库漫剧脚本技能放另一个仓库使用时再分别挂载到对应的项目里。这种“按场景隔离”的方式能有效避免技能串味也方便你在不同场景里快速切换。6. 实践中的高频问题与排查方法6.1 技能加载失败怎么快速定位技能加载失败是出现频率最高的问题而且很多都是低级错误逐个排查最快文件命名对不对确认是 SKILL.md大小写都别写错。目录层级对不对确认是“技能目录/SKILL.md”而不是把 SKILL.md 随意丢在某个子目录里。文件编码对不对有些文本编辑器默认存成带 BOM 的 UTF-8或者 GBK模型读取时可能出现解析问题统一换成无 BOM 的 UTF-8。有没有多余的空目录或隐藏文件工具扫描时可能被异常结构干扰确保技能目录干净。还有一点改完技能后不仅要保存文件还要重启会话或者等工具的扫描机制重新加载。我见过有人把文件改了又改对话框里还是旧行为就是因为忘了重新加载。6.2 模型不按技能执行怎么调整指令另一个常见问题是技能是加载了但模型“不听指挥”。遇到这种情况问题多半出在指令的表达方式上。把“请尝试”“可以考虑”这类弱表达改成“必须”“禁止”“按顺序执行”这种强指令效果立竿见影。比如“必须输出每个检查项的结论”就比“请列出检查结果”有效得多。如果你的技能步骤特别多模型后面容易“跳步”就教它“分阶段输出中间结果”。让模型每完成一个阶段先汇报一下再进行下一阶段。这样你就能及时纠偏防止它带着错误一路跑到底。还有一个要点给模型提供“负向示例”。直接在技能里写“不要只给建议必须给出可执行命令”或“禁止在输出中使用模糊词汇”。明确的禁止项比反复强调正向要求更好用这跟“告诉一个人别做什么”比“让他领会你要什么”更直接是一个道理。6.3 技能行为不稳定要建立“回归测试”习惯技能是自然语言不是代码所以它可能时灵时不灵。每次我改完一个技能都会留一组“回归测试问题”每个技能准备三五个典型问题快速跑一遍确认每次行为一致。虽然技能是文字不是软件但我们可以用软件工程里“回归测试”的思路来维护它。一套固定的验证问题能保证迭代不会破坏已有能力。我还习惯把每次实践里的失败案例记下来作为技能的“补充示例”写进指令里。比如某次生成漫剧分镜时角色描述崩了我就把“不允许在分镜中新增角色外貌特征”这条约束加进技能。每加一次约束技能稳定性就高一点。这个过程不是说教而是实操里最管用的“逐步打补丁法”。7. 写在最后的一点个人体会我自己的感受是skills 的价值不在于“装得多”而在于“用得准”。它是把 AI 从“问一句答一句”的对话工具变成“懂规矩、有手艺”的协作搭档的桥梁。从命名规范、目录结构到安装、调试、清理的整套流程我现在已经养成了习惯凡是重复三次以上的任务就会琢磨能不能沉淀成一个技能。这样一个一个攒下来技能库越来越像自己“数字外脑”里的工作手册而不是一个装着杂物的抽屉。如果你正准备从零开始接触 skills我的建议很简单先别急于写自己的技能去社区里找个评价好、场景贴近你需求的现成技能装上用几周体会一下技能加载前后的差别。等你能感受到“装上它之后确实更省心”再动手写自己的第一个技能也不迟。写的时候记得从最简单的应用场景开始一步步迭代。这个方向越玩越有意思而且每一步积累都能变成你长期可复用的生产力。