1. 从“skills”这个热词说起它到底是什么为什么突然火了如果你最近在技术社区、AI 工具群或者前端圈子里频繁看到“skills”这个词不用怀疑它确实正在成为 AI 辅助开发领域一个绕不开的概念。但很多人第一次接触时都会懵skills 到底是插件是提示词模板是某种配置文件还是某个平台的专属功能我刚开始也花了点时间才把这件事理清楚这里直接给结论——skills 本质上是一套写给 AI 编程助手看的“技能说明书”它用结构化的方式告诉 AI在什么场景下、按照什么步骤、调用哪些工具、遵守哪些约束去完成一件具体的任务。这个概念的流行和 Claude 系列工具尤其是 Claude Code的普及直接相关。Claude Code 是一个跑在终端里的 AI 编程助手它能读写文件、执行命令、搜索代码库能力很强但默认状态下它对你的项目规范、团队约定、特定领域的操作流程一无所知。你当然可以在每次对话里手动把要求打一遍但那样效率极低而且容易漏。skills 就是为了解决这个问题而出现的把重复性的、有固定套路的任务沉淀成一份可复用的技能描述文件AI 在需要时自动加载并执行。那为什么是现在火我的观察是三个因素叠加。第一AI 编程助手从“聊天玩具”变成了“真正能干活的工具”大家开始认真考虑怎么把它嵌进日常工作流第二社区里涌现出一批高质量的 skills 分享比如前端开发、数学建模、代码审查、文档生成等场景让后来者看到了“原来还能这么用”第三SKILL.md 这种约定俗成的文件格式降低了门槛你不需要写代码用自然语言加少量结构就能定义技能。这三点凑在一起skills 就从一个小众玩法变成了值得系统学习的东西。这篇文章适合谁看如果你是刚接触 Claude Code 或者类似 AI 编程工具的新手想搞清楚 skills 的来龙去脉和基本用法那前面的基础部分会对你有帮助如果你已经在用这类工具但觉得每次都要重复交代背景很烦想把自己的经验沉淀成可复用的技能库那中后段的实操和避坑经验会更对胃口如果你只是好奇“skills 推荐”“常用 skills”这类搜索词背后到底在说什么那通读一遍也能建立起完整的认知框架。我会尽量用从业者之间交流的方式来讲不堆术语该给步骤给步骤该说原理说原理。2. skills 的核心机制拆解SKILL.md 到底写了什么2.1 一个 skill 的最小结构长什么样要理解 skills最直接的方式就是看一个 SKILL.md 文件里到底有什么。虽然不同工具、不同版本的实现细节有差异但核心结构是相通的。一个典型的 skill 通常包含以下几个部分名称和描述用来说明这个技能是干什么的、什么时候该触发适用场景告诉 AI 在什么条件下应该加载这个技能操作步骤这是主体用自然语言或者半结构化的方式描述执行流程约束和注意事项比如哪些操作不能做、哪些参数必须确认示例给出输入输出的样例帮助 AI 理解预期结果。我拿一个前端开发场景来举例。假设你想定义一个“组件代码审查”的 skillSKILL.md 大概会这么写名称叫“react-component-review”描述是“对 React 函数组件进行代码审查检查 hooks 使用规范、props 类型定义、性能隐患和可访问性问题”。适用场景写明“当用户要求审查 .tsx 或 .jsx 文件中的组件代码时触发”。操作步骤分几条先读取目标文件识别组件定义和 hooks 调用然后逐项检查 useState 和 useEffect 的依赖数组是否完整接着检查 props 是否有 TypeScript 类型或 PropTypes 定义再检查是否有不必要的重渲染风险最后按严重程度输出问题列表和修改建议。约束里写清楚“不要自动修改代码只输出审查意见”“如果文件超过 500 行先询问用户是否只审查变更部分”。这个结构看起来简单但里面有几个关键设计点值得说。第一触发条件要明确。如果描述写得太宽泛AI 可能在不需要的时候也加载这个技能浪费上下文窗口写得太窄又可能该用的时候不触发。我的经验是触发条件里最好包含具体的文件类型、用户意图关键词和操作对象。第二步骤要可执行。不要写“检查代码质量”这种模糊的话要拆成“检查 X”“确认 Y”“对比 Z”这种 AI 能一步步照做的动作。第三约束要硬。尤其是涉及文件修改、命令执行、网络请求的操作一定要明确边界否则 AI 可能会做出你意料之外的事情。2.2 skills 和普通提示词的区别在哪里很多人会问我直接在对话里把要求打出来不就行了为什么要费劲写一个 SKILL.md这个问题我一开始也想过实际用下来发现区别主要在三个层面。可复用性是最直观的。你写一次 skill之后所有同类任务都能触发不用每次重新交代背景。比如你团队有一套固定的代码提交规范写成 skill 之后AI 在帮你生成 commit message 时会自动遵守省去了反复提醒的麻烦。一致性是第二个层面。人写提示词会有波动今天记得检查类型定义明天可能就忘了skill 是固化的每次执行都按同样的标准来输出质量更稳定。可组合性是第三个层面也是我觉得最有意思的地方。多个 skill 可以叠加使用比如一个“代码审查”skill 加一个“安全扫描”skillAI 在处理同一个文件时可以同时应用两套规则这种组合能力是手动提示词很难做到的。当然skills 也不是没有代价。写一个高质量的 skill 需要时间而且要对任务本身有足够深的理解否则写出来的步骤是空的。另外skill 加载会占用上下文窗口如果项目里塞了几十个 skillAI 可能反而被干扰。所以我的建议是高频、固定、有明确标准的任务才值得写成 skill一次性或者高度依赖具体上下文的任务直接对话更划算。2.3 不同工具对 skills 的支持差异目前 skills 这个概念并不是某一个工具独有的Claude Code、Codex 以及一些开源 AI 编程工具都在不同程度上支持类似机制。差异主要体现在几个方面文件位置和加载方式有的工具要求 skill 放在项目根目录的特定文件夹下有的支持全局技能库触发机制有的是 AI 自动判断是否加载有的需要手动调用格式严格程度有的要求严格的 YAML front matter有的只要自然语言描述就能识别。以 Claude Code 为例它通常会在项目目录下寻找特定命名的文件或文件夹来识别 skills。社区里常见的做法是在项目根目录建一个.claude/skills/或者类似结构的目录每个 skill 一个子文件夹里面放 SKILL.md。但具体路径和命名规则会随版本变化我踩过的坑是照着半年前的教程建了目录结果新版本改了规则skill 死活不触发。所以一定要以你当前使用的工具版本的官方说明为准社区教程只能参考思路不能照搬路径。Codex 那边的 skills 机制思路类似但在格式和触发逻辑上有自己的特点。如果你同时用多个工具建议把 skill 的内容和工具相关的配置分开管理核心的操作步骤和约束写成通用文档然后针对不同工具做一层适配。这样迁移成本会低很多。3. 手把手实操从零写一个能用的 skill3.1 动手之前先想清楚三件事在打开编辑器写 SKILL.md 之前我强烈建议你先花十分钟把这三个问题想明白否则写出来的 skill 大概率是废的。第一这个任务真的会重复发生吗如果只是偶尔做一次写 skill 的时间成本可能比直接对话还高。判断标准很简单过去一个月里你让 AI 做过几次类似的事如果超过三次就值得沉淀。第二这个任务有明确的成功标准吗skill 的价值在于把“怎么做”固化下来如果连你自己都说不清楚什么算做得好那写出来的步骤也是模糊的。比如“帮我写个好点的文案”就不适合做 skill“按照品牌调性检查文案中的禁用词和语气问题”就适合。第三这个任务需要 AI 调用外部工具或读写文件吗如果涉及文件操作、命令执行、API 调用skill 里必须把这些边界写清楚否则风险很高。我自己的习惯是在笔记软件里维护一个“候选 skill 清单”每次遇到重复性任务就记一笔攒够三次再动手写。这样能确保写出来的 skill 都是真正高频的不会变成一堆没人用的摆设。3.2 写一份 SKILL.md 的完整流程假设我们要写一个“数学建模论文格式检查”的 skill这是社区里搜索量很高的场景。下面是我实际操作的步骤。第一步确定 skill 的名称和触发描述。名称用英文小写加连字符比如math-modeling-format-check。描述要包含关键词方便 AI 匹配比如“检查数学建模竞赛论文的格式规范包括摘要结构、公式编号、图表标题、参考文献格式和页边距要求”。这里的关键是把用户可能说的同义表达都覆盖进去比如“论文格式”“排版检查”“格式规范”这些词都放进去提高触发率。第二步写适用场景和排除条件。适用场景写“当用户要求检查数学建模论文格式、排版或规范时触发”。排除条件也很重要比如“不适用于内容质量审查”“不适用于非竞赛类学术论文”这样能避免 AI 在不该用的时候乱用。第三步拆解操作步骤。这是最花时间的部分。我会先把整个检查流程在脑子里过一遍然后按顺序写下来。比如先读取论文文件识别章节结构然后检查摘要是否包含问题、方法、结果、结论四个要素接着检查公式是否连续编号、编号格式是否统一再检查图表是否有标题、标题位置是否正确然后检查参考文献格式是否符合竞赛要求最后检查页边距、字体、行距等排版参数。每一步都要写清楚检查什么、怎么判断、不符合时怎么记录。第四步补充约束和注意事项。比如“只输出检查报告不自动修改文件”“如果发现格式问题超过 20 处按严重程度排序后只展示前 20 条”“遇到无法判断的情况标记为待确认而不是直接报错”。第五步加示例。给一个输入样例和对应的输出样例让 AI 更清楚预期结果。示例不用太长但要有代表性。写完之后我会实际跑几个测试用例看看触发是否准确、步骤是否可执行、输出是否符合预期。通常第一版都会有各种问题改两三版才能稳定。3.3 让 skill 真正被触发的几个技巧写完 SKILL.md 只是第一步更头疼的是怎么让 AI 在该用的时候用上。我踩过的坑包括skill 写好了但从来不触发、触发了但执行到一半跑偏、多个 skill 同时触发互相干扰。下面这几个技巧是实测有效的。描述里放“用户会说的话”。AI 匹配触发条件时主要看你的描述和用户输入之间的语义相似度。所以描述里要包含用户可能用的口语化表达而不是只写专业术语。比如用户可能说“帮我看看这个论文格式对不对”那描述里就要有“检查论文格式”这样的短语。控制 skill 的数量和粒度。一个项目里不要塞太多 skill我建议控制在 10 个以内每个 skill 的职责尽量单一。如果一个 skill 想管太多事触发会变得不稳定执行也容易乱。宁可拆成两个小 skill也不要写一个巨无霸。用明确的文件路径和命名。不同工具对 skill 文件的存放位置有要求一定要按当前版本文档来。我见过有人把 SKILL.md 放在项目根目录结果工具只扫描特定子目录自然不触发。另外文件名大小写也要注意有的工具区分大小写。测试时用真实场景。不要只测试“完美输入”要试试模糊的、带错别字的、口语化的表达看看 skill 还能不能触发。真实使用中用户的输入往往是不规范的skill 的鲁棒性很重要。4. 高频场景与 skills 推荐哪些方向值得投入4.1 前端开发场景的 skills 实践前端开发是目前 skills 应用最密集的领域之一原因很简单前端任务重复性高、规范多、工具链成熟。我整理了几个实际用下来收益明显的方向。组件代码审查是最常见的。前面已经举过例子核心是检查 hooks 依赖、props 类型、性能隐患和可访问性。这个 skill 的价值在于把团队代码规范固化下来新人提交的代码也能按同样标准审查。样式规范检查也很实用比如检查是否使用了设计系统的 token、是否有硬编码颜色值、响应式断点是否统一。提交信息生成是另一个高频场景根据代码变更自动生成符合团队规范的 commit message省去手动写的麻烦。还有一个我觉得被低估的方向是依赖升级检查。前端项目依赖多、更新快升级时容易出兼容性问题。可以写一个 skill让 AI 在升级某个依赖前先检查项目中所有用到该依赖的地方列出可能受影响的文件和代码片段再给出升级建议。这个 skill 写起来不复杂但能省下大量排查时间。4.2 数学建模与科研场景的 skills 思路数学建模比赛和科研写作是 skills 搜索里的热门方向这也不难理解这类任务流程固定、格式要求严格、时间压力大正好适合用 skill 来提效。论文格式检查前面已经详细讲过。代码复现检查是另一个实用方向数学建模经常需要把论文里的算法用代码实现可以写一个 skill 来检查代码是否完整复现了论文中的公式和步骤有没有遗漏边界条件。图表生成规范也值得做比如统一图表配色、字体、尺寸确保论文里的图表风格一致。参考文献管理可以检查引用格式、去重、补全缺失信息。科研场景里文献综述辅助是一个有争议但确实有用的方向。让 AI 帮你梳理某个方向的文献脉络、提取核心方法和结论、对比不同工作的差异能节省大量阅读时间。但要注意AI 的文献理解能力有限输出只能作为参考不能直接引用。我的做法是把这个 skill 定位为“阅读辅助”而不是“写作替代”输出的是结构化的笔记而不是成稿。4.3 通用效率类 skills 的取舍除了垂直场景还有一些通用效率类的 skills 也值得考虑但要谨慎选择因为太泛的 skill 往往效果不好。文档生成是一个相对靠谱的方向比如根据代码注释自动生成 API 文档、根据变更记录生成发布说明。会议纪要整理也有人做把会议录音转写后让 AI 提取待办事项和决策点但准确率取决于转写质量。邮件草拟可以按场景分类比如客户回复、内部沟通、进度汇报每种场景一个 skill。我不太推荐做的是那种“万能助手”型的 skill比如“帮我处理所有文本任务”。这种 skill 描述太宽泛触发不稳定执行时 AI 也不知道该按什么标准来。skill 的价值在于具体越具体越有用。宁可写十个窄场景的 skill也不要写一个宽泛的。5. 常见问题与排查实录那些教程里不会写的坑5.1 skill 不触发怎么办这是最高频的问题。我遇到过的原因大概有这么几类文件位置不对工具根本没扫描到描述关键词不匹配用户输入和 skill 描述之间语义差距太大格式有误比如 YAML front matter 写错了导致解析失败skill 数量太多AI 在加载时做了取舍优先级低的被跳过了。排查顺序建议这样先确认文件路径和命名是否符合当前工具版本的要求这一步能解决大部分问题然后检查描述里是否包含了用户实际会说的关键词可以手动把用户输入和描述做对比接着看格式有没有语法错误特别是缩进和特殊字符最后如果 skill 确实很多试着临时移除一些看目标 skill 是否能触发。还有一个隐蔽的坑是上下文窗口限制。如果项目很大、对话很长AI 可能没有足够的上下文空间来加载 skill。这种情况下要么精简 skill 内容要么在对话开始时手动提示 AI 加载特定 skill。5.2 skill 执行到一半跑偏怎么处理触发成功但执行跑偏通常是因为步骤写得太模糊或者约束不够硬。比如你写“检查代码质量”AI 可能只检查了格式就结束了你写“修改文件”AI 可能改了你没预期的地方。解决办法是把步骤拆到不能再拆每一步都是一个明确的动作有明确的输入和输出。约束要写成硬性规则比如“禁止修改任何文件”“如果发现超过 10 个问题先输出摘要再询问是否展开”。另外可以在 skill 里加一个“执行前确认”步骤让 AI 在开始前先复述一遍它打算怎么做你确认后再继续。这个习惯能避免很多意外。5.3 多个 skill 冲突怎么协调当项目里有多个 skill 时可能会出现同时触发或者互相干扰的情况。比如一个“代码审查”skill 和一个“代码格式化”skill 同时作用于一个文件AI 可能不知道该先执行哪个。我的处理方式是给 skill 分优先级和适用范围。在描述里写清楚“本 skill 应在格式化完成后执行”或者“本 skill 仅适用于 .tsx 文件”。另外可以把相关的 skill 组织成一个工作流用一个上层 skill 来编排执行顺序而不是让它们各自为政。如果两个 skill 确实功能重叠那就合并成一个不要留着互相打架。5.4 常见问题速查表问题现象可能原因排查动作解决方向skill 完全不触发文件位置或命名错误对照当前版本文档检查路径移动到正确目录修正命名偶尔触发偶尔不触发描述关键词覆盖不足对比用户输入和描述文本补充同义表达和口语化短语触发后执行不完整步骤描述太模糊检查步骤是否可逐步执行拆解步骤增加明确动作执行结果不符合预期约束条件不够硬检查是否有禁止性规则增加硬性约束和确认环节多个 skill 互相干扰适用范围重叠列出所有 skill 的触发条件分优先级合并重叠项加载后 AI 响应变慢上下文占用过多统计 skill 总字数精简内容移除低频 skill6. 把 skills 用好的几个底层习惯6.1 像维护代码一样维护 skillskill 不是写完就完了它需要持续维护。我的做法是把 skill 当成项目代码的一部分放在版本控制里每次修改都记录变更原因。当团队规范更新时同步更新对应的 skill当发现某个 skill 经常出问题时及时重构而不是将就。另外定期清理也很重要。我每季度会过一遍所有 skill把过去三个月没触发过的删掉或者归档。skill 库不是越大越好保持精简才能让每个 skill 都保持高质量。6.2 从“写 skill”到“设计工作流”单个 skill 解决的是单点问题但真正提升效率的是把多个 skill 串成工作流。比如一个完整的前端开发流程可能包括需求分析 skill、组件设计 skill、代码实现 skill、代码审查 skill、测试生成 skill、提交信息生成 skill。每个 skill 各司其职按顺序执行形成一条流水线。设计工作流时要注意交接点。上一个 skill 的输出要能作为下一个 skill 的输入格式要统一。比如代码审查 skill 输出的问题列表要能被修复 skill 直接读取和处理。这需要在写 skill 时就考虑好数据格式和接口约定。6.3 保持对工具变化的敏感AI 编程工具迭代很快skills 的机制、格式、触发逻辑都可能变。我踩过的最大的坑就是照着旧教程配置结果新版本不兼容。所以建议关注你所使用工具的官方更新日志每次大版本更新后抽时间测试一下现有 skill 是否还能正常工作。社区里的 skills 分享也值得关注但要有判断力。别人分享的 skill 是基于他们的项目和工作流写的直接拿来用往往水土不服。正确的做法是理解它的设计思路然后根据自己的实际情况改写。抄思路不抄内容这是我用下来最稳的策略。6.4 一个实际案例的完整复盘最后分享一个我实际做的 skill 案例把前面的要点串起来。背景是团队里经常需要把设计稿转成前端代码每次都要跟 AI 反复交代设计规范、组件库用法、命名约定。于是我写了一个design-to-codeskill。描述里写了“根据设计稿描述生成 React 组件代码遵循团队组件库和命名规范”。适用场景限定为“当用户提供设计稿截图或描述并要求生成组件代码时”。步骤分五步先识别设计稿中的组件类型和布局结构然后映射到团队组件库中的对应组件接着生成代码骨架包括 imports、组件定义、props 类型再填充样式使用设计系统 token 而不是硬编码值最后输出代码并附上使用的组件和 token 清单。约束包括“不生成测试代码”“如果设计稿中有组件库没有的元素先询问而不是自行创造”“生成的代码必须通过 ESLint 检查”。实际用下来这个 skill 把设计稿转代码的时间从平均 40 分钟压缩到了 10 分钟左右而且代码风格统一审查成本大幅降低。当然也遇到过问题比如设计稿里的间距值不在设计系统 token 里AI 会卡住。后来在约束里加了一条“遇到无法映射的值时使用最接近的 token 并标注差异”问题就解决了。这个案例说明skill 的价值不在于写得多漂亮而在于真正嵌入工作流、解决具体问题、并且能持续迭代。你不需要一开始就写得很完美先跑起来遇到问题再改迭代几轮之后自然会稳定。如果你还没开始用 skills我的建议是从一个最小场景入手比如“提交信息生成”或者“代码格式检查”写一个最简单的版本跑通整个流程感受一下触发、执行、输出的完整链路。有了体感之后再逐步扩展到更复杂的场景。这个过程本身也是对你工作流的一次梳理哪些环节可以标准化、哪些环节需要人工判断想清楚这些比写多少个 skill 都重要。