Claude Code 中文自定义命令实战：10 个高频命令提升 AI 编程效率

1. 为什么我要给 Claude Code 塞进 10 个中文命令

用 Claude Code 写代码这件事，最开始吸引我的点其实很朴素：它能在终端里直接读项目、改文件、跑命令，不用在编辑器和浏览器之间来回切。但真正用起来之后，我很快发现一个尴尬的问题——每次开新会话，我都要用英文把同一套上下文重新讲一遍。比如"先读一下这个目录结构""帮我按团队规范写 commit""这个报错先别改代码，先定位根因"，这些话说一次两次还行，说十次就纯粹是浪费 token 和耐心。

更麻烦的是，Claude Code 默认的交互语言是英文思维。你让它"review 一下这个 PR"，它会给你一份很标准的英文风格 review；但你如果想让它按国内团队常见的习惯输出——比如先给结论、再列风险点、最后给修改建议，并且用中文写清楚——你就得每次手动调教。这种重复劳动，本质上和当年我们手动敲git status再看git diff一样，是可以用工具消灭的。

所以我干了一件事：把 10 个高频中文命令固化进 Claude Code 的工作流里。这里的"命令"不是指 shell 脚本，而是指 Claude Code 支持的自定义指令（custom commands）机制——你可以把它理解成给 AI 预设的"快捷话术模板"，输入一个短指令，它就自动展开成一段完整的、带上下文的中文任务描述。

这 10 个命令覆盖了我日常最高频的场景：项目初始化扫描、代码审查、commit 信息生成、报错根因定位、单元测试补全、重构建议、文档生成、依赖检查、性能排查、以及一个"翻译官"命令用来把英文报错转成中文解释。装完之后，我的体感是：同样一个任务，输入量减少了大概 70%，输出质量反而更稳定了，因为每次触发的提示词结构是固定的，不会因为我当天状态好坏而波动。

这篇文章我会把这 10 个命令的设计思路、具体配置、踩过的坑，以及怎么根据你自己的团队习惯做定制，完整讲一遍。适合已经在用 Claude Code、或者刚装好还在摸索阶段的人。如果你还没装，文里也会顺带说清楚安装和目录结构，不影响阅读。

2. Claude Code 的自定义命令到底是怎么工作的

2.1 命令文件放在哪，怎么被加载

Claude Code 的自定义命令本质上就是放在特定目录下的 Markdown 文件。默认情况下，项目级的命令放在项目根目录的.claude/commands/下，用户级的命令放在~/.claude/commands/下。文件名就是命令名，比如你建一个review.md，那在会话里输入/review就能触发。

这里有个很多人第一次会踩的坑：命令名和文件名是强绑定的，但斜杠后面的名字不包含.md。我一开始建了个code-review.md，然后在会话里敲/code-review，结果没反应，后来才发现是目录放错了——我放到了.claude/command/（少了个 s）。Claude Code 对目录名是大小写和复数都敏感的，commands必须是复数。

加载时机也需要注意：命令是在会话启动时扫描的。也就是说，你在会话进行中新建了一个命令文件，当前会话里是看不到的，得退出重进。这个设计其实合理，避免运行中动态加载带来的不确定性，但第一次遇到会让人以为配置没生效。

2.2 命令文件里写什么：frontmatter + 正文

一个标准的命令文件长这样：

--- description: 对当前改动做中文代码审查 argument-hint: [文件路径或留空审查全部改动] --- 请对以下内容做代码审查，要求： 1. 先用一句话给出总体结论 2. 按严重程度列出问题，每条包含：位置、问题、建议 3. 最后给出一个"如果只改一处，改哪里"的建议 审查范围：$ARGUMENTS

上半部分用---包起来的是 frontmatter，description会显示在/help列表里，argument-hint是给使用者看的参数提示。下半部分是正文，也就是真正发给模型的提示词。$ARGUMENTS是一个占位符，会被你在命令后面跟的参数替换掉。

这个机制的关键价值在于：它把"提示词工程"从一次性行为变成了可版本管理的资产。你可以把.claude/commands/提交到 git，团队里每个人拉下来就有一套统一的话术。这比在群里发"你们记得让 AI 先给结论啊"靠谱一万倍。

2.3 为什么用中文命令而不是英文

有人可能会问，Claude Code 原生对英文支持更好，为什么非要中文？我的实测结论是：对于"输出内容"这件事，中文提示词能显著提升中文输出的稳定性。如果你用英文提示词要求它"respond in Chinese"，它有时候会在中间段落偷偷切回英文，尤其是涉及技术术语的时候。但如果你整个提示词就是中文写的，它保持中文的概率高很多。

另一个原因是团队协作。我们团队里不是每个人英文都溜，中文命令降低了使用门槛。一个刚入职的同学看到/审查这个命令，他知道是干嘛的；看到/code-review他可能还得反应一下。

3. 这 10 个命令分别解决什么问题

我把这 10 个命令按使用频率排了个序，下面逐个说设计意图和实际效果。为了让你能直接抄，我把每个命令的核心提示词结构都写出来了。

3.1 项目扫描命令：/扫描

新接手一个项目，最耗时的不是读代码，而是建立心理地图。这个命令的作用是让 Claude Code 先帮你把项目结构、技术栈、入口文件、关键目录过一遍，输出一份中文的"项目导览"。

提示词核心结构是：先让它列出顶层目录并标注用途，再识别技术栈（看 package.json、requirements.txt、go.mod 这些），然后找出入口文件和核心模块，最后给一个"如果你想改 X 功能，应该看哪几个文件"的指引。

实测下来，这个命令对中型项目（几百个文件）效果最好，能省掉我大概半小时的摸索时间。超大项目（上万文件）它会有点力不从心，这时候我会加参数限定范围，比如/扫描 src/。

3.2 代码审查命令：/审查

这是我用得最多的一个。它的设计重点是强制结构化输出。默认的 AI review 很容易变成"这里可以优化，那里也可以优化"的流水账，没有优先级。我的提示词里明确要求：先给总体结论（通过/有条件通过/不通过），再按严重程度分级列问题，最后给一个"最小修改建议"。

这里有个经验：一定要让它区分"必须改"和"建议改"。我见过太多 review 把风格问题和逻辑 bug 混在一起，导致真正重要的东西被淹没。我在提示词里加了这么一句："如果一个问题不影响正确性和可维护性，标记为建议，不要和必须改的混在一起。"

3.3 Commit 信息生成：/提交

git diff看完之后写 commit message，这件事本身不复杂，但很烦。这个命令让它读当前 staged 的改动，然后按约定式提交（Conventional Commits）格式生成中文 commit message。

格式我固定成：类型(范围): 描述，类型限定在 feat/fix/refactor/docs/test/chore 这几个里。这样生成的 message 既能过 CI 检查，人看着也清楚。

注意：这个命令只读 staged 的内容，所以你得先git add。我一开始没注意，它把工作区所有改动都算进去了，生成的 message 和实际要提交的对不上。

3.4 报错根因定位：/定位

这个命令是我最得意的设计。普通做法是直接把报错贴给 AI 问"怎么修"，但这样它很容易直接给你一个补丁，而那个补丁可能只是把症状盖住了。

我的提示词明确要求：先不要给修复方案，先做根因分析。具体分三步：第一步解释这个报错在说什么（用人话），第二步列出可能导致它的 3 到 5 个原因并按可能性排序，第三步针对每个原因给出验证方法。只有你确认了原因之后，再让它给修复方案。

这个"先诊断后开药"的流程，帮我避免了好几次"改了这里坏了那里"的情况。

3.5 单元测试补全：/补测试

给它一个函数或一个文件，它分析现有测试覆盖情况，然后补上缺失的测试用例。提示词里我强调两点：一是测试要能真正失败（不能写那种永远通过的假测试），二是边界条件优先（空值、极值、异常输入）。

实测中我发现一个坑：如果不加限制，它会给每个函数都写一堆测试，包括那些 trivial 的 getter/setter。所以我在提示词里加了"跳过纯数据类和不含逻辑的转发函数"。

3.6 重构建议：/重构

针对一个文件或一个模块，让它给出重构建议。重点是不要让它直接改代码，而是先给方案。提示词要求它列出：当前代码的坏味道、重构的目标、具体的重构步骤、以及每步的风险。

这个命令的价值在于，它经常能发现一些我习以为常但确实该改的地方。比如有一次它指出我一个 300 行的函数里混了三种职责，我其实一直知道，但被明确点出来之后才下决心拆。

3.7 文档生成：/文档

给一个模块生成中文文档，包括用途、对外接口、使用示例、注意事项。提示词里我要求它从代码里提取事实，不要编造。如果某个参数的含义从代码里看不出来，就标注"需人工确认"，而不是瞎猜。

3.8 依赖检查：/依赖

读依赖清单文件，检查有没有明显的版本冲突、废弃包、或者已知有问题的版本。这个命令我一般在新项目初始化或者升级依赖前跑一次。

3.9 性能排查：/性能

针对一段代码或一个接口，分析潜在的性能问题。提示词要求它区分"确定的性能问题"和"可能的性能问题"，前者要有明确的复杂度分析或 IO 次数统计，后者要说明在什么条件下才会成为瓶颈。

3.10 报错翻译：/翻译

把英文报错、英文文档片段翻译成中文，并且保留技术术语的原文。这个命令看起来简单，但很实用，尤其是读一些老外的 issue 或者 stack trace 的时候。

4. 安装与配置：从零到能用的完整路径

4.1 前置环境

Claude Code 是 Node.js 生态的工具，所以第一步是确认 Node 版本。我实测下来Node 18 以上比较稳，16 也能跑但偶尔有奇怪的问题。检查命令：

node -v npm -v

如果版本太低，建议用 nvm 之类的版本管理工具切一下，别直接动系统自带的 Node，容易把系统工具搞坏。

4.2 安装 Claude Code

安装本身一条命令：

npm install -g @anthropic-ai/claude-code

这里有个国内用户常见的坑：npm 全局安装的 prefix 目录可能没有写权限，导致安装失败或者后续自动更新失败。报错信息通常是no write permission to npm prefix。解决办法是先查一下 prefix 在哪：

npm config get prefix

如果这个目录需要 sudo 才能写，要么改 prefix 到一个你有权限的目录，要么用 sudo 装（不推荐，后续更新会一直要 sudo）。我自己的做法是把 prefix 改到用户目录下：

npm config set prefix ~/.npm-global

然后把~/.npm-global/bin加到 PATH 里。这样以后所有全局包都不需要 sudo，干净。

4.3 创建命令目录

安装完之后，在项目根目录建命令目录：

mkdir -p .claude/commands

如果你想全局可用（所有项目都能用），就建在用户目录：

mkdir -p ~/.claude/commands

我的建议是：通用的命令放用户级，项目特有的放项目级。比如/翻译这种放用户级，/扫描如果每个项目扫描逻辑不一样，就放项目级。

4.4 验证命令是否生效

建好目录、放进去一两个.md文件之后，重启 Claude Code 会话，输入/help，你应该能在列表里看到你的命令。如果没看到，按这个顺序排查：

5. 命令设计的几个关键原则

5.1 输出结构要固定，不要留给模型发挥

这是我最深的一条体会。如果你不规定输出结构，模型每次给你的格式都不一样，你就没法快速扫读。我在每个命令的提示词里都会明确要求输出分几段、每段是什么。比如/审查固定三段：结论、问题列表、最小修改建议。这样我一眼就能定位到我要看的部分。

5.2 先诊断后开药，避免"补丁式修复"

前面/定位已经说过这个思路。推广开来，任何涉及"修 bug"的命令，都应该先要求分析再要求方案。因为模型有很强的"讨好倾向"，你问它怎么修，它就给你一个看起来能用的补丁，哪怕根因在别处。强制它先分析，能把这个倾向压下去。

5.3 用中文写提示词，但技术术语保留英文

纯中文提示词有个副作用：模型有时候会把一些约定俗成的英文术语也翻译成中文，比如把commit翻成"提交"、把branch翻成"分支"，读起来反而别扭。我的做法是在提示词里加一句："技术术语保留英文原文，如 commit、branch、merge、rebase 等。"

5.4 参数要少而精

命令的参数不是越多越好。我一开始给/审查设计了五六个参数（范围、严格程度、输出格式、是否包含建议……），结果自己都记不住。后来砍到只剩一个：审查范围。参数超过两个，使用率就会断崖式下降，这是我在多个工具上验证过的规律。

6. 实测中踩过的坑和解决办法

6.1 命令名冲突

Claude Code 本身有一些内置命令，比如/help、/clear之类。如果你自定义的命令名和内置的撞了，行为不确定。我建议自定义命令统一加个前缀或者用中文名，避开内置命令。我用中文名就是这个考虑，/审查、/定位这些基本不可能和内置冲突。

6.2 提示词太长导致响应变慢

我有个命令一开始写了 800 多字的提示词，结果每次触发都要等好久。后来发现提示词长度和响应时间基本成正比，因为输入 token 多了。我的优化是把提示词压到 200 到 300 字，只保留最关键的约束，剩下的靠模型自己发挥。实测质量没有明显下降，速度提升明显。

6.3 模型"忘记"约束

即使你在提示词里写了约束，模型有时候还是会违反，尤其是长对话之后。我的应对是在命令正文的最后再重复一次最重要的约束。比如/审查最后我会再写一句："记住：先给结论，问题按严重程度排序。"这个"首尾呼应"的写法，实测能明显降低违反率。

6.4 中文命令在某些终端下的输入问题

这个坑比较隐蔽。有些终端对中文输入法的支持不好，输入/审查的时候可能触发不了补全。我的解决办法是给中文命令配一个英文别名，比如/审查同时建一个review.md，两个文件内容一样。这样中文终端用中文，英文终端用英文，都能用。

7. 怎么把这套东西改成适合你自己的

7.1 从最高频的场景开始

不要一上来就设计 20 个命令。先观察自己一周，记录下你最常让 AI 做的三件事，把这三件事做成命令。用顺了再扩展。我最初只有三个命令：/审查、/提交、/定位，用了两周才加到 10 个。

7.2 把团队规范写进提示词

命令最大的价值是固化团队共识。比如你们团队要求所有函数必须有中文注释，那就把这条写进/审查的提示词里。这样每次 review 都会检查这一条，比在文档里写一百遍都管用。

7.3 定期回顾和迭代

命令不是建完就不管了。我每个月会看一遍自己的命令，把用不上的删掉，把经常需要手动补充的约束加进去。命令库应该像代码一样持续维护，而不是一次性配置。

7.4 版本管理

把.claude/commands/提交到 git，这样团队共享、历史可追溯。如果有些命令包含敏感信息（比如内部系统地址），就放用户级目录，不要提交。

8. 一些关于 AI 编程工作流的个人看法

用了几个月下来，我最大的感受是：AI 编程工具的价值不在于它能替你写多少代码，而在于它能不能把你的重复劳动固化下来。Claude Code 本身很强，但如果你每次都从零开始和它对话，你其实是在重复消耗自己的注意力。自定义命令这个机制，本质上是把你的经验沉淀成可复用的资产。

另一个体会是，中文命令这件事比我想象的重要。语言不只是沟通工具，它还影响思维方式。用中文描述任务的时候，我会更自然地想到"先给结论""分优先级"这些符合中文表达习惯的结构；用英文的时候，我更容易陷入"描述清楚就行"的惯性。这可能是个体差异，但对我确实成立。

最后说一个实际的小技巧：如果你不确定一个命令该怎么设计，先手动和 AI 对话几次，把效果好的那几次的提示词复制出来，整理成命令文件。这比凭空设计靠谱得多，因为它是从真实需求里长出来的。

这套 10 个命令我用了大概三个月，中间迭代了四五轮。现在我的日常流程基本是：/扫描建立上下文，干活，/审查自查，/提交生成 message，遇到报错/定位。整个链路下来，我在"和 AI 沟通"这件事上花的时间，比最开始少了大概三分之二。省下来的时间，用来想真正的问题。