Don't Build Agents. Build Skills.

发表信息: by

Don't Build Agents. Build Skills.

一个让 AI 真正拥有你专业知识的新范式

AI 很聪明，但它不懂"我们"

你有没有遇到过这种情况？

你让 Cursor 帮你写代码，结果它写出来的东西，完全不符合团队的规范。比如：

  • 数据库字段命名，我们用的是 created_at，它给你整个 createdAt
  • SQL 查询，我们明确说了不能用 SELECT *，它上来就给你来一句 SELECT *
  • 代码风格，我们有自己的一套，但它压根不知道

然后你跟它说："我们有规范，按规范来。"你还得告诉它 SQL 怎么写、权限校验是放 Handler 还是 Service、项目结构长什么样、model 里的 do 和 dto 包分别放什么……巴拉巴拉说了一大堆。

它说："好的，明白了。"

这一次表现还不错。但是——当你接了个新需求，甚至就是新开了个对话窗口，开始下一个任务的时候，它又忘了。又不知道该怎么写才能符合你的要求。然后你又得不厌其烦地跟它沟通一遍。每个人、每件事，都得这么来一轮。

这种感觉，像不像在带一个实习生？聪明是聪明，但你得反复教。而且更炸裂的是——它每天来上班之前，都会把自己的记忆清空。

这个问题往深了想，其实挺严重的：

对个人来说——就是效率损耗。你本来想让 AI 帮你省时间，结果你花了大量时间在"教育"它。当然话说回来，你花两个小时教它，它能帮你干四个小时的活，好像也值。所以你才愿意不厌其烦地跟它解释。但这事儿是违反程序员直觉的——按理说，一件事如果重复发生了三次，程序员就会想办法把它抽象出来、流程化、自动化，对吧？

对团队来说——知识没法沉淀。张三教了 Cursor 一遍规范，李四来了又得教一遍。每个人都在重复劳动。而且每个人的知识都成了自己的"护城河"，对个人来说可能是好事，但对团队来说可不是什么好事。

天才 vs 专家

这就是今天 Agent 的悖论：它们拥有超强的通用智能，却缺乏专业工作所需的程序性知识。

打个比方。它像什么呢？它像一个智商 300 的数学天才。

你让它帮你报税，它可以从第一性原理给你推导出整套税法。但问题是——过程很慢、结果不稳定，而且它完全不懂你在这个社会摸爬滚打这么多年，踩了多少坑、积累了多少经验。

而你真正需要的是什么？是一个干了多年的税务专家——他有成熟的流程、深厚的领域知识，能给你可靠、高效、一致的输出。

对于关键性的任务，我们需要的是懂行的专家，而不是刚入社会的天才。

那问题来了：怎么把一个"天才"变成"专家"？

旧范式：一个领域，一个 Agent

为了让 AI 能稳定地、确定性地干好一件事情，过去业界的思路是什么？

就是——一个领域，造一个专门的 Agent。财务有财务的 Agent，HR 有 HR 的 Agent。每个 Agent 都有自己的 prompt、自己的工具、自己的配置。

这种模式有三个致命问题：

  1. 不可扩展：每增加一个领域，就要从头再建一套
  2. 很脆弱：改一个地方，可能影响其他地方
  3. 知识无法共享：金融 Agent 学到的东西，编码 Agent 用不上

你想想看，我们有那么多领域，每个领域都搞一个 Agent，这成本得多高啊。

新洞察：一个通用 Agent + 可组合的专业知识

后来大家发现一个事儿：与其给每个领域造一个专门的工具，不如让一个通用的 Agent，通过最基础的能力——读文件、写文件、跑命令——去完成几乎所有的数字化任务。不管是 API 的调用，还是数据分析，还是别的什么，都可以干。

核心的脚手架可以薄到什么程度呢？就只有 Bash 和文件系统。

这就是为什么 Claude Code、Cursor 这些工具这么强大——它们不是给每个场景写死逻辑，而是让 AI 用代码去解决问题。

但是！通用能力是有了，专业知识怎么办？

我们团队的规范、我们公司的 SOP、我们组的最佳实践——这些东西，AI 它不知道啊。

"啊哈"时刻

假如有这样一个东西：

  • 你把你的经验、规范、流程写下来
  • AI 需要的时候，自动加载进去
  • 你写一次，整个团队都能用
  • 而且你还可以不断地迭代这些经验，让 AI 的产出更符合预期

是不是就把刚才说的那些问题全解决了？

这个东西，就叫 Skills。

解决方案：Agent Skills

Skills 是什么？

说白了，就是文件夹加 Markdown。

我知道这听起来有点反高潮——啊？就这？但这种简单是刻意设计的。

一个 Skill，本质上就是一个组织好的文件集合，给 Agent 打包一套可组合的程序性知识。里面可以有什么呢？

  1. 必选的指令文件（SKILL.md）——告诉 AI 这套技能是干嘛的、什么时候该用、具体怎么做
  2. 可选的可执行脚本——AI 可以直接调用的工具
  3. 模板、代码库、资源文件——各种辅助材料

一个最简单的 Skill 长这样：

my-skill/
└── SKILL.md

---
name: sql-standards
description: 团队 SQL 编写规范，写查询时使用
---

# SQL 编写规范

## 命名规则
- 表名：小写 + 下划线，如 user_orders
- 字段名：小写 + 下划线，如 created_at

## 查询规范
- 禁止 SELECT *
- 必须指定字段

会写 Markdown，就会写 Skill。

这不是工程师专属的能力。产品经理能写、运营能写、财务法务都能写。门槛就这么低。

更多实际的 Skill 示例

上面那个 SQL 规范是最简单的情况——一个纯文档的 Skill。但 Skill 可以做得更丰富。下面再看两个例子：

示例一：代码审查 Skill（纯文档型）

code-review/
└── SKILL.md

---
name: code-review
description: 团队代码审查标准，review 代码或提交 PR 时使用
---

# 代码审查规范

## 必须检查项
- [ ] 函数不超过 50 行，超过则拆分
- [ ] 错误处理：不允许空 catch，必须记录日志或上抛
- [ ] API 接口必须有入参校验（使用 validator 库）
- [ ] 数据库操作必须在 Service 层，Controller 层禁止直接操作 DB
- [ ] 敏感信息（密码、token）禁止硬编码，必须走配置中心

## 命名规范
- 变量/函数：camelCase
- 类名：PascalCase
- 常量：UPPER_SNAKE_CASE
- 文件名：kebab-case

## PR 描述模板
每个 PR 必须包含：
1. **改了什么**：一句话概括
2. **为什么改**：背景和动机
3. **怎么测的**：测试方法和结果
4. **影响范围**：涉及哪些模块

示例二：部署发布 Skill（文档 + 脚本型）

deploy/
├── SKILL.md
└── scripts/
    └── pre-deploy-check.sh

---
name: deploy-workflow
description: 生产环境部署流程和检查清单，发布上线时使用
---

# 部署发布流程

## 发布前检查
运行 `scripts/pre-deploy-check.sh` 执行自动化检查。

## 手动检查清单
- [ ] 所有 CI 流水线通过
- [ ] 数据库变更已提前执行并验证
- [ ] 配置项已在配置中心更新
- [ ] 回滚方案已确认

## 发布步骤
1. 合并 PR 到 release 分支
2. 触发构建流水线
3. 灰度 10% 流量，观察 15 分钟
4. 无异常则全量发布

## 回滚流程
如果发现问题，执行以下步骤：
1. 在发布平台点击"回滚"
2. 确认回滚版本号
3. 通知相关人员

#!/bin/bash
# scripts/pre-deploy-check.sh
# AI 可以读取、理解、甚至修改这个脚本

echo "🔍 执行发布前检查..."

# 检查是否有未提交的变更
if [ -n "$(git status --porcelain)" ]; then
    echo "❌ 存在未提交的变更，请先提交"
    exit 1
fi

# 检查测试是否通过
npm test || { echo "❌ 测试未通过"; exit 1; }

# 检查是否有已知的安全漏洞
npm audit --production || echo "⚠️ 存在安全漏洞，请评估"

echo "✅ 所有检查通过，可以发布"

注意这里的关键区别：pre-deploy-check.sh 不是黑盒 API，它是一个 AI 能读、能懂、能改的普通脚本。如果团队的 CI 工具换了，或者检查项需要调整，AI 自己就能改。

怎么工作的？两个核心机制

机制一：渐进式披露

打个比方——让你去造火箭。你不知道怎么造啊，那你肯定得先去图书馆查点资料。

但你不会一进门就把整个图书馆的书全读完再去造火箭，对吧？你肯定是先看看书架上的书名和简介，找到你需要的那本，再打开仔细读。

Skills 也是这个逻辑：

  1. 一开始，Claude 只看到每个 Skill 的名字和描述（就是元数据）
  2. 这样它就能"感知"到有几百个 Skills 存在
  3. 只有当它判断"这个任务需要用到这个 Skill"的时候，才会把完整内容加载进来

这解决了一个很现实的问题：上下文窗口是有限的，你不可能把所有知识一股脑全塞给它。

结果：你可以配置几十上百个 Skills，不浪费 token。

机制二：脚本是可以改的工具

这个稍微有点抽象，打个比方就懂了。

传统的做法是什么？给 AI 接一堆 API 工具，比如"发邮件"、"查数据库"、"生成报表"。这些工具对 AI 来说就是个黑盒——它只知道"我调这个接口，传这几个参数，能得到一个结果"。至于里面是怎么实现的，它完全不知道。

这就像什么呢？就像你给了它一个遥控器，它只能按按钮。按钮好使的时候没问题，但万一按钮坏了，或者你想要个遥控器上没有的功能，它就傻眼了，只能干瞪眼。

Skill 里的脚本不一样。

Skill 里面放的脚本，就是普通的代码文件，Python 脚本、Shell 脚本都行。关键是——AI 能看到源代码。能看到，就能看懂。能看懂，就能改。

举个实际的例子。

比如你的 Skill 里有个脚本，专门用来生成周报。结果有一天你发现，这脚本里日期格式写错了，月和日反了。

如果是传统的 API 工具，AI 没辙，只能等你去改代码。

但如果是 Skill 里的脚本，AI 自己就能发现这个问题，顺手就给你改对了，然后继续干活。

再比如，这个脚本原来是给 MySQL 写的，但你们公司后来换成了 PostgreSQL。AI 可以自己读懂脚本逻辑，把里面的 SQL 语法改成 PostgreSQL 兼容的，不用你操心。

一句话总结：Skill 里的脚本，AI 既是使用者，也是维护者——工具不好使，它自己能修。

怎么用？零摩擦

三步：

  1. 创建一个文件夹，写好 SKILL.md
  2. 放到指定目录，比如 .claude/skills/
  3. 没有第三步了

就这么简单。Claude 会自动发现、自动判断、自动使用。

你不用跟它说"请使用 xxx skill"，不用手动触发，什么都不用管。它自己会判断：这个任务跟哪个 Skill 相关？需不需要加载？该怎么用？

这个设计很重要——零摩擦。 你不用改变任何工作习惯，就是多了一个文件夹而已。该怎么跟 AI 对话还怎么对话，Skill 在背后默默生效。

有没有 Skill，差别有多大？

光说概念可能还是有点抽象。我们用一个具体场景来看看：新人小王入职第一天，接到一个 CRUD 需求——给用户管理模块加一个"修改手机号"的接口。

没有 Skill 的世界

小王：帮我写一个修改用户手机号的接口

AI：好的，这是一个 REST API 接口：
    PUT /api/user/updatePhone
    - 直接在 Controller 里操作数据库
    - 用 SELECT * 查用户信息
    - 字段用 phoneNumber (camelCase)

小王：不对，我们的接口规范是用 POST 不用 PUT，路径要用 /api/v1/user/phone
AI：好的，已修改...

小王：数据库操作不能放 Controller，要放 Service 层
AI：明白了，已调整...

小王：字段命名要用 phone_number，不是 phoneNumber
AI：收到...

小王：还有，查询不能用 SELECT *，而且要加权限校验中间件
AI：好的好的...

（20 分钟过去了，反复纠正了 5 轮，终于写出符合规范的代码）
（第二天，小王开了新对话，又来一遍...）

有 Skill 的世界

团队已经沉淀了 api-standards、sql-standards、project-structure 三个 Skills。

小王：帮我写一个修改用户手机号的接口

AI：（自动加载了相关 Skills）
    好的，根据团队规范，我来实现这个接口：
    - POST /api/v1/user/phone
    - Controller 层只做参数校验和路由
    - Service 层处理业务逻辑和数据库操作
    - 查询指定字段：SELECT id, phone_number, updated_at FROM users
    - 已添加 auth 中间件做权限校验
    - Model 放在 do 包，DTO 放在 dto 包

（一次到位，3 分钟搞定）

同一个新人，同一个需求。差别就在于：有没有人把团队经验写成了 Skill。

Skills 带来什么？

1. 一致性

同一个 Skill，团队所有人用，输出风格统一。不会再出现"每个人教出来的 AI 不一样"的问题。

2. 可复用

写一次，到处用。可以 Git 版本控制，可以分享给其他团队，可以跨项目复用。

3. 非技术友好

不用写代码，会写文档就会写 Skill。财务、法务、招聘都能参与。事实上，已经有很多非技术人员在写 Skill 了——财务在写报销审批流程，法务在写合同审核规范，招聘在写面试评估标准。

4. 持续学习

这是最有价值的一点。Skills 为 AI 创造了一条持续学习的路径。

"我们不断看到 Claude 反复写同一个 Python 脚本… 于是我们让 Claude 把它保存到 Skill 里，作为给未来自己的工具。"

第 30 天的 Claude 会比第 1 天更强，因为它积累了你们团队的特定程序性知识。而且你还可以不断地迭代这些经验，发现问题就更新 Skill，越用越完善。

5. 组织级知识库：知识的复利效应

一个人创建的 Skill，能立即升级组织内所有 Agent 的能力。

想象一下这个场景：李涛是团队里的 MongoDB 专家，他把这么多年在 MongoDB 上摸爬滚打的经验写成了一个 Skill。从这一刻起，团队里每个人的 Agent，都具备了李涛级别的 MongoDB 能力。

新人入职，不用专门培训。只要这个新人用 AI Agent 加上李涛沉淀的 Skill 去做开发，他就不会写出不符合规范的代码，能少踩很多坑。

传统的知识管理是什么样的？写文档、做培训、靠老带新。效率很低，而且人一走，知识就跟着流失了。

有了 Skills 之后：

  • 知识被显式捕获——不在人脑子里，在文件里
  • 知识被自动共享——不用培训，AI 自动就用上了
  • 知识在持续进化——发现问题就更新 Skill，越用越完善

这不是玩具，是趋势

这不是我们自己在玩，整个行业都在往这个方向走。

  • Anthropic 已经把 Skills 作为开放标准发布（agentskills.io）
  • 主流平台都在跟进——Coco、OpenCode、CodeX、Cursor，都在支持
  • 大厂都在参与——Atlassian、Figma、Notion、Stripe 已发布官方 Skills
  • 非技术人员也在写 Skill——财务写报销流程、法务写合同审核、招聘写面试标准

我觉得这个东西经过时间沉淀之后，会像 MCP 一样，成为一个重要的技术方向。

AI 的应用层

如果你熟悉计算机历史，这个模式你一定见过：

  • Models = Processors：需要巨额投资，蕴含巨大潜力，但单独存在时用处有限
  • Agent Runtimes = Operating Systems：编排资源，提供核心能力，让处理器真正变得有用
  • Skills = Applications：这才是真正解决具体问题的那一层

Skills 就是 AI 的应用层。

处理器和操作系统会持续改进和商品化。真正稀缺的是编码了领域知识的高质量 Skills——你的工作流、你的定义、你的规范、你的组织习惯。

怎么开始？

作为开发者，今天就可以试着写一个最简单的 Skill。从哪开始？从你最常重复跟 AI 说的那句话开始。

比如说，你每次用 Cursor 写代码，第一句话都是"我们用的是 TypeScript 不是 JavaScript"——那就把这句话写下来，这就是一个 Skill。就这么简单，别想太复杂。

非技术人员：把你的工作流程写成文档，让技术同事帮你放到正确的位置。或者直接对话让 Claude 帮你创建 Skill。

管理者：挑一个小团队 pilot 两周，观察效果，再决定推广。

三步开始：

  1. 创建文件夹，写好 SKILL.md
  2. 放到指定目录（如 .claude/skills/）
  3. 没有第三步了，Claude 会自动发现和使用

写好 Skill 的最佳实践

Skill 写起来简单，但写好还是有讲究的。分享几条实践经验：

该做的

  • 职责单一：一个 Skill 只解决一类问题。sql-standards 就管 SQL，api-standards 就管接口，不要搞一个"万能规范大全"塞进去。越聚焦，AI 判断什么时候该加载就越准。
  • 描述写精准：description 是 AI 判断"要不要加载这个 Skill"的唯一依据。写"团队 SQL 编写规范，写查询时使用"比写"数据库相关"好得多。
  • 包含具体示例：不要只说"命名要规范"，要给出 user_orders（对）vs UserOrders（错）的对比。AI 从示例中学到的比从抽象规则中学到的多。
  • 持续迭代：发现 AI 产出不对？别只是手动改代码，顺手更新 Skill。这样下次就不会再犯同样的错。
  • 加入"为什么"：不只告诉 AI "禁止 SELECT *"，还告诉它为什么——"因为会导致全表扫描，影响性能"。理解原因后，AI 在遇到类似场景时能举一反三。

不该做的

  • 不要写太大：一个 Skill 超过 500 行，说明它该拆分了。太大的 Skill 浪费上下文窗口，而且 AI 可能只用到其中 10% 的内容。
  • 不要和 CLAUDE.md 重复：CLAUDE.md 放全局规则（每次都要遵守的），Skills 放按需加载的领域知识。如果你在两个地方都写了"禁止 SELECT *"，维护的时候容易不一致。
  • 不要假设 AI 知道上下文：写 Skill 的时候，假设读者对你的项目一无所知。要提供足够的背景信息，而不是"参考 wiki 第 3 页"。
  • 不要写了就不管：团队规范会演变，技术栈会升级。定期 review 你的 Skills 库，清理过时的内容，和你清理技术债一样重要。

Skills vs 其他方案

你可能已经在用 .cursorrules 或 CLAUDE.md，那 Skills 和它们到底有什么区别？什么场景该用什么？

方案 加载方式 适合场景 数量 可组合 可共享
.cursorrules 每次对话自动加载 Cursor 项目级全局规则 1 个文件 否 仅项目内
CLAUDE.md 每次对话自动加载 Claude Code 项目级全局规则 1 个文件 否 仅项目内
Skills 按需自动加载 领域知识、工作流、最佳实践 不限 是 跨项目、跨团队
RAG 检索触发 大规模文档库、知识库问答 不限 否 取决于实现
Fine-tuning 内置于模型 持久性风格/行为调整 N/A 否 需重新训练

一句话总结：

  • 全局规则（每次都要遵守的）→ 放 CLAUDE.md / .cursorrules
  • 领域知识（特定任务才用的）→ 写成 Skill
  • 海量文档（几百上千页的知识库）→ 用 RAG
  • 行为层面的调整（比如让模型说某种语言风格）→ 考虑 Fine-tuning

它们不是互斥的，是互补的。你可以在 CLAUDE.md 里写全局规则，同时用 Skills 管理几十个领域知识模块。

怎么衡量效果？

诚实说，这是个难题。

理想的指标当然是：效率提升了多少？采纳率多少？返工率降低了多少？但说实话，这些很难自动化统计。我也没想到什么特别好的办法，只有一些比较粗糙的想法：

  1. 统计 Skill 数量——看看团队沉淀了多少知识
  2. 统计使用次数——看看哪些 Skill 被高频使用
  3. 收集主观反馈——定期问问大家感觉怎么样

纯靠体感，确实不完美。但先跑起来再说，因为不管怎么看这件事，最终收益的是我们自己。而且 Anthropic 官方也说了，未来希望让 Agent 能够自己创建、编辑和评估 Skills，这方面的工具会越来越完善的。

FAQ

Q: Skills 和 MCP（Model Context Protocol）什么关系？

它们是互补的。MCP 是让 AI 连接外部工具和数据源的协议，解决的是"能力扩展"问题。Skills 解决的是"知识注入"问题——怎么把专业知识教给 AI。你可以在 Skill 里调用 MCP 工具，它们配合使用。

Q: 和 CLAUDE.md / .cursorrules 什么区别？

CLAUDE.md 是项目级的全局指令，每次对话都会加载。Skills 是按需加载的——只有 AI 判断任务相关时才会加载。这样更高效，也更模块化。你可以有几十个 Skills，但 CLAUDE.md 只有一个。

Q: 多个 Skills 冲突了怎么办？

目前需要人工协调，确保 Skills 之间不冲突。实践中建议：1）Skill 职责单一，不要太大；2）命名和描述写清楚，减少歧义；3）团队定期 review Skills 库。

Q: 会不会泄露公司数据？

Skills 是完全本地的，就是你项目里的文件夹。它不会上传到任何地方。你的 Skill 内容只会在本地被 Claude 读取，和你的代码一样安全。

结语

"Stop Rebuilding Agents. Start Composing Expertise."

我们正在收敛到一个通用的 Agent 架构。Skills 提供了缺失的一层：可组合、可共享的专业知识。

这个范式解锁了持续学习，让每个人都能教 Agent 新能力——只需要往文件夹里放东西。

会写 Markdown，就能教 AI。

资源链接