1. 为什么我开始重新审视Skills这件事最近和几位做AI应用的朋友聊天发现大家不约而同地把注意力从怎么写出更长的提示词转移到了一个叫Skills的概念上。这个词在技术圈里火起来不是没道理的——它正在悄悄改变我们让大模型干活的方式。先说说我个人的感受。去年我在做一个内部文档问答工具时为了让模型按特定格式输出周报我在系统提示词里塞了差不多3000字的规则说明字段怎么填、日期格式怎么校验、异常情况怎么兜底……结果模型偶尔还是会漏掉某个字段或者把日期格式写成2025年4月12日而不是我要求的2025-04-12。每次改规则都要翻半天提示词用户体验也很割裂。后来我接触到了Skills的玩法才意识到过去那种把所有规则堆进提示词的做法本质上是在让模型从一段冗长的自然语言描述里猜我到底想要什么。而Skills的做法是把一套完整的执行能力包括明确的目标、步骤、参考脚本、示例、校验逻辑打包成一个结构化的文件夹模型在需要的时候会主动去加载这个技能像调用工具一样执行它。这套机制彻底解决了我两个痛点。第一提示词不再臃肿主提示词只负责对话策略具体的干活方式全部下沉到Skill文件里第二复用性极高同一个Skill可以挂到不同的项目里改一下配置就能适配新场景。如果你也在做AI应用开发、自动化流程设计或者团队成员里有人天天跟提示词较劲这篇文章值得你花十分钟读完。我会把它拆开揉碎从最核心的设计思路讲起再给出一套可以直接抄作业的构建方法最后附上我踩过的坑。2. 先搞懂Skills的底层逻辑2.1 它和提示词到底差在哪我在给团队做内部分享时最喜欢用一个比喻传统提示词像给一个聪明但没经验的新人发微信你得把需求说清楚、步骤列明白、注意事项逐条叮嘱他才能把活干对Skills则像是给这个新人一套带说明书的工具箱他打开工具箱就知道第一步干啥、第二步干啥、遇到异常找哪个手册。两者的本质区别在于系统是否拥有被唤起的能力。传统提示词里的规则是静态的每次对话都必须全部注入上下文模型不管用不用得上都得读完而Skills是一组按约定组织的文件模型可以在判断这个任务需要特定能力时主动去读取对应的SKILL.md文件用完之后只保留执行结果不需要把整本说明书一直背在脑子里。这带来的直接好处就是上下文窗口的解放。我实测过一个功能完整的Skill文件加上配套脚本可能占2000到4000个token如果用传统方式写进系统提示词这部分开销是固定的。而用Skills机制这部分token在处理无关任务时是零开销。另一个核心差异是可编程性。传统提示词本质上是文本你没法在里面写条件判断、循环、调用外部工具但Skills文件夹里除了说明书SKILL.md还可以放Python脚本、JavaScript代码、配置文件、参考模板。模型在执行时不只是按文字描述想象着做而是真的可以跑一段脚本去处理数据、调一个API去查信息、执行一段命令去操作文件。2.2 一个标准Skill的内部长什么样虽然不同平台的Skills机制在细节上略有差异但底层约定基本一致。我以目前最通用的一套规范为例一个典型的Skill通常包含以下内容组成部分作用必选还是可选SKILL.md技能说明书告诉模型这个技能能做什么、怎么用、有哪些步骤必选scripts/存放可执行的脚本Python、Bash、JS等供模型调用可选但强烈建议assets/存放静态资源比如模板文件、参考文档、示例数据可选config.json技能配置定义名称、描述、允许的操作范围等可选requirements.txt脚本依赖清单方便环境一键安装可选SKILL.md是整个技能的核心它的质量直接决定模型能不能正确使用这个Skill。我见过很多半路出家的Skill写不好问题基本都出在这份说明书上——要么写得像需求文档要么写得像散文模型读完根本不知道第一步该干什么。打个比方SKILL.md应该像机场的登机指引清晰、有序、每一步都有明确的动作而不是像旅游攻略那样描述你可以选择坐地铁或者打车如果时间充裕的话还可以逛逛。模型需要的是执行而不是选择。3. 动手之前先把Skill的使用场景想明白3.1 什么样的任务适合封装成Skill不是所有任务都适合做成Skill。我的经验是满足以下三个特征的任务封装成Skill的收益最大第一任务流程相对固定。比如把一段录音转成会议纪要无论谁来发这个需求处理流程都是转写语音、抽取发言人和时间线、按议题归纳、生成待办事项。这种流程固定的任务非常适合把每一步拆成明确的指令。第二需要领域知识或格式要求。比如财务报销单OCR识别后的结构化输出字段名、校验规则、异常处理都是高度领域化的光靠提示词很难一次说清。封装成Skill后所有规则写进说明书模型按图索骥就行。第三会被反复使用。如果你只是临时让模型做一次文本分类写个临时提示词就够用了但如果你的团队每周都要做数据分析报告、每天都要整理竞品动态那就值得投入时间把流程沉淀成Skill。3.2 封装前需要做减法别做加法