Agent Skill 工程化实践：从 SKILL.md 到可复用的 AI 工作流

Hyman 2026/9/11 笔记实践总结SKILL

# 前言

Skill 不只是一个 Prompt 文件，而是一套可以被 Agent 自动发现、按需加载、重复执行、持续验证和版本化管理的“工作流能力”。

随着 Cursor、Claude Code、Codex、ChatGPT 等 AI 编程和 Agent 工具不断成熟，一个非常明显的趋势正在出现：

AI Agent 的竞争正在从“模型知道多少”，逐渐转向“Agent 能否稳定执行一套专业流程”。

例如：

写 Go 代码时必须遵循项目 DDD 分层规范
做数据库迁移时必须先备份、迁移、校验，再允许删除旧结构
做 Code Review 时必须按照固定维度检查
写技术文章时必须先分析资料、再组织结构、最后自检
发布服务时必须经过测试、构建、灰度、监控和回滚
开发前端页面时必须使用公司统一组件和设计规范

这些事情的问题并不是模型“不会”，而是：

每一次都重新告诉 AI 怎么做，成本高，而且容易漂移。

Skill 的价值，就是把这些反复出现的工作方式沉淀成一种可以复用的 Agent 能力。

Anthropic 当前的官方文档将 Skill 定义为可复用的、基于文件系统的专业知识、工作流和最佳实践；Claude 会根据 Skill 的 name/description 判断相关性，在需要时进一步读取 SKILL.md 和配套资源。

OpenAI 的官方介绍也将 Skill 描述为一种可复用、可共享的工作流，用于减少重复解释，让模型按照稳定的流程完成任务。

Cursor 则把 Skill 定义为一种便携、可版本控制、可渐进加载的 Agent 能力包。

所以，真正值得讨论的问题已经不是：

“Skill 是什么？”

而是：

怎样设计一个工程化、高可靠、可维护、跨 Agent 复用的 Skill？

# 1. Skill 到底是什么？

可以把 Skill 抽象成：

Skill = Trigger + Instructions + Resources + Tools + Validation

也就是：

触发条件
   ↓
执行规则
   ↓
标准流程
   ↓
参考资料 / 脚本 / 模板
   ↓
结果校验

1
2
3
4
5
6
7
8
9

与传统 Prompt 最大的区别在于，Skill 不是一次性的对话指令，而是一个可以长期复用的能力模块。

例如一个：code-review Skill，可以规定：

什么时候使用
    ↓
先分析整体结构
    ↓
再检查正确性
    ↓
再检查并发
    ↓
再检查性能
    ↓
再检查安全
    ↓
最后输出问题等级和修改建议

1
2
3
4
5
6
7
8
9
10
11
12
13

Agent 每次遇到 Code Review 场景，都可以复用这个流程。

因此可以把：

Prompt

理解成：

“这一次怎么做”

而：

Skill

更像：

“以后遇到这类事情，一律按照这套方法做”。

# 2. Skill 与 Prompt、Rule、Agent、MCP 的区别

实际工程中最容易混淆的是这几个概念。

# 2.1 Prompt

Prompt 主要解决：

一次任务

例如：

帮我 review 这个 Go 文件。

它通常只对当前请求有效。

# 2.2 Rule

Rule 更偏向：

长期约束

例如：

项目统一使用 Go 1.24 禁止使用 panic 所有 Repository 必须通过 interface 注入

Rule 更像：

“这个项目永远遵守什么规则”。

# 2.3 Skill

Skill 解决的是：一类任务怎么完成

例如：

Code Review
数据库迁移
发布服务
生成技术文章
分析生产事故

1
2
3
4
5

它描述的不只是规则，而是：

Input
  ↓
Process
  ↓
Output
  ↓
Validation

1
2
3
4
5
6
7

# 2.4 Agent

Agent 更高一层。

可以理解成：可以理解成：

Agent
 ├── Model
 ├── Tools
 ├── Rules
 ├── Skills
 ├── Memory
 └── Context

1
2
3
4
5
6
7

Skill 是 Agent 的专业能力模块之一。

# 2.5 MCP

MCP 解决的是：Agent 能做什么例如：

查询 GitHub
访问数据库
读取 Jira
操作 Kubernetes
调用内部 API

1
2
3
4
5

Skill 解决的是：

Agent 应该怎么做

因此两者可以组合：

Skill
   +
MCP Tools
   ↓
完整业务工作流

1
2
3
4
5

例如：

production-incident-response

Skill:
    定义故障处理流程

MCP:
    查询 Prometheus
    查询 Kubernetes
    查询日志
    查询 GitHub

1
2
3
4
5
6
7
8
9
10

这才是企业 Agent 真正有价值的形态。

# 3. 官方标准实际上在强调什么？

目前 Agent Skills 生态正在形成比较一致的设计原则。

Anthropic 官方要求每个 Skill 至少包含一个 SKILL.md，其中通过 YAML frontmatter 定义：

--- 
name: your-skill-name 
description: What this Skill does and when to use it 
---

1
2
3
4

其中：

name 必须明确
description 必须同时说明“做什么”和“什么时候使用”
Skill 目录可以进一步包含脚本、参考资料等资源。

Cursor 同样采用：

skill-name/
└── SKILL.md

1
2

并支持：

scripts/
references/
assets/

1
2
3

等配套资源。

OpenAI 的官方 Skill 指南也强调：

Name
Description
Workflow Instructions
Resources
Required Output
Final Checks

1
2
3
4
5
6

这实际上和你给出的 Superpowers 规范高度一致。

# 4. 为什么 SKILL.md 不应该写成一本书？

这是 Skill 最重要的设计原则之一。

很多人第一次写 Skill，会犯一个错误：

把所有自己知道的东西全部写进去。

例如：

## 什么是 Go

Go 是 Google 开发的一门编程语言……

## 什么是 Goroutine

Goroutine 是 Go 提供的轻量级并发执行单元……

## 什么是 Channel

Channel……

1
2
3
4
5
6
7
8
9
10
11

这通常是错误的。

因为 Agent 本身已经具备大量基础知识。

官方文档明确强调：

Context Window 是共享资源。

Skill 一旦被加载，其内容会和系统指令、历史对话、其他 Skill、用户任务共同竞争上下文空间。因此 Skill 应该只提供模型缺失的、真正有价值的上下文。

正确方式应该是：

## Go Project Rules

- Use Go 1.24.
- Repository implementations must be injected through interfaces.
- HTTP handlers must not directly access GORM.
- Domain layer must not import infrastructure packages.

1
2
3
4
5
6
7

而不是：

什么是 Go？
什么是 interface？
什么是 GORM？
什么是 DDD？

1
2
3
4

核心原则就是：

Skill 写规范，不写百科。

# 5. Skill 最重要的设计：描述必须帮助 Agent 发现它

很多 Skill 写得很好，但 Agent 根本不会使用。

问题往往不在 Instructions，而在：

description:

例如：

description: Code review helper.

太模糊。

Agent 很难判断什么时候应该调用。

更好的形式：

description:
Reviews Go code for correctness, concurrency safety, performance, error handling, API design, and project conventions. Use this skill when reviewing Go pull requests, commits, or source files.

1
2

也就是：

What
 + 
When

1
2
3

Anthropic 官方明确要求 description 同时描述 Skill 做什么以及什么时候使用，并建议使用第三人称描述。

例如：

description:  Reviews Go services for correctness, concurrency safety, performance, maintainability, and project conventions. Use when reviewing Go code, pull requests, commits, or architecture changes.

这个描述明显比：

description: Go review.

更容易被正确发现。

# 6. Skill 的目录设计

一个成熟 Skill 不应该只有一个巨大 Markdown。

# 7. 最佳实践一：核心流程必须写在 SKILL.md

你提供的 Superpowers 规范中有一个非常重要的设计：

TRIGGERS
CORE RULE
STANDARD PROCESS
SELF-CHECK LIST
COMMON EXCUSES
ANTI-PATTERNS

1
2
3
4
5
6

这是非常适合工程实践的一种 Skill 结构。

# 8. 最佳实践二：不要所有地方都使用绝对规则

这里需要对 Superpowers 的“绝对化语气”做一个工程化修正。

在真正的 Skill 设计中：

NO EXCEPTIONS

并不是所有地方都适合。

Anthropic 官方实际上强调：

Skill 指令应该根据任务的不确定性设置不同程度的自由度。

可以分为三种。

# 高自由度

适合：

代码 Review
架构分析
技术方案设计
故障分析

1
2
3
4

例如：

Analyze the architecture and identify the most important risks. Choose the most appropriate review strategy based on the codebase.

不要规定每一步都必须使用固定命令。

# 中自由度

适合：

生成报告
构建代码
生成 API

1
2
3

例如：

Use the project template and adapt it to the current service.

# 低自由度

适合：

数据库迁移
生产发布
安全操作
证书轮换
数据删除

1
2
3
4
5

例如：

Run: ./scripts/migrate.sh --verify Do not modify the command. Do not skip verification.

官方文档给出的原则非常清晰：

任务越危险、越脆弱、越要求一致性，指令自由度就越低。

所以真正好的 Skill 不是：

一律绝对化

而是：

根据风险决定自由度

# 9. 最佳实践三：渐进式加载

这是现代 Skill 非常重要的设计思想。

不要：

SKILL.md 
↓
5000 行

1
2
3

而应该：

SKILL.md
↓ 
判断需要什么
↓
references/ scripts/ examples/ 
↓
按需读取

1
2
3
4
5
6
7

例如：

SKILL.md

只有：

## Migration 

1. Read references/migration.md 
2. Execute scripts/backup.sh 
3. Execute scripts/migrate.sh 
4. Run verification

1
2
3
4
5
6

真正复杂的内容放：

references/migration.md

这就是：

Progressive Disclosure

Anthropic 官方明确说明，Skill 的 metadata 会优先用于发现，而完整 SKILL.md 在 Skill 相关时再读取，其他资源也应该按需读取，从而控制上下文成本。

Cursor 也明确把 Progressive Loading 作为 Skills 的核心特性之一。

# 10. 最佳实践四：不要把“业务决策”全部塞进脚本

例如：

scripts/
└── deploy.sh

1
2

非常适合：

机械执行

例如：

docker build
kubectl apply
go test
go vet

1
2
3
4

但是不应该把：

到底部署哪个环境？ 
为什么部署？ 
什么时候允许灰度？ 
是否应该回滚？

1
2
3
4

完全写死在脚本中。

更合理的职责划分：

SKILL.md
    ↓
业务决策
    ↓
调用脚本
    ↓
机械执行

1
2
3
4
5
6
7

即：

模型负责决策，脚本负责确定性执行。

这样 Skill 才容易维护。

# 11. 最佳实践五：Skill 必须有验收机制

Skill 和普通 Prompt 最大的一个区别就是：

它应该知道什么叫“完成”。

例如：

## SELF-CHECK LIST

[ ] All tests pass
[ ] No TODO remains
[ ] API compatibility verified
[ ] Error handling reviewed
[ ] Output matches required format

1
2
3
4
5
6
7

这一步非常重要。

因为：

执行完成

和：

任务正确完成

不是一个概念。

一个成熟 Skill 应该形成：

Input
 ↓
Plan
 ↓
Execute
 ↓
Verify
 ↓
Output

1
2
3
4
5
6
7
8
9

而不是：

Input
 ↓
Generate
 ↓
Done

1
2
3
4
5

# 12. 最佳实践六：把错误经验写成 Anti-Patterns

Superpowers 规范非常值得保留的一部分。

例如：

## ANTI-PATTERNS

- Writing production code before tests
- Querying the database directly from HTTP handlers
- Ignoring existing project abstractions
- Adding unrelated refactoring
- Optimizing before correctness is verified

1
2
3
4
5
6
7

这样做比单纯写：

请写高质量代码

有效得多。

因为模型不仅需要知道：

应该做什么

还需要知道：

不能做什么

最终形成：

Positive Rules
+
Negative Rules
=
Behavior Boundary

1
2
3
4
5

# 13. 最佳实践七：不要把 Skill 写成“万能 Skill”

这是非常常见的失败模式。

例如：

software-engineering/

里面包含：

Go
Java
React
Kubernetes
Docker
MySQL
Kafka
ES
DDD
AI
Code Review
DevOps
...

1
2
3
4
5
6
7
8
9
10
11
12
13

最后变成几万字。

这种设计的问题是：

边界不清
触发不准
上下文巨大
维护困难
版本难管理

更好的方式是：

go-backend-development/
java-backend-development/
react-development/
kubernetes-deployment/
database-migration/
code-review/
architecture-design/
technical-writing/

1
2
3
4
5
6
7
8

一个 Skill：

只解决一种相对稳定的任务类型。

# 14. Skill 的组织模型

在真实研发组织中，Skill 不适合简单划分成“四层”，更准确的方式是从 任务类型、专业领域和配套资源 三个方面组织。

# 1. Workflow Skill：一类事情怎么做

描述完整工作流程，例如：

code-review
database-migration
release-service
incident-response
technical-writing

1
2
3
4
5

核心是：

Input → Process → Output → Validation

# 2. Domain Skill：某个领域怎么做

描述专业领域的规则和最佳实践，例如：

go-development
kubernetes
mysql
react
ddd

1
2
3
4
5

Workflow 和 Domain 可以组合：

code-review + go-development
        ↓
Go Code Review

1
2
3

# 3. References / Tools：Skill 的配套能力

它们不是独立的“层”，而是 Skill 的支撑资源：

Skill
├── SKILL.md       # 流程、规则、决策
├── references/    # 专业知识、规范、文档
├── scripts/       # 确定性的脚本执行
├── examples/      # 示例
└── tests/         # 验证 Skill 是否有效

1
2
3
4
5
6

可以简单理解为：

Workflow 定义怎么做，Domain 定义应该遵循什么，References 提供知识，Tools 负责执行，Tests 负责验证。

因此，Skill 更适合被理解为一个可复用的 AI 能力单元，而不是严格的“四层架构”。

# 15. 一个生产级 Skill 示例

下面给出一个比较完整的 Go Code Review Skill。

go-code-review/
├── SKILL.md
├── references/
│   ├── concurrency.md
│   ├── performance.md
│   └── security.md
├── scripts/
│   ├── test.sh
│   └── staticcheck.sh
└── examples/
    └── review-example.md

1
2
3
4
5
6
7
8
9
10
11

SKILL.md：

---
name: go-code-review
description: Reviews Go code for correctness, concurrency safety, performance, security, maintainability, and project conventions. Use when reviewing Go source files, commits, pull requests, or architecture changes.
---

# Go Code Review
## TRIGGERS
Activate when:
- Reviewing Go source code
- Reviewing Go pull requests
- Reviewing Go commits
- Reviewing concurrency-sensitive changes

## CORE RULE - NON-NEGOTIABLE
Correctness MUST be verified before optimization.

## STANDARD PROCESS
1. Read the changed code and surrounding abstractions.
2. Identify the intended behavior.
3. Check correctness and error handling.
4. Check concurrency safety.
5. Check performance and resource usage.
6. Check security-sensitive behavior.
7. Check maintainability and project conventions.
8. Run available automated checks.
9. Rank findings by severity.

### Concurrency
Read `references/concurrency.md` when the change contains:
- goroutines
- channels
- mutexes
- atomics
- worker pools
- context cancellation

### Verification
Run:
./scripts/test.sh
./scripts/staticcheck.sh

Do not claim verification if the commands were not executed.

## OUTPUT
Each finding MUST contain:
- Severity
- Location
- Problem
- Why it matters
- Recommended fix

Prioritize:
- Critical
- High
- Medium
- Low

## SELF-CHECK LIST
[ ] Intended behavior is understood
[ ] Correctness is checked
[ ] Concurrency is checked
[ ] Performance is checked
[ ] Security is checked
[ ] Automated checks are executed when available
[ ] Findings are prioritized
[ ] No unsupported claims are made

## ANTI-PATTERNS
- Reviewing only the changed lines without surrounding context
- Optimizing before correctness analysis
- Reporting stylistic preferences as bugs
- Claiming tests passed without running them
- Rewriting unrelated code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73

这个版本有几个关键特点：

触发条件明确
+
核心原则明确
+
流程明确
+
按需加载参考资料
+
使用脚本进行确定性验证
+
输出结构固定
+
最终自检

1
2
3
4
5
6
7
8
9
10
11
12
13

这基本就是一个可以进入真实团队使用的 Skill。

# 16. Skill 的测试，比 Skill 本身更重要

很多人写 Skill 的过程是：

写 SKILL.md
↓
感觉很好
↓
结束

1
2
3
4
5

这是不够的。

真正工程化的方法应该是：

Skill
 ↓
Test Cases
 ↓
Agent Execution
 ↓
Compare Result
 ↓
Modify Skill
 ↓
Regression Test

1
2
3
4
5
6
7
8
9
10
11

例如：

tests/
├── should-detect-concurrency.md
├── should-run-tests.md
├── should-not-overreview-style.md
└── should-prioritize-critical.md

1
2
3
4
5

测试：

输入：

这个 Go worker pool 有 data race。

期望：

必须识别并发问题
必须将其判定为高优先级问题
不能只提出代码风格建议

1
2
3
4
5
6
7
8
9

然后不断加入真实失败案例。

这就是：

Skill Regression Testing

Anthropic 官方同样强调 Skill 应该通过真实使用进行测试，而且不同模型可能需要不同程度的指导，因此实际使用哪些模型，就应该用哪些模型进行验证。

# 17. Skill 应该像代码一样管理

成熟团队不应该把 Skill 当成：

某个人电脑里的一个 Markdown

而应该放入 Git。

例如：

ai-skills/
├── skills/
│   ├── go-code-review/
│   ├── database-migration/
│   ├── kubernetes-deployment/
│   └── technical-writing/
├── shared/
├── tests/
└── README.md

1
2
3
4
5
6
7
8
9

每次变更：

PR
 ↓
Review
 ↓
Regression Tests
 ↓
Merge
 ↓
Release

1
2
3
4
5
6
7
8
9

例如：

go-code-review v1.3.0

这样 Skill 才真正具备：

版本
历史
Review
回滚
复用

1
2
3
4
5

Anthropic 的 Skills API 本身也已经将 Skill 与版本管理结合起来，API 提供 Skill 的创建、查询、删除以及 Skill Version 管理能力。

# 18. 跨平台兼容：不要过度绑定某一个 Agent

现在比较值得关注的一点是：

Agent Skills 正在形成一种跨 Agent 的目录与文件约定。

Cursor 官方已经直接将 Agent Skills 描述为开放标准，并兼容 .claude/skills/、.codex/skills/ 等目录。

因此推荐项目采用：

.agents/
└── skills/

1
2

作为通用目录，同时根据具体 Agent 做兼容：

.claude/skills/
.codex/skills/
.cursor/skills/
.agents/skills/

1
2
3
4

一个核心 Skill 尽量保持：

纯 Markdown
+
Shell/Python/Go 脚本
+
参考文件

1
2
3
4
5

避免：

强绑定某个 Agent 的特殊语法

这样可以最大化复用。

# 19. Skill 安全问题不能忽视

Skill 本质上是：

Agent 可执行的指令。

因此它实际上属于 Agent 的信任边界。

尤其当 Skill 能访问：

filesystem
shell
web
database
cloud
production

1
2
3
4
5
6

风险会明显增加。

Anthropic 官方明确提醒，Skills 应当像安装软件一样被信任；恶意或被篡改的 Skill 可能通过工具调用造成数据泄露或其他危险操作。对于来自 GitHub 的 Repository Skills，也必须信任相应代码仓库，因为提交者可能修改 Skill 的行为。

所以生产环境至少应该做到：

Skill Source
   ↓
Code Review
   ↓
Security Review
   ↓
Version Pinning
   ↓
Least Privilege
   ↓
Runtime Sandbox

1
2
3
4
5
6
7
8
9
10
11

尤其不要默认给所有 Skill：

生产数据库
+
云账号
+
全部文件系统
+
Shell root

1
2
3
4
5
6
7

权限。

# 20. Skill 与 MCP 的最佳组合

未来真正强大的 Agent，应该是：

           Agent
             │
       ┌─────┴─────┐
       │           │
     Skill         MCP
       │           │
  Workflow       Tools
       │           │
       └─────┬─────┘
             ↓
        Business Result

1
2
3
4
5
6
7
8
9
10
11

例如：

production-incident-response

Skill：

1. 收集故障信息
2. 判断影响范围
3. 查询指标
4. 查询日志
5. 检查最近部署
6. 建立假设
7. 验证假设
8. 输出修复方案
9. 判断是否回滚
10. 输出事故报告

1
2
3
4
5
6
7
8
9
10

MCP：

Prometheus
Grafana
Kubernetes
Loki
GitHub
Jira

1
2
3
4
5
6

最终 Agent 就不只是：

“回答问题”

而是：

按照企业规定的流程，使用企业工具完成工作。

这也是 Skill 真正的价值所在。

# 21. Superpowers 规范应该如何落地？

你给出的 Superpowers 规范：

TRIGGERS
CORE RULE
STANDARD PROCESS
SELF-CHECK LIST
COMMON EXCUSES
ANTI-PATTERNS
PLATFORM NOTES
SEE ALSO

1
2
3
4
5
6
7
8

我认为非常适合作为一套：

企业 Skill Authoring Convention

但可以进一步演进成下面这个标准。

# Skill Name

## TRIGGERS

明确什么时候触发。

## CORE RULE

最重要的不可违背规则。

## STANDARD PROCESS

标准工作流。

## DECISION RULES

描述什么情况下选择什么策略。

## RESOURCES

说明什么时候读取哪些 references。

## TOOLS

说明什么时候调用哪些 scripts / tools。

## OUTPUT

规定最终输出结构。

## SELF-CHECK LIST

完成前验证。

## COMMON EXCUSES

防止 Agent 绕过关键流程。

## ANTI-PATTERNS

禁止行为。

## PLATFORM NOTES

平台兼容说明。

## SEE ALSO

关联 Skill。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

这里增加了两个非常重要的部分：

DECISION RULES
RESOURCES

1
2

它们可以明显提高 Skill 的工程化程度。

# 22. 一个非常重要的原则：Skill ≠ 越详细越好

最终可以总结为：

Bad Skill
    ↓
Everything is written
    ↓
Huge Context
    ↓
Low Signal
    ↓
Poor Execution

1
2
3
4
5
6
7
8
9

而好的 Skill：

Skill Metadata
    ↓
Fast Discovery
    ↓
Minimal Core Instructions
    ↓
Progressive Loading
    ↓
Deterministic Tools
    ↓
Verification
    ↓
Stable Output

1
2
3
4
5
6
7
8
9
10
11
12
13

所以真正好的 Skill 应该满足：

短、准、可执行、可验证。

这和传统文档完全不同。

# 23. 我推荐的一套企业级 Skill 标准

如果团队准备真正建立自己的 AI Engineering Skill Repository，可以直接采用下面这套规范。

skills/
├── engineering/
│   ├── go-development/
│   ├── java-development/
│   ├── react-development/
│   └── architecture-design/
│
├── quality/
│   ├── code-review/
│   ├── security-review/
│   └── performance-review/
│
├── devops/
│   ├── kubernetes-deployment/
│   ├── database-migration/
│   └── incident-response/
│
├── documentation/
│   ├── technical-writing/
│   ├── api-documentation/
│   └── architecture-documentation/
│
└── ai/
    ├── rag-development/
    ├── agent-development/
    └── mcp-development/

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

每个 Skill：

SKILL.md
scripts/
references/
examples/
tests/

1
2
3
4
5

整个仓库：

Git
 ↓
PR
 ↓
Skill Review
 ↓
Automated Tests
 ↓
Version
 ↓
Distribution

1
2
3
4
5
6
7
8
9
10
11

这样 Skill 才从：

Prompt 技巧

真正升级为：

AI Engineering Infrastructure

# 24. 最终结论

Skill 最值得理解的，并不是：

“又多了一个 Markdown 文件”

而是：

Skill 正在成为 Agent 的“专业工作流层”。

传统软件：

代码
 ↓
函数
 ↓
模块
 ↓
服务

1
2
3
4
5
6
7

Agent Software：

Model
 ↓
Tool
 ↓
Skill
 ↓
Workflow
 ↓
Business Result

1
2
3
4
5
6
7
8
9

未来真正有价值的企业 AI 能力，很可能不是简单地给员工一个“大模型”，而是把企业中大量隐性的专家经验沉淀成：

Skills

例如：

一个优秀架构师怎么设计系统
一个优秀 DBA 怎么执行迁移
一个优秀 SRE 怎么处理事故
一个优秀工程师怎么做 Code Review
一个优秀产品经理怎么分析需求
一个优秀技术作者怎么写文章

1
2
3
4
5
6

这些经验过去存在于：

人的脑子
+
Wiki
+
代码规范
+
口头经验

1
2
3
4
5
6
7

而 Skill 的目标，是把它们转换成：

机器可以发现
+
机器可以执行
+
机器可以验证
+
机器可以版本化
+
团队可以共享

1
2
3
4
5
6
7
8
9

这才是 Skill 真正的工程价值。

# 一句话总结

Prompt 是“告诉 AI 做什么”，Rule 是“限制 AI 不能做什么”，Tool/MCP 是“给 AI 什么能力”，而 Skill 是“告诉 AI 面对一类任务，应该按照什么专业流程把事情做对”。

从这个角度看，SKILL.md 并不是 Prompt 的升级版，而是 Agent Workflow 的声明式工程载体。

# 参考资料

Anthropic Agent Skills Overview：Skill 的定义、目录结构、发现机制和生命周期。
Anthropic Skill Authoring Best Practices：上下文成本、Skill 简洁性、自由度、命名、描述和模型测试。
Anthropic Skills API：Skill 与版本管理能力。
Anthropic 官方 Skills Repository：生产级 Skill 的目录与实现参考。
OpenAI Academy — Using Skills：Skill、SKILL.md、工作流与复用理念。
Cursor Agent Skills：开放标准、目录结构、渐进式加载和跨 Agent 兼容。

艺术码农的小栈