AI Agent Skills系统深度解析：从Claude工程师实践看工作流迁移与调教心法

April 5, 2026

我之前曾指出，对于AI智能体（Agent）而言，记忆系统或上下文工程往往会成为其发展中的难点与瓶颈，而技能（Skills）生态才是其真正核心所在。这一点从OpenClaw的调教过程中便能得到印证：

大家在训练和优化这类智能体时，几乎不会过度关注上下文管理，但一定会持续不断地打磨Skills。原因非常简单：记忆系统通常是一个黑盒，难以直接干预；而Skills则是具体工作流程（Workflow）的迁移与封装。

因此，我们有必要再次深入探讨Skills，重新认识其价值。不过，这一次我们将引入更**“权威”**的视角：参考由Claude Code团队工程师Thariq撰写的一篇长文：

Lessons from Building Claude Code:  
How We Use Skills

Skills系统概述

首先，现代语境下的Skills含义非常丰富。它不再是一个简单的提示词文件，而是一个完整的能力包。这个能力包具备可维护、可复用、可度量的特性。

作者强调，一个Skill本质上是一个文件夹，它可以包含脚本、资产文件、参考文档、配置文件、数据以及各种钩子（Hook）。

它通过渐进式披露的策略，在不导致上下文信息爆炸的前提下，将流程沉淀为可被触发的工作流。需要注意的是，这里所说的流程既可以是个人工作习惯，也可以是组织或团队的协作流程。

Thariq这篇文章的核心价值并非其中提供的几段指令模板，而是他提出的一个系统性建议。这个建议的实践结果，催生了一套可规模化的Skills管理系统：

***技能分类法（共9类）：***帮助你像管理产品功能矩阵一样管理技能组合；
***设计原则：***避免写入常识性内容、将易失败点明确标注为“Gotchas”、利用文件系统实现渐进式披露、防止过度“牵引”模型行为、确保初始设置（setup）可恢复、从“提示工程”转向“上下文工程”；
***分发与治理机制：***从项目仓库内的 .claude/skills 目录，到插件化与市场（Marketplace）；从“自发试用”过渡到“被动发现+准入门槛”，以解决规模化后带来的技能冗余、冲突与上下文成本上升问题；
***度量闭环：***利用 PreToolUse 钩子记录Skill调用情况，识别热门技能、低触发技能及过度触发技能，从而将主观的“感觉很好用”转化为可量化、可迭代的增长系统。

原文链接如下：

https://x.com/trq212/article/2033949937936085378

我明白这些概括性的要点可能不易理解，它们相当于整篇文章的摘要。我们后续会逐一详细解释，因此不必担心。

这里需要补充两点：尽管Skills概念最初由Claude团队明确提出，但现在几乎所有主流的基础模型都对其提供了支持。这清晰地预示着一个趋势：

Skills正在成为AI Agent的通用中间层，它介于模型的基础能力与**具体工具（Tools）**之间，专门用于承载和封装各类流程与工作流。

简而言之，Skill就是为Agent准备的标准化作业程序（SOP）包。其内容核心，很多时候也确实就是SOP本身。

接下来，我们将进一步拆解，详细说明Skill包的组成部分及其运行机制。

Skills技术架构拆解

Skills包（或文件夹）是一种可执行的配置与资产封装格式，其典型结构如下所示：

<skill-name>/  
├── SKILL.md  
├── references/  
├── assets/  
├── scripts/  
└── 其他配置/数据文件

这意味着，一个Skill是一个目录级的能力单元：

SKILL.md：作为整个能力包的入口文件与主要说明文档。
references/：用于存放长文档、参考资料、规则解释等背景知识。
assets/：用于存放模板文件、样例、静态资源等。
scripts/：用于存放可执行的脚本文件。
必要时还可以包含 hooks、config、data 等目录或文件，用于承载约束条件、配置项与持久化状态。

这里需要再次强调：Skill的本质不是提示词的简单增强，而是工作流的系统性封装。

首先，我们来解析最外层的SKILL.md文件。

一、SKILL.md：总入口与调度中心

许多人会本能地认为SKILL.md就是写给模型阅读的正文内容，因此试图将所有说明、注意事项和流程步骤一次性全部塞入其中。

这是一种常见的误解。

SKILL.md真正扮演的角色，是这个能力包的索引页、路由页与使用说明页的综合体。它至少承担着以下四个核心职责：

向模型说明这个Skill是做什么的。
向模型阐明在什么情况下应该触发这个Skill。
引导模型在触发后，应该先读取什么内容，后读取什么内容。
规定模型输出的结果大致应该是什么样的格式或结构。

因此，SKILL.md实际上是一个调度入口：

一个Skill包就像一个项目文件夹，而SKILL.md则是这个文件夹的README文件、运行手册（runbook）和路由契约（routing contract）的结合体。

由于SKILL.md的核心作用是说明**“具体如何操作”**，其撰写原则也就清晰了：

主流程必须清晰明了。
触发条件和边界必须明确。
关键易错点需要突出强调。
引导模型按需读取references、assets等其他目录的内容。

二、description字段：触发协议

许多Skill失效，问题不在于内容本身，而在于description字段的编写。大多数人在撰写description时，产出的内容更像产品功能简介：

用于帮助分析数据。
用于自动生成报告。
用于产品验证。
用于故障排查。

这种写法对于人类读者尚可接受，但对于模型而言，几乎毫无用处。因为description的首要阅读对象是模型，而非人类。

它在Skill系统中的角色，本质上是一个触发协议。也就是说，这里真正要解决的问题不是“我是谁”，而是：在什么场景下，你应该想到并使用我。

一个高质量的description，至少需要同时回答以下四个问题：

我解决的是哪一类具体任务？
这类任务通常会被用户以什么样的语言或方式描述？
哪些情况属于我的职责边界之内？
哪些情况明确不属于我的处理范围？

举例来说，如果你只写：

用于产品验证

那么这句话的价值极低。因为“产品验证”可以涵盖多种情况：页面验收、埋点校验、视觉对比等。

更正确的写法应该是：

用于Web产品上线前的验证工作，适合检查主流程路径、核心按钮功能、关键数据埋点、错误日志记录以及进行截图对比。通常在需求开发完成、准备提交测试或正式上线前触发。不适用于需求评审阶段，也不处理纯文档撰写任务。

至此，我们应该更加清楚：description负责Skill的触发与路由判断，而SKILL.md则负责在路由命中后的具体执行流程展开。

三、references/目录：知识层

如前所述，Skill是工作流的迁移，而references目录则承载了知识层。这一层存放的并非“即将执行的步骤”，而是：

API接口文档。
业务规则详细解释。
数据字段口径说明。
历史案例与经验。
反常识或特殊规则。
相关系统背景知识。
……

它存在的意义非常明确：

将那些知识密度高、低频读取但在关键时刻至关重要的内容，从主流程说明中剥离出来，实现按需加载。

这正是渐进式披露理念的体现。

一个典型的references目录可能包含以下文件：

references/  
├── checklist-explained.md      # 解释每个检查项存在的理由  
├── common-failures.md          # 历史常见失败案例汇总  
├── screenshot-examples.md      # 截图对比的正例与反例  
└── analytics-gotchas.md        # 数据埋点与日志分析中的易错点

四、assets/目录：模板层

AI模型本身具备一定的自由度。许多任务真正的难点，不在于模型“不会做”，而在于它“每次做得不一致”。例如，让它输出一份故障复盘报告、周报或竞品分析……

模型当然能够完成，但输出格式往往不稳定。assets目录的作用，就是将这种“会做但不稳定”的问题，转化为“有模板可依”的稳定输出。它通常包含：

输出文档的骨架结构  
固定格式的模板文件  
可供参考的示例文件  
标准化的文件结构  
可复用的样例代码或配置

一个成熟的Skill，通常不仅告诉模型“如何执行”工作流，还会通过assets目录告诉它“最终应该交付什么格式的结果”。

五、scripts/目录：确定性脚本层

在AI智能体发展早期，业界有一句名言：更多的上下文（More context），意味着更少的控制（less control）。然而，实际的演进方向是朝着关键任务工作流的封装与管理发展。

到了scripts这一层，已经不再是简单地告诉模型如何操作，而是开始将那些需要确定性执行的动作下沉为具体的脚本。

这一步的意义非常重大。原因在于，模型最擅长处理的是：

理解任务意图。
做出判断与决策。
进行步骤规划。
提供解释与说明。
串联多个步骤。

而模型相对不擅长，甚至容易出错的，恰恰是：

重复性的精确执行。
严格的校验与比对。
机械化的格式转换。
固定结构的稳定输出。
可靠的数据抓取与处理。

如果强行让模型用自然语言处理这些动作，最终必然导致大量的输出不稳定。Skill的核心设计原则之一便是：

能够下沉为脚本执行的操作，就不要再让模型用自然语言勉强完成。

从这里可以看出，其设计理念已经与早期的“less control”思路有了显著不同。

具体而言，以下类型的任务非常适合封装进scripts目录：

读取日志文件并按错误级别进行过滤。
执行SQL查询并将结果转换为固定格式的表格。
调用多个API接口并聚合返回结果。
校验文件或目录结构是否符合规范。
进行页面截图并执行图像对比。
运行上线前的自动化检查项。
生成固定模板的报告文件。
……

通过逐步引入脚本，Skill的性质发生了转变。它不再仅仅是一份教模型做事的说明书，而是演变成一个：由模型负责调度与决策、人类经验负责规则约束、脚本负责确定性执行的复合能力包。

也正是从这里开始，Skills与传统Workflow之间的关系才真正清晰起来。因为许多传统工作流引擎中的节点，本质就是：

读取某个输入。
调用一个脚本或工具。
产生一个中间结果。

而现在，这种节点级的能力，正以更灵活的方式被重新封装并迁移到Skill目录中。所以我之前强调：

Skills是Workflow的迁移

那些曾经被硬编码在工作流引擎中的步骤，正在以更灵活、更可复用的方式，转化为Agent可直接调用的能力包。

例如，一个验证型Skill的SKILL.md中可能包含这样的流程指引：

1. 首先确认本次需要验证的页面范围。
2. 运行 scripts/check.sh 脚本进行基础环境与配置检查。
3. 如果检查失败，先汇总所有失败项，不要直接判断为通过。
4. 如果检查通过，再继续进行截图对比、埋点校验和日志层面的验证。
5. 最后，按照 assets/ 目录下的模板，输出完整的验证报告。

六、Hook：约束与埋点层

scripts层解决了如何稳定执行的问题，而Hook（钩子）层则致力于解决另外两个关键问题：

如何添加执行约束与安全控制。
如何进行调用埋点与状态观测。

这一层对于组织级的大规模落地至关重要。因为个人开发者编写Skill时，最关心的是“是否好用”；但组织内部引入Skill时，必须关心：

是否会被误用或滥用。
是否会执行越权操作。
是否会留下完整的操作日志以供审计。
是否会产生意外的副作用。
是否会影响其他并发流程或系统。

此时，Hook的意义就凸显出来了。它允许你在Skill执行链路的关键位置插入确定性的控制逻辑。

例如，可以实现的Hook包括：

在调用工具前检查输入参数的有效性与安全性。
在执行高风险命令（如删除、修改配置）前进行人工确认或自动拦截。
在结果生成后自动验证其格式是否符合要求。
在某个Skill被调用时自动记录日志，包含调用者、时间、参数等信息。
在运行结束后自动记录成功或失败的状态，并可能触发通知。

换言之，Hook赋予了Skill 可观测性、可治理性与风险控制能力。

到了这一步，Skill的系统性架构就完全展开了。你可以将其整体理解为一个分层结构：

SKILL.md 负责描述方法、流程与调度。
references/ 负责提供背景知识、补充说明。
assets/ 负责定义输出模板、固定格式。
scripts/ 负责执行确定性的、可重复的动作。
hooks 负责添加安全约束、进行埋点观测和状态记录。

这几层组合在一起，才构成一个完整、健壮的Skill。

接下来，在了解结构之后，我们探讨其运行机制。

Skills运行机制解析

许多人在优化AI智能体（如“小龙虾”）时效果不佳，往往是因为不了解Skills的内在机制。除了基本的目录结构，还需要清楚它究竟如何被触发、如何被展开、如何被执行。

实际上，Skills的运行逻辑是清晰且分层的。

第一步：索引与发现

一个Skill的内容并非在对话会话一开始就被全部加载到模型的上下文中。正常情况下，模型最初感知到的只是一个非常轻量级的索引层，通常包括：

Skill的名称。
description 字段（这是最核心的触发依据）。
少量元数据信息（如分类标签、版本等）。

然后，模型根据用户当前提出的任务或问题，判断是否有必要调用某个特定的Skill。也就是说，Skill的第一步是“被发现”，而非“被执行”。

因此，Skill系统的底层一定存在一个：技能目录、技能清单或技能索引。

这一层索引的清晰度直接决定了后续自动触发的准确性：索引越清晰，触发越精准；索引越混乱，则越容易出现“过触发”（不该触发时触发）或“欠触发”（该触发时未触发）的问题。

许多团队在后期会发现，Skill体系治理的第一个重点，并非脚本或模板的优化，而是：

索引体系是否清晰，即每个Skill的description字段是否撰写得足够精确。

第二步：主流程展开

当模型判断某个Skill与当前任务高度匹配（即“命中”）后，它才会开始读取该Skill目录下的 SKILL.md 文件。此时，模型获得的是该能力包的主流程说明，内容包括：

任务的具体目标。
推荐的执行步骤。
明确的使用边界与限制。
对输出结果的要求。
指明哪些背景知识存放在 references/ 目录中。
说明哪些确定性操作需要调用 scripts/ 目录下的脚本。
提示哪些执行阶段可能设有Hook进行干预。

这意味着，Skill并非一开始就让模型通读所有内容，而是遵循：

先触发发现，再展开主说明，最后根据实际需要深入读取具体资源。

这是一种典型的分层加载、按需索取的策略。

第三步：按需深入读取

模型在进入Skill的主流程后，并不会机械地将整个目录的所有文件全部读取一遍。更常见的情况是根据执行过程中的实际需求，动态展开不同层次的内容：

当缺乏背景知识时，去读取 references/ 下的相关文档。
当需要生成固定格式的输出时，去参考 assets/ 下的模板文件。
当需要执行一个精确、可重复的动作时，调用 scripts/ 下的对应脚本。
当执行到需要安全控制或状态记录的环节时，触发相应的Hook。

这一步的结果，是将原本可能冗长、混杂的一整段提示词（prompt），拆解为多个层次清晰、职责分明的能力组件。你可以将整个运行链路抽象为：

索引层（发现） → 主说明层（SKILL.md） → 知识层（references/） → 模板层（assets/） → 执行层（scripts/） → 约束层（hooks）

这正是Skills设计中的工程化思维体现：确保模型在合适的时机，获取到恰好需要的信息与能力。

核心结论

如果将上述整套机制进行高度抽象，你会发现：

Skill的本质不是对模型能力的直接增强，而是对工作流进行重组和封装的一种工程方法。

这一认识至关重要，因为许多人在讨论Skills时，思维仍停留在如何教会模型变得更聪明的层面。

实际上，Skill本身无法改变模型的基础能力。它本质上是一种工程优化方案：将人类的工作流程与方法论，系统地迁移并封装到AI Agent的体系之中。其根本目的，是在面对相同或类似任务时，实现以下几个目标：

减少每次从零开始构建解决方案的重复劳动。
避免模型因自由度过高而导致输出结果不稳定。
确保任务执行符合组织或团队既定的标准与方法。
……

因此，Skill并非模型内在能力的一部分，而是附着于其上的流程与方法包。它的真正价值不在于让模型变得更像一个善于聊天的助手，而在于：让模型转变为一个能够按照标准作业程序（SOP）可靠工作的执行单元。

Skill最终承载的，不是自然语言本身，而是结构化的方法与实践。重申一遍：它是Workflow的迁移。

至此，相信大家对Skills的运行机制已经有了清晰的理解。接下来，我们将深入探讨Thariq文章中的核心方法论部分：技能分类法。

技能分类法：构建可治理的能力矩阵

在理解技术结构之后，我们需要回答一个关键问题：Skill应该如何进行分类？

讨论分类的原因涉及更复杂的组织协作层面，其目的不仅是为了个人使用方便，更是为了支撑团队乃至组织级别的规模化运转。换言之，只要你计划将Skills应用到组织层面，建立分类法就是无法绕开的基础步骤。

原因非常简单。如果没有清晰的分类体系，所有Skill最终都会混杂在一起，进而引发四个严重的治理问题：

触发混乱：模型难以准确判断在什么场景下该调用哪个Skill。
维护混乱：随着数量增长，查找、更新、废弃Skill变得异常困难。
分发混乱：无法针对不同团队、不同项目进行精准的技能集分发。
度量混乱：难以对不同类型Skill的使用效果、ROI进行有效评估。

也就是说，没有分类，就谈不上有效的治理。这最终依然是一个需要被解决的工程问题。

Thariq文章的一个重要贡献在于，他没有将Skill仅仅视为零散的技巧集合，而是明确提出了一个包含九大类的技能分类法。

这件事的意义，并不完全在于“划分了九个类别”本身，而在于：

他将Skill从个人开发者私藏的效率技巧，提升到了可以像管理产品功能模块一样进行系统化治理的能力组合。

一旦Skills开始被分类，它就不再仅仅是工程师的个人工具箱，而是开始类似于：

软件开发的组件库。
操作系统的插件市场。
产品的功能特性矩阵。
企业内部统一的能力目录。

另一方面，对Skills进行准确分类至关重要。不同类型的Skill具备独特的特性，分类错误将直接导致后续的维护困难，例如：

一个本该只读的参考型Skill，错误地赋予了写操作权限。
一个本该将操作下沉为脚本的验证型Skill，却仍在主说明中堆砌冗长的操作描述。
一个本该明确触发边界的Skill，其description却写得像模糊的产品简介。
……

无论何时，分类都是管理复杂性的基石。分类的结果旨在清晰回答两个核心问题：

这类Skill应该扮演什么角色？
扮演这个角色的Skill有哪些共性？它们的设计模式、治理策略和分发方式应该是怎样的？

以下是Thariq提出的九类技能：

1. 参考型技能

这类技能最类似于“内部知识库插件”。它主要解决的并非执行问题，而是确保模型在特定专业领域内不再基于猜测或常识行事。

典型例子包括：

内部SDK或框架的详细使用规范。
特定API套件的调用方式与最佳实践。
关键业务系统的数据字段口径说明。
某条业务线的特殊规则与政策解释。
特定技术栈或架构的设计范式。

这类Skill的设计重点不在于脚本，而在于：

知识密度：提供深入、准确的背景信息。
引用组织：将知识结构化，便于模型按需查找。
触发边界：明确界定其适用的查询范围。
坑点介绍：明确指出该领域内常见的误解或陷阱。

它的核心价值在于，显著降低模型犯下“看似理解，实则错误”的低级错误的概率。

2. 验证型技能

这一类技能在整个Skill体系中具有极高的实用价值。因为它直接关系到产品质量、返工率和上线风险控制。

典型例子包括：

网页或应用界面的上线前验收。
数据埋点的完整性与准确性核对。
接口变更后的回归测试。
代码拉取请求（PR）的自动化检查。
发布前的冒烟测试（smoke test）。
需求实现完成度的自动化核查。

这类Skill的普遍特点是：

执行流程相对固定、明确。
验收标准可以部分或全部被标准化。
非常适合将检查动作脚本化。
特别适合配套使用断言（assertion）和固定报告模板。

它与“参考型技能”最大的区别在于：

参考型技能主要致力于教导模型理解知识，而验证型技能已经开始要求模型产出可验证的证据或结论。

因此，这类Skill通常最值得投入精力进行精细化打磨，也最容易产生可量化的投资回报率（ROI）。

3. 数据获取与分析型技能

这类技能主要用于处理数据相关的任务，包括：

从各种数据源拉取原始数据。
对数据进行清洗、转换与预处理。
聚合多个数据源的信息。
基于数据分析产出摘要或结论。

典型应用场景如：

拉取核心业务指标并自动生成每日/每周报表。
对比不同营销渠道的活动表现数据。
提取用户反馈文本并进行自动归类与情感分析。
汇总系统日志并生成异常事件摘要。
读取客户工单数据并进行问题聚类分析。

这类Skill的关键挑战不在于AI模型是否具备分析能力，而在于：

数据源连接的稳定性与权限控制。
数据口径说明是否清晰、无歧义。
输出模板是否固定，能确保报告格式统一。
分析过程中的中间状态或历史记录能否被有效保存和复用。

因此，它往往需要同时依赖references（口径说明）、scripts（数据拉取与处理脚本）、assets（报表模板），有时还需要持久化状态（data目录）来存储历史查询或配置。

一旦这类Skill成熟，通常最受业务团队欢迎，因为它最接近实际替代重复性人力劳动的目标。

4. 团队/业务流程型技能

这一类技能正是我之前常提到的，最接近标准化作业程序（SOP）封装的部分。

它不是为某个单一工具服务，而是直接承载一个团队或整个组织的固定协作流程。例如：

每周团队会议前的信息收集与议题整理。
新需求进入评审阶段前的材料准备流程。
软件版本发布前的标准检查清单执行。
客户投诉处理的标准操作流程（SOP）。
运维值班人员的交接班流程。
项目周报或事故复盘报告的自动化汇总与生成。

这类Skill的重点不在于某个单点能力的强弱，而在于完整流程的迁移与固化。也就是说，它最接近于：

将那些原本依赖人脑记忆、依靠师徒制或文档传承的组织做事方式，系统性地迁移并封装为Agent可以理解和调用的标准化工作流。

它的组织级价值非常高，因为它承载的已经超越了单纯的效率提升，更关乎：

流程一致性：确保不同成员、不同团队执行相同流程时标准统一。
组织经验沉淀：将优秀实践固化下来，避免因人员流动而流失。
新人入职手册：为新成员提供清晰、可交互的实操指引。
跨团队协作标准化：减少因流程理解差异导致的沟通成本。

5. 模板/脚手架型技能

这类技能最像传统的生产力工具或代码生成器。它们主要用于快速创建符合规范的文件或结构。

典型例子包括：

初始化一个新项目（如微服务、前端应用）的标准目录结构。
生成符合团队规范的拉取请求（PR）描述模板。
生成产品需求文档（PRD）或技术设计文档（TDD）的骨架。
生成测试用例的框架文件。
生成各种报告（如实验报告、调研报告）的初稿模板。

这类Skill的显著特点是：

输出结构的规范性至关重要。
模板资源文件（assets） 扮演核心角色。
相比于references，scripts（生成脚本）和assets（模板文件）通常更为重要。

它的核心价值在于，大幅减少项目初始化、文档撰写等场景下的重复性、机械性劳动，同时推动组织内部产出物的标准化。

6. 代码质量与评审型技能

这类技能主要服务于软件研发体系的质量保障环节。例如：

自动化检查代码拉取请求（PR）是否符合团队的编码规范（如命名、注释、复杂度）。
审查代码中可能存在的安全漏洞或风险模式。
校验单元测试或集成测试的覆盖率是否达标。
检查第三方依赖库的升级是否合理，评估兼容性与风险。
检查代码是否违反了某些特定的内部架构或设计约定。

这类Skill往往需要具备很强的“边界意识”。它看起来像一个“自动化代码审查意见生成器”，但真正有价值的部分在于封装：

组织特异性的代码评审标准和红线规则。
项目历史中常见的、易导致故障的编码模式（即“坑点”）。
必须检查但容易遗漏的细微项（如许可证声明、配置文件等）。
资深工程师在长期评审中积累的经验性判断逻辑。

它的产出不只是一些自动化评论，更是将团队的代码质量文化和审查经验进行了有效的数字化沉淀。

备注：这个分类法也存在可探讨之处，例如它专门针对研发场景设立了此类，那么是否也需要为人力资源、财务等职能部门设立专门的技能类别呢？这体现了分类法需要根据组织实际情况进行适配。

7. 部署/持续集成/运行保障型技能

这类技能开始触及较高风险的运维与发布领域。例如：

应用或服务上线前的最终自动化检查。
自动生成版本发布说明草稿。
引导或辅助执行服务回滚流程。
对目标部署环境进行预验证。
对持续集成（CI）流水线的运行结果进行总结与告警。
检查代码分支状态、依赖版本等发布相关条件。

这类Skill往往会涉及到：

执行Shell命令或运维脚本。
与部署工具链（如Ansible, Kubernetes）交互。
读取和判断复杂的环境状态信息。
调用外部监控、告警系统。

因此，其设计关键已不仅仅是“功能能否实现”，更需要重点考虑：

权限如何精细控制（如最小权限原则）。
是否应该禁止全自动触发，改为需要人工确认。
是否内置了二次确认或复核机制。
是否通过Hook 添加了充分的风险约束与操作审计。

这体现了组织级Skill与个人玩具级Skill在安全性和可靠性要求上的根本差异。

8. Runbook（运行手册）型技能

这类技能在运维领域特别具有代表性。它本质上是将传统运维文档中的故障处理手册、应急响应流程（Runbook）进行Agent化封装。

典型例子包括：

针对某类特定线上故障（如数据库连接池耗尽）的标准化排查路径。
处理某类特定监控报警（如CPU使用率持续飙升）的自动化诊断与处置建议。
应对某类数据库异常（如主从延迟过大）的调查与恢复步骤。
某类核心服务不可用时的应急预案执行引导。

这类Skill是体现Skill全部价值分层架构的绝佳样本：

references/ 承载故障背景知识、原理说明。
scripts/ 承载自动化的检查、诊断或恢复动作。
assets/ 承载标准化的故障报告、处置记录模板。
hooks/ 承载高风险操作前的拦截、确认与全程审计。
data/ （可选）承载历次故障处理的状态或历史数据。

这类Skill，也是Workflow迁移理念最直观、最有效的实践案例。

9. 基础设施/环境运维型技能

这类技能最接近高权限、高风险的底层系统操作。例如：

对服务器、容器、网络等基础资源的健康状态巡检。
自动修复某些已知的、低风险的环境配置问题。
对Kubernetes集群或其他编排系统进行标准化巡检。
联动分析日志系统与监控系统的数据，定位潜在问题。
执行磁盘空间清理、镜像仓库垃圾回收等资源维护任务。

这类Skill的组织价值可能很高（能提升运维效率），但其伴随的风险也最高。因此，它在治理策略上与前述类型有本质不同：

更适合手动触发，而非由模型全自动决策触发。
必须遵循最小权限原则，严格限制操作范围。
需要极强的操作审计（Audit Trail），所有动作必须可追溯。
需要强Hook防护，对删除、重启等高危操作进行多因素确认。
更适合作为受控分发的能力，仅对授权人员或系统开放，而非纳入普通的技能发现目录。

分类的目的在于有效治理

对Skills进行分类当然不是为了追求形式上的美观。其核心价值在于揭示一个关键事实：不同类型的Skill，天然适用于不同的设计模式、管理策略和风险控制等级。

例如：

参考型Skill，更侧重于references内容的丰富性与gotchas（易错点）的完整性。
验证型Skill，更侧重于断言（Assertions）的准确性、检查脚本的可靠性以及证据收集的完备性。
流程型Skill，更侧重于步骤编排的逻辑清晰度和输出模板的实用性。
Runbook型Skill，更侧重于可观测性（确保执行过程可见）和风险控制（防止误操作扩大问题）。
高风险运维型Skill，更侧重于权限隔离、操作确认机制和强审计要求。

因此，分类的本质不是简单的知识管理，而是进行规模化工程治理的必要前提。如果不先对Skill进行清晰的分类，后续几乎无法有效地开展以下几项关键治理工作：

为不同类型Skill制定统一的模板规范。
设置差异化的准入门槛和发布评审流程。
明确各类Skill的维护负责人（Owner）。
设计针对性的测试与验证方式。
划定清晰的权限与操作边界。
规划合理的分发渠道与策略（如项目内、团队内、组织内）。
建立有效的使用度量与迭代体系。

简而言之，一套清晰的分类法是决定组织级Skills能否成功落地、高效运转的基石。缺乏分类，整个体系很容易陷入混乱。

Skills设计核心原则

接下来进入实操技巧分享环节。许多人在编写Skill时最容易犯的一个错误，就是试图将所有背景知识写全、把所有流程步骤写满。这种做法看似完整，实则价值有限。

因为Skill不是编写给人用来复习知识的教科书，而是写给AI模型在执行具体任务时调用的操作指南。因此，真正有价值、需要写入Skill的内容，不是普遍性的常识，而是：

模型基于其训练数据默认容易理解错误或忽略的地方。
你所在组织内部特有的、非公开的业务规则或技术约定。
过去在执行同类任务时反复出现过的问题、翻车的案例。
哪些情况下不能按照常规逻辑或直觉去处理。

换句话说：

避免写入“众所周知”的常识，只专注于写入“模型不知道、但对于正确完成任务又至关重要”的信息。

这里最值得在Skill中沉淀的内容，就是 Gotchas。这个词在原文中反复出现，其大白话含义就是：

易错点：哪些地方最容易出错？
反常识规则：哪些规则与通常的认知或公共知识相悖？
历史翻车案例：过去曾经因为什么具体原因导致失败？
默认直觉会误判的地方：模型或人类直觉上容易做出错误假设的环节。

其实核心原则就一句话：优先纠正模型（或新手）最容易做错、最可能误解的地方。

其次，是第二个核心设计原则：能够下沉为确定性脚本执行的操作，就不要再继续用自然语言描述让模型“硬做”！

模型擅长的是理解、规划、解释和串联。但诸如重复执行、精确校验、固定格式转换、稳定数据抓取这类任务，天然更适合交给脚本程序来完成。总体建议是构建一个协同体系：

模型：负责高层次的任务理解、步骤规划、决策判断和流程串联。
脚本：负责低层次的、确定性的、可重复的具体动作执行。
模板：负责确保最终输出结果的格式稳定、符合规范。
references：负责在模型需要时，按需提供深入的背景知识补充。

备注：对于文中提到的脚本编写，大家无需感到压力。后续我们会有系列关于AI辅助编程（AI Coding）的文章，帮助大家高效地创建和维护这些脚本。

技能的分发与规模化治理

我们在过去使用工具调用（Function Calling / Tools）时，最常遇到的烦恼就是：工具数量增多后难以维护，且一次性加载过多工具容易导致上下文窗口紧张或调用错误。Skills本身的设计初衷之一是“包裹”和整合一堆相关的Tools。然而，随着Skill数量的增长，系统本身也出现了因Skills过多而导致的失控问题……

这一点在个人使用与团队协作的对比中尤为明显。个人开发者使用Skill，关注点主要在“是否好用、高效”；而团队或组织引入Skill时，必须关注：

技能是否会被错误地触发（误报）。
不同技能之间是否会产生逻辑冲突或重复。
加载大量技能是否会显著增加模型的上下文负担，影响响应速度与成本。
技能是否可能执行越权操作，带来安全风险。
随着时间推移，技能库是否会变得臃肿、难以维护和更新。

因此，当Skill体系发展到一定规模后，核心挑战就从“如何编写单个Skill”转变为“如何系统化地管理整个Skill生态”。这也是为什么我们必须强调分发层级这个概念。

在小型团队或项目初期，将Skill直接存放在代码仓库的 .claude/skills 目录下可能就足够了。但是，当Skill数量急剧增加、需要跨团队共享复用时，就必须考虑向插件化、内部市场（Marketplace）、企业级统一托管平台等更高级的分发模式演进。原因很直接：

并非每一个Skill都值得默认加载到每一个会话的上下文中。

每增加一个默认加载的Skill，就意味着多一份潜在的触发判断开销和上下文令牌（Token）占用成本。因此，组织级的Skill落地必然会走向以下两件事：

第一，实施分层分发策略。

项目专属Skill：仅存放在特定项目仓库内，供该项目成员使用。
跨项目复用Skill：打包为插件（Plugin），供有需要的团队订阅安装。
组织通用Skill：经过严格评审后，纳入企业级的统一技能目录，作为基础设施提供。

第二，建立技能准入门槛与评审机制。

不能允许任何人随意编写一个Skill就直接发布给全体员工使用。需要建立一套流程，包括：内部试用期、效果评估、安全与合规评审、代码/脚本审查，然后才决定是否允许其进入更广泛的分发渠道。

本质上，Skill在组织级语境下，已经转变为：一种需要被严格治理、持续维护、并作为资产进行管理的内部能力组件。

当然，如果是纯粹个人使用，可以相对随意，但通常个人场景下的Skill库规模有限，难以遇到复杂的治理问题。

根据过往经验，有一类Skill需要特别强调并单独处理，那就是高风险Skill。

例如涉及生产环境部署、删除关键资源、修改核心配置、执行高权限运维命令等能力。这类Skill绝不能按照普通Skill的方式来处理。至少，必须确保能够明确追踪是谁在什么时间、以何种方式触发了它，以及如果出现问题该如何界定责任和进行回滚。

技能的可观测性与持续迭代

只要是涉及AI的系统化项目，就一定离不开可观测性。目前许多团队在开发和使用Skill时，仍停留在一种相对原始的状态：

编写出一个Skill。
部分成员试用后感觉“还行”。
然后就将其搁置，缺乏持续优化。

然而，Skill一旦缺乏有效的度量与观测，就会出现三个严重问题：

你无法知道这个Skill是否真的被需要和使用。
你无法判断它是否在正确的场景下被触发，是否存在乱触发或漏触发。
你无法量化评估它到底为团队带来了多少效率提升或成本节约，即投资回报率（ROI）不清晰。

那么，应该如何解决呢？原文提供了一个非常实用的思路：利用Hook机制，特别是PreToolUse（工具使用前）这类钩子，对Skill的调用情况进行埋点记录。

通过收集这些埋点数据，你可以分析出：

哪些Skill被频繁调用（热门技能，价值高）。
哪些Skill几乎无人问津（可能设计不佳，或需求不明确，可考虑下线）。
哪些Skill触发后经常执行失败（需要排查是技能设计问题还是外部依赖问题）。
哪些Skill可能存在“过触发”（即在很多不相关的场景下被错误调用，需要优化其description或触发逻辑）。

从技术实现角度看，这种埋点并不复杂，但在工程层面需要进行系统化设计。如果只关注最核心的几个度量指标，建议优先跟踪以下三项：

触发准确率。 在应该触发该Skill的场景下，它是否被成功触发（召回率）？
误触发率。 在不应该触发该Skill的场景下，它是否被错误触发（精确率）？
任务成功率。 在该Skill被触发并执行后，最终是否成功完成了预定任务（可用性）？

拥有了这三个基础指标，Skill的优化迭代才真正具备了数据驱动的依据。否则，所谓的“优化”大多只能依赖主观感觉和猜测。

最后，从团队或组织的完整生命周期视角来看，Skill体系的健康运转其实构成一个闭环：

分类 → 设计 → 分发 → 度量 → 迭代

前面的步骤（分类、设计、分发）解决的是技能能否被创造出来并部署到位的问题；而最后的度量与迭代步骤，解决的则是：它能否在组织中持续发挥作用，并随着需求和环境的变化而不断进化、保持生命力。

总结

首先，衷心感谢 Thariq 分享的这篇关于Skills的深度文章。它让我个人对于Skills的认知变得更加系统化，尤其是其中关于技能分类的部分极具借鉴价值。其他如可观测性的论述，也再次印证了我们在此领域实践方向的正确性。

如果将这篇文章的核心思想压缩为一句话，那便是：

Skill不是更长的提示词，而是一种用于承载和封装组织工作流的新型工程化单元。

它内部包含的，远不止是操作说明文字，更是一个完整的工具箱，涵盖：

背景知识（references）。
输出模板（assets）。
执行脚本（scripts）。
安全约束与审计（hooks）。
效果度量方式（埋点与指标）。

因此，Skill本质上是一套优秀的工程解决方案。它并不试图改变底层AI模型的能力，而是提供了一种方法：将人类积累的经验、固化的流程以及可靠的执行方式，系统地迁移并集成到AI Agent的生态体系之中。

这也是为什么我始终强调，对于Agent而言，真正的核心能力不只在于记忆，更在于Skills。

记忆系统解决了Agent“知道什么”，使其在对话中不至于显得无知。而Skills系统解决的则是：当遇到具体任务时，应该“按照什么方法、以何种步骤”去执行，并且力求每次都做得正确、可靠。

好了，本文篇幅已经很长，就不再赘述了。希望以上的解析能对大家深入理解和应用AI Agent的Skills系统有所帮助。