Skill 使用实战:把团队经验沉淀成 Agent 可执行的工作方法
团队里有太多"只有某个人知道"的经验:怎么部署、怎么做数据库迁移、怎么处理线上故障……这些经验如果只存在人的脑子里,Agent 就用不上。Skill 就是把这些经验沉淀成 Agent 可执行的标准化工作流——不是写死的脚本,而是包含判断逻辑、异常处理和人工确认点的"方法论"。
一、Skill 是什么,不是什么
| 类型 | 定义 | 示例 | 适用场景 |
|---|---|---|---|
| 临时 Prompt | 一次性对话 | "帮我写一个 SQL 查询" | 用完即弃 |
| 项目规则 | CLAUDE.md / .cursorrules | "这个项目用 pnpm 不是 npm" | 全局约束 |
| Skill | 可复用的工作流模板 | "数据库迁移风险评估" | 反复执行的标准流程 |
| 脚本 | 自动化代码 | deploy.sh |
纯机械操作 |
Skill 和临时 Prompt 的区别:Skill 有明确的触发条件、输入输出规范、步骤分解和异常处理。临时 Prompt 只是一句话。
Skill 和项目规则的区别:规则是"约束"(不能做什么),Skill 是"方法"(怎么做某件事)。
Skill 和脚本的区别:Skill 包含判断和决策("如果检测到锁表风险,停下来等人工确认"),脚本只是线性执行。
二、什么时候该写 Skill
2.1 值得写成 Skill 的场景
# skill-worthiness-checklist.yaml
criteria:
- question: "这个任务团队多久做一次?"
threshold: "每周至少 1 次"
reason: "低频任务不值得沉淀成 Skill"
- question: "做这个任务有没有标准流程?"
threshold: "有,但新人经常做错"
reason: "没有标准流程的任务不适合写成 Skill"
- question: "任务中有没有需要判断的分支?"
threshold: "有,而且判断逻辑团队已有共识"
reason: "没有判断逻辑的任务用脚本就够了"
- question: "做错这个任务的代价大吗?"
threshold: "中等以上(需要回滚、影响用户、造成损失)"
reason: "低成本任务不需要 Skill 的标准化保障"2.2 三个常见的误用场景
一次性任务误用 Skill:团队有人写了一个"清理临时文件"的 Skill,但团队从来没手动清理过(都是 cron 自动清理)。Skill 写了没人用。
没有共识的流程误用 Skill:团队对"如何做代码审查"没有统一标准,有人看风格、有人看逻辑、有人看安全。硬写成 Skill 后每个人都不满意。正确做法是先通过讨论达成共识,再写成 Skill。
纯机械操作误用 Skill:
npm run build && npm run test这种纯线性操作,写成 Makefile 或 shell 脚本就够了,不需要 Skill 的"判断逻辑"层。
三、Skill 的结构
3.1 SKILL.md 示例
---
name: database-migration-review
description: 数据库迁移前的风险评估和审查流程
version: 1.2.0
author: "@dba-team"
last_updated: "2024-06-10"
# 触发条件
triggers:
- "db-migration"
- "数据库迁移"
- "/skill migration"
# 输入材料
inputs:
- name: migration_file
type: file
required: true
description: "SQL 迁移文件路径"
- name: target_table
type: string
required: false
description: "主要影响的表名"
# 输出
outputs:
- name: risk_report
type: json
description: "风险评估报告"
- name: rollback_script
type: file
description: "回滚 SQL 脚本"
# 依赖文件
dependencies:
- "docs/schema-snapshot.json"
- "docs/table-stats.json"
# 验证命令
validation:
command: "python scripts/validate-migration.py {migration_file}"
expected_exit_code: 0
# 不适用场景
exclusions:
- "纯数据迁移(INSERT 不涉及 schema 变更)"
- "测试环境的快速迭代迁移"
---
# 数据库迁移风险评估 Skill
## 适用边界
本 Skill 适用于生产环境的 schema 变更(ALTER TABLE、CREATE INDEX 等)。
不适用于测试环境或纯数据迁移。
## 工作流程
### 阶段 1:Schema Diff 分析
读取迁移文件,分析涉及的表和变更类型。
判断逻辑:
- 如果涉及 >100 万行的表 → 标记为高风险
- 如果包含 ALTER COLUMN TYPE → 标记为需要维护窗口
- 如果是 CREATE INDEX → 检查是否使用 CONCURRENTLY
### 阶段 2:风险评估
根据分析结果生成风险报告。
**人工确认点**:如果风险等级为 HIGH 或 CRITICAL,必须等待 DBA 确认后才能继续。
### 阶段 3:回滚脚本生成
为迁移脚本生成配套的回滚脚本。
要求:
- 回滚脚本必须幂等(IF EXISTS / IF NOT EXISTS)
- 回滚脚本必须经过 dry-run 验证
### 阶段 4:Dry-Run 验证
在测试数据库上执行迁移和回滚。
**失败处理**:如果 dry-run 失败,停止流程并报告具体问题。不要尝试自动修复。
## 异常处理
| 异常 | 处理 |
|------|------|
| 迁移文件语法错误 | 停止,报告具体错误位置 |
| 表统计信息不存在 | 使用默认阈值,标记"未验证" |
| DBA 未响应(超过 2 小时) | 告警,不自动继续 |
| dry-run 超时(超过 30 分钟) | 停止,建议分批执行 |3.2 Skill 调用示例
# 在 Claude Code 中调用 Skill
# 方式 1:Slash 命令
/database-migration-review migrations/20240615_add_tags.sql
# 方式 2:自然语言触发
"帮我做一次数据库迁移风险评估,迁移文件是 migrations/20240615_add_tags.sql"
# 方式 3:Agent 自动匹配
# Agent 检测到用户要执行数据库迁移时,自动建议调用 Skill3.3 配套脚本
# scripts/skill-runner.py
"""
Skill 执行器。
读取 SKILL.md,解析工作流程,驱动 Agent 按步骤执行。
"""
import yaml
import re
from pathlib import Path
class SkillRunner:
def __init__(self, skill_path: str):
self.skill_dir = Path(skill_path)
self.skill_md = self.skill_dir / "SKILL.md"
self.config = self._parse_skill_md()
def _parse_skill_md(self) -> dict:
"""解析 SKILL.md 的 frontmatter"""
content = self.skill_md.read_text()
# 提取 frontmatter(--- 之间的内容)
match = re.match(r"^---\n(.+?)\n---", content, re.DOTALL)
if match:
return yaml.safe_load(match.group(1))
return {}
def validate_inputs(self, inputs: dict) -> tuple[bool, str]:
"""验证输入参数"""
for inp in self.config.get("inputs", []):
if inp["required"] and inp["name"] not in inputs:
return False, f"缺少必填参数: {inp['name']}"
return True, "OK"
def run_validation(self) -> tuple[bool, str]:
"""运行验证命令"""
validation = self.config.get("validation", {})
if not validation:
return True, "无验证命令"
command = validation["command"]
expected = validation.get("expected_exit_code", 0)
import subprocess
result = subprocess.run(command, shell=True, capture_output=True, text=True)
if result.returncode == expected:
return True, "验证通过"
else:
return False, f"验证失败: {result.stderr[:500]}"
def get_workflow_steps(self) -> list:
"""提取工作流程步骤"""
content = self.skill_md.read_text()
# 提取 ### 标题作为步骤
steps = re.findall(r"### (阶段 \d+.+)", content)
return steps
def has_human_checkpoint(self, step: str) -> bool:
"""检查步骤是否有人工确认点"""
content = self.skill_md.read_text()
# 查找步骤下的 "人工确认点" 标记
pattern = rf"{re.escape(step)}.*?人工确认点"
return bool(re.search(pattern, content, re.DOTALL))四、Skill 的版本与维护
4.1 版本管理
# skill-versions.yaml
skill: "database-migration-review"
versions:
- version: "1.0.0"
date: "2024-01-15"
author: "@dba-lead"
changes: "初始版本"
- version: "1.1.0"
date: "2024-03-20"
author: "@senior-dba"
changes:
- "增加了 PG 11+ DEFAULT 值行为判断"
- "增加了 CONCURRENTLY 索引的检查"
- version: "1.2.0"
date: "2024-06-10"
author: "@dba-team"
changes:
- "增加了 dry-run 超时处理"
- "优化了风险等级判断规则"
# 版本策略
versioning:
major: "不兼容的工作流变更(删除步骤、修改输入输出格式)"
minor: "新增步骤、优化判断逻辑、增加异常处理"
patch: "修正文案、修复 bug"4.2 Skill 目录结构
skills/
└── database-migration-review/
├── SKILL.md # Skill 定义(frontmatter + 工作流)
├── scripts/
│ ├── analyze-migration.py
│ ├── generate-rollback.py
│ └── validate-migration.py
├── templates/
│ ├── risk-report.json
│ └── rollback-template.sql
├── examples/
│ ├── low-risk-example.md
│ └── high-risk-example.md
└── tests/
├── test-analyzer.py
└── test-rollback.py五、真实经验与踩坑
5.1 Skill 范围太宽会适得其反
场景:写了一个"代码审查"Skill,覆盖了代码风格、安全、性能、可维护性四个维度。
问题:Skill 太长(800 行),Agent 每次执行都超时。而且不同团队的审查重点不同——前端团队关注性能,后端团队关注安全。
解决方案:拆分成 4 个独立的 Skill(review-style、review-security、review-performance、review-maintainability),调用者根据需要组合使用。每个 Skill 控制在 200 行以内。
5.2 Skill 必须可回退到普通 Prompt
场景:Skill 执行到一半失败了(依赖文件不存在),Agent 不知道该怎么办,整个流程卡住。 问题:Skill 不是万能的。依赖变化、环境差异、特殊情况都可能让 Skill 失败。 解决方案:Skill 的异常处理中必须包含"回退策略"——如果 Skill 无法执行,回退到普通的 Prompt 模式,让 Agent 用通用能力处理。在 SKILL.md 中明确写清:"如果以下前置条件不满足,跳过本 Skill,使用通用方式处理"。
5.3 Skill 需要定期复盘更新
场景:一个"部署"Skill 写了 6 个月没更新,期间部署流程改了 3 次(从 Docker Compose 迁移到 K8s),Skill 还是旧的。
问题:有人用旧 Skill 部署,按 Docker Compose 的步骤操作,全部失败。
解决方案:每个 Skill 设置"复盘周期"(建议每月一次),检查 Skill 是否和实际流程一致。在 Skill 的 frontmatter 中记录 last_verified_date,超过 30 天未验证的 Skill 自动标记为"可能需要更新"。
六、参数说明表
| 参数 | 类型 | 默认值 | 说明 |
|---|---|---|---|
name |
string | 必填 | Skill 唯一名称 |
description |
string | 必填 | 一句话描述 |
version |
string | "1.0.0" |
语义化版本号 |
triggers |
list | 必填 | 触发条件(关键词、命令) |
inputs |
list | 必填 | 输入参数定义 |
outputs |
list | 必填 | 输出定义 |
dependencies |
list | [] |
依赖文件 |
validation |
object | {} |
验证命令 |
exclusions |
list | [] |
不适用场景 |
review_period_days |
int | 30 |
复盘周期 |
七、落地检查清单
- Skill 的触发条件明确,不会被误触发
- 输入参数有完整的类型和必填标注
- 工作流程的每个步骤有判断逻辑和异常处理
- 人工确认点标注清晰
- 不适用的场景已明确列出
- 配套脚本有测试覆盖
- 版本号遵循语义化规范
- Skill 可回退到普通 Prompt
- 复盘周期已设置
- 示例可运行、可验证
八、系列导航
上一篇:Lab 009:Agent 自动重试几次最合适?成功率与成本曲线 下一篇:插件使用技巧:以 superpowers 为例增强任务拆解、反思和复盘