你有没有这种感觉？明明昨天刚让Claude帮你改过那段代码的注释风格，今天换了新项目，又得从头给它讲一遍“请用Google风格写注释”、“别用尾随逗号”、“函数命名用驼峰”……每次都得把同样的话像念经一样重复一遍。

我受够了。

上个月团队来了三个新人，我一边要带他们，一边还要应付手头的重构任务，每天光在Claude里重复输入“上下文指令”的时间加起来都快两个小时了。后来实在忍不了，花了一个周末研究了一下Claude的Skill功能，现在总算把那些烦人的“重复提问”彻底关进了小黑屋。

今天这篇教程，我就用我自己最常做的一个“代码审查工作流”当例子，手把手教你如何把那些需要反复交代的背景、规则、流程，一次性打包成一个Skill。以后只要说一句“帮我review这段代码”，Claude就会自动按照你的标准干活，再也不用你啰嗦半个字。

---

第一步：先想清楚“重复提问”到底重复在哪儿

在动手之前，我拿了一张纸，把自己每天跟Claude的对话翻了一遍。发现重复提问主要集中在三类场景：

1. 角色设定类：每次写周报都得说“你是资深技术经理，请帮我总结本周工作”。

2. 格式规范类：每次生成接口文档都要强调“输出Markdown表格，包含参数、类型、必填、描述四列”。

3. 流程约束类：每次做代码审查都得告诉它“先看安全性，再看性能，最后看可读性，用三级标题输出”。

如果你也跟我一样，那恭喜你，这三类问题用Skill都能完美解决。

第二步：建一个“代码审查”Skill，让Claude记住你是谁

我管这个Skill叫 code-review-buddy。先在本地新建一个文件夹，名字随意，比如 my-skills，在里面建一个子文件夹 code-review-buddy。

关键一步：在这个子文件夹里创建一个文件，名字必须是 SKILL.md（全大写），因为Claude在扫描Skill包时，首先找的就是这个入口文件。

我的 SKILL.md 长这样，你可以直接复制，然后按你的习惯改：

---
name: Code Review Buddy
description: 专业的代码审查助手，遵循团队的代码规范和安全要求。当用户提到“review代码”、“审查”、“CR”时激活。
---

# 你是谁
你是一个拥有10年经验的资深后端工程师，精通Java、Python和Go。你对代码质量有洁癖，但说话温和，注重建设性建议。

# 审查流程（必须严格遵守）
当收到待审查代码时，按以下顺序执行：

1. **安全漏洞优先**：检查SQL注入、XSS、敏感信息泄露、权限绕过等。如果有任何安全问题，直接用 `[高危]` 标记，并放在报告最前面。
2. **性能隐患**：找出可能引起性能问题的点（如循环内查询数据库、大对象未释放等），用 `[性能]` 标记。
3. **代码规范**：对照Google代码规范（Java/Python/Go）检查命名、注释、格式。如果有不符合的地方，指出并给出修改建议。
4. **可维护性**：评估函数长度、圈复杂度、重复代码等，提出重构建议。

# 输出格式
请严格按照以下结构输出：

## 总体评价
一句话概括代码质量（优/良/中/差）。

## 问题列表
| 级别 | 位置 | 问题描述 | 建议 |
|------|------|----------|------|
| 高危/性能/规范/可维护 | 文件名:行号 | 具体问题 | 如何修改 |

## 优化后代码示例（可选）
如果发现问题较多，提供一个修改后的代码片段。

# 禁止事项
- 不要夸奖代码写得“不错”却没有具体理由。
- 不要输出与代码审查无关的内容，比如闲聊。
- 如果代码不完整，不要猜测，直接指出缺少上下文。

写完这个文件，你的Skill核心就已经完成了。不需要写一行代码，它就能让Claude变身成一个严格遵守你规则的审查专家。

第三步：让Skill真正“跑”起来——给Claude喂饭

有两种方法把Skill喂给Claude，我两种都用过，给你说说区别。

方法一：Project方式（推荐长期使用）

如果你是Claude Pro用户，并且经常要用这个Skill，建议建一个Project：

1. 在Claude左侧菜单点击“Projects” -> “Create Project”。

2. 把 code-review-buddy 整个文件夹拖进Project的“Knowledge”区域。

3. 在System Prompt里简单写一句：“激活 code-review-buddy 技能，严格按照SKILL.md定义执行。”

这样，以后你在该Project里的所有对话，Claude都会自动加载这个Skill，你不用再重复说任何话。

方法二：直接上传（适合临时使用）

如果只是想试试效果，直接在普通对话窗口上传 SKILL.md 文件，然后说：

“这是我要用的技能，现在请帮我审查以下代码：……”

注意：这里有个小坑——如果你只上传 SKILL.md，Claude有时会把它当成普通文件，而不是加载为Skill。我摸索出来的经验是：先上传文件，然后立刻说“请加载这个Skill”，成功率最高。

第四步：实战——看看它是不是真能干活

我来演示一遍。我随便写了一段有问题的Python代码（故意埋了几个坑），然后对Claude说：“帮我review一下这段代码。”

def get_user_data(user_id):
    query = "SELECT * FROM users WHERE id = " + user_id
    conn = get_db_conn()
    cursor = conn.cursor()
    cursor.execute(query)
    return cursor.fetchall()

Claude（激活Skill后）给我的输出是这样的：

总体评价

差。存在严重安全漏洞和性能隐患。

问题列表

级别	位置	问题描述	建议
高危	第2行	SQL注入漏洞：直接拼接字符串	改用参数化查询
性能	第3-5行	未关闭数据库连接，可能导致连接池耗尽	使用with语句或确保在finally中关闭
规范	第1行	函数缺少类型注解	添加参数类型和返回值类型

优化后代码示例

def get_user_data(user_id: int) -> list:
    query = "SELECT * FROM users WHERE id = %s"
    with get_db_conn() as conn:
        with conn.cursor() as cursor:
            cursor.execute(query, (user_id,))
            return cursor.fetchall()

看到了吗？它完全遵循了我SKILL.md里规定的流程：先查高危，再查性能，最后说规范，格式也完全是表格。最关键的是，我一个字都没重复说明这些规则。

第五步：进阶——让Skill动起来（集成外部脚本）

有些工作流光靠“说话”还不够，比如审查完代码后，你想让Claude自动把报告保存到本地，或者调用一个公司的API登记审查记录。这时候就要在Skill里加脚本了。

我在 code-review-buddy 文件夹里放了一个 save_report.py：

import sys
import json
from datetime import datetime

def save_report(report_text):
    filename = f"code_review_{datetime.now().strftime('%Y%m%d_%H%M%S')}.md"
    with open(filename, 'w', encoding='utf-8') as f:
        f.write(report_text)
    print(f"报告已保存至 {filename}")

if __name__ == "__main__":
    if len(sys.argv) > 1:
        save_report(sys.argv[1])
    else:
        print("无报告内容")

然后在 SKILL.md 的末尾加上一段：

# 自动保存
在生成审查报告后，你必须执行以下操作：
1. 询问用户：“是否需要将报告保存为Markdown文件？”
2. 如果用户同意，使用Python脚本 `save_report.py` 保存完整报告内容。

这样，Claude在输出报告后会主动问你要不要保存，如果你说“保存”，它就会给出运行脚本的命令。在Claude桌面版或者支持命令执行的环境里，你点一下就能自动保存，非常方便。

第六步：几个让你少走弯路的小经验

我做完第一个Skill时挺得意，结果用了一个礼拜，发现了一些小问题，后来通过不断调整 SKILL.md 解决的。分享给你，帮你避开我踩过的坑：

1. 规则要具体，别让AI猜
   最开始我写“检查代码可读性”，Claude有时候说“变量名可以更有意义”，有时候说“建议加注释”。后来我改成“变量名必须至少3个字符，禁止使用单字母变量（除了循环变量i、j）”，它就不含糊了。

2. 给AI留个“免死金牌”
   在SKILL.md里加一句“如果用户明确要求跳过某个步骤，优先服从用户”。不然有时候你想临时让它只看安全性，它会倔强地按完整流程走，很烦。

3. 定期更新SKILL.md
   团队规范在变，你的Skill也得跟着变。我习惯在SKILL.md最上面加一个“版本号”和“最后更新日期”，每次修改时更新一下，方便追踪。

4. Skill不是越多越好
   我一开始恨不得每个场景都做一个Skill，结果对话时经常搞不清激活了哪个。后来我把功能相近的合并，比如“代码审查”和“重构建议”放在一个Skill里，通过关键词区分，管理起来轻松多了。

写在最后

现在，我每天打开Claude，不再需要像传教士一样念叨那些重复的规则。一句“帮我review这段代码”或“写周报”，它就知道该用什么样的语气、什么样的格式、什么样的流程来干活。

这种感觉就像是给Claude发了一张“上岗证”，它终于变成了真正了解我工作习惯的专属助手。

其实Skill的门槛比你想象的低得多。你不需要会写复杂的代码，只要会用Markdown把你的工作流程写清楚，Claude就能学会。如果你平时有那种“每次都要重复说一遍”的场景，不妨花半小时试试看。

还是那句话，好的工具不是让你变得更忙，而是让你忙得有价值。希望这篇教程能帮你省下那些重复提问的时间，去做点更有意思的事。

如果你在折腾Skill的过程中遇到什么奇奇怪怪的问题，欢迎留言，我会把我知道的（和踩过的坑）都告诉你。