1. 为什么我要给 Claude Code 装一套中文命令用 Claude Code 写代码这件事我从它刚开放命令行版本就开始跟了。最开始那阵子我每天的工作流大概是这样的打开终端敲claude然后用英文跟它描述需求等它生成代码再手动复制到项目里跑一遍测试出错了再切回终端继续对话。一天下来光是来回切换窗口和重复描述上下文就消耗掉大量精力。真正让我下决心做一套中文命令工作流包的是连续三天遇到同一个问题每次新开一个会话我都要重新告诉它“这个项目用 pnpm 不用 npm”“测试用 vitest 不是 jest”“提交信息用中文”“不要动legacy/目录下的文件”。这些规则我明明已经说过无数遍但每个新会话都是白纸一张。Claude Code 本身支持CLAUDE.md项目记忆文件但那个文件是给项目用的不是给我个人工作习惯用的。我需要的是一个跨项目、跨会话都能生效的“个人命令层”。于是我开始琢磨能不能把那些我每天都要重复输入的指令封装成简短的中文命令比如输入/审查就自动触发代码审查流程输入/提交就按我的规范生成提交信息输入/解释就用中文把这段代码讲清楚。这样我不用记那些冗长的英文提示词也不用每次重新交代背景。这个想法落地之后我陆续封装了 10 个命令覆盖了从代码审查、提交规范、测试生成到文档翻译、依赖检查、性能分析等高频场景。实测下来每天至少省掉 30 到 40 分钟的重复沟通时间而且因为命令里固化了我的偏好和规范AI 输出的质量反而比我自己临时描述更稳定。这篇文章就是把这 10 个命令的设计思路、具体实现、踩过的坑和实际效果完整拆开讲一遍。如果你也在用 Claude Code、Codex CLI 或者类似的 AI 编程工具并且受够了每次都要重新交代背景的麻烦这套思路可以直接抄作业。哪怕你只用其中两三个命令也能明显感觉到工作流的顺畅度不一样。2. 整体设计思路命令层到底解决什么问题2.1 Claude Code 的原生命令机制是怎么回事Claude Code 的命令系统其实分两层。一层是内置的斜杠命令比如/compact用来压缩上下文、/model切换模型、/resume恢复会话这些是工具自带的你改不了。另一层是自定义命令通常放在~/.claude/commands/目录下每个命令对应一个 Markdown 文件文件名就是命令名文件内容就是提示词模板。这个机制的关键在于自定义命令本质上是一段预设的提示词当你输入/命令名的时候Claude Code 会把这段提示词连同你附加的参数一起发给模型。所以命令的质量直接取决于你提示词写得好不好。我见过很多人把自定义命令当成“快捷短语”来用比如写一个/fix就一句“帮我修复这个 bug”。这种命令价值有限因为信息量太低模型还是要靠猜。真正有用的命令应该是一个完整的“工作流封装”——它要包含角色设定、输入说明、处理步骤、输出格式、边界条件这五个要素。2.2 为什么选择中文命令而不是英文这个问题我被问过好几次。用英文命令不是更通用吗我的回答是看你个人的思维语言是什么。我在描述需求、思考问题的时候脑子里跑的是中文。如果命令名是英文我还得先做一次“中文需求→英文命令”的翻译这个转换本身就有认知成本。更重要的是命令内部的提示词用中文写模型对中文指令的理解在代码场景下已经足够好了。我实测过同一段提示词分别用中英文写在代码审查、测试生成这类任务上输出质量没有明显差异。但中文提示词对我来说维护成本更低改起来更快不容易出现“这个词英文到底该用哪个”的纠结。当然有个例外如果命令涉及具体的代码标识符、API 名称、框架专有名词那必须保留英文原文不能硬翻。比如useEffect就是useEffect翻成“使用效果”反而会让模型困惑。所以我的原则是命令名和流程描述用中文技术术语保留英文。2.3 十个命令的选型逻辑我没有一上来就堆二十个命令而是先观察自己一周的工作流把重复出现的操作记下来然后按频率排序。最后选出的这 10 个命令覆盖了四个大类类别命令解决的核心问题代码质量/审查/重构/测试减少人工 review 和补测试的时间版本管理/提交/分支/回滚规范 Git 操作避免手滑知识处理/解释/翻译快速理解陌生代码和文档环境维护/依赖/清理保持项目健康度选型的时候我遵循一个原则只封装那些“每次做都要想一下”的操作。如果一个操作我已经形成了肌肉记忆闭着眼睛都能敲对那就不需要封装成命令。命令的价值在于降低认知负荷而不是把所有操作都包一层。2.4 命令文件的目录结构和加载机制我的命令文件放在~/.claude/commands/下面按类别建了子目录~/.claude/commands/ ├── code/ │ ├── 审查.md │ ├── 重构.md │ └── 测试.md ├── git/ │ ├── 提交.md │ ├── 分支.md │ └── 回滚.md ├── docs/ │ ├── 解释.md │ └── 翻译.md └── env/ ├── 依赖.md └── 清理.md这里有个细节要注意Claude Code 加载自定义命令的时候子目录名会成为命令命名空间的一部分。也就是说code/审查.md对应的命令是/code:审查而不是/审查。如果你想要短命令名就得把文件直接放在commands/根目录下。我一开始为了命令短全放在根目录结果文件多了之后ls一屏都显示不完找起来很烦。后来改成子目录加命名空间虽然输入多几个字符但 Tab 补全的时候分类清晰反而不容易敲错。这个取舍看个人习惯没有绝对的对错。3. 核心命令的提示词拆解与实操要点3.1/审查命令让 AI 按你的标准做代码审查这个命令是我用得最频繁的平均每天触发 8 到 10 次。它的提示词结构是这样的你是一位有十年经验的 [语言] 工程师现在需要对一段代码做审查。 审查维度按优先级排列 1. 正确性逻辑是否有漏洞边界条件是否处理 2. 安全性是否有注入、越权、敏感信息泄露风险 3. 性能是否有明显的 N1 查询、不必要的循环、内存泄漏 4. 可维护性命名是否清晰函数是否过长耦合是否过重 5. 风格一致性是否符合项目现有代码风格 输出格式 - 按严重程度分三级阻断、建议、提示 - 每条问题必须给出具体行号和修改建议 - 如果某个维度没有问题明确说“未发现” - 最后给一个总体评价不超过三句话 不要做的事 - 不要重写整段代码只指出问题和改法 - 不要提“可以加注释”这种废话建议 - 不要假设代码的用途有疑问就标注出来这个提示词里最关键的是“不要做的事”那一段。我踩过的坑是早期版本没有这段结果 AI 每次审查完都要把整段代码重写一遍输出巨长我还得自己对比哪里改了。加上禁止重写之后输出精简了至少 60%而且每条建议都直接可操作。另一个经验是审查维度要按优先级排。如果不排优先级AI 会把“变量名不够好”和“这里有 SQL 注入”并列输出你扫一眼还以为是同等重要的问题。排了优先级之后阻断级问题永远在最前面不会漏掉。注意这个命令对语言敏感。如果你的项目里同时有 TypeScript 和 Python最好在命令参数里指定语言或者在提示词里写“根据文件扩展名自动判断语言”。我试过不指定结果 AI 用 TypeScript 的标准去审查 Python 代码闹了不少笑话。3.2/提交命令规范 Git 提交信息Git 提交信息这件事团队里每个人的写法都不一样。有人写“fix bug”有人写“修复了登录页面的一个问题”还有人写“update”。我封装这个命令的目的是让每次提交都自动符合 Conventional Commits 规范同时保留中文描述。提示词核心部分根据以下 git diff 内容生成一条符合规范的提交信息。 格式要求 type(scope): 中文描述 type 取值范围feat, fix, refactor, docs, test, chore, perf, style scope 用英文表示影响的模块 中文描述不超过 50 个字动词开头说清楚做了什么 如果 diff 涉及多个不相关的改动提醒我拆分提交。 如果 diff 里有删除文件的操作在描述里明确说明。这里有个实操技巧我让命令直接读取git diff --staged的输出而不是让我手动粘贴。实现方式是在命令文件里写!git diff --stagedClaude Code 会把命令执行结果注入到提示词里。这样我只需要git add之后输入/提交它就能自动生成提交信息。实测下来这个命令帮我避免了两类问题一是提交信息写得太随意回头看 git log 完全不知道当时改了什么二是把不相关的改动混在一个提交里。现在 AI 会主动提醒我“这次 diff 里同时有登录逻辑修改和 README 更新建议拆成两个提交”这种提醒在早期是完全没有的。3.3/测试命令按项目测试风格生成用例生成测试用例的命令难点在于让 AI 理解你项目的测试风格。有的项目用describe/it有的用test()有的用 pytest 的class TestXxx。如果命令里不指定AI 会按它自己的默认风格写生成出来的测试你还得手动改格式。我的做法是在命令提示词里加一段“风格探测”逻辑先读取项目中已有的测试文件优先找 *.test.ts 或 test_*.py 分析其使用的测试框架、断言风格、mock 方式、命名习惯。 然后按照同样的风格为指定的源文件生成测试用例。 覆盖要求 - 正常路径至少 2 个用例 - 边界条件至少 2 个用例 - 异常路径至少 1 个用例 - 如果函数有副作用必须 mock 掉外部依赖 不要生成“测试框架本身”的测试比如测试 expect 是否工作。这个“先探测再生成”的思路是我从 Codex CLI 的工作流里借鉴过来的。它比直接生成准确得多因为 AI 有了参照物不会凭空发明一套风格。提示如果你的项目测试文件很少探测不到足够样本可以在命令里硬编码风格。比如“本项目统一使用 vitest testing-library/react断言用 expect().toBe()”。硬编码虽然不够灵活但比让 AI 猜要可靠。3.4/解释命令用中文讲清楚陌生代码接手老项目或者看开源库源码的时候这个命令特别有用。它的提示词设计重点是“分层解释”用中文解释以下代码分三层 第一层一句话说清楚这段代码是干什么的不超过 30 字 第二层按执行顺序拆解主要步骤每步一句话 第三层指出这段代码依赖的外部假设比如“假设调用方已经做了鉴权” 如果代码里有不常见的写法或历史遗留的 hack单独标注出来并说明可能的原因。 如果代码有潜在问题在最后用“注意”开头列出。三层结构的好处是你可以根据当前需要选择看哪一层。赶时间就看第一层要改代码就看第二层要做架构评估就看第三层。我试过让 AI 只输出一段笼统的解释结果它总是把三层混在一起读起来很累。3.5/依赖命令检查依赖健康度这个命令解决的是“项目跑了一段时间之后依赖悄悄烂掉”的问题。提示词里我让它做四件事读取package.json或requirements.txt列出所有直接依赖检查每个依赖的版本是否落后于最新稳定版标记出已经不再维护的包比如超过两年没有更新检查是否有重复功能的依赖比如同时装了axios和node-fetch输出用表格呈现三列包名、当前版本、建议操作。建议操作只有三种升级、替换、保留。这样我扫一眼就知道该动哪些。实测发现这个命令最大的价值不是告诉我“有新版本”而是帮我发现“这个包已经没人维护了”。有次它标记出一个我用了三年的工具库最后一次更新是四年前issue 区全是未回复的 bug 报告。我顺着它的建议换了一个活跃维护的替代品省掉了后面可能踩的大坑。4. 完整实操从零搭建这套命令工作流4.1 环境准备与目录初始化先把基础环境确认一遍。Claude Code 的安装方式根据系统不同有差异macOS 和 Linux 下通常用 npm 全局安装Windows 下建议在 WSL 里操作原生 PowerShell 偶尔会有路径问题。安装完成后确认命令目录存在mkdir -p ~/.claude/commands/{code,git,docs,env}然后验证 Claude Code 能识别到自定义命令。启动claude输入/看补全列表里有没有你新建的目录。如果没有检查两点一是目录名是否拼写正确二是 Claude Code 版本是否支持自定义命令早期版本不支持需要更新。注意如果你在 Windows 上用 WSL~指向的是 WSL 的用户目录不是 Windows 的用户目录。别把命令文件放到/mnt/c/Users/xxx/下面那样 Claude Code 读不到。4.2 编写第一个命令文件以/审查为例完整文件内容如下--- description: 对指定代码进行多维度审查 --- 你是一位有十年经验的资深工程师现在需要对以下代码做审查。 审查维度按优先级排列 1. 正确性逻辑漏洞、边界条件、空值处理 2. 安全性注入风险、越权访问、敏感信息硬编码 3. 性能N1 查询、不必要的循环、内存泄漏 4. 可维护性命名清晰度、函数长度、模块耦合 5. 风格一致性是否符合项目现有风格 输出格式 - 按严重程度分三级阻断、建议、提示 - 每条问题给出具体行号和修改建议 - 无问题的维度明确写“未发现” - 总体评价不超过三句话 禁止事项 - 不要重写整段代码 - 不要提“加注释”这类无操作性建议 - 不要假设代码用途有疑问就标注 待审查代码 $ARGUMENTS文件头部的description是给命令列表用的会显示在补全提示里。$ARGUMENTS是占位符你输入命令时跟的参数会替换到这里。4.3 参数传递与动态内容注入Claude Code 的命令支持两种动态内容一种是$ARGUMENTS接收用户输入另一种是!command执行 shell 命令并把输出注入提示词。/提交命令就用了第二种根据以下 git diff 生成提交信息 !git diff --staged 格式要求 type(scope): 中文描述 ...这样你git add之后直接输入/提交不需要手动粘贴 diff。实测这个体验比复制粘贴流畅太多尤其是在改动文件多的时候。有个坑要注意!command里的命令是在你当前工作目录执行的所以如果你在项目根目录启动 Claude Codegit diff就能正常工作。但如果你在子目录启动可能会报“not a git repository”。解决办法是在命令里写!git -C $(git rev-parse --show-toplevel) diff --staged强制从仓库根目录执行。4.4 命令之间的组合调用单个命令用熟了之后我开始尝试组合。比如审查完代码之后直接生成测试再直接提交。Claude Code 支持在一个会话里连续调用多个命令上下文是共享的。我的典型流程是改完代码输入/审查看有没有阻断级问题如果有问题让 AI 给出修改方案我手动改改完再/审查一遍确认阻断级问题清零输入/测试生成对应测试用例跑测试通过后git add输入/提交这个流程走下来从改完代码到提交平均 5 到 8 分钟。以前手动做同样的事光是想提交信息、补测试用例就要 15 分钟以上。4.5 跨工具迁移Codex CLI 和 ZCode CLI 的适配这套命令思路不局限于 Claude Code。Codex CLI 的自定义命令机制类似也是 Markdown 文件加提示词模板只是目录位置不同通常在~/.codex/commands/。ZCode CLI 也支持类似的配置方式。迁移的时候主要改两个地方一是目录路径二是动态内容注入的语法。Claude Code 用!commandCodex CLI 可能用{{shell:command}}之类的写法。提示词本身基本可以原样搬过去因为核心逻辑是通用的。我实测过把/审查和/提交两个命令迁移到 Codex CLI改完语法之后效果一致。这说明命令层的设计是工具无关的你花时间打磨的提示词不会因为换工具就作废。5. 常见问题与排查技巧实录5.1 命令不生效的几种原因现象可能原因排查方法输入/看不到自定义命令目录路径不对确认文件在~/.claude/commands/下命令名带命名空间但补全不出来子目录名有特殊字符子目录名只用英文和数字命令执行了但输出为空提示词里$ARGUMENTS没传值检查是否在命令后跟了参数!command报错命令在当前目录不可执行用绝对路径或-C指定目录中文命令名乱码终端编码不是 UTF-8设置LANGzh_CN.UTF-85.2 提示词写得太长导致响应变慢我一开始追求“把所有情况都写进提示词”结果/审查的命令文件写到了 800 多字。实测发现提示词超过 500 字之后模型响应时间明显变长而且它开始抓不住重点输出质量反而下降。后来我做了减法把提示词控制在 300 到 400 字只保留最核心的规则。那些“偶尔才用到”的边界情况改成在对话里临时补充。这样命令响应快输出也更聚焦。提示判断提示词是否过长有个简单标准——如果你自己读一遍要超过 30 秒那就太长了。命令提示词应该是“扫一眼就知道要干什么”的密度。5.3 命令输出格式不稳定的处理AI 输出格式不稳定是常态。同一个/审查命令有时候输出表格有时候输出列表有时候还给你加个总结段落。我的应对策略是在提示词里用“必须”和“禁止”来约束“必须按三级分类输出”“禁止在最后加总结”“每条问题必须包含行号”用了这些强约束词之后格式稳定性从大概 70% 提升到 90% 以上。剩下 10% 的不稳定通常是模型版本更新导致的需要重新调提示词。5.4 上下文超长时的命令降级策略项目大了之后/审查一次性审查整个文件可能会超出上下文窗口。这时候需要降级只审查改动的部分而不是整个文件。我的做法是在命令里加一段判断逻辑如果待审查代码超过 500 行只审查最近修改的部分。 修改部分通过 git diff 获取不要审查未改动的代码。这样即使在大项目里命令也能正常工作不会因为上下文超长而失败。5.5 命令版本管理与团队共享命令文件多了之后版本管理就成了问题。我试过直接放在 dotfiles 仓库里但命令文件更新频繁每次都要提交很麻烦。后来改成用一个独立的 git 仓库管理~/.claude/commands/用软链接指过去。团队共享的话可以把命令仓库设为内部公开每个人 clone 之后建软链接。但要注意命令里可能包含个人偏好比如提交信息用中文还是英文共享之前要把这些个性化配置抽出来放到单独的配置文件里。6. 实测效果与个人体会这套命令工作流我用了大概三个月累计触发超过 2000 次。最直观的变化是以前我每天要在终端里输入大量重复的英文提示词现在大部分操作都是两三个中文字符搞定。省下来的时间不是重点重点是省下来的注意力——我不用再分心去想“这句话该怎么用英文表达”可以直接把精力放在代码本身。另一个意外收获是输出质量的稳定性。因为命令里固化了我的标准和偏好AI 的输出不会因为我当天状态好坏而波动。以前我状态好的时候能写出很精准的提示词状态差的时候就随便说两句结果 AI 也跟着敷衍。现在不管我状态如何命令触发的都是同一套高质量提示词。如果你打算开始搭自己的命令集我的建议是从一个命令开始就用你最频繁的那个操作。用一周感受一下哪里不顺手然后改提示词。改到你觉得“这个命令已经不需要再动了”再加第二个。不要一上来就搭十个那样你根本没精力逐个打磨最后每个都是半成品。最后分享一个我最近在试的扩展方向把命令和项目的CLAUDE.md联动。命令负责通用流程CLAUDE.md负责项目特定规则两者叠加之后AI 既知道“怎么做审查”也知道“这个项目的审查标准是什么”。这个组合目前看效果不错等再跑一段时间有更多数据了再单独写一篇。 
长河君 · 2026/10/4 16:23:28 · 阅读 1.2k 给 Claude Code 装一套中文命令：10 个高频场景提示词封装实践
1. 为什么我要给 Claude Code 装一套中文命令用 Claude Code 写代码这件事我从它刚开放命令行版本就开始跟了。最开始那阵子我每天的工作流大概是这样的打开终端敲claude然后用英文跟它描述需求等它生成代码再手动复制到项目里跑一遍测试出错了再切回终端继续对话。一天下来光是来回切换窗口和重复描述上下文就消耗掉大量精力。真正让我下决心做一套中文命令工作流包的是连续三天遇到同一个问题每次新开一个会话我都要重新告诉它“这个项目用 pnpm 不用 npm”“测试用 vitest 不是 jest”“提交信息用中文”“不要动legacy/目录下的文件”。这些规则我明明已经说过无数遍但每个新会话都是白纸一张。Claude Code 本身支持CLAUDE.md项目记忆文件但那个文件是给项目用的不是给我个人工作习惯用的。我需要的是一个跨项目、跨会话都能生效的“个人命令层”。于是我开始琢磨能不能把那些我每天都要重复输入的指令封装成简短的中文命令比如输入/审查就自动触发代码审查流程输入/提交就按我的规范生成提交信息输入/解释就用中文把这段代码讲清楚。这样我不用记那些冗长的英文提示词也不用每次重新交代背景。这个想法落地之后我陆续封装了 10 个命令覆盖了从代码审查、提交规范、测试生成到文档翻译、依赖检查、性能分析等高频场景。实测下来每天至少省掉 30 到 40 分钟的重复沟通时间而且因为命令里固化了我的偏好和规范AI 输出的质量反而比我自己临时描述更稳定。这篇文章就是把这 10 个命令的设计思路、具体实现、踩过的坑和实际效果完整拆开讲一遍。如果你也在用 Claude Code、Codex CLI 或者类似的 AI 编程工具并且受够了每次都要重新交代背景的麻烦这套思路可以直接抄作业。哪怕你只用其中两三个命令也能明显感觉到工作流的顺畅度不一样。2. 整体设计思路命令层到底解决什么问题2.1 Claude Code 的原生命令机制是怎么回事Claude Code 的命令系统其实分两层。一层是内置的斜杠命令比如/compact用来压缩上下文、/model切换模型、/resume恢复会话这些是工具自带的你改不了。另一层是自定义命令通常放在~/.claude/commands/目录下每个命令对应一个 Markdown 文件文件名就是命令名文件内容就是提示词模板。这个机制的关键在于自定义命令本质上是一段预设的提示词当你输入/命令名的时候Claude Code 会把这段提示词连同你附加的参数一起发给模型。所以命令的质量直接取决于你提示词写得好不好。我见过很多人把自定义命令当成“快捷短语”来用比如写一个/fix就一句“帮我修复这个 bug”。这种命令价值有限因为信息量太低模型还是要靠猜。真正有用的命令应该是一个完整的“工作流封装”——它要包含角色设定、输入说明、处理步骤、输出格式、边界条件这五个要素。2.2 为什么选择中文命令而不是英文这个问题我被问过好几次。用英文命令不是更通用吗我的回答是看你个人的思维语言是什么。我在描述需求、思考问题的时候脑子里跑的是中文。如果命令名是英文我还得先做一次“中文需求→英文命令”的翻译这个转换本身就有认知成本。更重要的是命令内部的提示词用中文写模型对中文指令的理解在代码场景下已经足够好了。我实测过同一段提示词分别用中英文写在代码审查、测试生成这类任务上输出质量没有明显差异。但中文提示词对我来说维护成本更低改起来更快不容易出现“这个词英文到底该用哪个”的纠结。当然有个例外如果命令涉及具体的代码标识符、API 名称、框架专有名词那必须保留英文原文不能硬翻。比如useEffect就是useEffect翻成“使用效果”反而会让模型困惑。所以我的原则是命令名和流程描述用中文技术术语保留英文。2.3 十个命令的选型逻辑我没有一上来就堆二十个命令而是先观察自己一周的工作流把重复出现的操作记下来然后按频率排序。最后选出的这 10 个命令覆盖了四个大类类别命令解决的核心问题代码质量/审查/重构/测试减少人工 review 和补测试的时间版本管理/提交/分支/回滚规范 Git 操作避免手滑知识处理/解释/翻译快速理解陌生代码和文档环境维护/依赖/清理保持项目健康度选型的时候我遵循一个原则只封装那些“每次做都要想一下”的操作。如果一个操作我已经形成了肌肉记忆闭着眼睛都能敲对那就不需要封装成命令。命令的价值在于降低认知负荷而不是把所有操作都包一层。2.4 命令文件的目录结构和加载机制我的命令文件放在~/.claude/commands/下面按类别建了子目录~/.claude/commands/ ├── code/ │ ├── 审查.md │ ├── 重构.md │ └── 测试.md ├── git/ │ ├── 提交.md │ ├── 分支.md │ └── 回滚.md ├── docs/ │ ├── 解释.md │ └── 翻译.md └── env/ ├── 依赖.md └── 清理.md这里有个细节要注意Claude Code 加载自定义命令的时候子目录名会成为命令命名空间的一部分。也就是说code/审查.md对应的命令是/code:审查而不是/审查。如果你想要短命令名就得把文件直接放在commands/根目录下。我一开始为了命令短全放在根目录结果文件多了之后ls一屏都显示不完找起来很烦。后来改成子目录加命名空间虽然输入多几个字符但 Tab 补全的时候分类清晰反而不容易敲错。这个取舍看个人习惯没有绝对的对错。3. 核心命令的提示词拆解与实操要点3.1/审查命令让 AI 按你的标准做代码审查这个命令是我用得最频繁的平均每天触发 8 到 10 次。它的提示词结构是这样的你是一位有十年经验的 [语言] 工程师现在需要对一段代码做审查。 审查维度按优先级排列 1. 正确性逻辑是否有漏洞边界条件是否处理 2. 安全性是否有注入、越权、敏感信息泄露风险 3. 性能是否有明显的 N1 查询、不必要的循环、内存泄漏 4. 可维护性命名是否清晰函数是否过长耦合是否过重 5. 风格一致性是否符合项目现有代码风格 输出格式 - 按严重程度分三级阻断、建议、提示 - 每条问题必须给出具体行号和修改建议 - 如果某个维度没有问题明确说“未发现” - 最后给一个总体评价不超过三句话 不要做的事 - 不要重写整段代码只指出问题和改法 - 不要提“可以加注释”这种废话建议 - 不要假设代码的用途有疑问就标注出来这个提示词里最关键的是“不要做的事”那一段。我踩过的坑是早期版本没有这段结果 AI 每次审查完都要把整段代码重写一遍输出巨长我还得自己对比哪里改了。加上禁止重写之后输出精简了至少 60%而且每条建议都直接可操作。另一个经验是审查维度要按优先级排。如果不排优先级AI 会把“变量名不够好”和“这里有 SQL 注入”并列输出你扫一眼还以为是同等重要的问题。排了优先级之后阻断级问题永远在最前面不会漏掉。注意这个命令对语言敏感。如果你的项目里同时有 TypeScript 和 Python最好在命令参数里指定语言或者在提示词里写“根据文件扩展名自动判断语言”。我试过不指定结果 AI 用 TypeScript 的标准去审查 Python 代码闹了不少笑话。3.2/提交命令规范 Git 提交信息Git 提交信息这件事团队里每个人的写法都不一样。有人写“fix bug”有人写“修复了登录页面的一个问题”还有人写“update”。我封装这个命令的目的是让每次提交都自动符合 Conventional Commits 规范同时保留中文描述。提示词核心部分根据以下 git diff 内容生成一条符合规范的提交信息。 格式要求 type(scope): 中文描述 type 取值范围feat, fix, refactor, docs, test, chore, perf, style scope 用英文表示影响的模块 中文描述不超过 50 个字动词开头说清楚做了什么 如果 diff 涉及多个不相关的改动提醒我拆分提交。 如果 diff 里有删除文件的操作在描述里明确说明。这里有个实操技巧我让命令直接读取git diff --staged的输出而不是让我手动粘贴。实现方式是在命令文件里写!git diff --stagedClaude Code 会把命令执行结果注入到提示词里。这样我只需要git add之后输入/提交它就能自动生成提交信息。实测下来这个命令帮我避免了两类问题一是提交信息写得太随意回头看 git log 完全不知道当时改了什么二是把不相关的改动混在一个提交里。现在 AI 会主动提醒我“这次 diff 里同时有登录逻辑修改和 README 更新建议拆成两个提交”这种提醒在早期是完全没有的。3.3/测试命令按项目测试风格生成用例生成测试用例的命令难点在于让 AI 理解你项目的测试风格。有的项目用describe/it有的用test()有的用 pytest 的class TestXxx。如果命令里不指定AI 会按它自己的默认风格写生成出来的测试你还得手动改格式。我的做法是在命令提示词里加一段“风格探测”逻辑先读取项目中已有的测试文件优先找 *.test.ts 或 test_*.py 分析其使用的测试框架、断言风格、mock 方式、命名习惯。 然后按照同样的风格为指定的源文件生成测试用例。 覆盖要求 - 正常路径至少 2 个用例 - 边界条件至少 2 个用例 - 异常路径至少 1 个用例 - 如果函数有副作用必须 mock 掉外部依赖 不要生成“测试框架本身”的测试比如测试 expect 是否工作。这个“先探测再生成”的思路是我从 Codex CLI 的工作流里借鉴过来的。它比直接生成准确得多因为 AI 有了参照物不会凭空发明一套风格。提示如果你的项目测试文件很少探测不到足够样本可以在命令里硬编码风格。比如“本项目统一使用 vitest testing-library/react断言用 expect().toBe()”。硬编码虽然不够灵活但比让 AI 猜要可靠。3.4/解释命令用中文讲清楚陌生代码接手老项目或者看开源库源码的时候这个命令特别有用。它的提示词设计重点是“分层解释”用中文解释以下代码分三层 第一层一句话说清楚这段代码是干什么的不超过 30 字 第二层按执行顺序拆解主要步骤每步一句话 第三层指出这段代码依赖的外部假设比如“假设调用方已经做了鉴权” 如果代码里有不常见的写法或历史遗留的 hack单独标注出来并说明可能的原因。 如果代码有潜在问题在最后用“注意”开头列出。三层结构的好处是你可以根据当前需要选择看哪一层。赶时间就看第一层要改代码就看第二层要做架构评估就看第三层。我试过让 AI 只输出一段笼统的解释结果它总是把三层混在一起读起来很累。3.5/依赖命令检查依赖健康度这个命令解决的是“项目跑了一段时间之后依赖悄悄烂掉”的问题。提示词里我让它做四件事读取package.json或requirements.txt列出所有直接依赖检查每个依赖的版本是否落后于最新稳定版标记出已经不再维护的包比如超过两年没有更新检查是否有重复功能的依赖比如同时装了axios和node-fetch输出用表格呈现三列包名、当前版本、建议操作。建议操作只有三种升级、替换、保留。这样我扫一眼就知道该动哪些。实测发现这个命令最大的价值不是告诉我“有新版本”而是帮我发现“这个包已经没人维护了”。有次它标记出一个我用了三年的工具库最后一次更新是四年前issue 区全是未回复的 bug 报告。我顺着它的建议换了一个活跃维护的替代品省掉了后面可能踩的大坑。4. 完整实操从零搭建这套命令工作流4.1 环境准备与目录初始化先把基础环境确认一遍。Claude Code 的安装方式根据系统不同有差异macOS 和 Linux 下通常用 npm 全局安装Windows 下建议在 WSL 里操作原生 PowerShell 偶尔会有路径问题。安装完成后确认命令目录存在mkdir -p ~/.claude/commands/{code,git,docs,env}然后验证 Claude Code 能识别到自定义命令。启动claude输入/看补全列表里有没有你新建的目录。如果没有检查两点一是目录名是否拼写正确二是 Claude Code 版本是否支持自定义命令早期版本不支持需要更新。注意如果你在 Windows 上用 WSL~指向的是 WSL 的用户目录不是 Windows 的用户目录。别把命令文件放到/mnt/c/Users/xxx/下面那样 Claude Code 读不到。4.2 编写第一个命令文件以/审查为例完整文件内容如下--- description: 对指定代码进行多维度审查 --- 你是一位有十年经验的资深工程师现在需要对以下代码做审查。 审查维度按优先级排列 1. 正确性逻辑漏洞、边界条件、空值处理 2. 安全性注入风险、越权访问、敏感信息硬编码 3. 性能N1 查询、不必要的循环、内存泄漏 4. 可维护性命名清晰度、函数长度、模块耦合 5. 风格一致性是否符合项目现有风格 输出格式 - 按严重程度分三级阻断、建议、提示 - 每条问题给出具体行号和修改建议 - 无问题的维度明确写“未发现” - 总体评价不超过三句话 禁止事项 - 不要重写整段代码 - 不要提“加注释”这类无操作性建议 - 不要假设代码用途有疑问就标注 待审查代码 $ARGUMENTS文件头部的description是给命令列表用的会显示在补全提示里。$ARGUMENTS是占位符你输入命令时跟的参数会替换到这里。4.3 参数传递与动态内容注入Claude Code 的命令支持两种动态内容一种是$ARGUMENTS接收用户输入另一种是!command执行 shell 命令并把输出注入提示词。/提交命令就用了第二种根据以下 git diff 生成提交信息 !git diff --staged 格式要求 type(scope): 中文描述 ...这样你git add之后直接输入/提交不需要手动粘贴 diff。实测这个体验比复制粘贴流畅太多尤其是在改动文件多的时候。有个坑要注意!command里的命令是在你当前工作目录执行的所以如果你在项目根目录启动 Claude Codegit diff就能正常工作。但如果你在子目录启动可能会报“not a git repository”。解决办法是在命令里写!git -C $(git rev-parse --show-toplevel) diff --staged强制从仓库根目录执行。4.4 命令之间的组合调用单个命令用熟了之后我开始尝试组合。比如审查完代码之后直接生成测试再直接提交。Claude Code 支持在一个会话里连续调用多个命令上下文是共享的。我的典型流程是改完代码输入/审查看有没有阻断级问题如果有问题让 AI 给出修改方案我手动改改完再/审查一遍确认阻断级问题清零输入/测试生成对应测试用例跑测试通过后git add输入/提交这个流程走下来从改完代码到提交平均 5 到 8 分钟。以前手动做同样的事光是想提交信息、补测试用例就要 15 分钟以上。4.5 跨工具迁移Codex CLI 和 ZCode CLI 的适配这套命令思路不局限于 Claude Code。Codex CLI 的自定义命令机制类似也是 Markdown 文件加提示词模板只是目录位置不同通常在~/.codex/commands/。ZCode CLI 也支持类似的配置方式。迁移的时候主要改两个地方一是目录路径二是动态内容注入的语法。Claude Code 用!commandCodex CLI 可能用{{shell:command}}之类的写法。提示词本身基本可以原样搬过去因为核心逻辑是通用的。我实测过把/审查和/提交两个命令迁移到 Codex CLI改完语法之后效果一致。这说明命令层的设计是工具无关的你花时间打磨的提示词不会因为换工具就作废。5. 常见问题与排查技巧实录5.1 命令不生效的几种原因现象可能原因排查方法输入/看不到自定义命令目录路径不对确认文件在~/.claude/commands/下命令名带命名空间但补全不出来子目录名有特殊字符子目录名只用英文和数字命令执行了但输出为空提示词里$ARGUMENTS没传值检查是否在命令后跟了参数!command报错命令在当前目录不可执行用绝对路径或-C指定目录中文命令名乱码终端编码不是 UTF-8设置LANGzh_CN.UTF-85.2 提示词写得太长导致响应变慢我一开始追求“把所有情况都写进提示词”结果/审查的命令文件写到了 800 多字。实测发现提示词超过 500 字之后模型响应时间明显变长而且它开始抓不住重点输出质量反而下降。后来我做了减法把提示词控制在 300 到 400 字只保留最核心的规则。那些“偶尔才用到”的边界情况改成在对话里临时补充。这样命令响应快输出也更聚焦。提示判断提示词是否过长有个简单标准——如果你自己读一遍要超过 30 秒那就太长了。命令提示词应该是“扫一眼就知道要干什么”的密度。5.3 命令输出格式不稳定的处理AI 输出格式不稳定是常态。同一个/审查命令有时候输出表格有时候输出列表有时候还给你加个总结段落。我的应对策略是在提示词里用“必须”和“禁止”来约束“必须按三级分类输出”“禁止在最后加总结”“每条问题必须包含行号”用了这些强约束词之后格式稳定性从大概 70% 提升到 90% 以上。剩下 10% 的不稳定通常是模型版本更新导致的需要重新调提示词。5.4 上下文超长时的命令降级策略项目大了之后/审查一次性审查整个文件可能会超出上下文窗口。这时候需要降级只审查改动的部分而不是整个文件。我的做法是在命令里加一段判断逻辑如果待审查代码超过 500 行只审查最近修改的部分。 修改部分通过 git diff 获取不要审查未改动的代码。这样即使在大项目里命令也能正常工作不会因为上下文超长而失败。5.5 命令版本管理与团队共享命令文件多了之后版本管理就成了问题。我试过直接放在 dotfiles 仓库里但命令文件更新频繁每次都要提交很麻烦。后来改成用一个独立的 git 仓库管理~/.claude/commands/用软链接指过去。团队共享的话可以把命令仓库设为内部公开每个人 clone 之后建软链接。但要注意命令里可能包含个人偏好比如提交信息用中文还是英文共享之前要把这些个性化配置抽出来放到单独的配置文件里。6. 实测效果与个人体会这套命令工作流我用了大概三个月累计触发超过 2000 次。最直观的变化是以前我每天要在终端里输入大量重复的英文提示词现在大部分操作都是两三个中文字符搞定。省下来的时间不是重点重点是省下来的注意力——我不用再分心去想“这句话该怎么用英文表达”可以直接把精力放在代码本身。另一个意外收获是输出质量的稳定性。因为命令里固化了我的标准和偏好AI 的输出不会因为我当天状态好坏而波动。以前我状态好的时候能写出很精准的提示词状态差的时候就随便说两句结果 AI 也跟着敷衍。现在不管我状态如何命令触发的都是同一套高质量提示词。如果你打算开始搭自己的命令集我的建议是从一个命令开始就用你最频繁的那个操作。用一周感受一下哪里不顺手然后改提示词。改到你觉得“这个命令已经不需要再动了”再加第二个。不要一上来就搭十个那样你根本没精力逐个打磨最后每个都是半成品。最后分享一个我最近在试的扩展方向把命令和项目的CLAUDE.md联动。命令负责通用流程CLAUDE.md负责项目特定规则两者叠加之后AI 既知道“怎么做审查”也知道“这个项目的审查标准是什么”。这个组合目前看效果不错等再跑一段时间有更多数据了再单独写一篇。