1. 先搞清楚Skills到底是个什么东西最近AI圈子里最热的词之一就是Skills尤其是Claude Agent Skills、Codex Skills这些概念出来之后整个Agent开发的方向又往前推了一大步。很多人看到这个词第一反应是“这不就是prompt模板吗”真不是。Skills是一套结构化的、可复用的能力封装它把提示词、工具调用、决策逻辑、甚至领域知识全部打包成一个独立模块让Agent在特定任务上表现得像“训练过一样”。我举个例子你就明白了。你用Claude写代码如果不加Skills每次对话你都得重新解释一遍“请按这种风格写、用这个技术栈、注意这些约束”。但如果装了一个“代码生成Skill”Agent会自动加载你定义好的规范、偏好、常用工具链甚至知道你习惯怎么组织目录结构你只需要说一句“帮我生成一个用户登录模块”它就能直接按你的风格干活。这东西解决了什么问题核心就三个上下文一致性、任务可复用、行为可编排。先说上下文一致性。普通对话式Agent有一个很大的问题——每次开新会话它就把之前的约定忘光了。你前面强调的“不要用any类型”“接口注释必须写清楚”新会话里它一概不知。Skills把这个痛点直接抹平了因为这些约定被固化成了Skill的一部分Agent每次加载都会自动带上。再说任务可复用。你花了一个小时调教出来的“代码审查流程”在没有Skills的体系下只对当前会话有效。有了Skills之后这个流程可以被保存、被分享、被团队其他人直接使用。别人加载同一个Skill就是同一套审查标准完全不需要重新调教。最后是行为可编排。这是Skills和MCP最大的区别所在。MCP解决的是“Agent怎么连外部系统”Skills解决的是“Agent怎么做特定任务”。MCP是工具Skills是方法论。一个Skill内部可以调用多个MCP工具也可以完全不依赖MCP靠纯逻辑和提示词完成任务。从架构层面看Skills是在Agent能力层做封装而不是在基础设施层做事。这个内容适合谁来学三类人。第一类是做AI应用开发的工程师你自己写Agent必须理解这个封装思路第二类是重度使用AI编程助手的开发者你掌握Skills之后相当于给这些工具装了外挂第三类是那些想做Agent技能生态、准备对外发布Skills的团队你需要系统的设计方法论。我个人的判断是Skills这套机制很可能就是Agent落地到具体业务场景的“最后一公里”因为它在表现形式上非常贴近真实的岗位能力——你不需要教一个人了解所有东西你只需要给他配一套岗位SOP他就能干活了。Skills就是Agent的SOP。2. 设计方法论好的Skill是怎么想出来的我研究了大量公开的Skills包括Claude官方文档里推荐的Agent Skills实践指南、GitHub上开源的skills集合、还有Codex生态里那些评分很高的技能包。看了几十个之后我总结出来一个真正好用的Skill绝不只是“一段prompt配几个工具”这么简单它背后有一套完整的设计逻辑而且这套东西是有方法论支撑的。2.1 能力边界的界定先想清楚“这个Skill到底该干什么”这步叫“能力边界界定”。Skill设计者最容易犯的错误就是贪大求全想一个Skill包打天下。比如说你想要一个“写文档的Skill”这个定位本身就是模糊的——是写API文档写用户手册写技术方案还是写会议纪要每一种文档的受众、结构、语言风格、评估标准完全不一样硬塞进一个Skill里只会让Agent在每个场景下都表现平庸。我在设计自己的Skills时有一个硬性约束一个Skill只解决一个任务域而且这个任务域要小到可以在一句话说清楚。比如“生成TypeScript项目README”“将用户反馈归类并生成产品需求摘要”这种粒度是合适的。如果一句话说不清楚或者需要加“如果……那么……”的限定就要考虑拆分。能力边界界定的另一个维度是“哪些事不该做”。好的Skill设计者会主动声明自己不管什么。比如一个“前端代码生成”的Skill明确说明它不负责后端接口设计不负责数据库建模只在拿到接口定义之后才能工作。这个声明写在SKILL.md的description字段里Agent会读它来决定何时触发这个Skill——不匹配就不加载反而提升了整体的调度效率。2.2 触发条件设计让Agent在正确的时机加载正确的技能Skill有一个很关键的属性就是description的写法它决定了Agent什么时候激活这个Skill。我见过太多人写description写得很敷衍比如“Used for writing code”这种描述根本没法让Agent做精确匹配。正确写法应该是包含触发词、适用场景、输入要求、输出约定相当于给Agent一个判断依据。“遵照Claude官方文档里对description的实践建议需要描述清楚‘什么时候用’和‘什么时候不用’并且提供具体的行为示例”这一点我自己实际测试下来的体会是——description写得好整个系统的准确率能提升一大截而且还能避免Agent把无关Skill加载进上下文里浪费token。2.3 渐进式披露别让信息一次全堆给Agent这里我要详细讲一下“渐进式披露”Progressive Disclosure这个概念因为这是Skills设计最核心、也是最容易被忽略的原理。所谓渐进式披露就是按照“描述 - 目录 - 文件清单 - 完成任务的详细指导”的优先级顺序在Agent执行任务时按需提供信息而不是把所有的步骤、细节、代码示例一次性全部填充到上下文中。为什么需要这么设计核心原因是从上下文的成本角度出发的。你现在用Claude或者Codex上下文窗口虽然是有限资源但也是按token计费的如果Agent只为了完成一个简单的“生成登录页”任务却因为加载了5万字的教学文档而消耗了10万token既浪费成本又容易导致Agent注意力被无关内容干扰。渐进式披露可以让Agent先以最小成本预览任务概况当它真正进入某个子步骤时才去读取那个子步骤对应的详细信息相当于分阶段加载把上下文预算花在刀刃上。我举个例子。假设你写了一个“前端项目脚手架生成Skill”完整版包含项目初始化、目录规范、组件库选型、状态管理方案、样式方案、代码风格。如果把这些全写到主文件里一次加载可能要用掉3万token。采用渐进式披露之后主文件里只放描述和各子任务的概要每个子任务单独一个文件Agent执行到某个子步骤时才通过读取文件的方式加载这部分细节整体消费可能只需要五千到一万token。Claude官方给出的SKILL.md结构中还建议在描述之后放一个“当遇到以下命名文件时使用”的指令让Agent能从命名的项目文件获取辅助决策信息同时指示Agent继续读取它认为有用的额外目录和文件。这一机制的价值在于把“判断该读什么”这件事下放给Agent让它自主决定信息获取的路径这也是为什么Skills不仅是一个静态配置它本质上是一套动态的、由Agent自主导航的知识系统。2.4 模板与少样本示例让Agent少走一点弯路除了明确的任务步骤之外Skill内部应当内置**“模板”和“少样本示例”**用具体例子把“预期输出”这个抽象概念具象化。这条经验是我们实测之后总结出来的。早期的Skills我们只写了规则不写示例Agent输出虽然符合基本规范但总差点意思——比如让它生成API接口文档字段说明总是写得不够到位示例值也经常编造。后来我们把“注释规则、格式模板、示例数据、错误处理约定”作为Skill的标准组成部分输出质量立刻上了一个台阶。Agent不需要自己“发挥创造力”去理解什么叫所谓的“规范写法”直接就有范例可循。这里有个关键点示例不是越多越好。少量、高质量、有代表性的示例比一堆泛泛的例子更有效。我通常的建议是每个输出类型给1到2个完整示例再给一些正反面对比不合格的例子和合格的例子这是空间效率最高的方案。3. 实操拆解开发一个Skill的完整流程理论知识说再多不如动手跑一遍。这一节我会从一个实际项目的角度完整走一遍开发、测试、分发一个Skill的流程。拿我最近做的一个“日志分析Skill”当案例这个Skill的定位是给Agent输入一段应用日志文本文件或目录它自动完成分类、错误提取、根因推断并输出分析报告。3.1 第一步搭建Skill目录结构一个标准的Agent Skill本质上就是一个目录里面包含一个SKILL.md主文件和其他辅助文件。它有统一的目录结构规范可以遵循大概长这样log-analysis-skill/ ├── SKILL.md ├── scripts/ │ ├── parse_logs.py │ └── extract_errors.py ├── references/ │ ├── common_error_patterns.md │ └── sample_logs.md └── assets/ └── report_template.md这个结构中SKILL.md是入口索引scripts放可执行脚本工具references放参考资料assets放模板。Agent会先读SKILL.md根据描述判断是否激活该Skill然后按需读取references或运行scripts。3.2 第二步编写SKILL.md主文件SKILL.md是Skill的灵魂它是Agent理解这个技能的第一入口。我按照Claude官方建议的“YAML frontmatter Markdown正文”格式来写。frontmatter里用name定义名称、description定义触发条件正文里写详细的执行步骤。关键的部分我贴一下我当时写的description写得比较详细确保Agent能精确匹配--- name: log-analysis description: - Analyze application log files to identify errors, anomalies, and root causes. Use when user provides a raw log file path, directory path, or pastes log content, and expects a structured analysis report, error categorization, failure root-cause inference, or>