过去这两个月我几乎把所有精力都花在了折腾 skills 上。不是背单词的那种技能清单而是 AI 智能体领域里的 skills把一套可复用的能力打包成文件按需加载给大模型使用。说得直白点它就是给 AI 配的工作手册——平时放在书架上遇到对应场景抽出来翻开而不是把所有规则都贴在墙上。我之所以认真研究它是因为一个很具体的痛点我经常需要让 AI 按固定的格式产出东西比如公司风格的周报、带特定字段的会议纪要、内部项目的变更说明。以前的做法是每次对话里把规则重新粘一遍时间长了我自己都懒得维护那串越来越长的提示词。后来看到 skills 的思路我才意识到问题不在模型能力而在能力怎么组织。这篇文章就是把这段时间的实践、踩坑和思考完整梳理一遍适合正在做 AI 自动化流程、写智能体脚本、或者只是想提高日常 AI 使用效率的人。1. 为什么现在的 AI 工作流都在谈 skills先搞清楚它解决的是什么问题1.1 通用模型的什么都会与固定流程的必须这样一个没有 skill 加持的大模型本质上是一个什么都会一点的通才。你说帮我写份周报它能写出像模像样的内容但大概率不是你们公司需要的周报日期格式不对、项目名写错、缺少风险项、进度百分比没填。因为模型并没有读过你们公司的周报规范它只是基于海量文本训练出的平均印象在作答。普通用户会觉得够用了但当你要求它连续三周产出同一格式的周报第四周它还是会悄悄改掉字段顺序。这不是模型变笨了而是没有任何机制把必须遵守的做事方式变成一个稳定的约束输入到每次调用中。你越是依赖这次再提醒它一遍输出就越像抽签。真正需要解决的问题不是模型能不能做到而是怎么让固定流程成为模型的默认行为。1.2 系统提示词、示例跟随、函数调用三条老路各自堵在哪往前倒几个月大家解决这个问题的方式无非三种我全都试过每一种都有明显的天花板。第一把所有规则写进系统提示词。这是最直觉的思路但提示词很快就膨胀到几千词。表述一多模型对规则的注意力被稀释后面的规则可能覆盖前面的规则还会和用户对话内容互相干扰。我见过一份三千词的 system prompt结果模型只记得前半段后半段的作用被中间一段无关输出冲掉了。第二给模型塞示例。在提示词里放两三个标准答案确实能提高格式稳定性但示例只能覆盖点覆盖不了整体流程。你给它看了三份周报它可能模仿第四份的排版却学不会先查项目进度、再整理风险、最后汇总领导关心的问题这个处理顺序。第三函数调用。这适合模型去触发外部动作比如调接口、查数据库、改文件。但它解决的是模型能不能做某个动作不解决模型该用什么方式持续地做一类动作。你会用函数调用去查天气但不会用它来管理你那套二十条的周报书写规则。这三条路的核心问题是一样的能力边界不是封闭的而是和具体场景强耦合的。每次从全部规则里检索出当前需要的那部分靠提示词工程做既不稳定也不便宜。1.3 skills 的本质把该怎么做和什么时候用一起封存skills 之所以在近半年里被越来越多的 AI 客户端和开源项目采用我觉得它抓住了一个关键思路不再把所有指令塞给模型让它自己挑而是把某一类场景的完整操作方法写成一个独立文件模型根据当前任务的特征决定要不要加载这个文件。我习惯用一个比喻system prompt 是公司的员工手册skills 是工位抽屉里的作业指导书。员工入职时读一遍员工手册就上岗了但真要操作某台设备、走某个特殊流程时他从抽屉里抽出对应那张指导卡照着做做完放回去。这样一来工作记忆不会被五十份指导卡占据每份卡之间的指令冲突也消失了。这个思路带来的好处是立竿见影的上下文更省了只有需要时才加载能力边界更清晰了一个 skill 管一件事维护更容易了改周报规则只改周报那个 skill不影响其他任务。而且它和函数调用完全不冲突skill 里完全可以写明遇到什么情况去调用哪个脚本、哪个 API两者是组合关系而不是替代关系。理解到这层再看具体实现就顺了。2. 一个 skill 的内部结构把能力写进文件而不是藏进对话2.1 先说最常见的目录规范SKILL.md、scripts 和 assets 各管什么虽然各家平台实现略有差异但我推荐的、也是社区里出现频率最高的做法是目录式组织。一个 skill 就是一个目录目录名就是技能名例如skills/ └── weekly-report/ # skill 名称weekly-report ├── SKILL.md # 核心指令文件模型读它就知道怎么做 ├── manifest.yml # 元信息描述、版本、依赖部分方案并入 SKILL.md 头部 ├── scripts/ # 可执行的辅助脚本 │ ├── parse_tasks.py │ └── format_excel.py └── assets/ # 静态参考资料模板、示例文档等 └── weekly_template.md这个结构非常明确SKILL.md 是给模型看的操作说明scripts 是模型通过工具调用的具体执行器assets 是模型可以参考的输入输出模板和素材。三者的关系有点像操作规程 工具 案例。注意scripts 和 assets 是可选的很多纯文本类 skill 只有一个 SKILL.md 照样跑得很好但一旦涉及数据处理、格式转换、文件操作脚本就能把模型的口头承诺变成可执行操作准确率会上一个档次。元信息则可以直接放在 SKILL.md 头部的 YAML 区域里这样整个 skill 就是一个文件夹加一个文件管理起来最省心。2.2 SKILL.md 是给模型读的操作手册不是给人类看的 README写 SKILL.md 最容易犯的错误是把它当成给人类看的 README。事实上读完这份文件的是一套上下文窗口有限的模型它不会像人一样自动领会字里行间的意图也不会记住你埋在第三段的暗示。所以我的写法遵循一个固定套路顺序很重要最前面写触发条件。用一两句话说明当用户需要 X 或者出现 Y 时可以使用本 skill。这是模型判断要不要加载它的依据不写清楚skill 再优秀也不会被调用。中间写固定流程。按步骤列出处理顺序比如第一步收集输入、第二步校验数据、第三步生成初稿、第四步套用模板。每一步的动作要具体到可执行避免使用合理整理这类模糊动词。靠后写输入输出规范。明确输入长什么样、输出长什么样必要时给出字段名、长度、日期格式。末尾放示例。一两份完整示例比十句解释都有用模型对示例的模仿能力比对规则文本的遵循能力更强。这里有个细节值得专门强调SKILL.md 内部不要写一堆你应该请注意这类规训式的话。模型不吃这一套这类句子只会白白占据上下文空间。它需要的是事实和步骤不是态度。2.3 description 字段决定模型会不会想起这个 skill我把它单独拿出来讲是因为这是我在实践中观察到的、对调用率影响最大的一个因素。很多实现会在 SKILL.md 的 frontmatter 或 manifest 里要求填一个 description用来告诉模型这个 skill 是干什么的。千万别随便写写不好模型根本不会调用它。我总结过几版 description 的对比写法类型示例模型的实际表现差周报工具太泛模型无法判断适不适合当前任务经常不调用中生成周报勉强能识别但无法区分日报和项目周报的差别好将分散的项目进度整理为公司标准周报格式包含日期、项目名、进度、风险、下周计划五个字段模型能清晰判断何时触发、何时不触发写 description 的核心原则是让模型能做出是/否判断。它应该回答的是当前任务符合这个 skill 的处理范围吗而不是当前任务和一个模糊的名词沾边吗。我见过不少人把 description 写成宣传语高效、强大、全能的周报神器这类词没有判断价值模型不知道该不该用。3. 实操把一个高频场景做成 skill 的全过程以结构化周报为例3.1 先定输出再定流程从目标格式倒推设计动手写文件之前我会花最多的时间做一件事把输出格式固定下来。因为 skill 的终极目标是产出一致的结果而一致性最直观的体现就是输出格式稳定。就拿我做的 weekly-report 这个 skill 来说需求来自我每周五都要花半小时整理项目周报要把群里零散的消息、代码仓库的提交记录、同事发来的进度整理成一份领导一眼能看懂的周报。我先把最终输出定义成下面这样周报标题X 项目周报YYYY-MM-DD 至 YYYY-MM-DD第一部分本周核心进展3 至 5 条每条约 50 字第二部分风险与阻塞没有则写无第三部分下周计划3 至 5 条第四部分数据/附件说明可选这个格式看起来简单但它是整个 skill 的核心。模型产出只要符合这个结构哪怕中间措辞有差异都是可控的反之结构不稳定后面全都不可控。定好格式之后我再倒推要产出这样的周报模型需要哪些输入、按什么顺序处理整个 skill 的逻辑就出来了。我强烈建议每个做 skill 的人先做这一步先定义输出再设计流程而不是反过来。3.2 第一版 SKILL.md 怎么写一份可以直接参考的完整示例下面是我这个周报 skill 第一版 SKILL.md 的核心内容做了脱敏处理保留了完整骨架。你可以直接参考它的组织方式。--- name: weekly-report description: 将分散的项目进度输入整理为公司标准周报输出包含标题、本周进展、风险与阻塞、下周计划、说明五个部分的固定格式文本。适用于用户提供多条项目动态、提交记录或口头描述并要求生成周报的场景。 version: 0.1.0 --- # 周报生成流程 ## 触发条件 当用户要求生成周报项目周报weekly report或提供多条项目动态并要求按固定格式整理时使用本 skill。 ## 输入要求 用户通常提供几种形式的素材 1. 多条消息记录或文字描述 2. 提交记录列表 3. 直接说明按上周格式生成 若素材不足例如缺少风险信息不要凭空编造输出待补充。 ## 处理步骤 第一步将输入拆分为进展风险计划三类 第二步检查每条进展是否包含项目名和状态词完成/进行中/阻塞 第三步合并同类项去掉重复内容 第四步按输出格式生成文本日期区间取本周一和本周日 ## 输出格式 标题{项目名} 周报{本周一日期} 至 {本周日日期} ### 本周核心进展 - 每条以动词开头50字以内 ### 风险与阻塞 - 列出风险及应对措施没有则写无 ### 下周计划 - 每条以动词开头 ### 说明 - 备注数据来源或待确认事项这里有个容易被忽视的点frontmatter 里的 name 和 description 与正文里的触发条件要互相呼应。name 是技能的唯一标识description 面向模型做意图匹配触发条件则是已经决定加载后再次确认适用性。三层各干各的别混在一起写。version 字段也建议从一开始就留着后面迭代时你会感谢自己的习惯。3.3 本地加载与第一次调用环境准备和冒烟测试文件写好之后最关键的问题是怎么让模型在对话时能读到它。不同工具的实现方式不同但主流思路是一样的把 skills 目录配置给客户端或框架然后在模型侧定义一个固定的工具入口用于读取 skill 文件。以我常用的本地方案为例分成三步第一把 skills 目录放到固定位置。我习惯放在项目的skills/目录下客户端启动时扫描这个目录每个子目录对应一个 skill。如果你用的是现成客户端通常是在设置界面里填一个目录路径不用自己写代码。第二配置模型可用的读取工具。如果你的方案基于函数调用那么定义一个名为load_skill(skill_name)的工具模型发现任务匹配某个 skill 的 description 时调用它加载 SKILL.md 并继续处理。这一步是把 skill 从静态文件变成模型能主动触达的能力的关键桥接。第三做一次冒烟测试。找一条典型输入比如我这周完成了登录模块、修了三个 bug下周做支付模块麻烦生成周报调用后看输出格式是否完整、字段是否有遗漏。我第一次跑通时输出里出现了本周核心进展和风险两部分格式基本正确说明配置没问题。到这一步skill 已经能用了接下来的问题才是真正花时间的怎么让它稳定地好用。4. 让 skill 稳定可用的调试方法调用率、上下文和回归测试4.1 模型不调用 skill先回头检查 description 和触发条件在本地实测一周后我发现最让人崩溃的问题是模型有时候会无视这个 skill直接凭记忆生成周报。第一次遇到时我以为是框架 bug后来排查发现是描述和触发条件写得不匹配。具体来说我在 description 里写了适用于用户提供多条项目动态的场景但实际使用时用户说的是写周报并没有提供多条动态这个字面特征。模型一看描述里说要项目动态以为不匹配就不调用。我的修复方式是让 description 以用户表达什么意图为中心而不是以输入素材长什么样为中心。因为模型判断任务的依据是用户的意图用户想要周报而不是输入的形式输入是不是动态列表。改完之后调用率立刻上来了。所以如果你的 skill 经常不被触发先回头读一遍 description假装自己是那个什么都不知道的模型看你会不会调用它。4.2 被调用了但输出仍然飘检查指令顺序和示例调用的问题解决后第二类坑出现在输出质量上有时候进展写得很好有时候又跑偏比如把风险与阻塞写成空、在下周计划里塞进来未完成事项。我逐条对照 SKILL.md 后发现问题不在写得不够严格而是处理步骤和输出格式之间隔着太多推理性步骤。模型确实照做了拆分类别但它对什么叫风险的理解和我不完全一样。解决方法是两步走。一是在处理步骤里把每一步的结果明确定义。比如风险这一条我增加了一句风险会导致项目延期、需领导知晓的问题不含日常沟通摩擦模型的理解立刻稳定了。二是在 SKILL.md 末尾放一份完整的输出示例让模型能对照样板填空。我自己试下来示例对输出稳定性的贡献甚至超过了大段规则描述给模型看一个正确答案比告诉它一百遍什么叫正确更有效。4.3 建一个最小回归集用固定的三组输入反复迭代调试 skill 最忌讳的是这次跑通了就觉得完成了。因为模型有随机性同一份输入今天这样、明天那样都很正常。我的做法是维护一个最小回归集三到五组有代表性的输入覆盖正常输入、边界输入、残缺输入三类。回归集的内容很简单我用一个文本文件记录每组的输入和预期输出要点每次修改 SKILL.md 后就把这几组输入跑一遍对比输出是否仍然满足核心预期。比如我的周报回归集包括正常素材输入应该输出完整五部分、零风险输入风险部分应输出无、只有一句话的极短输入应该输出其他字段为待补充而不是编造。任何修改如果导致回归集里有任何一条不达标我就不发布这版。这个习惯坚持三周后我的 skill 从偶尔好用变成了大概率和期望一致投入产出比非常高。5. 边界感什么场景值得做成 skill什么场景做了反而累赘5.1 高性价比场景高频重复、强格式要求、私有领域知识做 skill 做到后来我最大的体会反而是别什么都往里塞。回顾这段时间投入产出比最高的是三类场景。第一是高频重复场景比如周报、月报、会议纪要、客户回访记录一周用几次每次节省的时间都能感受到。第二是强格式要求场景比如公司内部单据、法律文书结构、数据报表格式模型很容易在这些场景里自由发挥skill 恰恰能把格式锁死。第三是需要私有领域知识的场景比如团队内部的部署清单、测试流程、发布检查项这些内容模型本来不知道你也不想每次都在提示词里写放进对应 skill 后按需调用就很自然。5.2 别做的场景一次性探索和需要大量自由上下文的研究类任务反过来我也踩过坑。有一次想给一个临时数据分析探索的活做 skill忙活一下午最后发现这个任务每次输入差异巨大几乎没有固定流程skill 写出来几乎等于一份空泛的指令列表还不如直接对话里交代。后来我总结出两组信号如果任务每次都需要重新思考、没有稳定重复的处理路径不要做 skill如果任务需要模型掌握大量跨领域的自由上下文比如让它梳理一个全新项目的整体思路不要硬塞 skill 结构。skill 适合的是流程已知、格式确定的执行类任务不适合开放探索、依赖发散思维的研究类任务。把这两类分清能省下大量无效打磨时间。5.3 看长期skill 是持续迭代的资产按代码的方式维护最后说一个经常被忽略的运维问题skill 是代码会腐化。业务规则一变比如周报格式新增了一个字段你得改 SKILL.md团队新来了同事操作流程变了脚本也要跟着动。我建议像管代码一样管 skill用 Git 做版本管理每次修改留下一行变更说明SKILL.md 头部加版本号字段方便回溯重要 skill 配一个自动化测试脚本把回归集的比对跑起来。这些习惯前期看着繁琐但当 skill 数量超过五六个、开始相互依赖的时候它们的价值会成倍放大。我个人的体会是skills 最打动我的不是某个特定的实现而是它把教 AI 做事这件事从临场发挥变成了工程化管理。过去我们是在对话里临时教育一个天才实习生现在我们是给它建一套可以持续迭代的工作手册。第一份手册可能粗糙但第二份、第三份会越来越接近团队真正的工作方式。如果你也在研究自动化我的建议很简单不要追求一开始就完美挑一个你每周都在做、烦了很久的任务做成第一个 skill跑三周再回头改。只有真正用过的人才能体会这个概念的重量。