大半年没见skills这个词在我朋友圈和技术社群里出现的频率高到离谱。做AI应用的聊Agent Skills做内容工具的聊技能市场连不少做企业数字化的朋友都在问怎么给团队搭一套技能库。说真的这个词本身不新人类从古至今都在谈技能但2025年大家挂在嘴边的skills明显另有所指——它正在从一种抽象的能力概念变成一种具体的、可封装、可加载、可复用的AI能力单元。这篇文章我就把这件事一次讲透Skills到底是什么、为什么突然火成这样、背后是哪套运行逻辑、以及最关键的——怎么从零写一个能真正跑起来的Skill。我把完整的实操记录、踩过的坑、排查思路都放在里面。适合正在研究AI Agent、做自动化工作流、或者单纯想给大模型插上手脚的开发者参考哪怕你之前只玩过Prompt助手跟着走也能做出一个可用的技能包。1. 先弄清楚Skills到底是什么1.1 从技能到技能包名字背后是范式的转变要理解现在的Skills得先退一步看AI圈子这两年发生了什么。最早大家用大模型核心玩法是写Prompt把需求描述得足够清楚模型就能给你一个答案。但这种方式本质上是一次性的你每次都要重新描述模型每次都在临时发挥上下文一乱结果就飘。后来出现了Function Calling模型学会调工具了但工具的粒度太细你让它做一个整理周报的事得拆成十几次函数调用中间还得有人盯着纠偏。Skills就是在这中间的空白处长出来的。它不是一个工具也不是一段Prompt而是一个完整的能力包里面有对模型的自我介绍元信息、有完成任务的操作手册指令、有可以调用的脚本和数据资产甚至还有几个示范案例。模型平时不认识你一旦你把它加载进来它就知道哦遇到这种活儿我有一套现成的路子按这个来。说白了传统Prompt是你告诉模型怎么做Skill是你给模型颁发一个上岗资格证连带操作SOP一起塞进去。这个转变很微妙但很重要。以前的能力在人的脑子里每次都得通过语言把脑子里的流程翻译给模型听现在能力被固化成文件、代码、模板模型按需加载随取随用。你可以把它理解成给ChatGPT装了一个应用商店里的AppApp不在系统里但你想用的时候点一下它的功能和界面就全出现了。1.2 为什么2025年大家都开始聊Skills任何一个概念爆火背后都有明确的推力。Skills能在今年集中爆发我觉得主要来自三个方向的变化。第一模型本身从答案机器变成了调度中心。大模型不再被要求记住所有事而是被要求知道该找谁办事。Claude的Agent Skills、各家国产模型平台上的技能广场其实都在做同一件事让模型具备一种即插即用的能力调度能力。模型的内置知识是底座Skills是钻头底座负责判断该上哪个钻头钻头负责真正干活。第二长尾任务的自动化终于有了可行的载体。企业里大量工作不是写一篇文章这么简单而是把一堆杂乱的会议记录变成待办清单把销售聊天记录按客户归类把周报里含糊的话自动标红。这些任务每个都不大但都有一套固定的处理套路过去写流程要开发写提示词又不够稳。Skill刚好卡在中间既有结构化流程的稳定又有不需要传统开发的轻量。第三生态层面的玩法成熟了。技能是可以分发、可以交易、可以版本管理的。现在不少平台已经支持把写好的Skill打包成一份文档或目录放到市场上让别人下载。这就催生了一个新物种技能开发者。你写的Skill被100个人用就相当于你把这套最佳实践复制了100份出去。这个想象空间跟当年插件生态刚起步时很像。不过话说回来概念热归热真正能用起来、不被模型阳奉阴违的Skill其实没那么好写。接下来我把一个标准技能包的骨架拆给你看。2. 一个标准Skill的基本骨架2.1 元信息区让模型知道什么时候该用你一个Skill从文件结构上通常长这样一个名字、一套描述信息、一个存放指令的主文档再加上一些附属文件。其中最容易写错、也最容易被忽略的是元信息区域。很多人的Skill不被模型调用问题就出在这一步。元信息是什么就是技能包最开头的说明部分一般长这样--- name: meeting-minutes-to-todo description: 把会议记录的转写文本转化为结构化的待办事项清单 支持提取责任人、截止时间与风险项。适合在产品评审会、项目同步会、 周会后使用。 version: 1.0.0 ---这里关键的是description这一行。它不是用来告诉模型我是什么的而是告诉模型你什么时候应该加载我。写description有一条核心原则写触发场景不要写自我表扬。很多新手喜欢写这个技能可以高效地把文本整理成清单这句话模型看了毫无反应因为高效是形容词不触发匹配。但如果你写适合在产品评审会后使用当用户提到会议纪或待办整理时使用模型就能在做相似度匹配时命中。实际开发中我还会在description里埋几个触发动词比如整理会议记录提取待办生成行动项。因为工具的调度本质上是一次语义匹配你给的触发词越接近用户日常口语命中率越高。这就好比搜索引擎的索引词你总得让用户搜得到你吧。2.2 指令与流程把怎么做写成人话元信息决定了模型什么时候用你指令部分决定了用你之后能不能干成。这一块是一份清晰、结构化、可执行的操作手册而不是一段泛泛而谈的提示词。标准写法是分模块。第一模块是输入声明明确告诉你这个技能吃什么数据格式是什么可能有哪些不理想的情况比如转写文本里有废话、有人名听错。第二模块是处理步骤按序号列出从头到尾的操作流程每一步都要输出什么结果。第三模块是决策分支遇到什么情况走哪条路比如如果文本中没有明确的责任人标记为待确认。第四模块是输出模板直接给出一个格式骨架让模型照着填别自由发挥。举一个最简单的例子指令核心部分大概是## 处理流程 1. 识别输入文本中的每一个讨论主题按主题切分内容。 2. 针对每个主题提取以下字段 - task用一句完整的话描述这个待办事项 - owner文中出现的责任人姓名若未出现填待确认 - due提取明确的日期/时间表达若未出现根据上下文推断或填未排期 - risk若文本出现风险延期阻塞等词记录相关说明 3. 全部提取后按紧急程度排序输出清单紧急且快到期的排最前。这个流程本质上是在教模型按套路出牌把原来藏在人脑子里的判断逻辑显性化。我见过不少失败的Skill问题不在模型笨而是指令写得像散文——模型读完了依然不知道第一步该干嘛、输出该用什么字段。记住模型对模糊的容忍度远比你想象的低而你因为指令模糊导致输出不稳定的时候第一反应往往不是改指令而是怪模型其实怪错了。2.3 脚本与数据资产从嘴上说到真正干纯靠Prompt的Skill能处理一部分任务但遇到需要算数、查数据、批量处理的情况就得配上脚本资产。这是Skill区别于纯提示词工作流的另一个关键点。一个实用的Skill目录通常是这样的meeting-minutes-to-todo/ ├── SKILL.md # 主入口元信息 指令 ├── scripts/ │ └── parse_date.py # 解析中文日期表达输出标准日期 ├── data/ │ └── company_names.txt # 常见的公司/项目名用于实体识别 └── examples/ └── demo_input.md # 示例输入帮助模型对齐格式 └── demo_output.md # 示例输出脚本的作用很纯粹把模型不擅长的事拿过来。模型不擅长精确算时间差、不擅长批量正则匹配、不擅长处理超大文本这些都可以丢给脚本。比如上面那个会议记录转待办的例子我会让模型在输出JSON里把日期字段留成下周一下午然后调用一个parse_date.py把它标准化成2025-06-03T14:00:00省得大模型自己推算日期算错。对这个目录结构多说一句examples里放一两个完整的输入输出示例作用比你在指令里写十句话都大。模型是few-shot动物你给它看一个从这样的输入到这样的输出的完整例子它对新任务的把握会明显提升。这也是我调Skill时最快见效的一招。3. 从一个需求到能跑的Skills完整实操记录3.1 需求拆解我要解决什么问题理论说再多不如亲手写一个。我用一个真实的需求走一遍全流程把团队里杂乱的会议记录转写文本变成一张结构清晰的行动清单。背景是团队每周开两次项目会转写文本动辄三四千字谁负责什么、什么时候交付全埋在对话流里会后靠人肉翻找。第一步永远不是写代码而是把需求拆到不能再拆。我拆出了三个子问题一是切分问题。一段会议记录里往往聊了五六个主题不能一锅炖得能按主题把内容切成块。二是抽取问题。每个主题块里要提取出做什么、谁来做、什么时候做完、有什么风险四个字段。三是排序与呈现问题。提取出的待办事项要按紧急程度排序方便会后直接投屏或发群。这套拆解做完之后我意识到一件事这个任务里真正依赖大模型理解能力的只有切分和抽取这两块日期标准化可以交给脚本排序规则是清晰的截止日期最近的优先。所以我的Skill设计思路就变成指令部分负责让模型做切分和抽取输出结构用JSON固定脚本负责把日期字段规范化最后在SKILL.md里给出一个完整示例保证格式对齐。3.2 写描述、写指令、配脚本三步走全过程先写SKILL.md的主文档。我完整放出来你可以直接当模板改--- name: meeting-minutes-to-todo description: 用户提供了会议转写文本语音转文字或会议纪要段落 想要提取待办事项、责任人和时间节点时使用。触发场景包括 会议结束后整理行动项、把会议记录转为任务清单、提取分派人。 version: 1.1.0 --- # meeting-minutes-to-todo ## 输入 用户输入一段会议记录转写文本任意长度。文本可能包含无关讨论、重复内容、口头语。 ## 处理流程 1. 将输入文本按讨论主题切分成多个片段。每个主题取一个简短的名称。 2. 对每个片段提取以下字段 - task该主题下需要推进的事用完整句子描述 - owner文中出现的负责人姓名未出现则填待确认 - due出现的时间表达支持周三下周月底6月15日等未出现则填未排期 - risk若片段中出现风险延期阻塞问题等词摘录相关语句否则为空字符串 3. 按以下规则输出JSON数组 - 有明确due的待办排前面且按时间先后排序 - 未排期的排在最后 ## 输出格式 直接输出JSON数组不要额外解释。格式 [ { topic: 主题名称, task: 具体待办事项描述, owner: 责任人姓名或待确认, due: 原始时间表达, due_standard: 由脚本标准化后的ISO时间或未排期, risk: 风险说明或空字符串 } ] ## 示例 输入 先说一下支付链路的事这个必须要在这个月底前上线负责人是李然。 还有个问题王哲那块的服务监控周四前要补上不然下个迭代心里没底。 另外数据分析平台的事暂时没人认领我先放着看看下回谁接。 输出 [ { topic: 支付链路上线, task: 支付链路功能在月底前上线, owner: 李然, due: 月底前, due_standard: , risk: }, { topic: 服务监控补全, task: 补齐服务监控周四前完成, owner: 王哲, due: 周四前, due_standard: , risk: 下个迭代心里没底 }, { topic: 数据分析平台, task: 数据分析平台待认领负责人, owner: 待确认, due: 未排期, due_standard: , risk: } ]主文档写完后我配了一个简单的日期解析脚本。它的逻辑很简单把月底周X下周X月X日这些表达映射成具体的日期通过Agent的工具调用机制在输出前自动跑一遍回填到due_standard字段。脚本只处理那些能在规则内解决的问题识别不了的字段保持原样绝不硬猜。这一步有一个特别重要的原则Skill里的指令要给模型留出不完美表达的空间。用户的原始文本大概率是周四前弄完这种口语模型如果如实复制周四前到due字段后面的日期排序就废了。所以我在输出格式里专门加了due和due_standard两个字段一个保留原文方便人读一个给脚本喂标准日期方便机器排序。你是让Skill的各个部件各干各的强项而不是指望模型一个人包打天下。3.3 测试与调优别第一次就跑生产Skill写完之后最忌讳的事就是直接丢给用户当生产工具用。我自己的习惯是先做一个离线测试不用真模型而是把写好的SKILL.md当作一份操作说明手动拿着三份历史会议记录走一遍流程看指令有没有表达含糊、示例能不能对齐。这个步骤很多开发者嫌麻烦但它是排查指令缺陷最快的方式。你会发现很多问题比如第一步按讨论主题切分没有定义主题切换的信号词人靠常识能判断模型可能会过度切分把一个主题切成三块。这时候就要在指令里补一条当出现换个话题接下来看另外等转折词时视为新主题的开始。这些信号词不是我想出来的是拿着真实文本走查时发现模型最容易犯错的地方提前写进去比到时候再查日志高效得多。离线测试通过后我还会做一组边界测试。我把输入文本故意改成全文没有提到任何日期、全文只有一个主题、同一个人在不同主题里被反复提及、有大量嗯啊就是说填充语。每个场景都跑一遍看着模型输出做微调。比如发现全文只有一个主题时模型有时会把一个主题拆成好几条待办粒度完全对不上。后来我在指令里加了限定每个主题最多输出两条task若超过两条合并为一条更完整的描述。这个口子一封输出立刻稳定下来。测试的最后一步是写评估标准。我建议你不要靠感觉判断好坏而是定几个硬指标字段完整率每条待办有没有漏掉owner或due、日期识别准确率、主题切分的一致性——同一份记录跑三次切分结果是否基本一致。这三个指标合格了Skill才算真正能交出去。4. 常见问题与排查实录4.1 模型就是不调用我的Skill怎么办这是被问得最多的问题。明明写好了技能模型却视而不见直接用自己的常识回答或者答得完全不是你的格式。我排查这个问题只按三个步骤走。第一步查description的触发词够不够具体。如果你写的是帮助用户整理文本那模型大概率不会用你因为这句话能匹配任意场景。你要做的是把输入长这样、用户意图长这样明确写出来最好直白地写当用户说整理会议记录提取待办时使用本技能。这里有一个我在实际项目中养成的习惯把description写成一个if-then句式——当用户提供XX类型内容、并希望得到XX结果时。模型的技能匹配逻辑对这种条件式描述非常敏感。第二步检查技能目录下所有文件名。有些平台会自动扫描SKILL.md并生成技能索引如果文件名有歧义或者SKILL.md不在根目录匹配阶段就直接挂了。我踩过一次坑把主文档命名为instructions.md而没有SKILL.md入口结果平台压根没识别出这是个技能包。后来我统一约定目录里必须有一个名为SKILL.md的文件作为唯一入口其他辅助文档从它出发引用。第三步如果前两步都没问题那就要借助技能匹配日志来看输出了。很多Agent框架会打印出模型在加载技能前的打分或匹配结果能看到模型对比description和用户输入算出来的相似度。有一次我发现模型把另一个技能weekly-report-writer误匹配到了我的会议记录整理需求上原因是我在那个技能的description里写了整理属于典型的触发词重叠。解决方法是把两个技能的触发场景说得更互斥并在整理之外各加一个专属动作词。4.2 输出了格式正确但内容不对还有一种更隐蔽的失败模型确实激活了技能也确实按照输出模板给了一个JSON数组但里面的内容是错的——比如把风险字段填成了一句完全无关的话或者把根本没提到的责任人硬编造了一个名字。这种格式对、语义跑偏的情况比模型不调用更难排查因为通道好像通了就是里面的数据脏。我总结下来原因通常是两个。一是抽取规则没有给出找不到时怎么办的兜底。模型宁可编一个答案也不愿意填待确认或空字符串——这是大模型的通病。所以你在指令里必须明确写出未出现则填待确认这种兜底分支并且在示例里真的放一个找不到责任人的样例让它学。二是风险提取的判定条件太宽泛。你写若出现风险、延期等词则记录模型就会把任何带问题两个字的句子都抄进来。后来我要求它只保留影响交付的负面描述并限制每个风险字段字数不超过30字输出质量立刻好了不少。这个问题的终极解法是加一个校验层让脚本在收到模型输出之后先跑一遍字段级检查发现owner是空或者risk超过30字就直接打回重写而不是人肉看。Skill是一个协作体模型负责生成脚本负责约束与纠正两边配合才是完整的。4.3 技能越写越臃肿反而变笨最后一个问题来自贪心。很多人包括我自己在写技能的时候总想一步到位一个Skill里既包含提取待办又包含生成会议纪要还包含统计每个人本周的任务量甚至想附带发送邮件的工具调用。结果就是这个Skill的指令文档越来越长模型加载之后要在几百行指令里自己找重点行为变得飘忽不定时对时错。这是非常典型的过度设计。解决思路就一句话一个Skill只做一件完整的事。注意完整的事不等于简单的事而是有一个清晰的开始和结束、一个可验收的结果。生成待办清单是一件事统计工作量是另一件事发送邮件是第三件事。如果你确实需要一条龙流程那也应该拆成三个Skill由一个更高层的编排者按顺序调用而不是把它们揉在一起。我给自己定了一套技能瘦身checklist每次写完都过一遍检查项判断标准技能目标数只能有一个核心动词比如提取生成归类指令文档行数建议控制在150行以内超过的先怀疑是不是混了多个技能外部依赖数引用的脚本、数据文件不超过3个多了就拆输出格式数只输出一种格式JSON或Markdown不要左右逢源兜底分支数每个字段最多一个找不到怎么办多了就是你没想清楚这张表不一定适合所有场景但对90%的内容处理类技能是好用的。反正我按照这张表重新梳理过好几个项目里的技能之后出错率都明显降下来了与其说是模型变聪明了不如说是技能变本分了。最后再分享一个我自己的小经验如果你是被skills这个词吸引过来的新手我的建议很简单不要在第一周就雄心勃勃地写三五个复杂技能先挑一个你日常高频但琐碎的任务——比如整理周报、提取账单、把群聊记录汇总成要点——做成一个只有几十行指令和一个小脚本的Skill。认真走一遍写描述-写指令-离线测试-边界调试的完整流程你的收获会比看三十篇概念文章都大。等手感来了再尝试把多个技能串成一个流程也不迟。我自己就是从一个三十行的待办提取器开始半年后手里攒了十几个能用、够稳的技能包。这条路径目前看对谁来说都还算靠谱。