1. 为什么我要给 Claude Code 塞进 10 个中文命令
用 Claude Code 写代码这件事，最开始我是拒绝的。原因很简单：命令行里敲英文提示词，脑子得先翻译一遍，再组织成 AI 能理解的句式，最后还得盯着它别跑偏。一套流程下来，写代码的节奏全被"想怎么跟 AI 说话"这件事打断了。后来我换了个思路——既然 Claude Code 支持自定义命令，那我为什么不把常用的中文指令直接固化下来，做成一套开箱即用的工作流包？
这个想法落地之后，我把日常开发里最高频的 10 个操作全部封装成了中文命令。现在我的使用体验是：打开终端，输入/审查，它自动帮我做代码审查；输入/测试，它按我的规范生成单元测试；输入/重构，它按我预设的规则拆分函数。整个过程不需要我每次重新描述需求，也不需要我记住复杂的英文提示词模板。
这套工作流包解决的核心问题有三个。第一是语言摩擦，中文母语者用中文下指令，思维链路最短，出错率最低。第二是一致性，同一个命令每次执行的行为完全一致，不会因为今天心情好多写两句、明天赶时间少写两句而导致输出质量波动。第三是可复用，命令一旦定义好，团队里任何人都能用，相当于把个人经验沉淀成了团队资产。
适合谁来参考这篇内容？如果你已经在用 Claude Code 或者 Codex CLI 这类 AI 编程工具，但每次都要现想提示词，那这套思路能直接帮你省掉大量重复劳动。如果你还没上手，也没关系，我会把安装配置、命令定义、踩坑细节全部讲清楚，照着做就能跑起来。整篇内容围绕"中文命令 + AI 编程工作流"这个核心展开，不扯虚的，全是能直接抄的配置和实测经验。
2. Claude Code 自定义命令的底层机制与文件结构
2.1 命令到底存在哪里
Claude Code 的自定义命令本质上就是 Markdown 文件。你不需要写代码，不需要编译，只需要在指定目录下创建一个.md文件，文件内容就是提示词模板，文件名就是命令名。这个设计非常轻量，但也意味着你得理解它的加载逻辑，否则很容易出现"我明明建了文件，为什么命令不生效"的情况。
命令文件的存放位置有两个层级。项目级放在项目根目录下的.claude/commands/文件夹里，只对当前项目生效。用户级放在用户主目录下的.claude/commands/里，对所有项目生效。我的建议是：通用型命令（比如代码审查、写测试）放用户级，项目专属命令（比如"按我们团队的 API 规范生成接口"）放项目级。这样既保证了复用性，又避免了项目特定逻辑污染全局。
文件名的命名规则需要注意：命令名就是文件名去掉.md后缀。比如你创建审查.md，那调用时就是/审查。中文文件名完全支持，这一点我实测过，在 macOS 和 Linux 上都没问题。Windows 用户如果用 WSL 也没问题，但如果你在纯 Windows 环境下用 Git Bash，中文文件名偶尔会有编码问题，建议这种情况下用拼音或者英文命名，然后在文件内容里写中文提示词。
2.2 命令文件里到底写什么
一个命令文件的内容结构其实很自由，但我摸索下来，最有效的写法是分成三段：角色设定、任务描述、输出约束。角色设定告诉 AI 它现在是什么身份，任务描述说清楚要做什么，输出约束规定格式和边界。这三段缺一不可，尤其是输出约束，很多人忽略它，结果 AI 每次返回的格式都不一样，根本没法自动化处理。
举个例子，我的/审查命令文件大概长这样：
你是一名资深代码审查员，专注于发现逻辑漏洞、边界条件缺失和性能隐患。 请审查当前 Git 暂存区的所有变更文件。 输出要求： 1. 按文件分组，每个问题标注严重程度（高/中/低） 2. 每个问题必须给出具体的代码行号和修复建议 3. 如果某个文件没有问题，明确说"无问题" 4. 不要提风格问题，除非它影响可读性这里有个关键细节：$ARGUMENTS这个占位符。如果你在命令文件里写了$ARGUMENTS，那用户在命令后面跟的参数会自动替换到这个位置。比如/审查 src/utils.js，那$ARGUMENTS就变成src/utils.js。这个机制让命令变得灵活——既可以不带参数执行默认行为，也可以带参数做定向操作。
2.3 为什么中文命令比英文提示词更高效
这个问题我被问过很多次。有人觉得英文提示词更"标准"，AI 理解得更准。我的实测结论是：对于 Claude 这个级别的模型，中英文提示词的理解准确率差异极小，但中文对使用者的认知负担低得多。
我做过一个对比测试：同一个代码重构任务，用英文提示词写，我需要 45 秒组织语言；用中文命令，我 3 秒敲完/重构就完事了。一天下来如果执行 20 次，光"组织提示词"这个动作就能省出十几分钟。更重要的是，中文命令降低了我使用 AI 的心理门槛——不用每次都想"我这句话语法对不对""AI 能不能理解我的意思"，直接说人话就行。
还有一个隐性好处：中文命令的提示词模板更容易被团队成员理解和修改。你让一个后端同事去改英文提示词，他可能得查半天词典；但中文提示词他看一眼就知道哪里该调整。这对于团队协作场景来说，价值非常大。
3. 10 个中文命令的完整定义与逐条拆解
3.1 代码审查类命令：/审查 和 /安全
/审查是我用得最频繁的命令，没有之一。它的核心逻辑是让 AI 扮演一个严格的代码审查员，重点看逻辑正确性和边界条件。我在提示词里特意加了一条"不要提风格问题"，因为风格问题有 Linter 管，AI 再插一脚只会让输出变得冗长。
/安全是/审查的专项版本，只关注安全漏洞。它的提示词里我列了一个检查清单：SQL 注入、XSS、敏感信息硬编码、权限校验缺失、依赖库已知漏洞。这个命令特别适合在提交前跑一遍，尤其是涉及用户输入处理的代码。
这两个命令的实测心得是：一定要限制输出范围。早期我没加约束，AI 会把整个文件从头到尾点评一遍，包括那些没改动的部分。后来我在提示词里明确写了"只审查 Git 暂存区的变更"，输出立刻精简了 70%。
3.2 测试生成类命令：/测试 和 /边界
/测试命令的行为是：读取当前打开的文件，为其中的每个导出函数生成单元测试。我在提示词里指定了测试框架（Jest 或 Vitest，根据项目自动判断），并要求覆盖正常路径、异常路径和边界值。
/边界是一个更聚焦的命令，专门生成边界条件测试。比如输入是数组，它会生成空数组、单元素数组、超大数组的测试用例；输入是数字，它会生成 0、负数、最大值、NaN 的用例。这个命令帮我抓出过好几个隐藏的 bug，尤其是那些"理论上不会发生"但实际会发生的场景。
这里有个坑要注意：AI 生成的测试有时候会 mock 过度，把被测函数的核心逻辑也 mock 掉了，导致测试永远通过但毫无意义。我的应对方法是在提示词里加一句"不要 mock 被测函数内部的纯函数调用，只 mock 外部依赖（网络、文件系统、数据库）"。
3.3 重构优化类命令：/重构 和 /性能
/重构命令的提示词里我定义了三条硬规则：单个函数不超过 30 行、嵌套层级不超过 3 层、重复代码超过 3 次必须提取。AI 会按这三条规则扫描当前文件，给出重构方案并直接生成重构后的代码。
/性能命令关注的是运行时效率。它会分析代码中的循环嵌套、重复计算、不必要的内存分配、同步阻塞操作。我印象最深的一次是它发现我在一个循环里反复调用JSON.parse，建议我把解析结果缓存到循环外，改完之后接口响应时间从 800ms 降到了 120ms。
这两个命令的使用建议是：重构命令不要一次性对整个项目跑。AI 的上下文窗口有限，文件太多它会丢失细节。我的做法是一个文件一个文件地跑，跑完一个提交一次，保证每次变更都可回溯。
3.4 文档与注释类命令：/注释 和 /文档
/注释命令为当前文件的每个函数生成 JSDoc 或 docstring 风格的注释。我在提示词里要求注释必须包含：功能描述、参数说明（含类型和默认值）、返回值说明、可能抛出的异常。这个命令特别适合接手老项目时快速补文档。
/文档命令更重量级，它会读取整个模块的代码，生成一份 Markdown 格式的模块说明文档，包括模块职责、对外接口、依赖关系、使用示例。我通常在新人入职时跑一遍这个命令，把生成的文档作为上手材料。
需要注意的是，AI 生成的注释有时候会"过度解释"，把显而易见的代码也注释一遍。我的处理方式是在提示词里加一条"只注释非自解释的代码，简单 getter/setter 不需要注释"。
3.5 调试与排查类命令：/排查 和 /日志
/排查命令的使用场景是：我有一段报错信息或者异常堆栈，直接粘贴给 AI，让它分析可能的原因并给出排查步骤。提示词里我要求它按可能性从高到低排序，每个原因附带验证方法。
/日志命令帮我快速在代码里插入日志语句。我告诉它我要追踪哪个变量、在哪些关键节点追踪，它自动生成console.log或对应的日志框架调用。这个命令在排查线上问题时特别有用，不用我手动一行行加日志。
这两个命令的实测经验是：排查命令一定要提供足够的上下文。只给一行报错信息，AI 只能猜；把相关的代码片段、运行环境、最近改动一起给它，准确率会大幅提升。
4. 从零搭建这套工作流包的完整操作路径
4.1 环境准备与 Claude Code 安装
先说安装。Claude Code 的安装方式取决于你的操作系统。macOS 和 Linux 用户最省事，直接用 npm 全局安装：
npm install -g @anthropic-ai/claude-code安装完成后，在终端输入claude就能启动。首次启动会引导你完成登录授权，按提示操作即可。
Windows 用户我强烈建议用 WSL2，不要用原生 Windows 终端。原因有两个：一是 Claude Code 的很多功能依赖 Unix 工具链（比如grep、find），原生 Windows 下这些命令的行为不一致；二是中文文件名在 WSL 下的编码处理更稳定。WSL 里安装 Node.js 之后，同样用上面的 npm 命令安装即可。
安装过程中最常见的报错是auto-update failed: no write permission to npm prefix。这个问题的根因是 npm 全局目录没有写权限。解决办法是重新配置 npm 的全局目录到用户目录下：
npm config set prefix ~/.npm-global export PATH=~/.npm-global/bin:$PATH把第二行加到你的.bashrc或.zshrc里，然后重新安装即可。这个坑我踩过两次，每次都是在新机器上配置环境时忘记改 prefix。
4.2 创建命令目录与文件
安装完成后，创建命令目录：
mkdir -p ~/.claude/commands然后为每个命令创建对应的 Markdown 文件。我建议先用一个脚本批量创建空文件，再逐个填充内容：
cd ~/.claude/commands for cmd in 审查 安全 测试 边界 重构 性能 注释 文档 排查 日志; do touch "${cmd}.md" done创建完成后，用你顺手的编辑器逐个打开填写提示词。这里有个小技巧：先写一个命令，跑通验证之后再批量写剩下的。因为提示词的写法需要根据实际输出反复调整，一次性写 10 个再一起调试，出了问题很难定位是哪个环节的毛病。
4.3 验证命令是否生效
写完之后，启动 Claude Code，输入/然后按 Tab 键，应该能看到你定义的所有命令出现在补全列表里。如果没看到，按以下顺序排查：
- 确认文件确实在
~/.claude/commands/目录下，用ls -la检查 - 确认文件扩展名是
.md，不是.txt或没有扩展名 - 确认文件内容不是空的，空文件可能不会被加载
- 重启 Claude Code，有时候新命令需要重启才能识别
我第一次配置时卡在第三步——有个文件我创建了但忘了写内容，结果那个命令一直不出现，排查了半小时才发现是空文件的问题。
4.4 命令的迭代与版本管理
命令文件写完之后不是一劳永逸的。随着你使用习惯的变化，提示词需要不断调整。我的做法是把~/.claude/commands/目录用 Git 管理起来，每次调整都提交一次，这样能追溯每个命令的演变历史。
cd ~/.claude/commands git init git add . git commit -m "初始化 10 个中文命令"如果你在团队里推广这套工作流，可以把命令目录做成一个共享仓库，每个人 clone 下来放到自己的~/.claude/commands/里。新人入职时一条命令就能获得全套工作流，省去了大量口头传授的时间。
5. 实测中踩过的坑与排查链路
5.1 命令不生效的三种典型情况
情况一：文件名和调用名不匹配。我创建了一个文件叫代码审查.md，但调用时输入/审查，自然找不到。命令名必须和文件名完全一致，包括中文字符。这个坑的本质是 Claude Code 按文件名索引命令，不做模糊匹配。
情况二：项目级命令覆盖了用户级命令。如果你在项目里也建了.claude/commands/审查.md，那项目级的会覆盖用户级的。我有一次在项目里调试一个特殊版本的审查命令，调完之后忘了删，结果之后所有项目里的/审查都走了那个特殊版本，行为完全不对。排查了半天才想起来是项目级覆盖的问题。
情况三：提示词里的$ARGUMENTS位置不对。如果你把$ARGUMENTS放在了一个永远不会被执行的段落里，那参数就传不进去。比如你写"如果用户提供了参数，则处理$ARGUMENTS"，但 AI 判断用户没提供参数（实际上提供了），那参数就被忽略了。我的建议是把$ARGUMENTS放在提示词的开头或者明确的任务描述里，不要藏在条件分支里。
5.2 输出格式不稳定的应对方法
AI 生成的内容格式不稳定，这是所有用 AI 编程工具的人都会遇到的问题。我的解决方案是在提示词里给出具体的输出模板，而不是只描述格式要求。
比如早期我写"按文件分组输出问题"，结果 AI 有时候用一级标题分组，有时候用二级标题，有时候用表格。后来我改成直接给模板：
## 文件：{文件路径} - [严重程度] 行号：问题描述 - 修复建议：xxx给了模板之后，输出格式立刻稳定了。这个经验适用于所有需要结构化输出的命令。
5.3 中文命令在 CI/CD 环境中的兼容性
如果你想把 Claude Code 集成到 CI/CD 流程里，中文命令可能会遇到编码问题。CI 环境的默认 locale 通常是C或POSIX，不支持 UTF-8 中文文件名。解决办法是在 CI 配置里设置LANG=C.UTF-8和LC_ALL=C.UTF-8。
我在 GitHub Actions 里踩过这个坑，本地跑得好好的命令，到了 CI 里就报"command not found"。后来在 workflow 文件里加了环境变量才解决：
env: LANG: C.UTF-8 LC_ALL: C.UTF-8如果你不想折腾编码问题，也可以给命令文件用英文名，只在文件内容里写中文提示词。这样兼容性最好，代价是调用时得敲英文。
6. 让这套工作流真正融入日常开发的几个习惯
6.1 命令的组合使用
单个命令解决单个问题，但实际开发中往往是多个问题交织在一起。我的习惯是按固定顺序组合执行：先/审查看逻辑，再/安全看漏洞，然后/测试补测试，最后/注释补文档。这个顺序不能乱，因为如果逻辑有问题，先写测试就是浪费；如果安全有问题，先补注释也没意义。
我把这个组合流程写成了一个 shell 脚本，每次提交前跑一遍：
#!/bin/bash claude -p "/审查" && claude -p "/安全" && claude -p "/测试"-p参数让 Claude Code 以非交互模式执行命令，执行完直接退出。这样我就可以把它挂到 Git 的 pre-commit hook 里，每次提交自动跑一遍检查。
6.2 根据项目类型调整命令
不是所有项目都适合同一套命令。后端 API 项目我会强化/安全和/性能，前端项目我会强化/审查和/测试，数据处理项目我会额外加一个/数据校验命令专门检查数据边界。
调整的方法很简单：在项目级的.claude/commands/目录里放一个覆盖版本。比如后端项目里，我把/安全的提示词改成了专门检查 SQL 注入和权限校验的版本，比通用版本更聚焦。
6.3 定期回顾和清理命令
命令用久了会积累，有些命令可能一个月都用不上一次。我每个月会回顾一次命令列表，把使用频率低的命令归档或者删除。判断标准很简单：如果连续两周没有主动调用过某个命令，那它要么是提示词写得不好用，要么是需求本身不成立。
清理的时候不要直接删文件，先移到~/.claude/commands/archive/目录里观察一段时间。因为有时候只是最近的项目类型不需要这个命令，过段时间换个项目又需要了。归档而不是删除，给自己留个后悔药。
6.4 把个人经验沉淀成命令
这套工作流最大的价值不在于那 10 个命令本身，而在于它提供了一种把个人经验固化成可复用资产的方法。每次我在代码审查中发现一个反复出现的问题，我就会把它加到/审查的提示词里；每次我总结出一个新的性能优化模式，我就会把它加到/性能的检查清单里。
时间长了，这套命令就变成了我个人经验的集合。新人用这套命令，相当于直接继承了我几年的踩坑经验。这比写文档、做分享的效率高得多，因为命令是"活"的，每次执行都在实际工作中产生价值。
我目前正在尝试的一个方向是：把命令和项目的代码规范文件联动起来。比如项目里有一个.eslintrc，那/审查命令就自动读取这个文件，按项目自己的规范来审查，而不是用我预设的通用规则。这个思路还在验证中，跑通之后应该能进一步提升命令的适配性。
