芥末
发布于 2026-04-21 / 0 阅读
0
0

Claude Skills 实践指南:把 Prompt 封装成可复用的 AI 工作流

很多人使用大模型时,习惯把所有要求都塞进一段 Prompt:角色、背景、步骤、格式、注意事项、示例,能写多细就写多细。这个办法适合一次性任务,但一旦任务变成团队里的长期流程,问题就会暴露出来:

  • 同一类任务每次都要重新复制 Prompt;
  • Prompt 越写越长,模型容易忽略关键要求;
  • 参考资料、模板、脚本混在一起,维护成本很高;
  • 不同成员写出的 Prompt 不一致,输出质量也不稳定;
  • 接入工具后,模型知道“能调用工具”,但不知道“什么时候、按什么顺序调用”。

Claude Skills 解决的就是这个问题。它不是再发明一种聊天技巧,而是把 Prompt 从一段文本升级成一个可维护、可复用、可测试的文件夹。

一个 Skill 可以理解成某个具体岗位能力的封装:里面有任务说明、执行流程、参考资料、自动化脚本和交付模板。Claude 在遇到相关请求时加载这个技能,然后按技能里的规则完成任务。

Claude Skill 是什么

Claude Skill 是一组打包在文件夹里的指令和资源,用来教 Claude 处理某类具体任务或工作流。

最小的 Skill 只需要一个 SKILL.md 文件。复杂一点的 Skill 可以继续拆出脚本、参考资料和模板。

典型目录结构如下:

release-notes-skill/
├── SKILL.md
├── scripts/
│   └── collect_commits.py
├── references/
│   ├── release-note-style.md
│   └── product-terminology.md
└── assets/
    └── release-note-template.md

各部分职责可以这样划分:

路径是否必需作用
SKILL.md必需技能入口,包含元信息、触发描述、核心工作步骤
scripts/可选放可执行脚本,用来处理确定性任务,比如解析文件、拉取数据、格式转换
references/可选放长文档、规范、术语表、API 说明等参考资料
assets/可选放模板、示例文件、图片素材、固定格式的交付物

这种设计的关键点是:不要把所有内容都写进一个超长 Prompt。核心规则放在 SKILL.md,大块资料放到 references/,需要计算或转换的部分交给 scripts/,固定交付格式放到 assets/

从 Prompt 到 Skill,变化在哪里

传统 Prompt 更像一次性口头指令,Skill 更像可执行的岗位手册。

对比项普通 PromptClaude Skill
复用方式复制粘贴作为文件夹复用
结构一段文本指令、脚本、资料、模板分层管理
上下文占用往往一次性塞满按需加载
适合任务临时问答、简单生成固定流程、复杂任务、团队协作
质量控制依赖提问者经验可以设计触发条件、流程和指标
维护成本越长越难改文件拆分后更容易维护

如果只是让 Claude “帮我润色这句话”,普通 Prompt 足够。如果是“每周根据 Git 提交、产品术语表和发布说明模板生成对外 Release Notes”,Skill 会更合适,因为它能把流程和资料固定下来。

Skill 的加载机制:渐进式披露

Claude Skills 有一个很重要的设计:Progressive Disclosure,通常可以翻译成“渐进式披露”或“按需加载”。

它的目标很明确:让模型先看到最少但足够的信息,只有在任务真正需要时才加载更多内容。

flowchart TD
    A[用户请求] --> B[读取 Skill 元信息]
    B --> C{是否匹配触发条件}
    C -- 否 --> D[不加载该 Skill]
    C -- 是 --> E[加载 SKILL.md 正文]
    E --> F{是否需要更多资料}
    F -- 否 --> G[按核心流程执行]
    F -- 是 --> H[读取 references/assets/scripts]
    H --> G
    G --> I[输出结果或调用工具完成任务]

这种机制一般分三层:

层级内容加载时机设计重点
第一层SKILL.md 的 YAML frontmatter常驻或被索引用于判断触发描述要准确,触发范围不能太宽
第二层SKILL.md 正文Skill 被判定相关后加载写清任务流程、约束和交付标准
第三层references/assets/scripts/执行中按需读取或调用存放大块资料、模板和确定性逻辑

渐进式披露能解决两个常见问题。

一个是上下文成本。企业知识库、产品规范、代码说明、接口文档通常很长,如果每次请求都完整塞进上下文,成本会快速上升,模型也更容易被无关内容干扰。

另一个是注意力稀释。模型并不是看到越多资料就越稳定。当一段 Prompt 同时包含几十条规则、多个示例、很多例外情况时,关键要求反而可能被淹没。Skill 把资料拆层后,模型先根据简短描述判断是否使用技能,再在需要时读取具体资料,整体更可控。

一个合格的 SKILL.md 应该怎么写

SKILL.md 是 Skill 的入口文件,通常包含两部分:

  1. YAML frontmatter:给系统判断这个 Skill 什么时候应该触发;
  2. Markdown 正文:给 Claude 执行任务时阅读。

一个发布说明 Skill 可以这样写:

---
name: release-notes
description: Generate customer-facing release notes from Git commits, pull request summaries, and product terminology. Use this skill when the user asks to create, rewrite, or standardize release notes, changelogs, or version update announcements.
---

# Release Notes Skill

## Goal

Create concise, customer-facing release notes from technical change records.

## Inputs

The user may provide one or more of the following:

- Git commit list
- Pull request summaries
- Version number
- Product area
- Target audience
- Draft release notes

If required information is missing, ask for it before generating the final release notes.

## Workflow

1. Identify the release scope: version, date range, product area, and audience.
2. Group changes into user-facing categories:
   - New features
   - Improvements
   - Bug fixes
   - Breaking changes
   - Deprecations
3. Remove internal implementation details unless they affect users.
4. Apply the tone and terminology from `references/release-note-style.md`.
5. Use `assets/release-note-template.md` as the final structure.
6. If commit data needs parsing, use `scripts/collect_commits.py`.

## Output Requirements

- Use clear headings.
- Keep each bullet short.
- Explain user impact, not internal code changes.
- Mark breaking changes explicitly.
- Do not invent features that are not present in the input.

这里最重要的是 description。它不是写给人类随便看的简介,而是决定 Skill 是否触发的关键字段。

一个差的描述通常太宽:

description: Helps with writing.

这个描述会导致误触发,因为“writing”覆盖面太大,写邮件、写代码注释、写广告语、写论文摘要都可能命中。

更好的写法应该明确任务、输入、触发场景和边界:

description: Generate customer-facing release notes from Git commits, pull request summaries, and product terminology. Use this skill when the user asks to create, rewrite, or standardize release notes, changelogs, or version update announcements.

好的 Skill 描述应该回答四个问题:

问题说明
它处理什么任务比如生成发布说明、审查发票、分析日志
它需要什么输入比如 Git 提交、合同文本、API 日志
用户怎么说时应该触发写出接近真实用户表达的触发语义
它不该处理什么通过范围控制减少误触发

把 Skill 当成岗位说明书来设计

设计 Skill 时,可以借用 JD(岗位说明书,Job Description)的思路。一个岗位不能只写“负责运营工作”,它要说明职责范围、交付物、协作边界和考核标准。Skill 也是一样。

以“发票审核 Skill”为例,职责可以这样拆:

设计项示例
岗位名称invoice-review
核心职责根据公司报销政策检查发票是否合规
触发场景用户上传发票、报销单或询问某笔费用是否可报销
输入材料发票图片、费用类型、报销人信息、公司报销政策
输出结果合规 / 不合规 / 需要补充材料,并列出原因
边界不负责最终付款审批,不替代财务系统记录
依赖资料报销政策、税务规则、费用类别表
自动化能力OCR 结果解析、金额校验、日期校验

对应到文件结构:

invoice-review/
├── SKILL.md
├── scripts/
│   ├── validate_amount.py
│   └── normalize_invoice_fields.py
├── references/
│   ├── reimbursement-policy.md
│   └── expense-categories.md
└── assets/
    └── review-result-template.md

这种写法能避免 Skill 变成一个“什么都能干一点”的巨型 Prompt。Skill 越具体,触发越准,输出也越容易稳定。

SOP:让 AI 按流程工作

SOP(标准作业流程,Standard Operating Procedure)是 Skill 正文里最该写清楚的部分。Claude 不只需要知道任务目标,还需要知道按什么顺序做、什么时候调用工具、遇到异常怎么处理。

常见工作流可以归纳为几类。

工作流模式适合场景Skill 里应该写什么
顺序流程发布说明、合同审查、报表生成明确第 1 步到第 N 步,每步输入输出是什么
多工具协同查数据库、调用 API、生成文件写清工具调用顺序、失败处理和数据传递方式
迭代打磨文案润色、方案设计、代码重构规定每轮如何评价、如何修改、何时停止
按上下文选工具运维排障、客服处理给出选择工具的条件,而不是固定调用一个工具
领域规则内置财务、法务、医疗、代码规范把规则放入参考资料,并规定优先级

发布说明 Skill 的流程可以画成这样:

flowchart LR
    A[输入 Git 提交或 PR 摘要] --> B[识别版本范围]
    B --> C[过滤内部实现细节]
    C --> D[按用户影响分类]
    D --> E[读取术语表和风格规范]
    E --> F[套用发布说明模板]
    F --> G[检查是否存在虚构内容]
    G --> H[输出最终 Release Notes]

如果 Skill 需要调用多个工具,流程就要写得更严格。例如一个“线上故障分析 Skill”可能要依次读取告警、查询日志、拉取指标、分析近期发布,再给出结论。

sequenceDiagram
    participant User as 用户
    participant Claude as Claude
    participant Alert as 告警系统
    participant Logs as 日志平台
    participant Metrics as 指标系统
    participant Deploy as 发布系统

    User->>Claude: 分析服务 5xx 升高原因
    Claude->>Alert: 获取告警详情
    Alert-->>Claude: 告警时间、服务名、错误类型
    Claude->>Logs: 查询异常日志
    Logs-->>Claude: 错误堆栈和请求样本
    Claude->>Metrics: 查询 QPS、延迟、错误率
    Metrics-->>Claude: 指标变化曲线
    Claude->>Deploy: 查询近期发布
    Deploy-->>Claude: 发布版本和变更摘要
    Claude-->>User: 输出可能原因、证据和处理建议

这里的重点不是让 Claude “自由发挥”,而是把排障路径写清楚。模型可以负责判断和归纳,但关键数据来源、工具调用条件、证据链要求都应该固定下来。

MCP 和 Skills 的关系

MCP(Model Context Protocol,模型上下文协议)解决的是“模型如何连接外部工具和数据源”的问题。通过 MCP,Claude 可以访问文件系统、数据库、搜索服务、内部 API、监控平台等能力。

Skills 解决的是另一个问题:拿到这些工具后,Claude 应该怎样完成任务。

可以用一个简单类比:

  • MCP 像厨房,提供锅、刀、烤箱、食材和操作台;
  • Skills 像菜谱,规定用什么材料、按什么顺序做、火候如何、最后怎么装盘。

只有 MCP,没有 Skills,Claude 可能知道自己能查日志、能调用接口、能读文件,但不一定知道某个业务流程中应该先查什么、后验证什么、最终交付什么。

只有 Skills,没有 MCP,Claude 可以按流程思考和写作,但遇到需要访问外部系统、执行脚本或读取实时数据的任务时,能力会受限。

组合起来之后,AI 工作流会更完整:

flowchart TD
    A[用户任务] --> B[Skill 判断任务类型]
    B --> C[读取流程和规则]
    C --> D{是否需要外部能力}
    D -- 不需要 --> E[直接生成结果]
    D -- 需要 --> F[MCP 提供工具和数据源]
    F --> G[按 Skill 流程调用工具]
    G --> H[汇总证据并输出结果]

在 Claude Code 这类开发场景里,还可以叠加 hooks。Hooks 可以理解成某些事件发生时自动执行的动作,比如保存文件后跑格式化、提交前跑测试、命令执行前做安全检查。Skill、MCP、hooks 组合后,Claude 不只是回答问题,而是能进入一个更接近工程系统的自动化流程。

如何创建一个可维护的 Skill

创建 Skill 时,不建议一上来就写一个巨大的“全能助手”。更稳妥的方式是从一个高频、边界清晰、输入输出稳定的任务开始。

1. 选一个具体任务

适合做成 Skill 的任务通常有几个特征:

特征说明
重复出现团队经常要做,比如生成周报、审查配置、整理发布说明
流程固定每次步骤差不多,只是输入数据不同
有明确交付物输出格式可以被模板化
有参考资料需要遵守规范、术语、政策或代码风格
可以验收能判断结果是否合格

不适合一开始就做成 Skill 的任务:

任务类型原因
目标非常开放的头脑风暴流程和验收标准不稳定
覆盖多个部门的大而全助手触发范围太宽,容易误用
需要大量实时权限但没有工具接入Skill 本身不能替代外部系统
规则还没沉淀清楚的新流程先用普通 Prompt 跑几轮,再固化

2. 写清触发描述

description 要贴近用户真实表达。可以把用户可能说的话列出来,再抽象成触发描述。

例如代码审查 Skill 的触发语句可能包括:

帮我看一下这个 PR 有没有问题
检查这段代码是否符合团队规范
review 一下这个 diff
这个提交有没有潜在 bug

对应描述可以写成:

description: Review code changes, pull request diffs, or patches for correctness, maintainability, security risks, and team coding standards. Use this skill when the user asks for code review, PR review, diff analysis, or patch inspection.

如果团队还有“安全审计 Skill”,就要避免两个 Skill 同时抢同一类任务。代码审查 Skill 可以覆盖通用质量问题,安全审计 Skill 则专门处理认证、授权、输入校验、敏感数据、依赖漏洞等安全主题。

3. 把长资料拆出去

不要把几千行规范直接写进 SKILL.md。入口文件只保留关键流程和引用方式,把重资料放到 references/

code-review/
├── SKILL.md
└── references/
    ├── backend-style-guide.md
    ├── security-checklist.md
    ├── database-guidelines.md
    └── api-design-rules.md

SKILL.md 里可以这样引用:

When reviewing backend code, consult `references/backend-style-guide.md`.

When the change involves authentication, authorization, input validation, file upload, SQL queries, secrets, or external dependencies, also consult `references/security-checklist.md`.

When the change modifies database schema, query logic, indexes, or transactions, consult `references/database-guidelines.md`.

这样做的好处是:Claude 不会在每次代码审查时都读取所有资料,而是根据任务上下文选择相关文件。

4. 把确定性工作交给脚本

大模型擅长理解、归纳、解释和判断,但不适合做需要精确计算、严格解析和大量重复处理的工作。能用脚本稳定完成的部分,应该放进 scripts/

例如发布说明 Skill 可以用脚本解析 Git 提交:

# scripts/collect_commits.py
import subprocess
import sys

def collect_commits(start_ref: str, end_ref: str) -> str:
    result = subprocess.run(
        ["git", "log", "--oneline", f"{start_ref}..{end_ref}"],
        capture_output=True,
        text=True,
        check=True,
    )
    return result.stdout.strip()

if __name__ == "__main__":
    if len(sys.argv) != 3:
        raise SystemExit("Usage: python collect_commits.py <start_ref> <end_ref>")

    print(collect_commits(sys.argv[1], sys.argv[2]))

Claude 负责解释这些提交对用户有什么影响,脚本负责稳定地把提交列表取出来。职责分开后,结果更容易复现。

5. 固定输出模板

如果交付物有固定格式,放到 assets/ 里。

<!-- assets/release-note-template.md -->

# Version {{version}}

Release date: {{date}}

## New Features

- ...

## Improvements

- ...

## Bug Fixes

- ...

## Breaking Changes

- ...

## Deprecations

- ...

## Migration Notes

- ...

SKILL.md 中规定:

Use `assets/release-note-template.md` as the final output structure.
If a section has no relevant changes, omit that section unless it is "Breaking Changes".
Always include "Breaking Changes"; write "None" if there are no breaking changes.

模板能减少输出漂移,尤其适合团队协作场景。

Skill 的质量指标

Skill 不是写完就结束。它应该像一个小型工程组件一样被测试和调优。

可以从几个指标观察质量:

指标目标说明
相关请求触发率约 90% 或更高用户确实在请求该任务时,Skill 应该能被触发
误触发率越低越好不相关任务不应该加载该 Skill
工具调用次数越少越稳定能一次拿到数据就不要反复调用
Token 消耗可控大资料按需读取,避免无意义加载
失败 API 调用数接近 0工具参数、权限、异常处理要写清楚
用户补充指令次数越少越好Skill 应该主动询问缺失信息,而不是输出半成品
跨会话一致性稳定同类输入在不同会话中应得到结构一致的结果

测试时可以准备三类样例。

样例类型目的示例
正例验证能正确触发“根据这些 PR 生成发布说明”
反例验证不会误触发“帮我写一封给客户的道歉邮件”
边界例验证缺失信息和复杂情况“这些提交里哪些需要写进更新公告?”

一个简单测试清单:

## Trigger Tests

- [ ] 用户说“生成 changelog”时触发
- [ ] 用户说“写版本更新公告”时触发
- [ ] 用户只问“解释这段代码”时不触发
- [ ] 用户要求“写营销邮件”时不触发

## Execution Tests

- [ ] 缺少版本号时会追问
- [ ] 不会编造不存在的功能
- [ ] 会把内部重构从用户可见更新中剔除
- [ ] Breaking Changes 永远单独列出
- [ ] 输出符合模板

常见坑

Skill 做得太大

一个 Skill 只做一类任务。不要把“写代码、查日志、写文档、做运营分析、生成 PPT”都塞进一个 Skill。巨型 Skill 会带来三个问题:

  • 触发条件模糊;
  • SKILL.md 变长后模型更容易漏规则;
  • 修改一个子流程可能影响其他无关任务。

更好的做法是拆成多个微技能:

skills/
├── code-review/
├── release-notes/
├── incident-analysis/
├── api-doc-generation/
└── sql-query-check/

frontmatter 描述太泛

description 决定 Skill 什么时候被使用。描述越泛,误触发越多;描述越窄,可能漏掉相关请求。比较好的策略是写入任务类型、输入材料和用户意图,而不是只写一个抽象能力。

差:

description: Helps analyze data.

好:

description: Analyze CSV sales reports to identify revenue trends, regional performance changes, and abnormal drops. Use this skill when the user uploads sales CSV files or asks for sales trend analysis.

把资料全部塞进 SKILL.md

SKILL.md 应该像任务入口和流程说明,不应该变成知识库本体。超过几百行后就要考虑拆分。长规范、术语表、示例库、政策文件更适合放进 references/

让模型做精确计算

金额校验、日期差计算、日志解析、批量重命名、JSON 转换、依赖扫描等任务,能用脚本就用脚本。模型可以决定是否需要调用脚本,也可以解释脚本结果,但不要让模型凭自然语言“算一下”。

没有写异常处理

生产环境里的任务经常缺数据、权限不足、接口失败、输入格式不符合预期。Skill 里要写清楚异常路径。

例如:

If required inputs are missing, ask for them before producing the final output.

If an external tool fails, report:
1. which tool failed;
2. what input was used;
3. what error was returned;
4. what the user can do next.

Do not silently continue with guessed data.

过度依赖自动生成

可以让 Claude 帮忙起草 Skill,但草稿不等于可用技能。真正可用的 Skill 需要人工检查:

  • 触发描述是否准确;
  • 流程是否符合团队真实操作;
  • 参考资料有没有过期;
  • 脚本是否能运行;
  • 输出模板是否符合交付要求;
  • 是否存在安全、权限或合规风险。

组织级使用时要注意什么

个人使用 Skill,重点是提高复用效率。团队或组织使用 Skill,还要考虑治理问题。

维度需要处理的问题
版本管理Skill 修改后如何回滚,哪些项目使用哪个版本
权限控制哪些 Skill 能访问敏感系统或内部资料
审核流程新 Skill 上线前谁负责检查
更新机制参考资料和脚本变更后如何同步
日志与审计工具调用、失败记录、输出结果如何追踪
命名规范避免多个 Skill 名称相似、职责重叠
安全边界防止 Skill 引导模型执行危险命令或泄露数据

企业场景里,Skill 更像 AI 能力资产。它不只是某个人收藏的一段 Prompt,而是可以统一部署、集中维护、持续改进的工作流组件。

一个从零开始的 Skill 模板

可以用下面这个模板快速搭一个新 Skill。

---
name: your-skill-name
description: Describe the exact task, expected inputs, and user intents that should trigger this skill. Keep the scope narrow and concrete.
---

# Skill Name

## Goal

State what this skill helps Claude accomplish.

## When to Use

Use this skill when:
- ...
- ...

Do not use this skill when:
- ...
- ...

## Inputs

Expected inputs:
- ...

If required inputs are missing, ask the user for clarification before producing the final answer.

## Workflow

1. ...
2. ...
3. ...

## References

Use these files when relevant:
- `references/example.md`: ...

## Scripts

Use these scripts when deterministic processing is needed:
- `scripts/example.py`: ...

## Output Format

Follow this structure:
- ...

## Quality Checks

Before finalizing, verify:
- ...
- ...
- ...

对应目录:

your-skill-name/
├── SKILL.md
├── scripts/
├── references/
└── assets/

如果一开始没有脚本、资料或模板,可以只保留 SKILL.md。等任务变复杂后再逐步拆分。

从 Prompt Engineering 到 Workflow Engineering

Claude Skills 代表的是一种工作方式变化:重点不再只是“怎么写一句更好的 Prompt”,而是“怎么把一个任务变成稳定、可复用、可评估的工作流”。

Prompt 仍然重要,但它只是入口。真正决定 AI 能不能在复杂任务里稳定工作的,是这些工程化细节:

  • 职责边界是否清楚;
  • 触发条件是否准确;
  • 流程是否可执行;
  • 工具调用是否有顺序;
  • 资料是否按需加载;
  • 输出是否有模板;
  • 失败路径是否被定义;
  • 质量指标是否能验证。

把这些内容封装进 Skill 后,AI 才更像一个能持续工作的系统组件,而不是每次都从零开始理解任务的聊天窗口。


评论