说实话，第一次在终端里敲/呼出 Claude Code 的命令列表时，我愣了一下——/init、/compact、/review，全是英文。对于一个习惯用中文语境思考技术方案的人来说，这些命令不是看不懂，而是每次都要在脑子里做一道“翻译题”：这个命令到底会触发哪套工作流？后来我试着把常用的工作流全部改成了中文命令：/需求分析、/写代码、/补测试、/代码审查、/提交……一套 10 个，放进~/.claude/commands/目录，等于给 Claude Code 装了一个属于自己团队的“工作流包”。这玩意儿不是什么黑魔法，本质就是把 Prompt 工程做成了可复用的命令文件。这篇文章我会从命令设计、配置文件写法、完整落地流程到避坑清单，一次性把它讲透。文章偏实操，适合已经把 Claude Code 跑起来、但觉得默认英文命令不够顺手的开发者，也适合刚接触 AI 编程、想找一套开箱即用工作流的同学。
1. 为什么我要做一套中文命令工作流包
1.1 先搞清楚 Claude Code 的命令是怎么工作的
Claude Code 的 slash command（斜杠命令）机制，很多人用了很久还是没太理解。它不是某个配置开关，也不是插件系统，本质上就是一个Markdown 提示词模板的快捷入口。
命令文件存放在~/.claude/commands/或者项目根目录的.claude/commands/下，文件名就是命令名。当你在交互窗口中输入/xxx 参数时，Claude Code 会读取对应的.md文件，把文件里的$ARGUMENTS替换成你敲入的参数，再把整段提示词注入当前会话。举个例子，你在终端里输入/提交 完成关键词过滤功能，Claude Code 内部做的事情是：找到提交.md这个文件，把文件中的$ARGUMENTS替换成“完成关键词过滤功能”，然后把整份处理好的 Markdown 内容当成一段系统指令交给模型。
这个机制的厉害之处在于：命令文件里可以写完整的操作步骤、约束条件和判断逻辑。你可以告诉模型“先运行 git status 查看当前变更文件，再读取 CLAUDE.md 里的提交规范，最后生成符合 conventional commits 格式的提交信息”。也就是说，命令不只是“简单指令”，而是把一整段可执行的工作流固化下来了。
命令所在的目录天然支持 Git 版本管理，所以整套工作流包可以跟代码一起在团队内共享，每个人 clone 下来就能用。这点和 Cursor 里的自定义指令、Copilot Chat 里的 prompt 文件思路一致，但 Claude Code 的命令颗粒度更细，每个命令负责一个明确的开发动作，用起来更像在 IDE 里定义快捷键。
1.2 中文命令解决的真实痛点
可能有人会问：/commit和/提交不就差一个名字吗？为什么非要多此一举？我在实际使用中的体验是，命令的命名直接影响使用频率。
第一层是认知负担。中文开发者看到/需求分析、/代码审查立刻知道接下来会发生什么，不用在/review和/inspect、/audit之间犹豫。这种无脑直觉的触发路径，在一天要调用几十次命令的场景下，节省的心理成本非常可观。
第二层是命令名本身就是工作流的标签。/补测试这个名字背后不只是“写点测试”，而是一套完整的动作：先读取 src 目录确认最近的改动范围，再读取项目的测试框架配置，按现有测试风格去补用例，最后跑一遍测试确认通过。中文命名能让这套流程在使用者脑中留下更直观的印象：补测试，补的是“覆盖”，而不是“随便写几个测试文件糊弄过去”。
第三层是团队协作。我们团队里测试和产品同事偶尔也会拿 Claude Code 来看代码、查问题，他们记不住一堆英文命令，但看到/总结/日报这样的中文命令，自己就能上手。我见过一个产品经理用/需求分析把一段模糊的 PRD 描述直接整理成了用户故事清单，全程没问过我怎么用。
中文命令不是噱头，它本质上是把“团队中隐性存在的规范”用自然语言固化下来，让 AI 每次执行任务时都自动遵守这些规范。
2. 10 个中文命令怎么设计，为什么这么设计
2.1 我沉淀出的命令清单
先把我现在稳定在用的 10 个命令列出来，每个都对应一个.md文件，放在项目级.claude/commands/目录下。
| 命令名 | 对应文件 | 一句话用途 | 典型使用场景 |
|---|---|---|---|
| /需求分析 | requirements.md | 读取需求描述和相关代码，拆成可执行任务 | 接到新需求，把一句话变成清单 |
| /方案设计 | design.md | 结合现有架构输出技术方案对比 | 改动较大的功能，先想清楚再动手 |
| /写代码 | implement.md | 按方案落地实现，重点在按约束执行 | 设计方案确认后，开始写具体实现 |
| /补测试 | test.md | 为最近改动补充单元测试和集成测试 | 准备提 PR 之前，把测试覆盖率补上 |
| /代码审查 | review.md | 审阅当前分支 diff，输出问题清单 | 自己复查改动，或帮同事做 code review |
| /重构 | refactor.md | 在保持行为不变的前提下优化代码结构 | 发现代码重复、长函数、命名混乱时 |
| /修复 | bugfix.md | 根据报错信息或现象定位并修复问题 | 线上出 bug 或者本地测试挂了 |
| /提交 | commit.md | 生成符合团队规范的 git 提交信息 | 准备 git commit 的瞬间 |
| /写文档 | docs.md | 为模块生成 README 或设计文档 | 一个功能做完，准备沉淀文档时 |
| /日报 | daily.md | 总结当天改动和下一步计划 | 下班前，快速整理当天工作 |
这 10 个命令覆盖了一条非常典型的开发主链路：接到需求 → 分析 → 设计 → 实现 → 测试 → 审查 → 提交 → 写文档 → 汇报。我没有把“部署”做成命令，因为部署环节涉及的环境变量和权限问题变数太多，让 AI 直接操作风险偏高，不如保留人工执行。
2.2 命令名背后的工作流设计
命令文件里的提示词才是真正的核心。以我最常用的三个为例，拆开讲讲设计思路。
/提交这个命令，我一开始只写了“生成 git 提交信息”，结果它每次都只会输出一行feat: xxx，完全不管我们团队实际用的type(scope): subject规范。后来我把命令改成：先运行git status查看变更文件，再运行git diff --stat查看改动统计，然后读取项目根目录的 CLAUDE.md 中的提交规范，最后结合$ARGUMENTS生成 3 条候选提交信息，每条都标注 type 理由。 这样改完，生成的提交信息基本都能直接使用，偶尔微调一下 subject 就够了。
/代码审查的设计原则是“被动审查”。命令会限制 AI 只针对当前分支尚未合并的 diff 工作，不允许它去审查整个项目的存量代码。具体流程是：先列出改动文件，再按测试覆盖、边界条件、性能影响、安全隐患四个维度逐文件输出问题，每个问题标注具体文件和行号。 这个命令对独立开发者尤其有用，相当于每次提交前都多了一个不看面子只讲问题的审查员。
/写代码这个命令我踩过不少坑，最核心的一点是：默认不让它直接开写。命令第一步是读取docs/design.md或相关设计文档，如果设计文件不存在，就要求先调用/方案设计或向用户确认。 为什么这样？因为 AI 编程最常见的翻车场景就是上下文还没对齐就埋头写码，写到一半发现方向不对，白白浪费 token。加一步“先读设计”，整个实现过程的准确率会有明显提升。
其他命令的设计也有针对性。/需求分析会让 AI 以用户故事加验收标准的形式输出，避免只给一句“这个有问题”的模糊结论；/日报先跑git diff再看git log，汇总当天提交节点和未完成事项。整套设计遵循两条原则：单命令专注一件事，拒绝大锅炖；命令里显式写清楚先做什么再做什么，而不是只给一个目标让 AI 自由发挥。
3. 工作流包落地的完整配置过程
3.1 目录结构和文件模板
命令的存放位置有两个：用户级目录~/.claude/commands/对所有项目生效，适合放个人偏好类命令；项目级目录.claude/commands/跟随仓库走，适合放团队规范类命令。我建议团队共享的类型放项目级，个人习惯类的放用户级，两边互不干扰。
每个命令就是一个.md文件，文件名即命令名。比如提交.md就对应/提交。文件头部可以带 YAML frontmatter，至少写description，否则命令列表里显示的就是文件名本身，不直观。我常用的头部结构如下：
--- description: 按团队规范生成 git 提交信息 argument-hint: 请输入本次提交的简要说明 ---argument-hint是给用户看的提示，告诉使用者在输入该命令时需要补充什么参数。进阶玩法是在 frontmatter 里配model指定某个命令强制走特定模型，或者配allowed-tools限制 AI 在这个命令里能调用哪些工具，比如/代码审查只允许它执行只读的 git 命令，不允许它修改文件，这样即使用错了也不会造成破坏。
下面给一个完整的提交.md模板，可以直接抄作业：
--- description: 按团队规范生成 git 提交信息 argument-hint: 请输入本次提交的简要说明 --- 请扮演经验丰富的 Git 提交信息编写者。 进行以下步骤： 1. 先运行 `git status` 查看当前变更文件列表。 2. 再运行 `git diff --cached --stat`，如果没有暂存文件则运行 `git diff --stat`。 3. 读取项目根目录的 CLAUDE.md，找到提交规范部分。 4. 结合用户输入 $ARGUMENTS 生成 3 条候选提交信息。 5. 每条提交信息必须满足： - 格式：type(scope): subject - type 从 feat/fix/docs/style/refactor/test/chore 中选择 - subject 用中文，不超过 50 个字符 6. 输出时按推荐程度排序，并简要说明每条信息对应的 type 选择理由。 注意：不要实际执行 git commit，除非用户明确说“直接提交”。命令文件不是越长越好。我踩过的判断标准是：要把流程讲清楚但不写逐字稿，一屏之内能看完是最佳长度。长篇大论的命令会让模型在长文本里的遵循度下降，也消耗更多上下文。
3.2 用 CLAUDE.md 把项目规范喂给所有命令
只写命令文件还不够，因为命令是“一次性提示词”，而项目规范是“背景知识”，每次都塞进命令里会让模板变得臃肿。正确的做法是把规范放进CLAUDE.md，这个文件会被 Claude Code 自动加载，作为项目级的背景上下文。
项目根目录放一个CLAUDE.md，里面写清楚：
- 项目技术栈和目录结构，比如“前端使用 Vue 3 + pnpm，禁止在 src 下新建 modules 之外的目录”
- 代码风格约束，比如“组件文件名使用 kebab-case，样式使用 scss 变量”
- 测试规范，比如“新功能必须有至少 3 个单元测试，覆盖正常/边界/异常三类”
- 提交规范，比如“提交信息使用 conventional commits，type 必须全小写”
- 明确禁止的事项，比如“不要修改 migrations 目录下的历史文件”
当CLAUDE.md把这些规范写清楚后，命令文件里就不需要重复贴一遍规范了。/写代码落地出来的代码大概率会自动遵守文件里的目录约定和命名规范，因为模型在生成时就已经带着这些上下文。
这里有一个关键的叠加关系：CLAUDE.md负责提供“长期记忆”，命令文件负责提供“当前任务的具体步骤”，两者配合才能达到稳定输出。很多人只配了命令文件却忽略了CLAUDE.md，效果直接打对折。
3.3 多模型切换和本地模型接入
命令工作流包只跟提示词有关，底下的模型可以随意换。我经常通过 cc switch 这个工具在 Anthropic 官方模型和 DeepSeek、Qwen、GLM 这些模型之间切换，用来对比同一套中文命令在不同模型上的表现。
cc switch 本质是一个配置管理器，维护多套 API base URL、模型名和密钥。切换时运行cc-switch选择对应配置，它会通过环境变量把当前选中的 provider 注入到 Claude Code 的启动环境中，重启后生效。我第一次用这套工具时只有一个感受：折腾一次配置，以后再也不用折腾了。
如果你更想用本地模型，也可以把 LM Studio 启动后的本地服务地址填进去，端口类似http://localhost:1234/v1。需要特别注意的是，本地小尺寸模型对长上下文的处理能力明显弱于云端大模型，命令模板如果写得过长，模型会“犯糊涂”。我踩过的建议是：切到本地或中小模型时，优先用 frontmatter 里的allowed-tools把工具范围缩到最小，同时把命令文本精简到核心步骤。
4. 用中文命令跑通一条完整开发流程
4.1 一次从需求到提交的实操记录
光讲配置不够，我用一个真实场景走一遍完整流程。假设项目是一个 Node.js 的 RSS 阅读器，新需求是给文章列表增加“关键词过滤”功能。
我在项目目录下运行claude进入会话，输入：
/需求分析 给 RSS 阅读器增加关键词过滤，用户能配置关键词列表，匹配到的文章自动打标，不删除
命令触发后，AI 做了这些事：读取 src 目录结构、查看 package.json、阅读现有数据库模型，然后输出一份需求清单，包含用户故事、验收标准、涉及的文件、测试点、风险点。整个过程不到一分钟，产出比我自己写需求文档还工整。
接下来输入/方案设计，AI 先读取了数据库迁移文件和前端页面代码，然后输出 3 个方案：纯前端过滤、后端存储关键词加前端展示、后端过滤加缓存。它推荐方案二，理由是后端集中管理规则，多端生效且改动最小。 我确认后输入/写代码 按方案二实现，AI 先读取了我之前的 design 文件，然后依次改了数据库模型、service、controller 和前端页面，并主动运行了npm test。
测试跑完后，我输入/补测试，AI 为过滤函数补了 8 个用例，覆盖关键词命中、大小写不敏感、空关键词列表、正则特殊字符等边界。补完测试我又输入/代码审查，它扫描当前分支 diff 后，指出两个问题：正则匹配可能在极端长文本上出现性能风险，空关键词列表时 UI 没有做空态提示。 这两个问题虽然不是致命的，但确实是我自己 review 时不一定会注意到的细节。
最后输入/提交 完成关键词过滤功能，AI 按照 CLAUDE.md 里的提交规范生成了三条候选提交信息，第一条是feat(filter): 增加文章关键词过滤功能，我直接选中了。整个流程从需求到提交，大概 15 分钟。
4.2 实操中的效果复盘
这次完整跑下来，我最直接的感受是：命令把“上下文”变成了可控变量。没有命令时，Claude Code 会把上一轮对话的结论带到这一步，导致跑偏；有了/写代码、/代码审查这种固定上下文入口，每次触发相当于一次“干净定向任务”，上下文污染的问题会减轻很多。
第二个感受是命令措辞直接影响结果。第一版/写代码我写的是“请实现需求”，结果 AI 经常不读设计文档就开写。改成“先读取 docs/design.md，如果没有设计文件则询问用户”之后，实现准确度明显上升。Prompt 工程在命令行里同样适用，只是换了一种载体。
第三个感受是命令文件适合版本管理。整个.claude/commands/目录提交到 Git 仓库后，团队每个成员 clone 下来就能用。团队规范是通过命令“长”在开发者的终端里，而不是躺在 Wiki 上吃灰。
5. 常见问题与避坑指南
5.1 命令失效和异常的排查思路
命令文件本身不复杂，但实操中会遇到各种奇怪问题。我整理了一个速查表，按“现象-原因-处理办法”来列：
| 现象 | 大概率原因 | 处理办法 |
|---|---|---|
| 输入 /命令 后列表里不出现 | 文件放错目录，或文件名后缀不是 .md | 确认文件在 ~/.claude/commands 或项目 .claude/commands，重启会话 |
| 命令触发后行为完全不对 | CLAUDE.md 里的规范覆盖了命令指令 | 在命令措辞里显式加上“本次以本命令为准” |
| $ARGUMENTS 只拿到第一个词 | 参数没有用引号包裹 | 输入时使用/命令 完整的一句话描述形式 |
| 每次执行命令都反复要授权 | Claude Code 默认对 bash 执行需要确认 | 在设置中给只读 git 命令加白名单，或压缩 allowed-tools 范围 |
| AI 不执行命令里写的 git 命令 | allowed-tools 限制了 Bash 工具 | 在 frontmatter 里允许 bash 工具，或在命令里说明这些命令是只读安全的 |
| 命令输出效果和普通对话没区别 | 命令文件太短，工作流没有写具体 | 按“步骤+要求+输出格式”三层结构重写命令 |
如果你是在 VSCode 的 Claude Code 插件里使用，自定义命令目录和终端版是一样的，插件底层启动的是同一个 CLI 核心，所以配置方式不用区别对待。桌面版同理，命令配置会同步生效。
如果遇到“组织已禁用订阅访问”之类的提示，那不是命令文件的问题，是账号或订阅权限的问题，需要找管理员开通权限，或者使用自带 API Key 的环境变量方案。
5.2 我踩过的几个坑
第一个坑是 YAML frontmatter 的格式错误。我一开始写description：xxx，用的是中文冒号，结果命令列表完全异常。frontmatter 是严格 YAML 格式，标点符号必须半角，这个低级错误排查了我十几分钟。
第二个坑是命令文件里写了绝对路径。/home/me/projects/xxx/src这种路径在自己机器上没问题，一旦分享给同事就废了。后来我把路径全部改成相对路径，或者让 AI 自己通过find和ls定位，彻底解决。
第三个坑是命令写得太长导致上下文爆炸。第一次写/需求分析时，我把整份团队规范贴进命令文件，结果每次触发都消耗大量 token，模型输出也变得机械、像复读机。后来把规范抽进CLAUDE.md，命令文件只保留流程步骤，问题立刻缓解。
第四个坑在 Windows 上比较多见：跑claude时出现 64 位兼容性报错，通常是因为装了旧版本的 npm 包。处理办法是先卸载干净再重装最新版本，或者直接在 WSL 里跑，比反复修环境省心得多。
最后一个建议：命令包不是一个“做完就完”的资产。每跑一段时间，把不符合预期的输出收集一下，回头迭代命令文件。我大概每两周会更新一次这套中文命令，把新踩的坑沉淀进去。
最后分享一个我自己的习惯：这套命令包我没有所有项目一刀切。每个项目 clone 下来后，第一件事是改CLAUDE.md，再根据项目特点微调命令文件。比如有的仓库用 pnpm，有的用 npm，我会在命令里加一句“先检测存在 pnpm-lock.yaml 还是 package-lock.json，再决定包管理器”。就这么一个小提示，AI 生成的命令基本不会跑偏。如果你也想搭一套中文命令工作流，别急着求多求全，先挑一个你最常重复的场景，比如提交信息或者代码审查，写一个能用的命令，跑几天再慢慢扩。这种包是会慢慢“长”大的，用着用着，它就会变成真正属于你自己的工作流。
