每次打开终端，面对 Claude Code 的输入框，我总要先在脑子里把想说的话翻译成英文。改个代码要敲“refactor this function to handle null case”，审查代码要敲“review the diff and find potential bugs”。半天工作下来，真正消耗精力的不是写代码，而是反复组织英文提示词。后来我索性把日常最常用的 10 个操作，全部做成了中文命令，装进了 Claude Code 的.claude/commands目录。现在敲两个斜杠加一个词，AI 就知道该干什么，输出格式也固定了，效率直接提升一个档次。
这篇文章就是把我的完整实践记录整理出来：为什么要这么做、10 个命令分别是啥、命令文件怎么写、真实项目里表现如何、还有哪些坑需要注意。适合已经装好 Claude Code、想在 AI 编程工作流里再省一层力的朋友，尤其是习惯用中文思考、但每天被英文提示词折磨的开发者。
1. 为什么要把工作流“打包”成中文命令
1.1 终端里的 AI 搭子，值得有一份母语说明书
先说一个反直觉的结论：用母语写提示词，效果通常比用英文更好。不是英文不行，而是当你用英文表达时，会不自觉地简化描述。举个例子，你想让 AI 审查代码里有没有并发隐患，脑子里想的是“看看这个函数在多线程环境下会不会出问题，共享变量是不是没有加锁，竞态条件有没有处理”，一翻译就变成了“check thread safety”，细节全丢了。用中文写命令文件，相当于把完整的、严密的审查逻辑写给 AI，它照着执行，比你现场组织语言要靠谱得多。
而且中文命令的学习成本几乎为零。团队里任何一个同事，不需要懂英文，看到/评审代码、/补测试就知道是干嘛的。相比之下，光解释“slash command 是什么”就要花不少口舌。我自己测下来的感受是：Claude Code 对中文的理解能力比很多人想象中要强，无论是识别指令、分析代码还是生成中文提交信息，都很自然。既然如此，为什么不用自己最舒服的语言？
1.2 Claude Code 自定义命令的底层机制
先补一个基础概念：Claude Code 支持自定义斜杠命令。你在项目根目录建一个.claude/commands文件夹，把 Markdown 文件丢进去，文件名就是命令名，文件内容就是提示词模板。比如建一个commit.md，在 Claude Code 输入框里敲/commit，AI 就会按这个文件里的指令执行。
每个命令文件还可以通过$ARGUMENTS变量接收用户输入，比如/评审代码 重点检查安全，后面那段“重点检查安全”就会传给命令文件。更妙的是，命令文件不是单纯的提示词，它可以在描述里要求 AI 执行工具调用，比如“先运行git diff”“先读取src/main.py”，Claude Code 会自主完成这些操作。这很像给 AI 写了一份岗位说明书：“你的职责是什么、流程怎么走、报告怎么写”，AI 会按流程执行，而不是每次重新讨论。
这个机制决定了：命令文件写得越具体，输出越稳定。你临时说一句“帮我看看这段代码”，和你通过命令文件说“先分析 git diff、再按安全维度逐条审查、最后按 P0/P1/P2 分级输出”，结果完全不是一个水平线。
2. 10 个命令的设计清单：覆盖我 80% 的日常编程动作
2.1 命令总表
先说结论：我只做了 10 个，因为我的动作频率表里，超过 80% 的重复工作就集中在这些场景。命令太多会有记忆负担，太少又覆盖不了日常工作。下面这 10 个命令，是我用了两周后留下来的一版：
| 命令名 | 文件 | 用途 | 触发场景 |
|---|---|---|---|
/review | review.md | 审查代码改动，按严重程度分级输出问题 | 提交代码前、合并分支前 |
/commit | commit.md | 根据 git 改动生成中文提交信息 | 每次 commit 前 |
/explain | explain.md | 讲解指定代码的实现思路 | 接手新模块、读不懂老代码 |
/debug | debug.md | 定位 bug 根因并给出修复方案 | 测试挂了、线上出问题 |
/test | test.md | 为指定函数或模块补单元测试 | 新增功能、提高覆盖率 |
/refactor | refactor.md | 小步重构，保持行为不变 | 清理坏味道、降低复杂度 |
/changelog | changelog.md | 根据提交记录生成更新日志 | 发版本前 |
/docs | docs.md | 根据代码生成或更新文档 | 写 README、整理接口文档 |
/db | db.md | 梳理数据库脚本，检查索引和迁移 | 写 SQL、改表结构 |
/release | release.md | 上线前的完整检查清单 | 发布前最后过一遍 |
2.2 设计原则：命令是“流程”，不是“对话”
设计这套命令时我守了三条原则，分享出来供参考。
第一，一个命令只解决一个高频动作。我不会把“审查代码 + 补测试 + 生成提交信息”揉在一起，因为组合场景太少了。分开的好处是命令文件可以写得更短更清晰，AI 不容易俘虏。
第二，强制固定输出格式。比如/review的输出必须按“P0/P1/P2”分级，/commit必须按 conventional commits 格式，/release必须一条条核对检查项。这就让 AI 的输出像机器一样稳定，方便我扫一眼就知道结果，而不是每次重新解析它吐出来的一堆废话。
第三，命令之间尽量减少重叠。/explain侧重“讲清楚做什么”，/debug侧重“找出为什么坏”，/refactor侧重“怎么改更干净”。边界一旦模糊，同一个任务就可能被重复执行，既浪费时间又容易产生冲突。
另外补充一点：这 10 个命令全部用中文写提示词，命令名却用英文，原因后面详细说。
3. 命令文件怎么写：从一条提示词到一套可复用模板
3.1 最简命令：提交信息生成器
先看一个最基础的例子。我的/commit命令文件内容如下：
--- description: 根据 git 改动生成中文提交信息 --- 根据当前 git 暂存区的改动，生成一段规范的提交信息。 要求： 1. 使用 conventional commits 格式，类型必须是 feat / fix / docs / refactor / test / chore 中的一种 2. 主体用中文描述改动内容，不超过 50 字 3. 如果改动涉及多个方面，用 bullet 列出要点 4. 不要生成多余的换行和签名 额外说明：$ARGUMENTS文件头部用---description---声明命令的用途，方便在命令面板里预览。正文就是写给 AI 的提示词。最后一行预留了$ARGUMENTS，这样我输入/commit 类型为 fix时，AI 会优先按我的补充执行。
这个命令我用了很久，最大的价值是解决了“提交信息随缘”的问题。以前 commit message 经常写“update code”“fix bug”，现在 AI 会自己先跑git diff --staged，再按规范生成中文描述，提交历史干干净净。
3.2 带参数的命令：代码审查怎么写得有章法
/review是这套命令里最复杂的之一，因为它既要控制审查范围，又要约束输出格式。我给它设计了两层参数：文件级范围和关注重点。
--- description: 审查代码改动，按严重程度分级输出问题 --- 你是一位拥有 10 年经验的资深代码审查员。请审查代码并输出结构化报告。 审查范围： - 如果没有额外指定，默认审查当前分支与主分支的差异 - 用户指定：$ARGUMENTS 审查维度： 1. 逻辑正确性：边界条件、空指针、并发竞态 2. 安全性：注入、敏感信息泄露、越权访问 3. 可维护性：命名、重复代码、复杂度 4. 性能：循环嵌套、N+1 查询、无谓的对象创建 输出要求： - 问题按严重程度分级：P0 必须修复、P1 建议修复、P2 可选优化 - 每条问题必须包含：文件与行号、问题描述、修复建议 - 最后输出一段总体结论，说明当前代码是否可以合并用起来很简单：/review默认审查整个分支的改动；我也可以输入/review login.js auth.js只审查这两个文件，或者/review 重点关注并发安全临时切换审查重点。$ARGUMENTS的存在让命令在保持固定流程的同时，不至于太死板。
3.3 用 CLAUDE.md 给命令提供项目背景
命令文件如果写得再长，也只能描述通用流程。真正的项目背景——比如目录结构、技术栈、代码规范——应该放在CLAUDE.md里。Claude Code 每次也会读取这个文件，把它和命令文件结合，相当于“项目说明书 + 岗位说明书”。
比如我有个旧项目用了很奇怪的命名惯例，控制器里写业务逻辑。如果命令文件不提，AI 会按通用最佳实践提一堆重构建议，实际上在这套代码里根本行不通。我在项目的CLAUDE.md里注明“controller 为业务逻辑层，命名遵循 xxxController，禁止在 service 层直接操作数据库”，后续/review和/refactor的表现立刻变得贴合实际。
所以我的建议是：**命令文件聚焦“怎么执行”，CLAUDE.md 聚焦“项目是什么”。**两者配合起来，效果远大于单独使用。
3.4 把命令同步给团队：工具包化
.claude目录可以提交到 Git 仓库，这样只要队友拉取了代码，就自动拥有了这一整套命令。我特意把所有命令稳定下来后才提交，避免团队成员的命令定义不一致导致结果千奇百怪。新版编辑器也支持把命令分享成链接，但仓库同步仍然是最简单、最不容易失效的方式。
4. 实测记录：这些命令在真实项目里表现如何
4.1 重构遗留代码时的高光时刻
有一个老模块，几千行代码塞在三个文件里，逻辑混乱到我接手时根本不敢动。当时我用/refactor指定先重构其中一个文件，要求“保持外部行为不变，逐步拆出纯函数，每步都要说明改动理由”。
Claude Code 先读取了文件，然后给出拆解方案，分三步执行：先把 Redis 操作抽成独立函数，再把业务分支合并成几个状态机分支，最后把重复的校验逻辑合并。每步都做了小范围改动，跑测试确认无误后继续下一步。如果是靠我手动敲提示词，可能第二次对话就忘记第一步做了什么、测试跑到哪个阶段了。但命令文件把“小步重构、保持行为不变”固化成流程，AI 全程没有跑偏。
4.2 紧急修 bug 的排查链路
最满意的一次是/debug的实战。有个接口在并发请求下偶发超时，我试了几次都没复现，就把日志和代码丢给命令。它的排查过程给我留下了深刻印象：
- 先读取控制器和对应的服务层代码
- 发现有个共享的 Map 在无锁状态下被多个 goroutine 并发读写
- 给出定位：并发 writes 导致偶发 panic，被 recover 后表现为超时
- 修复建议是加读写锁或换成并发安全的 sync.Map
整个过程我几乎没参与，命令通过$ARGUMENTS接收了我提供的日志文本和文件路径，按固定流程完成了从“看代码”到“提方案”的闭环。这里要说明一下：实际项目中不同的 bug 根因千差万别，AI 不一定每次都能一步到位，但命令至少把排查思路固化了，不会漏掉最基础的检查环节。
4.3 提交信息与更新日志的意外收获
/changelog命令的表现也确实让我惊喜。它先跑git log --oneline获取提交记录，然后按类型分组生成更新日志。因为/commit生成的提交信息本身已经用了 conventional commits 格式，/changelog汇总起来毫无负担，两者形成了很好的闭环。
有一个细节值得分享：为了让/changelog的版本分组准确，我会在命令里注明“本次版本区间为 tag A 到 tag B，按 feat / fix / docs 分类，并过滤掉 chore 类型”。AI 执行起来很利索，生成的 changelog 几乎不用改。
5. 使用中最容易翻车的 5 个细节
5.1 文件名与中文命名的坑
很多人看到“中文命令”，第一反应是直接用中文文件名，比如/审查代码。我试过，确实能用，但有两个问题：一是终端下输入中文斜杠命令不方便，输入法要切换，命令补全也不如一两个英文词来得到位；二是部分版本对非 ASCII 文件名支持不稳定，容易匹配不到。所以最终方案是：文件全用英文名，提示词全用中文。用户敲的是/review，读到的却是完整的中文审查流程，既好输入又保持了中文表达的质量。
5.2 参数引号与多行文本
$ARGUMENTS的使用需要留心。如果你输入/debug 修复登录问题 还有支付问题，AI 会把“修复登录问题”和“还有支付问题”当成两段描述。想传多行文本时，最稳的方式是先用@file引用一个文本文件，把内容放进去，再让命令去读那个文件。比如/debug @error.log，Claude Code 会把error.log的内容作为上下文带给 AI。直接贴大段日志在参数里，容易触发终端转义问题，我踩过一次以后就都改成文件传递了。
5.3 命令执行权限要提前配置
命令文件里如果写了“先运行git diff”或“执行pytest”，首次运行会给 Claude Code 逐条权限请求。频繁弹权限窗口其实很打断思路。我后来在.claude/settings.json里预授权了几个安全命令，比如git diff、git log、pytest、npm test，运行命令时就不再追问了。预授权的前提是命令本身安全，像rm -rf这种无论如何都不该放进预授权清单。
5.4 命令与 CLAUDE.md 打架
命令文件要求“直接给出修复代码”，而项目的 CLAUDE.md 里写了“禁止在 service 层直接操作数据库”，两者同时生效时，AI 大概率会先按命令文件的强指令执行，忽略 CLAUDE.md 的限制。这种冲突很难提前发现，我遇到过几次后总结了一个经验：在命令文件里显式加一句“遵守项目 CLAUDE.md 中约定”，让 Claude Code 在冲突时优先尊重项目规范。
5.5 本地模型与第三方模型的适配
我也把 Claude Code 接到过本地模型或第三方 API 上测试，切换模型后，同样一条命令的表现会有差异。比如国产模型在理解中文 prompt 上通常很好，但对“工具调用”的遵循度不如旗舰模型，有时会输出一堆思路分析而不是直接执行命令里写的流程。所以如果你用第三方模型，建议把命令文件里的指令写得更细，比如每一步要调用哪个工具、不准啰嗦，测试通过后再批量替换到所有命令。这一点对使用cc switch这类工具切换模型的朋友尤其重要。
6. 从 10 个命令出发：还可以怎么折腾
6.1 Agent Skills：更重的任务交给“技能包”
斜杠命令适合“一条提示词搞定一个动作”，但遇到多步骤、需要自带脚本和知识库的任务，就该用 Agent Skills。简单来说，Skill 是比命令更重的封装，包含一个SKILL.md说明文件，还可以附带脚本、模板和参考文档。比如我一个“检查线上接口稳定性”的 Skill，就把 curl 探测脚本和告警规则模板一起打包了进去，Claude Code 执行时会自行调用这些资源。
6.2 Hooks：让流程自动触发
如果你不想每次手动敲/review，可以用 hooks 在特定事件发生时自动执行。比如在PreToolUse阶段挂一个脚本，当检测到git push被调用时，自动先做一轮代码检查。这样做能实现“提交前自动过一遍规范”“写 release 时自动生成 changelog”，效率比手动唤命令还要再高一层。
6.3 把工作流包沉淀成团队资产
这套命令包的另一个价值在于团队复用。我把它提交到仓库后，新成员入职第一天就知道用/explain了解项目结构，用/commit生成规范的提交信息，大大降低了沟通成本。每隔一段时间我会根据团队反馈微调命令，比如新增某个具体框架的审查维度、补充部署脚本的检查项，让它越来越贴近实际业务。
我在实际使用中的体会是：命令不是越多越好，能覆盖你重复劳动的就是好命令。从 10 个中文命令开始折腾这一个月，我最明显的感觉不是“AI 变得更聪明了”，而是“我的重复劳动有地方安放了”——以前每次都要斟酌的提示词，现在变成了随手一拨的拨杆。如果你也在用 Claude Code，不妨从自己的操作频率表里挑 5 个最常做的动作，先做成命令试试，说不定会和我一样，从此离不开这个流程包。
