说实话第一次在终端里敲/呼出 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 commitstype 必须全小写”明确禁止的事项比如“不要修改 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 的格式错误。我一开始写descriptionxxx用的是中文冒号结果命令列表完全异常。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 生成的命令基本不会跑偏。如果你也想搭一套中文命令工作流别急着求多求全先挑一个你最常重复的场景比如提交信息或者代码审查写一个能用的命令跑几天再慢慢扩。这种包是会慢慢“长”大的用着用着它就会变成真正属于你自己的工作流。