如何打造一个真正智能、稳定且可维护的AI技能？本文深度解析Skill的核心结构、最佳实践与常见陷阱，从逆向工程到主动梳理，教你如何将重复工作流程转化为高效自动化方案。更包含渐进式披露机制、评估驱动开发等进阶技巧，助你突破AI协作的瓶颈。
写一个 Skill 本身其实并不难。
难的是，写出一个不需要你每次主动提醒，Agent 在需要的时候就能自动触发，并且产出稳定、长期且还能被人维护的 Skill。
今天这期内容，我会从什么时候应该做 Skill开始讲起，一路讲到具体的制作方法，几个常见的坑以及找到 skill 后，怎么改成自己的 skill。
文章内容有点长，认真读完，你一定有所收获。
Skill 本质上就是一个文件夹。
长下面这样。
重点讲三个东西。
1. SKILL.md
这是整个 Skill 最核心的文件。
里面包含YAML frontmatter和Markdown指令。
文件最上面的那一段是YAML frontmatter，里面一般会包含这个Skill的名字和描述。
下面的正文部分，就是你要教给 Agent 的方法、原则和执行方式。
2. references 文件夹
这里一般用来放规则、知识库、业务说明、风格指南等资料。
比如不是每次执行都需要加载的文件，就可以放在这里。
3. scripts 文件夹
这里放的是 Agent 可以直接执行的脚本。
比如你有一套固定流程，希望用更传统、更稳定的方式来保证标准化，那就可以把这部分逻辑写成脚本。
这样 Agent 不需要自己临场判断，只要执行脚本就可以了。
这个结构背后，有一个很有意思的机制，叫做渐进式披露。
简单来说，它分成三层。
第一层，Claude 启动时，每个 Skill 只会加载它的 name 和 description。
让模型知道「系统里有这个 Skill 可以用」就够了。
第二层，当对话内容触发某个 Skill 时，才会加载完整的 SKILL.md 文件。
第三层，是 references 和 scripts。
只有在真正需要使用skill的时候，Agent 才会加载这些内容。
用不到的时候，它们不会占用上下文窗口。
很多人遇到的第一个难点，就是完全不知道从哪里开始。
要解决这个问题，重点不是先研究技术，而是复盘你自己现有的工作流。
有没有这类的工作？
1. 高频重复，步骤固定
如果你发现某一类任务会反复出现，而且每次的执行流程都差不多，你总是需要在不同对话里重复输入相同的提示词、规则和要求。
那这件事就很适合被封装成 Skill。
2. 里面包含你的业务经验
也就是你做事情时的 SOP 流程、偏好和判断标准。
比如你们公司的内部文档格式、数据统计口径、汇报习惯、交付标准等等。
agent不知道这些信息，每次你都要在对话里重新解释一遍。
如果把这些内容做成 Skill，AI 就能学会你的业务逻辑和业务知识，帮你省掉大量重复沟通的时间。
3. 出错成本比较高
如果某个任务一旦出错，会带来明显麻烦，比如会影响对外交付、影响团队协作，或者返工成本很高，那也适合做成 Skill。
因为 Skill 可以帮助你强制规范执行流程，减少agent自由发挥带来的不稳定。
所以简单总结一下，适合做 Skill 的任务通常有三个特征：
高频触发、有专属业务知识、出错成本高。
只要满足以上一点，你就可以把它做成 Skill，慢慢的用 AI 构建你的工作模式。
具体应该怎么做一个 Skill？
我平时做 Skill，主要有两种方法。
方法一：逆向工程
逆向工程是一个很适合新手的起点。
这里我们用公众号文章创作来举例。
假设你今天上午开了一个新的对话，对 Agent 说：
我这周想写一篇公众号文章，主题是 AI Agent 落地。我希望文章里既要有观点，也要有实际案例，最后还能整理成适合公众号发布的结构。请你先帮我梳理最近收集的几篇参考资料，再分析里面有哪些值得展开的角度，最后帮我生成一份文章大纲和初稿。
这个过程中，AI 可能会跑题，可能会把文章写得太像资料总结，也可能会抓不到你真正想表达的核心观点。
于是你们协作了一个小时，不断调整选题角度、文章结构、标题表达和段落语气，最后终于完成了一篇你比较满意的初稿。
这个时候千万不要急着把这个对话关掉。
因为这段对话就是最有价值的上下文。
这时你可以直接让 AI 帮你把刚才的流程沉淀成一个 Skill。
你可以直接说：
请使用 skill creator skill，把我们刚刚的对话转换成一份可以重复使用的 Skill。
确保下次我遇到同类公众号文章创作任务时，不需要像刚才那样反复调整选题、结构、观点和语气。
方法二：主动梳理
适合那种你脑子里已经有想法，但还没有真实执行过，也没有现成对话可以逆向工程的情况。
这时你要做的，就是把自己的目标、流程、难点都说清楚，让 AI 帮你整理成 Skill。
还是以公众号文章创作为例，你可以这样说：
从现在开始，我每周都要写一篇公众号文章。
我希望你帮我制作一份 Skill，用来加快这个任务的执行速度，并且让文章质量更稳定。
我设想的流程是：先根据我提供的主题和素材，帮我判断最适合展开的文章角度；然后提炼核心观点，生成文章大纲；接着写出公众号风格的初稿；最后再检查标题、开头、结构、案例和结尾是否足够适合发布。
以上是我的初步想法。请你把它整理成一份以后可以重复执行的 Skill。
在开始之前，如果有任何不清楚的地方，请先向我确认，不要直接开始写。
当然，做 Skill 并不一定需要你自己亲手写完所有内容。
但这不代表你只需要动动嘴就可以。
在这个阶段，你最重要的任务，是把自己的意图、目标和约束讲清楚，让 AI 真正理解你想要的是什么。
很多人打开 AI 的时候，其实并没有想清楚自己到底要什么。
所以你要建立一个心态：
不要总问 AI 能帮你做什么。
而是反过来想：
我有没有把上下文、约束、方法和目标准备到足够清楚，让 AI 有机会成功交付？
换个更熟悉的说法：
我有没有说清楚这个功能解决什么问题，用户是谁，使用场景是什么，边界在哪里，验收标准清不清楚。
skill 其实就是在给 Agent 写一份可以反复执行的“需求文档”。
产品经理把需求交给研发，Skill 则是把你的工作方法交给 Agent。
这里再补充一个实践方法。
Anthropic 官方把它叫做 evaluation-driven development，可以理解为「评估驱动开发」。
意思是，在你做一个 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 做这件事时应该带着什么心态。第三，执行时要遵守哪些核心原则。
这里我们还是用公众号文章创作 Skill 来举例。
你可以这样写：
公众号文章是写给读者看的。
所以整理素材时的标准，不是「我收集到了哪些资料」，而是「这些内容能不能帮读者获得一个新的认知，或者解决一个真实问题」。
撰写时，要优先呈现读者最关心的痛点、文章的核心判断、能支撑观点的案例，以及读完之后可以直接参考的行动建议。
这不是步骤，而是原则，是优先级，是判断标准。
Agent 看到这些内容之后，就知道它应该用什么标准筛选信息。
比如某些资料虽然很多，但只是重复同一个观点，它就会判断不需要全部写进去。
某个案例虽然看起来很热闹，但如果不能支撑文章主线，它也能判断不应该强行加入。
当然，这不代表所有 Skill 都要写得很开放。
如果你的任务本身规则明确、对错有客观标准，比如固定 JSON 格式校验、表单字段验证、文件命名检查，那就应该写得严格一点。
判断方法很简单：
这件事有没有客观对错？有没有明确的规则，输入输出。
如果有，就可以写窄一点，因为你要的是标准化结果。
如果没有，就写原则和判断框架。
第三个坑是：Skill 写得太长。
LLM 有一个现象叫 context rot。
简单说，就是加载的 token 越多，它召回关键信息的精度就越容易下降。
更直白一点：
你塞进去的东西越多，模型越难从里面准确找到真正重要的内容。
官方建议是，如果一份 Skill 超过 500 行，就应该拆分。
我一般会控制在 200 行以内。
原因很简单：500 行的 Skill，我自己看都不想看，更别谈维护了。
未来一个 Agent 执行任务时，可能不会只调用一个 Skill，而是会调用多个 Skill。
当最终产出出问题时，你需要有能力回头定位：到底是哪一个 Skill 把它带偏了。
所以 Skill 不应该只追求功能完整，也要追求可读性和可维护性。
那具体怎么拆？
这就要回到一开始讲的 Skill 结构。
除了 SKILL.md，Skill 还可以包含 references 和 scripts。
什么时候用 references？
references 的作用，是把细节和规则拆出去。
大量参考资料、不是每次都需要加载的内容、只有特定场景才会用到的扩展资料，都适合放进 references。
比如你的公众号文章格式本身就有 100 多行，那就不要全部塞进 SKILL.md。
可以把它拆成一个 reference 文件，然后在 Skill 里写：
最终输出时，请参考 references 文件夹中的 output format。
什么时候用 scripts？
如果你想做自动化工作流，scripts 就非常重要。
scripts 的本质，是把确定性操作交给固定脚本处理。
什么是确定性操作？
比如排序、格式验证、API 调用、数据计算、文件重命名、文本清洗。
简单来说，就是那些有明确输入、明确规则、明确输出的事情。
这类事情，用脚本反而更稳定。
举个例子。
假设你有一个公众号文章创作 Skill。
它的流程是：先整理素材，再提炼观点，最后生成文章大纲和初稿。
但你的素材来源经常是 YouTube 转写稿、播客文稿、网页复制内容，里面会有很多时间戳、重复换行、口头禅、乱码符号，甚至繁简混杂的问题。
如果每次都让 LLM 自己判断怎么清洗，它可能这次删掉时间戳，下次忘了删；这次保留了重点段落，下次又把有用内容一起删掉。
这时你就可以写一个脚本。
这个脚本只负责一件事：
把原始素材清洗成统一格式。
比如：
于是 Agent 的任务就从：
自己判断怎么清洗这份转写稿
变成：
运行这个脚本，然后读取脚本返回的干净素材。
这样可以有效减少 LLM 不稳定发挥的问题，让后面的观点提炼、结构整理和文章生成都有一个更干净的起点。
另外，script 本身的代码不会进入上下文，只有执行结果会提供给 AI。
这也能节省上下文。
因为 AI 不需要每次重新研究怎么清洗转写稿，也不需要把清洗规则反复塞进提示词里。
你只需要在 Skill 对应段落中写：
请先执行素材清洗 script。拿到清洗后的 Markdown 文本后，再进入观点提炼和文章大纲生成阶段。
Agent 看到这句话，就会先运行脚本，拿到结果后继续处理。
每次都是一样的清洗规则，一样干净的输入，也更容易得到稳定的产出。
subagent怎么用？
这里再补充一个技巧：使用 subagent 做质量控制。
这个方法适合更专业的场景，或者容错率很低的商业场景。
你可以让 subagent 作为最后一层质检。
它的设计原则是：职责分离。
主 Agent 负责执行任务。
subagent 负责检查结果。
你可以给 subagent 一个干净的上下文，把质检清单作为输入，让它按照 checklist 验收。
它可以独立检查结果，然后把问题反馈给主 Agent。
这样做有两个好处。
第一，subagent 有独立上下文，不会被主 Agent 的执行过程干扰。
第二，可以避免主 Agent 既当运动员又当裁判。
所以在写 Skill 的时候，我建议你记住这几个原则：
Skill 的价值在于长期维护
Skill 最有价值的地方，在于它有复利效应。
你今天做一版，明天用一次，顺手修一次。下周再用，再继续优化。
一个月后，这份 Skill 很可能已经不是最开始那份 Skill 了。
真正让你效率越来越高的，不是第一次写出来的那个版本，而是后续持续迭代的过程。
但大多数人做完 Skill 之后，就把它放在那里了。
只要还能跑，就不管它。
但如果你现在随便打开一个自己写过的 Skill，很可能会发现：
这些东西叠加起来，会让你的 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 时，重点看这几个地方。
第一，改 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 的意义，不只是提升个人生产力。
更重要的是，它让你可以把自己的经验、判断标准和工作方法，转移给 Agent。
过去，一个人多年积累下来的 know-how，往往只能存在自己脑子里。想教会别人，只能靠反复讲、手把手带，或者写一堆 SOP。
但现在，你可以把这些经验整理成 Skill。
一旦 Skill 写好，Agent 就能按照你的方法做事：怎么判断，怎么执行，遇到问题怎么处理，哪些坑要避开。
这不只是个人提效，也是团队能力共享的一种新方式。
以前，一个高手的能力很难被复制。新人进来，要从零开始学流程、学标准、学经验。现在，只要团队把关键工作方法沉淀成 Skill，新人的 Agent 就能直接继承这套能力。
所以，写 Skill 不是为了让 AI 变得“更像你”。
而是把你脑子里的执行逻辑、判断标准和工作方法，变成 Agent 可以调用的能力。
模型会越来越强，Agent 也会越来越聪明。但真正有价值的，仍然是你对业务的理解、对流程的判断、对结果的要求。
这些东西，才是 Skill 里最值得沉淀的部分。
我认为，Skill 的价值现在还被很多人低估了。
它不只是让你这一周多写几份报告、多做几个任务。更长远地看，它会改变个人、团队和 Agent 之间的协作方式。
Skill 是人和 Agent 协作的新接口。
本文由 @流窜AI 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。