1. 为什么我要给 Claude Code 装一套中文命令用 Claude Code 写代码有一段时间了最开始的新鲜感过去之后我发现自己每天在做的事情其实高度重复让它读一遍项目结构、跑一遍测试、解释一段看不懂的旧代码、把改动整理成提交信息、把一段需求拆成任务清单。这些动作本身不难但每次都要重新敲一遍提示词敲多了就烦而且不同时间敲的措辞还不一样输出质量忽高忽低。后来我干脆做了件事把这十来件高频动作全部封装成中文命令做成一个轻量的工作流包直接挂进 Claude Code 里。现在我在终端里敲/读项目、/跑测试、/解释、/提交这种中文指令它就能按我预设的流程干活。这篇文章就是把这套东西从头到尾拆开讲清楚——它是什么、为什么这么设计、每个命令怎么落地、踩过哪些坑以及你照着做能复现出什么效果。先说清楚适合谁看。如果你已经在用 Claude Code、Codex CLI 这类命令行 AI 编程工具但还停留在“每次手打提示词”的阶段这套东西能帮你把重复劳动压下去一大截。如果你还没上手也没关系我会把安装、目录结构、命令注册这些基础环节都讲一遍跟着做就行。核心关键词就几个Claude Code、AI 编程、CLI、工作流、中文命令。整套方案不依赖任何特定平台纯本地文件组织换台机器拷过去就能用。我把它叫“工作流包”而不是“插件”或者“框架”是因为它真的很轻——本质就是一堆 Markdown 文件加一个目录约定没有编译、没有依赖、没有服务进程。轻量级工作流的好处是你随时能改、随时能删不用担心把环境搞脏。下面我按“整体设计 → 命令细节 → 实操落地 → 问题排查”的顺序展开中间会穿插大量我实际用下来的参数选择和取舍理由。2. 整体设计与思路拆解2.1 为什么是“命令”而不是“提示词模板”很多人第一反应是我搞一个提示词模板文档不就行了为什么要做成命令我一开始也是这么想的试了两周就放弃了。原因很实际模板文档需要你复制、粘贴、再补上下文这个动作在终端里非常割裂。而 Claude Code 这类 CLI 工具天生支持斜杠命令slash command你敲/xxx它就直接把预设内容注入当前会话上下文是自动带上的不用你手动搬运。更关键的是命令可以带参数。比如/解释 某个函数名它就知道你只想解释这一块而不是整个文件。模板做不到这种“半自动”的粒度。所以我的设计原则第一条就是凡是每天要做三次以上的动作一律做成命令凡是需要现场指定对象的动作命令必须支持参数。2.2 目录结构怎么定一个约定胜过十份文档Claude Code 读取自定义命令的位置是有约定的通常放在项目根目录下的.claude/commands/里不同版本可能略有差异以你本地实际为准。每个命令就是一个.md文件文件名就是命令名。这个约定非常朴素但正是它让整套方案变得可移植——你把.claude目录整个拷到另一个项目命令立刻生效。我的目录长这样.claude/ commands/ 读项目.md 跑测试.md 解释.md 提交.md 拆任务.md 找bug.md 重构.md 写文档.md 审代码.md 收尾.md十个命令覆盖了我日常 90% 的操作。注意文件名直接用中文这是刻意的选择——中文命令名在终端里输入时配合输入法的联想其实比英文还快而且语义一目了然。我试过用英文缩写结果过两天自己都忘了rc是 read code 还是 run check中文就没这个问题。2.3 每个命令的内部结构三段式写法一个命令文件不是随便写句话就完事。我摸索出来的稳定结构是三段角色设定 执行步骤 输出约束。角色设定告诉它“你现在是谁”执行步骤告诉它“按什么顺序做”输出约束告诉它“别废话、按格式来”。举个反例。我最早写的/解释命令只有一句话“解释这段代码”。结果它有时候给我讲原理讲一大段有时候只回一句“这是一个函数”完全看心情。后来改成三段式输出立刻稳定了。这个经验很重要命令的质量不取决于你写得多热情而取决于你把约束定得多死。下面每个命令我都会把这三段拆给你看。2.4 为什么坚持全中文有人会问AI 编程工具用英文提示词不是效果更好吗我的实测结论是对于“理解代码、解释逻辑、拆解需求”这类任务中文提示词的效果和英文没有可感知的差距因为底层模型的中文能力已经足够强。但对于“生成代码”这类任务我会在命令里明确要求“代码本身用英文标识符注释和说明用中文”这样既保证了代码规范又让输出对我友好。全中文还有一个隐性好处团队协作时门槛低。我把这套命令包分享给组里几个刚入行的同事他们不用理解什么 prompt engineering看文件名就知道该敲哪个。这一点在真实工作场景里比“理论上更优”重要得多。3. 十个中文命令逐个拆解3.1 /读项目让 AI 先建立全局认知这个命令是我用得最频繁的几乎每个新项目第一件事就是敲它。它的作用是让 Claude Code 快速扫一遍项目结构输出一份“项目地图”用了什么语言、什么框架、入口文件在哪、核心模块有哪些、依赖管理方式是什么。命令内容大致是这样组织的先要求它列出顶层目录和关键配置文件比如package.json、pyproject.toml、go.mod这类再要求它识别出“入口”和“核心业务目录”最后要求它用不超过 300 字总结这个项目在干什么。为什么要限制字数因为不限制的话它会给你写一篇小作文反而抓不住重点。提示这个命令最好在会话最开始用让它先建立全局认知后面所有操作都会更准。我试过跳过这步直接让它改代码结果它经常改错文件。3.2 /跑测试把“跑测试”这件事标准化跑测试看起来简单其实坑很多有的项目用npm test有的用pytest有的要先启动服务。/跑测试命令的设计思路是先让它自己探测项目的测试方式读配置文件、看有没有Makefile、看scripts字段探测到了再执行执行完把失败用例单独拎出来解释。这里有个关键细节我会在命令里明确要求“如果测试全部通过只回一行结论如果有失败逐个分析失败原因并给出修复建议”。这个分支逻辑非常重要否则它每次都会把通过的用例也啰嗦一遍浪费你的阅读时间。3.3 /解释带参数的精准解释前面提过这个命令支持参数。用法是/解释 函数名或文件名。命令内部会先定位到目标再分三层解释这段代码做什么、为什么这么写、有什么潜在风险。第三层是我特意加的因为很多旧代码的写法背后有历史原因AI 如果能点出来能帮你避免“想当然地重构”。我踩过的一个坑是早期没加“定位”这一步直接让它解释结果它经常解释错对象尤其是同名函数分布在多个文件时。加上“先确认目标唯一不唯一就列出来让我选”这条约束后准确率大幅提升。3.4 /提交把改动整理成规范提交信息写提交信息是典型的“小事但烦人”。/提交命令会先读一遍当前的改动相当于git diff然后按约定式提交Conventional Commits的格式生成信息比如feat: 增加用户登录校验。我要求它同时给出“一句话摘要”和“详细说明”两版方便我按团队规范挑。这里有个实操心得一定要在命令里要求它“只描述改动不要评价改动好坏”。早期版本它总爱加一句“这个改动提升了代码质量”这种主观评价在提交历史里是噪音。3.5 /拆任务把模糊需求变成可执行清单这个命令解决的是“需求太模糊不知道从哪下手”的问题。用法是/拆任务 一段需求描述。它会输出一个任务清单每个任务包含做什么、涉及哪些文件、预估难度、依赖关系。我特别要求它标注“依赖关系”因为很多任务是有先后顺序的比如“先建数据模型再写接口”。不标依赖的话你按清单顺序做很容易卡住。这个命令我一般在动手写代码前用相当于让 AI 帮我做一次任务规划。3.6 /找bug结构化排查而不是瞎猜/找bug 报错信息或现象这个命令我要求它按固定流程走先复述问题、再列出可能原因按可能性排序、然后针对每个原因给出验证方法、最后给出最可能的修复方案。这个“先验证再修复”的顺序很关键能避免它上来就改代码结果改错地方。实测下来这个命令对“报错信息明确”的场景特别有效对“偶现的诡异问题”效果一般——那种还是得靠人。所以我在命令里加了一句“如果信息不足以定位明确告诉我还需要哪些信息”让它学会“承认不知道”而不是硬编一个答案。3.7 /重构带安全网的重构重构最怕的是改完跑不起来。/重构 目标命令的设计里我强制要求它“先说明重构目标和预期收益再给出改动方案改动后必须提示我跑测试”。这三步缺一不可。尤其是最后一步AI 很容易改完就完事忘了验证。我还会在命令里要求它“保持外部行为不变”这是重构的定义。如果不写这句它有时候会顺手把功能也改了那就不是重构而是重写了。3.8 /写文档从代码反推文档/写文档 模块名会读指定模块的代码生成一份说明文档包含模块职责、对外接口、使用示例、注意事项。我要求使用示例必须是“可直接复制运行”的不能是伪代码。这个要求逼着它把接口参数写清楚效果比泛泛而谈好很多。3.9 /审代码模拟一次代码评审/审代码会读当前改动按“正确性、可读性、性能、安全”四个维度给意见每个维度最多三条按严重程度排序。限制条数是为了防止它列一大堆鸡毛蒜皮的小事淹没真正重要的问题。3.10 /收尾会话结束前的清理动作这个命令比较特别它不处理具体代码而是做收尾总结这次会话改了什么、还有哪些没做完、下次可以从哪继续。我一般在一天工作结束时敲它相当于给自己留一份交接笔记。这个习惯坚持下来第二天开工时能省不少“回忆上下文”的时间。4. 实操落地从零把这套命令装起来4.1 环境准备与安装确认第一步是确认你的 Claude Code 已经能正常跑起来。在终端里敲claude看能不能进入交互界面。如果提示命令找不到说明还没装好需要先完成安装。安装方式各平台不同Windows 用户注意可能需要额外的终端环境支持Ubuntu 用户一般直接按官方说明走就行。装好之后进到你的项目根目录敲一次claude确认它能读到当前项目。这一步别跳过因为后面所有命令都依赖“在项目根目录启动”这个前提。我见过有人在家目录启动结果命令读不到项目文件排查半天。4.2 创建命令目录并写入第一个命令在项目根目录建目录mkdir -p .claude/commands然后创建第一个命令文件.claude/commands/读项目.md内容按三段式写# 角色 你是一名熟悉多语言项目的资深工程师。 # 步骤 1. 列出顶层目录和关键配置文件 2. 识别入口文件和核心业务目录 3. 用不超过 300 字总结项目用途 # 输出约束 - 不要逐文件罗列只讲结构和重点 - 不确定的地方明确标注“待确认”保存后重启 Claude Code敲/读项目看它是否按预期输出。如果没反应检查文件名和目录位置是否正确。4.3 参数化命令的写法带参数的命令在文件里用占位符表示。比如/解释.md# 角色 你是一名擅长讲解代码的工程师。 # 步骤 1. 定位参数指定的目标不唯一则列出让用户选择 2. 分三层解释做什么、为什么、潜在风险 # 输出约束 - 每层不超过 5 行 - 风险部分没有就写“无明显风险”调用时敲/解释 用户登录函数参数会自动带入。这里的关键是“不唯一则列出让用户选择”这条它把歧义处理交回给人避免 AI 自作主张。4.4 参数选择与阈值设定有些命令涉及数值参数比如/审代码里我限制“每个维度最多三条”。这个数字不是拍脑袋定的。我试过五条结果意见太杂试过一条又漏掉重要问题。三条是实测下来“既能覆盖主要问题又不啰嗦”的平衡点。类似的还有/读项目的 300 字上限也是反复调整出来的。注意这些阈值没有绝对标准你要根据自己的项目规模和阅读习惯调。小项目可以放宽大项目要收紧。4.5 一次完整的实操记录我拿一个真实的小项目走一遍。进目录敲/读项目它输出这是一个 Python 的 Flask 项目入口是app.py核心逻辑在services/目录依赖用requirements.txt管理。接着我敲/找bug 启动时报端口占用它列出三个可能原因第一个就是“上一次进程没退干净”验证方法是lsof -i:端口号我照着查果然如此。然后我改了点代码敲/提交它给出fix: 修复启动时端口占用未释放的问题。最后敲/收尾它总结今天改了两处、还有一个 TODO 没做。整个过程不到十分钟比我以前手打提示词快了一倍不止。5. 常见问题与排查技巧实录5.1 命令不生效怎么办最常见的原因是目录位置不对。命令目录必须在项目根目录下的.claude/commands/不是家目录也不是子目录。第二个原因是文件名带了多余后缀比如读项目.md.txt这种在 Windows 上特别容易发生因为系统默认隐藏扩展名。第三个原因是没重启会话改完命令文件后要重新进一次才生效。5.2 输出不稳定怎么调如果同一个命令每次输出差别很大八成是约束写得太松。回去检查你的“输出约束”段落把格式、字数、结构都写死。我的经验是约束越具体输出越稳定。比如“分三层解释”就比“详细解释”稳定得多。5.3 中文命令名输入麻烦有人担心中文命令名在终端里输入慢。实测下来配合输入法联想敲两个字母就能出候选比敲英文还快。如果你实在不习惯可以给命令起个英文别名两个文件指向同一套内容用哪个都行。5.4 常见问题速查表现象可能原因解决方式敲命令无反应目录位置错误确认在项目根目录的.claude/commands/命令名识别不到文件名后缀异常检查是否变成.md.txt输出每次不一样约束太宽松补全输出格式和字数限制参数没带进去占位符写法错误检查命令文件里的参数引用方式改了命令不生效会话未重启退出后重新进入5.5 几条独家避坑心得第一别一次装十个命令。我建议先装/读项目和/解释这两个最高频的用顺了再逐步加。一次全装上你记不住反而不用。第二命令要跟着项目走。不同项目的技术栈不一样/跑测试在 Python 项目和前端项目里内容肯定不同。所以这套命令包最好是每个项目一份而不是全局一份。第三定期清理。用了一个月后回头看有些命令你根本没敲过那就删掉。命令包不是越多越好是越精越好。第四把命令当代码管理。我后来把.claude目录也纳入了版本控制这样团队里谁改了命令、改了什么都有记录还能互相 review。这一步做了之后命令包的质量明显上了一个台阶。6. 后续可以怎么扩展这套工作流这套东西跑顺之后我做了几个扩展效果不错分享给你。第一个是按项目类型分目录比如前端项目一套命令、后端项目一套用软链接切换避免每次手动改。第二个是给命令加“前置检查”比如/提交之前先自动跑一次格式检查不通过就拦下来。第三个是把常用命令串成组合比如“读项目 → 拆任务 → 写代码 → 审代码 → 提交”这一整条链路我后来写了个简单的 shell 脚本把它们串起来敲一个命令走完全程。我个人在实际操作中的体会是AI 编程工具真正的效率提升不在于模型多强而在于你把多少重复动作固化成了流程。模型再聪明你每次都要重新描述需求那效率也上不去。反过来哪怕模型一般但你的流程足够顺整体产出也会很可观。这套中文命令包就是“固化流程”这件事的最小可行版本成本极低收益却很直接。最后再分享一个小技巧如果你团队里有人对 AI 编程还比较抵触别一上来就讲原理直接把/读项目和/提交这两个命令给他用。等他发现“原来可以这么省事”再慢慢展开讲整套工作流。接受度会高很多。