看了很多文章依旧不会写skill？实战分享

如何打造一个真正智能、稳定且可维护的AI技能？本文深度解析Skill的核心结构、最佳实践与常见陷阱，从逆向工程到主动梳理，教你如何将重复工作流程转化为高效自动化方案。更包含渐进式披露机制、评估驱动开发等进阶技巧，助你突破AI协作的瓶颈。

写一个Skill本身其实并不难。

难的是，写出一个不需要你每次主动提醒，Agent在需要的时候就能自动触发，并且产出稳定、长期且还能被人维护的Skill。

今天这期内容，我会从什么时候应该做Skill开始讲起，一路讲到具体的制作方法，几个常见的坑以及找到skill后，怎么改成自己的skill。

文章内容有点长，认真读完，你一定有所收获。

一、先搞懂：Skill到底是什么？

Skill本质上就是一个文件夹。

长下面这样。

重点讲三个东西。

1.SKILL.md

这是整个Skill最核心的文件。

里面包含YAMLfrontmatter和Markdown指令。

文件最上面的那一段是YAMLfrontmatter，里面一般会包含这个Skill的名字和描述。

下面的正文部分，就是你要教给Agent的方法、原则和执行方式。

2.references文件夹

这里一般用来放规则、知识库、业务说明、风格指南等资料。

比如不是每次执行都需要加载的文件，就可以放在这里。

3.scripts文件夹

这里放的是Agent可以直接执行的脚本。

比如你有一套固定流程，希望用更传统、更稳定的方式来保证标准化，那就可以把这部分逻辑写成脚本。

这样Agent不需要自己临场判断，只要执行脚本就可以了。

这个结构背后，有一个很有意思的机制，叫做渐进式披露。

简单来说，它分成三层。

第一层，Claude启动时，每个Skill只会加载它的name和description。

让模型知道「系统里有这个Skill可以用」就够了。

第二层，当对话内容触发某个Skill时，才会加载完整的SKILL.md文件。

第三层，是references和scripts。

只有在真正需要使用skill的时候，Agent才会加载这些内容。

用不到的时候，它们不会占用上下文窗口。

二、判断时机：什么时候应该做一个Skill？

很多人遇到的第一个难点，就是完全不知道从哪里开始。

要解决这个问题，重点不是先研究技术，而是复盘你自己现有的工作流。

有没有这类的工作？

1.高频重复，步骤固定

如果你发现某一类任务会反复出现，而且每次的执行流程都差不多，你总是需要在不同对话里重复输入相同的提示词、规则和要求。

那这件事就很适合被封装成Skill。

2.里面包含你的业务经验

也就是你做事情时的SOP流程、偏好和判断标准。

比如你们公司的内部文档格式、数据统计口径、汇报习惯、交付标准等等。

agent不知道这些信息，每次你都要在对话里重新解释一遍。

如果把这些内容做成Skill，AI就能学会你的业务逻辑和业务知识，帮你省掉大量重复沟通的时间。

3.出错成本比较高

如果某个任务一旦出错，会带来明显麻烦，比如会影响对外交付、影响团队协作，或者返工成本很高，那也适合做成Skill。

因为Skill可以帮助你强制规范执行流程，减少agent自由发挥带来的不稳定。

所以简单总结一下，适合做Skill的任务通常有三个特征：

高频触发、有专属业务知识、出错成本高。

只要满足以上一点，你就可以把它做成Skill，慢慢的用AI构建你的工作模式。

三、从0到1：制作Skill的两种方法

具体应该怎么做一个Skill？

我平时做Skill，主要有两种方法。

方法一：逆向工程

逆向工程是一个很适合新手的起点。

假设你今天上午开了一个新的对话，对Agent说：

我这周想写一篇公众号文章，主题是AIAgent落地。我希望文章里既要有观点，也要有实际案例，最后还能整理成适合公众号发布的结构。请你先帮我梳理最近收集的几篇参考资料，再分析里面有哪些值得展开的角度，最后帮我生成一份文章大纲和初稿。

这个过程中，AI可能会跑题，可能会把文章写得太像资料总结，也可能会抓不到你真正想表达的核心观点。

于是你们协作了一个小时，不断调整选题角度、文章结构、标题表达和段落语气，最后终于完成了一篇你比较满意的初稿。

这个时候千万不要急着把这个对话关掉。

因为这段对话就是最有价值的上下文。

这时你可以直接让AI帮你把刚才的流程沉淀成一个Skill。

你可以直接说：

请使用skillcreatorskill，把我们刚刚的对话转换成一份可以重复使用的Skill。

确保下次我遇到同类公众号文章创作任务时，不需要像刚才那样反复调整选题、结构、观点和语气。

方法二：主动梳理

适合那种你脑子里已经有想法，但还没有真实执行过，也没有现成对话可以逆向工程的情况。

这时你要做的，就是把自己的目标、流程、难点都说清楚，让AI帮你整理成Skill。

我希望你帮我制作一份Skill，用来加快这个任务的执行速度，并且让文章质量更稳定。

我设想的流程是：先根据我提供的主题和素材，帮我判断最适合展开的文章角度；然后提炼核心观点，生成文章大纲；接着写出公众号风格的初稿；最后再检查标题、开头、结构、案例和结尾是否足够适合发布。

以上是我的初步想法。请你把它整理成一份以后可以重复执行的Skill。

在开始之前，如果有任何不清楚的地方，请先向我确认，不要直接开始写。

当然，做Skill并不一定需要你自己亲手写完所有内容。

但这不代表你只需要动动嘴就可以。

在这个阶段，你最重要的任务，是把自己的意图、目标和约束讲清楚，让AI真正理解你想要的是什么。

很多人打开AI的时候，其实并没有想清楚自己到底要什么。

所以你要建立一个心态：

不要总问AI能帮你做什么。

而是反过来想：

我有没有把上下文、约束、方法和目标准备到足够清楚，让AI有机会成功交付？

换个更熟悉的说法：

我有没有说清楚这个功能解决什么问题，用户是谁，使用场景是什么，边界在哪里，验收标准清不清楚。

skill其实就是在给Agent写一份可以反复执行的“需求文档”。

产品经理把需求交给研发，Skill则是把你的工作方法交给Agent。

四、实用技巧：先让AI失败一次

这里再补充一个实践方法。

Anthropic官方把它叫做evaluation-drivendevelopment，可以理解为「评估驱动开发」。

意思是，在你做一个Skill之前，先让AI不带任何方法论地尝试执行一次任务。

你什么规则都不提供，让它自己做。

然后观察它会卡在哪里、哪里做得不好、哪里需要你补充。

这些卡点，才是你真正需要写进Skill里的内容。

不要一开始就凭空脑补一堆规则。

Skill的优化也是一样。

不要只是对AI说「再试一次」。

你要回头问：

到底缺的是什么？

是缺工具？缺规则？缺文件？还是缺一个更清楚的验收标准？

真正有效的Skill迭代，补的是系统缺口，而不是抽卡一样不断重跑。

很多人写Skill时，会塞进去一大堆AI本来就能自己判断的废话。

这样通常会带来两个问题。

第一，token消耗会变高。

第二，规则越多，Agent的灵活性越低。

五、使用过程中常见的坑

讲完制作方法，接下来讲几个最常见的坑。

第一个坑是：Agent不使用你的Skill。

你按照前面的方法做出了一版Skill，开心地把它放进文件夹里。然后开了一个新对话，提出一个相关需求。

结果Claude根本没触发这个Skill，而是直接开始自由发挥。

这个问题非常常见，尤其是当你的工作流比较复杂时。

如果你没办法清楚定义每个Skill的触发时机，Agent就很容易漏掉。

解决这个问题，关键在于Skill的description怎么写。

description怎么写？

在渐进式披露机制下，Claude启动时看到的不是完整Skill文件，而是每个Skill的name和description。

所以description是Agent判断是否要触发某个Skill的主要依据。

写description有三个规则。

第一，要同时包含「做什么」和「什么时候用」。第二，尽量用第三人称。第三，description要包含用户自然会说出来的触发词，而不是只写技术名词。

如果你已经这样写了，但Skill还是不容易被触发，可以检查两个问题。

1.description是不是太技术化？

比如用户平时会说「帮我做周报」，但你的触发词写的是「整理周报」。

这样Agent就需要多推理一层，才知道应该触发这个Skill。

2.description是不是太宽泛？

比如你写了一个“会议纪要整理”的Skill，本来是想让它在处理完整会议录音、会议文档时才触发。

结果用户只是随口问了一句：“帮我总结一下”，它也被调用了。

这就是过度触发。

问题不在Skill本身，而在description没有说清楚：它应该在什么场景下用，不应该在什么场景下用。

第二个坑是：Skill能正常触发，但每次产出质量或效果不理想。

这是项目过程中特别容易碰到的问题。举一个实际案例：

你觉得实际使用体验那个提示词更好？答案是简易的那个

针对这类问题，我自己的经验是：

不要把Skill写的太窄。

一份过窄的SOP，本质上是在假设模型没有判断能力。

但现在的推理模型，已经具备相当强的判断能力。

我自己的实践是：给原则，但不要过度限制做法。

规则写得太死，AI遇到变化时就没有处理空间。

一份好的SKILL.md，最核心的不是步骤，而是执行原则。

我写Skill时，通常会关注三个要素：

第一，为什么要这样做。第二，Agent做这件事时应该带着什么心态。第三，执行时要遵守哪些核心原则。

你可以这样写：

所以整理素材时的标准，不是「我收集到了哪些资料」，而是「这些内容能不能帮读者获得一个新的认知，或者解决一个真实问题」。

撰写时，要优先呈现读者最关心的痛点、文章的核心判断、能支撑观点的案例，以及读完之后可以直接参考的行动建议。

这不是步骤，而是原则，是优先级，是判断标准。

Agent看到这些内容之后，就知道它应该用什么标准筛选信息。

比如某些资料虽然很多，但只是重复同一个观点，它就会判断不需要全部写进去。

某个案例虽然看起来很热闹，但如果不能支撑文章主线，它也能判断不应该强行加入。

当然，这不代表所有Skill都要写得很开放。

如果你的任务本身规则明确、对错有客观标准，比如固定JSON格式校验、表单字段验证、文件命名检查，那就应该写得严格一点。

判断方法很简单：

这件事有没有客观对错？有没有明确的规则，输入输出。

如果有，就可以写窄一点，因为你要的是标准化结果。

如果没有，就写原则和判断框架。

第三个坑是：Skill写得太长。

LLM有一个现象叫contextrot。

简单说，就是加载的token越多，它召回关键信息的精度就越容易下降。

更直白一点：

你塞进去的东西越多，模型越难从里面准确找到真正重要的内容。

官方建议是，如果一份Skill超过500行，就应该拆分。

我一般会控制在200行以内。

原因很简单：500行的Skill，我自己看都不想看，更别谈维护了。

未来一个Agent执行任务时，可能不会只调用一个Skill，而是会调用多个Skill。

当最终产出出问题时，你需要有能力回头定位：到底是哪一个Skill把它带偏了。

所以Skill不应该只追求功能完整，也要追求可读性和可维护性。

那具体怎么拆？

这就要回到一开始讲的Skill结构。

除了SKILL.md，Skill还可以包含references和scripts。

六、怎么让Skill更稳定？

什么时候用references？

references的作用，是把细节和规则拆出去。

大量参考资料、不是每次都需要加载的内容、只有特定场景才会用到的扩展资料，都适合放进references。

可以把它拆成一个reference文件，然后在Skill里写：

最终输出时，请参考references文件夹中的outputformat。

什么时候用scripts？

如果你想做自动化工作流，scripts就非常重要。

scripts的本质，是把确定性操作交给固定脚本处理。

什么是确定性操作？

比如排序、格式验证、API调用、数据计算、文件重命名、文本清洗。

简单来说，就是那些有明确输入、明确规则、明确输出的事情。

这类事情，用脚本反而更稳定。

举个例子。

它的流程是：先整理素材，再提炼观点，最后生成文章大纲和初稿。

但你的素材来源经常是YouTube转写稿、播客文稿、网页复制内容，里面会有很多时间戳、重复换行、口头禅、乱码符号，甚至繁简混杂的问题。

如果每次都让LLM自己判断怎么清洗，它可能这次删掉时间戳，下次忘了删；这次保留了重点段落，下次又把有用内容一起删掉。

这时你就可以写一个脚本。

这个脚本只负责一件事：

把原始素材清洗成统一格式。

比如：

去掉时间戳；

删除多余空行；

合并断句；

清理无意义口头禅；

统一标点格式；

把英语转成简体中文；

输出成干净的Markdown文本。

于是Agent的任务就从：

自己判断怎么清洗这份转写稿

变成：

运行这个脚本，然后读取脚本返回的干净素材。

这样可以有效减少LLM不稳定发挥的问题，让后面的观点提炼、结构整理和文章生成都有一个更干净的起点。

另外，script本身的代码不会进入上下文，只有执行结果会提供给AI。

这也能节省上下文。

因为AI不需要每次重新研究怎么清洗转写稿，也不需要把清洗规则反复塞进提示词里。

你只需要在Skill对应段落中写：

请先执行素材清洗script。拿到清洗后的Markdown文本后，再进入观点提炼和文章大纲生成阶段。

Agent看到这句话，就会先运行脚本，拿到结果后继续处理。

每次都是一样的清洗规则，一样干净的输入，也更容易得到稳定的产出。

subagent怎么用？

这里再补充一个技巧：使用subagent做质量控制。

这个方法适合更专业的场景，或者容错率很低的商业场景。

你可以让subagent作为最后一层质检。

它的设计原则是：职责分离。

主Agent负责执行任务。

subagent负责检查结果。

你可以给subagent一个干净的上下文，把质检清单作为输入，让它按照checklist验收。

它可以独立检查结果，然后把问题反馈给主Agent。

这样做有两个好处。

第一，subagent有独立上下文，不会被主Agent的执行过程干扰。

第二，可以避免主Agent既当运动员又当裁判。

所以在写Skill的时候，我建议你记住这几个原则：

给心法，给意图，给目标，让它们成为Agent的执行方向。

不需要每次加载的细节，放到references。

能标准化执行的流程，写成scripts。

对重要任务，再加一层subagent做质量检查。

七、Skill怎么长期维护？

Skill的价值在于长期维护

Skill最有价值的地方，在于它有复利效应。

你今天做一版，明天用一次，顺手修一次。下周再用，再继续优化。

一个月后，这份Skill很可能已经不是最开始那份Skill了。

真正让你效率越来越高的，不是第一次写出来的那个版本，而是后续持续迭代的过程。

但大多数人做完Skill之后，就把它放在那里了。

只要还能跑，就不管它。

但如果你现在随便打开一个自己写过的Skill，很可能会发现：

references里有很多没用的资料；

原本200行的Skill，在一次次迭代中膨胀到了1000行；

里面还有大量重复信息。

这些东西叠加起来，会让你的Skill从个人知识资产，变成产出不稳定的原因，甚至变成token消耗过高的元凶。

Skill必须被维护。

因为你的工作流会变，模型也会升级。

不维护的Skill，会越来越容易表现变差。

它可能会在错误场景下被触发，也可能在执行时消耗大量不必要的token，最糟糕的是，产出结果越来越不符合预期。

什么时候应该维护Skill？

我一般会在两种情况下维护已有的Skill。

第一种情况：新模型发布时

每次模型升级后，我会拿已有Skill跑一遍。

重点检查一个问题：

哪些内容是为了弥补旧模型能力不足而写进去的？

如果新模型已经能自己处理这些问题，那么旧模型时代留下来的补丁就可以删掉。

这样处理之后，Agent加载Skill时上下文会更干净，token消耗更少，表现反而可能更好。

第二种情况：工作流执行完之后

每次workflow跑完，我会让Agent自己复盘。

可以用这样一段提示词：

现在请你复盘刚刚的执行过程。

请列出我们犯了哪些错误，每个错误背后的原因是什么，并判断这些错误是否可以沉淀进现有Skill，避免下次再犯。

让Agent复盘并迭代Skill很好用。网上也有很多类似的skill。

但这里也有坑。

比如Agent可能会把新信息到处乱塞，破坏原本清晰的结构。

原来Skill还有清楚的骨架，复盘几次之后就变成一团乱。

还有一种情况是，Agent写出来的内容虽然自己能看懂，但人类很难维护。

所以在Agent写入Skill之前，你一定要让它先说明准备怎么改。

你需要审核它的修改方向，确保结构是干净的。

不要完全放手让AI自己改。

否则后续维护成本会越来越高。

维护Skill时，主要是做这三件事

第一，删除冗余信息

同一个原则，开头讲过，中间就不用再重复。

一条信息讲一次就够了。

除非这条原则非常重要，而且你发现AI执行时经常漏掉，否则不要反复强调。

第二，重整结构

我会重新读一遍整份SKILL.md，看看自己能不能快速看懂，能不能快速抓住它的骨架。

如果连我自己都读不明白，那就说明它该重构了。

因为你不可能维护一个自己都看不懂的东西。

第三，提取references

如果SKILL.md里塞了太多示例、边界情况和特殊说明，我会把它们拆到reference文件里。

这样主文件更清爽，也更容易维护。

八、找到现成Skill后，怎么改成自己的工作流？

很多时候，你不需要从零开始写一个Skill。

更高效的做法，是先找一个方向接近的现成Skill，然后把它改成适合自己工作流的版本。

因为通用Skill解决的是“这类任务怎么做”，而你真正需要的是“这件事在我的场景里应该怎么做”。

这中间差的，就是你的工具、流程、习惯和边界。

比如你找到一个通用的文档整理Skill，它可以帮你润色文字、重组结构、提炼重点。

但如果你想把它用于团队知识库，它还需要知道更多细节：

你的原始资料通常来自哪里？

是飞书文档、会议纪要，还是内部系统链接？

你的知识库文章有什么固定模板？

哪些内容可以直接整理，哪些事实必须标注待确认？

最终结果是只生成草稿，还是可以自动写入知识库？

能不能自动发布？

能不能自动@同事？

这些，就是把通用Skill改成你自己工作流时，需要补进去的内容。

改造Skill时，重点看这几个地方。

第一，改description

把你自己或团队真实会说的话写进去。

比如不是只写“整理文档”，而是写：

当用户提供飞书草稿、会议纪要或技术方案，并希望整理成团队知识库文章时使用。

description不是介绍，它是触发器。

你写得越贴近日常表达，Agent越容易在正确场景下调用它。

第二，改输入来源

通用Skill可能只说“读取文档”。

但你的工作流里，文档可能来自飞书、Notion、腾讯文档、内部系统，甚至是聊天记录。

这些来源要写清楚。

否则Agent每次都要重新问你资料在哪里。

第三，改workflow

通用Skill的流程可能是：

读取内容→润色→输出结果。

但你的团队流程可能是：

读取原文→判断读者和目标→按团队模板重组→标注待确认事实→输出到指定知识库空间。

这才是你的真实工作流。

第四，改输出格式

不要让Agent自由决定格式。

如果团队知识库有固定结构，就写进去：

标题；

导语；

适用场景；

正文结构；

参考资料；

待确认事项。

输出格式越明确，后期返工越少。

第五，改停止条件

这是很多人会忽略的地方。

有些动作Agent不能自动做。

比如：

不自动发布；

不自动修改权限；

不自动@人；

不自动删除原文；

遇到事实不确定时必须停下来确认。

这些边界要提前写清楚。

好的Skill，不只是告诉Agent该做什么，也要告诉它什么时候该停。

举个例子。

你可以把一个通用文档Skill，改造成团队知识库Skill：

name:team-kb-writerdescription:当团队成员提供飞书草稿、会议纪要或技术方案，并要求整理成可发布的团队知识库文章时使用。先读取原文，提炼读者和目标，按团队模板重组结构，输出知识库草稿和待确认事实清单。不自动发布，不自动@人。

改造后的workflow可以是：

1.检查来源文档是否可读取。

2.读取原文，判断内容主题、目标读者和发布目的。

3.按团队知识库模板重组结构。

4.标注待确认事实、缺失来源和风险表述。

5.输出草稿到指定位置，但不自动发布。

这样改完以后，这个Skill仍然不复杂，但它已经带上了你的工作痕迹。

它知道资料从哪里来，知道要按什么格式输出，也知道哪些动作不能越界。

判断一个Skill改得好不好，不看它写得多完整，而看下一次真实任务里：

你是不是少解释了几句？

是不是少返工了几轮？

Agent有没有在该确认的时候停下来？

如果答案是肯定的，说明这个Skill已经开始贴合你的工作流了。

所以，找到Skill以后，不要急着重写。

先问自己一句：

这个Skill和我的真实工作流之间，差了哪些上下文、工具、格式和边界？

把这些补进去，它就会从一个通用Skill，变成真正属于你的工作流Skill。

九、Skill的真正意义

Skill的意义，不只是提升个人生产力。

更重要的是，它让你可以把自己的经验、判断标准和工作方法，转移给Agent。

过去，一个人多年积累下来的know-how，往往只能存在自己脑子里。想教会别人，只能靠反复讲、手把手带，或者写一堆SOP。

但现在，你可以把这些经验整理成Skill。

一旦Skill写好，Agent就能按照你的方法做事：怎么判断，怎么执行，遇到问题怎么处理，哪些坑要避开。

这不只是个人提效，也是团队能力共享的一种新方式。

以前，一个高手的能力很难被复制。新人进来，要从零开始学流程、学标准、学经验。现在，只要团队把关键工作方法沉淀成Skill，新人的Agent就能直接继承这套能力。

所以，写Skill不是为了让AI变得“更像你”。

而是把你脑子里的执行逻辑、判断标准和工作方法，变成Agent可以调用的能力。

模型会越来越强，Agent也会越来越聪明。但真正有价值的，仍然是你对业务的理解、对流程的判断、对结果的要求。

这些东西，才是Skill里最值得沉淀的部分。

我认为，Skill的价值现在还被很多人低估了。

它不只是让你这一周多写几份报告、多做几个任务。更长远地看，它会改变个人、团队和Agent之间的协作方式。

Skill是人和Agent协作的新接口。