简介：Skill 不是更长的提示词，而是一种可复用、可触发、可评测的工作能力。本文围绕 Skill 的五种设计模式展开对比分析，说明各自的结构差异、适用场景与选型依据。同时结合一套可落地的评测方法，帮助团队判断一个 Skill 是否真的让智能体表现更好，而不是仅仅增加了提示词长度。
随着智能体应用逐步进入实际业务，很多团队已经不再争论 Skill 目录应该叫什么名字、SKILL.md 应该怎么写这类格式问题。真正的挑战变成了另一个更关键的问题：
一个 Skill 到底应该被设计成什么类型？它如何被触发？如何证明它确实让智能体表现更好了？
常见的 Skill 目录结构已经趋于一致：SKILL.md 负责写触发条件和执行说明，references/ 存放规则与知识，assets/ 放模板，scripts/ 放可执行脚本。这种目录结构解决了“知识放哪里”的问题，但没有解决“知识应该怎么组织才真正有效”的问题。
本文将 Skill 设计抽象为五种基础模式，并对它们进行系统对比。同时，引入一套最小可用的评测思路，帮助团队从“写得像 Skill”走向“确实有效的 Skill”。
在进入模式对比之前，需要先澄清两个容易混淆的设计思路。
最常见的一种做法是把大量背景知识、操作规范、接口说明直接塞进系统提示词里。虽然这确实能让智能体在某些任务上表现更稳定，但问题也很明显：
另一种做法是给每个能力建一个 Skill，但不考虑触发时机也不分层设计。结果是智能体加载了大量 Skill，却不知道什么时候应该用哪一个，最终表现为随机调用或漏调用。
这两种误区的本质都是缺少结构。Skill 需要被设计成一种可触发、可加载、可评测的单元，而不是一堆散落的知识碎片。
下面将五种 Skill 设计模式分别定义，并从核心目标、知识组织方式、触发方式、适用场景、主要风险五个维度进行对比。
核心目标：让智能体在执行某类工具或框架相关任务时，临时获得足够准确的领域知识。
这类 Skill 的核心特征是：SKILL.md 只负责说明“什么时候触发”和“如何应用规则”，详细的规范、约束和最佳实践放在 references/ 中。脚本则用于机械检查，避免智能体靠记忆执行。
典型场景包括：内部组件库使用规范、某业务模块的数据协议、某类接口的调用约定、框架最佳实践等。
优势：知识分层清晰，触发条件明确，不会长期占用上下文。
风险：如果触发词写得过于宽泛，可能导致错误触发；如果 references/ 内容过多且未做二次分层，加载后仍可能造成选择困难。
核心目标：解决输出结构不稳定的问题。
同样是让智能体写技术报告，第一次可能有摘要，第二次没有；第三次把结论放到了最前面，第四次又放到最后。内容本身可能都不差，但结构不一致意味着无法进入自动化流程。
生成器型 Skill 的做法是：
典型场景包括：技术报告、API 文档、PR 描述、发布说明、复盘模板、项目脚手架。
优势：输出结构可控，适合需要批量处理或进入下游流程的任务。
风险：如果模板设计过细，可能限制智能体在内容层面的发挥；如果过粗，又达不到稳定结构的目的。
核心目标：提供稳定、可重复的审查能力。
审查型 Skill 的关键设计原则是：把评审标准和评审动作解耦。评审标准属于“审什么”，放在 references/ 或 assets/ 中；评审动作属于“怎么审”，由 SKILL.md 中的流程描述或 scripts/ 中的检查脚本来执行。
典型场景包括：代码审查、安全检查、文档审校、架构评审。
优势：评审标准可以独立更新，不影响审查流程；审查流程可以被多个标准复用。
风险：如果标准文件组织不善，容易出现规则冲突；如果脚本只覆盖部分规则，智能体可能误以为已经完成全部检查。
相对于前三种模式，编排型 Skill 解决的是“多步骤协作”的问题。它并不直接提供领域知识，而是定义一组操作的执行顺序、条件分支和失败处理逻辑。
其核心是流程控制：先做什么、遇到什么情况走哪条分支、失败后重试还是降级。这类 Skill 的 SKILL.md 更像一个状态机描述，scripts/ 中可能包含步骤检查或环境准备脚本。
典型场景包括：发布流程、故障排查流程、数据入库前的多步清洗流程。
优势：降低智能体在多步任务中的跳步和遗漏。
风险：流程描述过于死板时，智能体缺少应对异常情况的灵活性。
当领域知识数量很大，无法在单次加载中全部放入上下文时，需要知识检索型 Skill。它的典型做法是：
这种方式与工具包装型的区别在于：工具包装型通常对应一个相对聚焦的领域，而知识检索型面向的是大规模、多子域的知识集合。
典型场景包括：大型平台的运维手册、跨团队的统一规范库、复杂业务系统的故障知识库。
优势：能够处理远超单次上下文容量的知识量。
风险：索引设计不合理时，智能体可能找不到正确条目；索引更新滞后时，会出现加载错误内容的情况。
| 对比维度 | 工具包装型 | 生成器型 | 审查型 | 编排型 | 知识检索型 |
|---|---|---|---|---|---|
| 核心目标 | 临时注入领域知识 | 稳定输出结构 | 可重复的审查流程 | 多步骤流程控制 | 大规模知识按需加载 |
| 知识组织重点 | references/ 为主 | assets/ 模板为主 | 标准与动作分离 | 流程描述为主 | 索引加分层文件 |
| 触发特征 | 任务类型匹配 | 输出类型匹配 | 审查对象匹配 | 流程起点匹配 | 索引条目匹配 |
| 主要风险 | 触发过宽或过窄 | 模板过细限制灵活性 | 规则冲突 | 流程过死板 | 索引失效 |
| 适合的知识规模 | 中小规模、聚焦领域 | 小规模、结构优先 | 中规模、标准明确 | 中小规模、流程明确 | 大规模、多子域 |
设计完成只是第一步。一个 Skill 是否真正有效，需要通过实际评测来验证。以下是可落地的评测思路，核心是将“能力提升”拆成可观察、可对比的指标。
任务集不是随意拼凑的几道题，而是要与 Skill 的触发条件对应。任务集应包含三类：
评测必须是相对比较。基线可以是：
没有基线，就无法判断提升究竟来自 Skill 设计，还是来自任务本身比较简单。
建议至少观察以下维度：
如果条件允许，可以对任务集进行人工评分或自动评分。评分标准应与 Skill 的目标一一对应。每次修改 Skill 后，都要在固定任务集上做回归，验证核心能力没有因调整而下降。
表现为智能体在部分任务中没有意识到 Skill 存在。改进思路是回看任务集中未触发的案例，归纳共同特征，在 SKILL.md 中补充更具泛化性的触发描述。
表现为 Skill 虽然被加载，但智能体没有真正使用 references/ 中的规则。改进思路是检查 SKILL.md 中的执行说明是否足够明确，是否存在“需要时参考相关资料”这类模糊表述。应当明确写出“在做出判断前，必须先读取 references/xx.md 中的规则”。
表现为脚本只覆盖部分检查点，智能体错误地认为脚本通过就是全部通过。改进思路是在 SKILL.md 中明确脚本的覆盖范围，以及哪些部分需要智能体自行判断。
当多个 Skill 在相似任务上发生竞争时，需要审视每个 Skill 的触发条件是否有足够的区分度。必要时可以将共同部分抽出来，作为独立的通用 Skill。
Skill 设计的关键，并不在于目录格式统一与否，而在于是否能为特定任务提供恰好需要的知识、结构或流程控制。五种模式之间的差异，本质上不是优劣之分，而是对不同任务特征的适配。
工具包装型解决“知识不够专业”，生成器型解决“输出不够稳定”，审查型解决“审查不够一致”，编排型解决“步骤不够可靠”，知识检索型解决“知识太多放不下”。一个成熟的 Skill 体系，往往不是只使用其中一种模式，而是根据任务特征选择最合适的组合。
评测的意义在于让 Skill 的迭代不再依赖主观感受。只有通过任务集、基线对比和回归测试，团队才能清楚地知道：一个 Skill 到底有没有用，以及它为什么有用。