你有没有遇到过这种场景让 AI 写一份带格式的 Word 报告它每次都给你 Markdown让它生成前端页面出来的风格五花八门让它写测试用例翻来覆去全是正常路径边界条件和异常场景一个没写。问题不在模型能力而在模型缺少一份“作业规范”。Anthropic 推出 Claude Skills 之后这个问题有了比较系统的解法。Skill 不是一个新模型也不是一套复杂框架它本质上是一份可复用的技能包告诉 Claude 在什么场景下该做什么事、按什么流程做、允许使用哪些脚本和模板。而anthropics/skills就是官方维护的 Skill 示例仓库里面包含了文档处理、前端原型、MCP 构建、Skill 自举等一批可以直接参考和使用的 Skill。我的判断是Skills 真正改变的不是模型本身而是你与模型协作的方式。它把过去靠人肉复制粘贴的“嘴皮子功夫”沉淀成了项目里可版本管理、可团队共享、可自动触发的资产。这篇文章会从概念、机制、安装、开发、验证到常见坑完整拆一遍读完你不仅能看懂anthropics/skills仓库还能自己写出第一个可用的 Skill。1. Skills 是什么从一句提示词到一份技能包先给一个直观定义。Claude Skill中文常译为“技能”是一个目录里面有一份SKILL.md文件以及若干辅助资源脚本、模板、参考文档等。SKILL.md用 Markdown 编写开头有一个 YAML 格式的 frontmatter声明了这个技能的名字和用途正文则是具体的操作说明和工作流程。Claude 在对话中会根据任务的语义主动判断是否需要加载某个 Skill。一旦匹配上它就会把SKILL.md中的指令作为上下文的一部分按里面定义的流程去执行任务。比如你让它生成一份 pptx它会加载 pptx 处理 Skill然后调用脚本把内容写入真实的.pptx文件而不是像以前那样只给你一段建议代码。如果你想更深入理解这个概念建议去翻阅 Anthropic 官方团队维护的anthropics/skills仓库里面有很多 Skill 的“成品形态”可以参考。一个比较合适的类比是给一个能力很强但刚入职的实习生发一份岗位 SOP。实习生本来就很聪明但缺少公司的业务规范和交付标准。SOP 的效果是他每次做同类事情时不需要你再反复叮嘱也不会自由发挥到方向跑偏。Skill 对 Claude 起的作用和这份 SOP 在实习生身上的作用几乎一样。从工程视角看Skill 解决的是三件事一致性同一个任务无论谁发起、什么时候发起Claude 都按同一套流程执行。可复用性团队里写好一个 Skill其他人克隆仓库就能用。可维护性Skill 是文件可以被 Git 追踪可以走 Code Review改坏了还能回滚。2. Skills、MCP 与 Prompt三者的分工与取舍现在很多开发者最容易混淆的就是 Skills、MCP 和 Prompt 这三者的关系。其实它们在体系中的层次完全不同。维度PromptSkillMCP载体一段文本目录 SKILL.md 资源文件一个服务/进程本质一次性指令结构化的流程知识轻量工具外部工具接口加载方式每次手动粘贴模型按场景自动加载应用启动后连接典型场景临时提需求专业领域任务、办公文档、代码规范查数据库、调 API、操作浏览器维护成本低但不可控中文件化管理高需要部署运维适合谁个人临时使用团队沉淀流程和标准系统集成和实时数据访问如果你只是想这一次让 Claude 按某种格式输出用 Prompt 就够了。如果你想让 Claude “以后每次都按这套流程处理这一类任务”那应该做成 Skill。如果你需要克隆数据到本地、实时查询最新信息、调用外部系统那才需要 MCP。Skill 与 MCP 不是二选一的关系反而是互补关系。实际项目里常见的组合是Skill 定义“怎么做”MCP 提供“做的时候需要的数据”。比如一个运维类 Skill流程上规定了先查状态、再变更、最后验证而查状态这个动作通过 Prometheus MCP 或 Kubernetes MCP 完成。Skill 负责编排MCP 负责执行外部动作。理解这个边界很重要。我在不少讨论区看到有人问“是不是有 MCP 就不用 Skill 了”答案是否定的。MCP 更接近一个工具插槽它不关心你的业务步骤是什么Skill 则恰好负责把业务步骤翻译成模型可执行的指令。两者解决的问题层次不同组合起来才是完成度较高的 Agent 工作流。3. SKILL.md 的内部结构触发与执行的关键要开发 Skill首先得把SKILL.md的结构吃透。它是整个 Skill 的入口也是模型判断“该不该用”以及“怎么用”的核心依据。一个最小的SKILL.md如下--- name: daily-report description: 生成标准化的每日工作汇报。当用户需要整理当天工作进展、输出日报时使用。 --- # Daily Report Skill ## 适用场景 - 用户需要生成日报、周报、月度总结 - 工作内容分散在多条消息中需要汇总 ## 工作流程 1. 让用户提供当天的任务列表 2. 按“完成 / 进行中 / 阻塞 / 明日计划”四类整理 3. 使用脚本 scripts/build_report.py 生成 Markdown 文件 4. 输出文件路径 ## 注意事项 - 不要编造用户未提到的工作内容 - 日期默认使用当天日期这里有两个字段对模型特别重要nameSkill 的唯一标识一般用 kebab-case比如daily-report、frontend-dev。命名要稳定别频繁改动否则容易造成旧任务加载失败。description这是整个 Skill 的“广告牌”。Claude 每次收到用户消息后会扫描所有可用 Skill 的 description判断当前任务是否需要加载对应技能。如果 description 写得含糊模型就不会触发它。描述里最好包含几类信息这个 Skill 解决什么类型的任务在什么场景下用户会提到这类需求有没有关键的触发词或前置条件比如description: 专用于生成数据分析报告。当用户上传 CSV / Excel 数据并要求输出分析结论、图表建议或 PPT 内容时使用。比下面这种写法要有效得多description: 一个数据分析技能。正文部分则要按“先原则、后步骤”的方式组织。模型不会像人一样逐字背下来但会把它作为上下文里的重要指令。原则放在前面能保证它在步骤执行偏离时回到正确的路线上来步骤拆得越细输出的稳定性越好。4. 环境准备Skill 应该放在哪里Skill 的开发和运行并不依赖额外的编译工具核心依赖是支持 Agent Skills 的 Claude 客户端。如果你使用的客户端版本较旧建议先升级到较新版本再继续排查问题。Skill 文件通常放在两个层级项目级目录只对当前项目生效你的项目根目录/.claude/skills/skill-name/用户级目录对当前用户的所有项目生效~/.claude/skills/skill-name/开发阶段建议先放项目级因为项目级目录改动后可以比较方便地通过 Git 查看变更也方便团队一起评审。一个 Skill 就是一个子目录目录名称建议与name保持一致。例如~/.claude/skills/daily-report/ ├── SKILL.md ├── assets/ │ └── templates/ │ └── report-template.md └── scripts/ └── build_report.py资源文件的组织不是强制的但建议按功能拆分assets/放模板、静态资源scripts/放可执行脚本references/放领域知识、长文档避免全塞进SKILL.md把上下文撑爆到这里可以简单盘点一下你是否有条件开始一个支持 Agent Skills 的 Claude 环境能访问 Anthropic 官方仓库或已有 Skill 文件一个用于实验的测试项目目录而不是直接在正式生产项目里动手都满足之后就可以开始安装官方 Skill 了。5. 快速上手从 anthropics/skills 仓库安装官方 Skillanthropics/skills是 Anthropic 官方维护的 Skill 示例仓库里面包含了文档处理、前端原型生成、MCP 构建、Skill 自举等一批高质量参考实现。想快速感受 Skill 的完整工作流直接用它是最省力的方式。先把仓库克隆下来git clone https://github.com/anthropics/skills.git cd skills然后查看仓库中已经有哪些 Skill 目录ls -la官方仓库里通常可以看到类似artifacts-builder、skill-creator、mcp-builder、office-worker、document-skills等目录。如果你需要处理 docx、pptx、xlsx、pdf 这类文档任务可以优先看document-skills相关的 Skill如果你想快速生成前端原型artifacts-builder值得直接拿来用。选定一个 Skill 后把它复制到 Claude 能识别的 skills 目录。以artifacts-builder为例mkdir -p ~/.claude/skills cp -r skills/artifacts-builder ~/.claude/skills/如果只在某个项目里使用则复制到项目目录下mkdir -p .claude/skills cp -r ../skills/artifacts-builder .claude/skills/复制完成后启动支持 Agent Skills 的客户端在项目目录下打开对话窗口试着让它“生成一个登录页原型”或“把这段产品说明做成一个可交互页面”。如果 Skill 被成功加载模型的输出方式会有明显变化它不再只是给你写一段代码而是会按其工作流程生成页面文件、调用脚本、产出可预览的结果。更稳妥的验证方式是直接问“当前有哪些可用 Skill”或查看客户端提供的技能列表入口。不同客户端的入口位置可能不同建议以你使用的客户端实际界面为准。官方仓库的价值不只是给你现成工具更是一套“最佳实践样例”。想自己开发 Skill 时把官方仓库里两三个 Skill 的SKILL.md完整读一遍比看十篇教程都管用。6. 动手开发写一个前端开发 Skill大多数人学了 Skill 概念后真正卡住的点是“自己从头写一个”。这一章用前端页面生成这个高频场景完整演示一个 Skill 从目录创建到运行验证的流程。先明确需求我们希望 Claude 在生成前端页面时不再随手写一个样式随缘的单页 HTML而是遵循团队统一的项目规范生成结构清晰、样式稳定、可直接在浏览器打开的页面。先创建目录结构mkdir -p .claude/skills/frontend-dev/{assets/templates,scripts}然后创建SKILL.md--- name: frontend-dev description: 前端页面原型开发技能。当用户需要生成 HTML 页面、登录页、落地页、组件演示页或把 Markdown 内容转换为可交互静态页面时使用。 --- # Frontend Dev Skill ## 设计原则 - 默认生成单个自包含 HTML 文件不依赖外部 CDN - 使用现代 CSS移动端优先 - 图片使用占位色块或 SVG避免链接外部图片 - 交互效果优先用原生 JavaScript 实现 ## 工作流程 1. 阅读 assets/templates/page-template.html 获取基础模板 2. 根据用户需求填充页面结构和样式 3. 使用 scripts/generate_page.py 将页面内容输出为最终 HTML 文件 4. 输出文件路径和预览方式 ## 注意事项 - 禁止引入未授权的第三方库 - 配色尽量克制默认使用系统字体栈 - 页面内文案不使用占位符 Lorem ipsum需根据需求生成有意义的中文内容接着创建一个最小可用的 HTML 模板放在assets/templates/page-template.html!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title{{title}}/title style * { margin: 0; padding: 0; box-sizing: border-box; } body { font-family: -apple-system, BlinkMacSystemFont, Segoe UI, sans-serif; line-height: 1.6; color: #1a1a1a; background: #fafafa; padding: 24px; } .container { max-width: 960px; margin: 0 auto; } h1 { font-size: 2rem; margin-bottom: 16px; } .card { background: #fff; border: 1px solid #e5e5e5; border-radius: 8px; padding: 24px; margin-bottom: 16px; } /style /head body main classcontainer h1{{title}}/h1 div classcard {{content}} /div /main /body /html再写一个简单的生成脚本放在scripts/generate_page.py。这个脚本负责从 JSON 参数生成最终 HTML 文件#!/usr/bin/env python3 import json import sys from pathlib import Path def main(): if len(sys.argv) 2: print(用法: python scripts/generate_page.py content.json) sys.exit(1) # 读取页面数据 with open(sys.argv[1], r, encodingutf-8) as f: data json.load(f) title data.get(title, 未命名页面) content data.get(content, ) # 读取模板 template_path Path(__file__).parent.parent / assets / templates / page-template.html template template_path.read_text(encodingutf-8) # 渲染 html template.replace({{title}}, title).replace({{content}}, content) # 输出文件 output Path(output) / index.html output.parent.mkdir(exist_okTrue) output.write_text(html, encodingutf-8) print(f页面已生成{output}) if __name__ __main__: main()这个脚本故意做得很简单目的是让你看到“Skill 里的脚本”不是魔法就是一个普通 Python 脚本。模型读取SKILL.md后会按里面的说明决定何时调用脚本、传入什么参数。开发完成后实测一下。在对话里说请用 frontend-dev 技能为「AI 编程助手」产品生成一个落地页需要包含产品亮点和 CTA 按钮。如果 Skill 没有生效可以先检查路径是否是.claude/skills/frontend-dev/SKILL.md再看name和目录名是否一致最后看description是否包含“生成 HTML 页面”这类触发场景。大多数不触发的问题都出在这三处。7. 测试场景把测试用例设计做成一个 SkillSkills 不只适合写文档和前端测试领域同样可以用。很多团队用 AI 生成测试用例时遇到的问题是用例太浅、只覆盖正常路径、格式不统一、无法和缺陷管理系统对接。这些问题恰好是 Skill 可以解决的。下面设计一个“测试用例设计” Skill让 Claude 在生成用例时自动套用团队规范。先创建目录mkdir -p .claude/skills/qa-designer/{templates,scripts}SKILL.md如下--- name: qa-designer description: 测试用例设计技能。当用户需要为功能需求编写测试用例、补充边界条件和异常场景、生成测试报告时使用。 --- # QA Designer Skill ## 设计原则 - 每个用例必须有独立编号格式为 TC-模块-序号 - 必须覆盖正常路径、边界条件、异常路径三个维度 - 用例描述必须包含前置条件、操作步骤、预期结果 - 优先参考 references/test-case-template.md 中的模板 ## 工作流程 1. 整理用户提供的需求描述 2. 识别业务规则、输入限制、异常分支 3. 按照模板生成测试用例表 4. 使用 scripts/generate_test_cases.py 输出 Markdown 文件 5. 检查用例编号是否重复检查是否缺少异常路径 ## 注意事项 - 不得编造需求中不存在的功能点 - 对模糊需求给出假设并明确标注“待确认”再写一个用例模板放在templates/test-case-template.md## {{module}} 测试用例 ### TC-{{module}}-{{seq}}{{title}} - **优先级**{{priority}} - **前置条件**{{precondition}} - **测试步骤** 1. {{step1}} 2. {{step2}} - **预期结果**{{expected}}最后是生成脚本scripts/generate_test_cases.py它接收 JSON 格式的用例数据生成规范 Markdown#!/usr/bin/env python3 import json import sys from pathlib import Path def main(): if len(sys.argv) 2: print(用法: python scripts/generate_test_cases.py cases.json) sys.exit(1) with open(sys.argv[1], r, encodingutf-8) as f: cases json.load(f) template Path(__file__).parent.parent / templates / test-case-template.md content template.read_text(encodingutf-8) result [] for case in cases: rendered content rendered rendered.replace({{module}}, case[module]) rendered rendered.replace({{seq}}, str(case[seq]).zfill(2)) rendered rendered.replace({{title}}, case[title]) rendered rendered.replace({{priority}}, case.get(priority, P2)) rendered rendered.replace({{precondition}}, case.get(precondition, 无)) rendered rendered.replace({{step1}}, case[steps][0]) rendered rendered.replace({{step2}}, case[steps][1] if len(case[steps]) 1 else 观察系统状态) rendered rendered.replace({{expected}}, case[expected]) result.append(rendered) output Path(output) / test-cases.md output.parent.mkdir(exist_okTrue) output.write_text(\n.join(result), encodingutf-8) print(f测试用例已生成{output}) if __name__ __main__: main()使用方式依然很直接对话里说请用 qa-designer 技能为「用户登录功能」设计测试用例输入是用户名和密码需要覆盖登录成功、密码错误、账号锁定、空输入等情况。模型会按SKILL.md的流程先生成结构化用例数据再调用脚本输出 Markdown 文件。如果团队还有对接禅道、Jira、飞书表格的需求完全可以把这些步骤也写进SKILL.md让用例格式从一开始就满足平台要求。测试领域的 Skill 之所以有价值是因为“测试设计”本身是一个高度依赖规范和经验的场景。用例覆盖度、编号规则、模板格式、优先级标准这些都是可以复用的团队资产。用 Prompt 每次临时写质量和格式很难稳定用 Skill 沉淀下来整个测试团队就都站在同一套标准上。8. 运行验证与排查思路Skill 写好之后如何确认它真的被正确加载和使用了这一步不能跳过否则你可能会误以为“Skill 没生效”其实是文件位置或格式错了。推荐的排查顺序如下第一步确认文件位置Skill 必须位于.claude/skills/skill-name/或用户级~/.claude/skills/skill-name/。注意是小写.claude不是.Claude或claude。目录名和SKILL.md中的name字段可以保持节奏一致方便识别。第二步确认 SKILL.md 格式打开文件确认 frontmatter 的---与---之间的 YAML 没有语法错误。常见错误包括name和description后面中文冒号、Tab 缩进、多余的引号。YAML 解析失败时客户端通常会忽略整个 Skill但不会弹窗明确告诉你。第三步确认 description 是否足够具体在对话中直接问“当前有哪些可用 Skill”。如果没有看到自己的 Skill多数是位置或格式问题如果看到了但触发不成功就要检查description里是否覆盖了真实任务里会用到的关键词和场景。第四步确认脚本环境如果 Skill 中有 Python 或 Node 脚本要确认运行环境存在并且依赖已安装。比如脚本用到 Python 第三方库需要先pip install脚本权限不足时需要给执行权限。脚本错误比SKILL.md错误更容易定位因为会报错但也容易被忽略因为模型可能会跳过脚本直接生成内容导致输出偏离预期。排查过程中可以借助下表快速定位问题现象可能原因排查方式解决方案问询时看不到 Skill目录位置错误或名称不匹配检查.claude/skills路径和大小写移动到正确目录Skill 能看到但不触发description 描述过泛或缺少触发词对比任务描述和 Skill 描述细化 description加入场景关键词生成结果不符合 Skill 规范SKILL.md 正文指令不够明确检查正文是否包含工作流程和规则补充分步骤指令和示例脚本报错找不到模块缺少 Python 依赖查看报错信息检查 requirements安装依赖或改用标准库脚本不执行没有执行权限或路径错误确认脚本路径和调用方式设置执行权限核对相对路径输出文件位置不固定脚本使用了相对路径检查脚本中输出路径定义统一使用与 SKILL.md 相关的相对路径9. 常见问题这一节汇总几个开发和使用 Skill 时的高频问题方便你在实践中快速对照。1. Skill 和插件有什么区别插件往往包含客户端层面的 UI、事件处理或集成能力而 Skill 更聚焦于给模型提供指令、知识和轻量脚本。Skills 可以理解为插件体系里偏向“模型能力扩展”的那一层。如果你需要深度集成外部工具或定制客户端行为那要关注的是插件/MCP而不是 Skill。2. 一个 Skill 可以包含多个流程吗可以但建议控制复杂度。如果一个大 Skill 里包含十几个互不相关的子流程模型的执行稳定性会下降。更合理的做法是拆成多个小 Skill各自有清晰职责然后在 description 里让模型按照任务类型选择加载哪个。3. Skill 里可以放敏感信息吗不建议。Skill 文件会被读取并进入模型上下文把密钥、令牌、内部账号密码放进 Skill 等同于泄露。敏感信息应该通过环境变量或密钥管理系统注入脚本运行时再读取。4. Skill 可以分享给团队吗可以而且这是 Skill 的核心价值之一。把 Skill 目录提交到 Git 仓库团队其他人拉取后就能在自己环境里使用。团队使用第三方或他人编写的 Skill 时要注意来源安全及时审查其中的脚本和指令。5. Skill 会一直占用上下文吗不会。Claude 是根据任务动态决定是否加载 Skill 的。加载后SKILL.md和必要资源会进入上下文不相关的 Skill 不会被加载。但这也意味着你不能依赖 Skill 里的内容在每次对话中都生效重要的规则仍然要在对话里明确提示。6. 为什么我用了 Skill输出还是不稳定常见原因是SKILL.md写得不够具体。Skill 不是魔法它是一份指令集指令越模糊输出越随机。尝试把工作流程拆成明确步骤并给出一个输出示例稳定性会明显提升。7. 开发 Skill 需要会 Python 吗不一定。Skill 的资源文件可以是脚本、模板、参考文档甚至只是纯 Markdown 指令。如果你的 Skill 不需要操作文件或调用命令只写一份高质量的SKILL.md也完全可行。脚本只是增强 Skill 能力的一种手段。10. 最佳实践与工程建议如果你准备把 Skills 引入日常开发或团队协作下面这些建议能让你少走一些弯路。description 要按任务导向写不要写“这是一个 XX 技能”这种描述而要写“当用户需要 XX、遇到 XX 场景时使用”。模型的触发逻辑更像搜索匹配它需要从你的描述里找到和当前任务匹配的关键信息。知识放到 references不要全塞进 SKILL.mdSkill 的优势之一是可以附带长文档。但如果把整本规范都写进SKILL.md上下文会迅速膨胀反而影响模型对核心指令的遵循。建议SKILL.md只保留流程和原则领域知识放到references/目录并在需要时让模型按需读取。脚本保持最小化Skill 里的脚本只是为了补齐模型做不到的事比如“生成真正的二进制 docx 文件”“操作 Excel 公式”“调用本地命令”。不要让脚本承担太多业务逻辑否则维护成本会高于收益。注意安全边界第三方 Skill 本质上是一堆指令加脚本理论上存在被植入恶意指令的风险。在公司团队中使用外部 Skill 前应先人工审查SKILL.md和脚本内容确认没有可疑的数据外传行为。用 Git 管理 Skill像管理代码一样管理它Skill 的变更会影响所有使用它的人。命名、目录结构、流程改动都应该走正常的版本管理流程。改坏一个 Skill 比改坏一段业务代码更容易被忽视因为错误不是立刻暴露而是潜伏在模型输出质量的下滑里。先跑通最小示例再追求覆盖度第一次开发 Skill 时先做一个只包含单一流程的最简版本验证模型能触发、能按流程走、能产出预期结果。然后再逐步补充边界场景、异常处理和脚本能力。一上来就写一个万事通型 Skill往往最后哪个场景都没做好。11. 写在最后Skill 给我最大的启发是它把“AI 协作经验”从个人脑子里搬到了文件系统里。过去一个团队里谁更会写提示词谁就能让 AI 产出更好的结果现在这套经验可以通过一个目录、一份文件、一组脚本变成团队公共资产。anthropics/skills官方仓库适合作为学习起点把它里面的 Skill 读一遍、装一遍再照着写一个自己的基本就能掌握这个新范式。接下来你可以在三类方向继续深入一是把自己日常重复的 AI 任务逐个 Skill 化二是研究如何让 Skill 里的脚本更可靠、更安全三是慢慢探索 Skill 与 MCP 的组合方式让模型既能遵循流程也能触达实时数据。建议先把文中“前端开发 Skill”和“测试用例 Skill”两个示例完整跑一遍感受一下从安装、触发、执行到产出的全流程。跑通之后你就会理解为什么我说Skills 不是模型能力的替代而是模型能力真正落地到具体工作流里的那层“中间件”。