每次打开终端面对 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 输入框里敲/commitAI 就会按这个文件里的指令执行。每个命令文件还可以通过$ARGUMENTS变量接收用户输入比如/评审代码 重点检查安全后面那段“重点检查安全”就会传给命令文件。更妙的是命令文件不是单纯的提示词它可以在描述里要求 AI 执行工具调用比如“先运行git diff”“先读取src/main.py”Claude Code 会自主完成这些操作。这很像给 AI 写了一份岗位说明书“你的职责是什么、流程怎么走、报告怎么写”AI 会按流程执行而不是每次重新讨论。这个机制决定了命令文件写得越具体输出越稳定。你临时说一句“帮我看看这段代码”和你通过命令文件说“先分析 git diff、再按安全维度逐条审查、最后按 P0/P1/P2 分级输出”结果完全不是一个水平线。2. 10 个命令的设计清单覆盖我 80% 的日常编程动作2.1 命令总表先说结论我只做了 10 个因为我的动作频率表里超过 80% 的重复工作就集中在这些场景。命令太多会有记忆负担太少又覆盖不了日常工作。下面这 10 个命令是我用了两周后留下来的一版命令名文件用途触发场景/reviewreview.md审查代码改动按严重程度分级输出问题提交代码前、合并分支前/commitcommit.md根据 git 改动生成中文提交信息每次 commit 前/explainexplain.md讲解指定代码的实现思路接手新模块、读不懂老代码/debugdebug.md定位 bug 根因并给出修复方案测试挂了、线上出问题/testtest.md为指定函数或模块补单元测试新增功能、提高覆盖率/refactorrefactor.md小步重构保持行为不变清理坏味道、降低复杂度/changelogchangelog.md根据提交记录生成更新日志发版本前/docsdocs.md根据代码生成或更新文档写 README、整理接口文档/dbdb.md梳理数据库脚本检查索引和迁移写 SQL、改表结构/releaserelease.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. 性能循环嵌套、N1 查询、无谓的对象创建 输出要求 - 问题按严重程度分级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.logClaude 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 个最常做的动作先做成命令试试说不定会和我一样从此离不开这个流程包。