1. 先搞明白你手里的skill到底是什么最近好几个群都在聊同一件事同一个skill在A模型上跑得好好的换到B模型就废了。你从Claude切到GPT它不听话从云上API换到本地部署的Qwen它更是直接放飞自我。甚至同一个模型升级一下版本原本调好的技能表现都开始飘。这篇文章就把这个问题彻底拆开讲清楚skill在不同大模型之间迁移时到底发生了什么、该怎么改以及怎么把一份skill写成“跨模型通吃”的样子。先说清楚概念因为现在“skill”这个词被用得太泛了。在Claude这类产品里skill可能是一个放置PROMPT.md的目录结构里面描述了某个技能的执行步骤在Codex、OpenCode这类开源工具里skill被定义成带元信息的Markdown文件在Spring AI里skill可以是一个Java类负责在Agent执行时调用特定工具还有更多场景里skill其实就是一段“长得比较规整”的系统提示词。这些东西形态五花八门但本质上都是一样的把一个任务的执行流程、判断逻辑、提示词技巧、工具调用规则封装成一个可以反复调用的能力单元。所以我们在讨论“同一套skill适配不同大模型”的时候其实讨论的是一个更底层的问题你写下来的那套“操作手册”不同模型能不能读懂、愿不愿意照着做。这和skill本身的载体关系不大核心在于你如何组织信息如何让不同“性格”的模型都愿意执行。我见过很多人把skill和agent混为一谈这其实是两码事。skill是“会做某件事的能力包”agent是“能自主决策干活的执行者”。你可以把skill理解成员工手里的岗位SOP手册agent则是那个会自己判断什么时候翻手册、什么时候请示、什么时候直接动手的新员工。工作流又是另一层它更像是流水线上的传送带规定了步骤先后。一个agent内部可以挂多个skill每个skill之间也可以由工作流串联。搞清楚这层关系之后你才会明白“适配skill”到底是在适配什么你要保证的不是某一个agent的决策逻辑而是那份SOP本身能被不同“文化背景”的模型都能理解。那问题就来了为什么同一份SOP换个人就执行不了答案不在skill身上而在模型的差异上。1.1 大多数情况下skill失效不是写法问题而是模型差异先泼一盆冷水你的skill写法可能没有问题真正出问题的是模型的“阅读理解能力”和“听话程度”不一样。大模型和人类员工最大的区别在于不同模型的训练数据、对齐方式、架构细节都不一样它们对“指令”的解读方式差异极大。你和一个人说“帮我写个方案”他至少知道要分背景、目标、策略但你和两个不同的大模型说同样的话一个可能给你结构化输出另一个可能直接给你一篇散文。这个差异在写skill的时候会被无限放大。因为skill本质上是一段高度压缩的指令集它里面充满了规则、约束、示例、格式要求。如果模型对这些规则的“重视程度”不同执行结果就会有天壤之别。比如你要求“必须返回JSON”有些模型会老老实实输出纯JSON有些模型会好心地加上json代码块还有些模型会直接开始跟你聊天完全无视你的格式要求。这其实就是模型在指令遵循instruction following能力上的差距。所以做适配之前你先要有一个认知不存在一份一模一样的skill能让所有模型都产出相同水平的结果。适配的目标不是“完全一致”而是“在各自能力范围内都达到可用状态”。这个心态不摆正后面怎么做都会很痛苦。1.2 适配的本质把技能写成“模型能读懂的语言”既然问题根源在模型的差异那适配的思路就很清晰了你不能要求所有模型都变成同一个样子但你可以把你的skill写得足够宽容、足够清晰让不同水平的模型都能抓住重点。这就像你给一个资深员工和一个实习生写同一份操作手册你不能指望实习生能看得懂那些只有资深员工才明白的“行话”。你要么写两份要么把手册写得足够细致、足够傻瓜。跨模型适配也是一样你需要在“写一份”和“写多份”之间做权衡。我的实践经验是大部分场景不需要维护多份skill只需要把skill写成“分层结构”让不同能力的模型自动取用不同的层级。后面几个章节我会把这个方法一步步拆开讲。2. 同一套skill在不同模型上翻车的真实原因聊适配之前必须把“为什么会翻车”讲透。只有知道模型之间的差异具体体现在哪些维度你才能对症下药。2.1 参数规模差异直接决定指令遵循天花板参数规模是影响指令遵循能力最直观的因素。拿本地部署来举例7B、14B的模型和70B的模型在理解复杂指令上的差距是肉眼可见的。7B模型能听懂“做这一步然后做那一步”但当你给它一个500字的skill里面塞了五六个约束条件、两三个输出格式要求它就容易顾此失彼。这跟人一样工作记忆容量有限指令太多就记不住最后挑着执行。70B以上的模型或者像Claude、GPT这些闭源大模型它们的工作记忆和理解能力明显更强能同时处理“角色设定步骤约束示例输出格式”这种多重任务。所以在写skill时你先要有个判断这份skill最终会跑在什么量级的模型上如果目标环境是14B左右的本地模型你的skill就得控制篇幅、减少约束、多用示例如果目标环境是闭源旗舰模型那你可以放心写得更精细、更复杂。2.2 不同模型对“格式”和“标签”的敏感度天差地别这是最容易踩坑的地方。我在实测过程中发现不同模型对提示词里的格式标记敏感程度完全不一样。比如XML标签Claude对 、 这类标签非常敏感你用标签包裹规则它能准确识别并执行。但你把这套写法原封不动搬到一个开源模型上它可能完全无视标签只把标签里的文字当成普通叙述。类似的还有Markdown标题、JSON结构、YAML配置等。有些模型看到“## 注意事项”就会把后面的内容当作重点执行有些模型则无感它只关注“必须”、“禁止”这类强指令词。所以你在设计skill时不能只依赖一种格式标记要给模型提供多重线索既用结构标签也用明确的祈使句既给示例也给反例。这样可以确保无论模型更擅长理解哪种形式都能抓到关键信息。还有一个就是语言问题。同一个模型对中文和英文的指令遵循度可能不一样。我试过在同一个开源模型上用中文写“严格按JSON输出”它返回的自然语言解释明显更多改成英文的“Respond only with valid JSON”输出就规矩很多。闭源模型的差异没那么大但也存在。也就是说你的skill不能默认“所有模型都擅长中文指令”必要时候关键字和格式示例可以用中英双语给两道保险。2.3 上下文窗口和token预算skill越厚模型越容易“分心”另一个被忽视的原因是token预算。现在主流的开源模型上下文窗口都不小但“上下文窗口大”不等于“长内容理解得好”。你把一份2000字的skill塞进上下文再给一段任务输入模型的注意力会被摊薄中间的很多约束条件可能被“选择性遗忘”。这和人看长篇说明书是一个道理规则列了20条真正执行的时候能记住的可能只有前5条和后3条中间的规则全被忽略掉了。不同模型对“中段注意力”的保持能力相差很多尤其是那些没有做过长上下文专门优化的模型基本就是“两头醒目、中间模糊”。所以适配的核心原则之一就是做减法。同一份skill跑在强模型上可以保留完整细节跑在弱模型上要学会砍掉非核心规则只保留最关键的限制条件。如果做不到动态裁剪那就干脆把skill设计成“主指令简短、细节放示例”的结构让模型从示例中自动推断规则而不是靠“命令清单”硬记。2.4 模型版本差异和本地部署的参数影响还有一个特别容易被忽略的变量同一个模型的版本更新。同一个开源模型从v1升级到v3指令遵循能力可能翻了几倍但你的skill是照着v1的脾气写的——里面充斥了各种应急措辞和冗余约束。结果就是新模型反而觉得这些约束矛盾表现还不如旧版。另外本地部署时的量化等级和采样参数也会影响skill执行。我实测过同一个模型FP16和4bit量化跑同一份skill在复杂任务上的表现稳定度差距明显。sampling参数里的temperature、top_p也会影响模型对指令的忠实度。temperature越高模型越容易“发挥”也越容易偏离约束。跑skill类的任务我一般建议temperature控制在0.2到0.4之间太高了再好的skill也会被玩坏。3. 从结构上改造skill一套可迁移的架构模板讲清楚翻车原因之后下面重点来了怎么改造成一套尽量在多个模型之间表现稳定的skill。这一步的核心思路我上面提过就是“分层”——把skill拆成强模型需要读的部分和弱模型需要读的部分让不同模型各取所需。3.1 把skill拆成“骨架血肉”先保障结构再填充细节很多人在写skill时习惯把所有的规则、限制、示例一次性平铺出来觉得只要写够了模型就一定能理解。但实际效果是模型面对海量约束时会产生“优先级混乱”。它不知道哪些规则是必须遵守的哪些只是参考。所以跨模型适配的第一个改造动作是把skill拆成两个明显的层级骨架和血肉。骨架部分是任何模型都必须遵循的刚性约束比如输出格式、调用工具的方式、执行步骤的顺序。这部分要尽量简短用最高优先级的语气写放在skill最靠前、最醒目的位置。血肉部分是辅助信息比如背景知识、优化建议、风格参考、详细示例。这部分可以丰富一些但要让模型感知到“这是供参考的不是强制规则”可以用“以下示例供参考”之类的话作引导。为什么这种结构能适配不同模型因为强模型和弱模型对“参考信息”和“强制规则”的区分能力差异巨大。强模型能准确识别哪些是参考、哪些是约束弱模型则常常把参考也当约束导致行为僵化。你把骨架和血肉做物理分离相当于给弱模型划了一条清晰的线这以上是必须做的以下是可选的。这能大幅降低模型的误解概率。3.2 一份可直接套用的跨模型skill模板直接给一份我目前在实际项目中常用的模板结构。这是一份“通用型技能定义”你可以按这个骨架往里面填内容再根据目标模型做调整。这里我用Markdown的自然语言来写因为适用范围最广如果你的工具支持YAML前置元信息可以把下面的字段对应放进去。# 技能名称XXX ## 执行目标 用两到三句话说明这个技能要完成什么任务输出什么结果 ## 刚性规则 1. 必须遵循比如只能使用中文输出 2. 必须避免比如不要编造数据 3. 输出格式要求比如必须返回JSON对象字段包含 result 和 reason ## 执行流程 Step 1分析输入内容提取关键信息 Step 2调用可用工具或基于知识库生成结果 Step 3按输出格式返回结果 ## 示例 ### 示例1 输入... 输出... 示例要包含正确的输出格式模型会模仿这个格式 ## 扩展参考 这段是可选的可以是详细的操作技巧、背景知识、更多示例。弱模型跑不动时可以整个删掉不影响主体逻辑这套模板的逻辑很简单前四部分加示例是任何模型要想跑通这个技能必须看的部分最后一部分是可选的增强模块。对强模型来说扩展参考能帮它输出更高质量的结果对弱模型来说删掉扩展参考可以降低认知负担让它集中精力完成主线任务。3.3 模板里的“变量区”为什么能成为适配的关键上面的模板虽然通用但离“一份通吃所有模型”还差一步。这一步就是“变量区”。所谓变量区就是在skill里预留几个可动态调整的占位符字段比如模型能力档位high / medium / low上下文窗口长度8192 / 32768 / 131072输出语言偏好中文 / English / bilingual约束严格程度strict / moderate / loose在接入不同大模型时你不需要修改skill主体只需要在变量区做配置切换。举个例子同样一份“文章润色”skill在Claude上跑时能力档位设为high约束严格程度设为strict让它输出三个润色版本让我选在本地14B模型上跑时能力档位设为low约束严格程度改为moderate让它只输出一个版本重点保证格式正确、不要跑偏。这个“变量区”听起来简单但它是一个很重要的设计思维转变。很多人写skill时习惯把所有场景都写死结果换一个模型就要改整篇。改成配置化之后skill本身的逻辑不变变的只是几个参数维护成本直接下降好几个量级。4. 提示词层面的适配心法让不同模型都能“看懂”结构改造解决的是“模型能不能找到重点”的问题接下来要解决的是“模型愿不愿意照做”的问题。这部分要聊的是提示词写作技巧也是我觉得整个适配过程里最考验功夫的地方。4.1 few-shot垫样本比反复强调“你必须”有用得多先抛一个我的实测结论对于指令遵循能力弱的模型给两个好示例胜过写十句强约束。原因是弱模型对“抽象指令”的理解能力差但对“具体模式”的模仿能力强。你让它“按照JSON格式输出”它可能不理解什么是JSON但你给它一个输入和对应的JSON输出示例它会照着样子做。所以跨模型适配时示例的质量和数量比规则本身更重要。我建议示例至少准备三个一个常规场景、一个边界场景、一个错误示范。错误示范尤其有用——告诉模型“这个输出是错的不要这样做”比反复强调“不要犯错”有效得多。这个方法对强模型同样有效因为它能消除歧义让强模型也更加明确你的预期。不过要注意示例不能太多否则会占用太多上下文。我一般控制在3到5个并且每个示例尽量短小精悍。如果示例太多太长反而会让模型把它们当作正文干扰它理解当前的任务输入。4.2 把关键指令放在开头和结尾中间放细节我在前面提到过模型的注意力往往是“两头高、中间低”。这个现象在长上下文中尤其明显。所以skill的编辑策略应该遵循一个原则最重要的规则放开头最终的输出要求放结尾中间的段落放过程和细节。具体来说开头部分要让模型明确“你在扮演什么角色”“这个技能的核心目标是什么”“最高优先级的约束是什么”。结尾部分要让模型看到“最后输出时你要遵循什么格式”“检查清单有哪些”。过程中的细节比如背景信息、中间步骤提示放中间。这样无论模型读到哪里都能保持对核心目标的感知。我见过一个很常见的坑有人把“输出格式要求”写在skill的最后一段觉得这是顺序问题无所谓。结果模型在生成输出时已经忘记了最后那段的约束按自己的格式来了。把输出格式要求同时放在“刚性规则”里和“结尾提示”里双重强调观测下来遵循率会明显提高。4.3 条件分支写法一份skill同时兼容强弱模型面对“又要在强模型上出彩又要在弱模型上不翻车”的矛盾一个有效的办法是写条件分支。简单说你的skill里可以包含这样的结构如果你能完整理解以下所有指令请执行详细版本分支A分支。 如果你只理解核心任务请按简化版本执行B分支。 A分支详细版 - 分析输入的结构识别逻辑关系 - 输出三个候选结果并给出推荐 B分支简化版 - 直接根据输入生成结果 - 按标准格式输出这种写法的原理不是让模型真的去“判断自己能看懂什么”而是给它一个容错的出口。强模型看到A和B两个分支会自动选择更详细、更高质量的A分支弱模型对复杂指令理解不足往往会选择它更“有把握”的B分支按简化流程执行。这相当于你提供了一份“进阶版”和一份“保底版”让模型基于自己的能力自动选择。当然这个写法的前提是无论A还是B输出格式必须是一致的。否则弱模型选择了B分支格式又和A分支不同你后续解析的时候就会很头疼。4.4 去掉AI味本质上也是在提高指令遵循率这个话题在热搜里被反复提及但很多人的理解停留在“让文案更像人写的”这个层面。我自己的体会是去AI味对skill的跨模型适配还有一个更实用的意义减少无效信息降低模型的注意力损耗。你看那些AI味很重的内容通常都是大量排比句、客套话、空洞的形容词和总结性套话。这些句子不包含有效指令却会占用模型的注意力权重。你把一份skill里填满“请您充分发挥大模型的优势”“让我们共同努力”这类话模型确实会“感动”但它对真正规则的重点关注度会下降。跨模型适配时尤其是对弱模型副作用会更大。弱模型本身对“哪些是废话、哪些是命令”的辨别能力就弱废话太多会直接稀释指令强度。所以我在写skill时有一个铁律每个句子都必须包含信息量要么是约束要么是流程要么是示例。没有任何信息量的铺垫句一律删掉。5. 工具调用与输出约束的适配如果你的skill涉及工具调用那适配的复杂度会再上一个台阶。因为不同模型对工具调用function calling / tool use的支持程度和实现方式差异很大这比纯提示词层面的适配要硬核得多。5.1 同时兼容function calling与纯文本输出现状是闭源主流模型大多支持标准的function calling但开源模型的工具调用能力参差不齐。有些模型经过工具调用微调表现很好有些模型则只是“看起来支持”实际执行时经常输出格式错误。更麻烦的是不同平台定义工具的字段名不一样比如有的用parameters有的用input_schema有的要求严格JSON Schema有的只接受宽松的JSON。所以一个稳妥的适配策略是skill内部定义好自己的工具调用抽象层不直接依赖模型原生的function calling格式。具体做法是在skill的提示词里约定一套统一的工具调用语法比如当你需要查询天气时输出以下格式 [TOOL_CALL] weather_tool {city: 北京} [/TOOL_CALL]然后让skill在执行时先由程序层解析这个格式再映射到具体模型的原生工具调用能力。这样即使底层模型不支持function calling也能通过纯文本输出的方式完成工具调用。这是一个很笨但很可靠的方法尤其是在本地部署多模型的环境下能省掉大量适配工作。5.2 输出格式的鲁棒性设计让解析器更抗造不管你用不用工具输出格式的鲁棒性都是必须考虑的。不同模型在“格式遵循”上的表现参差不齐同样的“输出JSON”要求有的模型会加markdown代码块有的会带注释有的会在JSON前后加多余的自然语言。如果你解析器写得不够宽容一个模型跑通、另一个模型跑崩的情况会反复出现。解决思路分两头。一头是解析器层面的兜底写一个专门处理模型输出的解析函数自动去除markdown代码块标记、提取JSON片段、忽略前后缀文案。另一头是prompt层面的引导在skill里明确“不要输出任何解释性文字直接输出JSON”并在示例里给出纯JSON的展示。两头配合基本能覆盖90%以上的格式偏差。这里特别说一下错误示范的示例在这里特别有用你可以在skill里加一句“不正确的输出json..., 正确输出{...}”模型对这种对比示例的敏感度很高能显著减少格式翻车。5.3 工具定义字段的兼容写法如果你的skill是要在多个支持工具调用的模型API之间迁移那在定义工具时也要做一些兼容策略。我的习惯是先写一份中立的工具定义用最通用的字段name、description、parameters。然后在适配层做字段映射——接入OpenAI格式时就生成OpenAI兼容的schema接入双运行时的本地模型时就生成对应平台的schema。这里有一个很容易被忽略的细节工具描述description的写法对调用成功率影响极大。不同模型对“什么时候该调用某个工具”的理解能力不一样描述写得模糊弱模型就会频繁错调工具。所以工具描述要写成“如果用户需求包含X调用工具Y”的条件句式同时附上一个正例和一个反例。这在很大程度上能弥补弱模型在意图判断上的不足。6. 多模型环境下的验证与迭代适配工作真正难的地方不在写而在验证。你改了skill不知道改完对哪个模型有效、对哪个模型有害只能靠一遍遍试错。所以建立一套快速的验证流程很有必要。6.1 本地部署多模型的skill测试矩阵我现在做跨模型适配时会先搭一个“测试矩阵”。所谓矩阵就是把目标模型、测试样本、关键指标列成一个表格每改一次skill就全量跑一遍。模型参数量量化等级上下文窗口测试结果备注Qwen2.5-7B7BQ432K格式基本正确逻辑有小概率偏差需要保留示例Qwen2.5-14B14BQ432K格式正确逻辑稳定推荐默认DeepSeek-R1-Distill-Qwen-14B14BQ832K推理增强但容易过度输出需要约束输出长度GLM-4-9B9BQ432K指令遵循一般易忽略中段规则需要精简skillClaude / GPT API超大无损128K忠实度高可保留完整版本适合完整skill这个表格的目的是快速暴露问题而不是追求全量测试。每次改完skill你只需要挑两三个有代表性的模型跑一遍确认改动方向是否正确再决定要不要全量回归。6.2 用最小样本集做回归测试跑全量测试很贵所以我会准备一个“最小样本集”。这个样本集通常是10到15条能够覆盖核心场景的输入包括正常输入、边界输入、无意义输入、恶意输入。每次改完skill先跑这个最小集把明显的问题过滤掉再决定是否扩大测试范围。这里有一个要点样本输出需要人工判断不能只看是否“跑通”。因为模型可能格式化正确但语义完全跑偏。我一般会关注三个维度格式是否符合要求、逻辑是否顺畅、约束是否全部遵守。三个维度都达标才算这次修改通过。6.3 三个最容易踩的坑和对应解法第一过度优化某个模型导致其他模型退化。这是最常见的坑。你在A模型上调了一个小细节A模型变好了B模型却因为新增的指令而变笨。解法是每次改动都回测所有核心模型避免“单模型优化”。第二只测了几条样本就发布。大模型输出稳定度其实有限好的skill也不是百分百稳定。你至少跑五到十次相同测试确认不是运气因素。第三忽略并发和延迟的额外开销。有些skill为了适配弱模型会写很多示例和分支这类skill在强模型上跑没问题但在高并发场景下会浪费大量token延迟和成本都会上升。解法是给线上环境单独维护一份裁剪后的精简版skill和完整版分开管理。7. 一次完整的适配实战记录把“深度润色”skill从Claude移植到两套本地模型前面讲了不少方法论这一节干脆用一次实际的适配过程来收尾。就拿我最近调的一个“深度润色”skill来说。这个skill最初的形态是给Claude用的功能是对输入的中文段落做全方位润色包括语感优化、冗余删减、节奏调整、用词升级。在Claude上表现一直很稳定输出质量也高。后来因为数据隐私的原因需要把同样的功能移植到本地部署的模型上目标是至少达到“可用”水平。第一轮测试我直接把Claude版skill原封不动扔到一台部署了Qwen2.5-14B的服务器上跑。结果很明显格式能遵循但润色力度非常弱改动寥寥而且部分输出带有比较重的“AI腔”。为什么因为这份skill里大量使用了“确保”“注意”“务必”这类模糊指令Claude能理解这些词的权重但14B模型对这类词的响应不明显。它更依赖具体的步骤和示例而不是抽象的要求。第二轮我按“骨架血肉”的模板把skill重写了一遍。核心改动有三个一是把原来的10条约束压缩成4条“刚性规则”其余约束全部移到“扩展参考”里二是在示例部分从1个增加到3个覆盖了“语感一般”“重复冗余”“用词平淡”三种输入情况三是在结尾加了输出格式检查清单让模型在返回结果前自查一遍。改完之后Qwen2.5-14B的效果明显提升润色力度和格式稳定性都基本达标但偶尔还会出现“过度解释”的情况比如在润色结果后面加一段说明文字。第三轮我在skill里加了一条“直接输出润色后的段落不要输出任何解释性文字”然后在示例的“正确输出”地方刻意放了一段纯润色结果、没有附加说明。同时我在解析层做了兜底如果检测到输出末尾有多余的说明性文字自动截断。这样即便模型偶尔“忍不住”解释最终拿到的结果也是干净的。同一份改完的skill我又在一台部署了GLM-4-9B的设备上测了一下。9B模型的指令遵循能力比14B弱一截但因为它对“示例模仿”的响应不错所以3个示例基本保证了输出格式的正确性。唯一的问题是它对“润色原则”的理解比较表层有时候只是替换了几个词没有做真正的结构调整。我把“扩展参考”部分的描述降低了一个优先级确保核心信息前置效果有所改善但说实话这种小模型的能力上限就摆在那里你再怎么调skill也很难让它在语义重写层面超过14B模型。7.1 案例复盘我从这次适配里沉淀的三个原则这次实战跑下来我把经验沉淀成了三个原则写在这里供参考。第一个原则是先按模型能力分档再决定skill怎么改。如果你的目标模型是70B以上或者闭源旗舰skill可以保留完整细节和复杂约束如果你的目标模型是7B到14B强制约束必须压缩到五条以内核心信息必须前置示例必须充足。不要在一开始就指望一份skill打天下先确认目标模型处于哪个能力档位再决定往哪个方向调整。第二个原则是示例的作用永远比规则大。这条在开源模型上体现得极其明显。你有10条规则不一定能限制住模型但你有3个正例和1个反例模型大概率会照着做。所以写skill时与其花时间堆砌约束条件不如认真打磨几个高质量示例。第三个原则是解析层的兜底能解决大量“prompt解决不了”的问题。大模型的输出天然带有随机性再好的skill也不可避免会出现格式偏差。在代码层面写一个宽容的解析器自动清理markdown标记、提取核心内容、截断多余说明能让你的skill在不同模型间迁移时省掉大量“死磕prompt”的时间。我现在的工作习惯是凡是写出来要跨模型用的skill交付前必定跑一遍多模型验证。至少选一个闭源API模型和一个本地部署的开源模型各自跑三到五次同样的测试确认不是运气好才过的。这个过程第一次做会比较花时间但跑通之后后续的模型迁移、版本升级都变得很快。希望这份经验对你也有用。
跨模型技能迁移实战：让同一套Skill在任意大模型上稳定运行
1. 先搞明白你手里的skill到底是什么最近好几个群都在聊同一件事同一个skill在A模型上跑得好好的换到B模型就废了。你从Claude切到GPT它不听话从云上API换到本地部署的Qwen它更是直接放飞自我。甚至同一个模型升级一下版本原本调好的技能表现都开始飘。这篇文章就把这个问题彻底拆开讲清楚skill在不同大模型之间迁移时到底发生了什么、该怎么改以及怎么把一份skill写成“跨模型通吃”的样子。先说清楚概念因为现在“skill”这个词被用得太泛了。在Claude这类产品里skill可能是一个放置PROMPT.md的目录结构里面描述了某个技能的执行步骤在Codex、OpenCode这类开源工具里skill被定义成带元信息的Markdown文件在Spring AI里skill可以是一个Java类负责在Agent执行时调用特定工具还有更多场景里skill其实就是一段“长得比较规整”的系统提示词。这些东西形态五花八门但本质上都是一样的把一个任务的执行流程、判断逻辑、提示词技巧、工具调用规则封装成一个可以反复调用的能力单元。所以我们在讨论“同一套skill适配不同大模型”的时候其实讨论的是一个更底层的问题你写下来的那套“操作手册”不同模型能不能读懂、愿不愿意照着做。这和skill本身的载体关系不大核心在于你如何组织信息如何让不同“性格”的模型都愿意执行。我见过很多人把skill和agent混为一谈这其实是两码事。skill是“会做某件事的能力包”agent是“能自主决策干活的执行者”。你可以把skill理解成员工手里的岗位SOP手册agent则是那个会自己判断什么时候翻手册、什么时候请示、什么时候直接动手的新员工。工作流又是另一层它更像是流水线上的传送带规定了步骤先后。一个agent内部可以挂多个skill每个skill之间也可以由工作流串联。搞清楚这层关系之后你才会明白“适配skill”到底是在适配什么你要保证的不是某一个agent的决策逻辑而是那份SOP本身能被不同“文化背景”的模型都能理解。那问题就来了为什么同一份SOP换个人就执行不了答案不在skill身上而在模型的差异上。1.1 大多数情况下skill失效不是写法问题而是模型差异先泼一盆冷水你的skill写法可能没有问题真正出问题的是模型的“阅读理解能力”和“听话程度”不一样。大模型和人类员工最大的区别在于不同模型的训练数据、对齐方式、架构细节都不一样它们对“指令”的解读方式差异极大。你和一个人说“帮我写个方案”他至少知道要分背景、目标、策略但你和两个不同的大模型说同样的话一个可能给你结构化输出另一个可能直接给你一篇散文。这个差异在写skill的时候会被无限放大。因为skill本质上是一段高度压缩的指令集它里面充满了规则、约束、示例、格式要求。如果模型对这些规则的“重视程度”不同执行结果就会有天壤之别。比如你要求“必须返回JSON”有些模型会老老实实输出纯JSON有些模型会好心地加上json代码块还有些模型会直接开始跟你聊天完全无视你的格式要求。这其实就是模型在指令遵循instruction following能力上的差距。所以做适配之前你先要有一个认知不存在一份一模一样的skill能让所有模型都产出相同水平的结果。适配的目标不是“完全一致”而是“在各自能力范围内都达到可用状态”。这个心态不摆正后面怎么做都会很痛苦。1.2 适配的本质把技能写成“模型能读懂的语言”既然问题根源在模型的差异那适配的思路就很清晰了你不能要求所有模型都变成同一个样子但你可以把你的skill写得足够宽容、足够清晰让不同水平的模型都能抓住重点。这就像你给一个资深员工和一个实习生写同一份操作手册你不能指望实习生能看得懂那些只有资深员工才明白的“行话”。你要么写两份要么把手册写得足够细致、足够傻瓜。跨模型适配也是一样你需要在“写一份”和“写多份”之间做权衡。我的实践经验是大部分场景不需要维护多份skill只需要把skill写成“分层结构”让不同能力的模型自动取用不同的层级。后面几个章节我会把这个方法一步步拆开讲。2. 同一套skill在不同模型上翻车的真实原因聊适配之前必须把“为什么会翻车”讲透。只有知道模型之间的差异具体体现在哪些维度你才能对症下药。2.1 参数规模差异直接决定指令遵循天花板参数规模是影响指令遵循能力最直观的因素。拿本地部署来举例7B、14B的模型和70B的模型在理解复杂指令上的差距是肉眼可见的。7B模型能听懂“做这一步然后做那一步”但当你给它一个500字的skill里面塞了五六个约束条件、两三个输出格式要求它就容易顾此失彼。这跟人一样工作记忆容量有限指令太多就记不住最后挑着执行。70B以上的模型或者像Claude、GPT这些闭源大模型它们的工作记忆和理解能力明显更强能同时处理“角色设定步骤约束示例输出格式”这种多重任务。所以在写skill时你先要有个判断这份skill最终会跑在什么量级的模型上如果目标环境是14B左右的本地模型你的skill就得控制篇幅、减少约束、多用示例如果目标环境是闭源旗舰模型那你可以放心写得更精细、更复杂。2.2 不同模型对“格式”和“标签”的敏感度天差地别这是最容易踩坑的地方。我在实测过程中发现不同模型对提示词里的格式标记敏感程度完全不一样。比如XML标签Claude对 、 这类标签非常敏感你用标签包裹规则它能准确识别并执行。但你把这套写法原封不动搬到一个开源模型上它可能完全无视标签只把标签里的文字当成普通叙述。类似的还有Markdown标题、JSON结构、YAML配置等。有些模型看到“## 注意事项”就会把后面的内容当作重点执行有些模型则无感它只关注“必须”、“禁止”这类强指令词。所以你在设计skill时不能只依赖一种格式标记要给模型提供多重线索既用结构标签也用明确的祈使句既给示例也给反例。这样可以确保无论模型更擅长理解哪种形式都能抓到关键信息。还有一个就是语言问题。同一个模型对中文和英文的指令遵循度可能不一样。我试过在同一个开源模型上用中文写“严格按JSON输出”它返回的自然语言解释明显更多改成英文的“Respond only with valid JSON”输出就规矩很多。闭源模型的差异没那么大但也存在。也就是说你的skill不能默认“所有模型都擅长中文指令”必要时候关键字和格式示例可以用中英双语给两道保险。2.3 上下文窗口和token预算skill越厚模型越容易“分心”另一个被忽视的原因是token预算。现在主流的开源模型上下文窗口都不小但“上下文窗口大”不等于“长内容理解得好”。你把一份2000字的skill塞进上下文再给一段任务输入模型的注意力会被摊薄中间的很多约束条件可能被“选择性遗忘”。这和人看长篇说明书是一个道理规则列了20条真正执行的时候能记住的可能只有前5条和后3条中间的规则全被忽略掉了。不同模型对“中段注意力”的保持能力相差很多尤其是那些没有做过长上下文专门优化的模型基本就是“两头醒目、中间模糊”。所以适配的核心原则之一就是做减法。同一份skill跑在强模型上可以保留完整细节跑在弱模型上要学会砍掉非核心规则只保留最关键的限制条件。如果做不到动态裁剪那就干脆把skill设计成“主指令简短、细节放示例”的结构让模型从示例中自动推断规则而不是靠“命令清单”硬记。2.4 模型版本差异和本地部署的参数影响还有一个特别容易被忽略的变量同一个模型的版本更新。同一个开源模型从v1升级到v3指令遵循能力可能翻了几倍但你的skill是照着v1的脾气写的——里面充斥了各种应急措辞和冗余约束。结果就是新模型反而觉得这些约束矛盾表现还不如旧版。另外本地部署时的量化等级和采样参数也会影响skill执行。我实测过同一个模型FP16和4bit量化跑同一份skill在复杂任务上的表现稳定度差距明显。sampling参数里的temperature、top_p也会影响模型对指令的忠实度。temperature越高模型越容易“发挥”也越容易偏离约束。跑skill类的任务我一般建议temperature控制在0.2到0.4之间太高了再好的skill也会被玩坏。3. 从结构上改造skill一套可迁移的架构模板讲清楚翻车原因之后下面重点来了怎么改造成一套尽量在多个模型之间表现稳定的skill。这一步的核心思路我上面提过就是“分层”——把skill拆成强模型需要读的部分和弱模型需要读的部分让不同模型各取所需。3.1 把skill拆成“骨架血肉”先保障结构再填充细节很多人在写skill时习惯把所有的规则、限制、示例一次性平铺出来觉得只要写够了模型就一定能理解。但实际效果是模型面对海量约束时会产生“优先级混乱”。它不知道哪些规则是必须遵守的哪些只是参考。所以跨模型适配的第一个改造动作是把skill拆成两个明显的层级骨架和血肉。骨架部分是任何模型都必须遵循的刚性约束比如输出格式、调用工具的方式、执行步骤的顺序。这部分要尽量简短用最高优先级的语气写放在skill最靠前、最醒目的位置。血肉部分是辅助信息比如背景知识、优化建议、风格参考、详细示例。这部分可以丰富一些但要让模型感知到“这是供参考的不是强制规则”可以用“以下示例供参考”之类的话作引导。为什么这种结构能适配不同模型因为强模型和弱模型对“参考信息”和“强制规则”的区分能力差异巨大。强模型能准确识别哪些是参考、哪些是约束弱模型则常常把参考也当约束导致行为僵化。你把骨架和血肉做物理分离相当于给弱模型划了一条清晰的线这以上是必须做的以下是可选的。这能大幅降低模型的误解概率。3.2 一份可直接套用的跨模型skill模板直接给一份我目前在实际项目中常用的模板结构。这是一份“通用型技能定义”你可以按这个骨架往里面填内容再根据目标模型做调整。这里我用Markdown的自然语言来写因为适用范围最广如果你的工具支持YAML前置元信息可以把下面的字段对应放进去。# 技能名称XXX ## 执行目标 用两到三句话说明这个技能要完成什么任务输出什么结果 ## 刚性规则 1. 必须遵循比如只能使用中文输出 2. 必须避免比如不要编造数据 3. 输出格式要求比如必须返回JSON对象字段包含 result 和 reason ## 执行流程 Step 1分析输入内容提取关键信息 Step 2调用可用工具或基于知识库生成结果 Step 3按输出格式返回结果 ## 示例 ### 示例1 输入... 输出... 示例要包含正确的输出格式模型会模仿这个格式 ## 扩展参考 这段是可选的可以是详细的操作技巧、背景知识、更多示例。弱模型跑不动时可以整个删掉不影响主体逻辑这套模板的逻辑很简单前四部分加示例是任何模型要想跑通这个技能必须看的部分最后一部分是可选的增强模块。对强模型来说扩展参考能帮它输出更高质量的结果对弱模型来说删掉扩展参考可以降低认知负担让它集中精力完成主线任务。3.3 模板里的“变量区”为什么能成为适配的关键上面的模板虽然通用但离“一份通吃所有模型”还差一步。这一步就是“变量区”。所谓变量区就是在skill里预留几个可动态调整的占位符字段比如模型能力档位high / medium / low上下文窗口长度8192 / 32768 / 131072输出语言偏好中文 / English / bilingual约束严格程度strict / moderate / loose在接入不同大模型时你不需要修改skill主体只需要在变量区做配置切换。举个例子同样一份“文章润色”skill在Claude上跑时能力档位设为high约束严格程度设为strict让它输出三个润色版本让我选在本地14B模型上跑时能力档位设为low约束严格程度改为moderate让它只输出一个版本重点保证格式正确、不要跑偏。这个“变量区”听起来简单但它是一个很重要的设计思维转变。很多人写skill时习惯把所有场景都写死结果换一个模型就要改整篇。改成配置化之后skill本身的逻辑不变变的只是几个参数维护成本直接下降好几个量级。4. 提示词层面的适配心法让不同模型都能“看懂”结构改造解决的是“模型能不能找到重点”的问题接下来要解决的是“模型愿不愿意照做”的问题。这部分要聊的是提示词写作技巧也是我觉得整个适配过程里最考验功夫的地方。4.1 few-shot垫样本比反复强调“你必须”有用得多先抛一个我的实测结论对于指令遵循能力弱的模型给两个好示例胜过写十句强约束。原因是弱模型对“抽象指令”的理解能力差但对“具体模式”的模仿能力强。你让它“按照JSON格式输出”它可能不理解什么是JSON但你给它一个输入和对应的JSON输出示例它会照着样子做。所以跨模型适配时示例的质量和数量比规则本身更重要。我建议示例至少准备三个一个常规场景、一个边界场景、一个错误示范。错误示范尤其有用——告诉模型“这个输出是错的不要这样做”比反复强调“不要犯错”有效得多。这个方法对强模型同样有效因为它能消除歧义让强模型也更加明确你的预期。不过要注意示例不能太多否则会占用太多上下文。我一般控制在3到5个并且每个示例尽量短小精悍。如果示例太多太长反而会让模型把它们当作正文干扰它理解当前的任务输入。4.2 把关键指令放在开头和结尾中间放细节我在前面提到过模型的注意力往往是“两头高、中间低”。这个现象在长上下文中尤其明显。所以skill的编辑策略应该遵循一个原则最重要的规则放开头最终的输出要求放结尾中间的段落放过程和细节。具体来说开头部分要让模型明确“你在扮演什么角色”“这个技能的核心目标是什么”“最高优先级的约束是什么”。结尾部分要让模型看到“最后输出时你要遵循什么格式”“检查清单有哪些”。过程中的细节比如背景信息、中间步骤提示放中间。这样无论模型读到哪里都能保持对核心目标的感知。我见过一个很常见的坑有人把“输出格式要求”写在skill的最后一段觉得这是顺序问题无所谓。结果模型在生成输出时已经忘记了最后那段的约束按自己的格式来了。把输出格式要求同时放在“刚性规则”里和“结尾提示”里双重强调观测下来遵循率会明显提高。4.3 条件分支写法一份skill同时兼容强弱模型面对“又要在强模型上出彩又要在弱模型上不翻车”的矛盾一个有效的办法是写条件分支。简单说你的skill里可以包含这样的结构如果你能完整理解以下所有指令请执行详细版本分支A分支。 如果你只理解核心任务请按简化版本执行B分支。 A分支详细版 - 分析输入的结构识别逻辑关系 - 输出三个候选结果并给出推荐 B分支简化版 - 直接根据输入生成结果 - 按标准格式输出这种写法的原理不是让模型真的去“判断自己能看懂什么”而是给它一个容错的出口。强模型看到A和B两个分支会自动选择更详细、更高质量的A分支弱模型对复杂指令理解不足往往会选择它更“有把握”的B分支按简化流程执行。这相当于你提供了一份“进阶版”和一份“保底版”让模型基于自己的能力自动选择。当然这个写法的前提是无论A还是B输出格式必须是一致的。否则弱模型选择了B分支格式又和A分支不同你后续解析的时候就会很头疼。4.4 去掉AI味本质上也是在提高指令遵循率这个话题在热搜里被反复提及但很多人的理解停留在“让文案更像人写的”这个层面。我自己的体会是去AI味对skill的跨模型适配还有一个更实用的意义减少无效信息降低模型的注意力损耗。你看那些AI味很重的内容通常都是大量排比句、客套话、空洞的形容词和总结性套话。这些句子不包含有效指令却会占用模型的注意力权重。你把一份skill里填满“请您充分发挥大模型的优势”“让我们共同努力”这类话模型确实会“感动”但它对真正规则的重点关注度会下降。跨模型适配时尤其是对弱模型副作用会更大。弱模型本身对“哪些是废话、哪些是命令”的辨别能力就弱废话太多会直接稀释指令强度。所以我在写skill时有一个铁律每个句子都必须包含信息量要么是约束要么是流程要么是示例。没有任何信息量的铺垫句一律删掉。5. 工具调用与输出约束的适配如果你的skill涉及工具调用那适配的复杂度会再上一个台阶。因为不同模型对工具调用function calling / tool use的支持程度和实现方式差异很大这比纯提示词层面的适配要硬核得多。5.1 同时兼容function calling与纯文本输出现状是闭源主流模型大多支持标准的function calling但开源模型的工具调用能力参差不齐。有些模型经过工具调用微调表现很好有些模型则只是“看起来支持”实际执行时经常输出格式错误。更麻烦的是不同平台定义工具的字段名不一样比如有的用parameters有的用input_schema有的要求严格JSON Schema有的只接受宽松的JSON。所以一个稳妥的适配策略是skill内部定义好自己的工具调用抽象层不直接依赖模型原生的function calling格式。具体做法是在skill的提示词里约定一套统一的工具调用语法比如当你需要查询天气时输出以下格式 [TOOL_CALL] weather_tool {city: 北京} [/TOOL_CALL]然后让skill在执行时先由程序层解析这个格式再映射到具体模型的原生工具调用能力。这样即使底层模型不支持function calling也能通过纯文本输出的方式完成工具调用。这是一个很笨但很可靠的方法尤其是在本地部署多模型的环境下能省掉大量适配工作。5.2 输出格式的鲁棒性设计让解析器更抗造不管你用不用工具输出格式的鲁棒性都是必须考虑的。不同模型在“格式遵循”上的表现参差不齐同样的“输出JSON”要求有的模型会加markdown代码块有的会带注释有的会在JSON前后加多余的自然语言。如果你解析器写得不够宽容一个模型跑通、另一个模型跑崩的情况会反复出现。解决思路分两头。一头是解析器层面的兜底写一个专门处理模型输出的解析函数自动去除markdown代码块标记、提取JSON片段、忽略前后缀文案。另一头是prompt层面的引导在skill里明确“不要输出任何解释性文字直接输出JSON”并在示例里给出纯JSON的展示。两头配合基本能覆盖90%以上的格式偏差。这里特别说一下错误示范的示例在这里特别有用你可以在skill里加一句“不正确的输出json..., 正确输出{...}”模型对这种对比示例的敏感度很高能显著减少格式翻车。5.3 工具定义字段的兼容写法如果你的skill是要在多个支持工具调用的模型API之间迁移那在定义工具时也要做一些兼容策略。我的习惯是先写一份中立的工具定义用最通用的字段name、description、parameters。然后在适配层做字段映射——接入OpenAI格式时就生成OpenAI兼容的schema接入双运行时的本地模型时就生成对应平台的schema。这里有一个很容易被忽略的细节工具描述description的写法对调用成功率影响极大。不同模型对“什么时候该调用某个工具”的理解能力不一样描述写得模糊弱模型就会频繁错调工具。所以工具描述要写成“如果用户需求包含X调用工具Y”的条件句式同时附上一个正例和一个反例。这在很大程度上能弥补弱模型在意图判断上的不足。6. 多模型环境下的验证与迭代适配工作真正难的地方不在写而在验证。你改了skill不知道改完对哪个模型有效、对哪个模型有害只能靠一遍遍试错。所以建立一套快速的验证流程很有必要。6.1 本地部署多模型的skill测试矩阵我现在做跨模型适配时会先搭一个“测试矩阵”。所谓矩阵就是把目标模型、测试样本、关键指标列成一个表格每改一次skill就全量跑一遍。模型参数量量化等级上下文窗口测试结果备注Qwen2.5-7B7BQ432K格式基本正确逻辑有小概率偏差需要保留示例Qwen2.5-14B14BQ432K格式正确逻辑稳定推荐默认DeepSeek-R1-Distill-Qwen-14B14BQ832K推理增强但容易过度输出需要约束输出长度GLM-4-9B9BQ432K指令遵循一般易忽略中段规则需要精简skillClaude / GPT API超大无损128K忠实度高可保留完整版本适合完整skill这个表格的目的是快速暴露问题而不是追求全量测试。每次改完skill你只需要挑两三个有代表性的模型跑一遍确认改动方向是否正确再决定要不要全量回归。6.2 用最小样本集做回归测试跑全量测试很贵所以我会准备一个“最小样本集”。这个样本集通常是10到15条能够覆盖核心场景的输入包括正常输入、边界输入、无意义输入、恶意输入。每次改完skill先跑这个最小集把明显的问题过滤掉再决定是否扩大测试范围。这里有一个要点样本输出需要人工判断不能只看是否“跑通”。因为模型可能格式化正确但语义完全跑偏。我一般会关注三个维度格式是否符合要求、逻辑是否顺畅、约束是否全部遵守。三个维度都达标才算这次修改通过。6.3 三个最容易踩的坑和对应解法第一过度优化某个模型导致其他模型退化。这是最常见的坑。你在A模型上调了一个小细节A模型变好了B模型却因为新增的指令而变笨。解法是每次改动都回测所有核心模型避免“单模型优化”。第二只测了几条样本就发布。大模型输出稳定度其实有限好的skill也不是百分百稳定。你至少跑五到十次相同测试确认不是运气因素。第三忽略并发和延迟的额外开销。有些skill为了适配弱模型会写很多示例和分支这类skill在强模型上跑没问题但在高并发场景下会浪费大量token延迟和成本都会上升。解法是给线上环境单独维护一份裁剪后的精简版skill和完整版分开管理。7. 一次完整的适配实战记录把“深度润色”skill从Claude移植到两套本地模型前面讲了不少方法论这一节干脆用一次实际的适配过程来收尾。就拿我最近调的一个“深度润色”skill来说。这个skill最初的形态是给Claude用的功能是对输入的中文段落做全方位润色包括语感优化、冗余删减、节奏调整、用词升级。在Claude上表现一直很稳定输出质量也高。后来因为数据隐私的原因需要把同样的功能移植到本地部署的模型上目标是至少达到“可用”水平。第一轮测试我直接把Claude版skill原封不动扔到一台部署了Qwen2.5-14B的服务器上跑。结果很明显格式能遵循但润色力度非常弱改动寥寥而且部分输出带有比较重的“AI腔”。为什么因为这份skill里大量使用了“确保”“注意”“务必”这类模糊指令Claude能理解这些词的权重但14B模型对这类词的响应不明显。它更依赖具体的步骤和示例而不是抽象的要求。第二轮我按“骨架血肉”的模板把skill重写了一遍。核心改动有三个一是把原来的10条约束压缩成4条“刚性规则”其余约束全部移到“扩展参考”里二是在示例部分从1个增加到3个覆盖了“语感一般”“重复冗余”“用词平淡”三种输入情况三是在结尾加了输出格式检查清单让模型在返回结果前自查一遍。改完之后Qwen2.5-14B的效果明显提升润色力度和格式稳定性都基本达标但偶尔还会出现“过度解释”的情况比如在润色结果后面加一段说明文字。第三轮我在skill里加了一条“直接输出润色后的段落不要输出任何解释性文字”然后在示例的“正确输出”地方刻意放了一段纯润色结果、没有附加说明。同时我在解析层做了兜底如果检测到输出末尾有多余的说明性文字自动截断。这样即便模型偶尔“忍不住”解释最终拿到的结果也是干净的。同一份改完的skill我又在一台部署了GLM-4-9B的设备上测了一下。9B模型的指令遵循能力比14B弱一截但因为它对“示例模仿”的响应不错所以3个示例基本保证了输出格式的正确性。唯一的问题是它对“润色原则”的理解比较表层有时候只是替换了几个词没有做真正的结构调整。我把“扩展参考”部分的描述降低了一个优先级确保核心信息前置效果有所改善但说实话这种小模型的能力上限就摆在那里你再怎么调skill也很难让它在语义重写层面超过14B模型。7.1 案例复盘我从这次适配里沉淀的三个原则这次实战跑下来我把经验沉淀成了三个原则写在这里供参考。第一个原则是先按模型能力分档再决定skill怎么改。如果你的目标模型是70B以上或者闭源旗舰skill可以保留完整细节和复杂约束如果你的目标模型是7B到14B强制约束必须压缩到五条以内核心信息必须前置示例必须充足。不要在一开始就指望一份skill打天下先确认目标模型处于哪个能力档位再决定往哪个方向调整。第二个原则是示例的作用永远比规则大。这条在开源模型上体现得极其明显。你有10条规则不一定能限制住模型但你有3个正例和1个反例模型大概率会照着做。所以写skill时与其花时间堆砌约束条件不如认真打磨几个高质量示例。第三个原则是解析层的兜底能解决大量“prompt解决不了”的问题。大模型的输出天然带有随机性再好的skill也不可避免会出现格式偏差。在代码层面写一个宽容的解析器自动清理markdown标记、提取核心内容、截断多余说明能让你的skill在不同模型间迁移时省掉大量“死磕prompt”的时间。我现在的工作习惯是凡是写出来要跨模型用的skill交付前必定跑一遍多模型验证。至少选一个闭源API模型和一个本地部署的开源模型各自跑三到五次同样的测试确认不是运气好才过的。这个过程第一次做会比较花时间但跑通之后后续的模型迁移、版本升级都变得很快。希望这份经验对你也有用。