我们学习了一系列关于 SKILL 技能的知识,但在实际项目开发中,常常觉得“用不上”、“没必要”,或者找不到非做不可的理由。
产生这些想法,很大程度上是因为我们开发者总是忙于一个接一个的项目,日复一日,却缺少了系统性的复盘总结。又或者,每天被工作和生活琐事填满,身心俱疲,实在没有精力再去梳理项目开发中遇到的零碎问题。打工人也需要休息……
在 AI 出现之前,这种状态或许还能接受,毕竟历史代码都在,大不了以后花时间慢慢找。但 AI 时代已经来临,我们需要把精力聚焦在真正重要、创造性的工作上,将重复性任务交给 AI 处理。作为开发者,我们必须打造自己的核心竞争力,去做 AI 目前难以替代的事情。如果依然重复那些 AI 也能轻松完成的工作,我们终将被时代淘汰。
AI 时代的程序员,是时候重新定义自己的价值了。
为什么要把工作流变成 SKILL?
你是否遇到过这种情况:每次使用 AI,都要重新解释一遍项目背景,写一长串 Prompt,拿到结果就结束对话。第二天遇到同样的事情,又得从头再来。甚至有时候,相同的提示词给出的结果却不一样,不得不开启新一轮,甚至多轮对话才能解决问题。
这样使用 AI 效率低下,我们处于被动局面,非常影响开发体验和心情。
将工作流固化为 SKILL 后,你只需要对 AI 说一句话,它就能自动执行整个流程。例如“发布这篇文章到微信公众号”,AI 便会知道需要读取文件、转换格式、调用 API、处理错误等一系列操作,无需你一步步指导。
什么时候值得做成 SKILL?
并非所有任务都值得封装成 SKILL。通常,满足以下条件的工作流才值得投入精力:
- 重复发生:一周内至少使用 3 次以上。
- 流程固定:步骤基本不变,只是每次的输入内容不同。
- 容易出错:手动操作时容易遗漏步骤或犯错。
- 有明确边界:能清晰定义技能的使用场景和限制。
正面例子:每次发布文章到微信公众号,都需要读取 Markdown、转换为 HTML、上传图片、调用 API。这个流程固定,但手动操作易出错。将其封装成 wechat-publisher 技能后,一句话即可搞定。
反面例子:偶尔写一封邮件或查一次资料,这类一次性的任务就不值得做成 SKILL。
工具和资源
skill-writer:帮你撰写 SKILL.md
skill-writer 是一个现成的技能,专门帮助你创建新技能。它会:
- 询问你技能的目标和使用场景。
- 帮你生成符合规范的
SKILL.md 文件框架。
- 指导你设计技能的整体结构。
使用方法很简单,直接对 Claude 说:
使用 skill-writer 技能,帮我创建一个代码审查助手技能
skill-writer 会通过几个问题了解你的需求,然后生成 SKILL.md 的骨架,你只需在此基础上填充具体内容即可。
skill-creator:完整的技能脚手架
skill-creator(官方出品)提供了更完整的技能创建流程,包括:
init_skill.py:自动创建技能目录结构。
- 标准的文件夹组织(如
scripts/、references/、assets/)。
SKILL.md 模板。
如果你需要创建结构复杂、涉及多个脚本和模板文件的技能,使用 skill-creator 会更省事。
MCP:连接外部世界
MCP(Model Context Protocol)使得 Claude 能够调用外部服务。常用的 MCP 服务器包括:
- GitHub MCP:操作 Issue、创建 PR、搜索代码库。
- Playwright MCP:自动化网页测试、数据抓取。
- 数据库 MCP:执行 SQL 查询、操作数据库。
当你的工作流需要调用外部 API、操作数据库或进行网页自动化时,就需要配置相应的 MCP 服务器。
CLAUDE.md、AGENTS.md 与 Cursor Rules:项目的“长期记忆”
这三个文件并非技能,而是 Claude 的“长期记忆”:
CLAUDE.md:定义项目级别的规范,如编码风格、测试命令、构建流程。
AGENTS.md:记录你的个人偏好和习惯,当 Claude 出错并被你纠正后,相关信息会记录于此。
Cursor Rules:在 Cursor 编辑器中,记录项目的一系列特定规范与要求。
这些文件会被不同的 AI 编辑工具读取,用以记住项目上下文,避免每次都需要重新解释。
不过个人认为,在日常开发中,如果你通常只给出简短的指令或功能描述,那么这类项目记忆文件的使用频率可能不高。它们更适合团队协作或需要严格统一规范的项目。对于个人随性的“Vibe Coding”,是否添加完全取决于你的个人习惯——有人认为有备无患,有人则认为无需多此一举。
如何把工作流转换成 SKILL:四步法
第一步:识别工作流的边界
首先,明确该工作流的输入、输出和触发条件:
- 输入是什么?(例如:文件路径、参数、配置项)
- 输出是什么?(例如:生成的文件、API 调用结果、系统状态变更)
- 什么时候使用?(触发条件)
- 什么时候不使用?(边界情况和限制)
以“代码审查助手”为例:
- 输入:待审查的代码文件路径。
- 输出:格式化的审查报告(Markdown)。
- 触发:用户说“审查这段代码”、“检查代码质量”。
- 边界:仅提供审查建议,不直接修改代码。
第二步:拆解成具体步骤
将工作流分解为可独立执行的步骤,并为每个步骤明确:
- 要做什么。
- 需要什么工具或操作(读取文件、执行脚本、调用 API)。
- 可能出现的错误。
- 错误发生时的处理方式。
以 wechat-publisher 为例,其步骤可拆解为:
- 读取 Markdown 文件。(可能失败:文件不存在)
- 获取微信 Access Token。(可能失败:配置错误)
- 上传封面图片。(可能失败:图片格式不支持)
- 将 Markdown 转换为 HTML。(可能失败:内容格式异常)
- 调用微信 API 创建草稿。(可能失败:网络错误)
每个步骤都应有对应的错误处理逻辑,并且脚本需要通过退出码明确告知 AI 执行成功(0)或失败(非 0)。
第三步:设计技能结构
根据技能的复杂度,选择合适的目录结构:
简单技能(仅包含指令,无需脚本):
skill-name/
└── SKILL.md
中等技能(需要辅助脚本):
skill-name/
├── SKILL.md
└── scripts/
└── helper.py
复杂技能(需要多种资源):
skill-name/
├── SKILL.md
├── scripts/
│ └── main.py
├── templates/
│ └── template.html
└── reference.md
第四步:编写 SKILL.md
SKILL.md 是技能的核心,需要清晰描述以下内容:
- name 和 description:技能的名称、功能概述以及最重要的——何时使用。
- 触发条件:用户说哪些话时,会激活这个技能。
- 工作流程:技能执行的具体步骤。
- 工具使用:需要用到哪些工具(如 Read、Write、
run_command 等)。
- 错误处理:可能遇到的错误及应对策略。
其中,description 字段至关重要,必须包含触发信息。例如:
description: 将Markdown内容一键推送到微信公众号草稿箱。支持自动排版、样式映射以及草稿管理。用户提到“发布到公众号”、“存为草稿”、“同步到微信”时激活此技能。
这样,Claude 才能准确判断何时应该调用这个技能。清晰的技术文档是技能成功的关键,你可以在云栈社区的技术文档板块找到更多关于编写优秀文档的指南。
常见问题和避坑指南
问题 1:技能不生效
可能原因:
SKILL.md 中的 description 未包含足够的触发关键词。
- 技能文件未放在正确目录(应为
.claude/skills/ 或 ~/.claude/skills/)。
- 需要重启 Claude Code 以加载新技能。
解决方案:检查 description 字段,确保其涵盖了用户可能使用的语句。如果是新增技能,尝试重启 AI 工具。
问题 2:脚本执行失败但没有报错
脚本必须有明确的退出码:
sys.exit(0) 表示成功。
sys.exit(1) 或其他非零值表示失败。
如果脚本执行失败却返回了 0,AI 会误以为任务成功,不会进行重试或报错。
问题 3:技能太复杂,一次做不完
采用迭代开发思路,先实现一个能跑通的最小可行版本(MVP)。例如,开发“代码审查助手”:
- v1.0:只检查基本的语法错误。
- v2.0:增加代码风格检查(如 PEP 8)。
- v3.0:加入性能优化建议。
切忌一开始就试图打造一个“全能”的技能。
问题 4:不知道如何下笔写 SKILL.md
使用 skill-writer 技能来辅助。直接对 AI 说:
使用 skill-writer 技能,帮我创建一个 [你的技能名] 技能
skill-writer 会通过问答引导你,并生成一个结构化的框架,你只需填充细节即可。
问题 5:需要调用外部 API 但不知如何集成
有两种主要方式:
- 使用脚本:在技能的
scripts/ 目录下编写 Python 或 Shell 脚本,在脚本内部调用 API。
- 使用 MCP:如果该 API 调用非常频繁或需要复杂的状态管理,可以为其开发一个专用的 MCP 服务器。
对于简单的、一次性的调用,使用脚本更快捷;对于复杂的、需要复用的接口,则推荐使用 MCP。
基础实战:创建一个简单的技能
假设你需要一个“自动生成 Git Commit Message”的技能(许多 AI 编辑工具已内置此功能)。但如果你使用的是 Claude Code、Gemini 3 等命令行工具,或者团队对提交信息有特殊的定制化要求(这非常有利于在大型项目或协作中追溯功能代码),那么创建这样一个技能就很有必要。
1. 确定需求
- 输入:当前
git diff 的内容。
- 输出:符合 Conventional Commits 规范的提交信息。
- 触发:用户说“生成 commit message”、“写提交信息”。
2. 创建技能目录
mkdir -p .claude/skills/commit-message-generator
3. 编写 SKILL.md
在 .claude/skills/commit-message-generator/ 目录下创建 SKILL.md 文件,内容如下:
---
name: commit-message-generator
description: 根据 git diff 自动生成符合规范的 commit message。用户提到“生成 commit message”、“写提交信息”、“自动提交”时激活此技能。
---
# Commit Message Generator
## 工作流程
1. 读取当前 git diff(使用 run_command 执行 `git diff`)
2. 分析变更内容(新增、修改、删除的文件和代码)
3. 生成符合 Conventional Commits 规范的 commit message
4. 输出格式:`<type>(<scope>): <subject>`
## 示例
用户说:“生成 commit message,信息标题前置XXX”,那么提交的git信息的前面就需要加上 XXX -
比如说:生成 commit message,git信息前置登录页面,那么提交的git信息就是类似:feat(api):登录页面-页面初始化与接口对接
Claude 会:
1. 执行 `git diff` 获取变更
2. 分析变更内容
3. 生成类似 “feat(api): XXX - 添加用户登录接口” 的 message
4. 测试
直接对你的 AI 编辑工具说:“使用 commit-message-generator 生成 commit message,信息标题前置项目优化”,观察其是否能正确工作。


5. 迭代优化
如果生成的提交信息不够理想,可以回头修改 SKILL.md,增加更详细的规则和更多的示例。
进阶技巧
组合多个技能
复杂的任务可能需要多个技能协同完成。例如,“发布文章到多平台”可能涉及:
wechat-publisher:发布到微信公众号。
xhs-style-generator:生成小红书风格的文案。
docx-exporter:生成 Word 文档版本。
Claude 可以自动识别并组合这些技能,串联起整个发布流程。
使用脚本处理复杂逻辑
如果工作流中包含复杂的逻辑(如正则表达式替换、数据格式转换),建议将这些逻辑封装在独立的脚本中,而不是全部堆砌在 SKILL.md 里。
例如,wechat-publisher 中涉及 Markdown 到 HTML 的转换,并需要注入特定的内联样式,这种包含正则表达式的处理逻辑,写在 Python 脚本里会更清晰、更易维护。这本身就是一次小型的开源实战。
配置和敏感信息管理
切勿将 API Key、密码等敏感信息硬编码在脚本中。推荐使用 .env 文件来管理环境变量:
import os
from dotenv import load_dotenv
load_dotenv()
app_id = os.getenv('WECHAT_APP_ID')
然后在项目根目录创建 .env 文件:
WECHAT_APP_ID=your_app_id
WECHAT_APP_SECRET=your_secret
重要:务必记得将 .env 文件添加到 .gitignore 中,避免将其提交到公开的代码仓库。
总结
将工作流转化为 SKILL 的核心思路如下:
- 识别重复:优先将每周使用超过 3 次的任务自动化。
- 明确边界:清晰定义技能的使用场景和限制条件。
- 拆解步骤:将流程分解为原子操作,并为每一步设计错误处理。
- 最小闭环:先打造一个可运行的最小版本,再逐步迭代增强功能。
- 善用工具:利用
skill-writer 辅助设计,用脚本封装复杂逻辑。
如果你发现某个操作在短时间内重复了多次,不妨停下来,思考如何将其封装成技能。这不仅能解放你的时间,更能让你专注于更具创造性和价值的核心工作。
在 AI 时代,我们需要紧跟技术浪潮,持续学习、尝试、沉淀,通过改变工作方式来提升自我价值。
本文旨在分享 AI 技能开发实践,更多开发者干货、实战讨论与开源项目,欢迎访问 云栈社区 进行交流。