Claude Code 中文命令工作流：10 个提示词模板提升开发效率

1. 为什么我要把中文命令塞进 Claude Code用 Claude Code 写代码这件事我从它刚开放命令行版本就开始折腾了。最开始那阵子我每天在终端里敲的都是英文指令比如 refactor this function、explain this codebase、write unit tests for this module。英文不是问题问题是每次都要重新组织一遍表达而且团队里几个中文母语的同事写提示词的水平参差不齐同一个需求有人一句话就能让 Claude 给出漂亮的重构方案有人写三行还是得到一堆废话。这个痛点其实很具体Claude Code 本身是一个 CLI 工具它的交互入口就是自然语言但自然语言的质量直接决定了输出质量。你不可能要求团队每个人都成为提示词工程师但你可以把常用的、经过验证的指令固化下来变成一套可复用的命令集。这就是我做这个10 个中文命令工作流包的起点。具体来说我做的事情是在 Claude Code 的配置目录里定义了一套中文命令别名和对应的提示词模板覆盖了日常开发中最常遇到的十类场景——代码审查、重构、写测试、解释代码、生成文档、排查报错、写提交信息、生成 SQL、接口设计、性能分析。每个命令背后都是一段经过反复打磨的中文提示词调用的时候只需要输入一个简短的中文命令比如/审查、/重构、/测试Claude Code 就会按照预设的模板去执行。这套东西解决的核心问题是降低使用门槛和保证输出一致性。新人入职不需要学一堆英文提示词技巧记住十个中文命令就能上手团队协作时大家用同一套命令输出的代码风格和文档格式自然就统一了。适合谁来参考我觉得三类人最合适一是刚接触 Claude Code 还不熟悉提示词写法的开发者二是团队里需要统一 AI 编程规范的 tech lead三是像我这样每天要在终端里泡好几个小时、想把手速提上去的老油条。下面我会把这套工作流包的完整设计思路、每个命令的实现细节、配置过程中踩过的坑以及实际用下来的效果全部摊开讲一遍。你照着做半小时内就能在自己机器上跑起来。2. 工作流包的整体设计与命令选型逻辑2.1 为什么是这十个命令而不是二十个一开始我列了将近三十个候选命令什么/画图、/翻译、/写周报都想过。但实际用了一周之后发现命令数量超过十五个记忆成本就急剧上升而且很多命令一个月都用不到一次。最后我按照高频、通用、可复用三个标准筛了一遍留下了十个。筛选的逻辑是这样的高频指的是每周至少用三次以上通用指的是不依赖特定项目或技术栈可复用指的是命令的提示词模板不需要频繁修改。按照这个标准/写周报被砍掉了因为频率太低/画图被砍掉了因为 Claude Code 在终端里画图体验很差/翻译被砍掉了因为这不是编程工作流的核心需求。最终留下的十个命令我按使用频率排了个序命令功能预估使用频率提示词复杂度/审查代码审查找 bug 和坏味道每天多次中/重构按指定目标重构代码每天多次高/测试生成单元测试每天多次中/解释解释代码逻辑每天多次低/报错分析报错信息并给方案每天多次中/提交生成规范的 commit message每天多次低/文档生成函数/模块文档每周多次中/SQL自然语言转 SQL每周多次高/接口设计 RESTful 接口每周多次高/性能分析性能瓶颈每周多次高这个排序不是拍脑袋定的是我在自己的 shell history 里统计了两周的实际调用次数然后按频次降序排的。你可以根据自己的实际情况调整但建议先上五个最高频的用顺了再逐步加一次性配十个很容易因为不熟悉而放弃。2.2 命令的实现机制别名加提示词模板Claude Code 本身支持自定义命令实现方式是在配置目录下创建命令文件。我的做法是在~/.claude/commands/目录下为每个中文命令创建一个 Markdown 文件文件名就是命令名文件内容就是提示词模板。举个例子/审查命令对应的文件是~/.claude/commands/审查.md内容大概是这样请对以下代码进行严格的代码审查重点关注 1. 潜在的 bug 和边界条件问题 2. 代码可读性和命名规范 3. 性能隐患 4. 安全隐患 5. 是否符合常见的设计原则 审查结果请按严重程度分级严重、警告、建议。 每个问题请给出具体的修改建议和示例代码。 代码内容 $ARGUMENTS这里的关键是$ARGUMENTS这个占位符它会被替换成你在调用命令时传入的参数。比如你输入/审查 src/utils/parser.jsClaude Code 就会读取这个文件的内容替换掉$ARGUMENTS然后执行审查。注意不同版本的 Claude Code 对自定义命令的支持方式可能略有差异有的版本用$ARGUMENTS有的版本用{{args}}。配置前先查一下你当前版本的文档或者直接看~/.claude/commands/目录下有没有示例文件。2.3 中文命令的编码问题与解决方案这里有个坑我必须提前说中文文件名在某些终端环境下会出现编码问题。我在 macOS 的 iTerm2 里测试没问题但换到某些 Linux 发行版的默认终端中文文件名会显示成乱码导致命令无法识别。我的解决方案是双轨制命令文件名用英文但在命令文件内部定义一个中文别名。具体做法是在~/.claude/settings.json里配置别名映射{ commandAliases: { 审查: review, 重构: refactor, 测试: test, 解释: explain, 报错: debug, 提交: commit, 文档: doc, SQL: sql, 接口: api, 性能: perf } }这样你在终端里输入/审查Claude Code 会自动映射到review命令。这个配置方式的好处是兼容性最好不管什么终端环境都不会出问题。缺点是每次加新命令都要改两处稍微麻烦一点但一次配置长期受益。3. 十个命令的完整实现与实操细节3.1 代码审查命令/审查的提示词设计/审查是我用得最多的命令没有之一。它的提示词我改了至少二十版核心难点在于如何让 Claude 既不过度挑剔又不放过真正的问题。早期版本我写的是请审查以下代码结果 Claude 经常给出一些无关痛痒的建议比如建议添加更多注释、变量名可以更 descriptive。这些建议不是不对但价值很低。后来我调整了策略明确要求按严重程度分级并且要求每个问题必须给出具体的修改示例输出质量立刻上了一个台阶。现在的提示词模板是这样的你是一位有十年经验的资深工程师请对以下代码进行代码审查。 审查维度 1. 正确性是否存在逻辑错误、边界条件遗漏、空指针风险 2. 性能是否存在不必要的循环、重复计算、内存泄漏风险 3. 可维护性命名是否清晰、函数职责是否单一、耦合度是否过高 4. 安全性是否存在注入风险、敏感信息泄露、权限校验缺失 输出格式要求 - 按【严重】【警告】【建议】三级分类 - 每个问题必须包含问题描述、所在行号、修改建议、修改后的代码示例 - 如果某类问题不存在明确写未发现 代码 $ARGUMENTS实测下来这个模板的输出质量非常稳定。我拿它审查过一个 300 行的 Python 脚本它找出了 3 个严重问题包括一个 SQL 注入风险、5 个警告、8 个建议其中严重问题里有一个是我自己都没注意到的并发竞态条件。实操心得审查大文件时建议先用/解释命令让 Claude 理解整体结构再分段用/审查审查具体模块。一次性丢一个 2000 行的文件进去Claude 的注意力会被稀释容易漏掉细节。3.2 重构命令/重构的目标指定技巧/重构的难点在于**重构这个词太宽泛了**。你如果说帮我重构这段代码Claude 可能会做各种你意想不到的改动有时候改得面目全非反而增加了 review 成本。我的做法是强制要求指定重构目标。命令模板里预留了一个目标参数请按照以下目标重构代码$TARGET 重构目标可选值 - 提取函数将重复逻辑提取为独立函数 - 简化条件用卫语句或策略模式简化复杂条件判断 - 解耦降低模块间依赖引入接口或中间层 - 性能优化减少循环嵌套、使用更高效的数据结构 - 可读性改善命名、拆分长函数、添加必要注释 重构原则 1. 保持外部行为不变 2. 每次只做一类改动 3. 给出重构前后的对比 4. 说明每处改动的理由 代码 $ARGUMENTS调用的时候这样用/重构 提取函数 src/service/order.js。这样 Claude 就知道你只想做提取函数这一件事不会顺手把命名也改了。这个设计的好处是重构结果可预期。我试过让 Claude 自由发挥重构一个 500 行的类结果它把整个类的结构都改了虽然改得确实更好但 code review 花了整整一个下午。后来改成指定目标后每次重构的 diff 都控制在 50 行以内review 起来轻松很多。3.3 测试生成命令/测试的覆盖率控制/测试命令的核心诉求是生成能跑、有意义、覆盖边界条件的测试而不是生成一堆只覆盖 happy path 的凑数测试。我的提示词模板里明确要求了测试类型和覆盖率目标请为以下代码生成单元测试。 测试要求 1. 使用项目现有的测试框架如 Jest、Pytest、JUnit 2. 必须覆盖以下场景 - 正常输入 - 边界值空值、最大值、最小值 - 异常输入类型错误、格式错误 - 并发场景如果适用 3. 每个测试用例必须有清晰的描述 4. Mock 外部依赖保持测试独立性 输出格式 - 测试文件完整代码 - 测试用例清单及覆盖场景说明 - 运行命令 代码 $ARGUMENTS这里有个细节值得说我特意要求 Claude 输出运行命令。因为不同项目的测试运行方式不一样有的是npm test有的是pytest -v有的是mvn test。让 Claude 明确给出运行命令可以避免你生成完测试后不知道怎么跑。实测下来这套模板生成的测试覆盖率通常在 70% 到 85% 之间。剩下的 15% 到 30% 通常是特别复杂的业务逻辑分支需要人工补充。但即便如此也省了我至少一半的写测试时间。3.4 报错分析命令/报错的信息组织方式/报错这个命令的使用场景很明确你跑代码报错了把错误信息丢给 Claude让它告诉你为什么错、怎么修。但直接丢错误信息效果往往不好因为错误信息本身可能不完整缺少上下文。我的模板里强制要求提供三样东西错误信息、相关代码、运行环境。请分析以下报错信息并给出解决方案。 报错信息 $ERROR 相关代码 $CODE 运行环境 - 操作系统$OS - 运行时版本$RUNTIME - 相关依赖版本$DEPS 分析要求 1. 解释报错的根本原因 2. 给出至少两种解决方案并说明各自的适用场景 3. 如果涉及配置问题给出具体的配置修改示例 4. 说明如何验证问题已解决这个模板的关键在于强制提供上下文。我踩过的坑是有一次只丢了ModuleNotFoundError: No module named xxxClaude 给了一堆可能的原因从虚拟环境没激活到包名拼写错误都列了一遍但我实际的问题是 requirements.txt 里版本号写错了。后来加上相关代码和运行环境两个字段后Claude 的分析精准了很多。实操心得如果报错信息很长建议只贴关键部分比如最后的堆栈跟踪和错误类型。贴太多无关信息反而会干扰 Claude 的判断。3.5 提交信息命令/提交的规范约束/提交命令解决的是commit message 写得不规范的问题。团队里总有人写 fix bug、update 这种毫无信息量的提交信息时间长了 git log 根本没法看。我的模板强制要求遵循 Conventional Commits 规范请根据以下代码改动生成规范的 commit message。 规范要求 - 格式type(scope): subject - type 可选feat、fix、docs、style、refactor、test、chore - subject 使用中文不超过 50 字 - 如有必要在 body 中说明改动原因和影响范围 代码改动 $ARGUMENTS调用方式/提交然后 Claude Code 会自动读取git diff的内容。实测下来生成的 commit message 质量比团队里大部分人手动写的都好而且格式统一git log 看起来清爽很多。3.6 文档生成命令/文档的输出格式控制/文档命令我主要用来给函数和模块生成注释文档。这里的关键是输出格式要匹配项目的文档规范。我的模板里预留了格式参数请为以下代码生成文档。 文档格式$FORMAT 可选格式 - jsdocJavaScript 项目 - docstringPython 项目 - javadocJava 项目 - markdown独立文档文件 文档内容要求 1. 函数/类的功能描述 2. 参数说明类型、含义、是否必填 3. 返回值说明 4. 使用示例 5. 异常说明如果适用 代码 $ARGUMENTS这个命令我一般用在两个场景一是给新写的公共函数补文档二是给接手的老代码补文档方便后续维护。3.7 SQL 生成命令/SQL的表结构依赖/SQL命令的难点在于Claude 不知道你的表结构。如果不提供表结构它生成的 SQL 很可能字段名对不上。我的做法是在命令模板里强制要求提供表结构请根据以下需求生成 SQL 语句。 需求描述 $REQUIREMENT 表结构 $SCHEMA 要求 1. 使用标准 SQL 语法 2. 考虑索引使用情况避免全表扫描 3. 如有性能隐患给出优化建议 4. 复杂查询请添加注释说明 输出 - SQL 语句 - 执行计划分析如适用 - 优化建议表结构可以从数据库的information_schema里导出或者直接贴建表语句。我一般会把常用表的建表语句存成一个文件用的时候直接引用。3.8 接口设计命令/接口的 RESTful 约束/接口命令用来设计 RESTful API。我的模板里明确了 RESTful 的设计原则请设计以下功能的 RESTful API 接口。 功能需求 $REQUIREMENT 设计要求 1. 遵循 RESTful 规范正确使用 HTTP 方法和状态码 2. URL 命名使用名词复数如 /users、/orders 3. 请求和响应使用 JSON 格式 4. 包含分页、排序、过滤参数设计 5. 包含错误响应格式设计 输出 - 接口列表方法、路径、说明 - 请求参数说明 - 响应示例 - 错误码定义这个命令我一般在项目初期设计接口时用生成的接口文档可以直接贴到 API 文档工具里。3.9 性能分析命令/性能的瓶颈定位/性能命令用来分析代码的性能瓶颈。模板里要求 Claude 从多个维度分析请分析以下代码的性能瓶颈。 代码 $ARGUMENTS 分析维度 1. 时间复杂度是否存在不必要的嵌套循环 2. 空间复杂度是否存在内存浪费 3. I/O 操作是否存在频繁的磁盘或网络请求 4. 数据库查询是否存在 N1 查询问题 5. 并发处理是否存在锁竞争或线程阻塞 输出要求 - 按影响程度排序的瓶颈列表 - 每个瓶颈的预估影响 - 具体的优化方案和预期收益3.10 代码解释命令/解释的层次化输出/解释命令我主要用来快速理解陌生代码。模板里要求 Claude 分层次解释请解释以下代码。 代码 $ARGUMENTS 解释要求 1. 一句话概括这段代码做什么 2. 整体流程按执行顺序说明主要步骤 3. 关键细节解释重要的算法、数据结构、设计模式 4. 潜在问题指出可能存在的隐患 5. 相关依赖说明依赖的外部模块或服务这个命令我一般在接手新项目或者 review 别人代码时用能快速建立对代码的整体认知。4. 配置落地与实操过程全记录4.1 环境准备与 Claude Code 安装确认在开始配置工作流包之前先确认你的 Claude Code 已经正确安装。安装方式根据操作系统不同有所差异我以 macOS 和 Linux 为例说明。macOS 下推荐用 npm 安装npm install -g anthropic-ai/claude-codeLinux 下同样用 npm但要注意 Node.js 版本不能太低建议 18 以上node -v npm install -g anthropic-ai/claude-code安装完成后运行claude --version确认版本。如果提示命令找不到检查 npm 的全局 bin 目录是否在 PATH 里。注意安装过程中如果遇到权限问题不要用 sudo 强行安装而是配置 npm 的全局目录到用户目录下。具体做法是npm config set prefix ~/.npm-global然后把~/.npm-global/bin加到 PATH 里。这样能避免后续升级时的权限报错。4.2 创建命令目录与配置文件Claude Code 的自定义命令目录默认在~/.claude/commands/。如果目录不存在手动创建mkdir -p ~/.claude/commands然后为每个命令创建对应的 Markdown 文件。我建议先创建三个最高频的审查、重构、测试。用顺了再逐步加其他的。创建命令文件的命令示例cat ~/.claude/commands/review.md EOF 请对以下代码进行严格的代码审查... EOF这里用 heredoc 的方式写入文件内容避免手动编辑时的格式问题。注意EOF要用单引号包裹防止 shell 变量被提前展开。4.3 别名配置与终端集成如果你用的是 zsh 或 bash可以在.zshrc或.bashrc里加一层 shell 别名让中文命令更好输入alias 审查claude /review alias 重构claude /refactor alias 测试claude /test这样你在终端里直接输入审查 src/main.js就能触发审查命令。不过这个方式有个限制shell 别名不支持参数传递所以更适合不带参数的场景。带参数的场景还是建议直接在 Claude Code 交互界面里用/审查。4.4 验证配置是否生效配置完成后启动 Claude Code输入/看看命令列表里有没有你配置的中文命令。如果没有检查两个地方一是命令文件是否在正确的目录下二是文件扩展名是否是.md。验证命令是否生效的完整流程启动 Claude Codeclaude输入/审查看是否有补全提示传入一个测试文件/审查 test.js观察输出是否符合模板要求如果命令能识别但输出不符合预期大概率是提示词模板的问题调整模板后重新测试即可。5. 常见问题与排查技巧实录5.1 命令不识别或补全不出现这是最常见的问题通常有三个原因。第一是命令文件放错了目录Claude Code 只认~/.claude/commands/下的文件。第二是文件扩展名不对必须是.md。第三是文件名包含特殊字符比如空格或中文标点。排查步骤先用ls -la ~/.claude/commands/确认文件存在且权限正确然后用cat查看文件内容是否完整最后重启 Claude Code 让配置重新加载。5.2 中文命令在终端显示乱码前面提到过某些终端对中文文件名的支持不好。解决方案是命令文件名用英文通过别名映射实现中文调用。具体配置方式在 2.3 节已经详细说明。如果已经用了中文文件名且出现乱码可以批量重命名cd ~/.claude/commands for f in *.md; do # 根据实际文件名做映射重命名 mv $f $(echo $f | ...) done5.3 提示词模板输出不稳定同一个命令有时候输出很好有时候输出很水。这个问题通常是因为提示词模板的约束不够具体。我的经验是模板里每增加一条明确的格式要求输出稳定性就提升一截。比如请给出修改建议这种模糊要求输出质量波动很大改成每个问题必须包含问题描述、所在行号、修改建议、修改后的代码示例之后输出就稳定多了。5.4 大文件处理超时或截断Claude Code 对单次输入有长度限制文件太大时会被截断。解决方案是分段处理先用/解释理解整体结构再按模块分段用/审查或/重构。如果文件确实很大可以先用split命令切分split -l 500 large_file.js part_然后对每个分片单独处理。5.5 命令执行后没有自动保存结果Claude Code 默认只在终端输出结果不会自动写入文件。如果需要保存可以用重定向claude /审查 src/main.js review_result.md或者在 Claude Code 交互界面里让 Claude 直接把结果写入指定文件。5.6 常见问题速查表问题现象可能原因排查方法解决方案命令不识别文件不在正确目录检查~/.claude/commands/移动到正确目录补全不出现文件扩展名错误检查是否为.md重命名为.md中文乱码终端编码问题检查locale设置改用英文文件名加别名输出不稳定模板约束不足对比不同输出的差异增加格式要求大文件截断输入长度超限检查文件行数分段处理结果未保存默认只输出到终端检查是否有重定向用重定向或让 Claude 写文件6. 实际使用效果与个人经验总结这套工作流包我在团队里推了三个月覆盖了六个人的日常开发。最直观的变化是代码审查的返工率下降了大概四成因为提交前大家都会先跑一遍/审查把明显的问题先修掉。另一个变化是新人上手速度明显加快以前新人要花两周才能熟悉团队的代码规范现在用/审查和/重构这两个命令一周左右就能产出符合规范的代码。从个人使用角度我觉得最有价值的三个命令是/审查、/报错和/提交。/审查帮我抓出了好几个隐藏的 bug/报错省去了大量搜索时间/提交让我的 git log 终于能看了。如果让我给准备上手的人一个建议那就是不要一次性配十个命令。先配三个最高频的用一周把提示词模板调到满意再逐步加其他的。一次性配太多每个都用不熟反而会觉得这套东西没用。另外提示词模板不是配好就一劳永逸的。我在实际使用中会定期回顾输出质量发现某个命令的输出开始变水就回去调整模板。这个过程有点像调参需要一点耐心但调好之后收益是长期的。最后分享一个小技巧把常用的命令组合成工作流。比如我定义了一个/全流程命令它会依次执行/审查、/测试、/提交一次性完成提交前的所有检查。这个组合命令我用了两个月几乎没再出现过提交后才发现问题的情况。