★ FEATURED ARTICLE 先交代一个背景。过去半年我一直在做各类大模型应用最头疼的倒不是模型本身够不够聪明而是要把一件具体的事交给模型干这件事始终找不到一个顺手的封装方式。Prompt越写越长Function越挂越多最后模型面对我那套二十多个工具和三千字指令经常答非所问。后来某个开源社区提出了技能化封装这套思路也就是现在AI圈子里越来越常听到的Skills我才意识到问题出在哪我把能力堆成了一座杂货铺而模型真正需要的是一个带说明书的工具箱。这篇内容就是想一次把Skills讲透。我会从它到底解决什么问题讲起对比它和Prompt、Function、工具协议、RAG、Agent这些概念之间的关系再实际带大家手写一个能跑的Skill最后分享我在集成和调度过程中踩过的坑。无论你是在做智能客服、内容处理工具、代码助手还是个人效率应用只要你的项目里需要让模型稳定地完成某类重复任务这篇都应该能帮上忙。1. 为什么Skills成了AI工程化的当红话题1.1 一段真实的Prompt越写越长踩坑经历我之前做一个智能客服项目最初模型只需要回答FAQ一条Prompt就能搞定。后来需求膨胀要识别用户情绪、查订单、算退款金额、生成工单摘要我当时的做法很朴素把所有要求塞进系统提示里再给模型挂上查询订单、查库存、发起退款这些工具函数。结果非常典型——模型开始选择困难明明是查订单的需求它非要先去调用一个无关工具有时候它会在长上下文里忘掉前面定的输出格式把JSON都写散了。这不是模型不行而是我把混乱的命令当成了清晰的指令。模型处理长文本时注意力是有限的你给它五十条平铺的规则它根本无法判断哪条应该在什么时机生效。后来我看到Skills的思路核心就一句话把完成某类任务的完整流程包括触发条件、执行步骤、输出规范、边界规则打包成一个独立的能力单元模型看到任务时先选单元再按单元内部流程执行。这比我之前那种把所有东西搅在一起的写法要干净好几个量级。1.2 从会说话到会干活Skills解决的三个层级问题要理解Skills火了的原因得先拆开大模型应用里三个经常被混为一谈的问题。第一层是知识问题模型知不知道某件事。这靠训练数据和RAG外挂资料解决。第二层是意图问题模型能不能理解用户想要什么。这靠Prompt里的指令和上下文理解能力。第三层是流程问题知道用户意图之后模型会不会按正确顺序把这件事做完。比如帮我把原始销售数据整理成周报这不是知识问题也不是意图理解问题而是模型知不知道应该先清洗数据、再按维度汇总、再生成标题和结论、最后输出特定格式。Skills正好卡在这第三层它把完成一项任务的成熟流程沉淀下来让模型每次做这件事的时候都能按照最佳实践来而不是临场发挥。大多数项目里模型表现不稳不是前两层的问题恰恰是第三层长期被忽略。1.3 为什么偏偏是现在火起来Skills能火和几个客观变化同步发生。一是模型的上下文窗口越来越大足以在每次任务时把一套完整的技能说明书装进去这在前两年是不可想象的。二是工具和连接器越来越多如果每个工具都靠裸Prompt来调维护成本会爆炸行业急需一个统一封装层。三是整个行业从玩模型能力转向做可靠产品大家开始意识到模型能不能稳定产出比模型冷不冷门更重要而稳定产出靠的就是固化流程。最后开源社区里开始出现成规模的技能库一个人写好一个Skill其他人可以直接拿去用生态一旦滚起来概念就压不住了。2. Skills的本质夹在Prompt、Function与Agent之间的小型能力单元2.1 一个Skill里到底装了什么我见过不少人对Skills的理解是高级一点的Prompt模板这个理解不完整。一个真正能用的Skill至少由三块组成。第一块是元信息Metadata包括这个技能的名字、它解决什么问题、什么场景下应该被触发、什么场景下不应该被触发。这部分是给模型看的标签决定了模型在收到用户请求时能不能想起它。第二块是执行流程Workflow这是整个Skill的核心。它不是一句请你分析这份文档就完事而是明确列出步骤先做什么、再做什么、每一步按照什么规则做、中间遇到异常怎么处理。有些Skill还会带分支逻辑比如如果输入超过30页就先做摘要再分析如果检测到敏感词就直接拒绝。第三块是附属资源Assets比如输出模板、代码脚本、数据字典、校验规则。模型在执行过程中可能需要参考这些资源来完成格式化输出或计算。一个整理证照的Skill可能会内置一个证件类型白名单一个生成SQL的Skill可能会内置一张数据库的字段说明表。2.2 Skill不是更大号的Prompt也不是更聪明的Function为什么说它既不是Prompt也不是Function因为二者解决的是不同层面的问题。Prompt本质是一次性指令它告诉模型这一次对话中你该怎么表现。它没有结构化的触发机制没有独立的生命周期写完就混在整段对话里改一处可能影响全局。Function工具调用本质是一次外部动作它把查天气发邮件这种能力暴露给模型调用。重点在调用而不在流程——模型决定调用哪个函数函数返回结果任务就算完了。但很多真实任务不是一次调用能搞定的比如市场调研需要先搜资料、再汇总、再生成报告这中间有顺序、有依赖、有校验单个Function表达不了这种多步骤流程。Skills正好填补了这个空白。它不是指令而是指令加流程加资源的组合包它也不是单次调用而是一个可以被模型执行完整个流程的小型工作流。你可以把Skills理解为预编排好的做事方法而Function是其中可以被调用的零部件。2.3 最小结构用一段配置看懂Skill下面是一个最简单的Skill配置用来做周报整理。我不展开具体平台的格式因为各家格式略有差异但核心字段是通用的name: weekly_report description: 把散乱的工作记录整理成结构化周报 when_to_use: - 用户提供多段工作日志并希望汇总成周报 - 用户提到本周工作、项目进展、待办事项 when_not_to_use: - 用户只需要翻译文本 - 用户没有提供任何工作内容 input: work_logs: 用户输入的工作日志文本 steps: - step: 提取所有工作条目按项目/日常/学习分类 - step: 去除重复条目合并同类事项 - step: 为每周输出总结性标题 - step: 按固定模板输出周报 output_format: | ## 本周总结 - 完成事项... - 项目进展... - 待办事项... - 风险与问题...这个结构看着简单但每一段都是有用的。description和when_to_use决定模型什么时候想起它steps决定执行质量output_format保证输出稳定。缺了任何一块这个Skill就只是一段建议而不是一个可执行的能力包。3. 和相近概念的关系一次讲清四个兄弟3.1 Prompt教一次 vs 会一辈子很多人问我有现成的Prompt转成Skill是不是就是把Prompt换个文件名还真不是。Prompt的问题在于它活在当下写得好也只在当前对话里有效。你这次写得漂亮下次还得重写你给同事分享同事复制过去还要再改半天。Skill不一样它是可复用的资产。你可以给每个特定任务建立专属Skill下次遇到同类任务模型自动调用不用再重新写指令。同样的经验还可以在不同项目之间迁移这就把灵光一现的Prompt变成了长期生效的能力。我自己的体会是好的Skill可以逐渐迭代今天加一个步骤明天补一个反例版本越来越完善而一条裸Prompt通常改着改着就乱了。3.2 Function Calling / Tools调用工具 vs 完成差事代码层面Function是工具Skill是使用工具的人。模型要完成一个任务通常要按顺序调用多个Function还要在每个Function返回结果之后做判断、再决定下一步。这些判断和排序就是Skill里要固化的东西。举一个实际的例子做生成客户跟进邮件这个Skill里面可能包含了查客户资料、分析对话历史、生成草稿、检查合规词这四步。其中每一步都会调用不同的Function但真正的做事方法不在任何一个Function里而在Skill编排的步骤里。所以两者不是替代关系是配合关系Skill是剧本Function是道具。3.3 模型上下文协议连接外部世界与包装内部能力的两种思路模型上下文协议MCP这两年的讨论也很多它是用来连接模型和外部系统的统一协议解决的是模型怎么拿到外部数据、怎么操作外部系统的问题。Skills解决的是模型拿到外部数据之后该怎么一步步把活干完的问题。我的理解是MCP更像给模型装上了手Skills则是给模型发了一本工作手册。两者完全可以组合一个Skill的内部步骤里可以明确要求调用某个MCP工具来取数取完数再按后续步骤加工。比如生成经营分析报告这个Skill第一步通过MCP工具读取数据库指标第二步再按模板生成分析段落。协议负责打通Skills负责教模型怎么用这些打通的能力干活。3.4 RAG和Agent知识的问题、做事的方法、调度的角色再看两个也容易混淆的概念。RAG解决的是模型不知道某个知识的问题它把外部文档切成块在模型回答时检索相关片段喂进去。表面上和Skills有点像——都要往模型上下文里塞东西但两者目标完全不同。RAG塞的是事实资料Skills塞的是做事流程。你可以在一个Skill里用RAG比如生成合规审查报告这个Skill的第一步就是检索公司制度文档这是组合使用不是二选一。Agent则更像一个调度大脑。Agent负责理解目标、拆解计划、决定下一步做什么Skills是Agent手下的执行单元一个Agent可以在执行过程中按需调用多个Skill。比如一个项目助理Agent处理用户需求时先调用需求分类Skill判断类型再调用会议纪要整理Skill或周报生成Skill。所以Agent是策略层Skills是能力层。如果只有Agent没有SkillAgent每次都在临场发挥有了SkillAgent才能稳定复用成熟经验。为了看得更清楚我把这些概念放一张表里对照概念解决什么问题核心载体和Skills的关系Prompt一次性对话指令自然语言Skill包含步骤型的指令但更结构化Function/Tools单次外部动作函数定义Skill可编排多个Function调用模型上下文协议MCP外部系统连接统一协议接口Skill可调用MCP能力取数或操作RAG外部知识获取文档向量检索Skill流程中可按需使用RAGAgent目标拆解与调度规划引擎Agent调度Skill执行具体任务Skills完整做事流程的封装元信息步骤资源本文主角4. 从零手写一个可复用的Skill4.1 先想清楚边界这活儿该不该交给模型很多人在动手写Skill之前根本没想过一个问题这件事真的适合做成Skill吗我见过最典型的失误是把一个需要强实时信息的任务做成了Skill比如让模型根据实时股价写分析报告——模型根本拿不到实时数据Skill写得再好也是空转。按我的经验适合做成Skill的任务至少满足三个条件任务高频。一周出现至少几次值得你花时间固化。步骤可描述。你能把处理流程拆成清晰的、可以照着执行的步骤。输出可校验。你知道什么样的结果算合格这样才能在Skill里写清楚验收标准。反过来纯开放性创作、强实时交互、完全依赖某次对话语境的临时任务都不适合做成Skill。你要是硬做大概率会得到一个既限制模型发挥、又没法稳定复现的四不像。4.2 一个范例会议纪要整理Skill的完整配置我拿自己项目里最常用的会议纪要整理当例子把这个Skill的核心配置展开讲。这个Skill解决的问题是用户扔进来一段会议录音转文字或者一堆零散笔记模型要输出结构化的会议纪要包含议题、结论、待办、负责人和截止时间。name: meeting_minutes description: 将会议录音转写文本或零散笔记整理成结构化会议纪要 when_to_use: - 输入是会议转写文本、聊天记录或多人讨论内容 - 用户要求生成会议纪要、行动项、结论摘要 when_not_to_use: - 输入是单人的思考日志误导为决议应输出个人待办 - 输入是产品文档或代码 input: source_text: 待整理的原始文本 steps: - step: 通读全文识别与会者提出的观点和争议点 - step: 划分段落背景/讨论/结论/待办 - step: 提取所有明确结论标注已确认 - step: 提取所有行动项为每条行动项指定负责人负责人必须是原文明确提到的人不能猜测 - step: 为每个行动项补充截止时间若原文未提及标记为待确认 output_format: | # 会议纪要 ## 会议信息 - 日期{推断或用户提供} - 参会人{原文提取} ## 议题与讨论 {按议题分点} ## 明确结论 - ... ## 行动计划 | 待办 | 负责人 | 截止时间 | 状态 | |------|--------|----------|------| validation: - 所有行动项必须有关联负责人字段缺失则为待确认 - 未提及的时间节点一律写待确认不得编造注意最后两行validation字段是我后来补上的。第一次跑这个Skill的时候模型会把没提到的截止时间自己脑补出来编一个本周五或者下周一非常误导人。在Skill里写死未提及就写待确认算是给模型套上了缰绳。这个细节看起来小实际使用里价值极大。4.3 为什么双层描述是Skill好用的关键我在测试十几个Skill之后发现一个规律只在description里写整理会议纪要这种笼统描述模型经常在错误的场景唤起这个Skill。比如用户只是问开会前需要准备什么它也把纪要Skill拉出来。问题出在描述没有给出判别依据。我在when_to_use和when_not_to_use里补充了大量场景化的描述比如输入是会议转写文本比如用户要求生成行动项。这相当于给模型一本触发判断手册它有正例也有反例。模型看到用户消息时会先拿消息和这些条件做匹配匹配度够了才唤起对应的Skill。这层设计在概念上类似给技能做检索索引——描述越贴近真实使用场景唤起准确率越高。我建议when_to_use里至少写三到五个反例因为反例比正例更能帮助模型做排除。4.4 用三个问题判断Skill是否写到位写完Skill别急着上线先拿三个问题自测一遍。第一个问题一个不了解背景的人只看你这个Skill的配置能不能按步骤完成一次任务如果步骤里写着分析文本那等于没说应该写从文本中提取所有日期并转换成统一格式。步骤必须具体到可以被执行。第二个问题你知道这个Skill的失败模式是什么吗每个Skill都有它容易出错的地方——会议纪要容易编造时间SQL生成容易编造字段代码助手容易默认引入不存在的依赖。如果你说不出来哪里会出问题那说明你对流程的边界没有想清楚。好的Skill会在步骤里直接内置对应防御像上面的未提及就写待确认就是典型防御。第三个问题这个Skill的输出能被下游程序稳定解析吗如果输出结果是给程序用的那一开始就要在output_format定义好结构最好直接给JSON Schema或固定模板。如果你的下游是自由文本那也要明确标题层级怎么用、列表怎么用、加粗怎么用否则模型每次排版都会不一样。5. Skill的调度与集成模型是怎么在几十个技能里选对的5.1 两种主流调度思路索引注入与动态路由Skill数量一多第一个要面对的问题就是模型怎么知道该用哪个Skill。最简单的方式是索引注入把项目里所有Skill的name和description汇总成一张索引表塞在系统提示里。模型看到用户请求后先从索引里挑出候选Skill再把选中的Skill完整加载进上下文执行。这种做法的优点是实现简单、对模型推理能力要求低缺点是索引本身也会占上下文Skill数量超过三十个之后索引太长反而干扰判断。另一种方式是动态路由用向量检索或规则引擎先对用户请求做一次预处理找出最匹配的Skill再执行。比如把每个Skill的描述向量化用户请求一到就做一次语义检索取Top K再喂给模型决定。这种方案适合Skill数量特别多的场景但需要额外维护一套检索服务。以我的经验个人项目和中小型应用先用索引注入就够了等Skill数量真的失控了再引入动态路由不迟。5.2 运行时设计与技能组合Skill的执行不只是读取配置逐条执行这么简单真正跑起来还有几个运行时要处理的点。顺序执行是最常见的按步骤列表一步步走。但真实任务常常有分支比如会议纪要整理时如果原文超过5000字先做分段摘要再提取结论这个条件分支就要在Skill里显式写出来。我习惯在步骤里用if这种直观的表达模型理解起来没有任何障碍。另一个问题是状态管理。有些多步骤任务需要中途记住前面算出来的结果例如先抽取出所有金额再对这些金额分类汇总。这时候Skill要么把中间结果记录在上下文中要么通过一个临时变量空间保存。你在设计Skill时要把中间结果放在哪里写清楚不然后续步骤拿不到前面的输出整个流程就会断。技能组合则是进阶玩法。一个复杂的Skill可以被拆成几个子Skill比如生成经营分析报告这个Skill内部会依次调用数据读取指标计算模板填充三个子技能。这种复合结构的好处是每个子技能可以独立复用到别的场景坏处是调试时链路变长。我建议先从单一Skill做起等复用的需求真的出现了再拆层组合。5.3 版本、缓存与回归测试的工程建议既然是工程实践就不能只聊机制还得聊聊研发流程。我踩过最大的坑是改了一个Skill把另一个功能改坏了——因为多个地方共用同一个技能包。后来我养成几个习惯非常管用。第一每个Skill都要有版本号改完配置就把版本号递增日志里记录每次执行用的是哪个版本。不然你根本无法判断以前跑得好好的怎么突然不行了到底是因为模型更新还是有人改了Skill配置。第二一定要建回归用例集。每个Skill对应一组固定的测试输入每次改完配置后把这组输入重新跑一遍逐条对比输出是否仍然符合预期。我的做法是给每个Skill存一份期望输出要点重点比对是否丢了字段、格式有没有乱、有没有出现编造信息。第三Skill执行过程要留痕。运行时把模型选择的Skill名、执行步骤的中间输出、最终结果都记录下来我甚至在日志里会记录这个Skill是被索引注入选中的还是被动态路由选中的。没有这些痕迹出了问题就只能干瞪眼。6. 我踩过的坑与绕开它们的办法6.1 把Skill写成伪需求清单我最早写过一批Skill现在回头看不忍直视。步骤写得全是全面分析用户需求深度洞察问题本质优化输出体验这类话。这些词听起来没毛病但模型执行的时候根本不知道具体要做什么。全面分析是什么标准深度洞察要洞察到哪一步后来我把这类模糊动词全部换成了可验证的动作。要用提取分类删除合并格式化这种有明确执行对象的动词而且要写清楚操作对象和判断依据。步骤写到这个粒度模型执行起来才稳定你也能通过日志判断模型到底是哪一步跑偏了。6.2 触发条件写得像数学题另一个深刻的教训是触发条件不能写得太逻辑化。我有一版Skill的when_to_use里写了当用户输入中包含第一人称且包含时间状语且意图为总结时触发这种多条件同时满足的逻辑人看着都费劲模型更是经常忽略了其中一条导致该触发的时候不动不该触发的时候瞎动。正确做法是写成场景描述用具体的例子代替抽象条件。不是当用户提供工作日志时而是当用户说帮我汇总一下这周做的事或贴出一段由今天、完成了组成的加班流水账时。模型对具体场景的敏感度远高于抽象逻辑。描述里加反例也一样用比如不要处理纯翻译请求就比当意图不是总结时不要触发要好用。6.3 过度依赖外部环境复现失败我犯过一个很低级的错误Skill里要求调用一个内部API但没说这个API需要什么密钥、在什么环境可用。结果Skill在本地测试时好好的部署到另一台服务器就全部报错我排查了半天才发现是环境变量缺失。现在我在Skill里加了一个依赖清单字段把所有外部依赖写清楚要调用哪个服务、需要哪些权限、环境变量名是什么、没有依赖时Skill是否有降级策略。Skill本身还应该内置一个self_check步骤执行开头先检查依赖是否就绪发现缺失就明确报告而不是硬着头皮一路执行到报错。这相当于给技能加了一个启动自检逻辑省了大量排查时间。6.4 安全边界Skill该被允许做什么不该做什么这一点放到最后说因为它比功能本身更重要。Skill本质上给了模型按步骤执行操作的权限如果步骤设计得不够谨慎就相当于把危险操作的开关交给了模型。我遇到过的最典型情况让模型调用工具删除重复文件Skill里写了删除前无需确认结果模型基于错误的判断把用户文件删了。从那以后我给所有涉及变更操作的Skill立了一条铁规矩凡是删除、修改、发送、付款这类有不可逆后果的动作Skill步骤里必须加执行前向用户确认这一环并且在输出格式里强制要求模型在调用该动作前输出一份确认清单写明要操作的对象、影响范围和风险提示。此外凡是Skill里用到用户提供的外部文本比如网页内容、文档内容都要在步骤里加入输入防注入检查这是防止用户数据里面藏着恶意指令把模型诱导去干别的事情。很多Skill翻车不是流程不对而是没有给输入内容设防。安全边界必须当成Skill的一等公民来对待而不是事后补救的功能。7. 我的体会Skills是一个可积累的能力资产7.1 从模型能力到个人能力库的转变用了几个月的Skills机制之后我最大的感受是它对项目开发方式的改变可能比模型本身的能力提升影响还要大。以前做AI应用每次都是针对当前需求写Prompt新需求来了旧Prompt就废弃了经验全散落在聊天记录里。现在不一样我每解决一个具体问题就会把它沉淀成一个Skill。做完一个项目手里攒下一批技能包下一个项目遇到类似任务直接把对应Skill拿过来改改就能用。这让我实实在在感觉到能力是可以积累的而且是跟着项目走的。一个Skill就是一条已经验证过的做事方法写多了之后你的技能库本身就是一笔资产。7.2 一个最实在的建议先为最烦琐的任务建Skill如果你刚接触Skills不知道从哪下手我的建议是别追热门直接从自己项目里最高频、最烦琐、最容易被模型搞砸的任务开始。找一个小而具体的场景比如把客服对话记录整理成工单、把零散笔记按康奈尔模板转成学习卡片、把不规范的SQL按字段字典改写成标准语句刻意练一次手写Skill的流程。先写元信息和步骤再补输出模板跑几遍之后根据失败模式加防御规则。这样走完一个完整闭环你对Skills的理解会比看十篇文章都深。AI工程化走到今天模型本身的能力差距在缩小真正拉开项目差距的是你会不会把自己的业务经验用结构化的方式固化给模型。Skills就是现阶段最好用的那个载体。剩下的就是挑一个最烦的任务把这个周末花在写你的第一个Skill上。
阅读完成 · 觉得有帮助？
