有段时间我特别头疼一件事让 AI 帮忙处理邮件、整理会议记录、生成项目周报结果今天好用明天翻车同一个需求换个说法执行质量就完全不一样。后来我意识到问题不在模型笨而在我每次都在临时教它而不是给它一套稳定的作业流程。真正解决这个问题的就是我现在要聊的 Skills 编写学习——把一次成功的工作方式沉淀成可复用的能力包。这篇内容适合两类人一类是刚接触 AI 工具、想让输出更稳定的普通用户另一类是正在研究怎么把 AI 集成到工作流里的技术同学。我会从 Skills 的底层逻辑讲起再拆解一份真实的 SKILL.md 应该怎么写最后把我自己迭代三版、踩过五个坑的全过程摊开给你看。看完你就能自己动手写第一个 Skill而不是继续靠运气调提示词。1. 先搞清楚一件事Skills 不是提示词是一套能力工程1.1 为什么每次让 AI 干活都像开盲盒大模型本身没有记忆同一个问题它每次回答都依赖你当下给的上下文。你今天把要做什么、按什么格式输出、注意哪几条红线写在提示词里明天换个人来问这些细节就全丢了。我一开始也天真觉得自己攒一套万能提示词模板就够了。结果发现提示词越长模型越容易选择性失明。十条规定它可能记住七条漏掉的三条恰恰是最关键的输出格式要求。更麻烦的是提示词只能解决一次性调用它没法把一套业务流程拆成多个可重复的环节也没法把范例文件、参考模板、辅助脚本一起带上。1.2 Skills 的本质把临时交代变成固定岗位Skills 的设计思路是把一个专业任务所需要的全部要素打包进一个文件夹任务说明、执行步骤、输出格式、参考范例、辅助数据甚至脚本。模型每次被调用时先加载这套岗位说明书再按里面的规矩干活。用生活化的比喻就是提示词像你在餐厅里临时跟服务员说少放盐、多放辣、别放香菜Skills 则像直接给后厨一份标准菜谱里面连每道菜的分量和摆盘要求都写好了。效果稳定是因为规矩不再依赖某一次的运气。一个完整的 Skill通常由三部分组成元信息负责告诉模型什么时候该用我、指令正文负责告诉模型具体怎么干、资源文件负责提供干活的参考材料。三者缺一不可很多新手只写了指令正文结果模型不知道何时主动调用也没有参考材料来控制输出格式。1.3 和普通提示词的核心差异我用一个表格把两者的区别摆清楚你看完就明白为什么提示词做不到的事Skills 能做到对比维度普通提示词Skills存储形式散落在对话里需要反复粘贴独立的文件结构可复用、可分发触发方式靠人每次手动描述靠 description 自动匹配任务场景资源支持只能把内容塞进对话可附带模板、数据、脚本等文件输出一致性容易受到上下文干扰有明确流程和格式约束相对稳定迭代方式每次都要改一段全新文字只改对应的 SKILL.md版本可管理这一对比背后其实藏着 Skills 真正的价值它把教模型干活这件事从对话艺术变成了工程管理。你可以像维护代码一样维护它——有版本、有测试、有回滚。这也是为什么我说Skills 编写学习本质上是在学习一套新的能力工程方法。2. SKILL.md 拆解你要写的每一段都有明确职责2.1 一个 Skill 的标准目录长什么样动手写之前先得知道一个 Skill 的物理结构。在主流 AI 助手平台上一个 Skill 通常就是一个文件夹名字一般用中划线分隔的小写单词比如 meeting-minutes、weekly-report、code-review-helper。文件夹里面至少要有一个 SKILL.md 文件这是整个 Skill 的核心入口。除此之外按需放置 resources参考文件、scripts辅助脚本、assets静态资源。我在实际使用中最常用的组合是 SKILL.md 加一个 references 目录里面放输出模板和正反例。目录结构示例meeting-minutes/ ├── SKILL.md └── references/ ├── output-template.md └── examples/ ├── good-example.md └── bad-example.md这个结构本身就在传达一个重要信息Skill 不只是一个文字说明它是一个可以携带生产资料的工作包。后面你会发现references 里的范例和模板对输出质量的提升作用甚至超过指令正文。2.2 frontmatter 里 name 和 description 的写法SKILL.md 开头有一段 YAML 格式的元信息通常包含 name 和 description。这一段看起来简单却决定了模型什么时候想起用它可以说整个 Skill 的生死都系在 description 上。name 的作用是唯一标识建议和文件夹名一致。description 则是给模型看的触发条件说明它要回答的问题是什么情况下该调用这个 Skill我在练习初期犯过一个典型错误description 写得太抽象比如用于整理会议纪要。结果模型判断边界很模糊有时候用户只是提到昨天开会说了个事它就自作主张调用有时候用户明确说把这段转录文本整理成纪要它反而没反应过来。正确的写法应该是场景描述 任务描述 输入类型比如这样--- name: meeting-minutes description: 当用户提供会议录音转录文本、速记文字或聊天记录并要求整理成结构化会议纪要、提取行动项或分配待办任务时使用本技能。适用于产品评审、项目周会、客户沟通等场景。 ---仔细看这个描述它写清楚了输入是什么转录文本、速记文字、聊天记录写清楚了输出是什么结构化纪要、行动项、待办任务还列举了几个典型场景。模型读到这样的描述匹配成功率会高很多。2.3 正文指令的三种写法流程式、约束式、示例式SKILL.md 的正文是重头戏我把它归纳成三种写法初学者往往只用一种所以要特别提醒三种要配合使用。流程式写法是给模型规定先做什么、再做什么、最后做什么。它适合多步骤任务能防止模型跳步。约束式写法是明确必须做什么、禁止做什么用来划定行为边界。示例式写法是给出具体的输入输出范例让模型照着样子模仿。我自己写正文时有个习惯顺序先用流程式搭骨架再用约束式堵漏洞最后放示例压质量。比如一个整理会议纪要的 Skill流程式部分规定先通读全文识别主题再按议题归类要点然后提取行动项最后套用输出模板。约束式部分规定不要虚构未出现的结论不要给未提到的人分配任务不确定的信息要标注待确认。2.4 资源文件怎么组织、怎么引用资源文件的价值在于给模型提供参照物。单靠语言描述一个目标格式模型经常理解偏直接给它一份完整范例它就能模仿得八九不离十。在 SKILL.md 正文里引用资源文件时我推荐使用相对路径格式类似references/output-template.md。模型通常能读取 Skill 目录下的附带文件路径写清楚、文件名有语义它就能找到。这里有个实操细节我建议把资源文件按功能分开放模板归模板、范例归范例、脚本归脚本不要在 references 目录下面堆一堆无名无姓的文件。模型在看指令时最讨厌的是面对一坨混乱的文件清单它会不知道该参考哪一个。3. 从零写一个实战 Skill会议纪要与行动项整理3.1 写之前先回答四个问题我每次动手写新 Skill 前都强迫自己先回答四个问题答不清楚不动笔第一这个任务的核心产出物是什么比如会议纪要的产出物就是一份结构化文档。第二产出物的格式长什么样是分点列表还是带表格还是纯段落第三哪些地方绝对不能出错比如虚构结论、漏掉行动项。第四什么情况下这个 Skill 不该被使用比如没有原始材料时。这四个问题的答案就是你 SKILL.md 的骨架。前面讲了那么多结构设计落到实操上就是从这四个问题里长出来的。以会议纪要与行动项整理为例我的答案是这样的产出物是一份包含会议主题、时间、参与方、讨论要点、决议事项、行动项表格的文档格式上要求讨论要点按议题分组行动项必须走表格绝对不能出错的是行动项里的负责人和截止时间原始材料缺失或过于简略时不强行生成纪要。3.2 完整 SKILL.md 逐段讲解下面是我实际在用的一份 SKILL.md 节选我逐段给你讲为什么这么写--- name: meeting-minutes description: 当用户提供会议转录文本、速记文字或聊天记录并要求整理成结构化会议纪要、提取行动项或分配待办任务时使用。适用于产品评审、项目周会、客户沟通等场景。 --- # 会议纪要与行动项整理 ## 第一步通读与识别 先完整阅读输入材料识别会议主题、关键参与人以及讨论的主要议题。 如果材料中出现多人对话尝试根据上下文区分发言角色。 ## 第二步按议题归纳 将讨论内容按议题分组剔除寒暄、重复表达和无关闲聊。 每个议题保留三要素背景、讨论结果、遗留问题。 ## 第三步提取行动项 逐条检查材料中所有需要有人做某事的表达提取出来。 行动项必须包含事项描述、负责人、截止时间。 材料里没有明确截止时间的标注待确认不要自行编造。 ## 第四步按模板输出 严格按照 references/output-template.md 中的格式输出。 输出后自行检查是否所有行动项都进入表格是否有虚构内容拆解一下这里面的设计逻辑第一步和第二步属于流程式写法管住分析过程第三步前半句是流程后半句不要自行编造是约束式写法第四步引导模型使用外部模板并让它输出前自检。你会发现一个不到二十行的文件已经覆盖了流程、边界、格式、自检四个方面这就是一个合格的 Skill 该有的密度。3.3 配套 references 模板光有 SKILL.md 还不够我在 references 目录里放了一个 output-template.md内容大概长这样# 会议纪要 会议主题{{主题}} 会议时间{{时间}} 参与角色{{角色列表}} ## 讨论要点 ### 议题一{{议题名称}} - 背景{{背景说明}} - 讨论结果{{结论}} - 遗留问题{{遗留事项}} ## 决议事项 - {{决议内容}} ## 行动项 | 事项 | 负责人 | 截止时间 | 状态 | | --- | --- | --- | --- | | {{行动项}} | {{负责人}} | {{截止时间}} | 待办 |模板的作用是锁死输出结构。模型只要按模板走你拿到的每一份纪要排版都是统一的后续如果要做自动化处理解析起来也省心很多。我在多处实操中验证过一件事没有模板时模型输出的格式五花八门有模板时基本一次成型。3.4 第一次试跑的翻车现场我第一次写完这个 Skill信心满满地扔了一段真实会议录音转写文本进去结果翻车翻得很彻底。模型把两个同名同事搞混了把本该属于 A 的行动项记到了 B 头上还自作聪明地给一个没提到的截止时间编了个日期。这次翻车给了两个重要教训。第一约束式指令不能只写不要编造要写没有就不写标待确认因为模型对否定式指令的执行力不足给它具体的替代动作反而更有效。第二同名义题在真实数据里很常见需要在流程里加入核对角色身份的步骤。4. 让 Skill 从能用到好用的三个进阶动作4.1 用检查列表兜住输出质量基础版 Skill 能保证做完但保证不了做好。我第二个阶段做的事情是给 Skill 加一个输出前检查列表。检查列表这招本质上是把模型的位置从执行者变成执行者审查者。我在 SKILL.md 末尾固定加一段输出前自查逐项列出必须检查的问题。比如行动项表格里有没有空的负责人所有负责人是否都在原文中出现过截止时间是否有编造嫌疑这个思路的来源其实很朴素我在训练自己带新人时发现与其反复纠错不如让他在提交前按清单自查一遍。模型也一样给它一份清单它能自己纠掉大部分低级错误你就不用每次都在输出里挑刺了。4.2 给指令写边界条款所谓边界条款就是明确告知模型遇到什么情况该怎么做本质上是预判异常并给出兜底方案。举个例子会议纪要 Skill 里我写了一条边界条款如果输入材料少于三句话或者明显缺失关键信息不要硬套模板直接输出一句输入材料过简请补充完整记录后再生成纪要。这条条款看起来简单但它避免了最尴尬的状况模型对着两行字硬编出一整页会议纪要全都是幻觉。我还习惯给每个边界条款配上触发条件执行动作的格式。触发条件要具体比如材料中未出现任何负责人的姓名执行动作要明确比如在行动项表格中标注待确认并在末尾提示用户补充。边界条款越多模型在异常情况下越沉稳输出越不容易出现离谱内容。4.3 用正反例压缩模型的自由发挥空间第三个进阶动作是我认为提升最明显的一招在 resources/examples 目录里放一个 good-example.md 和一个 bad-example.md。正向例子负责展示目标输出长什么样反向例子负责展示哪些问题绝对不能出现。比如 bad-example.md 里我会专门放一个有幻觉引用、格式混乱、行动项遗漏的反面教材并在旁边注明问题出在哪。这个做法有效是因为模型的模仿能力比理解能力更可靠。你给它一百字规则它不一定记住但你给它一个标准范例它真的会照着模仿。我在好几个 Skill 里都验证过加入正反例之后输出质量的波动幅度明显缩小尤其是格式一致性提升最显著。5. 调试是基本功同一个 Skill 我迭代了三版5.1 先建立自己的测试样本集Skills 调试最忌讳测一次就下结论。我自己的做法是每个 Skill 都准备一个固定的测试样本集至少包含五个不同的输入案例一个标准场景、一个被截断的输入、一个格式混乱的输入、一个包含敏感信息的输入、一个需要拒绝执行的输入。为什么要这样做因为只测一次你根本分不清这次效果好是指令写对了还是运气好碰上了。只有用同一批输入反复测你才能看出哪些问题稳定复现哪些问题只是偶发抖动。我把这个方法称为回归测试思维是从软件开发里借来的用在 Skills 调试上好使。5.2 三版改动明细与理由我做会议纪要 Skill 的三轮迭代每一轮的改动点都不一样也都有明确理由。V1 的问题是指令太笼统只有整理出要点这种话输出不稳定。V2 加入了输出模板和流程式步骤格式问题解决了但出现了幻觉信息尤其会编造时间。V3 的重点就是堵幻觉加入边界条款、输出前自查清单、正反例同时把 description 改得更精确避免误触发。三版改动我做成表格放这里版本主要改动解决的核心问题遗留问题V1只有基础指令输出结构混乱格式不稳定、细节丢失V2加入输出模板、流程步骤格式统一存在虚构信息、误触发V3加入自查清单、边界条款、正反例幻觉减少、触发更准复杂对话场景仍需人工复核每次迭代都只解决当前最痛的一个问题而不是一口气把能想到的规则全堆上去。这条原则我特别强调因为新手最容易犯的反面就是一次加二十条规则结果模型无所适从每条都没执行好。5.3 从失败案例反推指令的坑调试 Skill 最有价值的部分不是盯着成功案例看而是盯着失败案例找原因。我的固定流程是每次发现输出错误先问三个问题——是模型没理解指令、还是指令本身有歧义、还是指令没覆盖到这种情况如果是模型没理解我会把相关指令改得更直白多用必须、禁止、一律这类强约束词少用尽量、可以、酌情。如果是指令有歧义我会把模糊的词替换成可验证的表述。如果是指令没覆盖到我会判断这个场景值不值得专门写一条规则值得就补不值得就在 description 里缩小适用范围。这套反推流程让我从一个看见错误就烦躁的状态变成了看见错误就兴奋的状态——每个错误都是免费的测试反馈。6. 新手写 Skills 最容易踩的五个坑6.1 description 写得又美又没用第一个坑就是 description 写得太像宣传语比如高效智能地整理会议记录提升团队协作效率。这种话模型读不懂触发条件它只知道这个 Skill 挺好但不知道什么时候该调用。我现在的标准是描述必须包含三个要素——输入特征、任务目标、典型场景。没有这三个要素的 description基本等于没写。6.2 指令内部自相矛盾第二个坑藏在指令内部。有一次我写严格遵循模板输出紧接着又写根据内容灵活调整格式模型果然灵活调整了最后格式一塌糊涂。模型不会判断哪条指令优先级更高它只会机械地执行发现矛盾就容易随机选择。所以我每次写完 SKILL.md 都会通读一遍专门找前后冲突的表述宁可少写一条也不要写两条打架的。6.3 恨不得覆盖所有情况第三个坑是试图把世界上所有可能的情况都写进指令。结果 Skill 越来越长模型执行率越来越低。我后半程学会了取舍只覆盖高频场景和关键异常场景低频特殊情况直接留白靠模型应变。一个 SKILL.md 正文长度我建议控制在 500 到 1200 字之间超过这个区间边际收益就开始下降。6.4 忽略文件路径与资源限制第四个坑是资源文件的路径引用混乱。我见过有人在一个 Skill 里引用../../../data/old/xxx.md模型根本找不到指令执行到一半就断了。资源文件尽量放在 Skill 目录内部用相对路径引用文件名要有语义。另外要注意文件大小别把整本教材塞进 references模型一次能读取的上下文是有限的大文件反而会挤占真正重要的指令空间。6.5 测一次就宣布成功最后一个坑是验证不足。一个 Skill 在某一次输入上效果好不代表它真的合格。我自己的验证标准是至少准备五个测试案例连续三轮输出都稳定达标才敢把它放进生产流程。我还养成了一个习惯把每次测试的输入和输出都保存下来按日期和版本归档。回头迭代时这些历史记录就是最宝贵的判断依据能告诉我改动到底有没有效果而不是靠感觉。写到最后多说一句掏心窝的话Skills 编写学习最需要的就是把写文档当成写代码的心态。你写的每一份 SKILL.md 都是一段要被人反复执行的程序模型就是那个执行者。用这种心态去写你会发现它没有想象中那么玄乎剩下的就是多练、多测、多复盘。我自己也是从第一版翻车现场一路走过来的现在再看那一堆已经跑得很稳的 Skill靠的不过是两个字——较真。