只有橘子最近好几个朋友问我同一个问题：Skills到底怎么用？看着社区里大家都在装Superpowers、Nature、Cola这些技能包，我也去GitHub上拉了一堆回来，可真到干活的时候，AI好像也没变聪明多少。
这个困惑我太理解了。因为我第一次接触Skills的时候也是这样，装了一大堆，然后一脸懵。但用了一段时间、踩过一些坑之后，我意识到Skills这套机制本质上非常朴素——它不是给AI施魔法，而是给AI发了一套"岗位SOP"。这篇文章我就从最基础的东西讲起，把"怎么简单使用SKILLS"这件事彻底说清楚，覆盖Claude Code、Codex这类主流AI编码工具，也会聊到论文写作、数学建模、前端开发这些常见场景的实践感受。
1. Skills到底是什么：从一叠SOP到AI职业手册
1.1 为什么突然冒出个"Skills"概念
先说背景。AI编码助手刚火的时候，大家使用AI的方式非常原始：把一大段要求复制粘贴到对话框里，让AI去干活。问题在于，哪怕你把同一段需求反复粘贴一百遍，模型输出的"过程"也是不稳定的——今天它可能规规矩矩按你的流程来，明天就直接跳步给你一个半成品。为什么？因为对话上下文太短、太杂，AI没有一份"遇到这类任务时应该遵循的固定工作流"。
Skills就是来解决这个问题的。以Claude Code为代表的一批AI编程工具，允许你把一组"针对特定任务的完整做法"打包成独立的文件放好。工具在运行过程中识别到对应任务，就会自动读取这套文件，并按照文件里写的步骤、规则、模板来执行任务。
我习惯把Skills理解为"行业操作手册"。你招了一个能力很强的实习生，他什么都会一点，但没做过你们公司的项目。你给他一套前端开发的SOP，他做前端的时候就照着SOP走；你再给他一套数学建模的SOP，他建模的时候也按那套思考框架来。Skills干的就是这件事——让AI在不同任务里表现出"稳定且专业"的流程感。
1.2 Skills和普通Prompt的核心区别
很多人的第一个疑问是：我写一大段Prompt不也一样吗？不一样，区别非常明显。我把两者放在一起对比过，差异体感很直接：
| 对比维度 | 普通Prompt | Skills |
|---|---|---|
| 复用性 | 每次都要复制粘贴，还容易遗漏 | 一次性写入，多次调用，随处迁移 |
| 结构 | 一段话带过，步骤全靠AI自己脑补 | 分步骤、分阶段，有明确的质量门槛 |
| 共享性 | 只能自己用，没法分享 | 可以放进GitHub，全球开发者一起维护 |
| 版本管理 | 改一次丢一次，历史无从追溯 | 天然是文件、目录，可以纳入Git版本管理 |
| 触发方式 | 每次手动重申 | 通过技能描述中的触发词自动识别，按需生效 |
普通Prompt是一张便利贴，Skills是一本操作手册。便利贴适合随手写两句，但如果你发现同一套要求在反复使用、反复修改，那就该把它固化成Skills了。
1.3 现在主流工具里的Skills长什么样
不同工具的落地形式略有差异，但核心思路一致：
- Claude Code：用户级技能放在
~/.claude/skills/目录下，项目级技能放在项目根目录的.claude/skills/下。每个技能是一个独立目录，目录内必须有SKILLS.md文件作为核心指令。 - Codex：OpenAI Codex 类工具支持类似机制，主要通过
AGENTS.md这类项目说明文件来约束AI行为，也支持从外部导入技能集。 - 网页版入口：一些云开发环境或网页版AI工具会把Skills文件当作"工作区配置"或"知识库"导入，具体入口要看各自文档。
所以你不需要纠结"到底要不要用Skills"——只要你在用AI干活，并且希望AI的输出保持稳定，那你早晚需要一个类似Skills的机制。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 安装与生效路径：覆盖Claude Code、Codex和网页版入口
2.1 Claude Code：从建目录到跑通第一个技能
我以Claude Code为例，因为它的Skills支持最成熟，生态也最丰富。第一步先确认版本：
bash复制claude --version
建议用最新版本，早期版本对Skills的支持不完整。然后创建技能目录：
bash复制mkdir -p ~/.claude/skills/code-review
这个目录名字 code-review 就是技能名。接下来在目录里创建 SKILLS.md，这是技能的"主脑"。你可以用一个最简单的示例验证流程：
markdown复制---
name: code-review
description: 当用户要求检查代码质量、做代码审查时使用此技能。
---
# 代码审查
## 执行步骤
1. 先通读代码，理解整体结构和职责。
2. 检查命名、注释、函数长度、重复代码。
3. 检查错误处理与边界条件。
4. 输出问题清单，按严重程度排序。
5. 给出修复建议，必要时直接给出示例代码。
保存之后，在Claude Code会话里运行：
bash复制/skills
如果列表里出现了 code-review，说明技能已经被加载。这时你随便贴一段代码，说"帮我审查一下"，AI就会按照SKILLS.md里的步骤走，而不是自由发挥。
2.2 项目级技能与用户级技能怎么选
用户级技能放在 ~/.claude/skills/，所有项目都能用。项目级技能放在项目根目录下的 .claude/skills/，只有进入这个项目目录才会加载。
我的建议是：通用的、跨项目的技能（比如代码审查、提交信息规范）放用户级；和具体业务强相关的技能（比如你们公司的后端代码规范、特定框架的迁移步骤）放项目级。项目级技能还能跟着Git仓库走，团队其他人clone下来就直接共享同一套工作流，这一点在团队协作里非常好用。
2.3 手动安装GitHub上的Skills包
热搜词里有个高频问题：Claude Code怎么手动装GitHub上的skills？其实原理就是上面说的目录机制——绝大多数技能仓库的目录结构都是现成的，你只需要把对应目录放到 ~/.claude/skills/ 下。
假设你看到一个仓库叫 awesome-skills，它的目录结构是这样的：
text复制awesome-skills/
├── code-review/
│ └── SKILLS.md
├── git-commit/
│ └── SKILLS.md
└── refactor/
└── SKILLS.md
你可以直接clone整个仓库，然后只把需要的技能目录复制到Claude的技能文件夹：
bash复制git clone https://github.com/example/awesome-skills.git
cp -r awesome-skills/code-review ~/.claude/skills/
cp -r awesome-skills/refactor ~/.claude/skills/
注意，有些仓库提供一键安装脚本，有些依赖子模块，这些都要先读README再操作。装完之后重启会话，用 /skills 确认。
2.4 Codex和其他工具的安装差异
Codex类的工具不完全照搬Claude的目录结构。有的用项目根目录下的 AGENTS.md 来约束AI行为，有的支持在配置里指定外部技能目录。我的经验是：不管用什么工具，第一件事永远是读官方文档里关于"skills"或"agents"的那一章，不要看到一个GitHub仓库就往里塞，装错位置不会报错，只会让AI无视你的技能。
2.5 验证技能是真的生效，而不是"看起来装了"
装完技能后，最忌讳的事情就是不做验证。我见过太多人装了一堆技能，然后发现AI行为毫无变化，于是得出结论"Skills没用"。
正确的验证方法是"特征触发法"：选择一个技能里描述得最独特的场景，故意触发它。比如你的技能写的是"当用户要求分析日志时使用此技能"，那你就丢一段日志让AI分析。如果AI输出的格式、步骤、术语都符合技能里写的内容，说明生效了；如果输出明显是通用风格，那就要检查目录位置和描述触发词了。
3. 去GitHub淘技能包：怎么判断一个仓库值不值得装
3.1 社区里绕不开的几个名字：Superpowers、Nature、Cola
现在GitHub上Skills相关的仓库非常多，但口碑好、被反复提及的集中在几个方向：
Superpowers：这是目前社区讨论度最高的一组技能集，主要面向软件开发。它把工作流拆成了规划、执行、调试、测试、提交等环节，每个环节都有对应的技能。核心理念是"让AI先想清楚再做"，特别适合写代码时容易冲动出活、改来改去的情况。安装通常通过npm或者一键脚本完成，具体看仓库README。
Nature：偏轻量的技能管理工具，设计上更关注"如何创建、管理和组合技能"，附带一些常用技能模板。风格比Superpowers简洁，适合不太喜欢被流程约束、只想给AI加一点规则的人。
Cola：社区里一个覆盖面比较广的综合性技能合集，里面有不少拿来就能用的通用技能。特点是大而全，但正因为它大而全，我反而建议你按需挑选，不要把整个合集一股脑灌进去。
这三个仓库各有拥趸，没有绝对的好坏。Superpowers适合软件开发重流程场景，Nature适合轻量使用和技能自建，Cola适合快速找灵感。如果你刚接触，我建议先从Superpowers的若干核心技能入手，因为它的文档最完整、社区讨论最多。
3.2 评估一个技能仓库的五个检查点
GitHub上的技能仓库鱼龙混杂，有一些只是把几个Markdown文件堆在一起，质量堪忧。我判断一个仓库值不值得装，一般看五点：
- README是否说明了支持的工具和版本。如果连Claude Code还是Codex都没写清楚，大概率是个粗制滥造的仓库。
- 目录结构是否标准。核心技能目录里必须有
SKILLS.md，如果整个仓库连一个SKILLS.md都找不到，那它只是"关于skills的文章"，不是"skills本身"。 - 最近更新时间和Issue反馈。超过半年没更新、Issue长期没人回，就要谨慎，因为Skills机制本身还在快速演进。
- 是否和你主用工具匹配。Claude Code的技能搬到Codex上不一定能直接用。
- 技能粒度是否合理。好的技能是一个技能解决一类问题，而不是一个技能试图解决所有问题。
3.3 按场景选型的参考表
基于这个选型思路们结合社区常见的需求场景，我整理了一份参考表：
| 场景 | 推荐方向 | 说明 |
|---|---|---|
| 前端开发 | Superpowers + 前端专项技能 | 组件生成、代码审查、样式规范都能覆盖 |
| 数学建模 | 社区数学建模skills包 | 一般包含问题拆解、模型选择、结果验证等流程 |
| 论文写作 | workbuddy类写作技能 | 管理从大纲到参考文献的写作流程，注意遵守学术规范 |
| AI漫剧/多媒体脚本 | 脚本创作类技能 | 角色设定、分镜、对白、时长估算的流程化 |
| 日常脚本开发 | 通用代码生成类技能 | 先设计再编码，减少返工 |
具体仓库名称我不多列，因为这类仓库迭代太快，今天热门的明天可能就归档了。你在GitHub搜索时，直接搜"claude skills"、"codex skills"、"superpowers"、"nature skills"这些关键词，再按上面的检查点筛选。
4. 五类高频场景实测：论文、建模、前端、脚本与开发流程
4.1 数学建模：AI的思考框架被固定住了
数学建模最怕的不是AI不会算，而是AI的思考过程飘忽不定。同一道题你让它做两遍，第一遍它先分析数据假设，第二遍它直接上来列公式，你根本没法跟进它的思路。
我装了一个数学建模技能包之后，再让它处理建模题，它会强制走"问题理解-条件假设-模型选择-求解计算-结果验证-成文排版"这条路径。哪怕模型选错了，至少每一步都有迹可循，我能清楚地指出是假设环节出问题还是求解环节出问题。这个"可追溯性"就是Skills带给我最大的价值。对准备数学建模比赛或者学术研究的人来说，一个稳定的思考框架比偶尔的灵光一现重要得多。
4.2 论文写作：把"写论文"拆成可管理的任务
用workbuddy这类写作技能，最直观的感受是写论文不再是一句"帮我写一段引言"就能糊弄过去的事。技能会先让你明确研究问题、目标读者、核心论点，然后生成大纲，再逐段扩充，最后统一做术语一致性和参考文献检查。
这个过程看起来比直接让AI写慢，但最终稿的质量稳定得多。尤其对于长篇材料，AI如果没有一个"先框架后填充"的强制流程，写到后面经常出现论点重复、结构头重脚轻的问题。技能包在这里扮演的角色，就是那个一直提醒你"先别急着写，把框架定好"的合作导师。
使用AI辅助论文写作时，务必确认所在机构对AI使用的规定，按要求声明，学术诚信的底线不能碰。
4.3 前端开发：组件的风格一致性有救了
我做前端开发时的痛点不是AI不会写代码，而是它每次写的代码风格都不一样。同一个组件，这次用函数声明，下次用箭头函数；这次样式写在CSS文件里，下次又变成了内联样式。代码review的时候改这些琐碎差异特别消耗精力。
给AI配上前端开发类Skills后，技能里明确写了：组件必须遵循项目既有的目录结构、命名规范、样式方案和提交格式。AI生成的代码天然符合同一套规范，review时间压缩得很明显。如果你带团队，把团队规范固化成技能放进项目级目录，新成员用AI开发时产出的代码也会是统一的风格，这比贴一份规范文档在群里高效得多。
4.4 脚本开发与代码重构：先分析后动手
日常写小脚本、做代码重构，我习惯用Superpowers里的流程类技能。它会让AI先输出一份"改动计划"，包括涉及哪些文件、每个文件改什么、风险点在哪，我再确认计划后AI才动手改代码。
听起来很啰嗦，但它硬生生逼着AI养成了"先想后做"的习惯。以前AI拿到重构需求直接甩出十几个文件的大改动，我根本不敢合入；现在它先拆解计划、再分步执行，每一步都能审查。重构这种高风险操作，流程确定性比速度重要得多。
4.5 AI漫剧与多媒体脚本：创意工作的流程化
AI漫剧、短视频脚本这类场景也有人在做专门技能包。它们的流程通常是：先定角色设定和世界观，再拆场景、分镜，然后写对白，最后估算时长和配乐建议。你可能会觉得创意工作不该被流程绑住，但实际测试下来，有了流程之后AI的产出反而更完整了——至少不会出现角色前后性格不一致、分镜之间衔接不上这类低级问题。
技能包不是把创意变成流水线，它只是保证了创意的下限。真正精彩的点子，仍然需要你来提供。
4.6 实测过后的一个重要感受
如果你期望装完某个技能包之后AI立刻脱胎换骨，那你大概率会失望。技能包不是魔法，它给的是"流程确定性"。AI的能力上限基本没变，但输出的下限被拉高了——不飘、不跳步、不前后矛盾。对实际工作来说，下限稳定比上限偶尔爆发更重要。
5. 自己动手写Skills：从目录结构到SKILLS.md模板
5.1 一个技能的最小目录结构
与其到处找现成的技能包，不如自己写一个。因为技能的本质是"把你的工作方法沉淀成文件"，只有你自己最清楚做某类任务时应该遵循什么步骤。最小结构如下：
text复制my-skill/
├── SKILLS.md
├── template/
│ └── example.md
└── scripts/
└── helper.py
其中只有 SKILLS.md 是必须的。template/ 和 scripts/ 是可选资源，技能执行过程中AI可以读取模板，也可以调用脚本辅助处理。
5.2 SKILLS.md的标准区块拆解
我倾向用下面这套结构来写SKILLS.md，社区主流写法也大同小异：
markdown复制---
name: 技能名
description: 什么情况下使用此技能，包含触发词。
---
# 技能说明
一句话说明这个技能解决什么问题。
## 适用场景
列出适合使用此技能的任务类型。
## 执行步骤
1. 第一步做什么
2. 第二步做什么
3. 第三步做什么
## 质量清单
输出内容必须满足的标准，例如"所有代码必须包含错误处理""所有文件必须遵循命名规范"。
## 约束与禁忌
明确禁止AI做的事，例如"不要在没有确认的情况下修改公共函数签名"。
name 和 description 在YAML头里，description尤其重要，因为AI是靠它来判断"当前任务是否匹配这个技能"的。触发词写得越明确，技能在对话中自动激活的概率越高。
5.3 一个可以直接抄的示例：前端代码审查技能
下面是我自己常用的一个前端代码审查技能，你可以直接复制后根据自己的情况改。
markdown复制---
name: frontend-code-review
description: 当用户要求对前端代码进行评审、检查代码质量、review代码时使用。适用于HTML、CSS、JavaScript、TypeScript以及常见前端框架代码。
---
# 前端代码审查
## 执行步骤
1. 先阅读完整代码，概括组件/页面职责。
2. 从以下维度逐项检查：
- 语义化：标签和类名是否语义化，是否可访问。
- 样式：是否有硬编码尺寸、颜色；是否遵循项目设计变量。
- 逻辑：事件绑定是否清理，是否有潜在内存泄漏。
- 性能：是否存在不必要的重渲染、大数据量循环渲染。
- 错误处理：请求失败、资源加载失败是否有兜底。
3. 输出问题清单，按严重程度分为高、中、低三档。
4. 每个问题给出修改建议；高档问题给出示例代码。
## 质量清单
- 每条问题必须能定位到具体代码位置。
- 建议必须可执行，避免"建议优化"这种空话。
- 如果代码整体质量良好，明确说明，不要为了找问题而找问题。
## 约束与禁忌
- 不修改业务逻辑，只做审查和建议。
- 不引入新的依赖作为解决建议，除非项目已有该依赖。
- 不讨论与代码质量无关的风格偏好。
把上面的内容保存到 ~/.claude/skills/frontend-code-review/SKILLS.md，重启Claude Code，然后丢一段前端代码让它审查，你会看到它输出的问题清单结构和以前明显不同。
5.4 慢慢进阶：多文件技能和自动化
用熟单个技能之后，你可以让技能变得更强大：
- 多资源文件：在技能目录里放模板文件、参考示例、检查清单，让AI在执行时调用。比如审查技能里放一个"团队前端规范.md"，AI审查时自动对照。
- 配合外部脚本：技能可以引用外部脚本，例如用脚本自动统计代码复杂度、检查图片资源大小，把脚本输出纳入审查报告。
- 多个技能串行：一个问题可以触发多个技能，比如先"规划"再"执行"再"测试"。这在Superpowers这类流程型技能集里很常见。
模板文件方面，我现阶段的建议是：先确保单一技能跑得稳，再去搞复杂编排。十几个技能互相打架的时候，排查问题会让你怀疑人生。
6. 我踩过的坑和剩下的建议
6.1 坑一：技能装错了位置，AI完全无视
我第一次装Skills的时候，把技能目录放到了当前项目的普通文件夹里，想着AI应该能扫描到。结果AI完全无视，我还以为是技能写得不好。后来才发现，Claude Code只认 ~/.claude/skills/ 和项目下的 .claude/skills/ 这两类目录。位置不对，技能写得再好也白搭。
装技能之后，第一件事永远是 /skills 列表确认。看不到名字，就说明路径有问题，别急着改技能内容。
6.2 坑二：项目级技能和用户级技能同名冲突
项目级技能的优先级高于用户级技能。如果你的项目里有一个 code-review，用户目录下也有一个 code-review，AI会优先用项目级的，而且不会给你任何提示。这个问题排查起来很隐蔽，因为表面上看两个技能都"存在"。
解决办法也简单：保持命名唯一，项目级技能名加上项目前缀，比如 project-alpha-code-review。这样冲突概率小得多，团队协作时也容易识别。
6.3 坑三：一次性装几百个技能，上下文直接爆炸
有些技能合集仓库动辄上百个技能，我一度觉得"装得越多越好"。实际使用后，每开一个会话，工具都要给AI提供一份技能清单，技能太多会占掉大量上下文窗口，导致AI在处理任务时的有效记忆变短，表现反而下降。
现在我会严格限制自己，只保留高频使用的10-15个技能。新技能先试用一两周，确实有价值再留下来；没用的果断删掉，把技能目录当作一个需要定期清理的衣柜。
6.4 坑四：把AI当成"全自动执行器"
装了流程类技能之后，有一段时间我完全放开手，让AI自己跑完整条流程，结果翻了一次大车——它按流程走得很漂亮，但方向从一开始就错了。
Skills保证的是"过程稳定"，不是"方向正确"。方向靠谁来定？靠你。技能里的约束写得越明确，AI跑偏的余地越小，但最终的决策检查责任始终在你身上。流程类技能是让你省心做决策，不是让你不做决策。
6.5 我现在的使用习惯
经过这段时间反复折腾，我的最终使用习惯是：先梳理自己反复做的任务类型，挑一两个痛点，自建对应技能；再从社区找成熟方案补齐自己不擅长的领域，按需挑选而不是全量安装；每隔一两周过一遍技能清单，删除闲置的，更新失效的。
我个人认为，Skills这套机制最有价值的地方，不在于它让AI变聪明了多少，而在于它逼着我把自己做事情的方法论整理成了文件。整理的过程，本身就是一次自我复盘。你不需要一上来就搞超级复杂的技能集，从一个小技能开始，让它稳稳跑起来，你的AI使用体验会上一个台阶。