直接说结论把命令装进 Claude Code并不是什么黑科技它只是把claude这个终端工具的/xxx指令做成了你自己的快捷键。但当我真正把这 10 个中文命令一个接一个跑起来之后最直观的感受是AI 编程从“陪聊写片段”变成了“一条看不见的生产线”。你不需要每次反复解释上下文不需要复制粘贴代码再让它“帮我改”一个/修复或者/提交它自己知道该读哪些文件、按什么顺序查问题、最终给你什么格式的结果。这篇文章不是讲理论是我自己从零配置、反复测试、最后把这些中文命令真正嵌进日常开发工作流的完整记录。我会把每个命令怎么写的、为什么这么写、哪些地方会踩坑全部拆开讲。跟着走一遍你也能在任何项目里把这套东西跑起来让 Claude Code 从一个“对话窗口”变成真正贴近你团队习惯的编程搭档。1. 为什么我坚持把命令改成中文先说结论中文命令最大的价值不是“看得懂”而是“省上下文”。1.1 英文 Prompt 的隐形成本很多人一开始用 Claude Code都会从英文指令开始。比如让它“refactor this module and add error handling”或者“write unit tests for the parser”。如果你英文基础好这确实没毛病。但用久了你会发现一个微妙的问题英文指令写得越短AI 越容易“自由发挥”你为了让它的输出符合你的预期往往需要在对话里重复大量的项目约定。比如你要让它修一个 bug至少要跟它解释一遍“我们的项目里错误处理统一用 Result 类型不要抛异常”、“DTO 和 Entity 要分开”……这些信息每次都要说一遍不仅烦而且容易在复制粘贴里走样。中文命令的底层逻辑是把“项目自己的规矩”和“这个任务的标准动作”一起封装进一个指令里以后只需要调用这一个词。1.2 命令包本质上是一套“工作流契约”我个人的理解是每个命令不只是一段 prompt它是一份“合同”。你告诉 Claude Code“遇到/重构你就必须按我写的这几步来。” 比如我在/重构命令里写死了几个硬性动作——先扫描目标模块的依赖关系、再输出重构方案、最后才能动手改代码。这保证了不管谁在这个项目里用这个命令、不管这个项目的新人有多小白出来的结果都是稳定的。这一点特别适合团队协作。你不需要每个人都会跟 AI “讲条件”只需要让大家记住 10 个词/立项、/开发、/修复、/提交、/发布……整个工作流就串起来了。像不像把一个老工程师的“套路”变成了团队的默认操作规范这就是命令包真正的价值。2. 准备阶段先把 Claude Code 装好跑通模型接入在我开始写命令文件之前我花了点时间把底层的运行环境搞清楚。因为后面所有命令都是跑在 Claude Code 的 shell 会话里如果这里的基础没打好后面写多少命令都是花架子。2.1 安装与登录注意权限问题安装本身很简单就一条命令npm install -g anthropic-ai/claude-code装完之后在终端输入claude会进入交互界面第一次会要求登录。这里有一个非常常见的坑如果你公司的网络策略做了限制或者账号订阅层面被锁住了启动时会有类似 “your organization has disabled claude subscription access for claude code” 的提示。我的处理方式不去这里折腾直接把模型接入切到第三方 API。现在的 Claude Code 是支持通过环境变量配置自定义 API 端点的export ANTHROPIC_BASE_URLhttps://your-api-proxy.example.com export ANTHROPIC_AUTH_TOKENsk-your-token配置好之后重新跑claude就能正常进入会话。实测下来只要你转发的那一端模型能力达标体验上几乎没有区别。2.2 用 CC Switch 统一管理多个模型因为我手头不止一个 API 账号也没有一个固定的“主力模型”所以装了 CC Switch 这个开源小工具。它的作用很简单在本地起一个转发服务然后 Claude Code 里把 API 请求指到它下面我就能在 DeepSeek、Qwen、GLM 以及官方 Claude 模型之间一键切换不用每次去改环境变量。提示CC Switch 只是做 API 路由转发真正跑代码和文件操作还是 Claude Code 自己完成别指望它额外“提智商”。2.3 本地模型调用以 LMStudio 为例有段时间我为了测一个离线项目试过把 Claude Code 接到本地的 LMStudio 上。只需要确保 LMStudio 已经启动了本地服务然后在环境变量里指过去export ANTHROPIC_BASE_URLhttp://localhost:1234/v1 export ANTHROPIC_AUTH_TOKENlm-studio如果你用的是 LMStudio 这类本地推理工具建议选那种指令遵循能力强一点的模型。否则你会发现/重构这种复杂命令跑起来经常半途“走神”因为命令里步骤太多模型一旦跟不上就开始自由发挥。这一点后面我会再展开。3. 命令包整体设计10 个命令覆盖一条完整开发流水线我把自己的日常开发流程拆了一遍最后收敛成了 10 个命令正好覆盖一个需求从“立项”到“发布”的所有关键节点。这一步非常关键建议你在抄我的命令之前先把你自己的流程写下来。不一定非得是 10 个5 个也行 15 个也行重点是每个命令都必须有一个非常清晰的“职责边界”——它只做一件事且这件事有明确的输入和输出。我最终的 10 个命令清单如下命令触发词一句话说明/立项立项根据一句话需求生成项目结构、README/需求需求把模糊描述拆成用户故事和验收标准/规划规划生成开发计划排任务优先级/开发开发按计划实现功能边写边自测/重构重构在保持行为不变的前提下优化代码/修复修复根据报错或描述定位问题并修复/审查审查做代码 review给修改建议/测试测试补测试、跑测试、分析失败原因/提交提交生成规范 git commit message/发布发布版本号管理 变更日志整理从表格里能看出来这不是 10 个孤立的命令而是一条链路先立项再拆需求再排规划然后开发开发过程中可能穿插重构和修复做完之后审查、测试最后提交和发布。这套命令包的接口设计其实很像函数设计每个命令接收的参数尽量少返回的结果尽量结构化。这样命令才能被组合、被复用而不是一段只能跑一次的死 prompt。4. 核心环节实现逐个命令的编写过程与关键细节这部分是重点也是你自己动手最容易卡住的地方。我把每个命令的重要部分拎出来讲不说废话。4.1 命令文件放哪里命名怎么定Claude Code 的命令文件放在个人配置目录下~/.claude/commands/在这个目录下建一个 Markdown 文件文件名就是触发词。比如我想用/修复触发就创建一个修复.md。注意这里一定是纯中文文件名不能带后缀之外的符号。Claude Code 会递归读取这个目录里的.md文件。每个文件的头部还可以加一段 metadata 来定义参数--- description: 根据报错或描述定位问题并修复 argument_hint: [目标文件或 bug 描述] ---argument_hint是可选的但建议写上这样你在终端输入/修复之后它会提示你需要填什么参数。4.2 一个命令的完整“配方”我拿/开发这个最核心的命令来举例。--- description: 按规划实现功能边写边自测确保每个功能点可运行 argument_hint: [功能点描述] --- 你是一名资深后端工程师。请根据当前项目的技术栈和代码规范完成以下功能点的开发。 功能点{{argument}} ## 实现要求 1. 先读取项目根目录的 CLAUDE.md理解项目背景和技术规范。 2. 搜索与当前功能相关的现有代码梳理出需要改动或新增的文件清单。 3. 逐个文件给出实现方案再动手修改不要一次性堆出所有代码。 4. 每完成一个文件的修改立即运行相关测试或编译命令确保不破坏已有功能。 5. 如果出现错误先诊断错误原因再修复并将关键报错信息记录在回复中。 6. 最终输出必须包含 - 改动文件清单 - 每个文件的核心变更说明 - 测试或编译结果 - 可能存在的风险与后续建议 ## 行为约定 - 所有代码必须符合项目已有的风格不能自己发明新规范。 - 不允许删除现有功能代码如果必须改动接口要同步更新调用方。 - 修改过程中如果发现需求存在歧义立即说明并给出合理默认方案不要假装无事发生。你别看这个命令不长它的设计是“步步有约束”。每一步都是一个关卡AI 每过一关就得停下来汇报结果。这比甩给它一句“开发这个功能”要可控得多。4.3 调试类命令的写法/修复的自我约束/修复命令我调试了很多次原因很简单AI 一旦拿到报错信息最常见的毛病就是“猜”。它经常会猜测某个文件里变量没定义然后顺手就改了一跑又冒出一堆连环错误。所以/修复命令我在 prompt 里面增加了一条硬性要求在动手修改代码之前你必须先给出你认定的 root cause并列出至少两条佐证信息比如代码引用关系、日志行号、函数调用链。如果没有达到这个条件不许碰代码。这个约束实测非常有效。为什么因为你把“先诊断后动手”的职业习惯写进了命令而 AI 本身是“生成式”的它天生倾向于顺着上下文直接产出修改代码。你必须在 prompt 层面逼它走一遍诊断流程否则它永远在打地鼠。4.4 与 Git 挂钩的命令/提交和/发布/提交命令的本质是让它充当一个“git 语义化专家”。请先执行 git status 和 git diff --stat再查看本次变更的文件内容 diff最后生成符合 Conventional Commits 规范的提交信息。这里有一个容易被忽略的点命令是可以直接让 Claude Code 执行终端命令的。git diff、git log这些它都会自己跑完再给你结果。所以你不必在命令里贴 diff 内容只需要给它“看”的指令就行。/发布命令更复杂一点它是把版本号管理和 changelog 生成一起做了1. 基于 git log 分析从当前版本到上一个版本之间的所有提交。 2. 根据提交类型推断版本号的升级幅度breaking - majorfeat - minorfix - patch。 3. 询问我是否确认升级版本号确认后再执行 npm version / bump 命令。 4. 生成 CHANGELOG.md 片段按 Conventional Commits 分类整理。注意第 3 条我故意加了“询问我是否确认”这步。因为版本号这种东西一旦 AI 手滑打错 tag后面全乱。让它先输出方案我来拍板这个命令才能真正放心用。5. 完整实测从写命令到跑通一整个修复流程配置完那堆命令文件之后我找了一个周六的下午特意起了一个新的小项目模拟真实开发里最常见的一个场景接手一个别人留下的模块跑出报错然后从头到尾用中文命令把它修完。5.1 用/立项快速起一个项目我先在本地建了一个空目录然后进入 Claude Code敲下/立项 搭建一个 Python 命令行工具用于批量重命名图片文件按拍摄日期分目录保存命令执行后它会自动帮我做这些事情读取当前目录是否已有文件如果没有生成一个合理的项目结构建议写出 README 的核心功能描述给出技术选型建议。这个命令的 prompt 里我埋了一个关键设计它只能生成文件列表和 README不能直接初始化 git 和装依赖。为什么不让它一次干完因为我发现如果命令把所有事情都做掉中途一旦某个环节出错后期排查会很痛苦。不如让它先“纸上谈兵”我确认无误后再让它继续。命令拆得越细AI 越可控。5.2 用/需求和/规划把任务拆掉接着我用/需求把那个图片工具的功能拆成了具体的用户故事和验收标准/需求 支持按拍摄日期EXIF 里的 DateTimeOriginal分目录保留原始文件名前缀输出操作日志它会生成一个列表里面有“读取 EXIF 信息”、“处理无 EXIF 的文件”、“目标目录已存在同名文件时如何处理”这类细节。我只看了一眼就发现它确实把边界条件想清楚了。然后我敲/规划它会结合当前已生成的代码骨架把功能拆成可执行的开发任务并且标出先后依赖关系。这一步的输出质量直接决定了后面/开发的流畅程度。规划做得越细后面 AI 跑偏的可能性就越小。5.3 制造一个 bug再看/修复怎么揪出来为了测试/修复命令我故意在项目的核心函数里加了一个很隐蔽的错误在遍历图片文件时我把if not file_path.endswith((.jpg, .jpeg))写成了if not file_path.endswith(.jpg, .jpeg)也就是endswith传参方式不对它不会直接报语法错误但逻辑会完全失灵。然后我敲/修复 运行时报错TypeError: endswith() takes no keyword arguments命令执行后Claude Code 先是跑了git diff发现这个函数有改动历史然后又去翻对应的测试文件。它给出的诊断是“调用方式错误endswith不支持这种多后缀写法应改为元组传入。”接着它不仅改了代码还反手补了一个针对endswith的单元测试。这里我体会到一件事/修复之所以比普通对话好用是因为它在 prompt 里强制要求了“给证据再动手”。如果不是这个约束AI 大概率会直接改代码然后拿一句“已修复”交差你根本不知道它到底改对了没有。5.4/审查、/测试、/提交串成收尾流水线修完 bug 之后我依次敲了/审查、/测试、/提交。/审查第一次运行时它给我指出了两个问题一是异常处理太宽泛except Exception会把 KeyboardInterrupt 也吞掉二是一个函数没有类型注解不符合项目的风格约定。这两个点都挺中肯不是那种“建议添加更多注释”的废话。/测试命令则会先看项目里已有的测试文件补几个缺失的场景然后跑pytest把失败结果整理成表格。这里不用我告诉它“运行 pytest”因为命令 prompt 里写了它会自己找测试入口。最后/提交运行完它会给我一段符合 Conventional Commits 格式的提交信息比如fix(cli): correct image extension matching logic - Fixed endswith argument passing for multiple extensions - Added regression test for JPEG/JPG detection我确认无误后直接用整个过程顺滑得像一个训练有素的助手在帮忙。6. 意外情况和踩坑记录这些细节不注意命令就是摆设前面讲的都是“顺利路径”但实际操作中你一定会碰到各种幺蛾子。这里我整理了三个频次最高的坑希望你少走弯路。6.1 命令执行到一半“失忆”——上下文被截断Claude Code 本身有很长的上下文窗口但当你跑的是连环命令时前面命令的输出会在会话里堆积。尤其是/规划之后紧接着/开发如果规划结果很长后面命令在读取时就可能丢掉之前的细节。我的解法在CLAUDE.md或命令 prompt 里显式要求“在开始前先读取项目根目录的PLAN.md”而不是在对话里翻找。比如/开发命令的第一步永远是“读取当前目录下的PLAN.md如果没有就停止并提示”。这样信息是通过文件传递不依赖聊天历史稳定得多。建议每个项目的根目录都放一个CLAUDE.md里面写清楚项目背景、技术栈、命令约定。Claude Code 在每次会话开始时都会自动读取它相当于给 AI 一个“出厂记忆”。6.2 Bash 工具执行权限不足某些命令里写了要跑git log、npm test但实际运行时如果 Claude Code 的权限配置限制了 Bash 工具特别是第三方 API 接入的场景它可能会“拒绝执行终端命令”。表现是它会回复你“我没有权限运行此命令”然后停下来。处理方式在第一次会话时允许它使用 Bash 工具或者检查你的 API 配置是否支持函数调用。如果你用的是本地模型这一步最容易出问题因为一些轻量级模型的函数调用能力不够它根本不知道什么时候该调Bash工具。如果条件允许我建议你把“允许执行终端命令”这个选项开起来但只限制必要的命令白名单比如git status、git diff、pytest、npm test这种只读或可回滚的命令。千万别给它一把万能钥匙AI 手滑删库的故事网上不少。6.3 切换模型后命令表现不一致我在接入 DeepSeek、Qwen、GLM 这几个模型之后明显感觉到同一个命令在它们手下的“性格”不一样。有的模型很稳会在动手前先想步骤有的模型太“急”拿到命令就开干输出就不够规范。这里我给你的建议是如果团队里混用不同模型最好在关键命令里增加“结构化输出”的约束。比如要求“先输出文件清单再输出修改内容最后输出测试结果”。步骤约束越细不同模型的执行结果就越接近。另外如果你的主力模型是拿 API 转接的记得定期跑一遍那 10 个命令的“冒烟测试”。我自己的习惯是每两天花十分钟把/测试和/提交在两个小项目上跑一遍确认命令没有“退化”。7. 参数设计、权限边界与命令维护一套能用三个月的命令包命令写出来只是第一步真正要让它融入日常开发还需要考虑参数传递和长期维护。7.1 参数设计学会用 argument别把命令写死我早期写命令的时候犯过一个错把要处理的模块名直接硬编码在命令里。比如/重构里写死了“重构src/api.py”结果换一个项目就不能用了。后来我改成了用参数传递argument_hint: [目标模块或文件路径]然后在正文里用{{argument}}引用请重构 {{argument}} 这个模块要求保持对外函数签名不变。这样命令从“一次性脚本”变成了“可复用函数”。不同项目、不同任务换个参数就能用这才是命令包该有的样子。7.2 权限边界命令不是免费的“万能代理”命令包再强大也建议把 AI 的权力边界划清楚。我的设计原则是有些动作必须“先出方案等我确认”——比如/发布里的版本号升级。有些动作可以“自主执行”——比如/测试里跑pytest。有些动作直接“禁止”——比如所有会对项目结构产生不可逆影响的改动必须先输出git diff给我看。这个边界的明确划分不是为了限制 AI 的工作能力而是为了保住你的代码仓库。你把需要确认的点写进命令它就会在执行前停下来跟你沟通。7.3 命令维护写“命令的文档”和“文档的命令”10 个命令一旦铺开你自己也会忘记有些命令的细节。我建议在每个命令文件的最下面加一个“使用示例”区域记录一次真实的调用示例和输出结果。比如/修复.md末尾我会写着示例 /修复 运行 pytest 时 test_upload 失败断言超时 输出定位到 src/uploader.py:83原因是 SDK 超时配置未生效修复后测试通过。这个区不需要太长但非常有用。下个月你重新看这个命令时不用自己猜直接看示例就知道它能干嘛。我个人的维护频率是每完成一个新项目就过一遍命令包看有没有需要补充的新约定。比如最近一次我就在/审查里加了一条“检查所有新增代码是否包含 API Key 硬编码”因为那个项目踩了一次生产事故。7.4 环境隔离不同项目用不同的命令规则如果你同时维护多个项目你会发现不同项目的“规矩”可能完全不一样。一个项目用的是 pytest另一个项目用的可能是 vitest一个项目要求 type hints另一个项目可能还在用裸变量。这时候建议把命令分成两层第一层是全局命令放在~/.claude/commands/里适合那些所有项目通用的动作比如/提交和/审查第二层是项目级命令放在项目根目录的.claude/commands/下适合只对这个仓库生效的规则。Claude Code 会在运行时自动把项目级命令和全局命令合并。同名命令优先走项目的这意味着你可以针对某个特殊项目微调命令而完全不影响其他项目。试了一轮之后我个人的体会是真正难的不是把命令文件写出来而是把你的工作流想清楚。命令只是你思考的“固化形态”。你越是知道自己希望 AI 在什么节点做什么事、什么动作必须保留人类确认命令包用起来就越顺手。这也是为什么同一个开源工具在不同人手里差距极大的根本原因。这套 10 个中文命令的方案我现在已经用在了两个正式项目上每天高频触发开发、修复、提交这三个命令。再往后走我还打算给它接一个自动生成周报的/周报命令——让 AI 把这周的 git history 直接转成给团队看的总结。对写代码的人来说这算是在“程序员的最后一公里”上再往前走了一步。