跳转到主内容Skills：给 AI 写一本标准操作手册
日常使用篇的最后一站。
前面三篇分别讲了 CLAUDE.md（项目记忆）、命令与快捷键（操作效率）、Rules（模块化规则）。它们解决的核心问题是：让 Claude Code 知道「你是谁、项目是什么、该遵守什么规矩」。
Skills 要解决的是另一个问题：怎么让 Claude Code 按照固定流程做事。
什么是 Skill
举个场景。你每次写完文章要发布到三个平台：先转成 MDX 发到网站，再转成 HTML 发公众号，最后渲染成图片发小红书。每次你都得跟 Claude Code 解释一遍流程、格式要求、各平台的注意事项。
Skill 就是把这套流程写成一个 Markdown 文件，保存在固定位置。下次你只需要说一句「帮我发布这篇文章」，Claude Code 就会按照文件里的步骤一步步执行。
一个 Skill 就是一份给 AI 写的标准操作手册（SOP）。
跟你在公司写的 SOP 文档没有本质区别——只不过执行者从人变成了 AI。
Skill 和 Rule 有什么不同
上一篇讲的 Rules 和这篇的 Skills，初看有点像，都是 Markdown 文件，都影响 Claude Code 的行为。但它们的定位完全不同：
| 生效方式 | 始终生效，自动加载 | 按需调用，手动触发 |
| 性质 | 约束和偏好 | 工作流和步骤 |
| 类比 | 公司的规章制度 | 岗位操作手册 |
| 典型内容 | 「用中文回复」「不用 ORM」 | 「写文章的完整流程」「部署的标准步骤」 |
| 存放位置 | .claude/rules/ | .claude/commands/ 或 ~/.claude/commands/ |
简单说：Rules 管「什么能做什么不能做」，Skills 管「这件事该怎么一步步做」。
Skill 文件放在哪里
项目级：.claude/commands/（推荐）
这是 Claude Code 官方支持的自定义命令机制：
你的项目/
└── .claude/
└── commands/
├── deploy.md # 部署流程
├── review.md # 代码审查
└── new-page.md # 新建页面模板
放在项目的 .claude/commands/ 下，用 /命令名 调用。只在这个项目里生效，跟项目代码一起提交到 git，团队共享。
全局：~/.claude/commands/
如果你有跨项目通用的 Skill，放在用户级的 ~/.claude/commands/ 目录下，所有项目都能用 /命令名 调用。
~/.claude/commands/
├── scout.md # 内容调研
├── draft.md # 撰写稿件
└── publish.md # 多平台发布
两个层级可以同时用。全局放通用的，项目里放专用的。
Skill 文件怎么写
Skill 就是一个 Markdown 文件，没有严格的格式约束。但写得好不好，直接影响 Claude Code 执行的准确度。
基本结构
# 代码审查
对当前分支的改动进行代码审查，输出结构化的审查报告。
## 输入
- 当前 git 分支相对于 main 的所有改动
## 步骤
1. 运行 `git diff main...HEAD` 查看所有改动
2. 逐个文件分析，重点关注：
- 逻辑错误和边界情况
- 安全风险（硬编码密钥、SQL 注入等）
- 性能问题（N+1 查询、不必要的重渲染等）
- 代码风格是否符合项目规范
3. 汇总发现的问题，按严重程度排序
## 输出格式
### 🔴 必须修复
- [文件名:行号] 问题描述
### 🟡 建议改进
- [文件名:行号] 问题描述
### ✅ 做得好的地方
- 简要列出值得肯定的设计决策
步骤要具体。 不要写「分析代码质量」，要写「检查是否有硬编码密钥、SQL 注入风险、N+1 查询问题」。Claude Code 和人一样，指令越模糊，输出越随意。
定义好输出格式。 你希望得到一段话、一个列表、还是一个表格？明确写出来。否则每次调用格式都不一样。
写清楚前提条件。 这个 Skill 需要在什么环境下运行？需要哪些工具？有什么前置依赖？
带参数的 Skill
有些 Skill 需要接收输入参数。用 $ARGUMENTS 占位：
# 新建博客文章
根据给定的主题创建一篇博客文章的骨架。
## 输入
用户提供的主题：$ARGUMENTS
## 步骤
1. 在 `content/blog/` 下创建新的 MDX 文件
2. 文件名格式：`YYYY-MM-DD-主题关键词.mdx`
3. 生成 frontmatter（title, date, summary, tags）
4. 根据主题拟定 3-5 个小标题
5. 每个小标题下写 1-2 句引导性内容
/new-blog Claude Code 的 Skill 系统
怎么调用 Skill
无论放在项目级还是全局目录，调用方式都是 /文件名：
/deploy
/review
/new-blog 主题名称
输入 / 后 Claude Code 会自动补全可用的命令，你不需要记住每个文件名。项目级和全局的命令都会出现在补全列表里。
自己动手：写一个部署 Skill
光看不练记不住。我们来写一个实际的 Skill——项目部署命令。
假设你的项目部署流程是：提交代码 → SSH 到服务器 → 执行部署脚本。我们把它封装成一个 Skill。
第 1 步：创建文件
在项目根目录下创建 .claude/commands/deploy.md：
# 部署到生产环境
将当前代码部署到生产服务器。
## 前提检查
1. 确认当前在 main 分支
2. 确认没有未提交的改动（`git status` 应该是 clean）
3. 确认本地构建能通过（`npm run build`）
## 部署步骤
1. 将最新代码推送到远程：`git push origin main`
2. SSH 到服务器执行部署脚本：`ssh server 'cd ~/project && bash deploy.sh'`
3. 等待部署完成，检查输出中是否有错误
## 部署后验证
1. 访问网站首页确认能正常加载
2. 检查服务进程状态
3. 如果有数据库迁移，确认迁移已执行
## 失败处理
- 如果构建失败：检查类型错误，修复后重试
- 如果部署脚本报错：查看具体错误信息，不要手动操作服务器文件
- 回滚：联系我确认是否需要回滚，不要自行决定
第 2 步：调用
Claude Code 会按照文件里的步骤执行——先检查分支和状态，确认没问题才推送代码，然后 SSH 部署，最后验证。
整个过程你只需要在关键步骤（比如推送代码、SSH 执行命令）时按 y 确认。
第 3 步：迭代改进
第一次用完，你可能发现有些步骤需要调整。比如部署后还想清一下 CDN 缓存，或者想加上通知。直接改 .md 文件就行，下次调用自动生效。
更多 Skill 思路
- 代码审查 — 检查当前分支改动，按安全性、性能、可读性分类输出问题
- 写技术文章 — 从选题到大纲到正文，定义好格式和风格要求。我们团队用 Skill 封装了从调研到写稿到多平台发布的完整流程，一条命令走完全程
- 数据库迁移 — 生成迁移文件、执行迁移、验证数据完整性
- 新功能脚手架 — 创建新页面或组件时，自动生成文件结构和基础模板
- Bug 排查 — 定义排查步骤：复现 → 定位 → 查看日志 → 分析原因 → 提出修复方案
社区资源
用法很简单：找到你需要的 Skill 文件，复制到你的目录下，根据自己的项目调整内容，试跑一次，根据效果微调。
不要原封不动地用别人的 Skill。每个团队的技术栈、部署方式、代码规范都不一样，拿来之后一定要本地化。
日常使用篇回顾
四篇写下来，Claude Code 日常使用的核心能力已经覆盖了：
| 篇目 | 主题 | 解决的问题 |
|---|
| 第五篇 | CLAUDE.md | 项目记忆——不用每次重复解释背景 |
| 第六篇 | 命令与快捷键 | 操作效率——更快地完成日常操作 |
| 第七篇 | Rules | 模块化规则——按场景自动切换行为约束 |
| 第八篇 | Skills | 工作流封装——复杂任务一键执行 |
这四个能力是层层递进的关系：CLAUDE.md 让 Claude Code 理解你的项目。Rules 让它遵守你的规矩。Skills 让它按照你的流程做事。命令和快捷键则是你操控它的方式。
把这四样配好，Claude Code 就不再是一个「通用聊天机器人」，而是一个真正了解你项目、遵守你规范、能独立执行复杂任务的搭档。
下一篇开始进入进阶篇。我们会聊子智能体（Agent）——让不同的 AI 角色协作处理复杂任务，这是 Claude Code 最强大也最有意思的功能之一。
本篇要点：
- Skill 是可复用的工作流封装，本质是给 AI 写的操作手册
- Rules 管约束，Skills 管流程——两者互补
- 全局 Skill 放
~/.claude/commands/，项目级放 .claude/commands/
- 统一用
/命令名 调用
- 好 Skill 的关键：步骤具体、输出格式明确、有前提检查和失败处理
- 社区有现成 Skill 可以参考，但要根据自己的项目本地化
