1. 从每次都要重新教说起Agent Skill到底在解决什么如果你用过任何一款AI助手大概率经历过这样的场景你花十分钟跟它解释帮我整理会议纪要时要按项目分组每个项目下列出待办事项、负责人和截止日期语气要正式但不能太僵硬它完成得很好。第二天你打开新对话又得从头说一遍。更让人抓狂的是同一个需求你换了三个不同的助手每个都要重新教而且教出来的效果参差不齐。这个问题的本质不是模型不够聪明而是能力没有沉淀。每次对话都是一张白纸所有的上下文、规则、偏好都随着对话窗口的关闭而蒸发。Agent Skill要解决的就是这件事——它把怎么做一个具体任务的知识从一次性的对话提示变成可复用、可分发、可版本管理的结构化文件。你可以把它理解成给AI助手写的一份岗位说明书。以前你招一个新人得手把手教他怎么做周报、怎么回复客户邮件、怎么整理数据。现在你把这些操作规范写成文档任何人拿着这份文档都能快速上手。Agent Skill就是这份文档的标准化格式AI助手读了它就知道在特定场景下该怎么做、按什么步骤做、注意哪些坑。我最初接触这个概念的时候第一反应是这不就是系统提示词吗。但实际用下来发现两者有本质区别。系统提示词是全局的、笼统的通常是一大段话告诉AI你是一个专业的XX助手。而Agent Skill是模块化的、场景化的每个Skill只负责一类任务有明确的触发条件、执行步骤和输出格式。打个比方系统提示词是公司的员工手册Agent Skill是具体岗位的SOP操作流程。这个区别带来的实际影响很大。系统提示词写长了模型容易遗忘中间部分的内容而且不同任务的要求混在一起容易互相干扰。Agent Skill把任务拆开每个Skill独立加载用的时候才调出来既节省上下文窗口又避免了指令冲突。从行业趋势来看Agent Skill的兴起不是偶然。2024年下半年开始各大平台陆续推出了自己的Skill规范虽然格式不完全统一但核心思路一致用Markdown或YAML定义元信息用自然语言描述执行逻辑用文件系统组织资源。这种轻量级、可组合、可分发的设计让AI助手的能力扩展从改代码变成了写文档门槛一下子降了好几个数量级。适合读这篇内容的人我大致分三类一是日常重度使用AI助手的效率工作者想把自己的使用经验固化下来二是团队里负责搭建AI工作流的技术人员需要一套可维护的Skill管理方案三是对AI应用开发感兴趣的产品或运营同学想理解这个新范式的底层逻辑。不管你是哪一类接下来的内容都会从实际操作的视角把Agent Skill的里里外外讲清楚。2. 拆开一个Skill文件里面到底装了什么2.1 元信息层让AI知道什么时候该用我一个标准的Agent Skill文件开头通常有一段元信息用YAML格式写在Markdown文件的最上方被三个短横线包裹。这部分内容不参与实际的任务执行但它决定了这个Skill能不能被正确触发。元信息里最关键的几个字段是名称、描述、触发条件和版本号。名称是Skill的唯一标识通常用英文短横线连接比如meeting-notes-organizer。描述是一句话说明这个Skill干什么这句话会参与语义匹配所以写得越精准被调用的准确率越高。触发条件可以是一组关键词也可以是一段自然语言描述的场景比如当用户提到整理会议记录、会议纪要、会议待办时触发。我踩过的一个坑是描述写得太宽泛。最开始我写了一个文档处理的Skill描述是帮助用户处理各种文档结果几乎每次用户提到文档相关的内容都会触发它但实际执行时又因为场景不匹配而效果很差。后来我把这个Skill拆成了三个会议纪要整理、合同条款提取、技术文档摘要每个的描述都写得很具体触发准确率立刻上来了。版本号这个字段很多人会忽略但在团队协作场景下特别重要。你更新了Skill的执行逻辑如果没有版本号别人用的还是旧版本出了问题都找不到原因。我的习惯是每次修改都递增一个小版本号并在文件末尾附一个简短的变更记录。2.2 指令主体用自然语言写操作手册元信息之后就是Skill的指令主体这部分是真正指导AI执行任务的内容。写法上没有严格的语法限制但根据我的实践经验有几个结构化的要素能显著提升执行效果。首先是角色设定。虽然Agent Skill不是系统提示词但在指令主体里明确你在这个任务中扮演什么角色仍然很有帮助。比如你是一名资深的会议纪要整理专员擅长从杂乱的讨论中提取关键决策和待办事项。这句话看似简单但它能帮模型快速进入状态减少无关内容的生成。其次是执行步骤。这是指令主体的核心。我建议用有序列表把步骤写清楚每一步都说明做什么和为什么这样做。举个例子整理会议纪要的Skill步骤可以这样写通读全文识别出讨论涉及的所有项目或议题按出现顺序列出。对每个议题提取三类信息已达成的决策、待确认的问题、明确的待办事项。待办事项必须包含负责人和时间节点如果原文没有明确标注待确认而不是自行编造。输出时按议题分组每个议题下用三个子标题分别呈现决策、问题和待办。这里面的第3步就是典型的经验注入。如果不写这一条模型很可能会在信息缺失时脑补一个负责人或截止日期导致纪要失真。这种细节只有实际用过的人才知道要防。然后是输出格式。如果你对输出有明确的格式要求一定要在Skill里写清楚。可以是Markdown模板也可以是JSON结构甚至是一段示例输出。我个人的经验是给一个完整的示例比写十行格式说明都管用。模型对示例的模仿能力很强你给它看一个标准输出长什么样它就能照着来。最后是边界条件。这部分经常被忽略但实际使用中特别重要。边界条件要回答的问题是什么情况下这个Skill不应该继续执行比如如果输入内容少于100字直接告知用户内容过短无法整理或者如果检测到输入内容涉及多个不相关的主题建议用户分次处理。这些规则能防止Skill在不适用的场景下强行输出低质量结果。2.3 资源文件Skill的附件一个完整的Skill不只是一个Markdown文件它还可以包含附属的资源文件。常见的资源类型包括模板文件、参考数据、示例输入输出、脚本工具等。模板文件是最常用的。比如你做一个周报生成的Skill可以把周报的Markdown模板放在一个单独的文件里指令主体中引用这个文件路径。这样修改模板时不需要动指令逻辑维护起来更清晰。参考数据适合那些需要固定知识库的场景。比如一个产品术语解释的Skill可以把产品术语表放在一个CSV或JSON文件里指令中说明解释术语时优先参考术语表文件。脚本工具是进阶用法。有些Skill需要执行确定性的计算或格式转换纯靠自然语言描述容易出错。这时候可以附一个Python脚本指令中写明调用脚本处理数据脚本路径为xxx。不过这种用法对平台的支持程度有要求不是所有环境都能执行外部脚本。我自己的习惯是一个Skill文件夹里至少包含三个文件SKILL.md主文件、examples.md示例输入输出、changelog.md变更记录。示例文件特别有用一方面方便自己测试另一方面别人拿到你的Skill看几个示例就能明白怎么用。2.4 一个完整的Skill文件长什么样说了这么多理论直接看一个实际的文件结构会更直观。以下是我常用的一个技术方案评审纪要Skill的简化版本--- name: tech-review-notes description: 整理技术方案评审会议的纪要提取决策、风险和待办 trigger: 当用户提到技术评审、方案评审、架构评审的会议记录整理时触发 version: 1.2.0 --- # 技术方案评审纪要整理 你是一名资深的技术项目经理擅长从技术讨论中提取关键信息。 ## 执行步骤 1. 识别会议讨论涉及的技术方案名称和版本。 2. 提取以下三类信息 - 已确认的技术决策含决策理由 - 待解决的技术风险含风险等级和建议 - 明确的待办事项含负责人和时间节点 3. 如果某项信息在原文中缺失标注待确认不要自行补充。 4. 按方案分组输出每个方案下分决策、风险、待办三个部分。 ## 输出格式 参考 examples.md 中的模板。 ## 边界条件 - 输入内容少于200字时提示用户内容不足。 - 如果会议涉及三个以上不相关方案建议分次整理。这个文件不到500字但信息密度很高。元信息定义了触发条件指令主体明确了角色、步骤、格式和边界附属文件提供了示例。实际使用中这个Skill的触发准确率和输出质量都很稳定。3. 写一个好用的Skill从需求到落地的完整路径3.1 先想清楚这个Skill服务谁很多人写Skill的第一个误区是从我想让AI做什么出发而不是从谁在什么场景下需要什么出发。这两者的区别很大。前者容易写出大而全但不好用的Skill后者才能写出真正解决问题的Skill。我的做法是在动手写之前先回答三个问题这个Skill的目标用户是谁他们在什么场景下会用到他们期望得到什么样的结果举个例子同样是邮件回复这个需求如果是给销售团队用的场景是回复客户询价期望结果是专业、热情、包含明确下一步行动如果是给技术支持用的场景是回复故障报告期望结果是冷静、准确、包含排查步骤和时间预期。这两个Skill虽然都叫邮件回复但指令主体几乎完全不同。我通常会为每个Skill写一个简短的用户故事格式是作为一名[角色]当我[场景]时我希望[结果]以便[价值]。这句话会放在Skill文件的注释里不参与执行但写的时候能帮自己理清思路。3.2 指令写作的三要三不要写指令主体的时候我总结了六条经验三条是要做的三条是不要做的。三要要具体。不要说整理得清晰一些要说按项目分组每个项目下列出决策、风险和待办三个部分每部分用无序列表呈现。具体的指令才能产生稳定的输出。要举例。对于格式要求高的Skill给一个完整的示例输出比写一堆格式说明有效得多。示例要覆盖典型场景最好再给一个边界场景的示例。要留余地。指令不能写得太死要给模型一定的判断空间。比如如果原文中有明确的负责人直接使用如果没有标注待确认而不是必须为每个待办指定负责人。三不要不要写矛盾指令。同一个Skill里不要出现输出要简洁和每个要点都要详细展开这种互相冲突的要求。如果确实需要不同详细程度用条件分支写清楚。不要堆砌关键词。有些人为了让Skill更容易被触发在描述里塞一大堆同义词结果导致误触发率飙升。描述精准比覆盖广更重要。不要忽略否定场景。明确写出什么情况下不要用这个Skill和什么情况下停止执行能避免很多尴尬的输出。3.3 测试与迭代第一版永远不够好Skill写完之后一定要测试。我的测试流程分三步正常场景测试、边界场景测试、对抗场景测试。正常场景测试就是拿几个典型的输入跑一遍看输出是否符合预期。这一步通常能发现格式问题和明显的逻辑漏洞。边界场景测试是拿一些擦边的输入比如内容特别短、内容特别长、信息缺失严重、包含多个不相关主题等。这一步能检验边界条件写得够不够细。对抗场景测试是故意给一些容易引发错误输出的输入比如包含矛盾信息、包含诱导性指令、包含格式混乱的内容。这一步能发现Skill的脆弱点。我自己的经验是一个Skill从初版到稳定可用通常需要经过五到十次迭代。每次迭代不一定要大改可能只是调整一句话的措辞或者补充一个边界条件。但正是这些微调让Skill从能用变成好用。迭代的时候要记录变更。我习惯在Skill文件末尾维护一个简单的变更记录格式是版本号 - 日期 - 变更内容。这样当输出质量出现波动时可以回溯是不是某次修改引入的问题。3.4 版本管理与团队协作当Skill从个人使用扩展到团队使用时版本管理就变得很重要。我见过太多团队因为Skill版本混乱导致的问题A同事更新了SkillB同事不知道继续用旧版本两人处理同一批任务输出格式不一致下游环节直接崩溃。我的建议是团队共用的Skill统一放在一个共享目录里用Git做版本控制。每次修改都提交一个commitcommit信息写清楚改了什么、为什么改。Skill文件的元信息里保留版本号和Git的tag对应起来。另外团队协作场景下Skill的接口要稳定。所谓接口就是输入格式和输出格式。内部逻辑可以优化但输入输出的结构不要轻易变否则依赖这个Skill的下游流程都要跟着改。如果确实需要改接口提前通知所有使用方并给一个过渡期。4. 实战场景三个Skill的完整拆解4.1 场景一会议纪要整理Skill会议纪要整理是我用得最多的Skill也是最能体现Agent Skill价值的场景。以前我整理一场两小时的会议纪要至少要花四十分钟回听录音、梳理讨论脉络、提取决策和待办、调整格式。现在我把录音转文字后直接丢给Skill五分钟内就能拿到一份结构化的纪要初稿我只需要做最后的审核和微调。这个Skill的指令主体我重点打磨了三个地方。第一是信息分类规则。会议讨论往往是跳跃的一个话题没说完就跳到另一个过一会儿又跳回来。如果按讨论顺序整理读者会看得很累。我的做法是在Skill里明确要求按议题重新组织不按发言顺序。具体来说先识别出会议涉及的所有议题然后对每个议题从全文各处收集相关信息归拢到一起。第二是决策与讨论的区分。会议里有很多我觉得可以这样要不试试那个的讨论但这些不是决策。Skill里要明确区分已确认的决策和讨论中的观点。我的判断标准是有明确结论、有责任人、有执行意向的算决策只是提出想法、没有形成共识的算讨论观点放在待确认部分。第三是待办事项的完整性。待办事项必须包含三要素做什么、谁来做、什么时候完成。原文中缺失的要素标注待确认绝不自行编造。这一条我反复强调因为模型在信息缺失时脑补的倾向很强不明确禁止就会出问题。实际使用中这个Skill的输出格式是这样的会议基本信息时间、参与人、议题列表→ 每个议题的讨论摘要 → 决策清单 → 待办清单表格形式含负责人和截止日期→ 待确认事项。这个结构用了大半年反馈一直很好。4.2 场景二技术文档摘要Skill技术文档摘要的需求来自我的日常阅读。做技术选型的时候经常要读十几篇文档每篇几十页全部精读不现实但只读摘要又怕漏掉关键信息。这个Skill的目标是输入一篇技术文档输出一份包含核心结论、关键参数、适用场景和潜在限制的摘要。这个Skill的难点在于什么算关键信息。不同文档的关键信息不一样API文档的关键是接口定义和参数说明架构文档的关键是组件关系和数据流选型对比文档的关键是各方案的优劣和适用条件。如果Skill里只写提取关键信息模型会按自己的理解来结果往往不符合预期。我的解决方案是在Skill里内置一个文档类型识别步骤先判断文档属于哪一类然后按对应的提取规则处理。具体规则写在指令主体里用条件分支的形式呈现。比如如果文档是API参考重点提取接口路径、请求方法、参数列表含类型和是否必填、返回值结构、错误码。如果文档是架构说明重点提取系统组件、组件职责、组件间通信方式、数据流向、部署要求。如果文档是选型对比重点提取对比维度、各方案表现、推荐结论、推荐理由。这个Skill我迭代了大概七八版最大的收获是分类规则要基于实际文档来定不能拍脑袋。我最初写的分类规则很粗只有技术文档和非技术文档两类效果很差。后来我把自己常读的文档类型列出来逐一分析每类文档的关键信息是什么才形成了现在这套规则。4.3 场景三数据报告生成Skill数据报告生成是我帮一个运营团队做的Skill。他们的需求是每周把各个渠道的数据汇总生成一份包含关键指标、环比变化、异常说明和下周建议的报告。以前这份报告要花一个下午现在用Skill处理半小时内就能完成。这个Skill的特殊之处在于它需要处理结构化的数据输入。我的做法是Skill的输入约定为一个Markdown表格包含渠道、指标名称、本周数值、上周数值四列。Skill的执行步骤是读取表格数据按渠道分组。对每个渠道计算各指标的环比变化率。识别异常变化率超过正负20%的指标标记为异常。对异常指标结合历史数据给出可能的原因分析如果输入中包含原因说明则直接使用否则标注待分析。按渠道输出报告每个渠道下分关键指标、异常说明、建议三个部分。这里面的第3步变化率超过正负20%标记为异常是跟运营团队确认过的阈值。不同业务对异常的定义不一样有的业务5%就算异常有的业务50%才值得关注。这个阈值必须和实际使用方确认不能自己定。第4步的原因分析是个容易出问题的地方。模型很擅长编造合理的原因比如环比下降可能是因为季节性因素听起来很有道理但实际可能完全不是这么回事。所以我在Skill里明确写了如果输入中没有原因说明只标注待分析不要自行推测。这一条避免了报告中出现误导性的分析。5. 那些没人告诉你但一定会踩的坑5.1 触发不准要么不触发要么乱触发触发问题是Agent Skill使用中最常见的坑。表现有两种该触发的时候不触发不该触发的时候乱触发。这两个问题的根源是一样的描述和触发条件的匹配度不够。我遇到过一个典型案例。我写了一个合同条款风险提示的Skill描述是分析合同中的风险条款。结果用户说帮我看看这个合同有没有问题的时候Skill不触发用户说帮我分析一下这个合同的风险的时候Skill触发了但用户其实只是想让我帮忙看看合同格式对不对不需要风险分析。问题出在风险这个词上。它太宽泛了既可以是法律风险也可以是格式风险、表述风险。后来我把描述改成了识别合同中的法律和商务风险条款包括责任不对等、付款条件模糊、违约条款缺失等触发条件也列得更具体。改完之后触发准确率明显提升。我的经验是触发条件要写场景而不是关键词。关键词匹配容易误判场景描述能让模型更好地理解意图。比如不要写触发词合同、风险、条款而要写当用户提供合同文本并询问其中的法律或商务风险时触发。5.2 输出不稳定同样的输入不同的结果输出不稳定是另一个高频问题。同样的输入今天跑出来是这个格式明天跑出来是那个格式。这个问题在Skill刚写好、还没充分测试的时候特别明显。造成输出不稳定的原因主要有三个指令有歧义、格式要求不明确、缺少示例。对应的解决方案是把模糊的表述改具体把格式要求写死给一个完整的示例输出。我自己的做法是对于格式要求高的Skill在指令主体里直接嵌入一个输出模板用代码块包裹并注明严格按照以下格式输出。模板里用占位符表示需要填充的内容比如[议题名称]、[决策内容]。这样模型有明确的参照输出稳定性会好很多。还有一个技巧是在Skill里加入自检步骤。比如在输出之前要求模型检查是否所有待办事项都包含了负责人和时间节点是否有编造的信息。这个自检步骤不需要很复杂一两句话就行但能拦住不少低级错误。5.3 上下文超限Skill太长反而效果差Agent Skill的一个优势是节省上下文但如果Skill本身写得太长这个优势就没了。我见过一个Skill文件写了三千多字光指令主体就两千字结果每次调用都占用大量上下文留给实际任务的空间反而少了。我的经验是单个Skill的指令主体控制在800到1500字之间比较合适。超过这个范围就要考虑拆分。拆分的维度可以是场景比如把文档处理拆成会议纪要技术摘要合同分析也可以是步骤比如把数据报告生成拆成数据清洗和报告撰写两个Skill串联使用。另外Skill里不要放参考知识。有些人喜欢把产品手册、术语表、常见问题都塞进Skill文件觉得这样模型就能知道这些信息。但实际上这些内容会占用大量上下文而且大部分时候用不上。正确的做法是把这些内容放在附属文件里在指令中说明需要时查阅xxx文件。5.4 跨平台兼容换个环境就不灵了如果你写的Skill需要在多个平台使用兼容性是个必须考虑的问题。不同平台对Skill文件的支持程度不一样有的支持YAML元信息有的只认纯Markdown有的支持附属文件引用有的只能单文件上传有的支持脚本执行有的完全不支持。我的应对策略是核心逻辑与平台特性分离。Skill的指令主体用纯自然语言写不依赖任何平台特有的语法。元信息部分如果平台不支持YAML就把它写成Markdown的注释或者普通段落。附属文件如果平台不支持引用就把关键内容精简后嵌入指令主体。这样做的代价是Skill会稍微冗长一些但换来的是跨平台的可用性。我有个习惯是维护两个版本一个完整版用于支持附属文件的平台一个精简版用于单文件环境。两个版本的核心逻辑一致只是资源组织方式不同。6. 从个人效率到团队资产Skill的进阶玩法6.1 Skill组合让多个Skill协同工作单个Skill能解决一类任务但实际工作往往是多个任务的组合。比如周报生成这个需求可能涉及数据汇总进度整理风险识别报告撰写四个环节。如果每个环节都写一个Skill然后串联使用整体效率会比写一个大而全的Skill高很多。Skill组合的关键是定义好接口。上一个Skill的输出格式要正好是下一个Skill的输入格式。比如数据汇总Skill输出一个标准表格报告撰写Skill的输入约定就是这个表格格式。这样两个Skill可以无缝衔接。我目前维护了一个Skill流水线用于处理每月的运营报告。流程是数据清洗Skill → 指标计算Skill → 异常识别Skill → 报告生成Skill。每个Skill独立维护单独测试组合使用。哪个环节出了问题就改哪个Skill不影响其他环节。6.2 Skill分发怎么让别人也能用当你写了一个好用的Skill自然会想分享给同事或社区。但分发不是简单地把文件发出去就完了还要考虑使用者的环境和习惯。我的做法是每个对外分发的Skill都附带一个使用说明包含三部分内容这个Skill解决什么问题、怎么安装和配置、有哪些注意事项。使用说明用Markdown写放在Skill文件夹的根目录文件名统一为README.md。另外分发之前一定要做干净环境测试。所谓干净环境就是没有你本地那些隐含依赖的环境。我踩过一次坑我写的一个Skill在本地跑得很好因为我的环境里有一个辅助脚本但分发的时候忘了带上别人拿到Skill后一直报错。从那以后我每次分发前都会在一个全新的环境里完整跑一遍。6.3 Skill迭代怎么知道该改什么Skill不是写完就完了需要持续迭代。但迭代不能凭感觉要有依据。我的依据主要来自三个渠道使用记录、用户反馈、效果对比。使用记录是最直接的。我会记录每次使用Skill的输入类型、输出质量、是否需要人工修改。如果某个类型的输入频繁需要人工修改说明Skill在这个场景下有问题需要优化。用户反馈是补充。同事用你的Skill遇到问题会来找你这些反馈往往能发现你自己没注意到的问题。我有个习惯是每次收到反馈都记下来攒够三五个就集中改一版。效果对比是验证。改完Skill之后拿同一批输入跑一遍对比新旧版本的输出。如果新版本确实更好就保留如果差不多或者更差就回滚。这个对比不需要很正式自己看一眼就能判断。6.4 什么时候不该用Skill说了这么多Skill的好处也得说说它的边界。不是所有场景都适合用Skill。如果你的需求是一次性的、高度依赖具体上下文的用Skill反而麻烦。比如你只是想让AI帮你改一段话的措辞直接说就行没必要写个Skill。如果你的需求涉及大量实时数据或外部系统交互Skill也不是最佳选择。Skill擅长的是流程性的任务对于需要调用API、查询数据库、执行复杂计算的任务还是得靠专门的工具或代码。如果你的需求还在探索阶段自己都没想清楚要什么先别急着写Skill。先用对话的方式多试几次等需求稳定了再固化成Skill。我自己的判断标准是如果一个任务我重复做了三次以上而且每次的流程基本一致那就值得写个Skill。如果只是偶尔做一次或者每次的做法都不一样那就继续用对话解决。7. 我个人的一些实践体会写了这么多最后分享几点我自己的体会不一定对但都是实际用出来的。第一Skill的价值不在于多而在于准。我见过有人攒了几十个Skill但常用的就那么三五个。与其追求数量不如把几个高频场景的Skill打磨到极致。我现在主力使用的Skill不超过十个但每一个都迭代了至少五版。第二写Skill的过程其实是梳理自己工作流程的过程。很多时候你以为自己很清楚怎么做一件事但真要写下来才发现有些步骤是模糊的、有些判断是凭感觉的。写Skill逼着你把这些模糊的东西明确化这个过程本身就很有价值。第三不要追求全自动。Skill能帮你完成80%的工作但最后的20%还是需要人来把关。我现在用Skill处理任务都是把它当初稿生成器生成之后自己再过一遍。这样既享受了效率提升又保证了质量。第四保持简单。Skill的指令主体能一句话说清楚就不要写三句。能用自然语言说清楚就不要引入复杂的格式。我见过太多Skill因为写得太复杂反而不好用、不好维护。简单的东西才能长久。第五多和实际使用者聊。你自己觉得好用的Skill别人不一定觉得好用。多问问使用者的感受他们遇到的问题往往是你想不到的。我最好的几个Skill改进点都来自使用者的反馈。Agent Skill这个方向还在快速演进现在的做法过几个月可能就过时了。但底层的思路是不变的把重复性的工作沉淀成可复用的资产让AI助手从每次都要教变成拿来就能用。这个思路不管技术怎么变都是有价值的。