先说结论最近半年我把大量时间花在了折腾 AI 编程工具上绕了一圈发现真正让 Claude Code、Codex、OpenCode 这类工具从“聊天机器人”变成“项目助理”的关键不是模型本身有多强而是你给它装了什么样的skills。如果你还没接触过这个名词可以简单理解成Skills 是给 AI 预装的一套“岗位说明书操作手册”。它告诉 AI 在特定场景下应该按什么流程干活、调用哪些工具、产出什么格式的结果。前端开发用它规范代码风格数学建模用它统一分析流程AI 漫剧创作者用它批量生成分镜脚本。这篇文章我把自己从下载、安装、挑选、编写到清理的完整经验都整理出来了适合所有想让 AI 更“听话”的开发者、竞赛选手和内容创作者。1. 先搞清楚AI Skills 到底是什么网上讨论 skills 的文章很多但大部分都在堆概念。我尽量用大白话把它拆开你听懂了底层逻辑后面安装和开发都不会迷路。1.1 从“会聊天”到“会干活”Skills 解决的核心问题用过 AI 编程助手的人都有这种体验你不给它任何指令直接说“帮我写个登录页面”它确实能写但写出来的东西往往很泛。你说“按照项目现有风格写”它又会问你一堆问题。问题出在哪出在 AI 每次对话都是“失忆”的它不知道你的项目规范、不知道你习惯的代码结构、不知道你想要的输出格式。Skills 干的活就是把这些“隐含知识”显性化。一个写前端项目的 skill里面可以包含组件目录应该怎么组织、样式是用 Tailwind 还是 CSS Modules、接口请求统一走哪个封装、提交信息用什么格式。AI 在开始干活前先读一遍这份“手册”之后生成的内容就会贴合团队约定。这跟 Prompt 的区别很大。Prompt 是一次性的这次写好下次还要写Skills 是长期资产定义一次任何项目、任何时候都能复用。我把 Skills 看作“给 AI 上的第一节入职培训课”培训完了它就能直接上手干活。1.2 Skills 与插件、MCP、Agent 的区别很多人分不清 Skills、MCPModel Context Protocol、插件和 Agent 之间的关系。我用一个生活类比帮大家理顺假设 AI 是一个全能新手厨师。插件是给他准备的“专用厨具”比如一把好用的刀具代码格式化、一台烤箱测试框架。厨具解决的是“有没有工具”的问题。MCP是“食材供应链协议”让他能去不同的菜市场数据库、浏览器、设计稿拿到新鲜的菜。MCP 解决的是“数据从哪来”的问题。Skills是“菜谱后厨规范”告诉他红烧肉该先焯水还是先炒糖色出餐摆盘应该用什么盘子。Skills 解决的是“按下什么流程做”的问题。Agent则是整个后厨团队它会自己看菜谱、拿食材、用工具把菜做出来。所以你可以看到Skills 更像是一种“软性知识层”。它不直接调用外部工具而是指导 AI 怎么用工具、怎么组织流程。这也是为什么一个写得好的 Skills 往往比一堆插件更能提升效率。1.3 一套 Skills 的文件结构长什么样要深入理解 Skills最好直接看它的物理结构。目前社区里最通用的规范来自 Anthropic 提出的 Claude Skills 格式大多数开源项目都遵循这套结构。一个标准 skill 通常是一个文件夹里面最少包含一个SKILL.md文件。稍微复杂一点的会长这样my-skill/ ├── SKILL.md # 核心指令文件 ├── scripts/ # 可执行的辅助脚本可选 │ └── generate_report.py ├── references/ # 参考资料可选 │ └── style_guide.md ├── assets/ # 静态资源可选 │ └── template.xlsx └── requirements.txt # 依赖清单可选SKILL.md是灵魂。它通常有 YAML 格式的 frontmatter声明技能的名字和描述然后是 Markdown 正文写具体的操作指导。我用一个最小示例说明--- name: weekly-report description: 生成符合公司模板的周报。当用户要求写周报、汇报本周工作时使用。 --- # 周报生成流程 1. 先向用户确认本周完成的事项按重要程度排序。 2. 从 references/weekly_template.md 中读取模板。 3. 按“本周重点 / 风险与阻塞 / 下周计划”三个模块输出。 4. 输出格式必须为 Markdown文件名以 周报_YYYY-MM-DD.md 命名。AI 读了这个文件后就会严格按这套流程产出周报。这就是 Skills 最核心的运作机制用结构化的文件把经验写成 AI 可以稳定执行的指令。2. 怎么装 Skills手动安装 GitHub 项目的完整流程知道 Skills 是什么之后接下来最常遇到的问题就是GitHub 上看到一个 skills 项目怎么装到自己的工具里很多教程只讲了“放到某个目录”但不同工具的目录名、加载时机、优先级都不一样。这部分我把手动安装的细节写完。2.1 先看懂一个 Skills 项目的目录结构在动手安装前我建议先花两分钟看懂仓库结构。绝大多数开源 skills 仓库会这样组织awesome-skills/ ├── README.md ├── skills/ │ ├── code-review/ │ │ └── SKILL.md │ ├── db-design/ │ │ ├── SKILL.md │ │ └── scripts/ │ └── api-doc/ │ └── SKILL.md └── package.json 或 requirements.txt你要安装的并不是整个仓库而是仓库里某个具体的 skill 文件夹。比如你想装code-review这个技能只需要把skills/code-review整个文件夹复制到你本机的 skills 目录里就行README 和其他不相关的技能都不用管。这里有第一个容易踩的坑不要直接把整个仓库 clone 到 skills 目录。因为很多仓库根目录下没有SKILL.mdAI 扫描不到任何技能你还以为安装失败了。正确做法是进到仓库里找到每个包含SKILL.md的子目录再逐个安装。2.2 手动安装到 Claude CodeClaude Code 是目前对 Skills 支持最完善的工具之一。它默认从两个位置加载技能用户级全局目录~/.claude/skills/项目级目录.claude/skills/放在你当前项目根目录下两者的区别在于作用范围。装到用户级目录所有项目都能用装到项目级目录只有当前项目能用。我的习惯是通用型技能比如代码审查、周报生成放全局项目特定技能比如对接某个后端接口的规范放项目级。手动安装步骤很简单# 1. 创建全局 skills 目录如果不存在 mkdir -p ~/.claude/skills # 2. 进入仓库目录把某个技能文件夹复制过去 cp -r code-review ~/.claude/skills/ # 3. 验证目录结构 ls ~/.claude/skills/code-review/ # 应该能看到 SKILL.md复制完成后重新打开 Claude Code在对话里用自然语言描述需求AI 就会自动匹配合适的 skill。比如你装了一个叫code-review的技能只要说“帮我审查一下这段代码”它就会读取该技能并执行。这里有一个非常关键的操作细节改完 Skills 文件后需要重开会话才会生效。Claude Code 通常在会话启动时扫描技能目录如果你在对话中途修改了 SKILL.md它不会热加载。别问我怎么知道的反复改了文件不生效最后发现是没重启。2.3 手动安装到 Codex 和 OpenCodeCodex 和 OpenCode 目前对 Skills 的加载方式没有 Claude Code 那么标准化但社区已经有很成熟的约定。以 Codex 为例比较常见的方式是把 skills 放到启动目录下的.codex/skills/或~/.codex/skills/。如果你用的是支持 AGENTS.md 规范的版本也可以在项目里新建一个AGENTS.md用相对路径引用外部的 SKILL.md 文件。我自己是喜欢直接复制目录的方式简单直接。OpenCode 的情况类似默认会在~/.opencode/skills/寻找技能。如果找不到这个目录自己手动创建就行但要注意目录权限很多 Linux 环境下如果目录不是当前用户所有程序会静默跳过。具体代码# Codex mkdir -p ~/.codex/skills cp -r db-design ~/.codex/skills/ # OpenCode mkdir -p ~/.opencode/skills cp -r db-design ~/.opencode/skills/安装完成后同样要重启会话。另外建议在首次安装后先输入一句与技能描述高度匹配的指令看看 AI 是否真的加载了它。2.4 安装后如何验证生效验证 Skills 是否生效是小白最容易忽略的一步。我总结了一个三步验证法直接问 AI 有没有这个技能。在对话里输入“你会哪些 skills”大部分支持工具会列出已加载的技能名称。如果列出了你刚装的技能说明扫描成功。检查加载路径。如果你的工具支持/skills之类的斜杠命令直接查看技能列表确认路径是不是你复制进去的那个目录。用一个触发场景实测。这是最靠谱的方案。比如你装了论文润色技能就故意发一段写得稀烂的文字让它润色看输出格式和语气是否符合技能里的设定。如果发现技能没有加载先别着急重新复制。按优先级排查三件事第一目录名里有没有特殊字符空格、中文、括号全改成小写英文加连字符第二SKILL.md的文件名是不是完全一致大小写错了也会识别不了第三frontmatter 里的name字段是否合法有些工具要求只能包含字母、数字和连字符。3. 怎么挑 Skills常用技能库与场景化推荐装过几个技能之后你就会陷入“技能海洋”里。GitHub 上同名仓库一大堆质量参差不齐。这一章我按自己实际用过的经验把值得收藏的技能源和场景化推荐整理出来。3.1 值得收藏的 Skills 源网站和仓库社区里最省力的做法是先收藏几个聚合型的技能库再从里面挑自己需要的。awesome-claude-skills这类归档仓库会按 category 列出大量技能涵盖代码、写作、数据分析、生活效率等。优点是全缺点是没有统一的安装器需要手动挑选。Superpowers 项目这是 Jesse Vincent网上常称 obra发起的 Claude Code Skills 集合名字在网络热词里出现的频率很高。它不是简单罗列技能而是一套带方法论和工作流的技能包更强调“如何驱动 Claude 做复杂任务”。如果你不知道从哪里开始这个项目可以作为第一个深度学习的对象。TypeSafe 的 AI Skills 仓库这个被很多人缩写为typesafe ai skills github特点是工程化做得比较好。里面的技能都会声明依赖、测试方式和适用范围适合希望在团队内推广 Skills 的开发者。Codex 生态的 skills 集合比如nature skills或cola skills这类在部分竞赛圈子里很流行。名字不用太纠结本质上都是把某个领域的流程固化成技能文件。我个人的建议是不要“逛仓库式”地收藏几十个技能。真正好用的技能不是靠数量堆出来的而是靠跟自己的使用场景匹配。收藏三个高质量源比下载一百个低质量技能有用。3.2 前端开发场景的 Skills前端是 Skills 应用最成熟的领域。因为前端项目规范高度统一组件化、样式方案、状态管理、接口封装。一个前端 skill 可以把这些约定全部固化下来。我前端项目里常年安装这几个技能技能名称作用核心指令内容component-builder按设计稿生成组件读取设计稿描述生成 TSX 组件样式统一用 CSS Modulesapi-client-gen生成接口调用代码根据 OpenAPI 文档生成 TypeScript 类型和请求函数code-reviewer前端代码审查检查可访问性、性能、命名规范输出审查报告commit-helper生成规范提交信息解析 git diff按 Conventional Commits 规范生成提交信息这里我必须强调一个小技巧前端技能里最值钱的不是让它写新代码而是让它做“一致性的维护”。比如写完一个组件后让 AI 按照技能里的规范检查代码风格、检查命名、检查是否缺少 accessibility 属性。这比从零生成代码可靠得多因为生成类任务的不确定性大检查类任务只要规范写清楚AI 执行得很稳定。3.3 数学建模竞赛场景的 Skills最近在高校圈子里“数学建模”和 AI 工具的结合非常火。翻一眼热搜词就能看到“华为杯建模比赛好用的 codex skills”“数学建模 skills 推荐”这类问题。作为参加过多次建模竞赛的人我特别推荐给竞赛场景配置技能包因为竞赛的时间压力极大流程标准化能省下不少时间。一套合格的数学建模技能包至少应该包含五个子技能problem-analysis拆解赛题把模糊的问题转成可量化的研究问题。>description: 数据处理技能AI 看了根本不知道什么时候该用。强描述是这样的description: 对 CSV 格式的数据集进行预处理包括缺失值处理、异常值检测、字段类型标准化并输出一份数据清洗日志。当用户提供数据文件并提到清洗数据预处理分析数据时使用。正文部分我强烈建议按“流程分支输出”的结构组织流程按时间顺序写清步骤AI 会线性执行。分支写明“如果出现 xxx 情况就执行 yyy”。这能让技能更健壮。输出写明最终交付物的格式和命名规则。还有一条很容易被忽略的规范在技能里声明它不做什么。比如数学建模技能里可以写“本技能不做模型调参只做模型选型和实现”防止 AI 超出边界乱操作。4.2 一个完整示例写一个“周报生成器”Skills光讲规范有点干我直接带你写一个开箱即用的技能。需求很常见让 AI 根据 git 提交记录生成周报省去每天记录的工作量。首先创建目录结构weekly-report/ └── SKILL.md然后写SKILL.md--- name: weekly-report description: 根据本周的 Git 提交记录生成周报。当用户要求帮我写周报生成这周的工作汇报时使用。此技能适用于使用 Git 进行版本控制的软件项目。 --- # 周报生成流程 ## 背景 周报面向技术负责人和项目管理员重点描述本周完成的功能、解决的问题以及风险。 ## 执行步骤 1. 在用户指定的仓库目录下执行 git log --since7 days ago --prettyformat:%h|%an|%s获取本周提交记录。 2. 用 jq 或 Python 脚本解析提交记录按功能模块归类。归类优先级新功能、Bug 修复、性能优化、代码重构、文档更新。 3. 根据归类结果按以下模板生成周报 text ### 本周重点 - 列出最重要的 2-3 项工作标注对应提交 ID ### 风险与阻塞 - 如果存在未完成的提交、合并冲突或依赖升级困难列在此处如果没有写无 ### 下周计划 - 基于本周进展推测最多写 3 项输出文件名为weekly-report-YYYY-MM-DD.md保存到当前目录下的 reports 文件夹。注意事项不访问外部 API只使用本地 git 数据。如果仓库没有.git目录直接告知用户该目录不是 Git 仓库不强行生成。周报文字使用中文保持简洁单条不超过 40 字。这个示例麻雀虽小五脏俱全。它包含了触发条件、步骤、模板、文件名规范、异常处理。你把它放进 ~/.claude/skills/weekly-report/ 后一句“帮我生成这周的周报”AI 就会主动跑 git log、归类、套模板、存文件。 我实际用下来最喜欢的一点是**因为它会自动执行 git log所以我不用在对话里提供任何额外信息**。真正的“一句话任务”。 ### 4.3 调试与迭代技巧 写完技能后第一次运行大概率不完美。调试技能我有一套固定流程 1. **先测触发**。故意用描述里的关键词提问确认 AI 能正确唤醒技能。如果唤醒失败问题基本出在 description 上加场景词、加同义词。 2. **测步骤**。用很小的样本数据跑一遍观察 AI 是否按步骤执行。如果它跳过了某步就在 SKILL.md 里把该步骤写得更明确比如加上“必须”“禁止”这类强约束词。 3. **测输出**。检查输出文件格式是否符合预期。如果格式不对把模板放在 references/ 目录里并在正文中用读取 references/xxx.md 中的模板代替在正文中长篇写模板AI 读取参考文件时更稳定。 4. **加负面用例**。想想用户会在什么奇怪场景下触发这个技能在“注意事项”里补上边界条件。 调试过程中最有效的反馈源其实是对话历史里 AI 的自我总结。你可以在一次执行结束后让它“列出刚才执行过程中没有参照技能规范的地方”大部分模型会准确指出问题。然后用这些反馈去升级 SKILL.md迭代几次技能就会越用越顺手。 ## 5. Skills 的维护清理、更新与版本管理 技能装多了之后另一个烦恼随之而来每次会话启动AI 会扫描所有技能目录如果技能数量过多不仅启动变慢还可能出现技能互相干扰的情况。这时候就需要维护和清理。 ### 5.1 什么时候需要清理 Skills 我自己判断是否需要清理主要看三个信号 - **会话响应变慢**。模型每次都要把所有技能描述读一遍技能太多会拉低响应速度。 - **技能互相抢戏**。比如你同时装了“代码审查”和“代码风格检查”AI 不知道该先执行哪个最后可能输出一个四不像。 - **长期没用过**。装了好几个月的技能一次都没触发留着也是浪费。 清理不是简单删除而是先做一次“技能盘点”。我习惯用一个临时技能或脚本扫描所有 skills 目录列出每个技能的名称、描述、最近修改时间和大小。然后按“高频使用 / 偶尔使用 / 从未使用”分成三类。高频和偶尔的保留从未使用的直接禁用或删除。 ### 5.2 清理与禁用 Skills 的正确姿势 关于清理网上讨论里经常提到的 tibo 推荐的思路值得借鉴**不要急着删除目录先“隔离”**。 所谓隔离就是把暂时不用的技能移到一个专门的 disabled-skills 目录而不是彻底删除。因为技能文件往往包含你积累的 prompt 经验和流程设计删了就没了。隔离操作很简单 bash # 不再使用的技能移出加载目录 mv ~/.claude/skills/old-skill ~/.claude/skills_disabled/old-skill # 彻底删除前先打包备份 tar -czf skill-backup-$(date %Y%m%d).tar.gz ~/.claude/skills/我强烈建议养成定期备份 skills 目录的习惯。skill 的迭代是很珍贵的资产备份一下成本极低省得哪天不小心覆盖了好用的版本。这里还要提醒一个小细节清理技能后一定要重启会话。很多工具只在启动时扫描一次技能列表清理后如果不重启AI 仍然会认为技能存在甚至出现“报错了又说找不到技能”的诡异现象。5.3 更新与本地化改造GitHub 上的技能仓库更新很频繁但我不建议每次更新都无脑拉取覆盖。更好的做法是先看 changelog。如果新版本只是改了 README那跟你没关系。如果是 SKILL.md 里的核心指令变了再考虑要不要更新。保留本地定制。很多人装完技能后会改一版适合自己的比如把周报模板改成公司格式。这种本地化改造很容易被上游更新覆盖所以我在每个技能目录里会额外放一个LOCAL_CHANGES.md记录本地改了什么更新后按这个文件重贴 patch。把 Skills 当成代码来管理而不是当成文件来堆。我自己现在会把所有技能目录纳入 Git 仓库管理每次改动提交一次这样出问题随时能回滚。这个习惯强烈推荐给你特别是团队协作时特别有用。6. 几个容易踩的坑和实战心得最后这部分我分享一些在真实项目里踩出来的经验。这些内容很少出现在正式文档里但能帮你少走很多弯路。6.1 Skills 不是越多越好社区里有个误区觉得技能库越庞大越专业于是装了几十个技能。实际运行的时候模型要先在几十个技能描述里做相关性匹配匹配错了整场对话就偏了。我现在的原则是“够用就好”。一个项目场景下常用技能控制在 5-8 个以内。剩下的技能放到独立目录需要时再复制到加载目录。如果你觉得切换太麻烦可以在技能描述里写清“该技能仅在用户要求 xxx 时使用”降低误触发的概率。6.2 依赖环境的坑一个技能往往依赖外部命令。比如上文周报生成器依赖git数据处理技能依赖pandas。这些依赖装不装、装成什么版本都会直接影响技能执行结果。我在写技能时会明确在 SKILL.md 里声明依赖和安装方式。例如## 环境要求 - Python 3.10 - 安装依赖pip install pandas numpy scipy如果某些模型支持在技能里带requirements.txt就用文件声明。这样别人拿到你的技能也能顺利复现。6.3 安全与权限问题Skills 的本质是让 AI 按照你写的指令去执行操作如果指令里有恶意内容后果可能很严重。比如一个看起来是“生成代码”的技能背地里却要求 AI 执行系统命令、读取敏感文件。所以建议做到两点只安装信任来源的技能。从 GitHub 下载前扫一眼 SKILL.md 的正文看有没有可疑的系统操作指令。给技能设置边界。在技能里写“禁止执行文件删除、网络请求、环境变量修改等高风险操作除非用户明确要求”。这不只是为了安全也能防止 AI 在正常工作时因为误操作闯祸。我个人的体会是Skills 最迷人的地方在于它把“经验”变成了可复制的资产。你踩过的坑、沉淀的方法论、打磨过的流程都能写进一个 SKILL.md 文件里下次换个项目、换台机器、甚至换个人都能一键复用。与其到处找别人整理好的技能清单不如从今天开始把自己最常做的一件事拆解成流程写进你的第一个 SKILL.md 里。等这段流程跑顺了你会发现自己对 AI 的使用方式完全不同了。