Claude Code Skill 编写与应用：从自动化流程到可复用能力

Claude Code Skill 编写与应用：从自动化流程到可复用能力

前言

在使用 AI 编程助手时，我们经常会遇到一类重复任务：每次都要按照固定流程操作、每次都要读取相似资料、每次都要执行一组相似命令。比如自动发布博客、生成项目报告、检查 PR、创建标准化文档、连接浏览器完成页面操作等。

如果每次都把流程重新描述一遍，既浪费时间，也容易遗漏关键步骤。Claude Code 的 Skill 可以把这类经验沉淀成可复用能力：把"怎么做"写成结构化说明，让 AI 在合适场景自动调用，从而把一次性的提示词变成长期可维护的工作流。

本文将围绕 Skill 的编写思路、目录结构、触发方式、应用场景和最佳实践，介绍如何从零设计一个实用的 Skill。

---

一、什么是 Skill

Skill 可以理解为 Claude Code 的"专项能力包"。它通常包含一份说明文档，描述这个能力适用于什么场景、应该如何执行、有哪些参数、有哪些注意事项，以及必要时需要调用哪些工具。

它和普通 prompt 的区别在于：

对比项	普通 Prompt	Skill
使用方式	每次临时输入	可长期复用
结构化程度	依赖用户描述	有固定说明和流程
适用场景	一次性任务	重复性、流程化任务
可维护性	难以统一更新	可集中维护
团队协作	不易共享	可以沉淀为团队规范

简单来说，Prompt 更像"临时指令"，Skill 更像"可复用操作手册"。

---

二、什么时候应该编写 Skill

并不是所有任务都需要 Skill。适合抽象成 Skill 的任务通常具备以下特点：

1. 流程固定：每次执行步骤相似，例如打开页面、填写内容、点击发布。
2. 上下文复杂：需要包含大量注意事项，例如接口规范、发布规则、格式要求。
3. 容易遗漏：人工重复描述时容易漏掉某些步骤。
4. 需要工具配合：比如浏览器自动化、GitHub CLI、文件读写、命令执行等。
5. 多人复用：团队中多个人都可能用到同一套流程。

典型例子包括：

• 自动发布 CSDN 技术博客
• 根据 issue 生成实现计划
• 自动检查 PR 描述是否完整
• 将产品需求整理成测试用例
• 根据固定模板生成周报
• 自动化浏览器登录和页面操作
• 执行项目发布前 checklist

如果一个任务只是偶尔执行一次，直接写 prompt 就足够；如果它会反复出现，就值得沉淀成 Skill。

---

三、Skill 的基本结构

一个 Skill 通常位于独立目录中，目录中至少包含说明文件。不同环境的约定可能略有差异，但核心思想是一致的：让 AI 能够读懂这个 Skill 的作用、触发条件和执行流程。

一个简化结构如下：

my-skill/
├── README.md        # Skill 说明文档
├── examples/        # 示例输入输出，可选
├── templates/       # 模板文件，可选
└── scripts/         # 辅助脚本，可选

其中最重要的是说明文档。它通常应该包含：

• Skill 名称
• 适用场景
• 触发条件
• 输入参数
• 执行步骤
• 示例
• 注意事项
• 故障排查
• 输出格式

---

四、如何编写一个 Skill

下面以"自动生成并发布技术博客"的 Skill 为例，说明一个 Skill 应该如何设计。

4.1 明确目标

首先要回答：这个 Skill 到底解决什么问题？

例如：

# CSDN 自动发布博客 Skill

根据用户指定的技术主题，自动撰写一篇原创技术博客，并通过浏览器自动化发布到 CSDN。

目标要足够明确，避免写成"帮我处理博客相关任务"这种边界模糊的描述。

4.2 定义输入格式

输入格式越清晰，执行越稳定。例如：

使用格式：
主题：<技术主题>
关键词：<搜索关键词，可选>
风格：<入门/实践/源码分析/对比评测，可选>

如果用户没有提供完整字段，Skill 也可以定义默认行为，例如默认使用"实践教程"风格。

4.3 写清执行流程

执行流程应该像操作手册一样具体：

执行流程：
1. 打开 CSDN 编辑器
2. 切换到 Markdown 模式
3. 生成文章标题
4. 填入正文
5. 设置摘要和标签
6. 保存草稿
7. 点击发布
8. 获取文章链接

如果涉及浏览器自动化，还应该说明每次点击前要先获取页面快照，因为页面元素引用 ID 可能变化。

4.4 给出模板

模板能让输出更稳定。比如技术文章模板：

# <文章标题>

## 前言

说明背景和问题。

## 一、技术概述

解释核心概念。

## 二、实现原理

拆解工作机制。

## 三、实践案例

给出代码或操作步骤。

## 四、常见问题

列出排查方法。

## 五、总结

提炼核心观点。

模板不是为了限制创造力，而是为了保证基础质量。

4.5 加入故障排查

一个好用的 Skill 不只描述"成功路径"，还应该描述失败时怎么办。例如：

问题	处理方式
页面元素找不到	重新获取 snapshot
发布按钮无响应	检查必填项是否完整
浏览器连接失败	确认远程调试端口是否开启
内容未填入	检查编辑器是否为 contenteditable

故障排查越具体，自动化执行时越容易自我修复。

---

五、一个最小可用 Skill 示例

下面是一个简化版 Skill 文档示例：

# 技术博客生成 Skill

## 作用

根据用户输入的主题，生成一篇结构完整的中文技术博客。

## 触发条件

当用户要求"写一篇技术博客""生成博客文章""整理成 CSDN 文章"时使用。

## 输入

- 主题：必填
- 关键词：可选
- 文章风格：可选，默认实践教程

## 执行步骤

1. 分析主题所属技术领域
2. 设计文章标题
3. 按照"前言、概述、实现、实践、总结"结构生成正文
4. 添加代码块或表格
5. 生成摘要、标签和参考资料

## 输出格式

- 标题
- Markdown 正文
- 摘要
- 推荐标签

这个示例虽然简单，但已经具备 Skill 的核心要素：目标、触发条件、输入、流程和输出。

---

六、Skill 的实际应用场景

6.1 内容生产自动化

比如自动写博客、生成公众号草稿、整理会议纪要、生成 FAQ。Skill 可以统一文章结构和表达风格，减少重复排版成本。

6.2 研发流程自动化

例如：

• 创建 PR 前自动检查改动范围
• 根据 diff 生成测试计划
• 根据 issue 生成实现方案
• 发布前执行 checklist
• 根据错误日志生成排查步骤

这类 Skill 的价值在于把团队经验固化下来，让新人也能按相同标准执行。

6.3 浏览器操作自动化

如果配合浏览器自动化工具，Skill 可以完成网页中的重复操作，例如登录后台、填写表单、截图验证、发布文章等。

需要注意的是，浏览器页面元素经常变化，因此 Skill 中应明确要求"点击前先获取页面快照"，不能依赖固定元素 ID。

6.4 数据整理与格式转换

例如把接口文档转成 Markdown、把 CSV 分析成报告、把日志归类为问题类型、把需求列表转成测试用例。Skill 可以定义统一的输入输出格式，让结果更稳定。

---

七、编写 Skill 的最佳实践

7.1 只做一类事情

一个 Skill 不应该什么都做。比如"自动发布博客"和"代码安全审计"应该是两个 Skill，而不是混在一起。

好的 Skill 应该有清晰边界：

• 什么时候使用
• 什么时候不使用
• 输入是什么
• 输出是什么

7.2 步骤要具体，不要只写原则

不要只写：

请发布博客。

应该写成：

1. 打开编辑器
2. 获取页面快照
3. 查找标题输入框
4. 填入标题
5. 查找 Markdown 编辑区
6. 填入正文
7. 保存草稿
8. 发布并获取链接

AI 擅长执行明确流程，但不应该让它猜关键步骤。

7.3 把动态信息写成规则

例如页面元素 ID 会变化，不要在 Skill 中固定写死某个 ref，而应该写：

每次页面变化后都必须重新执行 snapshot -i，获取最新 ref 后再点击。

这类规则比一次性的示例更重要。

7.4 提供成功标准

Skill 最后应该说明什么叫完成：

• 是否生成了文章
• 是否保存了草稿
• 是否成功发布
• 是否拿到了链接
• 是否需要输出摘要

没有成功标准，执行结果就很难判断。

7.5 控制复杂度

Skill 不是越长越好。一个实用 Skill 应该包含足够信息，但避免把无关知识都塞进去。建议遵循：

• 高频规则写进 Skill
• 低频背景放到参考资料
• 可变内容通过参数传入
• 长模板可以拆到 templates 目录

---

八、常见问题

8.1 Skill 和脚本有什么区别？

脚本适合确定性强的任务，例如格式化文件、调用 API、批量重命名。Skill 更适合包含判断、写作、阅读、浏览器操作和多步骤协作的任务。

实际项目中，两者可以结合：Skill 负责决策和流程编排，脚本负责稳定执行某个具体动作。

8.2 Skill 会不会让 AI 变得死板？

如果 Skill 写得太死板，会。但好的 Skill 应该定义边界和关键流程，同时允许在内容生成、异常处理和结果表达上保持灵活。

8.3 一个 Skill 应该多长？

没有固定长度。判断标准是：一个新使用者只看 Skill 文档，能不能稳定完成任务。如果不能，就需要补充流程、示例或故障排查；如果已经包含大量无关内容，就应该拆分。

8.4 是否需要为每个任务都写 Skill？

不需要。只有重复、高价值、容易出错或需要团队统一规范的任务，才值得沉淀成 Skill。

---

九、从一次性 Prompt 到 Skill 的演进路径

可以按照以下路径逐步沉淀：

临时 Prompt
   ↓
整理出固定步骤
   ↓
补充输入输出格式
   ↓
加入示例和模板
   ↓
加入异常处理
   ↓
形成可复用 Skill

不要一开始就追求完美。最好的方式是先从真实任务中提炼，执行几次后再不断修正。

---

十、总结

Skill 的核心价值，是把重复性的 AI 协作经验变成可复用、可维护、可传播的能力。它不是简单的长 prompt，而是一份面向任务的操作规范。

一个优秀的 Skill 应该做到：

• 目标明确
• 触发条件清晰
• 输入输出稳定
• 执行步骤具体
• 有模板和示例
• 有故障排查
• 有完成标准

当团队开始把高频工作沉淀成 Skill，AI 就不再只是"临时问答工具"，而会逐渐变成围绕业务流程运行的自动化协作层。

---

参考资料

• Claude Code 官方文档：https://docs.anthropic.com/en/docs/claude-code
• Anthropic 官方文档：https://docs.anthropic.com/
• Chrome DevTools Protocol：https://chromedevtools.github.io/devtools-protocol/