用过 Claude 的人应该都有这种感觉每次要让 AI 干活都得重新描述一遍需求、背景、格式要求一件事重复十几次之后你会发现自己一直在复制粘贴同样的话。Claude Skills 就是来解决这个问题的——它把一套完整的执行逻辑打包成一个可复用的能力单元让 Claude 在遇到对应场景时自动调用而不是每次从头教一遍。这个教程是我自己反复调试、踩坑之后整理出来的目标只有一个你不需要理解底层实现照着步骤做就能做出属于你自己的 Skill。适合所有在用 Claude 处理写作、编程、数据分析、日常事务的读者不管你是纯小白还是已经折腾过一些配置的老手这篇文章都能让你少走弯路。1. 先搞清楚 Claude Skills 是什么别急着动手1.1 从每次重新教到一次定义随时调用先举一个生活化的例子。你请一位新同事帮你写周报第一次你要告诉他格式用表格、内容分三块、语气要正式、不要用感叹号。第二周你还要再说一遍第三周还要再说一遍。如果这个同事有记忆你其实只需要完整交代一次之后只需要说写周报三个字就够了。Claude Skills 就是这个同事的记忆。一个 Skill 本质上是一份结构化的指令文件里面写清楚了这个能力要在什么场景下触发、执行步骤是什么、输出格式是什么、有哪些参考示例。你把它加载到 Claude 之后以后只要对话内容匹配到这个 Skill 的触发场景Claude 就会自动按里面的规则执行。这跟普通的自定义指令Custom Instructions不太一样。自定义指令是所有对话都生效的人格设定而 Skill 是按需触发的能力模块。你可以同时挂十几个 Skill但某个具体任务只会激活相关的那个不会互相打架。这个按需激活的设计非常关键它意味着你可以积累一大批技能而不必担心 Claude 每次都被一堆规则限制住。1.2 Skills 解决的核心痛点是什么我自己用下来的体会是Skills 解决了我最头疼的三个问题痛点一重复劳动。以前我处理一份数据分析报告开场白要写背景、要说明口径、要规定输出格式每次都得打一大段话。现在直接说帮我分析这份数据Skill 会自动带上所有规则省了至少五分钟的废话。痛点二输出不稳定。相同的问题问十次Claude 的回复格式可能每次都不一样。Skill 里写明了必须包含哪几个部分表格放在什么位置结论写在最后输出一致性会明显提升。这对要拿去交付、发表的内容尤其重要。痛点三方法论无法沉淀。一个团队里写代码的人总结了一套代码审查清单写方案的人积累了一套方案结构模板——如果没有 Skills这些东西就散落在每个人的聊天记录里。有了 Skills它们可以变成文件直接共享和复用。所以我给你的建议是不要把这个功能想得很玄它就是一套可复用的操作手册。你自己平时怎么给 AI 交代任务把这些交代的内容结构化整理就是一个 Skill。2. 动手前需要知道的几个核心概念2.1 理解 Skill 的文件结构一个 Skill 在本质上就是一个目录文件夹里面最少包含一个SKILL.md文件核心代码如下my-skill/ ├── SKILL.md ├── examples/ │ ├── example1.md │ └── example2.md └── references/ ├── style-guide.md └── templates/ └── report-template.md这个结构不复杂但每一个部分都有它存在的意义SKILL.md是灵魂所有核心指令都在这个文件里。examples/目录放示例Claude 会参考示例来模仿你的预期输出。references/目录放参考资料比如风格指南、模板、数据字典是辅助材料。提示SKILL.md这个文件名是约定俗成的标准命名如果你改了名字Claude 可能识别不了。目录名才是 Skill 的名称标识可以自由命名。2.2 理解 Skill 的加载方式在聊加载之前首先要明白一件事Claude 不会同时读取你所有的 Skill 文件。它会在收到你的消息后根据消息内容判断当前任务和哪个 Skill 有关然后只加载那一个或少数几个Skill 的配置。这个机制和搜索引擎有点类似——你输入一个问题它先检索索引再拉取最相关的内容。那么 Claude 是怎么判断当前任务和哪个 Skill 有关的呢靠的就是SKILL.md里的两个字段Name技能名和Usage适用场景描述。这两个字段写得越精准Claude 的触发判断就越准确。这也是为什么我说写 Skill 的时候这两部分要格外用心。另外你要清楚一点Skill 的加载不是记忆消失的那种问题。Claude 每次会话开始时都会读取与当前对话相关的 Skill 内容所以你不需要在每次对话里重新上传只需要在对话中自然表达你的需求即可。如果你发现 Claude 没按某个 Skill 的规则来大概率不是它忘了而是触发判断没匹配上。这个问题我在后面常见问题章节里会专门讲排查方法。3. 保姆级实操从零创建一个完整 Skill现在我带你完整走一遍流程。我假设你的目标场景是帮我用统一的风格写周报这是每个职场人都用得上的需求。跟着这个流程走完你就掌握了 Skills 的全部核心操作。3.1 第一步创建目录结构在电脑上随便找一个你方便管理的位置新建一个文件夹命名为weekly-report。在这个文件夹里再新建两个子文件夹一个叫examples另一个叫references。weekly-report/ ├── SKILL.md 等会儿创建 ├── examples/ 空文件夹 └── references/ 空文件夹这个目录放在哪个根目录下取决于你用的是哪个版本的 Claude 客户端。你只需要知道Skill 本质就是这样一个文件夹无论是从本地上传还是从云端选择你只需要把整个文件夹打包或拖入即可。3.2 第二步编写核心的 SKILL.md 文件在weekly-report文件夹里新建一个文件命名为SKILL.md。文件内容采用 Markdown 格式我们需要在其中写入 yaml 格式的元数据和正文指令。下面是我建议的完整模板你可以直接复制使用--- name: 周报生成器 description: 当用户要求写周报、周总结、工作汇报时使用。适用于需要将零散工作内容整理成结构化周报的场景。 --- ## 角色定位 你是资深职场秘书擅长把杂乱的工作内容整理成清晰、有价值的周报。 ## 执行步骤 当用户提出写周报的需求后按以下顺序执行 1. **收集信息**如果用户没有提供足够的工作内容先提出以下问题引导用户补齐 - 本周完成了哪些主要任务 - 有没有特别突出的成果或数据 - 下周有哪些计划 2. **整理归纳**将零散内容按「本周完成」「核心成果」「问题与风险」「下周计划」四个板块分类。 3. **生成周报**按规定的格式输出周报。 ## 输出格式 周报正文必须遵循以下结构 ### 本周完成 - 每项任务用一句话概括按重要程度排序重要任务加粗。 ### 核心成果 - 优先呈现有数据支撑的成果格式为「成果描述数据指标」例如完成新版首页改版转化率提升5%。 ### 问题与风险 - 列出本周遇到的问题每个问题附上已采取的应对措施。 ### 下周计划 - 按优先级列出每项计划尽量明确预期时间节点。 ## 注意事项 - 周报语气正式、克制不使用感叹号。 - 所有数据必须来自用户提供的原始信息不得编造数据。 - 如果用户提供的信息不足必须先询问不要强行编造内容。 ## 示例 见 examples 文件夹。写完之后保存。这就是一个最基础的 Skill 的核心文件了。注意看我用---包起来的那段内容那是 yaml 格式的元数据name是技能名称description是触发条件描述。这两部分我建议认真打磨。3.3 第三步准备示例与参考资料接下来在examples文件夹里放两个示例文件第一个示例文件example1.md展示一个理想的周报输出### 本周完成 - **完成数据看板改版项目**本周上线新版本用户反馈良好。 - 修复后台管理系统的三个稳定性问题。 ### 核心成果 - 数据看板改版上线页面加载速度提升约 30%。 - 推动与外部数据平台的接口对接完成联调测试。 ### 问题与风险 - 数据接口超时问题偶发已联系对方优化预计下周修复。 - 团队成员本周有一人请假部分任务进度延后正在协调资源。 ### 下周计划 - 完成接口稳定性验证并输出完整测试报告预计周三前。 - 启动新功能需求评审暂定周四。第二个示例文件example2.md展示一个风格不同但同样合格的短版周报### 本周完成 - 完成客户 A 的季度数据报表交付。 - 跟进合同续签流程补充财务所需材料。 ### 核心成果 - 客户 A 报表提前一天交付客户确认无修改意见。 ### 问题与风险 - 合同续签审批进度偏慢已催促法务部门本周内应能完成。 ### 下周计划 - 跟进合同签署同步推动客户 B 的合作方案初稿。这两个示例给 Claude 提供了一个参照系。很多时候AI 不知道你想要多详细、什么格式但给它几个别人家的作业之后它模仿起来就非常准确。至于references文件夹如果你有一些内部的工作汇报规范文件、公司的写作风格文档也可以放进去。没有的话这个文件夹先空着也不影响。对于周报这种简单任务来说示例已经足够。3.4 第四步启用并测试 Skill文件都准备好了之后启用过程非常简单打开 Claude 的配置页面找到 Skills 相关入口。将weekly-report整个文件夹上传或导入。在配置列表里确认weekly-report出现在已加载的 Skill 列表中。然后你就可以实测了。发一段带工作内容的描述给 Claude例如我这周主要做了改版了首页、修了三个 bug、和某外部服务商对了一下接口。准备了一份客户提案。下周想推进一下新项目的技术预研。不需要特别说明请用周报 Skill只要你的 Skill 描述写得准确Claude 会自动匹配。正常情况下 Claude 会直接按周报格式输出。如果它没有反应或者输出不是周报格式就要检查description字段写的是否精确——我在常见问题部分会细讲。4. 写到好 Skill 的五个关键要素一整套流程跑通之后你会想更进一步——把 Skill 写得更好。根据我反复调试的经验决定一个 Skill 好用不好用的是下面五个要素。4.1 Name 与 Description 的触发逻辑name字段要短、要容易被识别description字段要长、要覆盖所有可能的用户表达方式。举个例子你的 Skill 是写周报那description就不要只写当用户要求写周报时使用而应该覆盖周报、周总结、工作汇报、weekly report、这一周的工作整理等表达。因为 Claude 的触发判断其实就是语义匹配。用户可能不会说写周报而是说帮我把这周干的事整理一下。如果你的description里只写了周报这个整理一下的需求可能就匹配不上。反过来如果你的description覆盖了多种表达命中率就会高很多。--- name: 周报生成器 description: 当用户要求写周报、周总结、工作汇报、周度复盘或表达整理本周工作内容总结这周成果等意图时使用。 ---这是我试下来比较有效的一种写法。原则是宁可多写几句覆盖不要少写一句漏掉。4.2 Instructions 的黄金结构很多初学者在写 Instruction 的时候会犯一个错误写一段你要认真负责、使用专业语言、考虑用户需求之类的空话。这些空话对 Claude 几乎没有约束力。真正有效的 Instruction 结构我总结为目标 步骤 边界 输出格式。目标一句话说清这个 Skill 的职责。步骤用数字编号写出完整的执行流程越具体越好。边界写清楚不要做什么例如不得编造数据不要使用感叹号不要忽略用户提供的原始数据。输出格式用 Markdown 或示例结构明确告诉 Claude 结果长什么样。我在周报例子里的写法就是按这个结构来的。注意边界经常被忽略但其实特别重要。AI 默认倾向于自由发挥你如果不划线它很容易给你输出一堆正确但没用的话。4.3 Examples 为什么如此重要很多人不理解为什么 Skill 里要放examples文件夹觉得 SKILL.md 写清楚了就够了。但根据我自己和一些朋友的实测有没有示例效果差别非常明显。原理是这样的Claude 本质上是一个语言模型它最擅长的其实是模仿。你在指令里说结果要清晰、简洁、有重点它可能理解得比较抽象但如果你直接给出一份理想的输出示例它就能非常准确地把这份示例的风格、长度、结构复制到新的输出中。这里有一条经验示例的质量比数量重要。放一个非常优质的示例比放三个平平无奇的示例有用得多。我建议你花时间打磨示例尽量让示例覆盖你期望的终极效果。4.4 默认启用与按需选择的策略Claude Skills 通常支持两种使用方式让 Skill 始终参与处理一直开着对全部对话生效或按需自动匹配靠触发条件激活。前者方便但如果开得太多会占用上下文窗口还可能互相冲突后者更精准但需要你把触发描述写得足够好。我给的建议是分两批处理高频、不复杂的 Skill 可以默认开启比如周报生成器低频、逻辑复杂的 Skill 最好按需触发比如某个项目的专属代码规范。另外永远不要同时开十几个 Skill 然后指望每个都好用。我见过很多人的崩溃现场就是从装了一堆 Skill开始的。实践下来同时启用 3 到 5 个 Skill 是比较舒服的区间既能覆盖主要需求又不会让 Claude 在触发判断上犯迷糊。4.5 多文件拆分SKILL.md、references 与 examples 各司其职我刚接触 Skills 的时候习惯把所有内容全部堆在 SKILL.md 里面。写长了之后发现几个问题一是 Claude 在读取时会消耗更多 token二是内容多了之后核心指令会被淹没触发准确率反而不高。后来我调整了策略SKILL.md 只保留最核心的触发信息、执行步骤和输出格式参考资料、模板、风格指南这类辅助信息全部挪到 references 文件夹标准案例放到 examples 文件夹。这样说明书变短了Claude 的重点反而更突出。举个例子我的文章润色 Skill里SKILL.md 只写了润色的核心规则和步骤references 文件夹里放了三个不同文章类型的风格指南examples 文件夹里放了两个润色前 vs 润色后的对照案例。每次 Claude 在执行的时候都知道先读 SKILL.md 知道怎么干再读 references 了解风格最后对照 examples 模仿效果。这个分层逻辑是我认为写出高质量 Skill 的关键建议你从一开始就养成这个习惯。5. 三个可以直接抄的 Skill 模板下面这三个模板是我自己每天在用的结构完整、效果稳定。你可以直接把整段内容复制成SKILL.md放到对应目录下使用根据自己的情况微调。5.1 文章润色 Skill这个 Skill 适合做公众号文章、技术博客、工作邮件等内容的语言润色。核心特点是保留原意改善表达。--- name: 中文文章润色 description: 当用户要求润色文章、修改文案、优化表达、改善文笔时使用。适用于中文文本的改写润色任务。 --- ## 目标 在不改变原文核心意思的前提下提升文本的表达质量。 ## 执行步骤 1. **通读原文**确定中心思想和语气基调。 2. **逐段润色**优先解决逻辑不通顺、重复啰嗦、语病、用词不准确的问题。 3. **保留个人风格**不要刻意改成完全不同的腔调。 4. **输出修正对照**用「原文 → 改后」的方式呈现方便用户确认。 ## 输出格式 每段输出包含两部分 - 修改后的完整文本。 - 一个简短说明列出修改了哪些关键点。 ## 边界 - 不改变原文事实与数据。 - 不得擅自增删用户的核心观点。 - 如果原文已经很好直接说明无需修改不要为了改而改。搭配的examples文件夹里我放了一个对比案例原文我们觉得这个功能很有用我们希望用户可以更容易地使用它。 改后这个功能的价值在于降低使用门槛让用户更快上手。 说明将冗余的情感表达转化为清晰的用户价值描述去掉重复的我们使用。5.2 代码审查 Skill写代码的人应该都用得上这个。它可以用来对小段代码做逻辑检查、风格检查、潜在 bug 排查。--- name: 代码审查 description: 当用户要求审查代码、检查 bug、评估代码质量、Code Review 时使用。适用于 Python、JavaScript、TypeScript、Java 等主流语言。 --- ## 目标 对用户提交的代码进行系统检查输出一份结构化的审查意见。 ## 执行步骤 1. **理解代码意图**先阅读代码注释或用户补充说明明确这段代码想完成什么功能。 2. **逐维度审查**按以下顺序检查 - 正确性是否存在逻辑错误、边界条件遗漏。 - 安全性是否存在注入、越权、敏感信息泄露等风险。 - 性能是否有明显的低效实现如重复循环、N1 查询。 - 可读性命名是否清晰、结构是否易于理解。 - 规范性是否有明显偏离语言惯例的写法。 3. **按严重程度输出**分为「必须修复」「建议修复」「可选优化」三档。 ## 输出格式审查结论一句话说明代码整体质量问题列表[严重等级] 问题描述位置文件路径/行号原因为什么这是个问题建议如何修改## 边界 - 不编造问题。如果代码整体质量很好如实告知。 - 不直接重写完整代码除非用户明确要求。5.3 会议纪要 Skill开会族福音。这个 Skill 能把口语化的会议记录转成结构化、可直接交付的会议纪要。--- name: 会议纪要整理 description: 当用户要求整理会议纪要、会议记录、把聊天内容转为会议总结时使用。适用于团队内部会议、客户会议、项目复盘会等场景。 --- ## 目标 将用户提供的零散会议内容整理成可直接发送的高质量会议纪要。 ## 执行步骤 1. **识别会议基本信息**主题、参会角色、会议时间从用户描述中推断。 2. **提取关键内容**按「结论」「任务」「待办事项」三类进行归纳。 3. **标记负责人**如果用户提供了人员信息则为每个任务标记负责人未提供则写待确认。 4. **生成纪要**按标准模板输出。 ## 输出格式 ### 会议主题 【会议主题】 【会议时间】 【参会人】 ### 结论 会议达成的一致意见 ### 任务与下一步行动 | 任务描述 | 负责人 | 截止时间 | | --- | --- | --- | | 内容 | 人员 | 时间 | ### 风险与待决事项 需要关注的问题或尚未达成一致的事项这三个模板都比较通用你可以直接拷走替换成自己的具体场景内容。只要是按照前面讲的目标、步骤、边界、输出格式框架来写效果都不会差。6. 常见问题与排查技巧实录Skills 用起来不难但总会出现一些明明配置了却没生效或生效了但效果不理想的情况。我把这段时间我在实际使用中遇到的问题整理成一份排查清单照着查基本能解决。6.1 Skill 没被触发怎么办这是最常遇到的问题你上传好了 Skill然后正常提问但 Claude 完全按默认方式回答Skill 像不存在一样。我的排查顺序是这样的检查描述文件是否正常被识别。看看 Skill 列表里有没有显示正确的名称和描述如果显示异常大概率是 yaml 格式写错了。注意name和description的冒号后面一定要加一个空格这是 yaml 格式最常见的坑。检查描述是否覆盖了你的表达。回顾一下我前面讲的触发机制Claude 是根据description做语义匹配的。如果你只说帮我整理一下这个文档而描述里只写了当用户要求写周报时使用那大概率就匹配不上了。解决方法是把描述改宽泛一些覆盖更多表达方式。检查是否同时启用了太多 Skill。如果你同时启用了七八个 Skill触发判断容易互相干扰。可以试试把不相关的 Skill 关掉只保留出问题的那一个再测一次。直接点名。如果用户懒得改 description也可以在提问时直接说用 XX Skill 来帮我处理。这是一种显式触发方式绕过语义匹配通常能确保生效。6.2 Skill 生效了但输出不符合预期这种也是常有的。触发没毛病但 Claude 的输出和你想象的不一样说明 SKILL.md 里指令不够精确。我一般会做三件事第一检查指令里有没有可做可不做的空间。比如你写用正式的语气改稿正式是一个模糊的词AI 的理解可能跟你不一致。更精确的写法是不使用感叹号、不使用口语化词汇如咱们挺、不使用网络用语。指令里的每个要求都应该是可客观判定的而不是需要主观感受的。第二检查示例的质量。前面说了示例是 AI 模仿的主要参照。如果你的示例写得不好或者跟实际任务偏差很大输出就会跑偏。建议直接把理想的输出照着自己真实需求写一份放进 examples 文件夹。第三把失败案例变成新的指令。我有个习惯每次看到不满意的输出会顺手把这次哪里不对写成一条负面指令补进边界。比如某次润色任务里我把原文里一个很生动的比喻改成了平铺直叙的一句话从那以后我在边界里加了一句保留原文的修辞手法不要擅自删除比喻、排比等表达方式。教训自然就沉淀成了规则。6.3 Skill 讲到的只有第一条规则后面的被忽略了如果你发现 Skill 的指令没被完整执行比如只执行了第一步后面重要的格式要求被跳过了大概率是指令写得太长太啰嗦关键信息密度太低。AI 在处理长文本时确实会有一个注意力衰减的问题不是它忘了而是后面的内容被前面的干扰了。解决办法有两个一是精简 SKILL.md 正文。能放 references 的参考资料就别放在正文里只保留最重要的信息。二是把最关键的输出格式要求放在文件的靠前位置把次要的背景说明往后放。注意输出格式尽量放在指令的中部而不是末尾因为 Claude 在生成最终回复时会重点读取最近和开头的内容放中部是最稳的。6.4 与其他配置冲突如果你同时设置了自定义指令Custom Instructions和其他全局规则有时会和 Skill 产生冲突。比如全局设定要求回答简洁而你的 Skill 要求输出详细的四段式周报这时候 Claude 可能会权衡两条规则导致 Skill 的输出被裁剪。我的处理原则是当冲突发生时Skill 的优先级应该高于全局设定。如果 Claude 没这么理解就在 SKILL.md 里明确加一句本 Skill 的输出要求优先于任何全局回答风格设定。实测下来这种显式的优先级声明通常能解决问题。7. 进阶心得让 Skills 真正成为你的外挂能力最后聊点我个人折腾这一段时间的真实体会。Skills 最妙的地方不在于让 AI 听话而在于它让你思考问题的过程变得可以复制了。以前你积累的是我自己会做某事现在你可以积累我做的这件事背后有一套方法论并且 AI 也学会了。写一个 Skill 的过程本质上是把你自己的隐性经验显性化。我自己保持的习惯是每当我连续三次以上用相同的方式向 Claude 提出同一类需求我就会停一下问自己——是不是该把这个需求固化成 Skill 了这是一个最低成本的判断标准。凡是重复出现的任务都值得沉淀成 Skill。另外建议你给自己的 Skills 定期做一次体检。我大概每个月会花半小时翻一遍已经建好的 Skills把那些从来没被触发过的删掉把那些输出质量不稳定的重新调整示例。Skill 不是越多越好而是越精越好。还有一个小技巧如果你和团队协作SKILL.md 文件本身就可以当作团队知识文档来管理。它结构清晰、格式统一新同事看了就能理解你们团队周报应该怎么记代码审查应该怎么做。这比存在某个人脑子里的经验可靠得多。我从最初的一时兴起研究这个功能到现在已经积累了一个覆盖写作、代码、管理、办公场景的小工具库。这个过程不需要什么编程基础也不需要懂 AI 原理最关键的就是这两件事一是按框架把指令写清楚二是用好示例让 AI 知道你要的效果长什么样。按这个方法去折腾你很快也能做出让自己用起来顺手的 Skill。