1. 为什么我开始关注Matt Pocock和他的Skills我大概是从2024年底开始认真折腾AI编程工具的那时候Claude Code刚火起来身边一帮搞前端的朋友都在聊一个名字——Matt Pocock。如果你平时写TypeScript大概率看过他的Total TypeScript教程或者刷到过他那些把TS类型题讲得特别通透的短视频。这哥们是英国的前端教育者在TypeScript领域相当有话语权后来他把注意力转向了AI编程辅助做了一套叫Skills的东西。先说清楚Skills是什么。用过Claude Code、Codex这类AI编程工具的人都知道它们自带了一堆能力但默认行为比较“通用”。比如你让它改一段TypeScript它可能改得中规中矩甚至规整得过头你让它写测试它可能写得像模板。这时候就需要一种机制把特定领域的专业知识、操作习惯、约束条件“注入”给模型。Skills就是干这个的它以目录和结构化文档的形式存在里面写清楚这个技能是干什么的、在什么场景触发、具体怎么做、有哪些注意事项。模型在对话过程中检测到相关任务时会主动去读取这些技能文件然后按照里面的规范执行。Matt Pocock做的Skills路子很TypeScript——极度类型安全、可复用、强调生产环境实战。我第一次用他的skills修一个泛型推断崩掉的场景时属实被震了一下AI没有再给我那种“把类型换成any”的偷懒方案而是老老实实按照技能里定义的策略一步步把类型参数之间的关系理清楚了还顺手帮我补了边界测试。这个体验让我意识到skil ls不是一个噱头它是真能把AI编程质量拉高一个档次的工具。这篇文章我想从实践的角度完整聊聊Matt Pocock的Skills到底解决什么问题它的内部机制是什么样的怎么从GitHub手动装到Claude Code和Codex里怎么在实际项目里用出效果以及我踩过的坑和排查经验。同时也想带大家看看除了Matt Pocock现在SKILLS生态里还有什么值得关注的方向——包括华为杯数学建模比赛里那些好用的Codex skills、AI漫剧常用skills、以及像“superpower skills”和“typesafe ai skills”这类概念到底指向什么。如果你是前端开发者、AI工具重度用户或者单纯对“给AI定制工作流”这件事感兴趣这篇文章应该能给你一套完整的落地思路。2. Skills的核心机制与设计思路2.1 Skills在AI编程工具中的角色很多人在刚接触Skills时会有个误区觉得它就是一个“写满了prompt的文档”。其实它的作用机制要比一个prompt复杂得多。以Claude Code为例它的系统会在每次对话启动时扫描当前项目以及用户全局目录下的所有Skills载入一份“技能清单”。这份清单里包含每个技能的名称和description。当模型分析用户需求时它会根据description判断某个任务是否匹配某项技能一旦匹配模型就会去读取对应的SKILL.md文件把技能的内容加入到上下文里然后用这套规则来指导自己的行为。所以你看这个机制本质上是给模型装了一组“按需加载的专业说明书”。关键点在于“按需”这两个字。不是把所有技能一股脑全塞给模型而是靠描述匹配来触发这样上下文不会被无关信息填满模型也能在被需要的时候拿到最精准的指导。Codex的机制也类似只是目录位置不同、格式略有差异。这套设计思路的好处在于技能模块可以和具体项目解耦你可以在不同的项目里使用同一套技能也可以在同一个工作区里按需激活不同的技能包。它有点像VS Code里的插件系统——核心编辑器就那么大功能全靠扩展往里插。剥离了“插件”概念的AI编程工具就像没装插件的VS Code能用但很难用出生产力。2.2 Matt Pocock技能包的典型特征Matt Pocock的Skills最突出的特征是“类型安全优先”。这和他多年整理TypeScript类型体操的经验直接相关。普通开发者写的技能往往聚焦在“让AI去做某件事”的流程描述上Matt写的技能还会规定“AI必须避免什么”“哪些场景属于异常”“遇到模糊情况该怎么办”。我用过一个他的技能场景是修复TypeScript类型错误。这个技能的核心规范包括几条先重现错误明确当前作用域的类型上下文不凭空猜测优先通过“收缩类型”或“类型守卫”的方式解决不推荐直接改any如果问题根源是数据源类型定义需要先修正类型声明而不是在调用点打补丁每组修复必须附带对应的类型验证命令或测试用例这套规范等于把Matt多年带团队时定的代码审查标准完整复刻到了AI的工作流里。你不需要自己在prompt里反复强调“别乱用any”技能文件已经替你把规矩立好了。另一个有意思的方向是他在“Total TypeScript”课程体系里沉淀下来的技能比如类型挑战、泛型工具类型的实现、字符串模板类型的分析等。安装之后你可以直接让AI生成一套类型挑战练习题或者让它针对你项目里的复杂类型写深度分析报告。我有时候会拿这些技能来做Code Review——不是看业务逻辑而是专门审查类型定义层面的设计问题。这大概是TypeScript前端工程师目前能用到的最顺手的一类AI辅助技能。2.3 “Superpower Skills”与“Typesafe AI Skills”是什么在找Matt Pocock的Skills时你大概率会碰到两个热门的词——Superpower Skills和Typesafe AI Skills。它们两个的侧重点不太一样。Superpower Skills是社区里比较火的一套通用技能集合它包含了很多“放之四海而皆准”的工作流比如项目规划、代码审查、重构指导、学习辅导。它的定位更像是一个“通用能力增强包”适用于各种项目类型。Matt Pocock本人的一些skills理念其实和superpowers有所呼应尤其是关于“模型要按严格的步骤执行不凭经验跳跃”这一点。而Typesafe AI Skills更偏TypeScript领域核心是把类型安全作为AI生成代码的第一约束。很多前端团队在实践AI辅助开发时最头疼的问题之一就是AI为了“快速交付”而疯狂使用any把整个项目的类型体系搞成一个漏斗。Typesafe方向的skills就是专门治这个毛病的——它会在技能描述里显式要求AI遵循严格类型约束并提供一组类型层面的质量检查清单。回头看Matt Pocock做的事其实可以把他的skills理解为一个“TypeScript领域的专业superpower”既有通用技能的流程化特征又深度绑定了类型安全的工程实践。所以如果你看到“matt pocock skills”和“typesafe ai skills github”被放在一起讨论不要觉得奇怪它们本质上是在解决同一个问题——如何让AI写出更可靠的前端代码。3. 从GitHub手动安装Matt Pocock的Skills3.1 安装前的准备与目录结构想用Matt Pocock的Skills不用等什么官方市场。就像热词里频繁出现的“claude code怎么手动装github上的skills”一样最常规的方式就是从GitHub仓库把技能文件clone到本地再放到对应工具的扫描目录里。先说目录结构。Claude Code默认扫描两个位置的skills全局目录~/.claude/skills/项目目录.claude/skills/Codex的目录略有不同通常是在~/.codex/skills/或项目内的.codex/skills/。如果你用的是opencode这类开源工具位置会再变一下建议装之前先看一眼官方文档。每个skill目录里面至少要有一个SKILL.md文件。这个文件是技能的核心描述了技能的触发条件和使用方法。有些技能还会自带参考文件、模板目录或脚本文件但SKILL.md是入口模型通过它来决定是否调用这个技能。手动安装时你不需要跑到某个市场东搜西找核心就是找到GitHub上的仓库地址然后clone。以“typesafe ai skills”这类仓库为例通常里面有skills/目录里面按技能名划分子目录。你需要做的就是把这些子目录复制到上述扫描路径里。3.2 逐步操作以Claude Code为例下面以Claude Code装Matt Pocock某套TypeScript技能为例走一遍完整流程。假设我想装的技能仓库是matt-pocock-skills实际仓库名以GitHub搜到的为准里面包含一个叫fix-typescript-errors的技能。第一步打开终端clone仓库到临时目录git clone https://github.com/your-org/matt-pocock-skills.git第二步进入仓库查看skills目录结构cd matt-pocock-skills ls -la skills/你会看到类似skills/fix-typescript-errors/SKILL.md这样的路径。有些仓库会把skills放在根目录没有skills/这一层看情况调整。第三步把技能复制到Claude Code的全局目录。这样你在任何项目里都能用mkdir -p ~/.claude/skills cp -r skills/fix-typescript-errors ~/.claude/skills/如果你想把这个技能限定在当前项目里复制到项目级目录mkdir -p .claude/skills cp -r skills/fix-typescript-errors .claude/skills/复制完之后我建议先检查一下文件结构是否完整find ~/.claude/skills -name SKILL.md确认能搜到SKILL.md文件就说明安装到位了。接下来重启Claude Code然后在对话里提出一个TypeScript类型错误相关的任务模型就会自动匹配并加载这个技能。3.3 安装Codex Skills的差异点Codex的手动安装过程在细节上有些不同。如果你的Codex是本地CLI版本同样需要创建一个skills目录然后把技能放进去。我知道很多参加华为杯数学建模比赛的同学在折腾Codex skills他们把建模常用的分析流程、绘图脚本规范、论文摘要写法都封装成了技能包。这非常实用因为数学建模比赛时间紧任务类型相对固定把常用的分析套路固化成skill相当于给AI配了一套标准作战手册。用Codex时需要注意的是它的技能触发机制可能和Claude Code不完全一致。部分版本的Codex需要在对话里主动提及技能名或相关关键词。比如你装了“数学建模数据预处理”这个技能最好在对话里直接说“使用数学建模数据预处理技能处理这份数据”这样触发的准确率会更高。另外如果你在Windows上操作路径可能需要调整——全局目录一般是C:\Users\用户名\.codex\skills\。装完技能后记得在Codex里执行一遍工作区扫描命令或者重启CLI工具才能让技能被识别。3.4 安装时的常见坑装技能这个操作本身不难坑主要在细节上。我把自己踩过的几个坑列出来大家能避则避。目录层级装错了。这是最常见的。有些人clone仓库后直接把整个仓库文件夹放进了~/.claude/skills/结果变成~/.claude/skills/matt-pocock-skills/fix-typescript-errors/SKILL.md。这种错误结构会导致技能不识别。正确做法是让~/.claude/skills/下面直接就是技能子目录也就是~/.claude/skills/fix-typescript-errors/SKILL.md。SKILL.md文件名大小写不对。某些工具对文件名敏感必须严格写成SKILL.md。写成skill.md或者Skill.md扫描时可能直接被忽略。缺少description字段。SKILL.md开头的YAML frontmatter必须有name和description。description是触发匹配的关键描述得越精准模型越容易在合适的场景调起它。如果description写得太泛模型可能永远不知道什么时候该用这个技能。吃完这些坑之后你的技能才能正常工作。装完技能先不要急着上生产项目建议先在一个临时目录里测试一下触发效果确认技能被正常加载再看实际业务效果。4. 实操体验用Matt Pocock的Skills修TypeScript错误4.1 典型场景一个泛型推断崩溃的真实案例理论讲再多不如跑一个真实例子。我在自己的一个开源库里有一段处理事件联合类型的泛型代码代码简化后大概长这样type EventMap { click: { x: number; y: number }; keydown: { key: string }; }; function onK extends keyof EventMap( event: K, handler: (payload: EventMap[K]) void ) { // ... } on(click, (payload) { // 这里payload的类型没有正确推断为 { x: number; y: number } // 而是被推断成了 { x: number; y: number } | { key: string } console.log(payload.x); });当时这个错误的根源是编译环境中某个类型工具函数把EventMap[K]的分布条件类型特性弄丢了导致联合类型没有正确分发。以前让AI帮我改它十有八九会直接建议把handler参数写成any或者让我在调用时手动指明泛型参数。那种方案能用但很丑而且会污染整个调用链。这次我装了Matt的技能后直接让AI处理。它加载技能之后明显换了套策略先是分析了触发修复的完整错误栈然后检查了EventMap的定义和泛型约束最终给出的方案是引入一个条件类型实现键到负载的显式映射绕过丢失的分发特性type PayloadForK extends keyof EventMap EventMap[K]; function onK extends keyof EventMap( event: K, handler: (payload: PayloadForK) void ) { // ... }严格来说这个改动就是个把索引访问类型包装成显式条件类型的小技巧。但关键在于AI是在技能约束下先判断“不要直接any”再思考“如何保持类型安全地解决”最后还主动建议我加一条ts-expect-error的测试来验证修复效果。这套动作链非常接近一个资深TypeScript开发者的处理路径。4.2 对比测试开不开启Skills的差别为了验证Skills的实际效果我在同一个项目里做了两组对比测试。第一组直接让普通的Claude Code修复这个错误第二组开启skill后再修复。两组都用同样的描述不带额外提示词。结果相当直观。普通模式下AI给出的修复方案在5个测试任务里有3个选择了宽松类型处理其中1个直接用了any。开启技能后5个任务里没有出现任何any而且每个修复都附带了解释“为什么不能直接改类型声明”。尤其是遇到一个涉及外部API响应类型的问题时普通模式试图在调用点断言类型技能模式则直接定位到了请求封装函数的返回类型定义错误。这个对比让我非常确定skill不是玄学它能通过约束和指导真正改变模型的行为模式。如果你有团队协作需求技能还能充当一种“团队规范的强制执行器”。比如你们公司规定API层类型必须从契约文件生成不允许手写你就可以写一个skill来约束AI凡涉及API类型定义的地方必须先检查契约文件。这在以前靠对话约束是极其不稳定的AI在长对话中很容易忘记规则而技能是持久化的只要触发就会生效。4.3 注意事项不要盲目信任技能当然我也要说句公道话技能不是万能的。它只能约束和引导不能改变模型底层的能力上限。如果模型本身理解不了复杂的泛型逻辑技能再完善也没用。而且技能之间存在优先级冲突的情况如果你同时装了好几个技能都负责“修复TypeScript错误”它们的描述可能互相重叠导致触发时模型同时读到两份指令产生混乱。我在实践中吃过一次亏装了一套“代码审查”技能和一套“重构建议”技能结果在处理同一个任务时AI先是按审查技能输出了一堆问题清单然后又按重构技能给出了一版改动方案——两边思路不一致把我整个diff都搅乱了。后面我清理掉其中一套技能只保留更适合当前项目语境的情况才恢复正常。所以我的建议是技能数量宁少勿多每个场景明确一个技能负责。技能之间如果存在重叠领域最好在description里加上明确的排除边界比如“本技能仅处理类型错误修复不涉及代码风格建议”。5. 动手写自己的SkillsAI技能的编写逻辑5.1 理解SKILL.md的结构看到热门搜索里有不少人在问“ai skills怎么写”“skills开发”这块我展开讲讲。自己写skill的核心就是要掌握SKILL.md的编写规范。它和写一篇博客不一样不是把知识记录进去就行而是要把知识“可执行化”让模型能按照你的意图完成任务。一个标准的SKILL.md由两部分组成YAML frontmatter和Markdown正文。YAML部分至少要有两个字段--- name: fix-typescript-errors description: 当项目中存在TypeScript类型错误、类型推断失败或泛型使用不当时使用。该技能提供类型安全的修复策略优先通过类型守卫和显式映射解决问题避免直接使用any。 ---name好理解。description是整个技能的触发开关写得好不好直接决定模型会不会在合适的时候调起它。一个好的description应该包含三个要素触发场景、处理对象、行为约束。比如上面的描述里“当项目中存在TypeScript类型错误”是触发场景“泛型使用不当”是处理对象“避免直接使用any”是行为约束。Markdown正文部分是具体的执行说明包括背景知识、操作步骤、实操要点和示例。同样以修复TypeScript错误的技能为例正文可以这么写# TypeScript错误修复实战 ## 步骤一定位类型错误 在修复前首先运行类型检查命令如 tsc --noEmit完整重现错误信息。根据错误栈定位到具体文件和代码行。 ## 步骤二分析上下文 检查当前变量、函数参数、返回值的类型声明。特别关注泛型参数是否显式声明、类型守卫是否存在、外部数据源的类型定义是否正确。 ## 步骤三选择修复策略 按优先级依次尝试 1. 通过类型守卫收缩类型 2. 修复数据源的类型声明 3. 使用显式映射类型解决分发问题 4. 仅在没有其他方案时使用类型断言并写明注释 ## 步骤四验证修复 修复后必须重新运行类型检查并补充或更新相关的类型测试用例。 ## 关键约束 - 严禁直接使用 any 或 unknown 绕过类型错误 - 严禁不验证就提交修复方案 - 严禁修改与当前错误无关的类型声明这样写的好处是模型拿到这份技能后就知道“这件事该按什么顺序做、有哪些红线不能碰”。如果只是简单写“请帮我修复TypeScript错误”模型的行为仍然不可控但把分步策略写进去模型的行为就有了流程约束。5.2 从零到一一个可落地的技能编写示例拿一个实际场景来走一遍完整流程。假设你想做一个“数学建模技能包”这也是热词里提到的方向尤其适合华为杯参赛者。第一步先定义这个技能包的scope是负责整个建模流程还是只负责某个阶段我的建议是只负责一个窄场景比如“数据探索与可视化”不要试图一个技能包干完所有事。第二步写YAML--- name: math-model-eda description: 在进行数学建模比赛时分析赛题数据、生成探索性分析报告和可视化图表的技能。触发条件当需要处理赛题表格数据、统计特征、缺失值、相关性分析、绘制分布图时使用。 ---第三步写正文步骤。这份技能面对的是赛题数据集所以步骤设计要贴合建模比赛节奏——时间紧、结论要直观、图表要规范# 数学建模数据探索流程 ## 1. 数据概览 加载数据后先输出维度、列名、数据类型、缺失值统计。不要用大量print堆屏直接给出结构化汇总。 ## 2. 缺失值处理建议 区分“完全随机缺失”和“结构性缺失”。对于结构性缺失优先分析缺失原因不推荐盲目填充。 ## 3. 相关性分析 针对数值型特征输出相关性矩阵高相关特征对要特别标注为后续模型选择提供参考。 ## 4. 可视化 - 单变量分布用直方图或密度图 - 双变量关系用散点图加趋势线 - 类别特征用箱线图对比 ## 输出要求 所有图表统一标注中英文标题保存为PNG放入报告目录。每个图表后附一行结论。第四步就是把它保存到~/.claude/skills/math-model-eda/SKILL.md重启工具后测试。自己写一遍之后你会对市面上其他技能包的理解更深。这就像你只有自己写过组件库才能真正用好别人的组件库。技能开发的核心不是“写文案”而是“梳理工作流”——你得把自己脑子里的隐性经验转化成模型能够按步骤执行的显性规范。5.3 技能编写的高频错误与改进方向写技能最容易犯的错误有两个。第一个是描述写得太宽泛。比如“帮助处理数据”这种描述模型永远不知道什么时候该调起这个技能。要改成“当用户提供CSV或Excel格式的赛题数据并需要分析其统计特征时”。第二个错误是正文没有可验证的步骤约束。很多人写技能只写“你应该做分析”“你应该避免乱填缺失值”但没有告诉模型“怎么算分析”“填充前要看什么”。好的技能正文需要有明确的步骤边界和验证方式比如“每个缺失值特征必须输出缺失比例”“填充前后必须做分布对比”。还有一个常见的问题是“示例缺失”。模型其实非常擅长从示例中学习格式和风格。如果技能里能附上两三段输入输出示例生成效果会显著提升。尤其像AI漫剧常用skills这类偏创作向的技能示例的作用比规则描述还大——模型看到一段完整的分镜描述后能更好地模仿其风格。6. 常见问题与排查技巧实录6.1 技能不生效的排查顺序技能装了一堆真到干活时发现AI完全不按技能走这种情况我遇到过太多次了。下面给出一套排查顺序按这个顺序来基本能解决90%的问题。先确认技能放对了位置。打开终端运行命令看看全局skills目录里到底有什么ls -la ~/.claude/skills/确认技能子目录直接挂在skills目录下面里面存在SKILL.md文件。如果这里就没问题接着检查YAML格式。有时候frontmatter里的description写得太长包含换行或特殊字符导致解析失败。最简单的验证方式是打开文件确认---上下闭合、字段名没有拼写错误。如果文件没问题还要看有没有重启工具。Claude Code和Codex通常只在启动时扫描一遍技能目录中途放进来的技能不会立刻生效。这一点经常被忽略改完文件后第一件事应该是重启会话或重载工作区。如果以上都没问题那就是触发条件不匹配了。仔细读一遍你写的description对比你实际输入的任务描述看有没有重叠的关键语义。比如技能描述是“当项目存在TypeScript错误时”你却在对话里说“帮我看看这个页面的布局为什么乱了”那它自然不会触发。调整触发描述或者把任务描述改得更贴近技能场景往往就解决了。6.2 技能冲突与性能问题处理技能装多了之后比较头疼的一个问题是“多个技能同时触发”。比如你装了一个“前端代码生成”技能又装了一个“React组件开发”技能结果让AI写一个组件时它同时把两个技能文件都读进去了如果两个技能里的规范不一致AI就会表现出人格分裂式的输出。解决方式有两种。第一种是把项目级目录.claude/skills/当成“白名单”来用——只把当前项目需要的技能放进去其余技能一律放在全局目录。这样在具体项目里模型会优先扫描项目目录冲突概率大幅降低。第二种是在写技能时提前在description里声明边界词比如“本技能专注于数据清洗阶段不涉及建模与论文撰写”。性能方面在我看来常规项目不会因为装了几十个技能就变慢。但如果你装了几百个技能每次对话都要进行匹配扫描肯定会有些拖慢。成熟的策略是全局目录只放通用性极强的技能比如代码审查、问题拆解项目目录临时放特定领域的技能用完了就删。我自己现在全局目录常年只挂三个技能剩下的全放项目里实测稳定不少。6.3 热门场景中的Skills实战经验最后聊几个从热词里看到的实战场景都是身边人验证过确实有效的方向。第一个是数学建模比赛。华为杯这类比赛时间紧、任务重复性强最适合用skills固化流程。除了前面提到的数据探索技能还可以做一个“论文摘要生成”技能它规定摘要必须包含研究问题、方法、模型原理、结果、创新点五要素并要求控制在300字以内。这种技能对AI漫剧、短视频文案这类创作场景也同样适用——把分镜描述、场景设定、对白风格规范写进技能AI生成的脚本质量会稳定很多。第二个是“ai漫剧常用skills”。这个领域的热度让我挺意外的但仔细一想很合理。漫剧创作需要连续输出统一的角色设定、场景描述和分镜风格凭对话维持一致性基本不可能而技能恰好能解决这个问题。把角色人设、画风偏好、镜头语言规范写进SKILL.md每次创作时模型都会自动遵循同一套设定这比什么提示词工程都管用。第三个是“codex skills在建模和开发中的实践”。很多人在Codex下装superpowers风格的大而全技能包结果由于技能体积过大、描述过于宽泛触发准确率反而不高。我的实践心得是再好的技能也要在做完任务后检查输出质量如果连续出现输出风格失控或者规则失效优先怀疑技能描述写得太大而空而不是怀疑模型本身。我个人在实际项目中已经把skills当作整个AI工作流的“基座”来用了。每次新建一个项目第一件事不是写业务代码而是把项目级别的技能目录搭好把类型规范、提交规范、审查规范写进技能里。这样做的好处是不管对话怎么演化AI都不会跑偏到“用any解决问题”或者“无视测试直接交付”的老路上去。如果你现在还在靠临时对话约束AI行为我强烈建议你花一个小时把团队最常强调的三五条规范固化成技能试试——你大概率会发现之前一直骂AI“不听话”问题不只在模型更在你没有给它一套足够清晰的执行手册。