Claude Code 中文命令封装：10个高频命令打造中文AI编程工作流-北京尧图网络

1. 为什么我要把中文命令塞进 Claude Code用 Claude Code 写代码这件事最开始吸引我的不是它能补全多少行而是它把终端变成了一个可以对话的编程入口。敲一句自然语言它就能读文件、改代码、跑测试、提交 commit。但用久了你会发现一个很别扭的地方所有交互都是英文语境。我让它在项目里加一个用户登录接口它回我一段英文解释我让它把这段逻辑抽成工具函数它用英文确认一遍再动手。不是看不懂而是每次都要在脑子里做一次中英切换尤其是连续工作两三个小时之后这种切换会明显拖慢节奏。更麻烦的是命令层面的割裂。Claude Code 本身有一套斜杠命令体系比如/compact压缩上下文、/model切换模型、/resume恢复会话这些都是英文的。而我在日常开发里积累了大量中文习惯用语——帮我看看这个报错把这段重构一下跑一下测试提交并写清楚 message。如果每次都要把这些翻译成英文再喂给工具那这个工具就没有真正融入我的工作流它只是又一个需要我适应的外部系统。所以我做了一个决定把 10 个高频中文命令封装成 Claude Code 可以直接识别的自定义命令让整个交互链路变成中文优先。这不是简单的翻译而是把中文开发者的表达习惯、项目上下文、常用操作模式一起打包进去。做完之后的效果是我在终端里敲/查错、/重构、/测试、/提交这些命令Claude Code 就能直接理解意图并执行对应动作中间不需要任何英文中转。这个工作流包的核心价值在于三点。第一降低认知负担中文母语开发者不需要在工具使用上额外消耗注意力。第二固化最佳实践每个中文命令背后其实是一套经过验证的操作流程比如/查错会自动先读最近修改的文件、再看报错日志、最后给出修复建议而不是漫无目的地问。第三可迁移这套思路不局限于 Claude Code任何支持自定义命令的 CLI 工具都能套用比如 Codex CLI、各类 AI 编程助手。适合谁来参考如果你已经在用 Claude Code 或者准备上手并且日常开发以中文思维为主这套东西能直接抄。如果你用的是其他 AI 编程 CLI命令封装的方法论同样适用只是配置文件的位置和语法需要调整。如果你还没接触过这类工具建议先跑通基础安装和登录再来看命令封装否则容易在环境问题上卡住。接下来我会把这 10 个命令逐个拆开讲清楚每个命令解决什么问题、背后的 prompt 怎么设计、配置文件怎么写、实测中遇到哪些坑。中间会穿插 Claude Code 的安装配置、自定义命令机制、上下文管理这些基础内容保证从零开始的读者也能跟上。2. Claude Code 自定义命令机制与工作流包的整体设计2.1 自定义命令到底存在哪里Claude Code 的自定义命令机制本质上是把 Markdown 文件当作命令模板。你在特定目录下放一个.md文件文件名就是命令名文件内容就是发给模型的 prompt 模板。当你在会话里输入/文件名时Claude Code 会读取这个文件把里面的内容作为指令注入到当前上下文然后模型基于这个指令和当前项目状态来执行。命令文件的位置分两个层级。项目级命令放在项目根目录的.claude/commands/下只对当前项目生效适合放跟这个项目强相关的命令比如部署到测试环境生成 API 文档。用户级命令放在用户主目录的~/.claude/commands/下对所有项目生效适合放通用命令比如查错重构提交。我这次封装的 10 个中文命令全部放在用户级目录因为它们是跨项目通用的。这里有个容易踩的坑目录名必须是commands不是command也不是cmd。我一开始写成.claude/command/结果命令死活不生效排查了半小时才发现是目录名拼错了。Claude Code 不会给你任何报错提示它只是静默地找不到命令。所以如果你发现自定义命令没反应第一件事就是检查目录名和文件扩展名。文件扩展名必须是.md文件名就是命令触发词。比如你想用/查错触发文件名就得是查错.md。中文文件名在 macOS 和 Linux 上都没问题Windows 上需要注意终端编码建议用 UTF-8。如果你的终端对中文文件名支持不好可以用拼音或者英文文件名然后在文件内容里用中文写 prompt效果是一样的。2.2 命令文件里到底写什么一个命令文件的内容本质上就是一段给模型的指令。但要让命令真正好用光写一句帮我查错是不够的。我总结了一个四段式模板每个命令文件都按这个结构写第一段是角色设定告诉模型在这个命令下应该扮演什么角色。比如/查错命令里写你是一名资深调试工程师擅长从报错信息和代码变更中定位根因。角色设定能显著影响模型的输出风格和关注点。第二段是执行步骤把操作流程拆成有序步骤。比如/查错的步骤是先读取最近修改的文件列表再读取报错日志或终端输出然后对比变更和报错定位可疑代码最后给出修复方案。步骤化能避免模型跳步或者遗漏关键信息。第三段是输出格式规定模型返回结果的结构。比如要求它先给一句话结论再给详细分析最后给可执行的修复命令。格式约束能让输出更易读也方便你快速抓重点。第四段是边界条件说明什么情况下不要执行或者要停下来问。比如如果报错信息不完整先向用户确认完整日志不要猜测。边界条件能防止模型在信息不足时瞎编。这四段写下来一个命令文件大概 30 到 80 行。太短了模型容易自由发挥太长了会占用过多上下文。我的经验是控制在 50 行左右最舒服既能说清楚又不会把上下文撑爆。2.3 十个命令的分工与命名逻辑我选的这 10 个命令覆盖了日常开发最高频的几类操作。命名上我刻意用了两字中文动词因为短、好记、输入快。具体分工是这样的命令触发词核心用途典型场景查错/查错定位并修复报错测试失败、运行时报错重构/重构改善代码结构函数过长、重复代码测试/测试生成或补充测试新功能缺测试、覆盖率不足提交/提交生成 commit 并提交完成一个功能点后解释/解释讲清代码逻辑接手陌生模块优化/优化性能与可读性优化慢查询、热点函数文档/文档生成注释和文档公共 API、工具函数审查/审查代码审查提交前自查、review回滚/回滚安全撤销变更改错了、要放弃当前改动总结/总结归纳当前会话进展长会话中途、切换任务前这个分工的逻辑是按开发流程的时间线排列。从接手代码解释、写代码重构、优化、验证测试、查错、审查审查、提交提交、文档到出问题回滚和阶段性收尾总结。每个命令对应流程里的一个节点用的时候不需要想我该用哪个按当前所处阶段自然就能选出来。命名上还有一个细节避免用单字命令。我一开始想用/查、/改、/测但单字太容易和别的命令前缀冲突而且输入时容易误触。两字动词既短又有明确语义实测下来最顺手。3. 从零跑通 Claude Code 与命令目录的搭建3.1 安装环节最容易卡住的地方Claude Code 的安装本身不复杂官方推荐用 npm 全局安装。命令是npm install -g anthropic-ai/claude-code但这一步在实际操作里卡住的人特别多我见过最多的三类问题。第一类是Node 版本不够Claude Code 要求 Node 18 以上如果你系统里是 16 或者更老安装会失败或者装上了跑不起来。用node -v确认版本不够就升级。第二类是npm 全局目录权限问题在 macOS 和 Linux 上如果 npm 的全局目录归 root 所有普通用户安装会报EACCES错误。解决办法是配置一个用户级的全局目录而不是用sudo硬装因为sudo装出来的包后续升级又会遇到权限问题。第三类问题最隐蔽安装过程很慢甚至超时。这通常是 npm 源的问题换成国内镜像源能明显改善。配置命令是npm config set registry https://registry.npmmirror.com换源之后重新安装速度会快很多。如果你已经装了一半失败先npm uninstall -g anthropic-ai/claude-code清理干净再重装避免残留文件导致后续命令行为异常。安装完成后用claude --version验证。能打印出版本号就说明装好了。如果提示command not found说明 npm 全局 bin 目录不在 PATH 里需要手动加进去。这个路径可以用npm config get prefix查到然后把$PREFIX/bin加到你的 shell 配置文件里。3.2 登录与首次启动的注意事项装好之后第一次运行claude它会引导你完成登录。这里有个细节Claude Code 的登录态是跟终端会话绑定的如果你在多个终端窗口同时用可能需要分别登录或者确保它们共享同一个配置目录。配置目录默认在~/.claude/登录凭证也放在这里。首次启动时Claude Code 会问你一些偏好设置比如是否允许它自动执行命令、是否开启遥测。我的建议是自动执行命令先关掉等你熟悉它的行为模式之后再按需开启。因为自动执行意味着它可以在不询问你的情况下跑 shell 命令虽然大多数时候没问题但在涉及删除文件、修改系统配置的场景下多一层确认更稳妥。启动之后你会看到一个交互式界面可以直接输入自然语言。这时候先别急着封装命令先用几句简单指令测试一下基本功能比如让它列出当前目录的文件或者读一下 package.json。确认它能正常读写文件、执行命令之后再进入命令封装环节。3.3 创建命令目录并放入第一个命令确认 Claude Code 能正常工作后创建用户级命令目录mkdir -p ~/.claude/commands然后创建第一个命令文件比如查错.md。用你习惯的编辑器打开写入四段式内容。写完之后在 Claude Code 会话里输入/查错如果它能识别并开始按你的指令执行说明整条链路通了。这里有个验证技巧先写一个极简命令测试机制是否生效。比如文件内容只写回复命令已生效。输入/查错后如果它回复这句话说明目录、文件名、扩展名都没问题然后再把完整内容替换进去。这样能把机制问题和prompt 问题分开排查省很多时间。如果命令没生效按这个顺序检查目录名是不是commands、文件扩展名是不是.md、文件名和触发词是否完全一致包括大小写、文件是否有读取权限。这四项覆盖了 90% 的不生效问题。4. 十个中文命令的 prompt 设计与实测效果4.1 查错与回滚处理出问题时的两个命令/查错是我用得最频繁的命令。它的 prompt 设计核心是强制模型先收集信息再下结论。很多 AI 工具的通病是一看到报错就急着给修复方案但报错信息往往只是表象真正的根因可能在几层调用之外。所以我在命令里明确要求第一步读取最近修改的文件第二步读取完整报错第三步对比两者定位可疑变更第四步才给修复方案。实测下来这个顺序很关键。有一次我遇到一个undefined is not a function的报错如果直接问模型它大概率会让我检查那个变量。但按/查错的流程走它先看了我最近改的文件发现我刚刚重构了一个模块的导出方式根因其实是导入路径变了导致拿到的是 undefined。这个定位过程如果没有先看变更这一步很容易被带偏。/回滚的设计重点是安全。撤销变更这件事风险很高搞不好会把没提交的工作一起弄丢。所以这个命令的 prompt 里我加了三道保险第一先列出当前所有未提交的变更让用户确认要撤销哪些第二区分撤销工作区改动和撤销已暂存改动不混在一起第三执行前明确提示哪些文件会被影响。实测中这个命令救过我两次一次是改错了一个配置文件想快速恢复一次是实验性改动不想留痕迹。这两个命令配合使用效果很好/查错定位问题如果判断是最近改动引入的直接/回滚撤销。整个链路都在中文语境里完成不需要切换思维。4.2 重构与优化改善代码质量的两个角度/重构和/优化看起来像但关注点完全不同。重构关注结构优化关注性能。我在 prompt 里把这两个目标分得很清楚避免模型把两件事混在一起做。/重构的 prompt 要求模型先识别代码坏味道比如函数过长、参数过多、重复逻辑、深层嵌套然后针对每种坏味道给出具体的重构手法比如提取函数、引入参数对象、合并条件表达式。关键是要求它一次只改一个坏味道改完让用户确认再继续。因为一次性大改很容易引入新 bug而且 diff 太大没法 review。/优化的 prompt 则要求先定位性能瓶颈再谈优化。我让它先分析代码里的热点比如循环里的重复计算、频繁的 DOM 操作、没必要的深拷贝然后按收益/风险比排序给出优化建议。高收益低风险的先做比如缓存重复计算结果高风险的比如改数据结构单独标出来让用户决定。实测中我发现一个反直觉的点优化命令不要让它自动改代码。因为性能优化经常涉及权衡比如用空间换时间这种决策应该由人来做。所以/优化的 prompt 我设定为只给建议和示例代码不直接修改文件。而/重构因为目标明确改善结构不改变行为可以允许它直接改但改完必须跑测试验证。4.3 测试与审查质量保障的两个环节/测试命令解决的是写测试很烦这个问题。它的 prompt 设计要点是先分析被测代码的边界条件再生成测试用例。很多人写测试只覆盖正常路径边界条件比如空输入、极值、异常分支经常漏掉。我让模型先列出所有边界条件再针对每个条件生成用例覆盖率明显提升。这个命令还有个实用变体针对已有测试补充缺失用例。有时候项目里已经有测试文件但覆盖不全。/测试会先读现有测试分析哪些分支没覆盖到然后只补缺失的部分不重复生成已有用例。这个功能在维护老项目时特别省事。/审查是提交前的最后一道关。它的 prompt 要求模型从几个固定维度检查逻辑正确性、边界处理、错误处理、命名规范、潜在性能问题、安全隐患。每个维度给出具体发现而不是笼统地说代码不错。实测中它抓到过几次我漏掉的空指针风险和资源未释放问题。审查命令的输出我设定为按严重程度分级阻断性问题必须改建议性问题可选改风格问题仅供参考。这样 review 的时候能快速抓重点。4.4 提交、文档、解释、总结日常高频四件套/提交命令的核心是生成规范的 commit message。它的 prompt 要求先看git diff了解改了什么再按约定式提交格式生成 message比如feat: 添加用户登录接口、fix: 修复分页越界问题。关键是让它用中文写 message因为团队里大家都看中文英文 message 反而增加理解成本。实测中这个命令让我的提交记录规范了很多以前经常写update、fix bug这种没信息量的 message。/文档命令生成注释和文档。它的 prompt 要求区分对外文档和内部注释对外文档写清楚用途、参数、返回值、示例内部注释只写为什么这么写不写这行在做什么。因为代码本身能说明做什么注释应该补充代码表达不了的意图。这个区分很重要很多项目的注释都在重复代码已经说清楚的事真正的设计意图反而没写。/解释命令用于快速理解陌生代码。它的 prompt 要求从调用链角度解释而不是逐行翻译。先讲这个模块在整个系统里的位置再讲它的输入输出最后讲关键实现。实测中接手别人代码时用这个命令比直接读代码快很多尤其是那些缺少文档的老模块。/总结命令用于长会话的阶段性收尾。它的 prompt 要求归纳已完成的事、待办的事、遇到的阻塞三部分。在连续工作几小时后用这个命令快速回顾进展或者切换任务前留个记录很实用。它还会把关键决策点记下来避免下次会话时忘记之前为什么这么选。5. 实测中踩过的坑与排查链路5.1 命令不生效的完整排查过程第一次封装命令时我遇到了命令完全不生效的问题。输入/查错之后Claude Code 把它当成普通文本处理没有任何特殊反应。这个问题的排查过程值得完整记录因为类似问题很常见。第一步我确认了命令文件确实存在用ls -la ~/.claude/commands/能看到查错.md。文件在排除路径问题。第二步我检查了文件内容确认不是空的排除内容问题。第三步我在会话里输入/help看命令列表发现自定义命令根本没出现在列表里。这说明 Claude Code 压根没扫描到我的命令目录。这时候我怀疑是目录层级问题。Claude Code 扫描命令的路径是~/.claude/commands/但我当时建的是~/.claude/command/少了个 s。改过来之后重新启动会话命令出现在列表里了。这个坑的教训是Claude Code 对目录名拼写错误没有任何提示它只是静默忽略。所以命令不生效时第一件事就是核对目录名。还有一次是文件编码问题。我在 Windows 上用记事本创建了命令文件保存时默认用了 GBK 编码结果 Claude Code 读取时中文全是乱码命令虽然被识别但 prompt 内容全错了。改成 UTF-8 编码后正常。跨平台使用时编码问题一定要提前确认。5.2 上下文被撑爆的应对策略用了一段时间后我遇到一个新问题长会话里上下文越来越满模型开始遗忘早期指令。Claude Code 有上下文窗口限制当对话轮次多了、读的文件多了早期内容会被挤出去。这时候自定义命令的行为会变得不稳定有时候按 prompt 执行有时候像没看到 prompt 一样。解决办法有两个。短期办法是用/compact命令压缩上下文它会把历史对话总结成摘要释放空间。但压缩之后细节会丢失适合在阶段性任务完成后用。长期办法是控制单次会话的任务范围一个会话专注一件事做完就/总结然后开新会话。我现在养成的习惯是一个功能点一个会话做完提交开新会话做下一个。这样上下文始终清爽命令行为也稳定。还有一个技巧是把大文件读取拆开。有时候/查错需要读很多文件一次性全读进来会瞬间占满上下文。我在 prompt 里加了限制单次最多读 5 个文件如果不够先给分析再让用户决定读哪些。这样既保证信息够用又不会撑爆窗口。5.3 模型自由发挥导致输出跑偏的修正自定义命令的 prompt 写得不够具体时模型会自由发挥输出跟你预期完全不同的东西。我遇到过几次/重构命令把代码改得面目全非虽然结构确实改善了但行为也变了测试全挂。根因是 prompt 里没有强调重构不改变外部行为这个约束。修正方法是在 prompt 里加一条硬性要求重构前后必须跑测试测试不通过就回退。同时明确列出允许的重构手法不允许的手法比如改函数签名、改数据结构需要单独确认。另一个跑偏场景是/文档命令生成的注释太啰嗦把代码逐行翻译了一遍。修正方法是加约束注释只写设计意图和边界条件不写代码已经表达的内容单个注释不超过三行。加了这条之后输出质量明显提升。通用经验是自定义命令的 prompt 要像给新人写操作手册一样具体。你觉得不用说也懂的约束模型不一定懂。把边界、格式、禁止事项都写清楚输出才稳定。6. 让工作流包真正融入日常开发的几个习惯6.1 命令组合使用的节奏感单个命令好用但真正的效率提升来自命令的组合。我现在的日常节奏是这样的接手新任务先用/解释快速理解相关代码然后/重构改善要改动的部分写代码过程中用/测试补测试写完用/审查自查通过后/提交最后/总结记录进展。这一套走下来每个环节都有工具支撑不需要在脑子里切换模式。出问题的时候组合更关键。测试挂了先/查错如果定位到是最近改动引入的/回滚撤销然后重新来。如果是老代码的隐藏问题/查错定位后/优化或/重构修复再/测试验证。整个排查修复链路都在中文语境里完成思路不会被打断。这里有个节奏上的经验不要在单个命令上纠结太久。如果/查错跑了两轮还没定位到根因说明信息不够这时候应该手动补充信息比如贴更多日志、说明复现步骤而不是反复跑同一个命令。工具是辅助判断还是靠人。6.2 根据项目特点调整命令内容这 10 个命令是通用版本但每个项目有自己的特点直接套用效果会打折扣。我的做法是在项目级命令目录里放定制版本覆盖用户级的通用版本。比如某个项目用特定的测试框架项目级的/测试命令就写明用这个框架的语法某个项目有特殊的提交规范项目级的/提交就按这个规范生成 message。项目级命令放在项目根目录的.claude/commands/下优先级高于用户级。这样同一个命令名在不同项目里有不同行为既保持了命令名的统一又适配了项目差异。这个机制很实用建议每个项目都建一个项目级命令目录把项目特有的操作固化进去。调整命令内容时有个原则只改跟项目强相关的部分通用逻辑保持不变。比如/查错的排查流程是通用的不用改但读取报错日志的路径是项目特有的需要改。这样维护成本最低也不会因为改多了引入新问题。6.3 持续迭代命令的实用方法命令不是写完就完了需要在用中迭代。我的做法是每次命令输出不理想时记一笔攒够几条就统一改 prompt。比如我发现/审查经常漏掉资源释放问题就在 prompt 的检查维度里明确加上资源管理这一项。改完之后再观察一段时间看问题是否解决。迭代时有个技巧改动要小步走一次只改一个点。如果一次改太多输出变好了你不知道是哪个改动起的作用变差了也不知道该回退哪个。我一般一次只加一条约束或者调整一个步骤改完用几个真实场景验证确认有效再继续。还有一个方法是把常用场景固化成命令的示例。比如/提交命令里我放了几个 commit message 的示例模型会参考这些示例的风格。示例比抽象描述更有效尤其是格式类的要求。你可以把团队里写得好的 commit、注释、文档片段放进命令文件当示例输出质量会明显提升。这套工作流包我用了几个月最大的感受是AI 编程工具的价值不在于它多聪明而在于它多贴合你的习惯。把中文命令封装进去本质上是在工具和你之间建了一层翻译让工具适应你而不是你适应工具。这 10 个命令只是起点你可以按自己的开发习惯增删改最终形成一套完全属于自己的中文 AI 编程工作流。

Claude Code 中文命令封装：10个高频命令打造中文AI编程工作流

相关推荐

基于Python Flask的码头船只货柜管理系统实战全解析

嵌入式电源路径保护：eFuse与MCU协同实现可诊断可恢复的硬保护设计

Pi Agent 工具提示词优化：按需加载省 91% token 的实操指南

更多资讯

Ryzen AI Max NPU激活指南：让gfx1151真正驱动SnowLLM

AnyPS5：面向Linux开发者的PS5硬件逆向工具链

Ponytail插件实战：AI整理引擎把碎片信息一键扎成周报日报

前端 Vite 接大模型接口：从 dev server 到上线，4 个最容易被忽略的工程坑

游戏引擎基础架构：内存、数据结构与数学库的底层设计

AI策略执行报告实战：从Policy到可执行拦截体系的工程化落地

今日更新

Agent Skills 完全指南：原理、写法、安装与实战避坑

Agent Skills 实战：从 Genkit 定义到 GKE 部署与排查

Agent Skills 实战：从设计到调试的完整指南

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？