这类工具最值得关注的不是“又多了一个新目录”而是它把过去靠复制粘贴的长提示词变成了一种可以安装、共享、版本管理的“技能包”。Anthropic Skills 以及围绕 anthropics/skills 展开的社区生态正在解决一个很实际的问题让 Claude 这样的模型在具体任务里不再每次都要重新理解你的工作方式而是直接调用一个预先定义好的技能文件。如果你正在用 Claude Code、前端开发、文档自动化、批量测试或者只是觉得提示词越来越长却越来越难维护那这部分内容应该能帮上忙。我个人的建议是先别看太多概念先跑通一个现成技能再拆开看它内部怎么写最后再考虑自己开发。下面按这个实际顺序来写。1. 先搞清楚 Skills 到底是什么1.1 从一段长提示词到可复用技能过去让模型处理一个任务最常见的方式是写一段提示词比如“你是一个前端开发助手请按照项目规范生成组件注意使用 TypeScript样式用 CSS Modules。”“请帮我分析这份 PDF 报告提取关键指标并按表格输出。”这种方式在小任务里没问题但一旦任务变复杂提示词会越来越长而且换一个项目就失效。更麻烦的是同一个任务换个环境又要重新写一遍。Skills 的思路不一样它把任务描述、执行步骤、脚本、输入输出格式、注意事项全部打包到一个固定目录里。模型看到这个技能之后会按照技能文件里的说明去执行而不是靠临场推断。这里的核心变化是提示词从“一次性输入”变成了“可装配的模块”。你可以把一个技能理解为一个“岗位说明书 工具箱”。模型是员工技能是它需要遵守的工作手册和可调用的脚本。1.2 它和 MCP、插件、Prompt 有什么区别很多人会拿 Skills 和 MCP、插件、Prompt 做对比。我不打算讲太细只说结论。Prompt 是最底层的能力本质上是一个文本输入。它的问题是缺少确定性模型每次都可能跑偏。MCP 解决的是“模型怎么连外部工具和数据”比如读取数据库、调用 API、访问文件系统。它更像是一套协议让模型和外部世界对话。插件通常是一种更重的集成往往带界面、生命周期和框架绑定比如编辑器插件。Skills 的位置比较巧。它不强行接管工具连接也不需要复杂框架它先是“一套结构化的提示词”然后可以附带脚本和工具调用建议。里面可以声明“处理这个任务时先用这个脚本检查输入再调用那个命令生成结果”。这样既保留了灵活性又比纯提示词更可控。所以如果你已经在用 MCP那 Skills 不会和它冲突更多是互补。你可以在技能里说明“这个步骤通过 MCP 工具执行”也可以让技能在本地跑一个 Python 脚本。1.3 为什么社区里突然这么多 skills 项目从目前趋势看Skills 之所以流行主要因为三个点门槛低写一个技能本质上就是写 Markdown 文件加几个脚本不需要完整插件工程。可共享一个技能目录直接复制给同事或者推到 GitHub别人拉下来就能用。更适配实际项目不同项目可以挂不同的技能集前端项目挂前端技能数据分析项目挂数据技能互不干扰。于是社区里出现了各种 skills 集合比如把文档编辑、PPT 生成、前端审查、学术研究、测试流程都封装成技能包。这个生态还会继续膨胀大概率会出现更多垂直领域的技能库。2. 装 Skills 之前确认环境和目录2.1 目前主流承载方式Skills 不是一个独立软件它需要被某个 Agent 环境加载。目前常见的方式有这么几类Claude Code在命令行里用天然支持技能目录。Claude 桌面端或网页端部分入口支持自定义技能。第三方编辑器或工具像 opencode 这类 AI 编码工具也开始支持 skills 目录。自建脚本如果你的项目里有自己的 Agent 编排也可以按同样的目录规范加载。不同的承载方式目录位置可能不一样。但绝大多数实现的共同逻辑是扫描指定的 skills 目录读取每个子目录里的描述文件然后把技能注册到模型可用的上下文里。2.2 目录结构和权限先不要急着写技能先看目录结构。最常见的位置是~/.claude/skills或者项目根目录下的.claude/skills。我一般会先检查这个目录是否存在ls -la ~/.claude/skills如果不存在手动创建mkdir -p ~/.claude/skills权限方面要特别注意。技能目录可能包含脚本如果权限配置不对脚本可能无法执行。尤其是在 Linux 或 macOS 环境记得给脚本加执行权限chmod x ~/.claude/skills/my-skill/scripts/run.sh如果是 Windows更常见的问题不是权限而是路径分隔符和编码。比如 SKILL.md 文件如果是 UTF-8 编码但带 BOM某些解析器可能会出现识别异常。建议直接保存成 UTF-8 无 BOM并且路径统一用小写加连字符。2.3 安装一个现成 Skills 的通用流程社区里的技能包通常就是一个目录。你从 GitHub 克隆或者下载下来之后把它放到 skills 目录里就可以了。不要把它压缩包原样放进去要先解压确认里面有 SKILL.md 这样的入口文件。cd ~/.claude/skills git clone https://github.com/example/some-skill.git装完之后不要直接跑到正式项目里用。先看这个目录里有没有 README 或安装脚本很多技能会要求安装 Python 依赖、Node 依赖或者外部命令行工具。cd some-skill pip install -r requirements.txt这里的要点是安装技能不是把文件复制进去就完事还要满足它的运行时依赖。很多技能看起来能用但一执行就报错原因往往不是技能本身有问题而是依赖没有装全。注意先跑通一个最小样例再放到真实项目里使用。不要一上来就同时安装十几个技能出了问题很难定位是哪个技能引起的。3. 推荐先试的几类现成 Skills3.1 文档处理类PPT、PDF、Word、Excel这类技能对大多数人都实用。以前让模型生成 PPT它只能给出文字大纲不能直接生成可编辑的 .pptx 文件。有了文档处理类技能之后模型可以调用脚本把内容结构转换成真正的文件。使用时的关键参数是输入输出格式和文件命名。我建议每次生成前先确认三件事输入内容是什么格式是 Markdown 大纲还是带结构的 JSON还是直接给一段自然语言输出文件要放在哪个目录技能默认可能写到当前目录也可能写到输出子目录。模板要求是使用默认模板还是指定公司模板路径。实际测试时最好先用一个简单输入跑一遍然后打开生成的文件检查内容和格式。重点看字体是否乱码、页面是否溢出、表格是否错位。如果发现问题先看技能脚本里的日志再调整输入结构。3.2 前端开发和网页检查类前端 skills 在社区里非常热门主要覆盖几个场景根据设计图或描述生成 React/Vue 组件。检查页面样式、可访问性、响应式布局。分析页面源码并给出优化建议。自动生成测试用例。安装这类技能后实际效果差异很大。原因在于前端组件生成强依赖上下文。如果你的技能文件里只写了“生成一个按钮组件”那和直接写提示词没太大区别。好的技能文件会要求你先提供项目技术栈、组件接口、样式约定、已有代码位置然后再生成。我用的时候会先跑一次“只读任务”比如让技能分析现有组件代码输出一份组件结构和问题列表。确认它能正确读取项目文件之后再让它生成新代码。不要上来就让它重写整个页面成本高而且容易破坏现有实现。3.3 学术研究和信息整理类学术研究类技能主要是帮你在本地完成资料整理、引用格式处理、文献笔记结构化。它和搜索引擎类工具有点像但更像是“研究流程的助理”。使用这类技能时要提前想清楚研究问题的边界。比如是让模型总结文章还是让它按特定维度提取信息输出格式是表格、Markdown 还是学术引用格式是否要求保留原文句子还是允许改写我见过很多翻车案例都是因为输入材料没有清洗干净。比如 PDF 文字层缺失模型只能看到图片输出自然不完整。这种情况下不是技能不好而是输入本身有问题。先确认 PDF 能否复制文字再跑技能。3.4 测试类技能从自动检查到报告生成测试相关的 skills 也很有意思。它不只是让模型写单测代码还可以把一套测试流程固定下来收集代码变更、分析影响范围、生成测试用例、执行测试、输出报告。我会建议这样起步先让技能读取一个小的代码目录输出测试计划。检查测试计划是否覆盖关键分支。确认无误后再让技能生成测试文件并执行。最后让技能根据测试结果生成一份报告。这里的核心参数是测试范围、执行命令、超时时间、失败重试次数。批量测试时尤其要注意模型生成的大量测试文件可能互相影响比如共享的 fixture 被修改、端口冲突、测试数据污染。不要一味追求生成数量先保证测试隔离性。4. 自己动手开发一个 Skills4.1 最小技能样例自己开发一个技能并没有想象中复杂。它最少只需要一个目录和一个 SKILL.md 文件。~/.claude/skills/ greeting-skill/ SKILL.mdSKILL.md 里可以写--- name: greeting_skill description: 当用户需要打招呼或者生成问候语时使用。 --- # Greeting Skill 这个技能用来生成简洁友好的问候语。 ## 使用步骤 1. 确认用户希望问候的场景。 2. 根据场景生成 3 条问候语。 3. 输出前检查语气是否合适。这不是一个完整的生产技能但它能跑通整个流程。把目录放到 skills 目录后在 Agent 环境里输入相关任务看它是否调用这个技能。如果调用了说明最小闭环没问题。4.2 SKILL.md 该怎么写写 SKILL.md 的时候最重要的不是格式多漂亮而是能不能让模型准确判断“什么时候该用这个技能”。name 要简短最好和任务强相关。description 是模型判断的关键里面要写清楚触发条件、适用输入、不使用这个技能的情况。正文部分我建议包含这几块背景或目标这个技能为什么存在。输入要求需要哪些信息怎么获取。执行步骤按顺序列出避免模型自行发挥。输出格式文件类型、目录、命名规则。检查清单完成之后要检查哪些点。常见错误历史踩坑比如“不要覆盖已有文件”“不要使用 esbuild 而是使用 swc”。写完后要自己测试几轮。特别是 description 不要写得太大比如“写代码的时候用”模型会不知道什么时候触发。更好的写法是“当用户要求生成 React 函数组件的测试文件时使用”。4.3 脚本参数和输入输出约定如果你的技能要执行脚本建议把输入输出约定写得非常明确。比如脚本scripts/process.py接收一个输入文件路径和一个输出目录路径。python scripts/process.py input.json output/脚本内部需要做好路径校验。如果输入文件不存在不能默默生成空结果而是返回明确错误码并打印原因。输出文件最好统一使用技能自己的命名规范比如加前缀skillname_防止和用户文件冲突。还要考虑一个问题模型执行命令时不一定记得所有参数。所以技能文件里最好写清楚“推荐命令”和“参数含义”。比如## 执行 使用以下命令 bash python scripts/process.py input output_dirinput待处理文件路径支持 .md 或 .json。output_dir输出目录必须存在。这样模型照着做而不是自己拼接命令。 ### 4.4 本地调试和版本管理 开发技能时最忌讳一直放到模型环境里反复试错。更高效的方式是把脚本从技能环境里抽出来先在命令行单独测试。 比如先手动构造一个输入文件然后执行脚本看输出是否符合预期。脚本跑通了再把技能目录放回去用自然语言让模型调用技能测试整体效果。 技能也要做版本管理。我会把技能目录单独放到一个 Git 仓库里每次改动都要提交并且写清楚 CHANGELOG。这样如果新版本效果变差可以回滚到旧版本。 技能目录内部不建议塞大量无关文件只保留 SKILL.md、脚本、配置、示例输入。 ## 5. 批量使用和项目级 Skill 管理 ### 5.1 项目级 skills 与用户级 skills 用户级 skills 在 ~/.claude/skills所有项目都能用。项目级 skills 一般放在 .claude/skills只在当前项目里生效。 我的建议是通用能力放用户级比如 PPT 生成、PDF 转 Markdown。项目特定能力放项目级比如某个线上商城的前端开发规范、某个算法的测试流程。 这样做的原因是避免技能污染。如果用户级目录安装了太多技能模型每次加载所有技能描述会增加不必要的上下文。技能数量过多时模型反而可能选错技能。 ### 5.2 多个 Skill 之间的依赖和冲突 当技能数量变多需要开始考虑依赖。比如一个技能需要 Python 3.10另一个技能需要 Python 3.8如果两个技能都在同一环境里跑很可能冲突。 解决思路有两种 1. 用虚拟环境隔离技能依赖比如每个技能一个虚拟环境。 2. 在技能文件里明确声明运行环境并在执行前做版本检查。 冲突更常见的是文件路径和端口。几个技能如果都往同一个临时目录写文件或者都尝试用同一个端口起服务就会相互干扰。建议每个技能使用独立的临时目录脚本里设置唯一的前缀或命名空间。 如果你要在同一个项目里同时使用多个技能先做一次“技能矩阵”检查列出每个技能的输入、输出、运行环境、文件前缀看看有没有重叠。 ### 5.3 在公司或团队中共享 团队共享 skills 时不能只把目录发给同事还要有统一的管理方式。常见做法是 - 建一个独立的技能仓库按目录分类组织。 - 在 README 里写明每个技能的环境要求和使用示例。 - 用 Git Tag 管理版本。 - 内部写一个安装脚本自动拉取最新版本。 如果你的团队规模更大可以考虑做技能市场或内部索引页面让同事可以搜索技能。但这个适合技能数量超过几十个之后再考虑初期没有必要。 我更推荐先整理一个“技能清单”表格字段包括技能名、用途、负责人、状态、依赖、维护频率。这个表格比任何复杂系统都实用。 ## 6. 常见报错和排查链路 ### 6.1 技能没有被识别 最典型的错误信号是模型完全没调用技能而是直接用普通对话回答。 拿到这个问题先按顺序排查 1. 技能目录位置是否正确。用户级还是项目级别放错。 2. SKILL.md 是否存在文件名大小写是否一致。 3. frontmatter 里的 name 和 description 是否正确description 是否足够触发。 4. 技能加载命令是否执行过有的环境需要重启。 5. 是否存在语法错误比如 YAML 解析失败。 很多情况下问题不是技能文件有问题而是 description 写得不够具体。模型很难判断当前任务和这个技能相关。可以换个说法把触发词写得直接一些比如“当用户提到 PPT 时使用”。 ### 6.2 技能被识别但脚本执行报错 这个问题出现在“技能被调用但执行失败”。先看完整错误日志确认是哪一步失败。 可能的方向 - 路径问题脚本找不到输入文件或输出目录。 - 依赖问题Python 包、Node 模块没有安装。 - 权限问题脚本没有执行权限或者没有写权限。 - 环境差异本地能跑但 Agent 执行环境缺少某些环境变量。 我一般会把 Agent 执行命令和手动执行命令对比看是不是参数不一致。如果手动执行成功、Agent 执行失败问题通常在参数或当前工作目录上。 ### 6.3 输出质量不符合预期 技能跑通但结果质量不高这是最难排查的情况。需要拆开看 - 是不是输入数据不够完整 - 是不是技能文件里的步骤描述太模糊 - 是不是模型没有严格按照检查清单执行 - 是不是输出后处理脚本不够 你可以先让模型把执行过程日志输出看它在关键节点的判断。如果模型跳过某个步骤那就是技能文件里的指令不够明确。 ### 6.4 资源占用和超时 技能如果处理大文件或批量任务要考虑时间和资源。一个技能处理 1MB 文件和处理 100MB 文件的耗时可能差几十倍。 建议在技能文件里写上预期耗时和资源上限。比如 - “本技能最多处理 1000 行输入超过后建议分批。” - “执行期间可能需要 2GB 内存请提前确认机器配置。” - “单个文件处理时间通常在 30 秒以内。” 如果超时先看是不是任务太大。不是所有技能都适合处理超大输入可以考虑先拆分任务。 注意低配置机器能跑通一个技能不代表它能跑通批量任务。批量使用前先测一两个任务观察内存和磁盘占用。 ## 7. 适用边界和个人建议 ### 7.1 适合什么场景 从我实际使用的感受来看Skills 最适合这三种场景 1. 重复性高且有固定流程的任务比如周报生成、测试计划输出、文档规范检查。 2. 需要调用本地脚本和外部工具的复杂任务比如生成 PPTX 后还要转 PDF。 3. 需要多人共享工作方式的任务比如团队统一的前端代码审查标准。 如果你正在做的任务每次都需要很长的提示词而且换个人就做不好那很适合把它变成技能。 ### 7.2 不适合什么场景 Skills 不适合特别灵动、开放的研究型任务。它更像“操作手册”如果你希望模型完全自由发挥技能反而会限制它。比如“帮我写一篇创意小说”这种任务不适合定义太多步骤。 另外如果你的任务特别依赖实时数据、私有系统或者复杂鉴权Skills 单独也解决不了。这种场景应该考虑 MCP 工具或更完整的服务编排。 不要在项目的早期阶段过度设计技能。项目还在频繁改需求时技能的维护成本会很高。等流程稳定再沉淀成技能。 ### 7.3 我的建议顺序 如果你刚接触这块我比较推荐这样的顺序 1. 先手动完成一次任务记录下完整的处理步骤。 2. 把步骤拆成输入、处理、输出三个阶段。 3. 建一个最小技能把步骤写进 SKILL.md。 4. 用真实数据测试观察模型哪些步骤执行得好、哪些跑偏。 5. 针对跑偏的部分补脚本和检查清单。 6. 稳定后再考虑共享和版本管理。 不要第一步就跟着社区项目装一堆热门技能。先把自己的常用任务沉淀成一个最小技能理解整个过程再去参考别人的优秀实现。这样你才能真正判断一个技能写得好不好而不是完全照搬。 落到最后我还是那句把单任务跑稳再谈批量和生态。Skills 的真正价值不是让你一次性生成一堆杂乱输出而是让每次输出都能复现、检查和改进。这一点在任何工具生态里都是最重要的。 Anthropic Skills实战指南：从提示词到可复用技能包
这类工具最值得关注的不是“又多了一个新目录”而是它把过去靠复制粘贴的长提示词变成了一种可以安装、共享、版本管理的“技能包”。Anthropic Skills 以及围绕 anthropics/skills 展开的社区生态正在解决一个很实际的问题让 Claude 这样的模型在具体任务里不再每次都要重新理解你的工作方式而是直接调用一个预先定义好的技能文件。如果你正在用 Claude Code、前端开发、文档自动化、批量测试或者只是觉得提示词越来越长却越来越难维护那这部分内容应该能帮上忙。我个人的建议是先别看太多概念先跑通一个现成技能再拆开看它内部怎么写最后再考虑自己开发。下面按这个实际顺序来写。1. 先搞清楚 Skills 到底是什么1.1 从一段长提示词到可复用技能过去让模型处理一个任务最常见的方式是写一段提示词比如“你是一个前端开发助手请按照项目规范生成组件注意使用 TypeScript样式用 CSS Modules。”“请帮我分析这份 PDF 报告提取关键指标并按表格输出。”这种方式在小任务里没问题但一旦任务变复杂提示词会越来越长而且换一个项目就失效。更麻烦的是同一个任务换个环境又要重新写一遍。Skills 的思路不一样它把任务描述、执行步骤、脚本、输入输出格式、注意事项全部打包到一个固定目录里。模型看到这个技能之后会按照技能文件里的说明去执行而不是靠临场推断。这里的核心变化是提示词从“一次性输入”变成了“可装配的模块”。你可以把一个技能理解为一个“岗位说明书 工具箱”。模型是员工技能是它需要遵守的工作手册和可调用的脚本。1.2 它和 MCP、插件、Prompt 有什么区别很多人会拿 Skills 和 MCP、插件、Prompt 做对比。我不打算讲太细只说结论。Prompt 是最底层的能力本质上是一个文本输入。它的问题是缺少确定性模型每次都可能跑偏。MCP 解决的是“模型怎么连外部工具和数据”比如读取数据库、调用 API、访问文件系统。它更像是一套协议让模型和外部世界对话。插件通常是一种更重的集成往往带界面、生命周期和框架绑定比如编辑器插件。Skills 的位置比较巧。它不强行接管工具连接也不需要复杂框架它先是“一套结构化的提示词”然后可以附带脚本和工具调用建议。里面可以声明“处理这个任务时先用这个脚本检查输入再调用那个命令生成结果”。这样既保留了灵活性又比纯提示词更可控。所以如果你已经在用 MCP那 Skills 不会和它冲突更多是互补。你可以在技能里说明“这个步骤通过 MCP 工具执行”也可以让技能在本地跑一个 Python 脚本。1.3 为什么社区里突然这么多 skills 项目从目前趋势看Skills 之所以流行主要因为三个点门槛低写一个技能本质上就是写 Markdown 文件加几个脚本不需要完整插件工程。可共享一个技能目录直接复制给同事或者推到 GitHub别人拉下来就能用。更适配实际项目不同项目可以挂不同的技能集前端项目挂前端技能数据分析项目挂数据技能互不干扰。于是社区里出现了各种 skills 集合比如把文档编辑、PPT 生成、前端审查、学术研究、测试流程都封装成技能包。这个生态还会继续膨胀大概率会出现更多垂直领域的技能库。2. 装 Skills 之前确认环境和目录2.1 目前主流承载方式Skills 不是一个独立软件它需要被某个 Agent 环境加载。目前常见的方式有这么几类Claude Code在命令行里用天然支持技能目录。Claude 桌面端或网页端部分入口支持自定义技能。第三方编辑器或工具像 opencode 这类 AI 编码工具也开始支持 skills 目录。自建脚本如果你的项目里有自己的 Agent 编排也可以按同样的目录规范加载。不同的承载方式目录位置可能不一样。但绝大多数实现的共同逻辑是扫描指定的 skills 目录读取每个子目录里的描述文件然后把技能注册到模型可用的上下文里。2.2 目录结构和权限先不要急着写技能先看目录结构。最常见的位置是~/.claude/skills或者项目根目录下的.claude/skills。我一般会先检查这个目录是否存在ls -la ~/.claude/skills如果不存在手动创建mkdir -p ~/.claude/skills权限方面要特别注意。技能目录可能包含脚本如果权限配置不对脚本可能无法执行。尤其是在 Linux 或 macOS 环境记得给脚本加执行权限chmod x ~/.claude/skills/my-skill/scripts/run.sh如果是 Windows更常见的问题不是权限而是路径分隔符和编码。比如 SKILL.md 文件如果是 UTF-8 编码但带 BOM某些解析器可能会出现识别异常。建议直接保存成 UTF-8 无 BOM并且路径统一用小写加连字符。2.3 安装一个现成 Skills 的通用流程社区里的技能包通常就是一个目录。你从 GitHub 克隆或者下载下来之后把它放到 skills 目录里就可以了。不要把它压缩包原样放进去要先解压确认里面有 SKILL.md 这样的入口文件。cd ~/.claude/skills git clone https://github.com/example/some-skill.git装完之后不要直接跑到正式项目里用。先看这个目录里有没有 README 或安装脚本很多技能会要求安装 Python 依赖、Node 依赖或者外部命令行工具。cd some-skill pip install -r requirements.txt这里的要点是安装技能不是把文件复制进去就完事还要满足它的运行时依赖。很多技能看起来能用但一执行就报错原因往往不是技能本身有问题而是依赖没有装全。注意先跑通一个最小样例再放到真实项目里使用。不要一上来就同时安装十几个技能出了问题很难定位是哪个技能引起的。3. 推荐先试的几类现成 Skills3.1 文档处理类PPT、PDF、Word、Excel这类技能对大多数人都实用。以前让模型生成 PPT它只能给出文字大纲不能直接生成可编辑的 .pptx 文件。有了文档处理类技能之后模型可以调用脚本把内容结构转换成真正的文件。使用时的关键参数是输入输出格式和文件命名。我建议每次生成前先确认三件事输入内容是什么格式是 Markdown 大纲还是带结构的 JSON还是直接给一段自然语言输出文件要放在哪个目录技能默认可能写到当前目录也可能写到输出子目录。模板要求是使用默认模板还是指定公司模板路径。实际测试时最好先用一个简单输入跑一遍然后打开生成的文件检查内容和格式。重点看字体是否乱码、页面是否溢出、表格是否错位。如果发现问题先看技能脚本里的日志再调整输入结构。3.2 前端开发和网页检查类前端 skills 在社区里非常热门主要覆盖几个场景根据设计图或描述生成 React/Vue 组件。检查页面样式、可访问性、响应式布局。分析页面源码并给出优化建议。自动生成测试用例。安装这类技能后实际效果差异很大。原因在于前端组件生成强依赖上下文。如果你的技能文件里只写了“生成一个按钮组件”那和直接写提示词没太大区别。好的技能文件会要求你先提供项目技术栈、组件接口、样式约定、已有代码位置然后再生成。我用的时候会先跑一次“只读任务”比如让技能分析现有组件代码输出一份组件结构和问题列表。确认它能正确读取项目文件之后再让它生成新代码。不要上来就让它重写整个页面成本高而且容易破坏现有实现。3.3 学术研究和信息整理类学术研究类技能主要是帮你在本地完成资料整理、引用格式处理、文献笔记结构化。它和搜索引擎类工具有点像但更像是“研究流程的助理”。使用这类技能时要提前想清楚研究问题的边界。比如是让模型总结文章还是让它按特定维度提取信息输出格式是表格、Markdown 还是学术引用格式是否要求保留原文句子还是允许改写我见过很多翻车案例都是因为输入材料没有清洗干净。比如 PDF 文字层缺失模型只能看到图片输出自然不完整。这种情况下不是技能不好而是输入本身有问题。先确认 PDF 能否复制文字再跑技能。3.4 测试类技能从自动检查到报告生成测试相关的 skills 也很有意思。它不只是让模型写单测代码还可以把一套测试流程固定下来收集代码变更、分析影响范围、生成测试用例、执行测试、输出报告。我会建议这样起步先让技能读取一个小的代码目录输出测试计划。检查测试计划是否覆盖关键分支。确认无误后再让技能生成测试文件并执行。最后让技能根据测试结果生成一份报告。这里的核心参数是测试范围、执行命令、超时时间、失败重试次数。批量测试时尤其要注意模型生成的大量测试文件可能互相影响比如共享的 fixture 被修改、端口冲突、测试数据污染。不要一味追求生成数量先保证测试隔离性。4. 自己动手开发一个 Skills4.1 最小技能样例自己开发一个技能并没有想象中复杂。它最少只需要一个目录和一个 SKILL.md 文件。~/.claude/skills/ greeting-skill/ SKILL.mdSKILL.md 里可以写--- name: greeting_skill description: 当用户需要打招呼或者生成问候语时使用。 --- # Greeting Skill 这个技能用来生成简洁友好的问候语。 ## 使用步骤 1. 确认用户希望问候的场景。 2. 根据场景生成 3 条问候语。 3. 输出前检查语气是否合适。这不是一个完整的生产技能但它能跑通整个流程。把目录放到 skills 目录后在 Agent 环境里输入相关任务看它是否调用这个技能。如果调用了说明最小闭环没问题。4.2 SKILL.md 该怎么写写 SKILL.md 的时候最重要的不是格式多漂亮而是能不能让模型准确判断“什么时候该用这个技能”。name 要简短最好和任务强相关。description 是模型判断的关键里面要写清楚触发条件、适用输入、不使用这个技能的情况。正文部分我建议包含这几块背景或目标这个技能为什么存在。输入要求需要哪些信息怎么获取。执行步骤按顺序列出避免模型自行发挥。输出格式文件类型、目录、命名规则。检查清单完成之后要检查哪些点。常见错误历史踩坑比如“不要覆盖已有文件”“不要使用 esbuild 而是使用 swc”。写完后要自己测试几轮。特别是 description 不要写得太大比如“写代码的时候用”模型会不知道什么时候触发。更好的写法是“当用户要求生成 React 函数组件的测试文件时使用”。4.3 脚本参数和输入输出约定如果你的技能要执行脚本建议把输入输出约定写得非常明确。比如脚本scripts/process.py接收一个输入文件路径和一个输出目录路径。python scripts/process.py input.json output/脚本内部需要做好路径校验。如果输入文件不存在不能默默生成空结果而是返回明确错误码并打印原因。输出文件最好统一使用技能自己的命名规范比如加前缀skillname_防止和用户文件冲突。还要考虑一个问题模型执行命令时不一定记得所有参数。所以技能文件里最好写清楚“推荐命令”和“参数含义”。比如## 执行 使用以下命令 bash python scripts/process.py input output_dirinput待处理文件路径支持 .md 或 .json。output_dir输出目录必须存在。这样模型照着做而不是自己拼接命令。 ### 4.4 本地调试和版本管理 开发技能时最忌讳一直放到模型环境里反复试错。更高效的方式是把脚本从技能环境里抽出来先在命令行单独测试。 比如先手动构造一个输入文件然后执行脚本看输出是否符合预期。脚本跑通了再把技能目录放回去用自然语言让模型调用技能测试整体效果。 技能也要做版本管理。我会把技能目录单独放到一个 Git 仓库里每次改动都要提交并且写清楚 CHANGELOG。这样如果新版本效果变差可以回滚到旧版本。 技能目录内部不建议塞大量无关文件只保留 SKILL.md、脚本、配置、示例输入。 ## 5. 批量使用和项目级 Skill 管理 ### 5.1 项目级 skills 与用户级 skills 用户级 skills 在 ~/.claude/skills所有项目都能用。项目级 skills 一般放在 .claude/skills只在当前项目里生效。 我的建议是通用能力放用户级比如 PPT 生成、PDF 转 Markdown。项目特定能力放项目级比如某个线上商城的前端开发规范、某个算法的测试流程。 这样做的原因是避免技能污染。如果用户级目录安装了太多技能模型每次加载所有技能描述会增加不必要的上下文。技能数量过多时模型反而可能选错技能。 ### 5.2 多个 Skill 之间的依赖和冲突 当技能数量变多需要开始考虑依赖。比如一个技能需要 Python 3.10另一个技能需要 Python 3.8如果两个技能都在同一环境里跑很可能冲突。 解决思路有两种 1. 用虚拟环境隔离技能依赖比如每个技能一个虚拟环境。 2. 在技能文件里明确声明运行环境并在执行前做版本检查。 冲突更常见的是文件路径和端口。几个技能如果都往同一个临时目录写文件或者都尝试用同一个端口起服务就会相互干扰。建议每个技能使用独立的临时目录脚本里设置唯一的前缀或命名空间。 如果你要在同一个项目里同时使用多个技能先做一次“技能矩阵”检查列出每个技能的输入、输出、运行环境、文件前缀看看有没有重叠。 ### 5.3 在公司或团队中共享 团队共享 skills 时不能只把目录发给同事还要有统一的管理方式。常见做法是 - 建一个独立的技能仓库按目录分类组织。 - 在 README 里写明每个技能的环境要求和使用示例。 - 用 Git Tag 管理版本。 - 内部写一个安装脚本自动拉取最新版本。 如果你的团队规模更大可以考虑做技能市场或内部索引页面让同事可以搜索技能。但这个适合技能数量超过几十个之后再考虑初期没有必要。 我更推荐先整理一个“技能清单”表格字段包括技能名、用途、负责人、状态、依赖、维护频率。这个表格比任何复杂系统都实用。 ## 6. 常见报错和排查链路 ### 6.1 技能没有被识别 最典型的错误信号是模型完全没调用技能而是直接用普通对话回答。 拿到这个问题先按顺序排查 1. 技能目录位置是否正确。用户级还是项目级别放错。 2. SKILL.md 是否存在文件名大小写是否一致。 3. frontmatter 里的 name 和 description 是否正确description 是否足够触发。 4. 技能加载命令是否执行过有的环境需要重启。 5. 是否存在语法错误比如 YAML 解析失败。 很多情况下问题不是技能文件有问题而是 description 写得不够具体。模型很难判断当前任务和这个技能相关。可以换个说法把触发词写得直接一些比如“当用户提到 PPT 时使用”。 ### 6.2 技能被识别但脚本执行报错 这个问题出现在“技能被调用但执行失败”。先看完整错误日志确认是哪一步失败。 可能的方向 - 路径问题脚本找不到输入文件或输出目录。 - 依赖问题Python 包、Node 模块没有安装。 - 权限问题脚本没有执行权限或者没有写权限。 - 环境差异本地能跑但 Agent 执行环境缺少某些环境变量。 我一般会把 Agent 执行命令和手动执行命令对比看是不是参数不一致。如果手动执行成功、Agent 执行失败问题通常在参数或当前工作目录上。 ### 6.3 输出质量不符合预期 技能跑通但结果质量不高这是最难排查的情况。需要拆开看 - 是不是输入数据不够完整 - 是不是技能文件里的步骤描述太模糊 - 是不是模型没有严格按照检查清单执行 - 是不是输出后处理脚本不够 你可以先让模型把执行过程日志输出看它在关键节点的判断。如果模型跳过某个步骤那就是技能文件里的指令不够明确。 ### 6.4 资源占用和超时 技能如果处理大文件或批量任务要考虑时间和资源。一个技能处理 1MB 文件和处理 100MB 文件的耗时可能差几十倍。 建议在技能文件里写上预期耗时和资源上限。比如 - “本技能最多处理 1000 行输入超过后建议分批。” - “执行期间可能需要 2GB 内存请提前确认机器配置。” - “单个文件处理时间通常在 30 秒以内。” 如果超时先看是不是任务太大。不是所有技能都适合处理超大输入可以考虑先拆分任务。 注意低配置机器能跑通一个技能不代表它能跑通批量任务。批量使用前先测一两个任务观察内存和磁盘占用。 ## 7. 适用边界和个人建议 ### 7.1 适合什么场景 从我实际使用的感受来看Skills 最适合这三种场景 1. 重复性高且有固定流程的任务比如周报生成、测试计划输出、文档规范检查。 2. 需要调用本地脚本和外部工具的复杂任务比如生成 PPTX 后还要转 PDF。 3. 需要多人共享工作方式的任务比如团队统一的前端代码审查标准。 如果你正在做的任务每次都需要很长的提示词而且换个人就做不好那很适合把它变成技能。 ### 7.2 不适合什么场景 Skills 不适合特别灵动、开放的研究型任务。它更像“操作手册”如果你希望模型完全自由发挥技能反而会限制它。比如“帮我写一篇创意小说”这种任务不适合定义太多步骤。 另外如果你的任务特别依赖实时数据、私有系统或者复杂鉴权Skills 单独也解决不了。这种场景应该考虑 MCP 工具或更完整的服务编排。 不要在项目的早期阶段过度设计技能。项目还在频繁改需求时技能的维护成本会很高。等流程稳定再沉淀成技能。 ### 7.3 我的建议顺序 如果你刚接触这块我比较推荐这样的顺序 1. 先手动完成一次任务记录下完整的处理步骤。 2. 把步骤拆成输入、处理、输出三个阶段。 3. 建一个最小技能把步骤写进 SKILL.md。 4. 用真实数据测试观察模型哪些步骤执行得好、哪些跑偏。 5. 针对跑偏的部分补脚本和检查清单。 6. 稳定后再考虑共享和版本管理。 不要第一步就跟着社区项目装一堆热门技能。先把自己的常用任务沉淀成一个最小技能理解整个过程再去参考别人的优秀实现。这样你才能真正判断一个技能写得好不好而不是完全照搬。 落到最后我还是那句把单任务跑稳再谈批量和生态。Skills 的真正价值不是让你一次性生成一堆杂乱输出而是让每次输出都能复现、检查和改进。这一点在任何工具生态里都是最重要的。