1. 从两个真实场景说起：为什么SKILL写得好不好，差别这么大
我最早接触SKILL这个概念，是在给一个内部知识库做检索增强的时候。当时团队里几个人各自写了一批SKILL，结果用起来效果天差地别：有人写的SKILL，模型调用起来准确率很高，几乎不需要返工；有人写的SKILL，模型要么理解偏了，要么输出格式乱七八糟，来回改了好几轮还是不稳定。后来我们把所有SKILL摊开对比，发现问题根本不在模型本身，而在于SKILL的写法——写得好的那批，几乎都遵循了两种很清晰的设计模式。
这两种模式，就是Anthropic官方在最佳实践里反复强调的模板模式和示例模式。听起来像是老生常谈，但我实际用下来发现，真正能把这两种模式用对、用出效果的人并不多。大部分人写SKILL的习惯是“把需求描述清楚就行”，但SKILL不是写给同事看的PRD，它是写给模型看的执行指令。模型不会揣摩你的言外之意，它只会严格按照你给的约束去执行。所以SKILL的质量，直接决定了模型输出的下限和上限。
这篇文章我想聊的就是：这两种设计模式到底怎么理解、怎么落地、各自适合什么场景、踩过哪些坑。不管你是刚接触SKILL的新手，还是已经写过几十个SKILL的老手，我相信下面这些从实操里总结出来的细节，都能帮你少走一些弯路。尤其是那些“看起来差不多但效果差很多”的微妙之处，往往就是决定SKILL能不能真正跑通的关键。
2. 先搞清楚SKILL到底是什么：它不是提示词，是执行契约
2.1 SKILL和普通提示词的本质区别
很多人第一次听到SKILL，会下意识觉得“不就是提示词嘛”。我一开始也这么想，直到被现实教育了几次才明白，这两者的定位完全不同。普通提示词更像是一次性的对话指令，你问一句它答一句，上下文一换效果就飘。而SKILL是一份可复用、可组合、有明确输入输出边界的执行契约。它要解决的不是“这一次怎么问”，而是“这一类任务怎么稳定地做对”。
打个比方：普通提示词像是你在餐厅随口跟服务员说“来个清淡点的菜”，厨师怎么做全凭感觉；SKILL则像是一份标准菜谱，写清楚了食材、用量、火候、步骤、成品标准，换谁来照着做，出来的东西都不会差太多。这个类比可能不完全准确，但核心意思是：SKILL的价值在于确定性，它要把模糊的需求转化成模型可以稳定执行的指令集。
2.2 一个SKILL通常包含哪些要素
从我实际写过的几十个SKILL来看，一个结构完整的SKILL通常包含这几个部分：触发条件（什么情况下该用这个SKILL）、输入定义（需要哪些参数、格式是什么）、执行步骤（按什么顺序做什么）、输出规范（结果长什么样、格式怎么约束）、边界与异常处理（遇到不符合预期的情况怎么办）。这五个要素缺一个，SKILL的稳定性就会打折扣。
我见过最常见的错误，就是只写了执行步骤，其他四个要素全靠模型自己猜。结果就是同一个SKILL，今天跑得好好的，明天换个输入就崩了。不是模型变笨了，是你没给它足够的约束。模型在缺乏明确边界的时候，会倾向于“自由发挥”，而自由发挥在工程场景里几乎等于不可控。
2.3 为什么设计模式对SKILL这么重要
设计模式这个词听起来有点重，但放在SKILL语境下，它其实就是一套被验证过的、可复用的结构套路。你不需要每次从零开始想“这个SKILL该怎么组织”，而是根据任务类型，直接套用合适的模式，然后往里填内容。这就像写代码时用设计模式一样，不是为了炫技，而是为了让结构清晰、维护成本低、出错概率小。
Anthropic官方提到的两种模式——模板模式和示例模式——本质上解决的是两类不同的问题。模板模式解决的是“结构要稳定”的问题，示例模式解决的是“意图要明确”的问题。两者不是互斥的，很多时候需要配合使用。但如果你连它们各自适合什么场景都没搞清楚，就很容易用错地方，导致SKILL要么过于死板，要么过于模糊。
3. 模板模式：用固定骨架锁住输出的稳定性
3.1 模板模式的核心思路
模板模式的核心就一句话：把SKILL的结构固定下来，让模型在预设的框架里填充内容。你可以把它理解成填空题——题干和格式都是定死的，模型只负责往空格里填答案。这种模式特别适合那些输出格式要求严格、字段固定的任务，比如生成结构化的报告、提取特定字段、按固定格式转换数据等。
我举个实际例子。之前我做过一个从会议纪要里提取行动项的SKILL，一开始没用什么模式，就是直接告诉模型“帮我提取待办事项”。结果模型有时候输出一段话，有时候输出列表，有时候还夹杂自己的评论，格式完全不统一，下游根本没法自动处理。后来我改成模板模式，把输出格式定死成固定的字段结构，每个字段的填写规则也写清楚，输出立刻就稳定了。
3.2 模板模式的结构长什么样
一个典型的模板模式SKILL，结构大致是这样的：先声明任务类型和适用场景，然后给出一个固定的输出模板，模板里每个占位符都标注清楚该填什么、格式要求是什么、取值范围是什么。最后再补充一些填充规则和异常情况的处理方式。整个SKILL读下来，就像一份带注释的表格模板。
这里的关键在于，模板本身要足够具体。我见过有人写模板只写个大概框架，比如“输出一个JSON，包含标题和内容”，这种模板等于没写。真正有效的模板，会把每个字段的类型、长度、是否必填、示例值都标出来。比如标题字段要写清楚“不超过20个字，不含标点”，内容字段要写清楚“分点陈述，每点不超过50字”。约束越具体，模型执行起来越不容易跑偏。
3.3 模板模式的适用场景与局限
模板模式最适合的场景有三类：第一类是结构化输出，比如生成表格、JSON、固定格式的报告；第二类是字段提取，比如从非结构化文本里抽取特定信息；第三类是流程化任务，比如按固定步骤做数据清洗、格式转换。这些场景的共同特点是：输出的结构比内容更重要，或者说结构本身就是质量的一部分。
但模板模式也有明显的局限。它不擅长处理那些需要灵活判断、创意生成、或者输出结构本身就不固定的任务。你硬要用模板模式去写一个创意文案生成的SKILL，结果就是文案变得千篇一律，失去了灵性。所以模板模式不是万能的，它是一把专门用来锁结构的锁，用错了地方反而会限制模型的能力。
3.4 写模板模式SKILL的三个实操要点
第一个要点是模板要可验证。你写完模板后，要能拿几个真实输入跑一遍，看看输出是不是严格符合模板。如果模型经常在某个字段上出错，说明那个字段的约束还不够明确，需要继续细化。
第二个要点是留好异常出口。模板模式最怕遇到模板覆盖不了的情况，这时候如果SKILL里没写异常处理，模型就会硬套模板，输出一堆垃圾。所以一定要在SKILL里明确写清楚：当输入不符合预期时，应该输出什么、或者应该报错而不是硬填。
第三个要点是模板别写太死。有些字段可以给一定的灵活度，比如内容字段允许模型根据实际情况调整长度，只要不超过上限就行。把每个字段都卡得死死的，反而会让输出变得僵硬。这个度需要根据具体任务来把握，我的经验是：结构字段卡死，内容字段给弹性。
4. 示例模式：用具体案例把模糊意图变清晰
4.1 示例模式的核心思路
示例模式的思路和模板模式正好相反：不规定结构，而是给几个具体的输入输出示例，让模型从例子里自己归纳出规律。这有点像教小孩做题，你不跟他讲抽象规则，直接给他看几道例题，他看多了自然就会了。示例模式特别适合那些“说不清楚但一看就懂”的任务，比如风格模仿、语气调整、复杂判断等。
我印象最深的一次，是做一个把技术文档改写成通俗解释的SKILL。一开始我写了一大堆规则，什么“避免术语”“用生活化类比”“控制句子长度”，结果模型执行起来还是经常跑偏，要么改得太浅，要么改得失去了原意。后来我换了个思路，直接给了三组对照示例：左边是原始技术描述，右边是改写后的通俗版本。模型看了这几个例子之后，输出质量立刻上了一个台阶。
4.2 示例模式的关键：示例的质量决定SKILL的质量
示例模式看起来简单，好像随便给几个例子就行，但实际上示例的挑选和设计非常讲究。我总结下来，好的示例要满足三个条件：覆盖典型情况、体现边界处理、展示输出风格。只给一个示例，模型学到的规律太窄；给的示例都是同一种情况，模型遇到变体就懵了；示例本身质量不高，模型学出来的东西也好不到哪去。
具体来说，我通常会准备三到五个示例，其中两到三个是典型场景，一个稍微偏一点但仍在合理范围内，还有一个是边界情况。这样模型既能学到主要规律，又能知道遇到特殊情况该怎么处理。示例的输入输出都要完整，不能只给输入不给输出，也不能只给输出不给输入，那样模型没法建立对应关系。
4.3 示例模式和模板模式的组合用法
实际工作中，这两种模式经常是配合使用的。一个常见的组合是：用模板模式定输出结构，用示例模式定内容风格。比如生成产品描述，输出结构用模板固定成“标题+卖点+适用场景+注意事项”，但每个部分具体怎么写，用几个示例来示范语气和详略程度。这样既有结构上的稳定性，又有内容上的灵活性。
还有一种组合是分层的：外层用模板模式定义SKILL的整体框架，内层的某个复杂判断环节用示例模式来处理。比如一个客服回复生成的SKILL，整体输出格式用模板固定，但“判断用户情绪并选择回复策略”这个环节，用几个示例来示范不同情绪下该怎么回复。这种分层组合能让SKILL既可控又灵活。
4.4 示例模式的常见坑与规避方法
示例模式最容易踩的坑有三个。第一个是示例太少，模型归纳不出规律，输出随机性很大。我的经验是至少三个示例起步，复杂任务要五个以上。第二个是示例之间有矛盾，比如两个示例对同一种情况的处理方式不一致，模型就会困惑。所以示例之间要逻辑自洽，不能自相矛盾。
第三个坑是示例过拟合，模型把示例里的具体内容当成了规则，遇到新输入时生搬硬套。比如示例里都是关于电子产品的，模型就以为这个SKILL只能处理电子产品。要避免这个问题，示例的覆盖面要广一些，同时在SKILL里明确说明“以下示例仅用于示范风格和逻辑，具体内容需根据实际输入调整”。
5. 两种模式怎么选：一张对照表帮你快速决策
5.1 按任务类型选模式
选哪种模式，最直接的判断依据是任务类型。如果任务的核心是“输出结构要统一”，优先用模板模式；如果任务的核心是“输出风格要一致”，优先用示例模式。如果两者都重要，那就组合使用。下面这张表是我根据实际经验整理的对照关系，可以帮你快速定位。
| 任务特征 | 推荐模式 | 原因 |
|---|---|---|
| 输出格式固定，字段明确 | 模板模式 | 结构约束比内容示范更有效 |
| 需要模仿特定风格或语气 | 示例模式 | 风格很难用规则描述清楚 |
| 复杂判断，规则难以穷举 | 示例模式 | 示例比规则更能覆盖边界情况 |
| 流程化操作，步骤固定 | 模板模式 | 步骤顺序和字段需要严格约束 |
| 创意生成，但需保持调性 | 示例模式为主，模板为辅 | 结构可松，风格要稳 |
| 数据提取与格式转换 | 模板模式 | 字段映射关系需要精确定义 |
这张表不是绝对的，只是一个决策起点。实际用的时候，还要结合具体任务的复杂度、对稳定性的要求、以及你手头有多少高质量示例来综合判断。
5.2 按稳定性要求选模式
如果你对输出的稳定性要求极高，比如下游有自动化程序要解析输出，那模板模式是首选。模板模式通过固定结构，把输出的方差降到最低。但代价是灵活性差，遇到模板覆盖不了的情况容易出问题。这时候可以在模板模式的基础上，加一层异常处理逻辑，让模型在遇到意外输入时走备用路径。
如果稳定性要求没那么高，但希望输出有“人味”、有风格，那示例模式更合适。示例模式给模型留了发挥空间，输出会更自然，但方差也更大。我的做法是：核心字段用模板锁死，非核心部分用示例引导风格，这样在稳定性和灵活性之间取一个平衡。
5.3 按维护成本选模式
从维护角度看，模板模式的维护成本主要在结构变更上。一旦输出结构要调整，整个模板都得改，而且改完之后要重新验证所有字段。示例模式的维护成本主要在示例更新上，当业务规则变化时，需要替换或补充示例。相对来说，示例模式的维护更灵活，但前提是你要有一套管理示例的机制，不然示例越堆越多，最后自己都搞不清楚哪个示例在起作用。
我个人的经验是：如果这个SKILL会长期使用、频繁迭代，那前期多花点时间把模板设计好，后期维护会轻松很多。如果是一次性任务或者快速验证阶段，用示例模式快速跑通更划算。没有绝对的好坏，只有适不适合当前阶段。
6. 从零写一个SKILL：完整实操流程拆解
6.1 第一步：明确任务边界和成功标准
写SKILL之前，先别急着动手写内容。我踩过的最大坑就是上来就写，写到一半发现任务边界没想清楚，又回头改，浪费大量时间。正确的做法是先花十分钟把这几件事想明白：这个SKILL要解决什么问题、输入是什么、输出是什么、什么算成功、什么算失败。把这些写在一张纸上，后面写SKILL的时候就不会跑偏。
具体来说，我会问自己四个问题：第一，这个任务如果不写SKILL，人工做的话步骤是什么？第二，哪些步骤是重复的、可以标准化的？第三，输出结果会被谁用、怎么用？第四，如果输出错了，最严重的后果是什么？这四个问题的答案，直接决定了SKILL的约束强度和异常处理策略。
6.2 第二步：判断用哪种模式，搭好骨架
任务边界清楚之后，对照上一节的对照表，判断用模板模式还是示例模式，或者两者组合。然后搭一个骨架出来。骨架不需要很详细，但要把主要章节列出来。比如模板模式的骨架可能是：任务说明、输出模板、字段规则、异常处理。示例模式的骨架可能是：任务说明、示例列表、示例解读、注意事项。
搭骨架的好处是，你能在写细节之前先看到整体结构，发现逻辑不通的地方可以及时调整。我见过很多人写SKILL是线性写的，写到后面发现前面缺了东西，又回去补，补完后面又乱了。先搭骨架再填内容，能避免这种反复。
6.3 第三步：填充内容，逐字段或逐示例打磨
骨架搭好之后，开始填内容。如果是模板模式，就逐个字段写清楚约束；如果是示例模式，就逐个示例写清楚输入输出和解读。这一步最耗时间，但也最出效果。我的经验是，每个字段或每个示例写完之后，都拿一个真实输入在心里跑一遍，看看模型会怎么理解、会不会有歧义。
这里有个小技巧：写的时候把自己当成模型，假设你完全不知道这个任务的背景，只看SKILL里的文字，你能不能准确执行？如果某个地方你自己都要想一下才能理解，那模型大概率也会理解错。SKILL的语言要直白、具体、无歧义，宁可啰嗦一点，也不要留模糊空间。
6.4 第四步：用真实数据测试并迭代
SKILL写完不是终点，测试才是。我通常会准备五到十个真实输入，覆盖典型情况和边界情况，跑一遍看输出。测试的时候重点看三件事：输出格式对不对、内容准不准、异常情况处理得怎么样。如果某个输入下输出不对，先别急着改SKILL，先分析是模型理解问题还是SKILL本身有漏洞。
迭代的时候，每次只改一个地方，改完再测。如果一次改好几个地方，出了问题都不知道是哪个改动导致的。我一般会迭代三到五轮，直到连续多个输入都能稳定输出符合预期的结果，才算这个SKILL基本可用。上线之后还要持续观察，收集bad case，定期更新SKILL。
7. 常见问题与排查技巧实录
7.1 输出格式不稳定怎么办
这是最常见的问题，尤其是模板模式的SKILL。表现是模型有时候按模板输出，有时候自由发挥。排查思路是：先检查模板本身是否足够明确，字段约束是否具体到没有歧义。如果模板没问题，再看SKILL里有没有给模型留“自由发挥”的口子，比如“根据情况调整”这种模糊表述。
我的解决方法是：在SKILL开头就强调“必须严格按照以下模板输出，不得增减字段”，然后在模板里每个字段后面都加上格式说明。如果还是不稳定，就在SKILL末尾再加一段“输出前自查清单”，让模型在输出前自己检查一遍格式。实测下来，这个自查清单对提升格式稳定性很有效。
7.2 示例模式输出太死板怎么办
示例模式用不好，模型会变得很死板，输出跟示例几乎一模一样，换个输入就不知道变通。这通常是因为示例太少或者太相似，模型把示例当成了唯一正确答案。解决方法是增加示例的多样性，同时在SKILL里明确写“示例仅用于示范风格和逻辑，请根据实际输入灵活调整内容”。
还有一个技巧是，在示例之后加一段“示例解读”，用文字说明这几个示例共同体现了什么规律、哪些部分是固定的、哪些部分是可变的。这样模型就能区分“规律”和“具体内容”，不会生搬硬套。
7.3 SKILL太长导致模型忽略关键约束
SKILL写得太长，模型可能会忽略中间部分的约束，只关注开头和结尾。这个问题在模板模式里尤其常见，因为模板模式往往需要写很多字段规则。我的应对策略是：把最重要的约束放在SKILL的开头和结尾，中间部分用清晰的小标题分隔，每个小标题下的内容控制在合理长度。
另外，可以用加粗、列表等方式突出关键约束，让模型更容易注意到。如果SKILL实在很长，可以考虑拆成多个子SKILL，用主SKILL来调度。这样每个子SKILL都短小精悍，模型执行起来更稳定。
7.4 常见问题速查表
| 问题表现 | 可能原因 | 排查方向 | 解决建议 |
|---|---|---|---|
| 输出格式忽好忽坏 | 模板约束不明确 | 检查字段规则是否具体 | 细化字段约束，加自查清单 |
| 输出内容千篇一律 | 示例太少或太相似 | 检查示例多样性 | 增加示例，加示例解读 |
| 模型忽略部分约束 | SKILL太长或结构混乱 | 检查约束位置和排版 | 关键约束前置，拆分SKILL |
| 异常输入处理不当 | 缺少异常处理逻辑 | 检查是否有异常出口 | 补充异常处理章节 |
| 输出风格不一致 | 模式选择不当 | 判断任务核心需求 | 切换或组合使用两种模式 |
8. 几个让我印象深刻的踩坑经历
8.1 模板写太细反而坏事
有一次我做一个数据提取的SKILL，为了追求精确，把每个字段的约束写得极其详细，连标点符号都规定了。结果模型变得非常僵硬，遇到稍微不一样的输入就报错，而不是尝试提取。后来我把一些非核心字段的约束放宽，只保留核心字段的严格约束，SKILL的鲁棒性立刻提升了。这件事让我明白：约束是为了稳定，不是为了限制，过度约束反而会降低SKILL的适应能力。
8.2 示例选得不好，模型学歪了
还有一次做风格改写的SKILL，我选了三个示例，都是比较正式的技术文档改写。结果模型学出来的风格偏正式，遇到口语化的输入时，改写出来还是很正式，跟预期不符。后来我补充了两个口语化输入的示例，模型才学会了根据输入风格调整输出风格。示例的覆盖面真的很重要，你给什么例子，模型就学什么，给窄了它就学窄了。
8.3 忘了写异常处理，线上直接翻车
最惨的一次是一个自动回复的SKILL，测试的时候用的都是正常输入，效果很好。上线之后遇到一个格式完全不对的输入，模型没有走异常处理，而是硬着头皮生成了一段莫名其妙的回复，被用户截图投诉了。从那以后，我写任何SKILL都会先写异常处理章节，明确告诉模型“遇到不符合预期的情况应该怎么处理”。这个教训值好几天的返工时间。
9. 关于SKILL设计，我个人的几条经验
写SKILL这件事，说到底是在人和模型之间搭一座桥。桥搭得好不好，不取决于你用了多高级的模式，而取决于你有没有真正站在模型的角度去思考。模型没有常识、没有背景知识、不会揣摩意图，它只有你给它的文字。所以SKILL里的每一句话，都要经得起“一个完全不了解背景的人能不能准确执行”这个检验。
模板模式和示例模式，本质上是在解决两个不同维度的问题：模板解决“结构确定性”，示例解决“意图明确性”。大部分高质量的SKILL，都是两者结合的结果。先用模板把骨架搭稳，再用示例把血肉填活，最后用异常处理把边界兜住。这个组合拳打下来，SKILL的稳定性和灵活性都能兼顾。
最后分享一个小习惯：我每写完一个SKILL，都会放一晚上，第二天再读一遍。隔一段时间再看，往往能发现当时没注意到的歧义和漏洞。SKILL是写给模型看的，但检验它的人是你自己。多读几遍，多跑几个case，比什么都管用。
