说起 Matt Pocock，前端圈的朋友应该不陌生，TypeScript 布道者、Total TypeScript 作者，常年跟类型体操和类型安全打交道。但今天我想聊的不是他的类型课，而是 Matt Pocock 在 AI 编程时代带火的一整套 Skills 使用与实践方法。Skills 这个词在 2025 年几乎被 Claude Code、Codex 这些 AI 编码工具喊成了标配：它不再是一条临时粘贴的提示词，而是变成项目里可复用、可版本管理、可分享的“技能包”。这篇文章适合正在用 AI 辅助写代码、又觉得 AI 总是“不够听话”的人，也适合想搞懂 skills 到底怎么装、怎么写、怎么清理的同学。
我大概花了两周时间，把社区里常见的 skills 仓库翻了一遍，在真实项目里反复试装、试写、试删。说实话，这东西本身不复杂，但网上教程特别散，大多只讲“怎么装”不讲“为什么这么设计”，更没人讲踩坑。所以我决定把整套实践整理出来，从一个前端开发者的视角，讲讲 Matt Pocock 和 TypeScript 社区这套 skills 玩法背后值得吸收的东西。
1. 为什么我会盯上 Matt Pocock 的 Skills 体系
1.1 从 TypeScript 布道者到 AI 技能包
Matt Pocock 在社区里的身份很明确：他把复杂 TypeScript 概念讲得通俗，又有非常强的工程化思维。这两年在 AI 辅助编程兴起之后，他很快把注意力转向了一个很实际的问题——怎么让 AI 在写代码、审代码的时候稳定复现“专家级操作”。
答案是 Skills，或者说 Agent Skills。简单理解，它是一个给 AI 助手用的“岗位说明书 + 工具清单 + 完成标准”三合一套件：一个目录，里面有 SKILL.md 文件，定义技能名、技能描述、使用场景、操作步骤、输入输出格式、注意事项。AI 工具会在合适的任务里读取这份文件，按里面的流程执行。
我看到 Matt Pocock 长期在推 Typesafe AI 这类方向，GitHub 上也有挺多以 typesafe ai skills 命名的仓库。本质上，他主张的开发方式是：把一对一的临时对话，变成一套可沉淀、可复用的工程资产。我第一次看到这个理念时觉得有点夸张，但真在自己项目里跑通后，才发现这个思路确实比堆提示词靠谱得多。
1.2 Skills 和普通提示词到底差在哪
很多人一开始会把 Skills 理解成“高级 prompt”，这个理解不准确，但也不能说完全错。一条普通的提示词，比如“帮我审查这个文件的 TypeScript 类型”，它的生命周期只存在于这次对话里。下一次你再问同样的问题，AI 完全可能给你换一套标准，甚至忘记上次约定的规范。
Skills 不一样。它是放在项目目录里的物理文件，每次 AI 启动、读到相关任务时，都能稳定地看到这份规则。这就好比外卖订单和餐厅后厨标准化菜谱的区别：提示词是“今天给我来一份少盐的宫保鸡丁”，skills 是后厨墙上贴着的“宫保鸡丁标准做法，所有厨师照此执行”，哪怕换了个 AI 模型，只要还在这个项目里，它读到的还是同一套做法。
对我来说，这个区别带来的直接好处是：团队协作时，不需要每个人把规则记在脑子里，也不需要每次对话都把长达数页的规范复制粘贴一遍。谁改动了 skill 文件，Git 记录里写得清清楚楚，规则演进变得可追溯。这一点，正是 Matt Pocock 这类工程派最看重的价值。
2. 动手装一个：从 GitHub 到 Claude Code / Codex 的全流程
2.1 装之前先搞清楚两件事：目录约定和触发方式
网上搜“claude code 怎么手动装 github 上的 skills”，出来的答案五花八门，原因是各家 AI 工具的约定并不完全一致，但大方向是通用的。以我用的 Claude Code 为例，它约定项目级技能放在.claude/skills/<技能名>/SKILL.md。也有用户级目录，一般放在家目录下的.claude/skills，区别是项目级只对当前项目生效，用户级对所有项目生效。
Codex 的目录结构大同小异，opencode 也支持类似约定。所以你先别急着复制命令，先确认一下自己主力工具的项目内技能目录叫什么，这个信息在官方文档里都有。我在实践里发现一个特别容易踩的坑：把 SKILL.md 直接扔在.claude/skills/根目录下，而不是放在skills/<技能名>/SKILL.md这种两级目录里。少了这层目录，很多工具直接识别不了。
触发方式也需要提前理解。不同工具不太一样，有的是在对话里用@技能名手动引用，有的是靠 SKILL.md 里的 description 字段做语义自动匹配，还有的会默认把所有技能都塞进上下文。搞清楚你用的工具属于哪一种，后面配置思路完全不同。如果工具支持自动匹配，description 字段就是你的“触发器”；如果不支持，那你可能就得手动管理加载顺序。
2.2 手动安装技能包的标准手顺
以“从 GitHub 手动下载一个技能包，装进当前项目”为例，我整理了一套不会出错的步骤。这里用占位符代替具体仓库地址，避免版本更新后误导你。
# 第一步：把技能库仓库克隆到临时目录 git clone https://github.com/你的账号/技能库仓库.git temp-skills # 第二步：在当前项目里创建技能目录（以 Claude Code 为例） mkdir -p .claude/skills # 第三步：把仓库里你需要的某个技能子目录复制进来 cp -r temp-skills/skills/你想要的技能名 .claude/skills/ # 第四步：检查最终目录结构是否正确 tree .claude/skills/你想要的技能名装完之后，一定要打开SKILL.md看一眼头部。大部分规范里面都有 YAML frontmatter，至少要包含 name 和 description。name 是技能的唯一标识，description 是给 AI 判断“什么时候用这个技能”用的。有些技能包还写了 allowed-tools，意思是只允许 AI 调用某些外部工具，这类配置你最好保留，不要手贱删掉，否则可能会导致 AI 乱调工具。
2.3 装完别急着用，先跑一次“冒烟测试”
我见过太多人装完技能包就以为万事大吉，结果真用起来发现完全没生效。我的习惯是装完之后马上做一个冒烟测试，任务越小越好。
比如我装了一个 TypeScript 类型审查相关的技能，就会在项目里随便挑一个类型文件，对 AI 说：“用刚才的 typescript-audit 技能审查这个文件的类型安全。”然后观察它有没有按 SKILL.md 里写的步骤走，比如先读取配置文件、再逐个类型检查、最后按固定格式输出问题清单。如果它只是一句“看起来没问题”，没有走技能里的流程，那多半是技能没加载成功，或者描述没匹配上。
冒烟测试过了，安装才算真正完成。这一步花不了两分钟，但能省下你后面整套工作流里最大的排查时间。
3. 值得装进“军火库”的几类 Skills 推荐
3.1 前端与 TypeScript 开发向：从类型审查到组件生成
Matt Pocock 那条线最值得关注的，自然是前端和 TypeScript 相关的技能包。我在 GitHub 上搜到过不少以 typesafe ai skills 命名的仓库，里面通常会把技能按场景拆分：
- 类型审查技能：专门检查类型定义、泛型使用、边界条件，适合 Code Review 场景。它能稳定输出“哪里类型太宽、哪里类型太窄、哪里可以用模板字面量类型收窄”。
- API 客户端生成技能：给一份后端接口文档，AI 按技能里定义的规范生成带完整类型定义的 fetch 封装。
- React 组件生成技能：规定组件文件、样式文件、测试文件的组织方式，让 AI 生成的代码跟项目现有风格一致。
这一类技能我实际用下来，收益最大的是“代码审查”。以前我让 AI 直接审代码，它经常会给一些泛泛的建议，比如“这里可以优化可读性”。但挂上 TypeScript 审查技能之后，它会强制自己先列类型边界，再逐条出问题，给出具体的类型推导示例。AI 还是那个 AI，但表现明显“专业”了很多，这就是技能包的价值——用流程约束输出质量。
3.2 数学建模与竞赛场景：技能包不是前端专属
别以为 Skills 只适合写代码的人。我搜了一圈之后发现，学生圈已经有人在整理“华为杯建模比赛好用的 codex skills”和“数学建模 skills 推荐”这类内容，思路其实非常值得借鉴。
数学建模比赛里，AI 最常见的翻车点不是“不会写公式”，而是写着写着就偏离了题目要求，论文格式也不稳定。你完全可以把一个“数学建模助手”定义成技能包，里面固定包含几块内容：常用数值计算库的选用规则（Python 的 numpy/scipy，还是 MATLAB 语法）、LaTeX 论文模板、图表风格规范、问题拆解流程。每次 AI 接到建模任务时，就按这个流程走：先拆问题，再定模型，再编码求解，最后按 LaTeX 模板生成论文段落。
这种技能包不需要多复杂，本质是把你团队去年比赛总结出的最佳实践写成 SKILL.md。对非程序员来说，反而更能体现 skills 的通用价值：它不挑行业，只挑“你是不是有可复用的工作流程”。
3.3 内容创作与 AI 漫剧：角色一致性的救星
另一个让我意外的高频关键词是“AI 漫剧常用 skills”。这背后其实是个很痛的需求：用 AI 生成漫画或短剧时，最难的是保持角色形象一致。今天的图长这样，明天的图长了另一张脸，所以有人开始把“角色设定”做成技能包。
一套做法是这样的：在技能目录里放一份角色描述文件，包含角色外貌、服装、画风关键词、常用表情的描述。AI 每次生成画面提示词时，先读这个技能里的角色卡，再输出 prompt，这样人物一致性会明显提升。还有更进阶的，把分镜语言、镜头运动、背景风格的规范也一起写进技能里。
这件事给我的启发是：技能包的定义范围可以非常个性化，它不一定非要“科技含量高”，只要能固化成稳定流程，就值得做成 Skill。我后来甚至把自己的写作检查清单也做成了一套小技能，效果意外地好。
3.4 去哪里找更多可靠的 Skills 源
聊到“skills 技能库网址”和“常用 skills 源网站”，我建议不要收藏一堆第三方导航站，直接去 GitHub 搜这几个关键词更靠谱：awesome agent skills、claude skills、superpower skills。GitHub 的代码搜索和 README 预览已经足够好用，有些仓库还提供了网页版预览界面，可以直接在浏览器里浏览技能列表，再决定下哪一个。
筛选标准我一般是三条：一是看最近更新日期，超过半年没更新的基本不碰；二是看 SKILL.md 的质量，有没有结构化的 frontmatter、有没有清晰的示例，如果只是几段废话，不要用；三是看 star 数和 issue 区有没有人反馈实际使用问题。单纯名字起得炫、Description 写得很唬人的技能包，比如一些叫 codex nature skills、cola skills 的冷门包，我建议谨慎对待，装之前多看一眼里面的真实内容。
4. 把 SKILL.md 吃透：自己写一个能跑的技能包
4.1 核心结构拆解：别只看表面格式
学会了装技能，下一步必然是写技能，否则你永远只能被别人的规则限制。我自己写的第一个 SKILL.md 踩了不少坑，这里给你们拆一份能直接上手的结构。
以 Anthropic Agent Skills 的写法为参考，一份 SKILL.md 由两部分组成：YAML frontmatter 和 Markdown 正文。frontmatter 里最关键的是 name 和 description。description 千万别写“用于处理 TypeScript 代码”这种废话，要写清楚“在什么情况下使用”，因为 AI 就是靠这句话判断要不要激活技能。正文部分我建议固定保留四个模块：
- Instructions：做什么，一二三写清楚。
- Workflow：先做什么后做什么，给出执行顺序。
- Checklist：最终输出前要检查哪些点。
- Examples：给一个输入输出样例，让 AI 有模仿基准。
这四个模块不是拍脑袋定的，而是在模仿一个靠谱新人入职时需要的培训材料：事情背景、做事顺序、检查标准、参考样例。缺了任何一块，AI 的输出质量都会明显下降。
4.2 手写示例：一个 TypeScript 类型安全审查 Skill
下面是我实际用过的一个最小示例，放在.claude/skills/typescript-audit/SKILL.md里，你可以直接复制改一改：
--- name: typescript-audit description: 当用户要求审查 TypeScript 类型安全、检查泛型边界、定位 any 或类型断言问题时使用。不要在没有 TypeScript 代码的对话中触发。 --- # TypeScript 类型安全审查 ## Instructions 1. 先读取项目中 tsconfig.json，确认 strict 模式是否开启。 2. 逐个检查用户提供的 TypeScript 文件，定位显式 any、类型断言、泛型边界问题。 3. 输出格式：每个问题按“位置 -> 问题 -> 改进建议 -> 示例代码”输出。 ## Workflow - 第 1 步：确认审查范围。 - 第 2 步：读取 tsconfig 和相关类型文件。 - 第 3 步：逐行审查并分类问题，分成 error / warning / suggestion 三级。 - 第 4 步：用“改进后代码”和“原有代码”做对比展示。 ## Checklist - [ ] 是否明确标出问题文件与行号？ - [ ] 是否给出具体类型定义，而不是只说“这里类型可以优化”？ - [ ] 是否避免直接把所有类型改成 unknown 或 any？ ## Examples 输入：一个包含 `const data: any = getData()` 的文件。 输出：指出 any 导致类型逃逸，建议根据函数返回类型推导，或显式定义 interface。这份技能写完，效果立竿见影。AI 在审查代码时明显会按步骤走，而不是信马由缰地乱给建议。你如果对 TypeScript 本身没兴趣，也可以按同样的结构写一份适合自己工作的技能，结构比内容更重要。
4.3 写 skill 的三个容易踩的坑
第一个坑是 description 写得太宽。我曾经写“用于辅助前端开发”，结果 AI 在写 CSS 的时候也触发它，流程根本对不上。后来改成“当用户要求审查 TypeScript 类型时使用”，触发准确率就正常了。description 宁可写窄，不要写宽。
第二个坑是流程写太死。技能包起到的是框架作用，不是刑法律条。如果你把所有细节都规定死，AI 反而会失去灵活性，遇到边界情况就表现得很僵。我的建议是：固定“顺序”，但给“方法”留弹性。比如规定“先读 tsconfig”，但不要规定“必须用某个具体命令行工具去读”。
第三个坑是忘了写“什么时候不要用”。很多技能包在 Instructions 末尾加一句“如果本次任务与上述场景无关，请忽略本技能”。这句话看似多余，实际能大幅降低误触发概率。尤其当你同时装了几十个技能时，这句话就是你最后一道防线。
4.4 一个可复用的 SKILL.md 起草流程
还有一个小技巧值得分享：不要凭空写技能，先把你的一次优秀对话“复盘”成技能。比如你某次让 AI 帮忙做了一个特别好的代码重构，把它当时的分析步骤、参考过的文件、输出格式整理一下，写成 SKILL.md。这比从零设计一套流程要容易得多，而且内容有真实的操作痕迹，AI 执行起来更自然。我自己最近写技能基本都是这种方法：先用普通对话得到一个好结果，再提炼成技能，之后让所有新对话都按这个标准来。
5. 用起来之后：配置、调优与清理
5.1 如何让 AI 按需加载，而不是一次性塞进上下文
技能包虽好，但“装太多”会出大问题。最典型的症状是上下文爆炸：AI 为了加载所有技能，把几千行规则全读进上下文，还没开始干活，输出质量已经开始下降。所以我用下来最核心的一条调优原则是：让技能按需加载，而不是多多益善。
如果工具支持语义匹配，重点优化每个技能的 description，让 AI 能精准判断什么时候激活。如果工具支持手动引用，那就更简单，默认不加载，需要时再手写@技能名唤起。我更推荐后一种方式，虽然多打几个字，但每次 AI 的执行质量都更可控。
另外，不同项目可以配不同技能集。别把三十个技能全放在用户级目录里，而要根据项目类型，只放跟当前项目相关的几个。比如这个项目是前端组件库，那就放组件生成、类型审查、测试生成；那个项目是写文档的，就放文档结构和校对相关技能。这样既不会污染上下文，也能保证每个团队成员的 AI 行为一致。
5.2 技能包膨胀和清理：为什么该删就得删
有一阵子我疯狂收集技能包，GitHub 上看到什么都想装，最多的时候同时挂了 30 多个。结果 AI 的表现反而变差了，经常是“表面看懂了，实际上一个技能都没用好”。后来看到社区里一位叫 tibo 的开发者也分享过类似的清理方法，核心思想是：技能是负债，不是资产；每多一个技能，就多一份维护成本和误触发概率。
我给自己定了个清理标准：
| 保留条件 | 删除条件 |
|---|---|
| 最近两周真实用过 3 次以上 | 装上之后再也没碰过 |
| 当前项目场景必需 | 跟另一个技能功能高度重叠 |
| SKILL.md 结构清晰、维护方便 | 内容老旧，描述已不符合实际输出 |
| 能明显提升输出质量 | 只是“看起来有用”，实际无感 |
清理动作也很简单：从技能目录里把对应文件夹移到一个_disabled_skills目录，而不是直接删除。这样万一发现某个技能还有用，可以随时恢复，同时又不会影响当前加载。我每两周左右做一次这样的“技能盘点”，AI 的稳定性明显恢复。
5.3 版本管理与团队共享：把技能当成代码对待
最后一定要养成版本管理意识。技能包是纯文本文件，天生适合放进 Git。我的建议是把.claude/skills目录提交到项目仓库里，这样新成员第一次 clone 项目时，AI 技能自动就位，不需要手动一对一地传文件。
团队里最好指定一个人专门维护公共技能。其他人想改技能，先提 issue 或 PR，而不是偷偷改自己本地的文件。因为技能一旦共享，牵一发动全身，你今天改了一句检查规则，明天可能让全团队的 AI 行为都发生变化。这样做几周之后，你会发现技能包已经变成了团队工程资产的一部分，而不是某个人的私人收藏。
6. 我踩过的坑和一些实在话
6.1 坑一：迷信“装得多”导致上下文爆炸
前面说过我最多装过 30 多个技能包，那段经历真的很折磨。表现是：AI 每条回复都变得特别啰嗦，动不动把各个技能里不相干的内容带进来；处理一个小问题要等很久，因为上下文中塞了太多规则；最重要的是，AI 开始“精神分裂”，一会按 A 技能的规范说话，一会按 B 技能的规范说话。
后来我把技能删到只剩 5 个，每个技能都是当前项目的高频场景，效果反而立竿见影。所以如果你刚开始接触 skills，别急着收藏一大堆，先认真把一两个核心技能用好，再慢慢扩张。
6.2 坑二：不更新旧技能，AI 用过期规则干活
还有一次，我在一个项目里保留了很早期的代码生成技能，里面推荐的目录结构早就不符合新项目规范了，但因为技能包一直在，AI 每次生成新文件都按老规范来。项目里于是出现了新旧两套结构共存的混乱局面。
这件事让我意识到，技能包是“活的”文档，不是在 GitHub 上 clone 下来就能一劳永逸的。你需要像维护代码一样维护它：每次项目规范变化，就去更新对应的 SKILL.md；每次发现 AI 输出不符合预期，优先怀疑是不是技能内容过时了。
6.3 最后说点大实话
Skills 这套东西的火爆，本质上是因为 AI 编程工具的能力已经足够强，瓶颈转移到了“如何让 AI 每次稳定地发挥出高水平”。Matt Pocock 和 TypeScript 社区带来的启发，是硬生生把“调教 AI”这件事，从一门玄学变成了可工程化的流程。你不需要多高深的技术，只需要认真思考自己的工作流，然后写成一份 AI 能读懂的标准文档。
我个人的体会是：真正有价值的技能包，往往不是从网上下载的，而是你自己从一次高质量人机协作里复盘出来的。别人再好的技能，只是给你提供一个起点，最终它只有在你的项目语境里被反复修改，才会真正长成你自己的东西。把这个动作持续做下去，你会发现 AI 编程从“碰运气”变成了“靠系统”，这大概就是 Matt Pocock 那套 Skills 实践最值得学习的地方。
