如果一年前有人告诉我AI 编程助手能靠一套“技能包”变成 TypeScript 专项顾问我大概率会觉得这是营销话术。直到我把 Matt Pocock 的 Superpowers Skills 装进 Claude Code用真实项目跑了三个月才明白为什么前端圈最近都在聊 Skills。不是普通 prompt而是一整套可复用的工作协议——它对 AI 的行为约束力比想象中强得多。这篇文章就围绕 Matt Pocock 这套 Skills讲讲它到底是什么、怎么手动装进 Claude Code、实战怎么用以及如何动手写一个自己的 Skills。先说结论这套东西最适合两类人。一类是天天跟 TypeScript、React 打交道的业务前端想减少 AI 写出的“能跑但类型稀烂”的代码另一类是团队里负责制定编码规范的人想把沉淀出来的研发流程直接“喂”给 AI而不是一遍遍复制粘贴上下文。如果你是纯后端或者只写脚本可以看思路但直接照搬意义不大。1. 先搞懂Matt Pocock 的 Skills 到底是什么1.1 从 Claude Code 的 Skills 机制说起Claude Code 里说的 Skills简单理解就是一组有固定格式的 Markdown 指令文件。每个 Skill 包含两大部分头部是元信息写名字和描述正文是具体的操作步骤、约束规则和示例。当你在对话里提出某个需求时Claude Code 会根据描述自动判断该调用哪个 Skill然后把 Skill 里的内容当成临时附加的系统指令来执行。用生活化类比就是你雇了一个助手平时你说什么他做什么但效果不稳定。现在你把“怎么泡茶”的标准流程写成一张卡片挂在墙上助手看到“泡茶”两个字就会主动按卡片上的流程走先烧水再洗杯温度多少闷几分钟。Skills 就是那张卡片Claude Code 是那个会看卡片的助手。这个机制最大的好处是复用。你今天总结出来的最佳实践明天、后天、下个项目都能用。而且 Skills 可以放在项目目录下跟着仓库走新同事 Clone 代码后AI 助手自动就具备团队规约。1.2 Superpowers 这套 Skills 有什么不一样Matt Pocock 是 TypeScript 教育的知名人物做过 Total TypeScript 课程自己也长期在开源项目里折腾类型系统。他做的这套 Superpowers Skills并不是教你写一行行提示词而是把一套完整的软件工程流程塞给了 Claude Code。我最开始用的时候只当它是普通的技能包后来看了里面的内容才反应过来真正值钱的是那几条“死规矩”。比如要求 AI 在任何修改前先写失败测试比如重构时必须“小步前进”每改完一个方法就停下来跑测试比如处理 Git 操作时不能直接git push而是要先查看状态、审查 diff、再提交。这些规则写的不是“你应该做什么”而是“你必须做什么”语气完全是工程规范而不是建议。这正是很多 AI 编码项目翻车的根源模型能力很强但没有纪律。让它自由发挥它能三分钟写出几百行代码可惜一半是过度设计。Superpowers 这套东西相当于给模型套上了一条“安全带”强制它按人类工程师的节奏工作。2. 手动安装从 GitHub 把 Skills 装进本地环境2.1 安装前要准备的工具和目录手动安装前先确认三个基础件Git、Node.js、Claude Code CLI。Git 用来拉取仓库Node.js 是 Claude Code 的运行环境CLI 本身就不多说了。注意版本别太旧Node 建议 18 以上Claude Code 保持在最新版否则解析新格式的 Metadata 可能出问题。然后要决定装在哪里。Claude Code 支持两种 Skills 位置用户级放在~/.claude/skills下面所有项目都能用适合放通用技能。项目级放在当前项目的.claude/skills下面只对这个仓库生效适合放团队专属规范。Matt Pocock 的 Superpowers 属于通用技能我建议放在用户级。好处是以后开任何一个新项目这些技能都能自动被加载不用每个仓库都复制一遍。如果你只想在某个具体项目里试水那放项目级更稳妥不会污染其他工作目录。2.2 克隆与放置的具体步骤手动安装的流程不复杂但有几个坑。我踩过最深的一个是把整个仓库目录直接当成了 Skills 目录——结果 Claude Code 扫描不到任何技能因为技能实际是在仓库里某个子文件夹中。正确做法是这样先把仓库克隆到一个临时目录。例如git clone https://github.com/mattpocock/superpowers.git注意这里只是示例实际地址要以你找到的仓库为准。进入仓库后找到真正存放 Skills 的目录。不同仓库结构不同可能是skills、superpowers或pull目录。用ls查看看到一堆带名字的子文件夹每个文件夹里都有SKILL.md那这里就对了。把整个 Skills 目录复制到目标位置。如果是用户级就执行cp -r ./对应目录 ~/.claude/skills/。如果目标位置还不存在先mkdir -p ~/.claude/skills。复制完检查一下目录树确保是~/.claude/skills/xxx/SKILL.md的层级。如果直接变成~/.claude/skills/skills/xxx/SKILL.mdClaude Code 可能认不出来路径层级很敏感。注意不要只拷贝单文件。有些技能会引用同目录下的辅助文件或模板只拿一个SKILL.md骑出去会导致技能运行到一半报错。2.3 验证 Skills 是否被识别装好之后别急着干活先验证。最直接的办法是重新启动 Claude Code让它的加载器重新扫描目录。启动后你可以输入一句类似“列出当前可用的 Skills”的指令注意不是斜杠命令而是自然语言询问。如果安装成功它会把技能名和对应描述列出来。我遇到过一种尴尬情况技能列表里明明有但让它执行时它还是按平时套路来。这时候检查一下当前项目目录是不是有另一个.claude/skills目录项目级技能会覆盖用户级同名技能。还有可能是描述写得太模糊AI 没判断出来该调用。这个需要检查每个SKILL.md的 description看是否覆盖了你想要触发的场景。3. 核心技能拆解我常用的几个 Skill 与适用场景3.1 测试先行TDDSkill 怎么用Matt Pocock 的 TDD Skill 是我最常用的一个。过去我让 AI 写功能它经常先写实现再补测试甚至不写测试。装上这个 Skill 后只要一句“用 TDD 方式给某个函数补全逻辑”Claude Code 就会按固定流程走先写一个失败的测试用例跑一次确认失败接着写最小实现让测试通过最后回头审视代码尝试重构。如果你自己没要求它写测试但只要任务涉及代码修改一些 Skill 会主动要求先列测试计划。具体效果举个例子。我之前写过一个计算价格折扣的函数考虑到会员等级和促销活动逻辑分支很多。让 Claude Code 直接用 TDD 流程改它第一步没写任何业务代码而是先列出四个测试场景普通会员、金卡会员、叠加活动、活动过期。确认这几个场景覆盖完整后再开始写实现。整个过程每轮修改都跑测试明显比直接让它“给个函数”稳得多。这个 Skill 的边界也很清晰它只适用于函数级、逻辑型的改动。如果让 AI 改 UI 样式用 TDD 就有点反应过度毕竟视觉验证不靠单测。3.2 类型安全重构 Skill 的实操要点前端项目到了一定阶段类型重构就像拆炸弹。改一个接口类型组件传参跟着报错连带把 store 也带崩。Matt Pocock 那套重构 Skill 特别强调“小步重构”和“保持行为不变”这两条我太认可了。实际操作时我会让 AI 先扫描项目的类型配置定位tsconfig.json的strict开关和当前类型错误数量。然后每次只处理一个模块改完立刻跑类型检查tsc --noEmit。如果错误超过预期立刻回滚重新解读类型之间的关系。有人觉得这样太慢但重构追求的是安全不是速度。我曾经让 AI 一次性改了十几个文件的类型结果出现大量any和类型断言表面错误清零实际类型覆盖形同虚设。后来切到这个小步重构 Skill每次改动控制在两三个文件内最终错误数从八十多个降到个位数过程中心态也稳。3.3 Git 操作与代码审查 Skill 的用法Superpowers 里的 Git 相关技能刚开始我觉得有点 “管太宽”用久了才发现它防住了好多手滑操作。简单说它要求 Claude Code 在提交前必须先看git status和git diff确认改动内容生成符合规范的提交信息然后经过你确认才执行提交。有一回我让它处理一份需要拆分的改动结果它把几个不相关的文件卷进了同一个提交。虽说现在有git reset能救但万一已经 push 到远端就要和同事解释半天。用这套技能后它会在提交信息里写出每个文件的改动原因并提醒我检查是否有多余文件。这种“确认确认再确认”的工作流非常适合几个项目同时进行的场景。代码审查相关的技能也很有用。丢给它一个 diff它能按类型安全、边界条件、可读性几个维度输出审查意见而且每条意见都会指向具体行号。比直接让 AI“帮我 review 代码”要规范得多。4. 自己动手写一个 Skills从零到上手4.1 Skills 文件的标准结构官方没有把规则定死但 Matt Pocock 这套是很好的模板。一个标准技能目录结构长这样.claude/ skills/ my-skill/ SKILL.md example.ts核心文件是SKILL.md开头用 YAML frontmatter 声明元信息。最简单版--- name: my-skill description: 当用户需要处理 XXX 场景时使用。包括 A、B、C 关键词…… --- # 技能正文 步骤、规则、示例……name必须唯一description是灵魂。Claude Code 判断什么时候调用技能主要靠 description 和当前任务的语义匹配。很多自写技能不生效根本不是格式问题而是 description 写得太泛。4.2 编写描述和指令的技巧关于 description我建议写成“触发条件 使用场景 排除条件”三段式。例如description: 当用户需要对 React 组件进行性能优化时使用尤其是避免不必要的重渲染。如果只是修改样式或文案不要使用本技能。把“什么时候不用”也写进去能显著减少误触发。我最早写的技能 description 只有一句“用于性能优化”结果每次提性能两个字都得触发一遍后来加上排除条件才算消停。正文部分则要避免概念化。不要光写“确保代码质量高”要写可操作步骤。比如列出当前组件的 props、state、context 来源。找出每次渲染都会变化的对象和函数。判断是否需要用React.memo或useMemo不要盲目使用。修改后运行npm run lint与npm run type-check。定义验收标准也很有用。告诉模型“当以下条件全部满足时任务才视为完成”。这样比让它自由发挥强得多。4.3 让 Agent 真正“理解”你的 Skill示例项目假设我想写一个“生成表单校验规则”的 Skill。描述可以写成description: 根据表单字段定义生成 zod 校验规则或为已有规则增加字段校验。仅适用于前端 TypeScript 项目。正文里给出输入格式和输出格式附带一个简单的示例。示例不能太长但要完整。下面是个迷你示范## 输入示例 字段email类型string必填是格式邮箱 ## 输出示例 z.object({ email: z.string().email(邮箱格式不正确), })然后写几条硬性规则所有错误消息必须使用中文。必须导出最终的 schema命名规范是表单名称 Schema。如果字段没有额外约束不要生成多余的校验链。这样写完你可以用一个小测试工程验证故意描述一个模糊需求看模型是否调用了这个技能。多试几次后调整描述措辞直到触发稳定。5. 实战记录用 Claude Code 完成一个前端类型错误修复5.1 需求描述我在维护一个 React TypeScript 的中型项目最近要增加一个“优惠券叠加使用”的功能。老代码里order对象的结构比较复杂类型定义还是几年前的里面一堆any。新需求要读取order.coupons但在部分订单里这个字段是undefined导致页面渲染时直接报 “Cannot read properties of undefined”。需求本身不复杂但这只动了老类型很容易改一个地方炸一片。我打算用 Claude Code 配合 Matt Pocock 的类型重构技能来处理。5.2 配合 Skills 的执行过程启动 Claude Code 后我先输入“请用类型安全重构技能修复order.coupons可能为 undefined 的问题不要改变现有业务逻辑。”AI 没有直接改代码而是先给我输出一份分析日志包括order类型的定义文件位置。coupons字段在多少个组件里被使用。当前是否有测试覆盖。建议先把coupons定义为可选数组再逐个访问点增加判空。我非常意外的是它接下来没有一上来就写代码而是问我要不要先创建几个测试用例来锁定现有行为。这就是技能里的规则起了作用——步骤顺序被写死了AI 想跳过都不行。确认后它先创建了两个测试一个订单没有coupons字段一个订单有多个优惠券且数量超过零。然后才开始修改类型定义。每次改完文件都会跑tsc --noEmit和相关的单测再进入下一个模块。5.3 踩坑与结果复盘中途出了一个插曲有个组件原本直接访问order.coupons.length类型改成可选后这里报错。AI 本能地想把order.coupons改成order.coupons || []我看了下不对因为那个组件要判断“用户是否使用了优惠券”不是真的需要默认空数组。于是我在对话里纠正了一下AI 马上调整方案改成先if (!order.coupons) return null再渲染。这个小插曲说明技能不是万能的。它能规定流程但业务语义还是要人来把关。最终改动涉及 6 个文件类型错误从 23 个降到 0单测从 47 个增到 59 个全部通过。整体耗时大约四十分钟比我手工改快也比我不加限制地让 AI 乱改安全得多。6. 常见问题与排查技巧实录6.1 Skills 不生效查这五个地方第一个检查SKILL.md文件是否存在于正确的目录层级路径里不能多套一层文件夹。第二个检查description是否简练明确过于模糊的技能很难被触发。第三个检查是不是存在同名覆盖项目级技能优先于用户级。第四个检查当前会话是不是旧的很多情况下重启 Claude Code 就会重新扫描技能。第五个检查有没有开启权限限制如果你限制了 AI 读取文件系统技能里的辅助文件自然读不到。我过去遇到技能不生效八成都是路径多套了一层或者把整个 README 仓库复制进去了。建议装完就用find ~/.claude/skills -name SKILL.md看一下能列出多少技能文件一目了然。6.2 多个 Skills 冲突怎么办问题往往是这样的装了 Matt Pocock 的通用测试技能又装了团队内部的测试规范技能两边指令有冲突。比如通用技能要求先写测试团队规范要求先评审测试计划。AI 有时会两个都参考结果行为不可预测。解决方法是合并或删减。我自己的原则是团队规范技能优先级更高就把 Matt 那套里涉及测试流程的部分抽出来跟团队规范合并成一个新技能删掉原技能。不要幻想 AI 能完美权衡你替它权衡最省心。6.3 实用资源配置建议不同的 Skills 对上下文长度和权限的设置敏感度不同。TDD 类的技能会在循环里跑测试消耗的 response 次数比较多如果没有开启自动批准工具调用你需要不停手动确认。建议在安全项目里把claude:allow-tools配置得宽松一点比如允许执行npm test、tsc --noEmit否则体验极其割裂。另外技能文件不要贪多。我见过有人一次装二十多个技能AI 每轮都要在大堆描述里做匹配很容易选错。最佳实践是个人目录只放最常用的五六个项目目录放团队专属的两三个保持精简。7. 个人体会Skills 的边界在哪里我自己实际用了大半年下来最大的体会就是不要把 Skills 当成魔法棒。它的本质是“将优秀工作流固化给模型”但前提是你已经知道什么流程是优秀的。Matt Pocock 这套 Superpowers 之所以好用是因为他先花了很多年研究 TypeScript 和测试实践然后把那些被验证过的经验变成规则。我们抄规则容易抄背后的判断力很难。另外一个小技巧写自定义技能时不要追求覆盖所有场景。本来想一个技能搞定“代码生成 测试 重构 提交”结果每个环节都做得浅。拆开成单个技能反而更灵活AI 可以按需组合调用。如果你刚开始尝试建议先只装一个 TDD 技能找一个不紧急的函数改一改体验一下被节奏约束的感觉。那个过程会有点不适应——AI 突然不炫技了但每一步都走得很稳。等你熟悉了这种工作方式再慢慢扩展其他技能。这条路走通之后你会发现团队多年沉淀的研发规范终于有了一个可以随身携带的载体。