从裸用 Claude Code 到把这 10 个中文命令装进去我差不多花了一个下午但之后省下来的时间是这个下午的几十倍。最开始我懒得配总觉得 IDE 里多打几个字也无所谓可真到了每天高频处理需求澄清、代码审查、重构、复盘这些固定动作时重复打同一段提示词是真的烦。而且每次打的措辞不一样AI 的输出质量也跟着抖。后来我把这套中文命令固化成了工作流包敲/需求就是一个标准的需求澄清流程敲/审查就是一轮结构化的代码 review。这篇文章不聊虚的直接给你看这 10 个命令怎么设计、怎么写、怎么放进 Claude Code以及我实际用了两周后踩过的坑。这套东西适合谁已经装上 Claude Code、每天拿它写代码或改代码但总觉得哪里不够顺手的开发者。也适合想给团队拉齐一套 AI 协作规范的人。项目级命令文件可以直接提交到仓库团队拉到代码后天然自带一套工作流这个后面我会细说。1. 为什么我要给 Claude Code 做一套中文命令1.1 默认命令够用但不是为我准备的Claude Code 自带的 slash command 其实不算少/clear、/init、/compact、/cost这些日常都在用。但我很快发现一个问题这些内置命令解决的是“会话管理”层面的需求解决不了“让 AI 按我的方式干活”的需求。我真正高频复用的是业务动作比如“请先帮我把这个需求澄清成一份可执行的任务清单然后再开始写代码”这种话我一天要敲三四遍。敲一遍两遍可以接受长年累月敲就是在浪费时间。还有个更隐蔽的问题同一件事我上午说的是“帮我看看这段代码有没有问题”下午说的是“以代码审查的角度检查一下这个文件的潜在风险给出修改建议”得到的输出风格完全不一样。人是稳定的AI 的发挥却因为提示词的细微差异而飘忽不定。这时候我就想要一个东西把“代码审查”这四个字真正变成一个可重复、可预期、可共享的流程。1.2 中文命令到底省下了什么把命令做成中文第一层价值是“少打字”。/审查比“请你以资深工程师的视角从正确性、性能、可维护性、潜在 bug 四个方面审查以下代码”短得多这不用说。第二层价值是“语义不丢失”。对中文团队来说/需求、/架构、/复盘是无歧义的甚至不需要解释用途。这一点对团队协作很重要。我用英文命令名时总要想一下到底是review.md还是code-review.md但中文命令不会。第三层价值也是我最看重的是“工作流固化”。好的命令不只是提示词模板它是一整套决策流程。比如/修复不只是让 AI“修复 bug”而是先复现、再定位根因、再改代码、最后补测试。这些步骤如果每次都靠临时发挥大概率会漏掉某一步。固化成命令之后AI 每次都会走完整个流程输出质量自然就稳定了。1.3 十个命令的整体规划我不建议一上来就做 50 个命令那不是工作流那是命令垃圾桶。我只选了再次高频、再次能沉淀成标准动作的 10 个分成三类需求侧/需求、/架构、/文档代码侧/审查、/测试、/重构、/修复工程侧/提交、/诊断、/复盘这个分类的逻辑很简单写代码之前需要想清楚需求写代码之后需要验证质量交付过程中需要提交、排障、复盘。10 个命令覆盖了日常开发里最容易反复沟通、也最容易因为沟通不清而返工的位置。2. 命令功能拆解与模板设计2.1 需求侧三条需求、架构、文档先看/需求。这条命令解决的是“AI 太急着写代码”的问题。很多人在 Claude Code 里说了一句“帮我做一个用户登录”它立刻开始写代码写到一半你发现它理解错了。其实不是 AI 笨是你的输入信息量不足以让它安全开工。/需求的做法是强制先做需求澄清收到命令后AI 必须先逐条追问直到目标、输入输出、验收标准都明确才能产出任务拆解。这是我的/需求模板--- description: 需求澄清与任务拆解先问清再做 argument-hint: 一句话描述你要做什么 allowed-tools: Read, Write, Bash --- 用户提出的需求是$ARGUMENTS 在动手前你必须完成以下澄清流程 1. 列出这个需求的目标用户和使用场景。 2. 列出明确的输入、输出以及成功验收的标准。 3. 指出哪些信息缺失逐条向用户追问。 4. 如果需求涉及现有项目先搜索并阅读相关代码再给出改动影响面。 5. 最后输出按步骤排列的任务清单标注每步的依赖关系。 在我确认需求清单之前不要写任何业务代码。注意模板里的$ARGUMENTS这就是你在命令行里跟在/需求后面的内容。比如敲/需求 用户登录后可以看到自己的订单列表这段文字就会被塞进$ARGUMENTS替换到模板里。这样命令既固定了流程又保留了每次的具体输入灵活和标准两头都占。/架构这条命令做的则是“从需求到技术方案”的桥接。很多需求澄清完了AI 直接就开始写实现跳过了方案设计结果写出来的代码没有结构。用/架构时我会让 AI 先产出模块划分、核心数据流、接口边界并对比至少两个候选方案。我还在模板里加了“必须画出文件级别的依赖关系”这条要求这个输出对后期维护特别有用。/文档我放在需求侧是因为它经常在项目早期就要用到。这条命令专门生成 README、接口说明、目录结构说明。模板里有几个硬性要求必须说明启动方式、必须列出环境变量、必须给一个最小可用示例。生成的文档直接写入文件而不是在对话里输出一大段然后让你自己复制这个体验差别很大。2.2 代码侧四条审查、测试、重构、修复代码侧的四条是我日常使用频率最高的尤其/审查和/修复。/审查的模板我最推荐你直接抄。它不是笼统地让 AI“看看有没有 bug”而是强制它从四个维度逐个检查正确性、性能、可维护性、安全隐患。并且每条发现都必须标注文件路径和行号不允许说“某处存在风险”这种不负责任的话。我还在模板里要求 AI 区分“必须修改”和“建议优化”这样我拿到审查结果后可以按优先级处理不用自己再筛一遍。--- description: 对目标代码做结构化审查 argument-hint: 文件路径或变更范围 allowed-tools: Read, Bash --- 审查目标$ARGUMENTS 请按以下流程审查 1. 先读取目标文件和相关依赖。 2. 从正确性、性能、可维护性、安全性四个维度分别检查。 3. 每个问题标注文件、行号、问题类型、严重级别、修改建议。 4. 最后输出两部分“必须修改”列表和“建议优化”列表。 禁止输出空话套话找不到问题时直接说“未发现”不要硬凑。/测试的核心是自动分析代码后补齐测试。我踩过很多次“让 AI 生成测试结果测了个寂寞”的坑后来发现原因很简单AI 根本不看被测代码的实现逻辑凭空编测试用例。所以/测试模板里我规定第一步必须读取被测文件列出核心函数和预期行为再基于这些真实信息生成测试最后还要执行一遍测试命令确保测试是真实跑过的不是幻觉。这条命令我配了Bash权限因为要真的跑测试。/重构是改代码不改变行为。这条命令最容易让 AI 放飞自我把逻辑一起改了。我在模板里加了三条铁律不改变外部行为、不顺手优化无关代码、每次重构完必须列出行为等价性的验证方式。另外我还提醒一点重构前最好用git diff确认改动范围这条命令和版本管理配合起来才安全。/修复可能是几万开发者最需要的命令。它的流程是复现问题、定位根因、修复、验证、补回归。很多人只让 AI“把它修好”AI 往往只修表面症状。比如把报错的变量判空但根因是上游传错了类型这次不报错下次换个数据又崩。/修复模板会先强制 AI 解释清楚根因判断再写修复代码并且修复后要给出一个可以验证的动作。2.3 工程侧三条提交、诊断、复盘/提交不是简单让 AI 写 commit message而是让它先看git diff理解你这次改了什么再按照我定义的格式生成提交信息。我要求格式包含改动类型、改动内容、影响范围、关联需求。模板里还加了一条“如果 diff 里有调试代码或临时代码要主动提醒”这个提醒救过我至少三次每次都能在 push 前发现残留的console.log。--- description: 根据 git diff 生成规范的提交信息 argument-hint: 可选的补充说明 allowed-tools: Bash, Read --- 执行 git diff 和 git status分析本次变更。 提交信息格式要求 - 第一行改动类型 一句话说明。 - 第二行起具体改动点。 - 最后影响范围和测试建议。 另外注意如果发现调试代码、临时文件、硬编码密钥必须在提交信息中明确标出。/诊断这条命令是给运行时报错准备的。遇到报错时把错误信息或相关日志贴进来命令会让 AI 按“复现路径、根本原因、修复方案、预防措施”四步走。模板里要求它区分“业务代码问题”和“环境配置问题”这两个方向的排查思路完全不同。实际用下来这条命令能把一次报错的定位时间从半小时压缩到几分钟。/复盘是我很得意的一条。它做的是面向一段开发过程的反省。使用场景比如这个功能终于上线了让 AI 基于刚才的对话记录和代码变更整理一下哪些做得好、哪些浪费了时间、哪些技术债要还。模板里我特意加了“给出下轮迭代可执行的两到三个改进项”复盘如果只总结不给行动就是自我感动。这条命令在我做完一个重要模块之后用效果比混混沌沌地开始下一个任务好得多。3. 把命令装进 Claude Code 的完整配置流程3.1 目录结构全局和项目级分开Claude Code 的命令文件其实就是 Markdown 文件放在专门的命令目录里。全局目录是我的用户目录下的~/.claude/commands/这里面的命令在所有项目里都能用。项目级目录是.claude/commands/只对当前项目生效。全局命令适合放通用动作比如/审查、/重构项目级命令适合放和当前业务强绑定的命令比如某套内部框架的生成流程。我实际的结构是这样~/.claude/commands/ ├── 需求.md ├── 架构.md ├── 文档.md ├── 审查.md ├── 测试.md ├── 重构.md ├── 修复.md ├── 提交.md ├── 诊断.md └── 复盘.md创建目录用这条命令mkdir -p ~/.claude/commands mkdir -p .claude/commands项目级目录如果提交到 Git 仓库团队其他人拉到代码后就会自动拥有这套命令。这意味着你可以在团队里统一 AI 交互规范每个人敲/审查跑的都是同一套审查标准。这个价值比单个命令本身大得多它相当于把团队多年沉淀的编码规范翻译成了 AI 能直接执行的流程。3.2 一份标准的命令文件长什么样命令文件本质上是一个带 YAML frontmatter 的 Markdown 文件。frontmatter 里是元信息正文里就是告诉 AI 怎么做的 Prompt 模板。我先说 frontmatter 中几个我每次都会用到的字段。description是一段简短说明。这个字段会显示在命令列表里也是 AI 判断什么时候该用哪个命令的参考。我建议控制在 20 个字以内写清楚用途就行不要写成长句。argument-hint是参数提示。你敲/审查的瞬间Claude Code 会自动把这段提示显示出来告诉用户该填什么参数。比如argument-hint: 文件路径或变更范围用户就知道后面要接什么。allowed-tools是工具白名单。这是我认为最容易被忽略也最重要的字段。它可以限制命令执行时 AI 能调用哪些工具。比如/审查我一般只给Read和Bash不想让它在审查过程中随手改代码。而/测试就必须给Write和Bash因为要生成测试文件并执行。--- description: 需求澄清与任务拆解先问清再做 argument-hint: 一句话描述你要做什么 allowed-tools: Read, Write, Bash ---还有一个可选字段model可以指定这条命令使用哪个模型。比如简单模板用更快的模型复杂架构设计用更强的模型。如果你把 Claude Code 接到本地模型或第三方兼容接口上这个字段的取值要根据你实际配置的模型别名来填。3.3 参数、模型与工具的白名单控制命令正文里最关键的变量是$ARGUMENTS。它代表用户在触发命令时输入的原始内容。这个机制非常像命令行函数的参数。以/修复为例我在编辑器里敲/修复 登录接口超时错误码是 500模板中所有出现$ARGUMENTS的位置都会被替换成“登录接口超时错误码是 500”。这就是命令既标准化又能接受个性化输入的核心。提到工具白名单我再多说一句。我见过有人把所有命令都配成allowed-tools: Bash, Read, Write, Edit这等于没配。白名单的意义是约束 AI 的权限边界。比如/需求阶段你要它读代码可以给Read但你想让它先别改文件就不能给Write。等到了/测试再放开写权限。这样做一方面安全另一方面也让 AI 更专注不会在澄清需求时手痒去改代码。注意命令正文中最好不要写“你现在是一个资深工程师”这种语气修饰词。Claude Code 本身的系统提示里已经有角色设定你再重复只会浪费上下文窗口。把字数留给真正有效的行为约束。3.4 把 MCP 和本地模型绑进来的高级玩法前面说的都是基础命令。如果你已经在 Claude Code 里配了 MCP 服务可以把相关工具也写进命令的allowed-tools里。比如/诊断这条命令如果项目里接了日志查询的 MCP我可以在模板里明确要求先通过 MCP 拉取最近一小时的错误日志再结合线上信息和代码路径做根因分析。这样/诊断就从“读代码猜 bug”升级成了“看日志定位 bug”。命令文件里还可以写一些环境相关的指令。比如/提交里我可以加一步“先读取项目根目录的 CONTRIBUTING.md”让 AI 在生成提交信息时遵循团队的提交规范。这种和项目环境联动的写法比死板地写“必须按 conventional commits 格式”要灵活得多。如果你用的是本地模型接口或兼容 API可以在命令的 frontmatter 里指定model字段。我建议便宜的简单命令用轻量模型非重逻辑的命令用性能更强的模型。同一个会话里不同命令切换模型实际体验下来确实能平衡成本和效果。这事值得单独花时间调一调。4. 实测两周后我建议你这样避坑4.1 常见问题速查表配置过程中我踩了不少坑整理成一张速查表遇到问题直接对照。现象原因解决办法敲/需求提示命令不存在命令文件不在正确的目录里检查是放在~/.claude/commands/还是.claude/commands/文件后缀必须是.md中文命令名能显示但触发不了终端或文件系统编码问题或当前会话缓存了旧列表重启 Claude Code 会话如果仍有问题改用拼音文件名在description里写中文提示命令里的$ARGUMENTS是空的触发命令时没有带参数敲命令后补上参数例如/审查 src/api/user.ts参数里有特殊字符被截断shell 对空格、引号做了分隔用引号包裹参数或者不要传太长参数命令内让 AI 自行读取文件模板不生效AI 还是自由发挥模板文件太长核心指令被淹没精简正文把最重要的行为约束放在前几条其余内容移到项目 CLAUDE.md 里allowed-tools限制了功能AI 说“无法完成”工具白名单过严比如生成的检查拒绝写入文件按命令的真实需要配置工具审查只读测试给写权限提交只读命令和 CLAUDE.md 里的规则冲突项目级规则和命令模板要求不一致以命令模板为准但最好把差异反馈到 CLAUDE.md避免团队困惑生成的文档写入了错误目录模板里没指定相对路径AI 习惯性写到了工作目录模板里明确写出文件路径例如“写入docs/ARCHITECTURE.md”表格里最值得反复说的是第二条。中文命令名很爽但确实依赖终端和文件系统对 Unicode 的支持。在我当前使用的版本里实测是能用的但如果你遇到识别不了的情况最稳的退路是命令文件名用拼音比如shencha.md然后在description和模板正文里保持全中文。用户敲/shencha之后AI 依然按中文流程运转。4.2 设计中文命令的三个雷区第一个雷区是把命令文件写得巨长。我第一次写/需求的时候踩了这个坑模板写了 300 多行结果是每次触发命令这 300 多行都会被塞进上下文。命令本身就是非常耗费上下文窗口的模板越长留给后续代码分析的余量越少。现在我的命令文件基本控制在一二十行之内只写流程骨架和关键约束把具体执行规则交给 AI 根据项目情况展开。第二个雷区是误解model字段。model是让命令在触发时优先使用指定模型不代表这条命令只能使用这个模型也不意味着它一定能加载成功。如果你的模型路由或 API 配置发生变化命令里写了不存在的模型名可能会导致命令执行异常。最安全的做法是要么不写model写上就确保它指向一个真实可用的模型。第三个雷区是命令之间职责重叠。我最初做了/审查和/重构后来发现两者经常冲突审查要求不要改代码重构要求改代码。如果用户在某些环节分不清该用哪个就会出现“审查完了让你直接改”的混乱。解决办法是命令设计时把边界写清楚/审查只输出报告/重构只负责实施两者互不越界。4.3 这套工作流包到底值不值我可以给你几个直观数据。过去两周我统计了日常会话里启动命令的频率平均每个工作日在 15 次以上。按以前每次手动描述需求或审查流程需要 200 字来计算每天至少省掉了 3000 字的重复输入。更关键的是输出质量的稳定性之前同样一个审查任务AI 发挥时好时坏现在用/审查跑出来的结果基本每次都能控制在同一个水平线。还有一个容易被忽略的收益是切换成本。以前我写代码时如果临时想换个任务比如从写功能切到补测试心理上要经历一次很长的“重新描述上下文”过程。现在就是一个/测试的事AI 会自动读取目标文件、生成用例、跑测试我只需要在它偶尔跑偏时纠正一下。这种流畅感不是省几个字能衡量的它直接影响你一晚上能完成多少事。根据我自己的体会配置这套命令包最花时间的不是写命令文件而是“想清楚每个命令到底要固化什么流程”。命令文件只是把你本来就该做的事写成了 AI 能读懂的形式。最后分享一个小技巧每条命令上线后先别急着推广自己用一个星期观察 AI 的输出哪些步骤是你每次都要手动纠正的然后把纠正后的规则回写到模板里。这样迭代三轮命令就和你真实的工作习惯完全对齐了。