Claude Skills：Agent 能力扩展的新范式

为什么需要 Skills？

2025 年被称为智能体元年。各类 Agent、子 Agent、MCP 工具及自动化流水线迅速出现，让 AI 可以接手越来越多真实工作。比如 Claude Code 推出的 Agent 模块，或通过可视化平台、LangChain 开发的各种工具。

随着智能体功能增强，需要更具可组合性、可扩展性和可移植性的方法，为它们配备特定领域专业知识。这促使智能体 Skills 诞生：智能体可动态发现并加载包含指令、脚本和资源的文件夹，从而更好完成特定任务。

什么是 Skills？

Skills 的核心价值是 "将专业知识、工作流、脚本与权限，打包成可组合的文件夹"。Claude 在对话启动时扫描技能描述，根据需求动态加载具体内容，让通用 Agent 即刻化身为拥有领域经验的专业 Agent。

它把 "指令 + 结构化知识 + 可执行脚本" 聚合在一个目录下，让 Claude 在需要时加载，实现 "按需放大上下文 + 精准授权工具" 的工作模式。与传统 Prompt 相比，Skill 具备以下三类关键特性：

可组合：多个技能可共存，Claude 根据 description 自动选择，像插件一样随时装载或释放，避免全局 Prompt 的 "越长越稀释" 问题。
可扩展：通过 references/、scripts/、assets/ 等子目录，不断追加高质量内容，让技能随业务演进成长，不污染基础对话。
可移植：一个 Skill 目录即一份可复制的知识资产。复制整个文件夹即可分享给其他项目或团队，实现知识沉淀和复用。

Skills 架构与文件体系

Claude Skills 本质上是一种 "按需加载的 Meta Tool"。Claude Code 在新对话开始时，先扫描所有 Skill 的 name 和 description，在输入命中关键词时才加载对应技能，注入 SKILL.md 内容、引用文件和额外工具权限。

目录结构

一个完整 Skill 至少包含 SKILL.md。推荐目录层级如下，在实际项目中根据需要扩展：

1my-skill/
2  SKILL.md
3  references/
4    domain.md
5    playbook.md
6  scripts/
7    validator.py
8    helper.sh
9

SKILL.md：采用 YAML Frontmatter + Markdown 正文。Frontmatter 控制 name、description、allowed-tools、版本号等核心属性；正文写清楚工作流、Checklist、提示、常见问题。
references/：存放长文档、规范、数据字典或接口说明，只在需要时加载，避免每次占用上下文。
scripts/：封装可执行脚本或模板，例如 bash、python、ts-node 等，让模型直接执行脚本，无需加入上下文。
assets/：流程截图、系统结构图、UI 布局等视觉资料，不常用。

渐进式披露（LOD-0/LOD-1/LOD-2）

Skill 并非全新概念，也是新瓶装旧酒。它最被关注的点是所谓的渐进式披露（Progressive disclosure patterns）。官方建议把技能内容按照 "层级化 Disclosure（Level of Detail）" 组织：

级别	加载时机	内容	示例
LOD-0	对话初始化；仅扫描 metadata	name + description + allowed-tools	“code-review：检查 staged 代码并运行 tsc/eslint/prettier/test”
LOD-1	Claude 决定加载 SKILL.md 时	核心流程、Checklist、引用链接	“Plan → Validate → Execute 工作流、常见陷阱”
LOD-2	Claude 继续读取 references/、scripts/、assets/	详细 playbook、脚本、图片、长文本	"git-commit-guide.md、code-review.sh、示意图"

在上下文工程（Context Engineering）中，我们知道，用户的输入只占很小部分，整个上下文窗口还包含：

Instructions/System Prompt：系统级指令和角色设定
History：对话历史（短期记忆）
Long-Term Memory：持久化的用户偏好和事实（长期记忆），比如 Cursor 的 memory、rules，或 Claude Code 的 CLAUDE.md
Retrieved Information：动态检索的外部数据（例如来自 RAG，仓库代码）
Available Tools：可用的工具（API、函数）及其定义，比如 MCP 功能或智能体自身的工具（write、read tools）

即使当前大模型都具备很长的上下文窗口，一旦窗口使用超过 50% 以上，模型回答质量和速度都会下降很多。

而通过渐进披露，技能既能保证启动迅速，又能在真正需要时提供完整上下文，避免 "模型先读 1000 行指令却用不上" 的浪费。

YAML Frontmatter 模板

SKILL.md 头部采用 YAML，示例：

1---
2name: code-review
3description: 对 staged 代码进行质量检查（类型、规范、格式、测试、安全性），并在需要时生成符合规范的 commit message
4allowed-tools: Read, Bash(bash:*), Bash(git:*), Bash(npm:*)
5version: 1.0.0
6---
7

注意：

name 只能包含小写字母、数字和连字符，推荐动名词（如 code-review、incident-audit）。
description 要说明“做什么 + 何时触发”，包含关键字以便 Claude 匹配。
allowed-tools 可填写多个能力，必要时使用 Bash(<command>:*) 精确授权。
其他字段如 version、authors、skills（引用其它技能）可以按需添加。

目录模板与最佳实践

Skill 目录最好控制在 500 行以内，可通过 references/ 拆分长文档。
文件命名统一使用英文和连字符，避免空格。
所有脚本默认应跨平台（至少在 Claude Code 默认 Linux 环境可执行），必要时在文档中说明依赖。
引用外部资源时保持路径相对，方便迁移。

完整运行流程

Skill 的运行可以划分为 Discovery → Activation → Execution → Feedback 四个阶段，完整流程：

1---
2config:
3  look: handDrawn
4  theme: neutral
5---
6sequenceDiagram
7    participant U as 用户
8    participant C as Claude
9    participant S as Skill Tool
10    participant CTX as Context Window
11    participant T as Tools/MCP
12
13    C->>S: 会话启动：预加载所有技能的 name/description
14    S-->>C: 返回技能 metadata，等待触发信号
15    U->>C: 描述需求（“请检查我刚暂存的代码并生成报告”）
16    C->>S: 扫描 description，匹配 code-review skill
17    C->>CTX: 加载 SKILL.md
18    CTX-->>C: 根据需求，判断是否需要额外加载 reference 或者执行脚本
19    C->>T: 按 SKill 说明执行 Bash/Read/npm，运行 code-review.sh
20    T-->>C: 返回类型检查、ESLint、Prettier、测试结果
21    C->>CTX: 更新 scratchpad（缺陷列表、下一步动作）
22    C-->>U: 汇报审查结果并附 Checklist
23

四个阶段在流程中的表现为：

Discovery：会话启动时，Claude 预加载所有技能的 name/description，并在用户发出请求后匹配最合适的技能（如 code-review）。
Activation：Skill Tool 注入 SKILL.md、引用文件路径。
Execution：Claude 依据工作流执行任务或直接运行脚本和 Checklist，调用 Bash、Read、MCP 等工具，确保流程在自动化与人工审查之间切换自如。
Feedback：完成任务后，将检查结果、未解决问题和下一步建议写入 scratchpad/memory，然后向用户输出结构化报告。

实战示例：code-review skill

下面以一个 Code Review Skill 示例项目，展示如何使用 Claude Code 的 skill 功能进行代码审查。

示例代码仓库：skill-dojo

场景与需求

痛点：手动审查常常遗漏类型错误、Lint、格式或测试；不同人输出标准不一，commit message 更是随意。
Skill 价值：自动运行四项检查、给出 P0/P1 质量门槛、必要时生成符合规范的提交消息。
触发条件：当用户在会话中提到“代码审查、commit、TypeScript、测试”等关键词，Claude 就会启用该技能。

完整实现

目录结构

1.claude/skills/code-review/
2├── SKILL.md
3├── references/
4│   └── git-commit-guide.md
5└── scripts/
6    └── code-review.sh
7

SKILL.md 配置

1---
2name: code-review
3description: 对 staged 代码进行质量检查（类型、规范、格式、测试、安全性），并在需要时生成符合规范的 commit message
4allowed-tools: Read, Bash(bash:*), Bash(git:*), Bash(npm:*)
5---
6
7# Code Review
8
9## 执行流程
10
11### 1. 运行自动化检查
12
13执行脚本进行完整检查（TypeScript、ESLint、Prettier、测试）：
14
15``` bash
16bash .claude/skills/code-review/scripts/code-review.sh

2. 代码检查要点

在自动化检查通过后，对代码进行以下审查：

P0（必须）

代码逻辑清晰，错误处理完善
安全性：无 XSS、SQL 注入、命令注入等漏洞
用户输入验证和清理
测试覆盖充分

P1（推荐）

无性能问题和重复代码
命名语义化

3. 提交代码（仅在用户要求提交时）

重要：只有当用户明确要求提交代码时，才执行以下步骤：

阅读 references/git-commit-guide.md 了解完整规范
根据规范生成 commit message：

1<类型>: <简短描述>
2
3[可选详细描述]
4[可选关联 issue]

类型：feat, fix, docs, style, refactor, perf, test, chore

执行 git commit 提交代码

约束

【必须】P0 问题必须解决才能提交
【禁止】提交包含安全漏洞的代码
【禁止】commit message 中添加 AI 生成标记


正文部分按照“执行流程 → 注意事项 → 约束”组织：

1. **执行脚本**：[`bash .claude/skills/code-review/scripts/code-review.sh`](https://xplanc.org/primers/document/zh/03.HTML/EX.HTML%20%E5%85%83%E7%B4%A0/EX.code.md)，负责类型、ESLint、Prettier、测试四步检查。
2. **人工审查要点**：P0 必须项包括逻辑正确、安全性、测试完整；P1 推荐项包括性能、命名等。
3. **提交流程**：只有在用户要求时才读取 `git-commit-guide.md`，并生成 `<类型>: <描述>` 格式的提交消息。
4. **约束**：必须解决 P0 问题、禁止提交安全漏洞和 AI 标记。

#### 自动化脚本 [`scripts/code-review.sh`](https://xplanc.org/primers/document/zh/03.HTML/EX.HTML%20%E5%85%83%E7%B4%A0/EX.code.md)

脚本的核心逻辑如下：

```bash
#!/bin/bash

# Code Review Script - 对 git staged 文件进行代码审查

set -e

echo "开始代码审查..."
echo ""

# 检查 staged 文件
STAGED_FILES=$(git diff --cached --name-only)
if [ -z "$STAGED_FILES" ]; then
  echo "[错误] 没有 staged 的文件"
  echo "提示：请先使用 'git add <文件>' 暂存要审查的文件"
  exit 1
fi

FILE_COUNT=$(echo "$STAGED_FILES" | wc -l | tr -d ' ')
echo "Staged 文件 ($FILE_COUNT 个):"
echo "$STAGED_FILES" | sed 's/^/  /'
echo ""

# 统计文件类型
STAGED_TS_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep -E '\.(ts|tsx|js|jsx)$' || true)
STAGED_FORMAT_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep -E '\.(ts|tsx|js|jsx|json|md)$' || true)

# 1. TypeScript 类型检查
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo "[1/4] TypeScript 类型检查"
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
if npx tsc --noEmit 2>&1; then
  echo "[通过] TypeScript 检查通过"
else
  echo "[失败] TypeScript 检查失败"
  exit 1
fi
echo ""

# 2. ESLint 检查
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo "[2/4] ESLint 代码规范检查"
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
if [ -n "$STAGED_TS_FILES" ]; then
  if echo "$STAGED_TS_FILES" | xargs npx eslint 2>&1; then
    echo "[通过] ESLint 检查通过"
  else
    echo "[失败] ESLint 检查失败"
    echo "提示：运行 'npm run lint:fix' 自动修复部分问题"
    exit 1
  fi
else
  echo "[跳过] 无 TypeScript/JavaScript 文件"
fi
echo ""

# 3. Prettier 格式检查
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo "[3/4] Prettier 格式检查"
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
if [ -n "$STAGED_FORMAT_FILES" ]; then
  if echo "$STAGED_FORMAT_FILES" | xargs npx prettier --check 2>&1; then
    echo "[通过] Prettier 检查通过"
  else
    echo "[失败] Prettier 检查失败"
    echo "提示：运行 'npm run format' 自动修复格式问题"
    exit 1
  fi
else
  echo "[跳过] 无需格式检查的文件"
fi
echo ""

# 4. 测试
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo "[4/4] 运行测试"
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
if npm test -- --bail --passWithNoTests 2>&1; then
  echo "[通过] 测试通过"
else
  echo "[失败] 测试失败"
  exit 1
fi
echo ""

# 显示变更统计
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo "变更统计"
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
git diff --cached --stat
echo ""

echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo "[成功] 所有检查通过！"
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"

其实就是执行各种检查命令，直接在 SKILL.md 中说明执行 npm script 也一样。这里只是为了样式。

引用文档 `references/git-commit-guide.md`

git-commit-guide.md 覆盖提交消息格式、八种类型（feat/fix/docs/style/refactor/perf/test/chore）、描述规范、关联 issue 写法，并提供 P0/P1 Checklist。Skill 主体不会一次性注入这些细节，只有在执行 "生成 commit message" 时才加载，符合 LOD 设计。

1# Git 提交消息规范
2
3## 消息格式
4

<类型>: <简短描述>

[可选详细描述] [可选关联问题]


## 提交类型

- `feat`: 新功能
- `fix`: 修复 bug
- `docs`: 文档修改
- [`style`](https://xplanc.org/primers/document/zh/03.HTML/EX.HTML%20%E5%85%83%E7%B4%A0/EX.style.md): 格式修改（不影响功能）
- `refactor`: 代码重构
- `perf`: 性能优化
- [`test`](https://xplanc.org/primers/document/zh/10.Bash/90.%E5%B8%AE%E5%8A%A9%E6%89%8B%E5%86%8C/EX.test.md): 测试相关
- `chore`: 构建/工具变动

## 描述规范

- 使用中文，不超过 50 字符
- 动词开头，现在时（"添加"非"添加了"）
- 不以句号结尾

## 关联问题

- `close #123` - 关闭 issue
- `fix #123` - 修复 issue
- `ref #123` - 引用 issue

## 提交前检查清单

### P0（必须通过）

- [ ] 提交消息格式正确
- [ ] TypeScript、ESLint、Prettier 检查通过
- [ ] 类型定义完整，避免 [`any`](https://xplanc.org/primers/document/zh/02.Python/EX.%E5%86%85%E5%BB%BA%E5%87%BD%E6%95%B0/EX.any.md)
- [ ] 功能完整，错误处理完善
- [ ] 测试通过且覆盖新功能
- [ ] 无安全漏洞（XSS、SQL 注入、命令注入等）
- [ ] 只包含相关变更，无调试代码

### P1（推荐）

- [ ] 复杂更改有详细描述和 issue 关联
- [ ] 代码逻辑清晰，无重复代码
- [ ] API 或界面变更已更新文档

## 约束

- 【禁止】commit message 中添加 AI 生成标记
- 【禁止】提交敏感信息文件（.env, credentials.json 等）
- 【推荐】每次提交只做一件事，保持原子性

实际运行效果

只进行代码 review

1> code review 改动代码
2
3⏺ 我来帮你查看 code review 的改动代码。首先让我看看当前的 git 状态和改动内容。
4
5⏺ Bash(git diff src/__tests__/string.test.ts)
6  ⎿  (No content)
7
8⏺ 让我查看一下 staged 的改动：
9
10⏺ Bash(git diff --cached src/__tests__/string.test.ts)
11  ⎿ diff --git a/src/__tests__/string.test.ts b/src/__tests__/string.test.t
12    s
13    index 52997f2..19908cf 100644
14    … +38 lines (ctrl+o to expand)
15
16⏺ 我看到了 code review 的改动。主要有两个变化：
17  ......
18
19  问题分析
20
21  这些改动看起来有问题：
22  1. 重复的测试用例：添加了 4 个完全相同的测试，这是不必要的重复代码
23  2. import 顺序：虽然调整了顺序，但没有明显的改进（不是按字母顺序）
24
25  你想要：
26  1. 撤销这些改动？
27  2. 还是修复这些问题（删除重复的测试用例，保持合理的 import 顺序）？
28
29> code-review 代码
30
31⏺ 我来帮你执行 code review。让我运行 code-review skill：
32
33⏺ /code-review
34
35⏺ Task Output code-review
36  ⎿  Error: No task found with ID: code-review
37
38⏺ 让我查看一下 code-review skill 的配置：
39
40⏺ Read(.claude/skills/code-review/SKILL.md)
41  ⎿  Read 58 lines
42
43⏺ 好的，我来执行 code review。首先运行自动化检查脚本：
44
45⏺ Bash(bash .claude/skills/code-review/scripts/code-review.sh)
46  ⎿  Error: Exit code 1
47     开始代码审查...
48
49     Staged 文件 (1 个):
50       src/__tests__/string.test.ts
51
52     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
53     [1/4] TypeScript 类型检查
54     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
55     npm warn Unknown user config "home". This will stop working in the next
56     major version of npm.
57     … +17 lines (ctrl+o to see all)
58
59⏺ Code Review 结果
60
61  ❌ 自动化检查失败
62 ......
63
64  这些测试用例：
65  1. 标题完全相同：违反了 Jest 规范，同一个 describe 块中不能有重复的测试标题
66  2. 测试内容重复：没有测试新的场景，只是重复了已有的测试
67  3. 没有实际价值：不增加测试覆盖率
68
69  建议
70
71  必须修复（P0）：删除这 4 个重复的测试用例，保留原有的测试即可。
72
73  你想要我帮你修复这些问题吗？
74
75

可以看到 Claude 识别到我的意图是进行代码 review，所以它加载 SKILL.md 的具体指令，并按照指令执行。指令中提到要运行脚本，它就直接执行脚本，执行脚本的好处是：

不需要将脚本内容加载到上下文窗口中，所以不管脚本是 1000 行还是 10000 行都无所谓。当然，如果脚本执行出错，模型可能会去阅读脚本内容并修复，这时就会占用上下文空间。所以保证脚本可用性比较关键。
效率快，让模型处理，不仅消耗 token，而且速度会慢很多。尤其是工程化方面，或重复性场景，直接使用脚本，不仅快，而且结果更可控，毕竟模型输出是概率性问题。模型负责整体规划，各个具体环节使用脚本处理，脚本也可以让模型生成。实际上，模型在日常生码时，它自己也会编写脚本加读取大文件或做验证工作。

代码 review 和提交

1> codereview 并提交
2
3⏺ 我会帮你执行代码审查并提交。让我先运行 code-review skill。
4
5⏺ /code-review
6
7⏺ 让我查看一下 code-review skill 的输出，并检查 staged 的文件：
8
9......
10
11⏺ 完美！代码审查完成，所有检查都通过了。现在让我更新 todo 并提交代码：
12
13⏺ 现在让我查看 git commit 规范并提交代码：
14
15⏺ Read(.claude/skills/code-review/references/git-commit-guide.md)
16  ⎿  Read 58 lines
17
18⏺ 现在让我提交代码：
19
20⏺ Bash(git commit -m "chore: 初始化 Code Review Skill 示例项目…)
21  ⎿  [main (root-commit) 3bf459d] chore: 初始化 Code Review Skill 示例项目
22      18 files changed, 5794 insertions(+)
23      create mode 100644 .claude/skills/code-review/SKILL.md
24     … +18 lines (ctrl+o to expand)
25
26⏺ 完成！代码审查和提交已成功完成。
27
28  代码审查总结
29
30  检查结果：
31  - ✅ ESLint 检查通过（无错误）
32  - ✅ TypeScript 类型检查通过
33  - ✅ 测试通过（21 个测试用例全部通过）
34  - ✅ 代码规范符合要求
35
36  代码质量评估：
37  1. 类型安全：所有函数都有明确的类型定义，无 any 类型
38  2. 错误处理：认证服务有完善的输入验证和错误处理
39  3. 测试覆盖：包含完整的单元测试，覆盖正常和异常场景
40  4. 代码规范：符合 ESLint 和 Prettier 配置的规范
41  5. 安全性：HTML 转义函数可防止 XSS 攻击，邮箱验证使用正则表达式
42
43

因为我明确提到需要提交代码，所以这一次 Claude 才去读取 git-commit-guide.md 文件内容，并提交。

Skills vs. 其他机制深度对比

笔者在以前讲解过 Cursor Rules 开发实践指南，如果使用过 Cursor Rule 的朋友，可能会发现这和 Rules 没什么区别，Rules 也是给出指令，规范模型行为，也支持模型自主确定是否需要放入上下文中。甚至与 Claude 的 CLAUDE.md 或 command 命令都是大同小异。所以笔者才说 Skill 并非全新概念，也是新瓶装旧酒。它最被关注的点是所谓的渐进式披露（Progressive disclosure patterns）。

对比

机制	核心定位	触发方式	上下文 / 权限特征	典型场景与补充说明
Skills	注入场景知识与脚本，固化 Plan → Validate → Execute 流程	Claude 自动解析 description 并自主加载	LOD 控制按需读取；临时扩展 allowed-tools；可结合脚本/引用动态增广上下文	高频、结构化任务（代码审查、日志排查）；可依赖 Rules 但不与之冲突
Cursor Rules / CLAUDE.md	会话级“操作系统”规则，限定语气、流程、禁忌	会话初始化时一次性注入（个别 Rules 通过模型自主加载）	长期占用上下文；权限通常固定，少变化	规范项目基调、入职指南；为 Skills 提供通用约束背景
Slash Commands	用户显式触发的快捷提示或宏	输入 /command 即调用	仅在当次请求中插入短提示；不改变工具权限	低频、记忆性任务；适合临时指令，而非复杂流程
MCP	连接外部系统/数据库/API 的行动力层	Claude 需要时显式调用工具	不大量占用上下文，调用瞬间返回结果；权限由 Server 定义	数据查询、CI/CD、Jira 等外部操作；与 Skills 配合时按 Skill 规划调用顺序
Subagents	具有独立上下文与工具集的子任务执行者	Claude 或用户显式指派	拥有独立会话窗口与权限，运行成本较高	并行调查、多角色交互、需要隔离上下文时使用
传统 Prompt	一次性指导语或提问补充	用户手动输入文本	不提供持久结构；无额外权限	ad-hoc 指令或突发问题；难以复用、缺乏流程约束

Skills 和 MCP

Skills 与 MCP 并非竞争关系，而是 "知识 + 行动力" 的组合。Skills 负责告诉 Claude "为什么、何时、怎样做"，MCP 则负责 "怎么去外部世界获取数据或执行动作"。比如 Skills 可以使用脚本执行具体任务，当然也可以明确使用 MCP 处理具体场景。

Claude 官方的文章 Skill Explained 不同的场景对比有更详细的解释

Skills 的优势与适用场景

自动触发：description 命中即可调用，免除 slash command 的额外输入
上下文精准：LOD 控制加载层级，脚本与引用只在真正需要时注入
流程固化：把 "计划 → 校验 → 执行" 写入技能，使 Agent 行为确定、可复现
跨团队复用：复制整个目录即可共享，从项目到项目快速迁移

编写 Skills 的最佳实践

命名规范：name 使用动名词或结果导向词（如 generate-release-notes）
描述写法：遵循 "做什么 + 何时触发 + 关键名词"，例："Analyzes staged frontend code when users request review"
Workflow + Feedback Loop：写清 Plan → Validate → Execute → Report，附 Checklist
简洁优先：上下文窗口是公共资源，每个指令都要简洁并且精确
自由度梯度：根据脆弱性决定指令精度，必要时提供伪代码甚至完整脚本
渐进披露：SKILL.md 控制在 500 行内，引用文件不要互相嵌套
评估先行：在真实任务记录缺陷，再据此编写技能，避免凭空想象
脚本质量：脚本必须可执行、可重复，失败时输出清晰提示
依赖清单：说明 npm/pip 依赖、Node 版本等，减少环境猜测

Skills 创建和使用

在 Claude Code 中可以直接在官方提供的 /plugin 中使用 claude-plugins-official 中预制的 skill，以及 skill-creator 创建自己 skills。

除了 Claude Code，Codex、Gemini CLI 也相继支持 Skill，市面上也会出现越来越多 awesome-skill 的仓库，可以下载使用（当然，少不了之前各种 MCP 也会使用 Skill 再实现一遍）。

当然，其实你不一定需要各种 awesome fantastic skills，最重要的是根据自己日常开发，找到重复纠正 AI 的部分，让 AI 将其沉淀为一份 Skill，减少日常和 AI 的来回拉扯，会有效得多。

总结

模型现在最大的问题是没有记忆，为了让模型能更长时间工作，增大了上下文窗口，但加上各种外部工具、MCP 之后，无论多大的窗口也终究撑满，所以更大的窗口并没有有效提升模型的编码质量。更重要的是这些信息是否真的那么重要，是否一开始就必须加载到上下文中更值得研究，所以 Skills 被提出来，让上下文只包含对当前任务来说真正重要的内容（不知为什么去年 10 月提出后，响应还不大，最近突然就火了起来。可以预见的是：程序员又得再死几次了）。即使不使用 Skill，这套渐进式披露的思路也可以在日常 Vibe Coding 中用起来。

那么下一步呢？

在 Manus 合伙人访谈提到一点我很赞同。人脑的工作内存其实很小，我们脑袋里真正装载的内容并没有那么多，其他和当前任务不相关的内容，我们会通过文本等方式存到笔记中，在真正需要时才去查找。重要的是我们有自动 Compress 和需要时自动查找的能力。而模型现在的上下文压缩通常发生在上下文空间快满的时候，自动压缩的意识很弱，并且也没有意识将进展和成果 download 到外部，以及后续从对应的地方加载的这些意识。虽然目前可以通过 memory bank 的方式来规范。但如果模型后续这部分的意识进一步增强，那么对于长期任务和代码的统一性能达到更好的效果。在此之前，如果规范模型主动压缩上下文，外化记忆和加载阶段性成果依旧值得我们去给模型加上指令规范。

参考资源：

《Claude Skills：Agent 能力扩展的新范式》是转载文章，点击查看原文。

Claude Skills：Agent 能力扩展的新范式

为什么需要 Skills？

什么是 Skills？

Skills 架构与文件体系

目录结构

渐进式披露（LOD-0/LOD-1/LOD-2）

YAML Frontmatter 模板

目录模板与最佳实践

完整运行流程

实战示例：code-review skill

场景与需求

完整实现

目录结构

SKILL.md 配置

2. 代码检查要点

P0（必须）

P1（推荐）

3. 提交代码（仅在用户要求提交时）

约束

引用文档 references/git-commit-guide.md

实际运行效果

只进行代码 review

代码 review 和提交

Skills vs. 其他机制深度对比

对比

Skills 和 MCP

Skills 的优势与适用场景

编写 Skills 的最佳实践

Skills 创建和使用

总结

那么下一步呢？

引用文档 `references/git-commit-guide.md`