团队里有太多"只有某个人知道"的经验:怎么部署、怎么做数据库迁移、怎么处理线上故障……这些经验如果只存在人的脑子里,Agent 就用不上。Skill 就是把这些经验沉淀成 Agent 可执行的标准化工作流——不是写死的脚本,而是包含判断逻辑、异常处理和人工确认点的"方法论"。

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 的场景

yaml
# skill-worthiness-checklist.yaml
criteria:
  - question: "这个任务团队多久做一次?"
    threshold: "每周至少 1 次"
    reason: "低频任务不值得沉淀成 Skill"
  
  - question: "做这个任务有没有标准流程?"
    threshold: "有,但新人经常做错"
    reason: "没有标准流程的任务不适合写成 Skill"
  
  - question: "任务中有没有需要判断的分支?"
    threshold: "有,而且判断逻辑团队已有共识"
    reason: "没有判断逻辑的任务用脚本就够了"
  
  - question: "做错这个任务的代价大吗?"
    threshold: "中等以上(需要回滚、影响用户、造成损失)"
    reason: "低成本任务不需要 Skill 的标准化保障"

2.2 三个常见的误用场景

  1. 一次性任务误用 Skill:团队有人写了一个"清理临时文件"的 Skill,但团队从来没手动清理过(都是 cron 自动清理)。Skill 写了没人用。

  2. 没有共识的流程误用 Skill:团队对"如何做代码审查"没有统一标准,有人看风格、有人看逻辑、有人看安全。硬写成 Skill 后每个人都不满意。正确做法是先通过讨论达成共识,再写成 Skill。

  3. 纯机械操作误用 Skillnpm run build && npm run test 这种纯线性操作,写成 Makefile 或 shell 脚本就够了,不需要 Skill 的"判断逻辑"层。

三、Skill 的结构

3.1 SKILL.md 示例

markdown
---
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 调用示例

yaml
# 在 Claude Code 中调用 Skill
# 方式 1:Slash 命令
/database-migration-review migrations/20240615_add_tags.sql

# 方式 2:自然语言触发
"帮我做一次数据库迁移风险评估,迁移文件是 migrations/20240615_add_tags.sql"

# 方式 3:Agent 自动匹配
# Agent 检测到用户要执行数据库迁移时,自动建议调用 Skill

3.3 配套脚本

python
# 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 版本管理

yaml
# 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 目录结构

text
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-stylereview-securityreview-performancereview-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 为例增强任务拆解、反思和复盘