看到标题里的“收藏”两个字我大概能猜到你现在的状态AI大模型相关的内容看得越来越多真正能留在手边反复用的却没几个。这篇关于Claude Agent Skills的拆解我打算照着“一次讲透、当场上手”的标准来写核心就一句话——让Claude按照你预先设定好的流程去干活而不是你每次重新教它一遍。Claude Agent Skills是Claude平台里一套把工作流封装成“技能”的机制适合所有正在从“问一句、答一句”转向“让模型自动完成某类任务”的开发者尤其是刚入门不久的小白程序员。下文不需要你有深厚的算法基础只要会看一点YAML的基本格式沿着步骤操作就能落地先别急着划走。1. Skills到底解决什么问题1.1 从“提示词”到“技能”的认知转变很多朋友问我Prompt写得好好的为什么还要搞一个Skills出来这个问题的答案其实取决于你怎么看待“稳定输出”这件事。拿最日常的“写周报”举例。以前你用Prompt大概是这个流程先把周报模板粘进对话再解释数据从哪来、语气要什么风格、重点要突出哪些内容每一次都要重新说一遍。如果中途切换了对话你还得担心它把之前的格式忘了然后反复修正。这本质上是在“每次临时指挥”效果好坏全看你对提示词的表达功力运气成分很大。而Skills的思路完全不一样。你可以把“周报怎么写”这件事整体打包成一个技能模板、数据源说明、语气要求、常见坑位、输出结构全部写进一个名为SKILL.md的文件里。以后你只需要对Claude说一句“帮我写本周周报”它就自动加载这套流程直接按照你预定义的标准执行。一句话总结Prompt是口头交代Skill是标准作业程序。从这个角度看Skills是Claude把这个“类人协作”逻辑往前推了一大步。它把知识、规则和工作流从对话上下文里抽出来变成可复用、可管理、可迭代的独立单元。对于经常处理重复性事务的开发者来说这套机制节省的不只是时间更是精力——你不用每次“重新组织语言教育模型”模型已经学会了你的干活方式。1.2 Skills和Prompt、MCP、Projects这些概念怎么区分初学者最容易搞混的就是这一组概念Prompt、Skills、MCP、Projects。我用一个厨房的比喻来拆解Prompt是“口头点菜”你想吃什么直接告诉厨师完全依赖临场发挥。Skills是“标准菜谱”把每个菜的配方、火候、摆盘都写清楚厨师照着做稳定不跑偏。MCP是“外接食材库和工具架”模型可以从中获取外部数据、调用第三方服务比如查数据库、调API。Projects是“专属厨房工作台”你可以把某个项目相关的技能、资料、对话历史全都放在一起互不干扰。在实际使用中它们可以组合你在某项目的厨房里备好菜谱Skills接上食材库MCP然后开始让Claude处理一桌完整的宴席多轮Agent任务。Skills在其中扮演的是“步骤流程领域知识”的角色解决的是“模型如何按你的套路办事”这件事它不替代MCP也不替代Projects而是共同配合。理解了这层关系你再看官方文档里那些“在Projects中启用Skills”“在Claude Code中引入自定义技能”的说法就不会一头雾水了。Skills是独立的但它的使用场景通常附着在Projects或Claude Code中。1.3 谁适合现在就学先泼一盆冷水如果你平时只用Claude聊天、写写邮件那Skills对你暂时没有太大吸引力。它真正发力的场景是“重复性任务模型自动化”。但我依然建议所有小白程序员尽早接触原因有三第一门槛真的低不需要部署服务器不需要写复杂代码核心就是一个Markdown文件第二它能直接帮你把手头那些琐碎的事情自动化越早用越早受益第三Skills的设计思想——把隐性经验显性化——本身就是工程师应该培养的核心能力之一。做测试的可以把“缺陷报告编写规则”封装成技能做运维的可以把“日志排查流程”封装成技能做算法的可以把“数据预处理规范”封装成技能。无论你现在负责哪一块只要每天有重复性的输出型工作Skills就值得你花一下午研究。2. Skills的核心机制拆解2.1 SKILL.md“说明书”就是技能本身要理解Skills的工作原理先看一个核心文件SKILL.md。这个文件就是技能的大脑和说明书通常放在一个以技能名命名的目录下。Claude在执行任务时会先去定位并读取这个文件然后严格按照里面的指令来行动。SKILL.md开头的格式叫做YAML frontmatter也就是被两行---包起来的那部分元信息。最常见的几个字段是name技能名称必须唯一。Claude靠它来识别和索引技能。description技能的功能描述。这一项非常重要直接影响模型在什么场景下调用这个技能。描述越具体触发越准确。license可选字段声明技能的使用许可一般个人使用可以忽略或填一个“私用”。除了frontmatter文件正文就是指令主体。你需要用自然语言写清楚什么情况下使用这个技能、具体怎么做、有哪些步骤、输出格式是什么、有哪些注意事项。模型不会“猜”它只会照着文字执行。你写得多细它执行得多稳两者基本成正比。我第一次看到这套设计时第一个感觉是这不就是给模型写“操作手册”吗事实也确实如此。一个写得很好的SKILL.md就像一份新员工入职培训手册而Claude就是那个学习能力极强、但完全不懂职场潜规则的新人——它需要你把一切写明白。2.2 技能目录里的reference和scriptsSKILL.md不是孤零零存在的。官方推荐的技能目录结构大致是这样的skill-name/ ├── SKILL.md ├── references/ │ ├── template.md │ └── example_output.md ├── scripts/ │ └── helper.py └── assets/ └── icon.pngreferences目录用于存放参考资料、模板、样例输出之类的附属内容。比如“代码评审助手”技能可以把一份高标准的代码审查样例放在里面让Claude模仿那个风格。scripts目录存放实际可执行的脚本比如Python脚本、Shell脚本当技能需要跑一些本地逻辑时使用。assets目录一般放图片、资源文件。这引出一个实操建议别试图一开始就把所有目录都塞满。大多数场景下一个写清楚的SKILL.md加上几个参考资料就够用了。脚本是“锦上添花”当你发现纯文本指令无法满足需求、需要调用本地工具或进行精确计算时再考虑加也不迟。保持轻量才方便迭代。2.3 Claude是怎么“选中”你的技能的如果你想有效使用Skills最好理解一下背后的触发机制。Claude并不是把所有技能都读一遍而是根据用户的自然语言输入结合用户已有的技能库通过语义匹配来决定调用哪个技能。这个匹配的关键就是SKILL.md里的description字段。很多人踩过的一个坑是description写得太笼统。比如“用于代码评审。”那句话信息量太低了。模型看到“帮我看看这段代码”时可能并不知道该不该调用它。更好的写法是“当用户请求进行代码审查、查找潜在缺陷、识别安全风险或提出重构建议时使用此技能。适用于Python、JavaScript和TypeScript文件。”一旦描述里包含“何时使用”的触发条件和“适用于什么范围”的边界模型的触发准确率会高很多。所以记住一个原则description不是给读者看的是给模型的“检索关键词触发开关”写的。它要足够明确、可匹配、可判断。2.4 Skills能调用什么能力这里多说一句因为很多朋友搞不清Skills和普通对话的边界。Skills本身不改变Claude的基础能力——它仍然是一个对话模型仍然擅长文本理解与生成。但Skills可以组合三种额外的能力参考文件通过references目录附带示例、模板、规范文档让模型按照范例输出。脚本执行通过scripts目录调用Python、Shell等本地脚本处理计算、文件读写等任务。多技能协作一个技能的指令里可以明确要求先调用另一个技能A再调用技能B形成流程编排。换句话说Skills其实是一个“壳”把Claude的已有能力、你的业务规则、外部的工具脚本统一编排到一条确定性的执行路径里。理解了这一层你就能设计出远超“单条提示词”的复杂工作流。3. 从零写一个自己的Skill3.1 准备阶段先想清楚“边界”在动手写文件之前先做一件更重要的事明确这个技能要解决什么、不解决什么。我自己的经验是一个技能最好遵循三个原则——独特、高价值、不易混淆。“独特”是说这个技能能完成的事不应该用一句普通Prompt就能轻易做到它必须包含一定的固定流程或专属知识。“高价值”是说它最好对应你日常频繁处理的任务值得你花时间沉淀。“不易混淆”是说它的职能边界要清晰不能跟已有技能重叠否则模型在调用时会出现竞争。举个例子你每天都要做接口测试可以把“接口测试用例生成器”做成一个技能。它内部包含你团队常用的测试用例模板、字段覆盖策略、边界值分析规则甚至能调用一个脚本自动生成部分测试数据。这就是一个好的技能候选因为它沉淀了你的方法论而不是一句“帮我写测试用例”能覆盖的。3.2 目录结构搭建一个文件夹就是一门手艺想好边界后就创建目录。以“周报助手”为例在本地建一个叫weekly-report-assistant的文件夹然后按规范建好子目录mkdir -p weekly-report-assistant/references mkdir -p weekly-report-assistant/scripts mkdir -p weekly-report-assistant/assets也许你觉得多此一举但我建议保留references目录的初始化习惯。即使刚开始用不上后续维护也会方便很多。实践一段时间后你会发现技能是否被经常使用很大程度上取决于它是否有足够好的参考样例而references就是放这些样例的地方。3.3 编写SKILL.md的完整步骤打开编辑器创建SKILL.md文件。第一步是写frontmatter--- name: weekly-report-assistant description: 当用户需要生成周报、整理本周工作内容、总结项目进展、评估下周计划时使用。该技能会帮助用户将零散的工作记录按照指定模板整合为结构清晰的周报。 ---然后是正文部分。正文是给Claude看的操作指令我建议按这个结构组织什么时候用、做什么、怎么做、注意事项、示例。完整的SKILL.md大致长这样# 周报助手 ## 用途 当用户要求生成周报时按以下流程处理。 ## 输入要求 询问或确认用户提供以下信息 1. 本周完成的工作事项按项目和类型分组 2. 下周计划安排 3. 本周遇到的问题及处理结果 ## 操作步骤 1. 将工作事项按类型分类开发、测试、会议、文档、其他。 2. 按时间倒序排列优先展示最近完成的事项。 3. 使用简洁的动词开头例如“完成”“推进”“解决”。 4. 对于未完成事项明确标注“进行中”并说明当前进度。 5. 生成输出时严格遵循以下模板。 ## 输出模板 ### 本周总结 - 开发xxx - 测试xxx - 会议xxx ### 本周问题与反思 - 问题(描述现象) - 处理状态(已解决/进行中) ### 下周计划 1. xxx 2. xxx ## 注意事项 - 不得编造用户未提供的工作事项。 - 如果用户提供的信息不足必须主动询问补齐再输出。 - 输出语言与用户输入语言保持一致。看到这里你应该会有一种感觉这像在写“给机器人的工作手册”。没错这就是核心。Skills的好坏基本就取决于你写“手册”的能力。3.4 安装和测试让Claude认领技能文件写好后怎么让它生效具体操作取决于你用的是Claude.ai还是Claude Code。在Claude.ai的Projects中可以在项目设置里找到Skills相关选项上传或关联你的技能目录。在Claude Code中你可以通过配置CLAUDE.md文件把技能目录路径告诉它或者在初始化时指定加载自定义技能。安装完成后的测试环节很多人会忽略。我强烈建议你做一个“无技能基线对比”先在没有启用该技能的情况下直接问同样的问题记录它给出的回答然后启用技能问同一个问题再记录回答。两者一对比你会立刻看出技能带来的差异——有没有遵循模板、有没有执行步骤、有没有漏掉注意事项。如果差异不明显说明技能写得还不够细需要继续迭代。这种对比习惯非常重要它能帮你始终保持对技能效果的敏感度避免辛辛苦苦做完一个技能结果不知道它到底起没起作用。4. 实战做一个“代码评审助手”Skill4.1 场景描述与需求拆解前面讲原理比较多下面我用一个完整实例带你走一遍从零到一的过程。这个实例是“代码评审助手”适用场景非常普遍。先拆解需求我们希望这个技能能够审查用户粘贴的代码按标准输出一个结构化的代码评审结果内容包括问题等级、问题描述、修改建议。它跟普通Prompt的区别在于技能内部会定义一套完整的“评审维度”比如代码规范、潜在Bug、性能隐患、安全风险、可维护性等等。这样每次评审时模型都会按照同一个框架来分析不会漏掉关键维度。4.2 完整配置与代码准备创建目录结构mkdir -p code-review-assistant/references mkdir -p code-review-assistant/scripts然后写SKILL.md--- name: code-review-assistant description: 当用户请求进行代码审查、查找潜在缺陷、识别性能问题、检查代码规范或提出重构建议时使用。适用于Python、JavaScript、TypeScript、Java等常见编程语言。不要用于解释代码逻辑、生成新代码或编写测试用例。 license: private ---正文部分加上清晰的步骤和评审维度# 代码审查助手 ## 审查步骤 1. 通读用户提交的代码了解整体功能和逻辑。 2. 按以下维度逐项检查 - 代码规范命名是否清晰、缩进和格式是否统一、是否存在死代码。 - 潜在Bug是否存在边界条件未处理、空指针/未定义访问、逻辑判断错误。 - 性能隐患是否存在循环内重复计算、不必要的递归、没有限制的查询。 - 安全风险是否有可能的注入攻击、敏感信息硬编码、权限校验缺失。 3. 根据严重程度为每个问题分配等级严重/一般/建议三个级别。 ## 输出格式 ### 总结 - 整体评价(一段不超过120字的总评) - 高风险问题数(数字) ### 问题清单 按严重等级从高到低排列每条使用如下格式 1. [等级] 位置问题描述 - 原因(说明为什么会出问题) - 建议(给出具体修改方式) ## 注意事项 - 只审查用户明确贴出的代码片段不要假设不存在的上下文。 - 输出必须使用中文。 - 不要修改用户的代码只给出建议。为了丰富技能我还在references里放了一份示例审查报告让模型参考输出风格。# references/example.md 以下是一个审查结果示例用于展示输出格式 ### 总结 整体功能实现清晰但在异常处理和数据校验上存在明显不足建议上线前修复高风险问题。 ### 问题清单 1. [严重] 第23行未对输入参数做非空校验 - 原因当参数为null时会抛出未捕获异常 - 建议增加前置校验并返回友好的错误信息这里为什么没有写scripts因为“代码评审”本质上是基于语言理解与逻辑推理的任务Claude自身就能完成不需要外部脚本介入。如果你希望它能自动读取某个路径下的文件那才需要写一个脚本作为辅助。这个判断思路也值得你借鉴能用模型能力直接完成的就不额外引入工具层保持简单。4.3 使用效果与细节打磨我实际测试这个技能时验证工作流很简单贴一段带有多处坑点的Python代码模型按要求输出了结构化的审查报告问题清单按照“严重/一般/建议”进行了分级并且每条问题都附了修改建议。与没启用技能时的回答相比差异非常明显——普通问答模式下模型往往只是笼统点评“代码有一定问题”而启用技能后输出是严格的清单式评审几乎没有漏项。当然第一版远称不上完美。我在使用中发现它有时会忽略“输出必须使用中文”这条规则用户输入是英文时输出会跟着变英文。解决方法是把注意项的措辞改成更强硬的约束比如“无论用户输入什么语言输出一律使用中文。这是必须遵守的规则。”语气越直接模型的遵从度越高。这个细微差别在普通对话里无所谓在技能指令里就是决定性的。在迭代技能的过程中我还形成了一套优化节奏每实际使用3次左右就把发现的问题和改进点记录下来每周集中修改一次SKILL.md。这样既不会频繁改动导致不稳定也不会让技能长期停留在粗糙的初版状态。5. 进阶心得让Skill真正好用的细节5.1 描述词怎么写才“准”而不是“长”在最前面说过description是触发开关但很多新手容易走另一个极端——把description写成一段小作文。其实不需要你只需要精确不需要全面。好的description应该包含三要素触发场景、技能能力范围、不适用场景可选。反例“该技能用于代码审查涵盖各种编程语言提供全面的代码分析服务帮助开发者提升代码质量……”这句话太长且没有触发感。正例“当用户要求审查代码、查找缺陷、优化性能或重构建议时使用。支持Python/JavaScript/TypeScript。不用于解释代码思路或生成注释。”我实测下来加上“不用于什么”反而能提高触发准确率因为这种否定约束给了模型更清晰的边界信息减少了误调用。5.2 别急着把什么都封装成技能有些朋友学会Skills之后恨不得把所有日常任务都做成技能。这种热情我理解但我也见过不少反面教材技能库里堆了几十个名字花哨但不常用、维护也跟不上变化的“僵尸技能”。结果模型在选技能时多了一个不确定项反而降低整体体验。我的建议是技能的数量要克制。一个新技能必须满足“至少每周用一次”的频率才有封装的必要。如果你的任务是“偶尔才做一次”那直接用Prompt来对话反而更灵活。技能本质上是为了沉淀固定的高频工作流而不是取代所有对话。那低频但重要的流程怎么办你依然可以用一个“通用流程技能”来承载比如“任务处理大师”里面写清楚拆解任务、分步骤执行、复盘总结的通则然后针对不同任务临时补充规则。这种方式更灵活也更容易维护。5.3 多技能协作的经验当技能数量慢慢积累起来以后你可能会需要“技能组合拳”。比如写一个“会议纪要生成助手”技能后你可以再设计一个“周报生成助手”技能并且在周报技能的指令里明确写上首先调用会议纪要技能提取本周会议内容然后调用工作总结技能生成工作条目。这样Claude就能自动串联多个技能输出一份整合度非常高的周报。实操时要注意顺序。技能A引用技能B时一定要在A的SKILL.md里指定B的调用条件和时机否则模型可能会跳过、颠倒顺序。一个技巧是在需要用到的步骤前写上加粗提示句“先处理会议纪要技能的输出再进入下一环节”。指令越明确协作越稳定。5.4 版本管理与备份最后一个小建议但非常实用——给SKILL.md加上版本号。你可以在frontmatter里增加一个version: 1.0字段或者直接在文件头部写一句“最近更新时间2025-xx-xx”。这样当模型输出效果变差时你能快速回溯到之前可用的版本找出是哪次改动引入的“退化”。不要相信自己的记忆文件迭代没有版本管理早晚会吃大亏。6. 常见问题与排查6.1 技能不触发这是被问得最多的一个问题。技能文件写好了目录也加载了但当你提出相关请求时模型完全没有按技能走。我遇到过的情况主要有三类一是description写得不够具体模型没有在技能库里“匹配”到它二是目录结构放错了位置或者技能没有正确加载到当前的Projects/会话中三是技能本身存在的优先级不够用户在对话中表达的意图比较模糊模型优先走了普通对话路径。排查顺序建议是先检查加载状态确认当前会话能看到这个技能名称再检查description把它跟你的提问语句对比一下看是否足够吻合最后检查目录结构和文件名是否规范。6.2 技能执行一半跑偏有时候技能确实触发了但执行到中途模型开始自由发挥脱离了设定的输出格式。这往往是因为SKILL.md里的指令按优先级来看不够强。比如你写了“请按模板输出”模型可能觉得用户刚才那句话优先级更高于是打乱了模板。解决办法是在关键步骤上增加“约束型表述”例如“必须严格使用上述模板”、“不得自定义其他格式”、“无论用户提出何种补充要求都要保留以下结构”。我在实际使用中这些强约束词对稳定性的提升非常明显。6.3 更新技能后没生效修改了SKILL.md但测试时发现模型的表现跟修改前没什么两样。这里有一个可能的原因模型在会话中读取技能文件时可能命中较早的缓存版本你需要开一个新的对话或者重新加载技能。技能更新后最好先新建对话测试避免上下文污染。另外如果技能目录内存在多个SKILL.md或者目录路径包含特殊字符也可能导致加载异常。建议文件路径只使用英文小写字母、数字和短横线。6.4 常见问题速查表问题可能原因解决方法技能没有被触发description描述过于笼统或缺少触发词在description中增加“当用户…时使用”句式明确场景与范围技能加载失败目录位置不对、文件名错误检查技能目录是否在正确路径确认文件名严格为SKILL.md执行格式不稳定指令约束力不足在SKILL.md中使用“必须”“不得”“一律”等强约束措辞更新后无效当前会话仍使用旧缓存开新对话测试或重新加载技能多个技能互相干扰技能职责重叠、边界不清合并同类技能或在description中写明不适用场景输出语言不对缺少输出语言约束在注意事项中明确“输出必须使用中文/英文”6.5 一个容易被忽略的变量最后说一个容易被忽略的点Skills运行的稳定性不仅取决于技能本身也取决于模型当前的基础能力版本。同样的技能在不同时间、不同模型参数下执行效果可能会有细微差异。所以不要一看到输出异常就急着改技能文件先多测试几次确认是稳定复现再动手修改。如果是偶发问题很可能是模型行为波动不是你写得不好。我个人在实际操作中养成的习惯是每次修改技能后连续测试三轮相同请求记录输出的一致程度。差异大就继续优化非常稳定就暂时放着不折腾。这套“少改动、多观察、按需迭代”的方法帮我避免了不少过度调整带来的麻烦。如果你也准备开始做自己的第一个技能我的建议是从你最痛苦的重复任务入手可能是月报整理可能是代码审查也可能是接口日志分析。不要贪多就挑一个把它写到“机器照着做基本不出错”的程度。等你完整走完一遍从设计、编写、测试到迭代的过程后面再扩展技能库就是顺手的事了。