Matt Pocock 这个名字凡是在前端圈混过几年的朋友应该都不陌生。他做的 Total TypeScript 系列课程帮无数人把 TypeScript 从“会写”练到了“敢写”。但最近让我眼前一亮的不是他的类型体操而是他在 AI 编程工具里力推的一套方法论——从提示词到 Skills。简单说Skills 就是把我们平时反复粘贴给 AI 的提示词沉淀成结构化、可复用、跨项目生效的“操作手册”。Claude Code 有 skillsCursor 有 rulesOpenAI Codex 也有自己的指令文件各家叫法不同思路殊途同归。这篇文章我想结合 Matt Pocock 的方法以及我自己在 Claude Code、Cursor、Codex 里来回折腾的经验手把手聊聊怎么理解 Skills、怎么手动安装 GitHub 上的现成技能包、怎么评估技能源以及怎么从零写一个属于自己的 Skills。无论你是前端、全栈还是做数据分析只要能动手改配置这篇文章里的东西你都能用上。1. 从提示词到 SkillsMatt Pocock 的思路拆解1.1 Skills 到底是什么先打个比方。你雇了一个很聪明的实习生每次让他写周报你都要从头交代一遍邮件标题怎么起、语气什么风格、数据放哪一栏。交代了五六回之后你终于烦了把要求写成一页说明贴在工位上。下次只需要说一句“出周报”他就能照着工位上的说明办事甚至能把你交办过的细节一起记住。这个“工位说明”就是 AI 编程工具里的 Skills。它本质是一个文本目录里面有一份核心说明文件外加示例、模板、脚本之类的辅助资源。Skills 和普通提示词最大的区别在于提示词是“一次性”的这次写完、用完就没了Skills 是“结构化”的它有固定的目录格式、描述字段、名称能被工具的检索机制识别在你需要的时候自动加载进上下文。换句话说提示词是给 AI 的一条临时指令Skills 是给 AI 的一份长期岗位说明书。1.2 Matt Pocock 主张什么Matt Pocock 在这个方向上的贡献不是发明了某个技能仓库而是把“Skills”这个概念向开发者群体讲透了尤其是从提示词到 Skills 这条进阶路径。他的核心观点和我踩坑之后的感受完全一致普通人用 AI 的瓶颈不是不会写提示词而是每换一个项目、每新开一个会话都在重复输入同样的提示词。他给我的最大启发是把你最常用、最耗时、最“值钱”的几个工作流优先变成 Skills而且不要一上来就想做一个覆盖所有场景的“超级技能包”。原因在于大部分技能系统的加载机制是靠 description 描述和当前任务的语义匹配度来决定要不要使用某个技能。技能包越宏大描述越模糊AI 在需要的时候反而检索不到。做三五个精准的小技能永远好过做一个什么都管的大包。1.3 不同工具里的 Skills 形态很多人在讨论 skills 时会把 Claude Code、Cursor、Codex 混在一起说其实它们的存储和加载方式各有差异。Claude CodeAnthropic 官方 CLI支持.claude/skills/目录形式的技能每个技能一个子目录里面有SKILL.md。CursorAI 代码编辑器更多是走.cursor/rules/规则文件和.cursor/commands/命令模式社区也做了不少把标准 Skills 适配到 Cursor 的办法。OpenAI Codex命令行编程工具则支持在配置目录里放AGENTS.md等指令文件社区通过文件夹结构实现了类似效果。这些工具的共性是都认可“结构化指令文件 自动加载”的价值差异在于路径、命名和优先级。想跨工具复用一套技能最稳的方法是保留统一的技能目录结构在每个工具里做一层“入口映射”后面我会演示具体怎么操作。2. Skills 文件格式与配置规范2.1 目录结构一个技能就是一个小项目无论你是安装别人写好的技能还是自己从零开发第一步都是理解它的目录长什么样。社区经过半年多的磨合基本形成了一套通用约定my-skill/ ├── SKILL.md ├── examples/ │ └── example-1.md ├── scripts/ │ └── run.sh └── references/ └── reference.md核心文件是SKILL.md它是技能的门面也是检索系统最先读取的内容。其余辅助文件用来在技能被调用时提供深度参考。如果你的技能足够简单所有内容塞进SKILL.md也完全没问题保持轻量才是关键。很多初学者把目录搭得特别复杂结果维护成本比收益还高这是没必要的事情。2.2 SKILL.md 的元数据字段SKILL.md通常以 YAML frontmatter 开头里面写着技能的名称和描述下面这个例子就是 mvp 级的--- name: weekly-report description: 生成符合团队规范的周报包含进度、风险、下周计划三个板块。仅在你的任务是撰写或修改周报时使用。 ---这里有两个细节值得较真。第一name短而唯一用英文小写加连字符方便后续命令行引用。第二description是决定检索命中率的关键字段必须写清楚“什么时候该用”它就像标签任务描述一旦出现相关关键词系统就能把对应技能查出来。常见的错误是描述写得太泛比如“帮助生成周报”AI 判断相似度的时候容易误匹配。改成“生成符合 XX 公司研发团队规范的周报适合在每周五提交或修改周报时调用”命中率会高很多。这也是 Matt Pocock 反复强调的描述决定命中内容决定质量。2.3 把一段优质提示词改写成 Skills从提示词到 Skills并不难难在养成复盘意识。我通常分三步走。第一步复盘。回忆过去一个月里反复粘贴的提示词把频率最高的那几类圈出来。我自己的高频场景是代码评审、环境变量整理、架构文档输出。第二步提炼。把长提示词里“规则”和“示例”分开规则是要 AI 一直遵守的行为约束比如“不要修改无关文件”“提交信息遵循 Conventional Commits”示例是你期望的输出格式。第三步结构化。规则写进SKILL.md主体示例放进examples/目录最后配一段清晰可检索的 description。严格来说这活儿没有高深技术含量真正难的是第一步复盘。很多人一听说 Skills 很火拿起工具就开写结果技能数量上来了、质量很差最后全躺在目录里吃灰。先花一周记录自己的提示词使用习惯再动手做收益会大得多。3. 手动安装 GitHub 上的 Skills完整实操记录3.1 找到技能安装目录“Claude Code 怎么手动装 GitHub 上的 skills”这个问题的第一步是弄清楚你的工具从哪个目录读取技能不同工具差异很大这里也最容易出错。以 Claude Code 为例项目内使用的场景是把技能放进.claude/skills/目录。终端执行mkdir -p .claude/skills ls -la .claude/skills这个目录跟随项目提交到 Git 仓库后团队其他成员 clone 下来就能共享整套技能。如果你的诉求是所有项目都能用那就放到用户级配置目录具体路径以对应版本文档为准。需要提醒的是Claude Code 不同版本对用户级目录的路径定义有过调整遇到“明明装了但没生效”的情况第一件事先确认版本。Cursor 的场景稍微绕一点先把技能内容克隆到本地然后在.cursor/rules/增加一个导入或映射的规则文件。Codex 类似把技能内容整理好在AGENTS.md里追加对应引用。一句话总结技能本体是通用的差异全在“入口”这一层。3.2 克隆开源技能仓库以 superpower skills 为例GitHub 上最有名的技能集合之一是 glipsnort 的superpower-skills仓库里面收集了大量实用技能覆盖文本总结、会议记录、代码分析等场景。手动安装的步骤很简单git clone https://github.com/glipsnort/superpower-skills.git克隆下来之后每个子目录就是一个独立技能。不建议把整个仓库拖进项目那样会让目录变得很臃肿。按需挑选才是正确操作# 假设只需要 code-review 这个技能 cp -r superpower-skills/code-review .claude/skills/如果你用 Cursor 或 Codex只要技能内部不依赖特定工具命令可以保留同样的目录结构再在自己工具的配置文件里做引用。重点强调一下“按需复制”的重要性。我见过有人把整套技能库复制进项目目录里堆了几十个用不上的技能不仅拖慢加载还会增加误命中概率整体效果反而更差。3.3 配置启用让 AI 真正调用你装的技能复制好目录只完成一半还要验证两个点一是SKILL.md文件名有没有拼错、路径层级对不对二是 description 写得是否清晰如果含混不清AI 很可能在需要时“想不起来”这个技能。最直接的验证方法是新开一个会话用对应场景的命令触发它。比如我装了commit-message技能就故意输入“帮我对这些改动写一个 commit message”。如果 AI 正确调用了技能它会按技能内的格式和规则输出如果毫无反应多半是描述问题或路径问题。还可以在会话中直接问一句“你现在有哪些 skills 可用”让模型自报家门这也是排查时的快捷通道。3.4 版本更新与顺便聊聊清理从 GitHub 安装技能的天然问题是上游更新之后本地怎么同步。我的做法是在原克隆仓库里执行git pull然后再次按需复制到项目目录。这里有一个实操上很容易踩的坑不要直接在项目目录里git clone别人的整个仓库否则会留下嵌套的.git目录后面做项目初始化或者提交时会有各种干扰。清理技能这块网上有位叫 Tibo 的开发者分享过一个方法核心一句话定期把技能目录完整铺开看一遍删掉那些连续两周都没被用到的技能。我照着做了一轮把 20 多个技能删到 8 个项目目录清爽很多AI 的响应速度和准确率都有可感知的提升。技能库这种东西本质上是会腐烂的不清理就越积越乱。4. 常用 Skills 源网站与精选推荐清单4.1 去哪找技能GitHub 搜索技巧GitHub 是目前最核心的 Skills 分发渠道因为技能本质上是文本和脚本集合天然适合用 Git 管理。我常用的入手路径有三个。第一是直接搜索关键词用claude skills、codex skills、skills marketplace按 stars 排序。第二是看官方仓库Anthropic 官方发布的内容优先看因为格式和升级兼容性有保证社区里superpower-skills这类明星项目也值得收藏。第三是找 awesome 风格的汇总列表里面有按类目整理好的链接适合快速了解生态全貌。4.2 superpower 与 typesafe ai skills 哪个更适合你如果你问我对刚接触 Skills 的人最推荐哪个仓库我的答案会根据场景分两路。追求通用技能选superpower-skills覆盖面广文本和代码场景都能照顾到做前端和 TypeScript 工程化我更推荐typesafe-ai-skills这是一个社区整理的、面向类型安全与前端工程化场景的技能集几乎算是 TS 场景绕不开的参考。后者的价值在于里面很多技能不只是简单的提示词粘贴而是把类型约束、代码风格、评审规范封装成了统一技能导入 Claude Code 或 Codex 之后相当于给 AI 发了一本团队编码规范手册。安装方式和前面 superpower 的例子一样克隆后按需复制。我的建议是把类型检查和代码评审相关的技能放在优先位置因为使用频率最高。前端团队的收益尤其明显——我把它接入项目后AI 生成的代码在any、未使用变量、组件拆分这些问题上收敛了很多。4.3 数学建模与竞赛场景的 Skills 推荐热搜词里有“华为杯建模比赛好用的 codex skills”“数学建模 skills 推荐”这里多说两句。竞赛场景特别能体现技能的价值比赛时间紧张你不想每次换一道题都重新教 AI 怎么写数据分析报告、怎么排版公式、怎么做图表。社区里确实有专门针对论文写作、数据可视化、latex 排版的技能搜math modeling skills、codex math、latex skills就有不少。选择时重点看它的示例是不是用真实建模题做的。只是泛泛的“帮助写论文”基本就是提示词换了个马甲价值有限。真正好用的技能里往往会放一个完整的真题示例里面包含数据读取、建模、结果分析、论文输出的完整链路这才是竞赛场景下能直接抄作业的东西。4.4 如何甄别技能质量stars 数只是一个粗筛指标我更看重三样东西更新频率、示例完整性、描述精细度。一个半年没动的仓库大概率已经和最新的工具版本脱节装进去反而出各种兼容问题一个自带可运行示例的技能可信度会高很多因为示例是技能质量最诚实的呈现一个精品技能肯定会在 description 里写明适用场景、输入输出要求、注意事项而不是写一句空洞的“非常强大的技能”。按这三条标准筛一圈能过滤掉市面上大半的垃圾技能包。5. 从零开发一个属于自己的 Skills5.1 设计原则如果说装别人的技能像“买菜”那自己写技能就像“做菜”能做符合自己口味的才是长期动力。写技能之前先确认三个原则。第一单一职责。一个技能只干一件事。我见过有人写了一个“全能助手”技能description 里列了十个能力AI 根本不知道什么时候调用。拆成十个独立小技能反而每个都好用。第二描述即检索入口。把“什么时候用”放在 description 开头而不是悬在结尾。第三示例驱动。SKILL.md 里不要只写抽象规则尽量带一个完整的小示例模型看一眼示例就知道你要的输出长什么样。5.2 核心模块怎么一层层写按层次来组织一个技能一般六个部分元信息区name / description适用场景说明什么时候用、什么时候不要用具体步骤Step 1 / 2 / 3尽量拆细输出模板一个 Markdown 模板规定结构示例放一两个具体例子注意事项哪些事绝对不能做这套结构借鉴了 Matt Pocock 的分享也融合了我自己的习惯。最容易被忽略的是“什么时候不要用”但它其实能大幅度减少误调用。按我的实测加了负向场景说明之后AI 误调用某个技能的概率能降一半以上。5.3 实战写一个前端代码审查技能我拿真实案例走一遍。假设我想让 AI 在代码审查时遵循团队规范那么新建.claude/skills/frontend-code-review/SKILL.md--- name: frontend-code-review description: 对 React/TypeScript 前端代码进行审查重点关注类型安全、性能、可维护性。当用户要求 review PR、检查代码质量问题、评估重构风险时使用。 --- # Frontend Code Review ## 审查步骤 1. 先阅读改动范围相关的上下文避免只看被修改的那几行。 2. 检查类型定义是否合理任何显式 any 都必须给出替换方案。 3. 检查组件是否违反单一职责是否过度抽象。 4. 检查性能隐患不必要的重渲染、大列表、大依赖。 5. 按“阻塞问题 / 建议问题 / 可选优化”三档输出结论。 ## 输出格式 ## 审查结论 ### 阻塞问题 ### 建议问题 ### 可选优化 ## 示例 放一个具体的代码片段和对应的审查结果示例 ## 注意事项 - 不要为了挑问题而挑问题没有明显问题时直接说明。 - 阻塞问题必须给出可操作的修复建议不能只说一句“需要关注”。写完这个文件我在真实项目中做了测试输入“帮我看下这几个组件文件有什么问题”AI 的输出明显更稳定自动分了优先级不再像以前那样想到哪说到哪。这就是结构化技能与自由提示词之间最直观的差别。注意这个示例里的修复建议、输出格式都是根据常见实践补充的实际使用时完全可以根据你们团队的评审流程调整措辞。5.4 测试与快速迭代写完技能不要急着收工至少跑三轮测试。第一轮按 description 描述的场景正常触发一次看输出是否符合预期。第二轮换个场景故意说一句不相干的需求看 AI 会不会错误调用如果误调用了说明 description 不够收紧。第三轮模拟边缘场景比如输入为空目录、只有一个文件、文件很大看技能能不能扛住。按我的经验一个技能写完头两天一定会经历一次大改因为真实运行时的行为和你动笔时的想象一定有差距。这不是你水平不行而是这种格式的工具天然需要靠实际运行来校准。建议把一个技能当成小项目迭代不要追求一次到位。6. 常见问题与排查技巧实录6.1 装上技能后完全不生效这个问题的排查顺序应该是路径是否放对Claude Code 是.claude/skills/Cursor 是.cursor/rules/或对应映射位置Codex 是配置目录的指令文件文件名是否规范必须是SKILL.md大小写敏感description 是否清晰最后确认是否新开了会话。大部分工具的技能加载发生在会话初始化阶段改了技能文件必须重开会话。如果是中途装的技能、当前会话一直不生效先别怀疑配置退出重进大概率就好了。6.2 描述模糊导致检索不到这个问题前面反复提过但值得再说一次。一个技能如果“想不起来”用大多数时候不是文件坏了而是 description 没写好。这里分享一个自测技巧把 description 文本拉出来和你希望它服务的那类任务的关键词做一次相似度自检。如果描述里根本没有“周报”“评审”“提交信息”这类词AI 很难把它跟你的任务关联起来。想检验也行在会话里直接输入相关任务如果 AI 没调用该技能就顺手在描述里补上更明确的任务关键词。6.3 跨工具复用时的兼容性问题同一个技能在 Claude Code 里好用换到 Codex 就可能失效原因多半是技能内部依赖了某个工具特有的命令或路径约定。如果你确实需要跨工具复用写技能时尽量避开环境相关内容核心规则、输出格式、示例放在SKILL.md环境特异的命令放到可选脚本文件里这样移植成本会低很多。这个原则在选型阶段就要想好否则后面改起来很折腾。6.4 技能库越来越乱怎么办给目录做一次“瘦身”我的操作是四件事所有技能必须有 README 或说明文件技能目录名与 name 保持一致不一次性导入整个仓库按需复制每周清理一次连续两周没用到就直接移除或归档到备份目录。我用这套方法管理之后技能过期问题基本绝迹。还有一个习惯值得养成新增技能之前先在已有技能里搜一下是否已经有人做过避免重复造轮子。6.5 少走弯路的三个提醒第一不要迷信技能越多越好高频复用的永远就那么几个多而杂不如少而精。第二警惕那些收藏了大量技能却从不更新的仓库这种仓库随着工具版本演进价值会迅速衰减。第三动手之前先确认工具版本很多“装不上”“不生效”的问题最后都指向版本兼容版本永远是最优先排查的变量。我自己的习惯是装技能前看一眼工具版本装完后先跑一条最简单的验证命令通过之后再投入到真实场景。这套流程走下来我的真实体会是Matt Pocock 的方法论精髓不是怎么安装技能包而是逼你重新审视自己每天到底在让 AI 重复干什么活。那些反复用、反复教的部分才是 AI 提效最值得沉淀的资产。从提示词到 Skills本质上是从“临时发挥”走向“工具沉淀”把你脑子里的隐性经验显性化然后再交给 AI 去执行。等你写完三五个专属技能之后会发现 AI 的产出稳定性有一个明显的跃升那才是这类功能最值钱的地方。遇到同一个问题需要教 AI 第三遍的时候不用犹豫把答案固化成技能吧。
