★ FEATURED ARTICLE 如果你经常用 Claude Code、Codex 或 Cursor 这类 AI 编程工具肯定已经发现一个尴尬模型很聪明但每次让它做事都要把项目背景、代码规范、输出格式重新啰嗦一遍。Skills 就是为解决这个问题出现的。Matt Pocock 这个名字搞 TypeScript 的人应该都不陌生他做 Total TypeScript 多年最近一直在折腾 AI 编程工作流他维护和推荐的 skills 集合被不少人直接当成“前端开发技能包”来用。这篇文章就围绕 Matt Pocock Skills从安装、使用到自定义开发把我在实际项目里踩过的坑和验证过的方法一次讲清楚。1. Skills 是什么以及 Matt Pocock 为什么盯上它1.1 从提示词到技能包的一次进化先说个生活化类比。以前用 AI 写代码好比你每次找一位新实习生都得从头教一遍“我们项目用 React 18、TypeScript 严格模式、组件要写测试、提交前跑 lint”。虽然他能听懂但每次换任务、换会话这些上下文就丢了输出质量全看当天模型心情。Skills 则像你给这位实习生发了一份《岗位说明书》加一套《工作模板》他上岗前自己读一遍之后每次干活都按这套标准来。具体到技术层面一个 skill 就是目录里的一个文件夹里面至少有一个SKILL.md文件用来描述这个技能的触发场景、执行步骤、输入输出格式还可以附上参考文档、代码模板、脚本。当你在对话里提到相关任务时支持 skills 的 AI 工具会自动把这个文件内容作为上下文注入相当于提前把“经验”喂给模型。Matt Pocock 之所以在 skills 上花这么多精力是因为他常年教 TypeScript太清楚模型在类型推断、泛型约束、组件泛型这些场景里有多容易翻车。他自己在项目里沉淀了一批针对 TS/React 工作流的技能包比如类型报错排查、组件生成、代码评审。他的核心观点是不要让 AI 每次“临场发挥”而是把团队的最佳实践变成可复用的技能文件让模型稳定地输出 80 分以上的结果。1.2 这套方式适合谁能解决哪些实际问题如果你属于下面几类人这篇文章对你会很实用正在用 Claude Code、Codex、Cursor 写业务代码的前端/全栈开发者觉得 AI 输出水平忽高忽低。团队里想统一 AI 编码规范但又不想把一堆 prompt 复制来复制去的技术负责人。想自己动手写 skills但不知道文件夹结构、格式怎么写的人。我实际用下来skills 解决的主要问题有三个。第一是类型问题让 AI 修 TypeScript 报错它经常会在同一个错误上绕圈加了 skill 之后它会按“先看 tsconfig再找最小复现再给修复方案”的顺序来效率和准确率明显提升。第二是生成代码一致性同一个组件需求不同会话生成结果可能完全不同有 skill 约束后文件命名、样式方案、测试覆盖都稳定很多。第三是评审质量默认情况下让 AI 做 code review它容易只夸不批或者只会说“代码很清晰”技能里如果写了“必须列出至少三个问题并给出修改建议”效果立刻不一样。2. 安装前的基础知识不同工具怎么读 skills2.1 各主流 AI 编程工具的 skills 目录机制不管是从 GitHub 上下载别人的技能包还是自己创建第一步都得搞清楚你用的工具从哪里读 skills。这步搞错后面全白搭。我整理了一个表格覆盖最常见的几个工具工具默认 skills 目录项目级配置备注Claude Code~/.claude/skills/项目下.claude/skills/读取规则比较直接目录下有SKILL.md就会被识别Codex~/.codex/skills/项目下.codex/skills/部分版本需要配置allowedSkills或通过配置文件指定路径Cursor项目下.cursor/skills/同左Cursor 更偏向工作区级也可以显式引用某个 skill要注意的是这些工具的 skills 支持还在快速迭代不同版本行为可能不一样。安装后最好用一个测试任务确认技能有没有被激活别等到正式写代码时才发现路径错了。2.2 手动安装 GitHub 上 skills 的三步法热词里有人问“claude code 怎么手动装 github 上的 skills”这里给出我每次用的标准流程下文以把matts-pocock-ts-skills一个虚构但结构典型的前端技能库装到 Claude Code 为例。# 1. clone 到临时目录 git clone https://github.com/example/matts-pocock-ts-skills.git /tmp/matts-skills # 2. 查看目录结构确认 SKILL.md 的位置 ls -la /tmp/matts-skills # 通常你会看到类似 my-ts-fix/、my-react-gen/ 这样的子目录 # 3. 把需要的技能目录复制到 Claude Code 的全局 skills 目录 mkdir -p ~/.claude/skills cp -r /tmp/matts-skills/* ~/.claude/skills/装完之后重启你的 Claude Code 会话然后直接在对话里说“帮我修复这个文件的类型错误”如果它开始按技能里的步骤走就说明生效了。如果没生效优先检查每个技能目录下是否真有SKILL.md文件名大小写是否一致以及目录是否嵌套过深。3. Matt Pocock 风格的核心 Skills 实操拆解3.1 TypeScript 类型排查类技能这是 Matt Pocock 最擅长的方向也是我最推荐新手第一个抄作业的 skill。它的目的很简单当 AI 被要求修复 TypeScript 报错时不再盲目改代码而是先做系统地诊断。下面是我参考他的思路写的一个最小可用示范目录结构如下ts-error-fixer/ ├── SKILL.md └── references/ └── ts-error-checklist.mdSKILL.md内容可以这样写--- name: ts-error-fixer description: 当用户要求修复 TypeScript 类型错误时使用此技能。 --- # TypeScript 错误修复流程 1. 读取项目根目录的 tsconfig.json确认 compilerOptions。 2. 找到用户指定的文件完整读取后定位所有红波浪线。 3. 对每个报错先尝试从“类型本身”找原因而不是急着修改。 4. 生成最小复现片段验证修复方案。 5. 如果涉及泛型检查是否缺少约束是否推导为 unknown。 6. 输出修复后的代码并补充一行解释。 ## 禁止项 - 不要一次性改多个无关点。 - 不要使用 any 来绕过问题除非用户明确允许。这个 skill 之所以有效是因为它把“先理解再动手”的原则写死了。很多 AI 修类型错误时看到报错就尝试改类型声明很容易引发连锁反应。加了流程约束后它会先读tsconfig.json这看起来是个小动作但能避免它忽略strict: true带来的差异。配套的references/ts-error-checklist.md可以放入更细的清单比如常见报错代码对应原因。这样主文件保持精炼细节放在引用文件里模型会根据需要读。3.2 前端组件生成类技能另一个高频场景是生成 React 组件。没有 skill 时AI 生成的组件虽然能跑但经常出现文件组织混乱、样式方案不统一、忘记导出类型、组件的 props 设计没有语义化这类问题。我建议的技能文件里至少包含这些固定要求--- name: react-component-gen description: 生成新的 React 组件时使用。 --- # React 组件生成规范 - 使用 TypeScriptprops 定义在组件文件顶部。 - 组件文件采用 PascalCase 命名。 - 导出组件本身和 Props 类型。 - 默认使用 CSS Modules样式文件放在同目录下。 - 同时生成一个测试文件至少覆盖默认 props 和主要交互。 - 组件需要支持 className 透传。每次生成新组件时只要对话中提到“帮我写一个按钮组件”AI 就会按照这套规范输出完整目录。你可能觉得这不过是把 prompt 写长一点但区别在于普通 prompt 只对当前会话有效而 skill 可以长期沉淀、团队共享。这里有个实操细节description字段的触发词很重要。不要写太长太泛否则所有对话都可能激活这个技能白白消耗上下文。最好写成“当用户要求生成新的 React 组件时使用”让触发更精准。3.3 代码评审与重构类技能让 AI 做 code review 是很多人忽略的场景。默认情况下你贴一段代码让它 review它大概率会说“代码整体不错”“逻辑清晰”偶尔提两个小建议。这类回复对实际开发没有价值。整改后的 skill 可以这样定义--- name: code-reviewer description: 用户要求 review 代码或提出改进建议时使用。 --- # 代码评审清单 1. 功能正确性是否存在边界条件遗漏 2. 类型安全是否合理使用类型有没有隐性 any。 3. 性能隐患是否存在不必要的重复计算。 4. 可维护性函数是否过长命名单词是否表意明确。 5. 可测试性依赖是否容易 mock。 6. 输出格式必须列出足够具体的问题给出修改建议按严重程度排序。加了这种技能之后review 结果会从“挺好的”变成“这里 map 和 filter 连着用导致遍历了两次这里依赖数组少了一个字段这个函数超过 60 行了建议拆成三个小函数”。这种差别谁用谁知道。4. 自定义 Skills把团队规范固化下来4.1 最小可用的目录结构如果你不满足于装别人做好的技能想自己写一个我先给你一套不会出错的最小模板。先不要追求复杂的嵌套引用和脚本先把结构跑通。my-custom-skill/ ├── SKILL.md └── scripts/ └── run-check.tsSKILL.md是整个技能的核心必须包含 frontmatter开头---包裹的元信息和正文。正文就是你对 AI 的完整指令。scripts/目录可以放一些辅助脚本比如格式化、校验、代码生成器。不是必须但需要时能派上大用场。我自己常用的结构是SKILL.md外加一个references/目录放详细的规则文档。原因很简单模型上下文窗口再大也有限全部塞进SKILL.md会让它在无关任务时也背上额外负担。主文件只放步骤和关键要求细节放到引用文件里按需读取。下面是一个针对“中文论文翻译成英文”场景的 skill 简要示例正好也是热词里有人问的方向--- name: paper-translator description: 将中文论文翻译为英文时使用。 --- # 论文翻译任务 1. 先保留原始 markdown 结构不要改变标题层级。 2. 术语表优先使用给定文件 references/terms.csv。 3. 翻译风格采用学术英语不使用口语化表达。 4. 数学公式保持不变只翻译文字部分。 5. 输出时同时生成中英对照表。4.2 编写技能时的三个关键细节细节决定成败。我自己写了十几个 skill 之后发现有三点特别容易踩坑。第一任务拆解要足够具体。像“修复这个 bug”这种要求本身就不合格。你要告诉 AI 技能的目标、步骤、输出格式而不是让它自己发挥。步骤最好控制在 5 到 8 步太多会让模型在长上下文中迷失。第二给正反例。在技能里写“推荐做法”和“避免做法”比单纯描述规则有效得多。尤其是代码类技能给一段错误示例和对应修改模型能直观理解边界在哪里。第三控制上下文的粒度。不要把几十条规则全塞进SKILL.md。我见过有人把整个团队的 ESLint 规则贴进去结果模型真正需要的信息被淹没。更好的做法是只写“遵循 references/eslint-summary.md 中的关键规则”让模型按需读取而不是一次性吃进一大堆内容。5. 实战中的常见问题与调试技巧5.1 技能没生效先从这五个方向排查我在群里见过最多的问题就是“为什么我装了 skill 但它没用”。下面按优先级列出排查步骤路径错了。确认你放的是~/.claude/skills/而不是~/.claude/skill/少个 s 都不行。目录结构不对。AI 工具识别的是SKILL.md不是随便一个index.md或README.md。文件名大小写。在 Linux 和容器里SKILL.md和skill.md是不同文件别依赖系统帮你忽略大小写。触发词太模糊或太冷门。如果description里写的是“处理复杂任务时使用”模型可能根本不会关联到它。重启了吗。大多数工具在会话启动时加载技能运行过程中新增文件不会热更新重启一下更保险。如果你还是不确定可以做一个最小实验新建一个技能目录SKILL.md里只写一行“当用户说 ping 时回答 pong”然后测试触发。这个办法能快速判断是工具问题还是内容问题。5.2 多个工具共用一套 skills 目录热词里提到“codebuddy 和 claude code 公用 skills 目录”这是一个很现实的需求。我现在的做法是把技能放在一个独立目录比如~/workspace/shared-skills/然后在各工具的默认目录里放符号链接指向它。ln -s ~/workspace/shared-skills/ts-fixer ~/.claude/skills/ts-fixer ln -s ~/workspace/shared-skills/ts-fixer ~/.codex/skills/ts-fixer这样做的好处是只维护一份文件改了立刻多个工具同时生效。坏处是各工具对SKILL.md的 frontmatter 字段兼容性略有不同比如某些字段在 Claude Code 里支持在 Codex 里可能被忽略。所以如果你要共用最好只用最通用的name和description字段避免写复杂的条件逻辑。5.3 效果不稳定学会给技能“做减法”很多新手会犯一个错误技能文件越写越长最后模型反而变笨了。我自己的经验是当某个技能触发后输出质量下降先别急着加规则而是试着删掉一半细节。为什么因为模型在长指令下会过度约束导致它不敢正常推理甚至生硬地按步骤走流程不考虑实际上下文。比如你在组件生成技能里规定了“所有行内样式都要用 CSS 变量”这个约束在简单组件里完全多余但模型会为了遵守规则写出一堆无意义的变量定义。我调试技能的方法是先简化到只剩最核心的三步跑通后再逐步加约束每次加一条就跑一次测试用例直到发现输出变差马上回退。这个方法听上去笨但确实能帮你找到技能文件的“容量上限”。6. 从 Matt Pocock 的实践中能学到的进阶玩法6.1 让技能覆盖建模、排版、文档处理等场景看热搜词时我发现大家已经不满足于用 skills 写代码了还会用来做数学建模、生成 AI 漫剧、处理 Word/PPT、做 LaTeX 排版。这些方向本质上都一样把任务拆解成稳定步骤再配上输入输出模板。以热词里的“华为杯建模比赛好用的 codex skills”为例你在做数学建模论文时最耗时间的往往不是建模本身而是论文排版、表格规范化、公式引用。把这些操作写进一个 skill让 AI 按固定格式输出 LaTeX 片段和图表描述效率会高很多。再比如“latex 排版 skills”核心思路就是规定清楚数学公式用equation还是align、图表标题用什么格式、交叉引用命令怎么统一。你甚至可以把自己的学校论文模板放进 references 目录让 AI 直接按模板生成。6.2 像维护开源项目一样维护自己的技能库Matt Pocock 身上最值得学的不是某个技能文件而是他对待技能库的方式版本管理、按场景分类、持续更新。我自己现在也把 skills 目录变成了一个 Git 仓库每个技能文件独立提交同时用README.md记录每个技能的用途和更新日期。这样做的好处有两个。第一换了新电脑或换新工具只需要git clone一下就能恢复全部技能配置。第二当你发现某个技能的描述和实际行为不一致时改起来有历史记录可以回滚。我还在仓库里加了一个archive/目录专门放那些“曾经有用但现在很少用”的技能。这样主目录不会越来越臃肿需要时还能捞回来参考。这个方法跟管理 npm 包依赖差不多核心原则就是“可追踪、可回滚、可分享”。6.3 把技能接入团队协作的一点建议如果你想让整个团队都用同一套 skills可以创建一个私有仓库作为技能源然后在文档里写清楚安装方式。这里有个容易被忽略的点不同开发者的项目路径、系统环境不一样安装命令里最好不要写死绝对路径优先用~和相对路径。另外团队里不要一次性引入十几个技能先从两三个最高频的开始比如类型修复、组件生成、代码评审。跑两周再根据反馈调整否则大家装了一堆技能触发规则互相干扰反而觉得这东西不好用。我在实际使用中最深的一个体会是Skill 本质上是你和 AI 之间的“共识文件”。它不是魔法不会让模型突然变聪明但它能把你的经验、团队的规范、项目的上下文沉淀下来让 AI 每次都在同一个高起点上工作。与其今天一句 prompt、明天一段规则不如花半小时把这些散落的知识收拢到一个目录里。这套思维才是 Matt Pocock 这些实践者真正想传递的东西。
阅读完成 · 觉得有帮助？
