用Claude/Cursor Skill封装业务流程：告别AI Agent碎片化，开启“入职手册”时代

Sam Altman曾指出一个普遍现象：当前许多团队构建AI Agent的方式，就像在管理一群“初级员工”。你下达任务，他提交成果，但产出往往不达标，需要你反复进行质检、打回和拼接。表面上AI在工作，但管理、审核和修补的成本全都转移到了人类身上。

这并非真正的自动化，更像是 “返工自动化”。

Anthropic将这个问题剖析得更为直接：过去一年，AI应用行业的默认模式是为每一个业务需求“制造”一个独立的Agent。这种做法本质上是在用“复制粘贴”来扩展能力。这并非在沉淀资产，而是在堆积工程负债。

那么，正确的出路在哪里？Anthropic给出的答案是进行一次范式转换：

别再忙着“造人”了，试着为你那高智商的AI“员工”写一本“入职手册”吧。

旧模式（造人）：财务需要人就造一个“财务Agent”，法务需要人就造一个“法务Agent”。
新模式（教书）：保持一个高智商的通用Agent，根据不同的任务需求，为它分发相应的“入职手册”（Skills）。

这本“入职手册”，就是 Skill。

Skill 到底是什么？

一言以蔽之：Skill是给AI编写的“入职文档”。

想象一位新人入职第一天，你不会期望他无所不能。你会递给他一本手册，其中写明了公司的业务规则、标准作业程序（SOP）以及常见问题的处理方法。

Skill所承担的正是这个角色。

但这里必须强调：Skill绝不是“更长的提示词（Prompt）”，而是一种工程化的封装。 它包含了三个核心维度：

• 流程性（Process）：侧重于“如何做”而非“是什么”，将复杂的业务SOP拆解为Agent可以逐步执行的明确指令。
• 可组合（Composable）：如同乐高积木，同一个“数据分析Skill”既可以被财务流程调用，也可以用于销售预测流程。
• 可执行（Executable）：内部可以封装代码脚本。当涉及排序、精确计算等任务时，Agent不再依赖不稳定的自然语言推测，而是直接运行脚本来获得确定性的结果。

换句话说，Skill是为Agent打包好的、可组合、可版本控制、可执行的流程性知识包。

Skill 与你熟悉的概念有何区别？

为了更清晰地定位Skill，我们可以将其与其他常见概念进行对比：

概念	解决什么问题	类比
Prompt	单次对话的指令	口头吩咐一句话
Rules	IDE或系统级别的全局行为约束	公司员工守则
RAG	让AI检索外部知识库	让员工去资料室查资料
MCP	连接外部工具和数据源	给员工开通各种系统权限
Skill	定义具体的业务流程和操作规范	发放一本详细的岗位操作手册

理清MCP与Skill的关系至关重要——MCP解决“能连接什么”，Skill则解决“如何正确地做”。两者协同工作的公式是：

新业务能力 = MCP（工具链）+ Skill（流程链）

例如，制作一份客户流失分析报告。MCP负责从数据库拉取原始数据，而Skill则负责定义分析口径、套用报告模板、执行合规性检查等一系列流程。

没有 Skill，你会陷入哪些困境？

结合实践来看，当前企业应用AI普遍面临三大痛点：

1. 口口相传：一条规则修改五遍

设想一下，公司没有成文的员工手册，所有规矩都靠老员工口头传达。现在退款政策调整了，你需要找到5个部门的5个人逐一叮嘱。结果有人记住了新规，有人还在沿用旧例，最终给客户的答复互相矛盾。

这正是“一个需求造一个Agent”模式的写照。每个Agent都拥有独立的Prompt、工具链和权限，同一条业务规则需要在多个地方重复编写。当Agent数量达到几十个时，知识碎片化将变得极其严重。你并非在管理AI，而是在进行一场大型且低效的“传话游戏”。

2. 名校毕业生：聪明绝顶但不懂行规

你招聘了一位名校毕业生，他智商极高，逻辑推理能力一流。但让他做财务审计，他却不清楚公司的记账口径；让他处理客户退款，他不了解哪些特殊情况可以破例。他不是不聪明，只是没人教过他“这里的规矩”。

大模型也是如此——它们拥有强大的通用推理能力，但在具体的业务场景中，往往缺乏特定的处理口径、内部规则以及那些只有老员工才知道的业务“暗坑”，因此常常会犯一些令人啼笑皆非的低级错误。在商业世界里，最珍贵的并非“灵光一现”，而是“稳定且一致的高质量执行”。一个天才如果每次审计的标准都不同，对企业而言就是一场灾难。

3. 越叮嘱，越糊涂

既然新人不懂行，那就多交代几句？于是你开始往System Prompt里不断堆砌规则。这就像一个焦虑的领导，每天给新人发送数十条语音消息：第一条说“退款一律不超过30天”，第八十条又说“VIP客户可放宽至90天”。当新人听到第八十条时，早已忘记了第一条的内容。

这么做的后果有三：Token成本急剧飙升、模型响应速度变慢、过多的规则相互干扰，导致你根本无法追踪究竟是哪条指令引发了AI的误操作。Prompt本身并非知识管理工具，它无法承担如此沉重的职责。这种“想到什么就叮嘱什么”的模式，是一条注定走不通的死胡同。

Skill 的技术架构：它如何运行？

理解了Skill是什么，再来看看它在技术上是如何实现的。

文件结构：从“一段话”到“一套文件夹”

Skill不再仅仅是聊天对话框里的一段文本，而是存储在硬盘上、拥有标准化结构的目录：

skill-name/
├── SKILL.md          # 入口文件：技能名、描述、执行指南（SOP）
├── reference.md      # 参考资料：业务手册、政策文档
├── examples.md       # 使用示例
└── scripts/          # 可执行脚本
    ├── validate.py
    └── helper.sh

其中的核心是 SKILL.md 文件。它采用结构化的Markdown格式，明确定义了：

• 元数据：技能名称、描述、版本号。
• 执行指南：Agent调用此技能时必须遵循的步骤、边界条件、输入输出规范。

这种文件化结构的意义在于，它使得AI技能能够像代码库一样，被纳入Git工作流，实现版本控制、代码审查和一键回滚。Skill从此不再是对话框中易失的文本片段，而是可以像软件资产一样被工程化管理的实体。

渐进式披露：如何管理成千上万个Skill？

这是Skill架构中最精妙的工程设计——渐进式披露（Progressive Disclosure）。它完美解决了“规则越多，模型上下文越臃肿，性能越差”的Token膨胀问题。其核心思路是：并非一次性加载所有内容，而是分层、按需加载。

• 第一层：Agent启动时，仅加载所有Skill的名称和简要描述。这部分占用极少的Token，但足以让Agent知道自己“拥有哪些技能”。
• 第二层：当用户的需求与某个Skill匹配时，才加载该Skill对应的 SKILL.md 详细内容。
• 第三层：在执行具体操作步骤时，才会去读取相关的脚本和参考文档。

这套分层加载机制通常由Agent框架（如Cursor）自动处理。开发者只需按照规范编写 SKILL.md 的元数据和内容，框架便会在合适的时机加载合适的层级。结果是：你的技能库可以从10个轻松扩展到10000个，而Agent的上下文窗口永远不会被撑爆。

大脑与手的分工：确定性输出的保障

这里有一个关键的架构公式：Agent（大脑）+ Runtime（手）= 确定性输出。这是将灵活但不稳定的自然语言推理与稳定可靠的代码执行相结合的关键。

• Agent（模型）负责：理解人类需求、选择合适的Skill、并将执行结果以人类可理解的方式解释出来。
• Runtime（执行环境）负责：运行Python/JS脚本、进行精确数学计算、处理文件格式转换等“体力活”。

这意味着，当任务涉及计算、数据抓取等需要精确性的工作时，模型不再进行容易出错的自然语言推理，而是直接调用Runtime执行预定义的脚本。这从根本上治愈了AI“算错数”和“产生幻觉”的顽疾——既降低了错误成本，又提升了执行效率。

这套架构还带来了三大工程优势：

1. 可观测性：你能清晰地追踪Agent为何选择技能A而非技能B，脚本在哪个具体环节报错。
2. 可调优性：出现问题无需重写整个Agent，只需修改特定Skill的 SKILL.md 或脚本即可。
3. 权限治理：可以为不同部门开放不同的Skill文件夹权限。例如，财务部可以加载“审计Skill”，而市场部则无权访问。

简而言之，AI的落地应用不再是玄学般的“炼丹”或盲目地“调Prompt”，而是回归到严谨的软件工程范式——模块化、解耦、按需加载、确定性执行。

实战：使用 skill-creator 创建一个代码审查 Skill

理论讲了不少，现在我们来动手实践。在Cursor中，内置了一个 create-skill 技能，专门用于引导用户创建Skill。整个过程就像在与一位经验丰富的同事讨论如何撰写操作手册。

以下是一个完整的交互演示，目标是创建一个“代码审查”Skill。

阶段一：需求收集（Discovery）

你只需向AI陈述你的目标：

你：帮我创建一个用于团队内部MR/PR审查的代码审查Skill。

AI会通过提问来明确关键细节（也可能提供结构化的选择框）：

AI：

1. 这个Skill是个人使用（存放在 ~/.claude/skills/），还是团队共享（存放在 .claude/skills/）？
2. 你们的代码审查最关注哪些方面？（例如：安全性、性能、可维护性……）
3. 是否有现成的团队编码规范可供参考？
4. 对审查结果的输出格式有何偏好？

你的回答将帮助AI明确需求边界。

阶段二：设计（Design）

AI根据你的回答，起草Skill的骨架结构：

AI：我规划了如下的目录结构：

code-review/
├── SKILL.md          # 审查流程和规范
├── STANDARDS.md      # 团队编码标准（详细版）
└── examples.md       # 好/坏代码示例

Skill名称：code-review
触发场景：当用户提交代码审查请求、打开MR/PR，或明确说出“帮我review代码”时触发。
你觉得这个结构可以吗？

阶段三：生成（Implementation）

确认结构后，AI会直接生成文件。其中核心的 SKILL.md 文件内容大致如下：

---
name: code-review
description: Review code for quality, security, and maintainability following team standards. Use when reviewing pull requests, examining code changes, or when the user asks for a code review.
---

# 代码审查

## 审查流程

1.  阅读变更概览，理解改动意图
2.  按以下清单逐项检查
3.  输出审查报告

## 审查清单

-   [ ] 逻辑正确性：边界条件、异常路径是否覆盖
-   [ ] 安全性：SQL注入、XSS、敏感信息泄露
-   [ ] 可维护性：函数职责单一、命名清晰、注释充分
-   [ ] 性能：是否有明显的N+1查询、内存泄漏风险
-   [ ] 测试覆盖：改动是否有对应的单元测试

## 输出格式

-   🔴 **必须修改**：不改不能合并
-   🟡 **建议改进**：非阻塞性建议
-   🟢 **做得好**：值得肯定的地方

## 详细资料

-   团队编码标准详见 [STANDARDS.md](STANDARDS.md)
-   审查示例详见 [examples.md](examples.md)

阶段四：验证（Verification）

AI会自动执行多项检查：

• SKILL.md 文件是否控制在合理长度（如500行）以内。
• 描述是否包含了清晰的触发关键词。
• 术语使用是否前后一致。
• 文件引用深度是否只有一层（避免循环嵌套）。

全部通过后，这个Skill就可以投入使用了。

几条核心的编写原则

在使用skill-creator的过程中，有几条原则值得牢记：

1. 简洁是王道
AI本身已经足够聪明，你不需要教它“什么是代码审查”。你需要告诉它的是：你的团队标准是什么，你的特定流程是什么。避免写成教科书，要写成实用手册。

2. 贯彻渐进式披露
将核心指令放在 SKILL.md，将详细的参考资料、标准文档放在独立的文件中。确保Agent只在需要时才去读取它们。

3. 自由度需匹配任务的“脆弱”程度
根据任务对精确性的要求，灵活选择描述方式：

自由度	适用场景	举例
高（文字描述）	存在多种合理做法	代码审查的具体意见
中（模板/伪代码）	需要统一输出格式	报告生成、邮件撰写
低（具体脚本）	必须精确一致，不容有失	数据库迁移、财务计算

如何将 Skill 用起来？

个人使用

将创建好的Skill目录（例如 code-review/）放入 ~/.claude/skills/ 目录下，这样你在所有项目中都能自动调用它。

~/.claude/skills/
├── code-review/
│   └── SKILL.md
├── daily-summary/
│   └── SKILL.md
└── commit-message/
    └── SKILL.md

当你在Cursor中说“帮我review这段代码”时，Agent会自动匹配到 code-review 这个Skill，并严格按照你定义的流程执行。例如，你提交了一段数据库查询代码，AI的输出将会遵循你设定的清单和格式：

审查报告

🔴 必须修改

• getUserOrders() 存在N+1查询问题：在循环内逐条查询订单详情，建议改为JOIN一次性查出。
• 缺少SQL参数化，userId 直接拼接字符串，存在SQL注入风险。

🟡 建议改进

• 函数体超过80行，建议拆分为 fetchOrders() 和 formatResponse() 两个函数。
• 缺少对 pageSize 参数的上限校验，恶意请求可能导致内存溢出。

🟢 做得好

• 错误处理覆盖了数据库连接超时的场景。
• 返回值类型定义清晰。

在没有Skill时，AI的代码审查是“自由发挥”，每次的关注点和输出风格都可能不同。有了Skill之后，每次审查都遵循同一套标准流程，输出格式统一，结果高度可预期，极大提升了团队协作效率。

团队共享

将Skill目录放入项目的 .claude/skills/ 目录中，并随代码一起提交到Git仓库。

your-project/
├── .claude/
│   └── skills/
│       └── code-review/
│           ├── SKILL.md
│           └── STANDARDS.md
├── src/
└── ...

这样，团队任何成员克隆项目后，都能立即使用同一套标准化Skill。当退款规则更新时，你只需要修改一个文件，提交并推送，全团队即可同步生效。 再也无需逐个修改几十个不同Agent的Prompt了。

心态转变：从“寻找”到“创造”

这里有一个容易陷入的心态陷阱需要注意。

与MCP（Model Context Protocol）不同——社区中存在大量现成的工具插件可供安装——Skill天然更具“私有性”。它封装的是你独有的业务流程、团队内部标准以及领域特定经验，这些几乎不可能存在通用版本。

因此，请不要将时间浪费在“去哪里找一个现成的Skill”上。正确的做法是：当你发现自己正在反复向AI解释同一套操作流程时，就应该停下来思考——这个过程能否被流程化？如果可以，那就立即动手创建一个Skill。

Skill不是用来“下载使用”的，而是需要你从日常实践中“沉淀提炼”的。每一次你将口头的、隐性的经验转化为一份结构化的 SKILL.md 文件，你就是在将一次性的对话成本，转化为一份可长期复用、不断增值的数字资产。

展望未来：Skill 的深远意义

Skill的意义远不止于“更好地管理Prompt”。它可能正在拉开下一阶段竞争的序幕。

真正的差距不在模型，而在“手册”

底层大模型会变得越来越通用、越来越强大。当所有人使用的都是相同或相近的模型时，企业间的差距将体现在哪里？

在于你沉淀了多少本高质量的“数字入职手册”。

那些隐藏在老员工脑海中的“口头经验”、散落在各处文档里的SOP、每次项目启动都要重新解释一遍的业务规则……过去，这些“隐性知识”要么流失在口口相传中，要么淹没在杂乱无章的Prompt副本里。一旦它们被系统地封装成Skill，就变成了可复用、可版本控制、可分发的标准化资产。

回到“入职手册”的比喻：一家公司的新员工上手速度快慢，不取决于招聘来的人有多聪明，而取决于公司是否拥有一套成熟、高效的培训体系。对于AI而言，道理相通——模型的“智商”是基础模型厂商提供的，但“操作手册”的质量与深度，却是由你自己积累和定义的。

理性看待：Skill 并非万能

当然，我们也不应神化Skill，必须认清它的能力边界：

第一，手册再好，也需“大脑”够用。 Skill只是“操作指南”，而理解复杂需求、处理意外情况、进行临场判断，依然依赖于底层模型本身的推理能力。如果基础模型的“IQ”不足，给予再详尽的手册也无济于事。

第二，Skill 能“做对事”，也能“做错事”。 普通的Prompt出错，最多导致回答不准确。但Skill中如果包含了可执行脚本，一旦出错就可能导致真实损失——算错财务数据、误发重要邮件、误删数据库表。因此，Skill上线前必须像代码一样进行严格的同行评审；对谁能使用哪些Skill必须进行精细的权限控制；所有执行记录必须完整、可追溯。一句话：请像管理“生产环境插件”一样管理Skill，而非像对待普通文本文档那样随意。

总结

让我们回到开头Sam Altman指出的困境——你以为在推进自动化，实则是在管理一群令人头疼的“初级员工”。

Anthropic提出的Skill架构指明了一条出路：停止为每一个琐碎任务“制造”一个独立的Agent，转而将核心的业务逻辑从Agent中抽离出来，封装成可自由组合、可重复使用的标准化资产。

Skill的本质，是做对三件事：

1. 将碎片化、隐性的经验，封装为标准化、显性的知识包。
2. 将不稳定的自然语言推理，与稳定的代码确定性执行相结合。
3. 将对“AI员工”的复杂管理，降维为对“操作手册”的清晰管理。

当下的行动指南非常明确：

1. 停止制造碎片化、功能重复的Agent。
2. 开始梳理内部高频、重要的SOP，并将它们编写成标准的 SKILL.md 文件。
3. 引入工程化管理，使用Git进行版本控制，逐步为团队构建统一、强大的技能底座。

最后，用三句话作为收尾：

不要盲目追求Agent的数量，要精心打磨技能资产的密度与质量。
Skill很可能正在开启AI应用的“App Store”时刻，因为它极大地丰富了高质量、可复用的供给。
当底层模型日趋同质化，对知识的组织、封装与管理能力，将成为新的核心竞争力。

参考资料

• Anthropic关于Skill的官方介绍与技术演示：https://www.youtube.com/watch?v=xeoWgfkxADI&t=19s

---

本文探讨的AI Skill工程化实践，与云栈社区中开发者们关注的自动化流程与知识沉淀主题高度契合。如何将团队经验转化为可复用的数字资产，是提升研发效能的关键，欢迎在社区相关板块深入交流。