1. 这套中文命令包的由来先说结论Claude Code 是我最近几个月用得最频繁的 AI 编程工具没有之一。它把 Claude 的上下文能力和终端工作流绑在一起能直接读项目文件、改代码、跑命令比在网页对话框里来回粘贴代码高出一个量级。但用了一段时间后我发现一个问题——官方内置的斜杠命令以英文为主我这种习惯用中文思考的人每次都要在脑子里把需求翻译成英文 prompt再手写一大段指令效率打折不说写出来的 prompt 还经常前后不一致。后来我翻文档发现Claude Code 的命令系统支持完全自定义用户可以在.claude/commands目录里放任意数量的命令文件而且触发词可以是中文。这扇门一开我就开始认真琢磨与其每次都临时敲一段 prompt不如把日常开发里最高频的 10 个场景全部沉淀成中文命令做成一套固定的 AI 编程工作流包。这篇文章不聊虚的我就把整套方案从设计思路、配置文件写法、命令逐条拆解到实测中的坑全部摊开。如果你也在用 Claude Code或者正准备入坑这套东西可以直接抄过去改改就能用。2. 开工前的环境准备2.1 Claude Code 的安装与登录先给没装过的朋友把环境补上。Claude Code 本质是 Anthropic 官方出的终端编程代理通过 npm 分发。安装命令非常简单npm install -g anthropic-ai/claude-code装完之后终端里敲claude就会进入交互界面。首次启动会走一次登录授权流程跟着提示在浏览器里完成确认就行。装完建议立刻验证版本我一般用这个命令确认环境没问题claude --version这里有一个我踩过的坑如果你之前装过测试版或旧版本直接全局升级有时候会报auto-update failed: no write permission to npm prefix。这本质上是 npm 全局目录权限不足和 Claude Code 本身没关系。我当时的处理方式是把 npm 的 global 目录权限理顺或者直接用 Node 版本管理工具装的 npm 再执行升级权限位就是当前用户自己的基本不会再碰到写入失败的问题。2.2 配置文件目录的规划Claude Code 的命令系统支持三个层级的配置目录优先级从高到低是配置位置路径生效范围项目级最高.claude/commands/只在当前项目仓库内生效用户级推荐~/.claude/commands/当前操作系统用户全局生效企业级通过管理策略下发团队统一生效我一开始图省事把命令文件放在项目目录里后来发现换个项目就要重新复制一份非常低效。现在我把 10 个中文命令全部放在~/.claude/commands/下一次性配置所有项目通用。如果你习惯用 VS Code直接在终端里敲code ~/.claude/commands/就能打开这个目录后续编辑也方便。3. 10 个中文命令的设计思路与标准3.1 为什么要做中文命令包可能有人觉得Claude Code 本身支持自然语言对话直接说中文就行为什么还要单独做一套中文斜杠命令我的理解是对话式操作和命令式操作解决的是两类问题。临时问一句“这段代码什么意思”确实不需要命令但凡是高频、重复、有固定流程的动作每次现场组织语言都不可避免会漏掉关键约束。比如 code review 这件事我自己写 prompt 时不是忘了解释项目背景就是忘记指定审查范围。沉淀成命令之后约束全部固化在模板里每次触发都是同一套质量标准输出稳定性明显提升。另外中文斜杠命令还有一个好处可发现性。输入/之后命令列表里看到的是“/审查”“/重构”“/补测试”而不是“/review”“/refactor”不需要二次脑内翻译直接根据意图选就行。3.2 每个命令的命名规则与参数设计这 10 个命令我遵循统一的命名逻辑触发词用 2-4 个汉字简短、表意明确不和常用 Shell 命令撞车。命令文件内部分为三个区域角色定义、处理流程、输出约束。可以通过$ARGUMENTS接收用户传入的补充参数但必须给默认行为兜底。以/审查这个命令为例我设计的是先看当前 Git 变更集再按七类问题逐一检查最后输出分级表格。如果一个命令没有清晰的输出格式AI 就容易自由发挥结果千奇百怪。所以我在模板里直接写明输出结构问题等级、文件定位、行号、修复建议、修复成本一个都不能少。再比如/重构命令我要求必须分成“推荐重构方向”和“最小改动方案”两个阶段执行先给方案再动手避免 AI 一上来就大规模改写把本来就稳定的逻辑改出回归 bug。这一条后面还会细说。4. 逐个拆解10 个中文命令实录下面是这 10 个命令的完整设计说明和配置要点。每个命令我都考虑到“在真实的项目环境里怎么用最顺手”而不是写一堆花架子。4.1/需求——模糊需求到开发任务清单这个命令用来承接产品经理或自己脑子里那句含糊的话。输入可能只有一句话输出必须是拆好优先级、标好依赖关系、带验收标准的任务列表。核心提示词逻辑你是一名资深技术负责人。请把用户描述的需求整理成可开发的规格说明 1. 先列出需求中的明确信息与缺失信息。 2. 补全合理的默认假设标注为“假设”。 3. 拆解为 3-8 个开发任务标注优先级P0/P1/P2。 4. 每个任务必须包含验收标准。 5. 最后评估潜在技术风险。 用户需求$ARGUMENTS用了一段时间我的体会是让 AI 承认“信息缺失”比让它硬猜重要得多。很多需求在描述阶段就存在歧义如果 AI 默认一个假设直接开干后面返工成本极高。所以我在提示词里专门加了“明确信息与缺失信息”这一步强制它先做需求澄清。4.2/初始化——孤儿项目快速起步接到一个没有 README、没有依赖说明、没有启动脚本的仓库时这个命令特别好用。它会让 Claude Code 自动扫描项目结构、识别语言和框架、判断入口文件然后给出初始化方案。命令文件里写的约束包括不得删除任何现有文件、安装依赖前必须展示完整命令清单让用户确认、补全 README 必须包含“本地开发”“环境变量”“测试命令”三节。这里有个细节我必须强调让 AI 直接跑npm install这类命令之前一定要在命令模板里明确“先展示将要执行的命令等待用户确认”否则 AI 可能在你还没看完的时候就已经把依赖装上了万一装错包或者拉入不需要的大型依赖会很被动。4.3/审查——增量代码 Review这个命令只针对 Git 工作区里的改动不会把整个项目的代码全部读一遍。模板里我写的是请针对当前 Git 变更的代码进行严格审查 1. 先运行 git diff 查看工作区改动。 2. 按以下方面逐项检查并输出文件:行号 - 逻辑正确性与边界条件 - 安全风险注入、越权、敏感信息泄露 - 性能隐患 - 错误处理与资源释放 - 命名与可读性 - 测试覆盖建议 3. 按严重级别输出P0 阻塞 / P1 需修复 / P2 建议优化。 4. 每个问题必须给出具体修复代码示例。实测下来这个命令输出质量的高低直接取决于项目上下文。如果仓库里已有编码规范文档建议在模板开头让 AI 先读一遍.cursorrules或项目内规范文件再执行审查出来的结果会更贴合团队的代码风格。另外我加了“只审查当前变更”这个硬约束非常重要否则 AI 偶尔会把历史遗留代码一并点评输出内容就发散掉了。4.4/重构——小步重构而非大爆炸重构命令是我花时间调得最多的一个。原因无他——AI 重构代码时最可怕的不是它不会而是它太爱一次性改一大片。往往你觉得只是让它提取一个公共函数结果它把整个文件的命名、顺序、风格全改了diff 大得没法 review。所以这个命令的关键约束是“分阶段 可回滚”请进行代码重构严格遵守以下流程 阶段一分析并列出当前代码的问题清单提出2-3个重构方案说明各自优缺点 阶段二推荐一个方案并拆解为单次可验证的最小步骤 阶段三用户确认后一次只完成一个步骤每一步都主动运行相关测试。 约束 - 不改动与本次重构无关的逻辑。 - 不重命名公共 API。 - 每次改动规模控制在 50 行以内。这套约束下来AI 的行为立刻变得保守了很多但保守才是重构正确的姿态。实际开发里小步重构配合测试绿条才能保证代码永远处于可发布状态。4.5/补测试——围绕核心逻辑生成单测写测试这件事本身不难难的是知道先测什么、边界值在哪、mock 什么。这个命令模板的核心逻辑是先识别代码里的纯函数和副作用边界再按优先级补测试。针对当前文件/函数生成单元测试 1. 先判断被测对象是否适合单测 - 纯逻辑或可注入依赖的代码直接生成。 - 涉及 IO、网络、时间等难以控制的逻辑优先抽象后再测。 2. 列出 5-8 个关键测试用例覆盖正常路径、边界值与异常输入。 3. 标注每个用例对应的分支覆盖率目标。 4. 输出可直接运行的测试代码说明运行命令。使用这个命令有个注意点AI 生成的测试有时会倾向“为了覆盖而覆盖”写了大量断言但都是同一路径。我后来在模板里加了硬要求——用例之间必须体现不同的输入条件制造差异化。4.6/查错——报错信息的精准翻译与定位这是使用频率最高的命令之一。报错信息不是全英文就是堆栈特别长直接复制给 AI它经常会被误导。这个命令的设计重点不是让 AI 看报错本身而是让 AI 先理解上下文再定位问题。用户遇到一个运行报错/异常。请执行 1. 调用工具查看最近的日志与相关代码上下文。 2. 复述报错的关键信息并翻译成通俗中文。 3. 分析可能产生该问题的 2-3 个根因按可能性排序。 4. 对每个根因给出验证方法与修复方案。 5. 如果信息不足列出还需要补充的信息不要盲目猜测。 报错信息$ARGUMENTS这里面第 5 条最关键。AI 有个通病信息不足时爱编。让它明确说出“还缺什么信息”比让它硬答有价值得多。我在实际使用中最常补充的信息是“复现步骤”和“完整堆栈”这两项一到位定位准确率会直线上升。4.7/改bug——修复后必须附回归验证改 bug 和查错是两件事查错是定位改bug是动手。同一个命令不要既查又改职责一混就容易乱。/改bug命令固定输入一个已定位的问题描述然后按“先复现→再分析→后修复→必验证”的流程推进。请修复这个 bug 问题描述$ARGUMENTS 流程 1. 先撰写一个可复现问题的最小脚本或测试。 2. 运行它确认失败证明问题确实存在。 3. 阅读相关代码定位根因说明为什么会出现该问题。 4. 实施最小修复不牵连无关代码。 5. 重新运行复现脚本确认修复生效。 6. 运行相关既有测试确保无回归。这个命令给我带来的最大改变是AI 不再跳过“无法成功复现”的阶段。以前让它修 bug它经常看完代码直接给答案结果改了跟没改一样。现在模板强制先复现错误的修复方案在第一道关就会被过滤掉。4.8/写文档——注释、README、接口说明大部分工程师都不喜欢写文档但文档又是项目的生命力。这个命令我做了三个子模式通过参数区分$ARGUMENTSreadme生成或更新 README包含项目简介、架构概览、快速开始、配置项说明。$ARGUMENTScomment为当前文件生成中文注释只注释公共 API、复杂逻辑、非显然决策。$ARGUMENTSapi根据接口代码生成调用文档包含入参、出参、错误码、示例。模板里专门加了“禁止为每行代码注释”这一条因为我发现 AI 默认倾向满屏注释写得又多又没用。好的注释是解释为什么这样写而不是在复述代码本身。4.9/提交——规范的 Git Commit 信息别小看 commit message它直接决定你三个月后能不能看懂自己当初的改动。这个命令会先执行git diff --cached查看暂存区然后按统一格式生成提交信息请根据暂存区的代码变更生成 Git 提交信息。 要求 1. 使用 Conventional Commits 格式type(scope): subject。 2. type 从 feat/fix/refactor/docs/test/chore 中选择。 3. subject 使用不超过 20 字的中文描述概括核心改动。 4. body 列出 2-5 条要点聚焦“为什么”而不是“做了什么”。 5. 如果有破坏性变更在 footer 中写明 BREAKING CHANGE。这个命令配合我现在的工作习惯非常顺手白天写代码傍晚统一暂存然后挨个跑 /提交 生成信息。它产出的 commit 比我自己手写的更稳定读完一眼就明白那个改动要解决什么问题。4.10/解释——遗留代码的高效阅读理解接手旧项目的经典场景指着一段代码问“这是干嘛的”。这个命令就是干这个的。请解释以下代码/模块 $ARGUMENTS 要求 1. 用通俗中文说明这段代码实现的核心功能。 2. 拆解执行主流程标注关键函数与数据流转。 3. 指出代码中不显而易见的隐晦逻辑或历史包袱。 4. 给出改进建议但明确说明改动风险。它和直接问 AI 最大的区别在于输出结构固定先讲功能、再讲流程、最后讲风险和优化。不会出现你问一个点它洋洋洒洒写一篇作文的情况。5. 实战技巧与踩坑总结5.1 命令文件的配置格式与坑位命令文件的格式其实很宽松本质是 Markdown 文本扩展名为.md文件名就是触发词。比如我要注册/审查命令就新建一个名为审查.md的文件放在~/.claude/commands/目录里内容直接写 prompt 模板即可。但有几个坑位需要提醒文件内容最前面可以加 YAML front matter 声明参数比如allowed-tools或description但我实测下来纯文本模板更稳定AI 对复杂 front matter 的解释偶尔会有偏差。文件名不要用带空格的词否则斜杠命令的解析会出问题。如果命令在某个项目里没生效优先检查是不是有同名项目级命令覆盖了用户级配置这是最隐蔽的 bug。5.2 从编程辅助到上下文管理的几个认知转变用这套工作流包两个月我最大的感受是AI 编程工具拼的不是模型多聪明而是上下文管理多到位。一套好的命令体系本质是把你平时容易漏掉的约束条件前置固化。比如/补测试命令如果每次都是现写 prompt“帮我补点测试”你十次里有八次会忘记说“先判断哪些函数值得测”。但做成命令之后这一步永远存在。命令模板真正降低的不是操作门槛而是决策负担。所以我建议每个用 Claude Code 的人不需要像我一样做 10 个命令哪怕只做 2 个——一个是最常用场景一个是最近踩坑最多的场景——都会让你对这套工具的体验明显不一样。把你自己反复复制粘贴的那段提示词哪怕只存一个.md文件都是巨大的效率提升。5.3 关于模型接入的备注上面所有命令设计都基于 Claude Code 原生的模型能力工作。目前社区里也有一些方案把其他模型接到 Claude Code 上核心原理无非是修改环境变量指向兼容接口。这套命令文件是纯 prompt 模板理论上换模型后依然可用但命令对指令遵循能力的敏感度不同——审查和重构类命令需要模型有较强的多步推理能力如果发现输出质量明显下降优先缩窄一次命令的处理范围让步骤更小更聚焦。5.4 中文命令的协作优势最后说一个意外的收获这套中文命令不仅自己用起来顺手在团队协作中的价值更大。我把这套命令文件直接提交到了团队公共配置仓库同事拉下来之后不管是谁敲/审查得到的输出结构完全一致。code review 的讨论焦点变成了代码问题本身而不再纠结于报告格式。如果你的团队已经统一使用 Claude Code我强烈建议把常用场景的命令文件沉淀成一个共享包纳入版本管理。这个工作一次性投入大概一两个小时换来的是团队每个人每天的几十次操作都走同一套高标准流程。这笔账怎么算都不亏。以上是我整套中文命令包的实践记录。最后再分享一个小经验命令模板不是一次写成的我前两周几乎每天都在微调把一个命令里效果不好的句子拿出来改掉。别指望一蹴而就用到不顺手的时刻就去改提词器这本身就是和 AI 协作的正常节奏。