1. 为什么我要给 Claude Code 塞进 10 个中文命令用 Claude Code 写代码这件事最开始吸引我的点其实很朴素它能在终端里直接读项目、改文件、跑命令不用在编辑器和浏览器之间来回切。但真正用起来之后我很快发现一个尴尬的问题——每次开新会话我都要用英文把同一套上下文重新讲一遍。比如先读一下这个目录结构帮我按团队规范写 commit这个报错先别改代码先定位根因这些话说一次两次还行说十次就纯粹是浪费 token 和耐心。更麻烦的是Claude Code 默认的交互语言是英文思维。你让它review 一下这个 PR它会给你一份很标准的英文风格 review但你如果想让它按国内团队常见的习惯输出——比如先给结论、再列风险点、最后给修改建议并且用中文写清楚——你就得每次手动调教。这种重复劳动本质上和当年我们手动敲git status再看git diff一样是可以用工具消灭的。所以我干了一件事把 10 个高频中文命令固化进 Claude Code 的工作流里。这里的命令不是指 shell 脚本而是指 Claude Code 支持的自定义指令custom commands机制——你可以把它理解成给 AI 预设的快捷话术模板输入一个短指令它就自动展开成一段完整的、带上下文的中文任务描述。这 10 个命令覆盖了我日常最高频的场景项目初始化扫描、代码审查、commit 信息生成、报错根因定位、单元测试补全、重构建议、文档生成、依赖检查、性能排查、以及一个翻译官命令用来把英文报错转成中文解释。装完之后我的体感是同样一个任务输入量减少了大概 70%输出质量反而更稳定了因为每次触发的提示词结构是固定的不会因为我当天状态好坏而波动。这篇文章我会把这 10 个命令的设计思路、具体配置、踩过的坑以及怎么根据你自己的团队习惯做定制完整讲一遍。适合已经在用 Claude Code、或者刚装好还在摸索阶段的人。如果你还没装文里也会顺带说清楚安装和目录结构不影响阅读。2. Claude Code 的自定义命令到底是怎么工作的2.1 命令文件放在哪怎么被加载Claude Code 的自定义命令本质上就是放在特定目录下的 Markdown 文件。默认情况下项目级的命令放在项目根目录的.claude/commands/下用户级的命令放在~/.claude/commands/下。文件名就是命令名比如你建一个review.md那在会话里输入/review就能触发。这里有个很多人第一次会踩的坑命令名和文件名是强绑定的但斜杠后面的名字不包含.md。我一开始建了个code-review.md然后在会话里敲/code-review结果没反应后来才发现是目录放错了——我放到了.claude/command/少了个 s。Claude Code 对目录名是大小写和复数都敏感的commands必须是复数。加载时机也需要注意命令是在会话启动时扫描的。也就是说你在会话进行中新建了一个命令文件当前会话里是看不到的得退出重进。这个设计其实合理避免运行中动态加载带来的不确定性但第一次遇到会让人以为配置没生效。2.2 命令文件里写什么frontmatter 正文一个标准的命令文件长这样--- description: 对当前改动做中文代码审查 argument-hint: [文件路径或留空审查全部改动] --- 请对以下内容做代码审查要求 1. 先用一句话给出总体结论 2. 按严重程度列出问题每条包含位置、问题、建议 3. 最后给出一个如果只改一处改哪里的建议 审查范围$ARGUMENTS上半部分用---包起来的是 frontmatterdescription会显示在/help列表里argument-hint是给使用者看的参数提示。下半部分是正文也就是真正发给模型的提示词。$ARGUMENTS是一个占位符会被你在命令后面跟的参数替换掉。这个机制的关键价值在于它把提示词工程从一次性行为变成了可版本管理的资产。你可以把.claude/commands/提交到 git团队里每个人拉下来就有一套统一的话术。这比在群里发你们记得让 AI 先给结论啊靠谱一万倍。2.3 为什么用中文命令而不是英文有人可能会问Claude Code 原生对英文支持更好为什么非要中文我的实测结论是对于输出内容这件事中文提示词能显著提升中文输出的稳定性。如果你用英文提示词要求它respond in Chinese它有时候会在中间段落偷偷切回英文尤其是涉及技术术语的时候。但如果你整个提示词就是中文写的它保持中文的概率高很多。另一个原因是团队协作。我们团队里不是每个人英文都溜中文命令降低了使用门槛。一个刚入职的同学看到/审查这个命令他知道是干嘛的看到/code-review他可能还得反应一下。3. 这 10 个命令分别解决什么问题我把这 10 个命令按使用频率排了个序下面逐个说设计意图和实际效果。为了让你能直接抄我把每个命令的核心提示词结构都写出来了。3.1 项目扫描命令/扫描新接手一个项目最耗时的不是读代码而是建立心理地图。这个命令的作用是让 Claude Code 先帮你把项目结构、技术栈、入口文件、关键目录过一遍输出一份中文的项目导览。提示词核心结构是先让它列出顶层目录并标注用途再识别技术栈看 package.json、requirements.txt、go.mod 这些然后找出入口文件和核心模块最后给一个如果你想改 X 功能应该看哪几个文件的指引。实测下来这个命令对中型项目几百个文件效果最好能省掉我大概半小时的摸索时间。超大项目上万文件它会有点力不从心这时候我会加参数限定范围比如/扫描 src/。3.2 代码审查命令/审查这是我用得最多的一个。它的设计重点是强制结构化输出。默认的 AI review 很容易变成这里可以优化那里也可以优化的流水账没有优先级。我的提示词里明确要求先给总体结论通过/有条件通过/不通过再按严重程度分级列问题最后给一个最小修改建议。这里有个经验一定要让它区分必须改和建议改。我见过太多 review 把风格问题和逻辑 bug 混在一起导致真正重要的东西被淹没。我在提示词里加了这么一句如果一个问题不影响正确性和可维护性标记为建议不要和必须改的混在一起。3.3 Commit 信息生成/提交git diff看完之后写 commit message这件事本身不复杂但很烦。这个命令让它读当前 staged 的改动然后按约定式提交Conventional Commits格式生成中文 commit message。格式我固定成类型(范围): 描述类型限定在 feat/fix/refactor/docs/test/chore 这几个里。这样生成的 message 既能过 CI 检查人看着也清楚。注意这个命令只读 staged 的内容所以你得先git add。我一开始没注意它把工作区所有改动都算进去了生成的 message 和实际要提交的对不上。3.4 报错根因定位/定位这个命令是我最得意的设计。普通做法是直接把报错贴给 AI 问怎么修但这样它很容易直接给你一个补丁而那个补丁可能只是把症状盖住了。我的提示词明确要求先不要给修复方案先做根因分析。具体分三步第一步解释这个报错在说什么用人话第二步列出可能导致它的 3 到 5 个原因并按可能性排序第三步针对每个原因给出验证方法。只有你确认了原因之后再让它给修复方案。这个先诊断后开药的流程帮我避免了好几次改了这里坏了那里的情况。3.5 单元测试补全/补测试给它一个函数或一个文件它分析现有测试覆盖情况然后补上缺失的测试用例。提示词里我强调两点一是测试要能真正失败不能写那种永远通过的假测试二是边界条件优先空值、极值、异常输入。实测中我发现一个坑如果不加限制它会给每个函数都写一堆测试包括那些 trivial 的 getter/setter。所以我在提示词里加了跳过纯数据类和不含逻辑的转发函数。3.6 重构建议/重构针对一个文件或一个模块让它给出重构建议。重点是不要让它直接改代码而是先给方案。提示词要求它列出当前代码的坏味道、重构的目标、具体的重构步骤、以及每步的风险。这个命令的价值在于它经常能发现一些我习以为常但确实该改的地方。比如有一次它指出我一个 300 行的函数里混了三种职责我其实一直知道但被明确点出来之后才下决心拆。3.7 文档生成/文档给一个模块生成中文文档包括用途、对外接口、使用示例、注意事项。提示词里我要求它从代码里提取事实不要编造。如果某个参数的含义从代码里看不出来就标注需人工确认而不是瞎猜。3.8 依赖检查/依赖读依赖清单文件检查有没有明显的版本冲突、废弃包、或者已知有问题的版本。这个命令我一般在新项目初始化或者升级依赖前跑一次。3.9 性能排查/性能针对一段代码或一个接口分析潜在的性能问题。提示词要求它区分确定的性能问题和可能的性能问题前者要有明确的复杂度分析或 IO 次数统计后者要说明在什么条件下才会成为瓶颈。3.10 报错翻译/翻译把英文报错、英文文档片段翻译成中文并且保留技术术语的原文。这个命令看起来简单但很实用尤其是读一些老外的 issue 或者 stack trace 的时候。4. 安装与配置从零到能用的完整路径4.1 前置环境Claude Code 是 Node.js 生态的工具所以第一步是确认 Node 版本。我实测下来Node 18 以上比较稳16 也能跑但偶尔有奇怪的问题。检查命令node -v npm -v如果版本太低建议用 nvm 之类的版本管理工具切一下别直接动系统自带的 Node容易把系统工具搞坏。4.2 安装 Claude Code安装本身一条命令npm install -g anthropic-ai/claude-code这里有个国内用户常见的坑npm 全局安装的 prefix 目录可能没有写权限导致安装失败或者后续自动更新失败。报错信息通常是no write permission to npm prefix。解决办法是先查一下 prefix 在哪npm config get prefix如果这个目录需要 sudo 才能写要么改 prefix 到一个你有权限的目录要么用 sudo 装不推荐后续更新会一直要 sudo。我自己的做法是把 prefix 改到用户目录下npm config set prefix ~/.npm-global然后把~/.npm-global/bin加到 PATH 里。这样以后所有全局包都不需要 sudo干净。4.3 创建命令目录安装完之后在项目根目录建命令目录mkdir -p .claude/commands如果你想全局可用所有项目都能用就建在用户目录mkdir -p ~/.claude/commands我的建议是通用的命令放用户级项目特有的放项目级。比如/翻译这种放用户级/扫描如果每个项目扫描逻辑不一样就放项目级。4.4 验证命令是否生效建好目录、放进去一两个.md文件之后重启 Claude Code 会话输入/help你应该能在列表里看到你的命令。如果没看到按这个顺序排查现象可能原因排查方法/help里没有命令目录名写错确认是.claude/commands不是.claude/command命令列表里有但触发无反应frontmatter 格式错误检查---是否成对中间不能有语法错误触发后报参数错误$ARGUMENTS用法问题确认占位符拼写正确大小写敏感改了文件但没生效会话未重启退出当前会话重新进入5. 命令设计的几个关键原则5.1 输出结构要固定不要留给模型发挥这是我最深的一条体会。如果你不规定输出结构模型每次给你的格式都不一样你就没法快速扫读。我在每个命令的提示词里都会明确要求输出分几段、每段是什么。比如/审查固定三段结论、问题列表、最小修改建议。这样我一眼就能定位到我要看的部分。5.2 先诊断后开药避免补丁式修复前面/定位已经说过这个思路。推广开来任何涉及修 bug的命令都应该先要求分析再要求方案。因为模型有很强的讨好倾向你问它怎么修它就给你一个看起来能用的补丁哪怕根因在别处。强制它先分析能把这个倾向压下去。5.3 用中文写提示词但技术术语保留英文纯中文提示词有个副作用模型有时候会把一些约定俗成的英文术语也翻译成中文比如把commit翻成提交、把branch翻成分支读起来反而别扭。我的做法是在提示词里加一句技术术语保留英文原文如 commit、branch、merge、rebase 等。5.4 参数要少而精命令的参数不是越多越好。我一开始给/审查设计了五六个参数范围、严格程度、输出格式、是否包含建议……结果自己都记不住。后来砍到只剩一个审查范围。参数超过两个使用率就会断崖式下降这是我在多个工具上验证过的规律。6. 实测中踩过的坑和解决办法6.1 命令名冲突Claude Code 本身有一些内置命令比如/help、/clear之类。如果你自定义的命令名和内置的撞了行为不确定。我建议自定义命令统一加个前缀或者用中文名避开内置命令。我用中文名就是这个考虑/审查、/定位这些基本不可能和内置冲突。6.2 提示词太长导致响应变慢我有个命令一开始写了 800 多字的提示词结果每次触发都要等好久。后来发现提示词长度和响应时间基本成正比因为输入 token 多了。我的优化是把提示词压到 200 到 300 字只保留最关键的约束剩下的靠模型自己发挥。实测质量没有明显下降速度提升明显。6.3 模型忘记约束即使你在提示词里写了约束模型有时候还是会违反尤其是长对话之后。我的应对是在命令正文的最后再重复一次最重要的约束。比如/审查最后我会再写一句记住先给结论问题按严重程度排序。这个首尾呼应的写法实测能明显降低违反率。6.4 中文命令在某些终端下的输入问题这个坑比较隐蔽。有些终端对中文输入法的支持不好输入/审查的时候可能触发不了补全。我的解决办法是给中文命令配一个英文别名比如/审查同时建一个review.md两个文件内容一样。这样中文终端用中文英文终端用英文都能用。7. 怎么把这套东西改成适合你自己的7.1 从最高频的场景开始不要一上来就设计 20 个命令。先观察自己一周记录下你最常让 AI 做的三件事把这三件事做成命令。用顺了再扩展。我最初只有三个命令/审查、/提交、/定位用了两周才加到 10 个。7.2 把团队规范写进提示词命令最大的价值是固化团队共识。比如你们团队要求所有函数必须有中文注释那就把这条写进/审查的提示词里。这样每次 review 都会检查这一条比在文档里写一百遍都管用。7.3 定期回顾和迭代命令不是建完就不管了。我每个月会看一遍自己的命令把用不上的删掉把经常需要手动补充的约束加进去。命令库应该像代码一样持续维护而不是一次性配置。7.4 版本管理把.claude/commands/提交到 git这样团队共享、历史可追溯。如果有些命令包含敏感信息比如内部系统地址就放用户级目录不要提交。8. 一些关于 AI 编程工作流的个人看法用了几个月下来我最大的感受是AI 编程工具的价值不在于它能替你写多少代码而在于它能不能把你的重复劳动固化下来。Claude Code 本身很强但如果你每次都从零开始和它对话你其实是在重复消耗自己的注意力。自定义命令这个机制本质上是把你的经验沉淀成可复用的资产。另一个体会是中文命令这件事比我想象的重要。语言不只是沟通工具它还影响思维方式。用中文描述任务的时候我会更自然地想到先给结论分优先级这些符合中文表达习惯的结构用英文的时候我更容易陷入描述清楚就行的惯性。这可能是个体差异但对我确实成立。最后说一个实际的小技巧如果你不确定一个命令该怎么设计先手动和 AI 对话几次把效果好的那几次的提示词复制出来整理成命令文件。这比凭空设计靠谱得多因为它是从真实需求里长出来的。这套 10 个命令我用了大概三个月中间迭代了四五轮。现在我的日常流程基本是/扫描建立上下文干活/审查自查/提交生成 message遇到报错/定位。整个链路下来我在和 AI 沟通这件事上花的时间比最开始少了大概三分之二。省下来的时间用来想真正的问题。 
长河君 · 2026/10/9 8:44:26 · 阅读 1.2k Claude Code 中文自定义命令实战：10 个高频命令提升 AI 编程效率
1. 为什么我要给 Claude Code 塞进 10 个中文命令用 Claude Code 写代码这件事最开始吸引我的点其实很朴素它能在终端里直接读项目、改文件、跑命令不用在编辑器和浏览器之间来回切。但真正用起来之后我很快发现一个尴尬的问题——每次开新会话我都要用英文把同一套上下文重新讲一遍。比如先读一下这个目录结构帮我按团队规范写 commit这个报错先别改代码先定位根因这些话说一次两次还行说十次就纯粹是浪费 token 和耐心。更麻烦的是Claude Code 默认的交互语言是英文思维。你让它review 一下这个 PR它会给你一份很标准的英文风格 review但你如果想让它按国内团队常见的习惯输出——比如先给结论、再列风险点、最后给修改建议并且用中文写清楚——你就得每次手动调教。这种重复劳动本质上和当年我们手动敲git status再看git diff一样是可以用工具消灭的。所以我干了一件事把 10 个高频中文命令固化进 Claude Code 的工作流里。这里的命令不是指 shell 脚本而是指 Claude Code 支持的自定义指令custom commands机制——你可以把它理解成给 AI 预设的快捷话术模板输入一个短指令它就自动展开成一段完整的、带上下文的中文任务描述。这 10 个命令覆盖了我日常最高频的场景项目初始化扫描、代码审查、commit 信息生成、报错根因定位、单元测试补全、重构建议、文档生成、依赖检查、性能排查、以及一个翻译官命令用来把英文报错转成中文解释。装完之后我的体感是同样一个任务输入量减少了大概 70%输出质量反而更稳定了因为每次触发的提示词结构是固定的不会因为我当天状态好坏而波动。这篇文章我会把这 10 个命令的设计思路、具体配置、踩过的坑以及怎么根据你自己的团队习惯做定制完整讲一遍。适合已经在用 Claude Code、或者刚装好还在摸索阶段的人。如果你还没装文里也会顺带说清楚安装和目录结构不影响阅读。2. Claude Code 的自定义命令到底是怎么工作的2.1 命令文件放在哪怎么被加载Claude Code 的自定义命令本质上就是放在特定目录下的 Markdown 文件。默认情况下项目级的命令放在项目根目录的.claude/commands/下用户级的命令放在~/.claude/commands/下。文件名就是命令名比如你建一个review.md那在会话里输入/review就能触发。这里有个很多人第一次会踩的坑命令名和文件名是强绑定的但斜杠后面的名字不包含.md。我一开始建了个code-review.md然后在会话里敲/code-review结果没反应后来才发现是目录放错了——我放到了.claude/command/少了个 s。Claude Code 对目录名是大小写和复数都敏感的commands必须是复数。加载时机也需要注意命令是在会话启动时扫描的。也就是说你在会话进行中新建了一个命令文件当前会话里是看不到的得退出重进。这个设计其实合理避免运行中动态加载带来的不确定性但第一次遇到会让人以为配置没生效。2.2 命令文件里写什么frontmatter 正文一个标准的命令文件长这样--- description: 对当前改动做中文代码审查 argument-hint: [文件路径或留空审查全部改动] --- 请对以下内容做代码审查要求 1. 先用一句话给出总体结论 2. 按严重程度列出问题每条包含位置、问题、建议 3. 最后给出一个如果只改一处改哪里的建议 审查范围$ARGUMENTS上半部分用---包起来的是 frontmatterdescription会显示在/help列表里argument-hint是给使用者看的参数提示。下半部分是正文也就是真正发给模型的提示词。$ARGUMENTS是一个占位符会被你在命令后面跟的参数替换掉。这个机制的关键价值在于它把提示词工程从一次性行为变成了可版本管理的资产。你可以把.claude/commands/提交到 git团队里每个人拉下来就有一套统一的话术。这比在群里发你们记得让 AI 先给结论啊靠谱一万倍。2.3 为什么用中文命令而不是英文有人可能会问Claude Code 原生对英文支持更好为什么非要中文我的实测结论是对于输出内容这件事中文提示词能显著提升中文输出的稳定性。如果你用英文提示词要求它respond in Chinese它有时候会在中间段落偷偷切回英文尤其是涉及技术术语的时候。但如果你整个提示词就是中文写的它保持中文的概率高很多。另一个原因是团队协作。我们团队里不是每个人英文都溜中文命令降低了使用门槛。一个刚入职的同学看到/审查这个命令他知道是干嘛的看到/code-review他可能还得反应一下。3. 这 10 个命令分别解决什么问题我把这 10 个命令按使用频率排了个序下面逐个说设计意图和实际效果。为了让你能直接抄我把每个命令的核心提示词结构都写出来了。3.1 项目扫描命令/扫描新接手一个项目最耗时的不是读代码而是建立心理地图。这个命令的作用是让 Claude Code 先帮你把项目结构、技术栈、入口文件、关键目录过一遍输出一份中文的项目导览。提示词核心结构是先让它列出顶层目录并标注用途再识别技术栈看 package.json、requirements.txt、go.mod 这些然后找出入口文件和核心模块最后给一个如果你想改 X 功能应该看哪几个文件的指引。实测下来这个命令对中型项目几百个文件效果最好能省掉我大概半小时的摸索时间。超大项目上万文件它会有点力不从心这时候我会加参数限定范围比如/扫描 src/。3.2 代码审查命令/审查这是我用得最多的一个。它的设计重点是强制结构化输出。默认的 AI review 很容易变成这里可以优化那里也可以优化的流水账没有优先级。我的提示词里明确要求先给总体结论通过/有条件通过/不通过再按严重程度分级列问题最后给一个最小修改建议。这里有个经验一定要让它区分必须改和建议改。我见过太多 review 把风格问题和逻辑 bug 混在一起导致真正重要的东西被淹没。我在提示词里加了这么一句如果一个问题不影响正确性和可维护性标记为建议不要和必须改的混在一起。3.3 Commit 信息生成/提交git diff看完之后写 commit message这件事本身不复杂但很烦。这个命令让它读当前 staged 的改动然后按约定式提交Conventional Commits格式生成中文 commit message。格式我固定成类型(范围): 描述类型限定在 feat/fix/refactor/docs/test/chore 这几个里。这样生成的 message 既能过 CI 检查人看着也清楚。注意这个命令只读 staged 的内容所以你得先git add。我一开始没注意它把工作区所有改动都算进去了生成的 message 和实际要提交的对不上。3.4 报错根因定位/定位这个命令是我最得意的设计。普通做法是直接把报错贴给 AI 问怎么修但这样它很容易直接给你一个补丁而那个补丁可能只是把症状盖住了。我的提示词明确要求先不要给修复方案先做根因分析。具体分三步第一步解释这个报错在说什么用人话第二步列出可能导致它的 3 到 5 个原因并按可能性排序第三步针对每个原因给出验证方法。只有你确认了原因之后再让它给修复方案。这个先诊断后开药的流程帮我避免了好几次改了这里坏了那里的情况。3.5 单元测试补全/补测试给它一个函数或一个文件它分析现有测试覆盖情况然后补上缺失的测试用例。提示词里我强调两点一是测试要能真正失败不能写那种永远通过的假测试二是边界条件优先空值、极值、异常输入。实测中我发现一个坑如果不加限制它会给每个函数都写一堆测试包括那些 trivial 的 getter/setter。所以我在提示词里加了跳过纯数据类和不含逻辑的转发函数。3.6 重构建议/重构针对一个文件或一个模块让它给出重构建议。重点是不要让它直接改代码而是先给方案。提示词要求它列出当前代码的坏味道、重构的目标、具体的重构步骤、以及每步的风险。这个命令的价值在于它经常能发现一些我习以为常但确实该改的地方。比如有一次它指出我一个 300 行的函数里混了三种职责我其实一直知道但被明确点出来之后才下决心拆。3.7 文档生成/文档给一个模块生成中文文档包括用途、对外接口、使用示例、注意事项。提示词里我要求它从代码里提取事实不要编造。如果某个参数的含义从代码里看不出来就标注需人工确认而不是瞎猜。3.8 依赖检查/依赖读依赖清单文件检查有没有明显的版本冲突、废弃包、或者已知有问题的版本。这个命令我一般在新项目初始化或者升级依赖前跑一次。3.9 性能排查/性能针对一段代码或一个接口分析潜在的性能问题。提示词要求它区分确定的性能问题和可能的性能问题前者要有明确的复杂度分析或 IO 次数统计后者要说明在什么条件下才会成为瓶颈。3.10 报错翻译/翻译把英文报错、英文文档片段翻译成中文并且保留技术术语的原文。这个命令看起来简单但很实用尤其是读一些老外的 issue 或者 stack trace 的时候。4. 安装与配置从零到能用的完整路径4.1 前置环境Claude Code 是 Node.js 生态的工具所以第一步是确认 Node 版本。我实测下来Node 18 以上比较稳16 也能跑但偶尔有奇怪的问题。检查命令node -v npm -v如果版本太低建议用 nvm 之类的版本管理工具切一下别直接动系统自带的 Node容易把系统工具搞坏。4.2 安装 Claude Code安装本身一条命令npm install -g anthropic-ai/claude-code这里有个国内用户常见的坑npm 全局安装的 prefix 目录可能没有写权限导致安装失败或者后续自动更新失败。报错信息通常是no write permission to npm prefix。解决办法是先查一下 prefix 在哪npm config get prefix如果这个目录需要 sudo 才能写要么改 prefix 到一个你有权限的目录要么用 sudo 装不推荐后续更新会一直要 sudo。我自己的做法是把 prefix 改到用户目录下npm config set prefix ~/.npm-global然后把~/.npm-global/bin加到 PATH 里。这样以后所有全局包都不需要 sudo干净。4.3 创建命令目录安装完之后在项目根目录建命令目录mkdir -p .claude/commands如果你想全局可用所有项目都能用就建在用户目录mkdir -p ~/.claude/commands我的建议是通用的命令放用户级项目特有的放项目级。比如/翻译这种放用户级/扫描如果每个项目扫描逻辑不一样就放项目级。4.4 验证命令是否生效建好目录、放进去一两个.md文件之后重启 Claude Code 会话输入/help你应该能在列表里看到你的命令。如果没看到按这个顺序排查现象可能原因排查方法/help里没有命令目录名写错确认是.claude/commands不是.claude/command命令列表里有但触发无反应frontmatter 格式错误检查---是否成对中间不能有语法错误触发后报参数错误$ARGUMENTS用法问题确认占位符拼写正确大小写敏感改了文件但没生效会话未重启退出当前会话重新进入5. 命令设计的几个关键原则5.1 输出结构要固定不要留给模型发挥这是我最深的一条体会。如果你不规定输出结构模型每次给你的格式都不一样你就没法快速扫读。我在每个命令的提示词里都会明确要求输出分几段、每段是什么。比如/审查固定三段结论、问题列表、最小修改建议。这样我一眼就能定位到我要看的部分。5.2 先诊断后开药避免补丁式修复前面/定位已经说过这个思路。推广开来任何涉及修 bug的命令都应该先要求分析再要求方案。因为模型有很强的讨好倾向你问它怎么修它就给你一个看起来能用的补丁哪怕根因在别处。强制它先分析能把这个倾向压下去。5.3 用中文写提示词但技术术语保留英文纯中文提示词有个副作用模型有时候会把一些约定俗成的英文术语也翻译成中文比如把commit翻成提交、把branch翻成分支读起来反而别扭。我的做法是在提示词里加一句技术术语保留英文原文如 commit、branch、merge、rebase 等。5.4 参数要少而精命令的参数不是越多越好。我一开始给/审查设计了五六个参数范围、严格程度、输出格式、是否包含建议……结果自己都记不住。后来砍到只剩一个审查范围。参数超过两个使用率就会断崖式下降这是我在多个工具上验证过的规律。6. 实测中踩过的坑和解决办法6.1 命令名冲突Claude Code 本身有一些内置命令比如/help、/clear之类。如果你自定义的命令名和内置的撞了行为不确定。我建议自定义命令统一加个前缀或者用中文名避开内置命令。我用中文名就是这个考虑/审查、/定位这些基本不可能和内置冲突。6.2 提示词太长导致响应变慢我有个命令一开始写了 800 多字的提示词结果每次触发都要等好久。后来发现提示词长度和响应时间基本成正比因为输入 token 多了。我的优化是把提示词压到 200 到 300 字只保留最关键的约束剩下的靠模型自己发挥。实测质量没有明显下降速度提升明显。6.3 模型忘记约束即使你在提示词里写了约束模型有时候还是会违反尤其是长对话之后。我的应对是在命令正文的最后再重复一次最重要的约束。比如/审查最后我会再写一句记住先给结论问题按严重程度排序。这个首尾呼应的写法实测能明显降低违反率。6.4 中文命令在某些终端下的输入问题这个坑比较隐蔽。有些终端对中文输入法的支持不好输入/审查的时候可能触发不了补全。我的解决办法是给中文命令配一个英文别名比如/审查同时建一个review.md两个文件内容一样。这样中文终端用中文英文终端用英文都能用。7. 怎么把这套东西改成适合你自己的7.1 从最高频的场景开始不要一上来就设计 20 个命令。先观察自己一周记录下你最常让 AI 做的三件事把这三件事做成命令。用顺了再扩展。我最初只有三个命令/审查、/提交、/定位用了两周才加到 10 个。7.2 把团队规范写进提示词命令最大的价值是固化团队共识。比如你们团队要求所有函数必须有中文注释那就把这条写进/审查的提示词里。这样每次 review 都会检查这一条比在文档里写一百遍都管用。7.3 定期回顾和迭代命令不是建完就不管了。我每个月会看一遍自己的命令把用不上的删掉把经常需要手动补充的约束加进去。命令库应该像代码一样持续维护而不是一次性配置。7.4 版本管理把.claude/commands/提交到 git这样团队共享、历史可追溯。如果有些命令包含敏感信息比如内部系统地址就放用户级目录不要提交。8. 一些关于 AI 编程工作流的个人看法用了几个月下来我最大的感受是AI 编程工具的价值不在于它能替你写多少代码而在于它能不能把你的重复劳动固化下来。Claude Code 本身很强但如果你每次都从零开始和它对话你其实是在重复消耗自己的注意力。自定义命令这个机制本质上是把你的经验沉淀成可复用的资产。另一个体会是中文命令这件事比我想象的重要。语言不只是沟通工具它还影响思维方式。用中文描述任务的时候我会更自然地想到先给结论分优先级这些符合中文表达习惯的结构用英文的时候我更容易陷入描述清楚就行的惯性。这可能是个体差异但对我确实成立。最后说一个实际的小技巧如果你不确定一个命令该怎么设计先手动和 AI 对话几次把效果好的那几次的提示词复制出来整理成命令文件。这比凭空设计靠谱得多因为它是从真实需求里长出来的。这套 10 个命令我用了大概三个月中间迭代了四五轮。现在我的日常流程基本是/扫描建立上下文干活/审查自查/提交生成 message遇到报错/定位。整个链路下来我在和 AI 沟通这件事上花的时间比最开始少了大概三分之二。省下来的时间用来想真正的问题。