差不多一个月前，我还在手动往~/.claude/skills里塞各种 SKILL.md 文件，一边塞一边抱怨网上关于 Matt Pocock Skills 的内容太零散。当时我对这个词的理解很简单：一个叫 Skills 的插件系统，装上就能让 AI 多几个超能力。真正让我改观的，是某天我把一套 TDD 技能装进日常流程之后——我的代理开始先写失败的测试、再写实现、跑绿了才收工，从“给什么写什么”直接升级成“按规范执行任务”。
这篇文章不是什么官方文档翻译，而是一份从实际折腾中沉淀下来的使用指南：为什么 Skills 能改变 AI 编程习惯、Matt Pocock 那套 Superpowers 到底厉害在哪、不靠一键脚本怎么手动把 GitHub 上的技能请到本地、一个 SKILL.md 文件内部是怎么运作的，以及技能装多之后躲不开的清理与冲突问题。适合正在被“提示词越写越长但效果越来越不稳定”困扰的人，也适合刚听说 Skills 这个概念、想从零开始研究的读者。废话不多说，直接进入正题。
1. Skills 并不是新发明，只是把 AI 从“临时工”变成“老员工”的说明书
1.1 什么是 Skills？为什么大家都在谈
在 Claude Code、OpenCode、Codex 这些 AI 编程工具里，Skills 其实是一份可以反复使用的“岗位说明书”。它通常是一个目录，里面放一个描述自身用途的文件（最常见的是 SKILL.md），可能还附带脚本、模板、示例数据。当你的对话内容命中某个技能的描述条件时，工具会把这份说明书注入上下文，AI 随后会严格按照说明中的流程、规则和验收标准来执行任务。
很多人容易把 Skills 和普通提示词混在一起。我理解的区别是：提示词是一次性的，每次都要重新写、重新调；Skills 是持久化的，写一次之后可以在后续会话里被自动加载。更重要的是，Skills 的目标不是让 AI“说得好”，而是让 AI“做得对”——它把任务的分步做法、决策边界、常见误区全部固定下来，就像老员工入职时领到的那本 SOP 手册。
1.2 为什么“给 AI 装技能”突然成了关键词
最近一段时间我更新了不少工具版本，最大的感受是模型本身的能力已经足够强，瓶颈反而在“工程化”上：模型知道怎么写代码，但不知道你的项目有什么偏好、团队有什么规范、你希望先写测试还是先补文档。Skills 恰好补上了这个缺口——它让一个人沉淀下来的工作流，可以被另一个人直接复用。
这也是 Matt Pocock 的前端开发 Skills 能被大量搬运的原因。Matt 本身就是做 TypeScript 教育的，他非常清楚“讲清楚规则”和“让模型能执行规则”是两回事。他把前端的代码规范、重构思路、测试流程写进技能里，等于把一个资深前端的工作习惯编译成了让 AI 照着跑的说明书。你不需要懂他脑子里的完整逻辑，只要把技能装上，AI 就能沿着他预先设计好的路径工作。
1.3 Skills 和 Rules、MCP 到底区别在哪
这个坑我踩过，先说清楚，免得后面混淆。Rules（规则）通常是一组简短的行为约束，比如“永远使用函数组件”“提交信息遵循 Conventional Commits”；Skills 则是完整的工作流程，包含步骤、分支判断和输出格式。MCP（模型上下文协议）解决的是 AI 和外部工具、数据源的连接问题，比如让 AI 查数据库、发请求；Skills 解决的是“面对一个任务时按什么步骤、什么标准完成”的问题。
三者能配合，但职责不同。你完全可以在一个技能内部要求 AI 调用某个 MCP 工具，但技能本身不是连接器，它是作业流程。如果你还停留在“把所有约束都堆进 system prompt”的阶段，那 Skills 就是更进阶的替代方案：约束被拆散了、分类了、按需加载了，而不是一股脑塞进每个会话里。
2. Matt Pocock 的 Superpowers：他往文件夹里塞了什么
2.1 Superpowers 不是黑魔法，而是“显式工作流”
Matt Pocock 那套名为 Superpowers 的技能集合，在 GitHub 上常被搜作 superpower skills 或 typesafe-ai-skills。它最初给我的感觉像是一个“提示词合集”，直到我认真读完其中几个 SKILL.md 文件才意识到，它做的其实是把软件开发里那些“模型默认应该懂、但经常不做”的流程显式化。
举个例子，代码评审技能。如果直接让 AI“帮我 review 一下代码”，它大概率会泛泛而谈：调整风格、补充注释、注意边界。但 Superpowers 的代码评审技能会要求 AI 先梳理整个变更范围，再按提交粒度逐条列出问题；每个问题需要注明严重级别、影响文件、复现步骤、可参考的修复方向。它甚至会规定 AI 在评审时不要顺手改代码——评审就是评审。这种“边界感”比模型默认行为强得多，效果立竿见影。
2.2 从 TDD 技能开始试水：为什么流程类技能最容易见效
如果你刚接触 Skills，我强烈建议从测试驱动开发（TDD）类的技能入手。原因很简单：它的流程是“最硬”的，模型不容易糊弄。装好之后，你让 AI“实现一个函数”，它会先停下来问：需求是什么？模块边界在哪？现有测试覆盖了什么？然后根据技能模板先写失败用例，跑一遍确认失败，再实现逻辑，最后跑通完整测试。
在实操中你会发现，模型并不是每次都能完美执行整套流程，但技能文本会把流程步骤牢牢嵌入上下文，所以即使模型“走神”，它也更容易被拉回来。这就是文本型技能的价值：它不靠模型自觉，靠过程控制。很多人觉得“AI 写代码不行”，其实很多时候是缺少这种显式的过程控制。
2.3 为什么我建议先手动安装，而不是跑一键脚本
网上有各种一键安装脚本，但我个人的观点是：用脚本之前，请先手动装一次。原因有三个。
第一，手动安装能让你看清技能的真实目录结构和触发条件，出了问题知道去哪排查，而不是对着一堆自动化脚本干瞪眼。第二，很多脚本会往全局目录塞一堆技能，你根本不知道每个技能是干嘛的，时间一长环境就变成一团乱麻。第三，手动安装的过程本身就是一次安全审计：逐行看过 SKILL.md 之后再决定要不要启用它，这个动作比任何“信任脚本”都靠得住。
3. 手动安装 GitHub 上的 Skills：把配置牢牢掌握在自己手里
3.1 第一步：把技能仓库 clone 到本地并做基本审计
以最常见的 Claude Code 为例。安装一个技能前，我会先找到技能的 GitHub 仓库，然后 clone 到临时目录：
git clone https://github.com/your-user/your-skill-repo.git /tmp/skills-check cd /tmp/skills-check ls -la强调一句：不要急着把所有文件都复制走。先看仓库结构。大多数技能仓库会有一个skills/目录，里面每个子目录就是一个独立技能；也有仓库直接在根目录放多个 SKILL.md。打开 SKILL.md 从头到尾读一遍，确认它做的事是你需要的，确认没有让你无法理解的远程脚本或危险命令，再进入下一步。
这一步听着繁琐，但真的能避免后患。技能的本质是给 AI 增加可执行的能力，如果你把一个来源不明的技能装进环境，等于给 AI 发了一张“照做即可”的命令书——它不会替你判断这个指令是否合理。
3.2 第二步：确定安装目录，别把 SKILL.md 放错层级
对于 Claude Code，技能目录分两级：
- 全局技能：
~/.claude/skills/<skill-name>/SKILL.md - 项目技能：
.claude/skills/<skill-name>/SKILL.md（放在项目根目录）
全局技能对所有项目生效，适合放通用工作流，比如 Git 提交规范、代码评审、通用调试流程。项目技能只对当前仓库生效，适合放和业务强相关的技能，比如“后端 API 补全流程”“数据迁移脚本写法”。具体操作就是把刚才 clone 下来的技能目录复制到目标位置：
# 以全局技能为例，Linux / macOS 下 mkdir -p ~/.claude/skills cp -r /tmp/skills-check/skills/code-review ~/.claude/skills/ # Windows PowerShell 下 # New-Item -ItemType Directory -Force $HOME\.claude\skills # Copy-Item -Recurse /tmp/skills-check/skills/code-review $HOME\.claude\skills\复制之后检查目录结构，必须是~/.claude/skills/code-review/SKILL.md这种形式。很多人把 SKILL.md 直接丢到~/.claude/skills/SKILL.md，这是不会被识别的——技能必须以独立子目录为单位存在。
3.3 第三步：新开会话验证加载情况
装完之后，别急着关终端。重新打开一个会话（技能通常在会话启动时扫描目录，当前会话不一定会热加载），然后直接问 AI：你加载了哪些技能？它们的名字是什么？
如果 AI 列不出来，优先检查三个地方：目录层级是否正确、文件名是不是叫SKILL.md、YAML frontmatter 是否完整。部分工具的扫描逻辑严格区分文件名大小写，写成skill.md也很容易翻车。另外要提醒的是，旧会话里 AI 可能保留着上一轮上下文，刚装完技能后最好新开会话再测试。
如果你用的编码工具带有网页管理界面，也可以从设置面板的“技能/Skills”入口查看当前已加载列表。但无论界面多花哨，底层事实来源仍然是那个目录——页面只是把目录结构可视化了而已。
3.4 OpenCode、Codex、Cola 等工具：目录有差异，机制有共性
当前能承载 Skills 的不只有 Claude Code。OpenCode 支持类似机制，技能目录通常放在项目下的.opencode/skills/或用户配置目录；Codex 和 Cola 等工具也陆续在适配。这里我不给出绝对路径，因为版本变化太快，最靠谱的方法是看官方文档搜“skills directory”，然后按“全局放通用技能、项目放特定技能”的原则放置。
无论路径叫什么，核心机制一致：工具在会话开始时扫描技能目录，把每个技能的 name 和 description 建一个索引，命中后载入完整正文。所以你在任何工具里装的技能，迁移到另一个工具时主要改目录，不用重写整个 SKILL.md。
4. 拆开一份 SKILL.md：AI 是怎么被一步步指挥的
4.1 一份可被识别的 SKILL.md 长什么样
一个能被工具正确识别的 SKILL.md 通常长这样：
--- name: code-review description: 当用户要求对代码进行审查、检查代码质量、发现潜在缺陷或合并前评审时使用。执行时会先分析变更范围，再按严重级别逐条输出问题。 --- # Code Review 技能 ## 目标 对用户指定的代码变更做系统化评审，提供可执行的改进建议。 ## 步骤 1. 先列出本次变更涉及的文件和提交范围。 2. 逐文件阅读，记录可疑点。 3. 按严重级别分组输出，每条包含影响文件、问题描述、修复建议。 ## 输出格式 ...name是技能的唯一标识；description是触发器的来源。工具会把当前对话上下文和所有已安装技能里的description做匹配，匹配成功后才将完整 SKILL.md 读入上下文。简单说，description 是技能表面的“招牌”，正文是客人进门后看到的“菜单”。
4.2 description 是技能的入口，写不好就废了
这段是我最想强调的。很多人写自己的 Skills 时，把全部精力放在正文流程上，description 随手写一句“用于代码审查”，结果发现技能根本不会被触发，或者动不动误触发。
这里的关键在于：description 是技能的唯一索引。写得过于简短，AI 无法判断技能与当前需求是否匹配；写得过于宽泛，又会和别的技能互相抢占触发权。我自己写技能时的经验是，description 至少包含三个信息：触发场景、任务对象、输出预期。比如前面例子里的“当用户要求对代码进行审查、检查代码质量、发现潜在缺陷或合并前评审时使用。执行时会先分析变更范围，再按严重级别逐条输出问题。”前半句是触发条件，后半句是执行预期，AI 看了一目了然。
4.3 正文写“强制动作”的三条经验
正文是给 AI 的指令，但普通口语和流程指令的差距很大。我总结了几条实战经验。
第一，用祈使句明确边界。“只检查，不要修改任何源文件”比“你应该注意不要随意修改代码”好用得多，因为模型对否定式宽松约束的遵守率不够稳定。第二，给判断分支。“如果测试尚未通过，停止输出修复方案，先执行测试并汇报结果”，这能让 AI 面对异常路径时不自作主张。第三，固定输出结构。凡是需要稳定产出的任务，都在技能里给一个 Markdown 模板，AI 照着模板填空，产出质量会稳定很多。
网上关于“ai skills 怎么写”的讨论很多，有些教程会把整个知识库塞进一个 SKILL.md。我的态度是：技能文件应该轻。它负责写流程、给边界、定输出格式，而不是把百科全书塞进去。如果真有大量背景知识需要带，放一个“参考资料”相对路径或外部链接让 AI 按需读取，比全部堆进技能里更合理。
4.4 技能不触发、乱触发，怎么排查
技能装好但没被调用，是新手遇到最多的问题。排除路径错误后，九成原因是 description 写得太差。你可以做一个实验：把 description 改成“场景 + 对象 + 预期”的写法，然后新开会话，用包含触发词的自然语言提问，看工具的响应开头是否标注“已使用 XX 技能”。
相反的情况是乱触发。你只想让 AI 简单列个大纲，结果它调用了“深度分析技能”，输出一堆你根本不要的东西。这种问题多半是 description 里写了太多高频通用词，比如“分析”“总结”“生成”。处理办法是把这些词从 description 中删掉，换成更具体的领域词，把技能限定在“当用户要求代码审查、构建测试、做数学建模”这类窄场景里。
5. 装多了就会打架：清理、冲突与社区整理思路
5.1 上下文膨胀与技能冲突，是怎么发生的
技能数量增加的第一个直接后果，是上下文膨胀。每个技能都有 description，每次新会话都要把全部技能索引过一遍。装二三十个技能之后，你会发现两件事：一是启动对话的 token 消耗明显上涨，二是 AI 开始混淆相似技能。比如你同时装了“代码审查”和“代码重构”两个技能，description 都提到“代码”，AI 很容易在你想重构时调用审查技能，输出完全跑偏。
我的做法是定期给技能做“体检”。打开技能目录，看每个 SKILL.md 的 description 是否互有重叠；记录过去一段时间实际触发过哪些技能，把长期没触发过的移出全局目录。担心“删了以后还要用怎么办”？简单，在全局目录旁边建一个skills-disabled目录，把不常用技能放进去，需要时再移回来。
5.2 审计—分类—隔离：社区里那套清理方法论
说到清理，社区里有个比较有代表性的思路，被整理得最系统的要属 Tibo 那套“清理 skills 的方法推荐”：审计—分类—隔离三步走。
审计的意思是先把所有已安装技能列出来，逐个回答三个问题：这个技能解决什么问题？最近一个月是否被调用过？它是否与其它技能存在描述重叠？分类则是把技能按“核心通用”“项目专属”“实验探索”三个等级打标签。隔离就更直接：项目专属的挪到项目级目录，实验探索的先禁用，只保留核心通用技能在全局目录。这套流程听起来简单，但真能解决大多数“技能打架”的问题。
我自己每隔两周会花半小时做一次清理。清理时会顺手检查技能仓库有没有更新，因为不少热门技能迭代速度很快，旧版本里的某个步骤可能已经被社区发现会导致误触发。更新方式也不复杂：重新拉取仓库最新代码，对比本地 SKILL.md 的差异，手动合入变更。
5.3 从哪些地方找靠谱技能，怎么判断质量
很多人在搜“skills推荐”“常用skills”时，会看到一张又一张清单。我的建议是认准几个靠谱来源：一是 GitHub 上人气较高的集合仓库，比如各类 awesome 开头的前端开发 skills 清单；二是以 Matt Pocock 为代表的作者型仓库，这类仓库通常有明确的使用文档和示例，适合拿来入门；三是社区论坛和博客里带实操复盘的推荐文章，比如有人写“华为杯建模比赛好用的 codex skills”或“ai漫剧常用skills”，这类文章会告诉你具体在什么场景下怎么用，比单纯列名字有用得多。
看到别人推荐的技能，不要“全家桶”式安装。逐个看 SKILL.md：结构是否清晰、description 是否具体、是否包含可执行的输出模板，三个方面都过关，再装进环境。判断一个技能库网站的质量，也可以参考同样的标准：不是仓库 star 数越高越好，而是技能文件本身的工程化程度决定长期体验。
6. 把同一套方法复制到数学建模、AI 漫剧和其它领域
6.1 技能不挑行业，只依赖流程化
聊完编程场景，我想把眼光抬高一点。这套方法论真正动人的地方，不在于写了多少前端技能，而在于它把“隐形知识”变成了“显性流程”。任何领域，只要能讲清楚“遇到什么情况、按什么步骤、产出什么格式”，就可以写成技能。
数学建模赛前准备就是一个典型场景。你完全可以自己写一个“数学建模辅助技能”：description 写成“当用户提出数学建模题目、要求进行问题分析、模型假设、建立求解或撰写建模论文时使用”。正文里定义一个工作流：先复述问题并列出已知条件，再明确假设边界，接着选择合适的模型类型，求解后做误差分析，最后按赛题要求的章节结构输出。甚至可以规定 AI 必须先给出“建模思路”草案，用户确认后再深入计算，避免它一上来就闷头算一个跑偏的模型。
6.2 AI 漫剧和内容生产场景的 Skills 示例
我也见过有人用类似思路做 AI 漫剧。一个“漫剧分镜技能”可以把“角色一致性、场景描述、镜头语言、旁白节奏”全部写成固定流程：AI 每次生成脚本前先读取角色卡，然后按分镜编号输出画面描述和台词，切换镜头时标注景别和时长。
这种做法本质上是把“资深漫剧编剧的工作习惯”实例化了。内容生产团队把技能文件放进项目目录，团队里的任何人——哪怕完全没经验的新手——都能得到同样稳定的产出质量，而不是依赖某个人反复调整提示词。对想规模化产能的团队来说，这比“手工调 prompt”可靠得多。
6.3 第一次写技能，建议从改模板开始
如果你从没写过自己的 Skills，我的建议是先从改模板开始，别从零写。找一份结构完整的 SKILL.md，比如你喜欢的代码审查技能，把正文中的领域知识替换成你自己的流程。不要一上来就追求“完美技能”，先跑通一次触发、一次执行、一次产出的完整闭环，再慢慢迭代 description 和输出模板。
我自己写第一个技能，就是拿别人的模板改出来的，改了三四轮之后才真正理解“description 决定触发、正文决定质量”这句话。也不要怕写出来的技能太简陋，先给一个真实项目用起来，实际跑两周，你自然知道哪些描述会让 AI 跑偏，哪些流程细节缺失会导致上下文不够用。
7. 写在最后的一点个人体会
把 Matt Pocock 这套 Skills 的理念消化完之后，我对 AI 编程工具的看法变了不少。以前总觉得“提示词写得好”就是一切，现在更确信“工作流沉淀得好”才是长期优势。模型能力会越来越强，但如果不把流程固化成技能，每次让 AI 干活都得重新解释一次“按什么流程做、做到什么标准”，效率折损非常明显。
你不一定非要装一整套 Superpowers，完全可以只挑一个技能先装上，比如代码评审或者 TDD，跑一周看看自己和 AI 的配合是不是更顺畅了。手动安装过一次之后，那些配置目录在你眼里就不再神秘，它们本质上就是一个个写着标准作业程序的文件夹，把合适的工作流放到合适的位置，AI 自然会变成你期待的那个“老员工”。
