大话 Skill 设计：能力如何驱动产出

JanYork_简昀

发布于 2026-04-10 17:31:24

1300

下午好，

上一篇我们聊了如何进行良好的提示词设计。

从为什么输出总是不稳定，到怎么把一个模糊的意图变成模型可以稳定执行的指令。

如果你已经能写出结构清晰、约束充分、可以复用的提示词，那你已经越过了大多数人停留的地方。

但我想在今天提出一个新问题。

当你有了十条、五十条、一百条提示词，然后呢？

它们分散在不同的文档里，不同的工具里，不同人的脑子里。每次用都要重新找，找到了还要判断是不是过时了，想复用却发现换个场景就失效。

你建立了能力，但这些能力没有被组织起来。这就是今天要谈的核心问题。

今天要讲的是，Skill。

Skill 不是更长的提示词，不是更复杂的指令，而是一个不同层次的概念。

它把能力本身作为设计对象，而不是把单次任务作为设计对象。

这个转变，是从"用好 AI"到"构建 AI 能力体系"的真正分水岭。

今天的内容面向两类读者。

如果你是产品经理或运营，这里会帮你理解如何把个人的 AI 使用习惯，转化成团队可以共享和复用的能力资产。

如果你是技术负责人或产品负责人，这里会帮你建立一套评估和设计 Skill 的系统框架。

两类人可以从不同的深度来听，但核心判断只有一个：Skill 是可复用的能力单元，不是更长的提示词。

理解这个差异，是今天所有内容的起点。

先从一个你一定遇到过的困境说起。

你花了两个小时，把一条用于竞品分析的提示词调到了满意的状态。输出结构清晰，约束充分，格式可以直接用。

你把它存在备忘录里，或者发进了某个工作群。

三周后，同事做同类任务，你把这条提示词发给他，他用了，说效果不对，因为他分析的产品类型不同，目标受众不同，需要调整的地方有五六处。

但他不知道哪里该改、为什么要改、改了之后怎么判断是不是更好。

这条提示词在你手里是资产，到了别人手里是负担。这不是提示词写得不够好的问题，这是提示词作为一种形式，天然的局限。

要理解 Skill 是什么，需要先把三个容易混淆的概念区分清楚。

不是为了玩概念游戏，而是因为这三个层次代表了三种根本不同的设计思路，混在一起会导致每个层次的问题都解决不好。

Prompt 是单次任务的指令。

它描述的是"这一次，我要模型做什么"。它的生命周期是一次对话，它的复用方式是复制粘贴，它的维护单位是个人。

Prompt 是 Skill 的原材料，但 Prompt 本身不是 Skill。就像一段好的代码片段不是一个函数，更不是一个模块，它可以被提炼成更高层次的结构，但在被提炼之前，它只是一段有效的代码。

Tool 是模型可以调用的外部能力。

搜索引擎、计算器、数据库查询、文件读取，Tool 解决的是模型能力边界的问题，让模型可以访问它原本无法访问的信息，或执行它原本无法执行的操作。

Tool 是 Skill 可以调用的资源，但 Tool 本身也不是 Skill。知道可以搜索，和知道在什么情况下搜索什么、怎么处理搜索结果，是两件不同的事。

Skill 是封装好的、可复用的能力单元。

它描述的是"在这一类场景下，应该怎么做"。它包含触发条件、执行流程、输入输出定义、约束规则。

Skill 不是一次指令，而是一个可以被反复调用的能力模块，它的设计目标是让同一类任务在不同场景、不同调用者、不同时间点下，都能稳定产生可接受质量的输出。

三者的关系用一句话来说：Prompt 是 Skill 的内核，Tool 是 Skill 的资源，Skill 是把两者组织起来、赋予边界和流程的结构。

那么，Prompt 到底不够用在哪里？

这里有三个内在局限，在个人使用阶段不明显，在规模化使用时会集中暴露。

第一个是不可组合。

单条 Prompt 是线性的、封闭的，无法被拆分成子模块，无法被其他 Prompt 调用，无法在不同任务之间共享部分能力。

你写了一百条 Prompt，它们之间没有结构关系，是一百个孤立的点，而不是一张可以延伸的网。

当你想构建一个稍微复杂的 AI 工作流，你会发现每一步都需要重新写一条提示词，而这些提示词之间的衔接逻辑，完全依赖你手动处理。

第二个是不可维护。

当模型更新、业务场景变化、评估标准调整时，Prompt 需要被修改。

但修改一条 Prompt，你面临的问题是：它在哪里被使用？修改会影响哪些下游任务？修改前后的效果差异可以被评估吗？

Prompt 没有版本，没有依赖关系，没有测试机制。你修改了它，你不知道是变好了还是变差了，更不知道在哪个方向上变了。

随着时间推移，你的 Prompt 库会积累大量"可能有用但不确定"的条目，最终变成一个没有人敢动也没有人愿意管的遗产库。

第三个是不可移交，这是最根本的局限。

一条 Prompt 的有效使用，深度依赖写它的人对业务背景的理解。

这个理解是隐性的，存在于写作者的脑子里，没有被结构化表达出来。当你把这条 Prompt 交给别人，你实际上只给了他指令，没有给他背景，没有给他边界判断的标准，没有给他"这个对、那个不对"的评估能力。他拿着一条黑盒，可以运行，但无法真正掌控。

Skill 的设计，正是为了把这三个问题一一解决：

可组合，因为 Skill 有清晰的输入输出定义，可以被编排；

可维护，因为 Skill 有版本、有测试用例、有评估标准；

可移交，因为 Skill 把执行逻辑、触发条件、约束规则都显式化了，不依赖写它的人在场。

理解了 Prompt 的局限，再来看 Skill 的本质是什么。

一个有用的定义是：Skill 等于 Prompt 加 Workflow 加 Context 加 Constraint。

这个等式容易被误读成"把这四样东西拼在一起"，但它描述的不是 Skill 的组成清单，而是 Skill 的四个设计维度，每个维度解决一个不同的问题，缺少任何一个，Skill 的质量都会在特定场景下崩塌。

Prompt 是核心指令，定义模型在这个 Skill 的执行过程中要做什么，它是 Skill 的执行核心，但单独存在时，它只是一条提示词，没有流程定义、没有上下文管理、没有约束边界。

Workflow 是执行流程，定义这件事分几步做、每步的目标是什么、每步的输入从哪里来、输出传到哪里去，这是 Skill 区别于 Prompt 最直接的特征，它把一次性的指令变成了可以被拆解、监控和优化的流程。

Context 是上下文管理，定义执行这个 Skill 需要哪些背景信息、从哪里获取、在执行过程中如何传递、在完成后哪些需要保留，上下文管理不是"提供更多信息"，而是"提供刚好够用的信息"，冗余的上下文会分散注意力，缺失的上下文会导致错误假设。

Constraint 是约束规则，定义输出必须满足的硬性条件和软性偏好、输入异常时的处理逻辑、在什么情况下 Skill 应该拒绝执行或返回错误，约束是 Skill 可信赖性的来源，一个没有约束定义的 Skill，你不知道它在边界情况下会做什么。

把 Skill 的结构从另一个角度来理解，可以用四个问题来框架。

When，什么情况下应该调用这个 Skill，触发条件的精准度直接决定 Skill 在系统里能否被正确路由，好的触发条件设计需要同时考虑"什么情况下该调用"和"什么情况下不该调用"，后者往往更难定义，也更重要。

How，这个 Skill 如何一步步完成任务，需要回答执行分几个阶段、每个阶段的目标是什么、每个阶段的输出是什么格式、前一个阶段的输出如何传入后一个阶段、在什么条件下需要进入修正循环。

References，执行这个 Skill 需要调用哪些外部资源，包括外部 Tool、其他 Skill、静态知识库、动态数据源，资源的定义决定了 Skill 的能力边界，需要但未定义的资源会导致 Skill 在执行时用不可靠的方式填补空白。

Rules，这个 Skill 的输出必须满足哪些条件，分两类，硬性约束是必须满足的条件，违反则输出无效；软性偏好是尽量满足但在权衡时可以让步的条件，区分这两类的价值在于，硬性约束违反时 Skill 应该触发失败机制而不是给出一个"基本满足"的输出。

理解 Skill 的本质，有一个角度比技术定义更有穿透力：Skill 是把人的经验，转化成模型可以执行的结构。

一个有丰富用户研究经验的产品经理，在做用户访谈分析时，脑子里有一套他自己可能都没有意识到的流程。

他先扫一遍所有访谈，不急着归类，先感知整体。然后开始区分表层抱怨和深层需求，识别跨访谈的共同模式，判断哪些信号值得追问，按影响范围和频次排列输出。

这套流程是经验，不是知识，是在做了二十次、五十次用户研究之后磨出来的直觉。

把这套隐性流程显式化、结构化，写成一个可以被模型稳定执行的 Skill，就是把个人经验转化成组织能力的过程。

完成之后，这套流程就不再只存在于一个人的脑子里，它可以被文档化，可以被测试，可以被团队共享，可以在这个人离开之后继续工作。

这是 Skill 设计最重要的价值所在，也是为什么说 Skill 是"组织能力"而不只是"个人工具"。

如果 Skill 是一个可以被独立设计和使用的能力单元，它就需要有一张标准化的说明书，让任何一个调用者都能理解它的能力边界，而不需要去找写它的人问。

这张说明书可以叫 Skill Card。

一个完整的 Skill Card 应该包含：这个 Skill 叫什么、解决的是哪类问题；在什么场景下应该调用，在什么场景下不应该调用，后者和前者同等重要；接受什么格式的输入，哪些字段是必须的，哪些是可选的，输入异常时如何处理；产生什么格式的输出，每个字段的含义是什么，输出的质量指标是什么；分几步执行、每步做什么、关键的判断节点在哪里；硬性约束和软性偏好分别是什么，失败条件是什么，降级策略是什么；这个 Skill 在哪类输入下表现不稳定，哪些场景超出了它的设计范围，调用者需要注意什么；当前版本是什么，和上一版本相比改了什么，改动的原因和评估结果。

Skill Card 不是为了做文档而做文档，它是 Skill 可被复用的基础设施。

一个没有 Skill Card 的 Skill，无论设计多精良，都只属于写它的那个人。

明白了 Skill 是什么，我们来建立一套标准，判断一个 Skill 是否优秀。

优秀的 Skill 可以被评估，不靠感觉靠标准。

判断一个 Skill 好不好，最直觉的方式是看输出，用了之后效果不错，就觉得 Skill 设计得好。

但这个判断方式有一个致命的问题：它依赖结果，而不依赖结构。

一个设计存在严重缺陷的 Skill，在典型输入下可能表现得相当好，直到遇到边界输入、异常输入、或者使用场景稍微偏移，它就开始以不可预期的方式失效。

评价体系的价值，是让你在设计阶段就可以判断 Skill 是否有结构性缺陷，而不是等到生产环境里出了问题才去排查。

可以从七个维度来评估一个 Skill 的质量。

第一个维度是原子性，这个 Skill 是否只做一件事。

一个承载多个职责的 Skill，复用性下降，测试困难，出错时定位不清。判断原子性的标准很简单：这个 Skill 的职责能用一句话清楚描述吗？如果描述里出现了"并且"，大概率需要拆分。

第二个维度是触发精准性，这个 Skill 的触发条件能否准确区分"应该调用"和"不应该调用"的场景。

触发精准性差会在系统里制造两类问题，误触发是这个 Skill 被调用了但场景并不适合，输出质量低但调用方可能察觉不到，把错误的输出当成可信结果使用；漏触发是明明适合这个 Skill 的场景，被路由到了其他地方，或者没有被任何 Skill 处理。

第三个维度是行为确定性，在相同输入下这个 Skill 是否产生稳定的输出。

行为确定性不要求措辞完全一致，但要求输出在质量水平、结构格式、核心内容上保持在一个可接受的范围内，并且这个范围可以被预期。行为确定性低的 Skill，在团队使用时会引发信任问题，调用者开始对每次输出做大量人工检查，Skill 的效率优势消失。

第四个维度是上下文效率，这个 Skill 使用了最少的必要信息吗。

冗余的上下文会分散模型的注意力、增加执行成本，有时候还会因为引入了与当前任务无关的信息而降低输出质量。衡量上下文效率的方式是问：如果去掉某条上下文信息，这个 Skill 的输出质量会下降吗？如果不会，这条信息是冗余的。

第五个维度是可评估性，这个 Skill 的输出可以被测试吗。

可评估性要求 Skill 有明确的评估标准：什么样的输出是通过，什么样的输出是失败，评估标准可以被量化或至少可以被一致应用。没有可评估性的 Skill 无法被迭代改善，你不知道修改之后是变好了还是变差了，也无法向团队证明这个 Skill 是可信赖的。

第六个维度是可组合性，这个 Skill 可以作为其他 Skill 的输入或输出吗，它的输入输出格式是否为编排设计好了接口。

一个只能独立运行、无法被编排进更大流程的 Skill，在系统价值上是有上限的。

第七个维度是安全与可控性，这个 Skill 是否定义了它不应该做什么，在异常情况下它的行为是可预期的吗。

安全与可控性包含两个层次：内容安全，也就是 Skill 是否有可能生成不应该生成的内容；行为安全，也就是在输入异常或执行过程出错时 Skill 是否有明确的降级行为，而不是以不可预期的方式运行。

把七个维度综合起来得到一个判断框架：高质量 Skill 等于能力边界乘以执行质量乘以工程可用性。

这是乘法关系，不是加法。

任何一个维度接近于零，整体质量趋近于零。

一个原子性极强但完全不可评估的 Skill 在生产环境里没有价值，因为你无法验证它是否在正确地工作。

一个行为确定性极高但触发条件混乱的 Skill 会在系统里制造大量噪音。

一个可组合性很好但没有安全边界的 Skill 在系统里是一个潜在的风险源。

这里有三个失效的反例值得单独说说。

第一个是过度封装的 Skill。

有人把"完整的竞品分析流程"做成一个 Skill，从搜集竞品信息、功能对比、市场定位分析，到生成报告，全部在一个 Skill 里完成。

这个 Skill 在原子性维度上严重失分，它实际上承载了四个性质完全不同的子任务：信息收集依赖 Tool 调用，结构化对比依赖分析框架，定性判断依赖领域知识，报告生成依赖写作能力。

把它们塞进一个 Skill，导致的结果是换一个分析目的整个 Skill 需要重写，某一个子任务出了问题无法定位是哪一步，无法单独复用其中任何一个子能力。

正确的做法是把这四个子任务拆成四个 Atomic Skill，再用一个 Task Skill 把它们编排成完整的分析流程。

第二个是触发条件过于宽泛的 Skill。

有一个 Skill 的触发条件是"当用户需要了解产品相关信息时"，这个触发条件的覆盖范围几乎是无限的，导致这个 Skill 频繁被调用，但因为场景差异太大，内部的执行逻辑无法同时适配所有场景，输出质量严重不稳定。

更严重的问题是因为这个 Skill 覆盖面太广，其他更专业的 Skill 没有机会被触发，系统的整体能力被压缩成了一个万能但平庸的 Skill 的表现。

第三个是没有失败定义的 Skill。

一个用于分析用户反馈情感倾向的 Skill，定义了成功输出的格式，但没有定义在什么情况下应该拒绝执行或返回错误。

结果是当输入不是用户反馈时，比如输入了一段代码，它会给出一个情感倾向判断，但这个判断是没有意义的，而且格式上完全正确，调用方无从判断。

在自动化流程里，没有人工审查的情况下，这个错误输出会被当成有效数据传入下一步，导致整个流程的输出基于一个错误的前提。

在实际设计时可以用七个问题做一次快速自检。

这个 Skill 的职责可以用一句话不包含"并且"地描述吗？

列出五个应该触发和五个不应该触发的场景，触发条件的判断都正确吗？

把同一个典型输入运行三次，输出在质量水平和核心内容上是否基本一致？

去掉任何一条上下文信息，输出质量是否会下降？

能否清楚地描述什么样的输出是通过，什么样的输出是失败？

输入输出格式是否标准化，可以被不同的上游传入和不同的下游接收？

输入异常时这个 Skill 会做什么，失败条件是否明确定义？

七个问题，如果有任何一个回答是"不确定"，那里就是 Skill 在设计上的薄弱点。

说完了评价标准，我想在这里停下来谈一件更根本的事，因为如果跳过它，后面所有的方法论都会被误用。

Skill 的质量上限，不取决于你掌握了多少设计框架，而取决于你对业务场景的理解有多深。

这个结论在上一篇讲提示词时已经出现过，在 Skill 的语境里它有更具体的含义，因为 Skill 比 Prompt 封装了更多的隐性判断，这些判断的质量完全由设计者的认知深度决定。

Skill 设计里有三类关键判断，没有一类可以被框架替代。

第一类是粒度判断，这个任务应该被设计成一个 Skill，还是三个 Skill？边界在哪里？

这个判断没有公式可以套用，它依赖设计者对这个任务在真实业务场景里的理解：哪些子任务在不同情境下会被独立调用，哪些子任务的耦合关系太紧密不适合拆分，哪些子任务的复用价值足够高值得独立封装。

一个没有在这个业务领域工作过的人，拿到同样的任务描述，会做出截然不同的粒度判断，这两种错误在 Skill 运行的早期都不容易被发现，但会在规模化使用时集中暴露。

第二类是约束判断，这个 Skill 的边界在哪里？哪些输入是异常的？哪些输出是不可信的？

这类判断依赖对领域的深度理解。

一个有丰富用户研究经验的人，在设计"提炼用户访谈痛点"的 Skill 时，知道哪类输入是不可靠的，比如访谈时间过短、被访者对产品不熟悉、访谈问题引导性太强，也知道哪类输出需要被标记为低置信度。

没有这个背景的人，约束往往停留在表层：输入格式正确、输出字段完整。这样的 Skill 在典型场景下能用，在边界情况下开始失效，但设计者没有能力预见这些边界，也没有能力在失效后定位原因。

第三类是评估判断，这个 Skill 的输出好不好，好在哪里，差在哪里，怎么改。

评估能力是 Skill 能否持续改善的决定因素。

一个 Skill 从"能用"到"好用"，需要经历大量的迭代，每一步都依赖设计者的评估能力。

没有评估能力，Skill 的迭代就变成了随机的调整，改了一些，运行一下，感觉好像变好了，也不知道为什么，下次出了问题还是无从下手。

这里还有一个在实践中非常常见的做法需要被说清楚：让 AI 帮你生成 Skill，给它一个任务描述，让它自动生成触发条件、执行流程、约束规则。

这个做法可以生成一个 Skill 的框架，解决了从零开始的启动成本问题，但它无法生成高质量的 Skill，原因是结构性的。

AI 能生成的，是在它的训练数据里见过的模式的组合，对于通用的 Skill 结构它可以给出合理的框架。

但 Skill 里真正有价值的部分，精准的触发条件、合理的粒度拆分、真正有效的约束边界，都依赖对你的具体业务场景、你的用户群、你的产品特点的深度理解，这些理解不在 AI 的训练数据里，它在你的经验里。

更根本的问题是：如果你没有能力判断 AI 生成的 Skill 框架是好是坏，你就无法有效地修改和改善它。

用 AI 生成 Skill 框架是节省启动成本的合理做法，但不要把这个过程和 Skill 设计混淆。Skill 设计是填充框架的判断，不是生成框架的操作。

来看两个人面对同一个任务设计"分析竞品功能差异"的 Skill，这个对比会把认知差距说得很清楚。

第一个人在产品领域工作了五年，做过深度的竞品分析，知道竞品分析在不同阶段服务于不同的目的，立项时看可行性，产品迭代时看差距，融资时看市场空间，每个目的对应不同的分析维度和输出格式。

他知道什么样的竞品信息是可靠的，什么样的是需要质疑的，也知道竞品分析最常见的失效模式是流于表面的功能罗列，缺乏对用户场景的理解。

他设计的 Skill，触发条件会明确区分三种使用目的，执行流程会在功能对比之前先建立用户场景框架，约束规则会包含"不做无证据的价值判断"，失败条件会定义"当竞品信息来源不可靠时返回低置信度标记而不是正常输出"。

第二个人对竞品分析的理解停留在概念层面，他设计的 Skill，触发条件是"当需要了解竞品时"，执行流程是"收集信息、整理对比、生成报告"，约束规则是"输出要专业、客观"，没有失败条件定义。

这两个 Skill 在结构上都是完整的，都可以运行。但在实际使用时，第一个 Skill 的输出对决策的价值，会系统性地高于第二个。

差距不在于谁掌握了更多的 Skill 设计技巧，而在于谁对这个领域的理解更深。

可以用一个公式来总结这一点：Skill Quality 约等于建模能力乘以领域知识乘以评估能力。

这里也是乘法关系，其中任何一个因子接近于零，整体质量就趋近于零。

建模能力决定了 Skill 的粒度划分是否合理、触发条件是否精准、流程设计是否有效。

领域知识决定了 Skill 的约束是否覆盖了真正重要的边界、失败条件是否定义了真实会发生的异常。

评估能力决定了 Skill 能否被有效迭代，从初版走向稳定的高质量版本。

技巧只是最后一公里，前面那段路靠的是认知。

这个结论有两个直接的实践含义。

第一，在你有深度理解的领域先建 Skill，不要试图用 Skill 覆盖你不熟悉的领域，从你最熟悉的三个场景开始，把你在那些场景里的隐性经验显式化成 Skill，然后在使用中积累评估能力，再逐步扩展。

第二，Skill 设计是显式化认知的过程，不只是写文档的过程，在设计 Skill 的过程中你会被迫回答很多平时不会明确思考的问题：这个任务真正的目标是什么，失败的条件是什么，什么样的输出是我不满意的，为什么不满意。

设计 Skill 的副产品，是你对自己工作经验的更清晰的理解，这个理解不只在 Skill 里有用，在所有需要判断的场景里都有用。

理解了认知是上限，我们来看 Skill 设计的第一步，也是最难的一步：如何定义能力边界。

Skill 设计的核心不是描述任务，而是抽象能力。大多数人在设计 Skill 时，会从任务描述开始，"这个 Skill 是用来做竞品分析的"，"这个 Skill 是用来整理用户反馈的"。

任务描述是必要的起点，但它不是 Skill 的定义，任务描述告诉你这个 Skill 服务于什么目的，能力抽象告诉你这个 Skill 实际在做什么。

这两者之间的差距，就是 Skill 设计真正困难的地方。

来看一个具体的例子。

任务是"整理用户反馈"。如果直接把这个任务描述变成 Skill，你会得到一个输入是"一批用户反馈"、输出是"整理好的反馈报告"的黑盒。

能力抽象的做法是拆解这个任务，识别其中涉及的不同性质的子能力。

第一个子能力是信息提取，从非结构化的文本里识别有效的反馈信息，区分具体的功能反馈、情感表达、使用场景描述，这是一个信息处理能力。

第二个子能力是分类聚合，把性质相似的反馈归并到同一个主题下，识别跨条目的共同模式，这是一个模式识别能力。

第三个子能力是优先级判断，根据反馈的频次、影响范围、业务重要性，排列输出的优先级，这是一个评估判断能力。

这三个子能力性质不同，触发条件不同，需要的领域知识不同，可以被独立测试，也可以在不同的任务组合里被独立调用。

把它们分别设计成三个 Atomic Skill，再用一个 Task Skill 编排成完整的反馈整理流程，就得到了一个可组合、可测试、可复用的 Skill 结构。

任务描述是目的，能力抽象是手段，从任务描述出发，通过能力抽象，才能得到真正有工程价值的 Skill 定义。

把从任务到能力的抽象过程分解成三个步骤。

第一步是分解任务，识别子任务，找出其中的天然边界，天然边界通常出现在输入输出格式发生变化的地方、所需知识类型不同的地方、可以独立被复用的步骤。

第二步是判断性质，区分能力类型：信息提取类、转换类、判断类、生成类、路由类，不同类型的能力在设计时关注的重点不同，信息提取类 Skill 的核心是覆盖率和精确度，判断类 Skill 的核心是判断标准的清晰度，生成类 Skill 的核心是约束的充分性。

第三步是确定粒度，决定合并还是拆分，判断标准是三个问题：

这个子任务可以用一个清晰的单句描述吗？

它在两个以上的不同场景里会被独立使用吗？

它可以被独立测试吗？

三个问题都回答"是"，适合作为独立的 Atomic Skill；有任何"否"，需要进一步分析是粒度太细需要合并，还是职责太复合需要继续拆分。

关于粒度，有一个值得记住的原则：初期设计时，建议稍微倾向于细粒度。

细粒度的 Skill 可以组合，粗粒度的 Skill 很难拆分，而拆分的代价远大于组合。

当 Skill 的数量增长，同质化是最常见的质量问题，功能高度重叠的 Skill 并存，调用者不知道该用哪个，维护时需要在多处同步修改。

同质化有三类成因：命名不同但行为相同，这类最难发现；场景不同但逻辑相同，这类情况通常可以通过参数化解决，把差异作为 Skill 的输入参数，用一个 Skill 覆盖多个场景；迭代产生的版本重叠，旧版本没有被明确下线，这是版本管理缺失的直接后果。

去重的判断标准不是名字而是行为：在相同输入下，两个 Skill 的输出在质量水平和核心内容上有实质差异吗？如果没有，它们是同质的，应该合并。

Skill 库里 Skill 的数量不是能力强弱的指标，一个有二十个边界清晰、可组合的 Skill 的库，系统价值远高于一个有两百个功能重叠、粒度混乱的 Skill 的库。

能力边界清楚了，下一步是设计 Skill 的内部结构，让它真正稳定地执行。

Skill 的稳定性来自过程定义，不来自目标描述。目标描述和行为定义的差距，在简单任务里不明显，但当输入开始变化，没有行为定义的 Skill 就开始表现出不稳定。

设计一个 Skill 的正确顺序，是先定义输入和输出的结构，再设计执行流程，最后写核心指令。

输入结构决定了 Skill 需要什么信息，输出结构决定了 Skill 应该产生什么，两者共同约束了执行流程的设计空间。

在结构没有定义清楚之前设计流程，是在没有地基的情况下砌墙。

输入 Schema 的设计需要回答：这个 Skill 需要哪些必须提供的信息，缺少这些信息 Skill 无法执行或无法产生可信的输出；哪些是可选信息，提供了会改善输出质量，不提供也可以以降级模式运行；输入的格式是什么；输入里有没有需要预处理的部分。

输出 Schema 的设计需要回答：这个 Skill 产生什么格式的输出，下游的调用者如何使用这个输出；输出的每个字段代表什么；哪些字段是必须的，哪些是在特定条件下才出现的；输出里需要包含置信度或质量标记吗。

把输入和输出 Schema 定义清楚，执行流程的设计就有了明确的起点和终点。

有了结构，下一步是把执行过程分解成清晰的步骤。

好的步骤设计有几个特征：每个步骤有单一的目标，可以用一句话描述完成这个步骤意味着什么；步骤之间有清晰的衔接关系，前一步的输出是后一步的输入，没有信息的隐含跳跃；每个步骤的成功条件是可以判断的；关键的判断节点被显式标记出来，在哪些步骤上执行路径会根据中间结果分叉。

在 Skill 的执行流程里，有两类性质根本不同的步骤，需要用不同的方式设计。

推理步骤需要模型做出判断：这段反馈属于哪个类别，这个问题的优先级是高还是低，这个用户的真实需求是什么。

推理步骤的设计不应该给出过于细化的规则，而是应该提供判断框架，什么样的特征对应什么样的判断，边界情况如何处理，判断的置信度如何标记。

过度细化推理步骤的规则会带来两个问题：

一是覆盖不了所有情况，规则之外的输入会导致不可预期的行为；

二是有时候正确的判断需要违反规则，但被规则约束的模型无法做出这个判断。

推理步骤需要的是框架，不是规则。

执行步骤需要模型按规则操作：把输出格式化成指定的格式、把超过一百字的内容截断、把三个并列的分析结论合并成一段摘要。

执行步骤的特点是正确答案是明确的，它依赖对规则的精确遵守，不需要判断，不应该有歧义。

对执行步骤应该给出精确的规则，不留自由发挥的空间，否则会引入不一致性。

把推理步骤和执行步骤在设计里明确区分，是提升 Skill 行为确定性最有效的单一措施之一。

一个只定义了成功路径的 Skill，是不完整的设计。

完整的 Skill 设计必须同时定义失败条件。

前置验证是在 Skill 开始执行之前检查输入是否满足基本前提，如果不满足返回明确的错误而不是强行执行，应该覆盖输入格式是否符合要求、输入内容是否在 Skill 的处理范围内、输入规模是否在可处理的范围内。

中间步骤的质量检查是在关键步骤完成后检查中间输出是否达到继续执行的质量阈值，阈值的定义需要具体化，不是"质量不够好就重试"，而是"如果分类步骤的置信度低于某个值，触发人工确认流程"。

输出验证是在产生最终输出之前检查输出是否满足所有硬性约束，如果不满足进入修正流程或者返回错误。

降级策略是定义当 Skill 无法完成预期任务时能提供的最低保证，完全失败通常不是最好的选择，一个部分完成的输出加上明确的标记说明哪些部分无法完成，往往比一个空输出更有价值。

失败设计的价值不只是防止错误输出，更重要的是让调用方对 Skill 的行为有清晰的预期，这种可预期性是 Skill 在系统里可以被信赖的基础。

在推理控制上，还有三种成熟的策略可以在不同场景下提升执行质量。

逐步推导适用于判断链条长、中间步骤相互依赖的推理步骤，要求模型先展开推理过程再给出结论，可以显著减少推理跳跃带来的错误，但会增加输出长度和处理时间，适合对质量要求高、对速度要求低的步骤。

自我验证是在生成输出之后要求模型检查输出是否满足所有约束，并在不满足时修正，适用于有多个并列硬性约束的步骤，使用这个策略时验证步骤应该有明确的检查清单，而不是笼统的"检查输出是否满足要求"。

示例引导是在步骤里提供输入输出对的示例，让模型学习期望的处理模式，适用于有明确输出模式但难以用语言精确描述的步骤，示例的质量比数量更重要，一个高质量的示例比三个平庸的示例更有效。

单个 Skill 设计清楚了，接下来面对一个更大的问题：多个 Skill 如何协同工作。

单个 Skill 的价值有限，系统协同才是真正的能力放大。

真实的业务任务几乎没有可以被单个 Skill 完整覆盖的，从单个 Skill 到 Skill 系统，是能力从点到网的跨越。

这个跨越需要在设计层面解决几个新问题：Skill 怎么分层，怎么路由，怎么编排，怎么管理状态。

一个成熟的 Skill 体系，自然会形成三个层次。

Atomic Skill 是原子能力层，单一职责，边界清晰，独立可测试，可以在不同的 Task Skill 里被复用。

Atomic Skill 应该对调用方透明地暴露它做什么、接受什么格式的输入、产生什么格式的输出、在什么情况下会失败，调用方不需要知道 Atomic Skill 内部如何实现，只需要知道如何调用和如何处理它的输出。

举例来说，从文本里提取结构化的时间信息、判断一段内容的情感倾向、把非结构化的产品描述转化成标准化的功能列表，这类能力是 Atomic Skill 的典型候选。

Task Skill 是任务能力层，由多个 Atomic Skill 编排而成，完成一个完整的业务任务。

Task Skill 本身通常不包含核心的执行逻辑，它的主要职责是编排，按什么顺序调用哪些 Atomic Skill、如何传递中间结果、在什么条件下选择不同的执行路径、如何汇总和格式化最终输出。

Task Skill 的设计关注的是流程的合理性和鲁棒性：当某个 Atomic Skill 失败时怎么处理，当中间结果不满足预期时走哪条路径，如何在保证质量的前提下最小化执行成本。

Meta Skill 是元能力层，负责根据上下文判断应该调用哪个 Task Skill 或 Atomic Skill，处理跨任务的状态管理和异常协调。

Meta Skill 是系统的调度层，它的输入是用户的原始请求或系统的触发信号，它的输出是执行路径的决策。Meta Skill 的设计难度最高，因为它需要准确理解所有下层 Skill 的能力边界才能做出正确的路由决策。

大多数组织目前在 Atomic Skill 和 Task Skill 层已经有足够的复杂度需要处理，Meta Skill 是系统成熟后自然演化到的层次，不建议在能力体系建立的早期就急于设计。

在多 Skill 系统里，给定一个输入，系统如何决定调用哪个 Skill，这个问题叫路由，它的设计质量直接决定系统的整体行为是否可预期。

路由有两种基本模式：

规则路由用明确的条件判断来决定调用哪个 Skill，优点是行为完全可预期、可以被精确测试，缺点是当输入的多样性增加时规则的维护成本快速上升；

模型路由用一个专门的 Skill 判断输入应该走哪条路径，优点是对输入的多样性有更好的适应性，缺点是路由本身的行为不完全可预期。

实践中两种模式往往需要结合使用，用规则路由处理高频明确的场景，用模型路由处理长尾模糊的场景，并且对模型路由的结果建立监控，定期把高频的模糊场景转化成明确的规则。

路由设计的核心原则是：每个 Skill 的触发条件之间应该有清晰的互斥关系，所有应该被处理的场景都应该有对应的 Skill 可以被路由到不留盲区，路由的决策应该可以被记录和审查。

多 Skill 编排有三种基本模式。

顺序执行是前一个 Skill 的输出是后一个 Skill 的输入，步骤之间有明确的依赖关系，设计要点是明确每个步骤的输出格式使得它可以直接作为下一步的输入。

并行执行是多个 Skill 同时处理不同维度的问题，结果在后续步骤里合并，适用于任务的各部分可以独立分析的场景，设计要点是合并步骤的逻辑，当多个并行 Skill 的结果都返回后如何综合，如果某个并行 Skill 失败是等待重试还是用其他结果继续。

条件分支是根据某个 Skill 的输出结果决定下一步调用哪个 Skill，设计要点是分支条件的精确定义，"如果质量不够好走修正分支"不是一个可执行的条件，什么叫质量不够好、用什么指标判断、阈值是什么，这些需要在设计阶段明确。

三种模式的组合使用是真实 Task Skill 编排里最常见的形式。

状态管理方面，Stateless 是 Skill 的默认选择。Stateless Skill 每次执行都是完全独立的，不依赖任何历史执行的结果或状态，行为完全可预期，可以被精确测试，可以并行运行，失败时可以安全重试，不存在状态累积带来的行为漂移。

绝大多数 Atomic Skill 应该是 Stateless 的，如果一个 Atomic Skill 的执行需要访问历史状态，大概率是边界划分有问题。

Stateful Skill 在执行过程中维护状态，后续执行可以访问历史结果，适用于任务的性质确实需要跨轮次的信息积累，但设计复杂度显著高于 Stateless，需要定义状态的数据结构、生命周期、一致性保证、恢复机制。

判断标准是：任务的性质是否确实需要跨轮次的状态积累，而这种积累无法通过在每次调用时传入完整上下文来替代？如果可以通过传入完整上下文来解决，优先选择 Stateless。

这里有一个值得单独说的反直觉点：系统里 Skill 之间的关系，比每个 Skill 本身的质量更重要。

一个由边界清晰、关系简单的普通 Skill 组成的系统，比一个由精心设计但相互耦合的优秀 Skill 组成的系统，在长期维护和演化上表现得更好。

结构清晰是系统价值的基础，单点质量是在结构清晰之后才值得投入的优化。

系统设计清楚了，下一步是工程化。

没有工程约束的 Skill，不具备生产价值。

一个在测试环境里表现良好的 Skill，进入生产环境后面临的挑战是完全不同量级的。

测试环境里，输入是精心准备的典型案例，运行是手动触发的单次调用，评估是有经验的设计者逐条审查。

生产环境里，输入是真实用户或真实数据，充满了测试用例里没有覆盖到的边界情况，运行是自动化的高频调用，没有人在每次执行后审查输出，出了问题需要有机制来发现、定位和修复。这个距离，就是工程化实践要填补的。

一个没有通过工程化验证的 Skill，进入生产的风险不是"可能表现不够好"，而是"可能在不被察觉的情况下持续产生错误输出"。

一个 Skill 在进入生产之前，必须有可以被执行、结果可以被客观判断的测试。

测试不是指"手动跑几次感觉还不错"，而是有明确的测试用例、有可以判断通过或失败的标准、有可以量化的评估指标。

测试用例需要覆盖三类场景：

典型用例，覆盖最常见的正常使用场景，应该反映真实使用中 80% 的情况而不是最简单或最容易通过的情况；

边界用例，覆盖触发条件边缘的场景，这类通常是 Skill 在生产中失效最多的地方；

异常用例，覆盖不应该被这个 Skill 处理的场景，测试的是 Skill 的拒绝能力。

评估标准需要量化，结构性标准检查输出的格式是否符合 Schema 定义，这类标准可以完全自动化检查；质量性标准检查输出的内容是否达到预期的质量水平，可以通过设计具体的检查问题来提高一致性。

有些 Skill 的质量标准确实难以量化，这种情况下至少要建立一个"专家评估"的基线，让领域专家对一批典型输入的输出做评分，建立质量基线，未来的版本用同样的评估方式对比。

每次 Skill 的执行都有成本，Token 消耗决定直接费用，延迟决定用户体验，并发限制决定系统吞吐量。

上下文效率是成本控制的核心杠杆，上下文冗余不只是贵，它还会降低输出质量，精简上下文是同时提升质量和降低成本的操作，不是质量和成本之间的权衡。

在设计阶段，对每条传入 Skill 的上下文信息问一个问题：如果去掉这条信息，输出质量会下降吗？如果不会，这条信息是冗余的，去掉它。

不同使用场景对延迟的容忍度不同，用户实时等待的场景延迟直接影响体验，需要在设计阶段就控制 Skill 的复杂度和输出长度；批量处理的场景延迟相对不敏感，可以在质量和速度之间更偏向质量。

安全方面有两类必须提前设计的风险。

第一类是 Prompt Injection，当 Skill 的输入来自用户或外部数据源时，存在恶意输入试图覆盖 Skill 指令的风险，防御的核心是在 Skill 设计里明确分离指令层和数据层，在系统提示词里放置 Skill 的核心指令和约束规则，在用户消息里放置需要处理的输入内容，并明确说明用户消息是需要被处理的数据而不是需要被执行的指令。

第二类是数据泄露，Skill 在执行过程中可能接触敏感信息，防御有两个层次：

在 Skill 的约束层明确定义哪类信息不能出现在输出里；

在输出验证层自动检查输出是否包含了被禁止的信息类型。

对于处理高度敏感信息的 Skill，需要在系统架构层面考虑数据隔离。

生产环境里的 Skill 还需要有完整的执行记录，包括完整保存每次调用的输入内容（在安全合规允许的前提下）、Skill 版本、每个步骤的执行结果、可量化质量指标、每次执行的 Token 消耗和延迟。

完整的执行日志不只是为了排查问题，它是持续优化 Skill 的数据基础，通过分析日志可以识别哪类输入最频繁触发边界情况、哪个步骤最常出现质量问题、Skill 的实际使用场景和设计时预期的使用场景有哪些偏差。

上线前的检查清单只有五项，缺任何一项不应该进入生产：

有覆盖典型、边界、异常场景的测试用例并通过；

失败条件明确定义；

执行日志机制就位；

成本在可接受范围内有估算；

安全风险已审查。

通过了工程化的验证，Skill 进入生产，但这不是终点，而是生命周期的开始。

Skill 是长期资产，不是一次性产物，它需要被管理，而不只是被使用。

一个 Skill 在设计完成并通过测试之后，业务场景会变化，模型会更新，使用者的期望会提升，系统里其他 Skill 的变化会影响这个 Skill 的表现。

一个在半年前设计良好的 Skill，今天可能已经不再满足业务需求，但如果没有生命周期管理，这个事实不会被主动发现，只会在某次使用时发现"怎么突然不好用了"。

Skill 的生命周期包含六个阶段。

设计阶段，把业务需求转化成 Skill 的结构定义，核心产出是 Skill Card，包含能力定义、触发条件、输入输出 Schema、执行流程、约束规则、失败条件、已知局限。

这个阶段还需要做一件经常被跳过的事：记录设计决策的理由。

为什么粒度划定在这里而不是更粗或更细？

为什么选择了这个执行流程而不是另一种方式？

这些决策的背景和理由，对未来维护和修改这个 Skill 的人来说，价值不亚于 Skill 本身。

没有记录理由的设计，随着时间推移，会变成一个没有人敢动也没有人愿意管的黑盒。

测试阶段，用覆盖典型、边界、异常场景的测试用例验证 Skill 的行为，建立质量基线，产出测试报告。

测试报告需要记录哪些用例通过了，哪些没有通过，没通过的原因是什么，是被接受的已知局限还是需要修复的问题。

没有通过所有测试的 Skill，在进入生产之前需要一个明确的决策：是修复后再上线，还是带着已知的局限上线并记录清楚？

两种选择都是合理的，但这个决策需要被明确做出，而不是被默默忽视。

发布阶段，Skill 进入生产环境，初期通常需要灰度发布，先在小范围内开放，观察真实使用场景下的行为，确认与测试环境的表现一致，再逐步扩大覆盖范围。

发布时需要同步完成的事：确认执行日志机制就位，设置关键指标的监控和告警，通知 Skill 的潜在调用方并提供 Skill Card 的访问路径和使用说明，明确维护责任人以及问题反馈的渠道。

监控阶段，持续观察 Skill 在生产环境里的表现。需要监控的核心指标包括：

执行成功率，也就是触发执行后成功产生有效输出的比例；

质量分布，如果有自动化的质量评分机制，追踪分布的变化；

边界触发频率，触发失败条件的频率高于预期说明有系统性的输入问题；

成本趋势，Token 消耗和延迟的趋势，异常上升需要排查。

一个 Skill 的质量通常不会突然崩塌，而是缓慢漂移，输入分布的微小变化、模型行为的细微调整、业务场景的渐进演化，都会逐渐让 Skill 的表现偏离设计预期。

只有持续的监控，才能在漂移变成严重问题之前发出信号。

优化阶段，基于监控数据和用户反馈进行定向改善。优化的触发来源有三类：监控指标的异常、用户或调用方的反馈、主动的定期审查。

每次优化都需要遵循一个基本原则：先定位问题，再修改设计，再测试验证，再发布新版本。

跳过定位直接修改或者跳过测试直接发布，会引入新的不稳定因素，而且无法确认修改是否真正解决了问题。

优化完成后，需要记录改了什么、为什么改、改前改后的质量指标对比。

淘汰阶段，当一个 Skill 不再满足业务需求，或者被更好的设计取代时，有明确的下线流程。

淘汰不是把 Skill 从库里删掉，而是一个有步骤的过程：

首先确认没有活跃的调用方依赖这个 Skill，通知所有历史调用方，提供替代方案，在一段观察期后正式下线并归档而不是删除。

归档而不是删除，是因为一个被淘汰的 Skill 仍然有价值，它的 Skill Card 记录了当时的设计决策，它的测试报告记录了质量基线，它的版本历史记录了迭代过程，它的失败案例记录了设计的边界和教训，这些记录是设计下一代 Skill 的宝贵输入。

每次对 Skill 的修改都应该产生一个新版本。

版本管理的价值不是形式上的规范，而是解决三个实际问题：

当新版本出现预期外的问题时能够快速回滚，当某个时间点后 Skill 的输出质量发生变化时能够追溯到具体是哪次变更引入了问题，在发布新版本之前可以用旧版本和新版本同时处理同一批输入对比输出质量。

版本记录的基本要素包括版本号、变更时间、变更内容摘要、变更原因、变更后的测试结果、当前版本的状态。

版本号建议采用主版本和次版本的格式：主版本号变更代表结构性修改，需要重新完整测试；次版本号变更代表优化性修改，可以做针对性的回归测试。

当 Skill 的数量积累到一定规模，需要一个有组织的结构来管理，也就是 Skill Library。

Skill Library 不是 Skill 的堆积，而是一个有检索能力、有质量标准、有维护机制的能力管理系统。

好的 Skill Library 应该让调用者能够快速找到他们需要的能力，判断某个 Skill 是否适合他们的场景，以及在多个候选 Skill 之间做出合理选择。

这要求每个 Skill 有清晰的分类和可搜索的描述，有明确的质量门槛，区分"可信赖"和"实验性"的 Skill，有定期审查机制，识别长期未更新但业务场景已变化的 Skill、识别同质化的 Skill 并推动合并、识别长期低质量的 Skill 并推动改善或下线。

没有维护机制的 Skill Library，会随时间积累成一个混乱的废墟。

一个优秀的 Skill 不是静态的，它应该随着使用积累而持续演化，在保持核心职责稳定的前提下提升边界情况的处理质量、降低执行成本、收窄触发条件的误差。

可学习性的前提是可评估性，只有能被评估的东西才能被有方向地改善。

Skill 演化的数据来源有三个层次：

执行日志提供大量真实的输入输出对，是识别 Skill 在哪类输入上表现不稳定的最直接来源；

用户反馈提供了自动化评估无法捕捉的质量维度；

专家评审定期让领域专家对一批 Skill 的输出做深度评估，识别自动化监控无法发现的系统性偏差。

把这三个来源的数据结合起来，形成对 Skill 当前状态的完整理解，是 Skill 从"能用"演化到"好用"的路径。

把所有这些综合起来，我们来看最后一个问题：这一切的终点是什么？

Skills 体系的终极价值，不是让 AI 更强，而是让组织能力可以被沉淀、复用和传承。

理解这件事，需要从三个层次来看。

第一个层次，Skill 作为能力单元，解决的是"一类任务能不能被稳定执行"的问题，这是个人层次的价值。第

二个层次，Skill Library 作为组织能力，解决的是"团队积累的经验能不能被结构化地保存、共享、传承"的问题，这是组织层次的价值。

一个有良好 Skill Library 的团队，和一个同样规模但能力都存在个人脑子里的团队，在人员流动、业务扩张、跨部门协作时，表现会有系统性的差距。

前者的能力存在于系统里，后者的能力存在于人身上。

存在于系统里的能力可以被传承、被复用、被持续改善，存在于人身上的能力随着人的离开而流失。

第三个层次，Agent 系统作为调度层，解决的是"在复杂的动态任务里，如何动态组合能力来最优地达成目标"的问题，这是大多数组织还没有到达的阶段，但理解它的位置有助于判断当下的 Skill 设计是否在朝正确的方向积累。

理解这三个层次有一个直接的实践含义：不要跳步。在 Skill 的质量还不稳定、Skill Library 的组织还混乱的时候，急于建设 Agent 调度系统，只会把复杂度叠加到混乱之上。

大多数组织的 AI 能力演化会经历三个阶段。

第一阶段是个人使用，每个人用自己的方式使用 AI，能力无法共享，经验无法传承，AI 使用是个人行为，不是组织能力。

第二阶段是 Skill 化，把个人的提示词和工作流提炼成有结构的 Skill，建立 Skill Library，能力开始在团队层面流通，从第一阶段到第二阶段是一个需要主动推动的跨越，不会自然发生，它需要有人承担推动者的角色，建立规范，并且有耐心在早期投入比直接使用更多的时间来设计和文档化 Skill。

第三阶段是系统化，Skill 之间形成协同关系，有路由机制、编排逻辑、监控体系，能力不再是孤立的点而是一个有结构关系的网络，组织开始把 AI 能力作为基础设施来管理而不是作为个人工具来使用，这个阶段的标志不是技术复杂度而是组织成熟度。

最有效的起点，不是设计一个宏大的 Skill 体系，而是选择一个你最熟悉的、高频使用的场景，把你在这个场景里的隐性工作流显式化成一个完整的 Skill。

完整意味着有 Skill Card、有测试用例、有失败条件定义、有评估标准，不需要一开始就做到完美，但每个要素都应该有。

然后用这个 Skill 工作几周，收集真实的使用数据，识别它在哪里表现不如预期，做第一次迭代，记录迭代过程。

这个过程会让你对 Skill 设计的实际挑战有第一手的理解，也会让你有一个具体的可以展示给团队的例子，来说明 Skill 化带来的实际价值。

从一个 Skill 开始，比从一套体系开始，更容易产生真正有价值的结果。

最后，用两篇内容加在一起的视角做总结。

上一篇解决的问题是如何把一个模糊的意图，设计成模型可以稳定执行的精准指令，核心工具是结构化提示词、七步设计框架、多轮编排。

今天解决的问题是如何把可以稳定执行的指令，封装成可以被组织管理和复用的能力单元，并把这些单元组织成协同工作的系统，核心工具是 Skill 的四层结构、七维度评价模型、生命周期管理框架。

两篇内容共享同一个底层判断：认知是上限，工具只是放大器。

不管是提示词还是 Skill，设计质量的天花板都由设计者对业务场景的理解深度决定。

工具会持续变化，模型会更强，架构会演化，Skill 的定义和边界也会随着实践的深入被重新理解。