每天都要花十分钟告诉 AI 你是谁、要干嘛、输出什么格式的人一定会在看到 Claude Skills 的那一刻拍大腿这不就是我一直在手动做的事吗作为一个几乎把 Claude 当成第二个工作台来用的人我过去一年里最大的时间黑洞不是写需求、不是调代码而是反复向 AI 解释规则。每次换新对话我都得像第一次见面一样把我的身份背景、任务要求、输出格式、禁忌事项重新说一遍。后来我甚至把这段自我介绍存成了一个长文本每次对话开头直接粘贴结果它越来越长越来越难维护还会在复制粘贴的过程中莫名弄丢几行关键规则。Claude Skills 解决的就是这个问题。它把身份设定 执行步骤 输出规范 质量检查清单打包成一个独立的技能文件放进指定目录后Claude 就能在相关任务出现时自动调用或者在对话里直接唤起。这相当于给 AI 装了一本可随时翻阅的岗位手册而不是只给它一句口头交代。这篇文章我会从原理、编写方法、真实场景、避坑经验一路讲到我自己的技能管理节奏看完你就能自己动手写一套趁手的技能包。1. 为什么需要把说话方式打包成技能文件1.1 我每天重复的那句提示词就是最早的技能你回想一下自己平时是怎么用 AI 的。是不是经常这样开头你是一个资深的公众号编辑请帮我写一篇关于XX的文章要求标题吸引人、正文口语化、段落不能太长最好再给三个备选标题。这种提示词说得好听叫自定义指令说得直白点就是一次性的口头交代。问题在于每次开新对话这个口头交代都要重新来一遍。哪怕你已经把这句话优化得非常完善换一个会话又要重新粘贴。更麻烦的是如果你今天既要写公众号文章又要做会议纪要还要审一段代码你要么在同一个对话里反复切换角色要么开好几个对话分别解释规则。前者会让上下文变得混乱后者则是一遍遍重复劳动。我有一段时间就是这么干的。写文章用一个固定开头写周报用另一个固定开头做竞品分析再用第三个固定开头。每次粘贴大段提示词的时候我心里都在想这些东西本质上不就是一个技能吗为什么不能让 AI 自己记住呢当时我也尝试过把提示词保存成笔记文件需要的时候打开复制但复制模板的过程依然很烦而且模板本身也会过期。1.2 Claude Skills 到底改变了什么从临时指令到可复用资产Claude Skills 出现之后我整个使用习惯都被重构了。它的逻辑其实很简单把一段完整的工作方法写成一个 Markdown 文件核心文件名通常叫 SKILL.md放到 Claude 能读取的技能目录里。以后当我让 Claude 做某类事情时只要对话内容跟技能的描述能匹配上它就会自动加载这个技能文件然后按文件里写好的流程来执行。这个转变看起来只是把粘贴提示词变成了保存技能文件但本质上是两套完全不同的心智模型。过去我的提示词是放在对话里的它是上下文的一部分会随着对话变长而稀释也会因为后面聊了别的事情而跑偏。而技能文件是放在对话之外的它像一份固定的操作规程Claude 每次执行任务时都能回到文件本身去查阅不会因为聊了半小时天气就把你的输出规则忘掉。另一个核心区别是复用性。一个写好的技能文件不仅能在你自己的所有对话里被调用还能复制给别人或者从社区里安装别人做好的技能。我第一次从朋友那里拿到一个做会议纪要的技能时感觉就像拿到了一份免费的岗位培训手册——里面不仅写了纪要格式还写了怎么提炼决策项、怎么区分待办和知会。这种东西靠口头提示词是很难完整传递的因为它太长了长到没人愿意每次手打一遍而技能文件天然就是为了承载这种长度的。2. Claude Skills 与一堆相关概念的边界别把它们混为一谈网上讨论 Claude Skills 的时候经常有人把它和自定义指令、MCP、Project 混在一起说。我在实际使用中踩过不少混淆的坑这里把边界彻底捋清楚。2.1 它和自定义指令Custom Instructions的差异粒度完全不同自定义指令是全局的一旦设置好它会在你所有对话里默默生效相当于给 AI 设定了一个基础人格。它的优势是省事劣势也正是因为它太全局了——你今天聊编程它带着你的文风要轻松活泼这种全局设定明天聊数据分析它还是带着这套设定。Skills 则完全不同。它是按需触发的一个技能只负责一个特定场景彼此之间互不干扰。我可以同时装代码审查技能周报生成技能文章润色技能这三个技能可以有不同的角色设定、完全不同甚至互相矛盾的输出要求但只要触发条件设置得合理它们就不会打架。打个比方自定义指令像是给员工统一配发的工牌上面写的是公司价值观而 Skills 像是不同岗位的操作手册财务有财务的SOP运营有运营的SOP。空泛的价值观不能替代具体的操作手册反过来也一样。2.2 它和 MCP / 工具调用的关系Skills 不是工具是用工具的说明书很多人第一次接触 Skills 时看到里面可以指定要调用外部工具误以为 Skills 就是 MCP模型上下文协议或者说是某种工具插件。实际上这俩是完全不同的层次。MCP 或者普通的工具调用解决的是AI 能操作什么外部系统的问题比如读数据库、调API、查文件。它像是给 AI 接上了手和脚。Skills 解决的是AI 应该怎么思考和干活的问题它定义的是流程、规则、判断标准、输出模板相当于给 AI 一份用脚手做事的方法论。更好的理解方式是工具给你的是可能性技能给你的是纪律。比如我电脑里装了一个可以跑代码的工具如果没有技能约束AI 可能会写一段能跑但是毫无代码风格可言的脚本而一旦我加载了项目代码规范技能它就知道跑测试之前先看 lint提交代码之前要先写 changelog。工具本身不会教它做这些事这些只能靠技能文件里的文字规则来约束。2.3 它和 Project项目的差异一个打包给工作区一个打包给模型如果你用过 Claude 的 Project 功能可能也疑惑过Project 里也能配置指令和知识库是不是有 Skills 就够了我的体会是两者解决的问题完全不同。Project 更像是围绕一个具体工作建立的信息环境。你可以在里面放参考文档、设定这组对话的知识背景让 Claude 在这个项目的语境里干活。它的核心是信息——和这个项目相关的资料都堆在这里。而 Skills 的核心是行为——不管在哪个项目里只要需要做这类任务这套行为标准都能通用。一个典型的例子我写代码时会遇到两个项目一个用 React一个用 Vue。它们都有自己的 Project里面放了各自的技术文档。但代码审查这个行为在两个项目里是高度相似的都要检查边界条件都要看错误处理是否完整都要确认命名规范。所以代码审查技能只需要写一份放在全局技能目录里任何项目都能用。Project 管的是你在做什么Skills 管的是你该怎么做。3. 手把手编写第一个 Skill从需求拆解到文件落盘下面这部分是重点。我会拿会议纪要技能来做例子完整走一遍从需求拆解到文件写好的全过程。3.1 准备工作搞清楚 Claude Skills 的存放位置与结构不同客户端安装 Skills 的入口有差异但绝大多数情况下技能都是放在某个固定的目录下的比如~/.claude/skills/这一类路径。每个技能占一个文件夹文件夹名字就是技能名里面至少有一个 SKILL.md 文件。你也可以在同一文件夹里放一些辅助文件比如示例数据、提示词模板、参考范文等这些文件在技能被触发时同样会被加载供模型查阅。如果你是第一次接触建议先别急着手工建目录先在 Claude 的设置界面里找到技能管理入口看看当前版本支持的目录路径和命名规范。不同版本的入口位置可能不一样但机制基本一致你需要在指定目录下创建一个技能一个文件夹的结构。示例结构如下~/.claude/skills/ ├── meeting-notes/ │ ├── SKILL.md │ └── template.md ├── code-reviewer/ │ └── SKILL.md └── writing-assistant/ └── SKILL.md也就是说meeting-notes这个技能文件夹里可以只放一个 SKILL.md也可以再加一个 template.md 作为纪要模板。文件放好后到设置里刷新一下技能列表就能看到新技能了。3.2 第一步把任务场景拆成触发条件、执行步骤、输出模板三块任何技能在动笔写之前都要先想清楚三件事什么时候用它、做了哪些步骤、最后交付什么。我习惯用一个很笨的办法先不开技能直接手动开一个对话以正常聊天的方式让 Claude 帮你处理一次这个任务然后把过程记录下来。记录时特别留意这三个环节。以会议纪要为例。触发条件很简单用户提供一段会议录音转写文本或者粘贴一堆聊天记录并明确说帮我做会议记录。执行步骤则可以拆成先通读全文提取参会人和讨论主题然后按议程梳理讨论过程最后标记结论、待办事项、负责人和截止时间。输出模板则是一份标准的会议纪要格式会议主题、时间、参与人、讨论要点、决策项、行动项。为什么要在动手写之前先拆这三块因为技能文件最容易犯的错就是只写目标不写步骤。如果你只在文件里说你是一个会议纪要助手模型确实能干活但它的干活方式每次都会漂移。只有把步骤和模板都写清楚了输出质量才能稳定。3.3 第二步在 SKILL.md 里写清楚人设规矩与心法SKILL.md 本质上就是一个 Markdown 文件前半部分通常有一段元信息描述用来说明这个技能的名称和用途后半部分是正文也就是你要交给 Claude 的具体指令。我可以给你一个可以直接套用的骨架--- name: meeting-notes description: 当用户需要整理会议记录、生成纪要、提取行动项时使用。适用于会议录音转写、聊天记录整理等场景。 --- # 角色 你是一位经验丰富的会议纪要整理专家擅长从冗长混乱的对话中提炼有效信息。 # 执行步骤 1. 通读用户提供的全部对话内容识别会议主题和参会人。 2. 按讨论顺序梳理主要议题删除与议题无关的闲聊内容。 3. 对每个议题提炼讨论要点标注出各方观点和分歧。 4. 识别明确的结论和待办事项整理成行动项表格。 # 输出格式 输出一份结构化的会议纪要包含以下章节 - 会议主题 - 参会人 - 讨论要点 - 结论与决策 - 行动项含负责人和截止时间 # 注意事项 - 如果原文中没有明确截止时间不要编造标注待确认。 - 行动项要具体到负责人找不到负责人的写待指派。 - 保持客观中立不使用口语化评价。写这份文件最核心的心法是把你自己希望 AI 怎么做事的标准都变成明确的句子而不是模糊的形容词。不要写要专业要写清楚什么叫专业比如结论要和讨论过程分开、行动项必须包含负责人。技能文件不怕啰嗦怕的是含糊。3.4 第三步用实际对话反复测试、迭代版本写完第一次版本之后一定不要直接宣布成功。我每次新写一个技能都要准备一组真实的历史数据来测。比如写会议纪要技能就找一段以前开会的对话记录喂进去看输出是不是符合预期。测试时重点关注三个维度第一技能有没有被正确触发。如果我在对话里只说帮我总结一下这段聊天记录没提会议两个字它还会不会主动加载这个技能第二执行步骤有没有被完整走完。如果模型看到步骤一就直接跳到输出说明步骤写得太轻。第三输出格式是否完全遵守。有些技能写得很细模型却容易在最后一个环节放飞自我这时候就该把输出模板的示例放在显眼位置。迭代不是一次性的。我用一个新技能的前两周基本上每隔几天就会改一次 SKILL.md要么是把新增的例子补充进去要么是删掉那些让 AI 过度发挥的啰嗦指令。这个习惯比写作本身更重要。4. 几个真实场景的 Skills 示例与拆解光讲方法论很难让人真正上手我把我常用的几个技能拆开来展示一下。不是让你照抄而是看一个成熟的技能文件长什么样。4.1 编程代码审查技能我做代码审查技能时最核心的写法是把多年的 code review 经验变成可检查的清单。单纯说请审查这段代码是没有意义的模型只会给你一些正确的废话。所以我把审查过程拆成了几个层次--- name: code-reviewer description: 当用户提供代码片段或 PR 变更要求审查代码质量时使用。 --- # 执行流程 1. 先通读代码理解功能意图直到能用自己的话概括这段代码要做什么。 2. 检查正确性边界条件、空值处理、异常分支是否完整。 3. 检查可维护性命名、函数拆分、重复代码、注释质量。 4. 检查性能隐患不必要的循环、明显的重复计算。 5. 输出分级问题列表严重问题、建议修改、风格优化。这是最有价值的一步不要直接让 AI 输出代码很好或者有几个小问题而是规定它先理解再检查再分级输出。分级列表非常关键否则所有问题都会被平铺成一大段项目经理根本没法判断优先级。4.2 个人周报生成技能周报技能是我用得最频繁的一个。它最大的难点不是格式而是如何从一堆工作记录里识别值得一提的成果。我的技能文件里专门有一段写筛选标准只有对业务有明显改进、或者解决了关键问题的工作才值得写进重点成果零散的日常沟通不算成果。这个筛选标准如果不写清楚AI 就会把所有事情都平铺直叙地列进去周报变成了流水账。而一旦写清楚AI 就会主动帮你做增量筛选。所以你看技能文件里的心法往往比步骤更值钱。我还在技能里加了一个强制规则最终输出的周报里至少要有一个量化指标实在没有量化条件的就写进度状态不能写正常推进四个字敷衍过去。4.3 内容平台风格化写作技能做内容的人应该都会喜欢这个场景。我给 AI 设计写作技能的时候刻意规避了写一篇爆款文章这种空泛目标而是把风格拆成了非常具体的约束条件。比如我写小红书风格的技能时文件里会规定开头前两行必须出现你也能用这种利他感很强的句子正文必须分成短段落且每段不超过三行结尾必须引导用户收藏或关注但不能用家人们这种烂大街说法。你看这些约束看起来很小但它们加起来就决定了一篇文章是否像真人写的。一个很重要的经验风格类技能要多给正反例。我在 SKILL.md 里专门放了两段对比示例一段是看了就划走的机械文案一段是让人愿意读到底的自然文案然后告诉 AI 输出要靠近后者。模型看到具体例子之后风格还原度会明显高于只听抽象描述。4.4 数据整理与报表技能数据清洗这类技能和前面几种不同它更依赖确定的规则。我做一个周期性销售数据整理技能时把步骤写成了几乎接近程序逻辑的流程先识别表头再检查缺失值和空值再按指定维度做透视汇总最后生成结论摘要。这种技能最大的坑是模型会在默认情况下帮你脑补数据。比如某一列数据缺失了它可能默认按零处理然后在结论里告诉你同比上升。所以我在这类技能的注意事项里永远会写一句任何缺失值必须在输出中明确标出禁止猜测补全所有计算必须显示计算依据。我建议你做类似技能时把不许做什么放在要做什么的前面。数据类任务的容错率很低防呆规则比效率规则更重要。5. 安装、切换、共享Skill 的日常管理与避坑5.1 从社区安装 Skill 时的资质审查要点现在网上已经有不少人分享自己的技能文件可以直接克隆到目录里使用但千万别看到一个标题就无脑安装。我身边就有朋友因为装了一个万能提示词技能结果后续对话质量反而严重下降因为那个技能文件里写了一大堆互相矛盾的规则。从陌生来源安装技能时我必做三件事第一打开 SKILL.md 全文通读看它的指令是不是和你的使用场景匹配第二特别留意有没有忽略之前的指令这类改写性描述这种句子要么是调试残留要么是刻意做Prompt注入攻击第三先在一个非关键任务里测试一轮不要直接让它在重要任务中生效。技能文件本质上是可执行的行为逻辑它的重要性相当于一个脚本你不能运行不看内容的脚本。5.2 为什么技能没生效往往不是格式问题而是触发问题通常在社区里最常见的求助帖是我已经把技能放到目录里了刷新也刷新了但它就是不触发。这种情况九成不是文件格式问题而是描述信息没写好。技能触发靠的是 SKILL.md 头部的 description 字段与用户对话之间的语义匹配。如果你把 description 写得太窄比如只写了当用户提到周报两个字时使用那用户实际说的是帮我写一下本周工作总结技能就不会被唤起。反过来如果 description 写得太宽比如动不动就写所有分析任务都使用本技能那么它会被频繁误触发后面你还得手动关闭更麻烦。我的经验是description 里必须写至少两个常见的同义说法宁可多列几种表达方式也不要漏掉用户可能会说的一个词。触发逻辑是语义匹配不是关键词匹配所以写得太死的效果更差。5.3 最容易把技能写烂的三种错误写法我看了不下几十份别人写的 SKILL.md总结了三种最常见的翻车写法。第一种是功能堆叠。一个技能文件夹里既写代码审查又写简历制作还指导用户怎么养猫。模型加载这个技能后反而不知道该优先执行哪套规矩。技能一定要窄一个技能只负责一类任务。第二种是只给目标不给流程。比如你是资深运营请把文章改得更好这句话放在技能文件里等于没写。模型确实能改但它不知道怎么改才算更好输出只能靠猜。好的技能要有可以逐步执行的步骤哪怕是先列出现有标题再写五个优化方向再选择最优这样简单的流程。第三种是没有任何约束条件。技能文件只告诉模型做什么完全没写不做什么。这会导致 AI 在边界处放飞自我。比如写作技能没写不要编造数据和案例AI 就可能在文章里虚构一个不存在的调查结果。约束和步骤同样重要。6. 我的实战心得值得构建的技能矩阵和迭代节奏6.1 不同身份角色的技能矩阵建议如果你还是不知道从哪下手我建议别一次性写十个技能而是先想想自己一周之内重复了哪些明明做过很多次、却每一次都要重新讲一遍规则的事。这些事情才是你第一批发力点。我从不同角色角度给你列一个参考矩阵。内容创作者可以优先做文章风格化写作、标题生成、选题头脑风暴、竞品拆解。程序员可以优先做代码审查、错误信息解读、重构建议、commit message 生成。运营岗可以优先做活动复盘、数据周报、用户反馈归类。研究者可以优先做文献摘要、论点梳理、报告润色。这些技能有一个共性它们都是骨架稳定但内容多变的任务。所谓骨架稳定指的是你每次都要遵循同样的步骤和输出规范内容多变则是说每次处理的具体材料不同。这种任务特别适合做成技能因为你的经验可以直接沉淀成规则减少每次从头思考的成本。6.2 我的迭代节奏先手动跑通再固化成技能最后聊聊我自己管理技能的节奏。我现在不会看到一个新场景就立刻写技能而是坚持一条简单原则同一个任务类型如果我在两周之内手动做了三次以上我就会专门开一个对话先手动把流程走一遍然后把每一步需要 AI 执行的规则记录下来整理成 SKILL.md。这看起来比直接套用网上的模板要慢但它有一个巨大的好处你写出来的技能文件是从真实需求里长出来的它只包含你真正用得上的规则不会有一堆看着有用但实际用不上的花哨配置。我的技能目录里也淘汰过很多版本每次淘汰都不是因为功能坏了而是因为我在真实使用中发现那个技能被调用得太少不值得维护。现在每次想写新技能时我都会先问自己一句这个流程如果一周要做两次以上我就该固化下来。如果一个任务只是偶尔做一次那就让 AI 用通用能力自由发挥吧技能带来的稳定反而会变成拖累。真正好的技能库永远是在够用和简洁之间找到了自己的平衡。