刚把 Claude Code 装好的头一个月我几乎把所有精力都花在了“怎么跟 AI 解释我要干什么”上。每天最常做的事就是反复敲同一句话“帮我看看这段代码有没有问题”、“这个报错是什么原因”、“给这次改动写个提交信息”。次数多了我就开始琢磨明明每天都用同样的工作流为什么每次都要重新打一遍于是我用了一个晚上把 10 个高频需求做成了中文 slash 命令塞进了~/.claude/commands/目录。现在干活基本就是输入命令名、丢一个参数、回车完事。这篇文章就写给所有想让 Claude Code 真正变成“工作流工具”而不是“聊天窗口”的人。我会把这 10 个命令的完整设计思路、配置文件源码、真实使用场景以及我踩过的坑全部公开。看完你不需要照抄我的答案但一定能学会怎么给自己打造一套中文命令包。1. 为什么要做一套中文命令包1.1 重复输入是 AI 编程里最大的隐性成本很多人在聊 AI 编程时都盯着模型能力其实真正影响效率的是交互成本。Claude Code 这类命令行工具已经把 AI 编程变成了一个高度可交互的过程可以读文件、执行命令、改代码但你依然需要每次都告诉它“你现在是什么角色帮我做什么事重点关注哪些点”。这些前置条件不是一两句话能说清的。比如“代码审查”如果你只丢一句“看看这段代码”它大概率会给出很泛泛的反馈什么“代码风格总体良好”之类完全达不到你要的效果。但如果你把审查标准、输出格式、关注重点全部写在命令模板里结果马上就不一样。中文命令包解决的问题就是把那些每天重复说的高质量 prompt 存成文件用一句话甚至一个词触发。本质上相当于给 AI 编程工具做了宏定义把你经验中沉淀出来的最佳实践固化下来。1.2 为什么一定要用中文有人会问slash 命令名用英文不也一样吗我的实际体会是中文命令名有两个不可替代的好处。第一是记忆成本低。/审查代码和/review-code哪个一眼就知道是干什么的显然中文对母语者更直观尤其当你有几十个自定义命令的时候英文命令名很容易混淆。第二是参数语义更清晰。我的命令都支持参数比如/审查代码 登录模块中文参数和中文命令名连在一起读语义非常自然不需要额外的转换脑回路。这里也要说一下Claude Code 对不同环境的支持略有差异如果你在某个终端里发现中文文件名创建的命令无法触发可以直接新建一个拼音命名的副本比如/shencha内部 prompt 依然是中文不影响使用效果。1.3 这套方案适合谁如果你符合下面任何一条这套方案就值得你花一晚上搭起来每天都在用 Claude Code 写代码、查代码但每次对话还要重复描述需求经常觉得自己给 AI 的 prompt 不够稳定这次效果好下次效果差接手过陌生项目想让 AI 帮你快速理解代码库但不知道该从何问起希望沉淀一套团队的 AI 协作规范而不是每次都由着个人自由发挥我做的 10 个命令覆盖了代码审查、重构、报错排查、测试编写、提交信息、任务拆分、项目盘点、代码讲解、文档生成和每日总结基本把日常开发的完整闭环都包进去了。2. 动手前的准备工作2.1 确认 Claude Code 环境正常先检查你的环境是不是装好了。我用的安装方式很简单npm install -g anthropic-ai/claude-code装完之后跑一下版本号确认一切正常claude --version这套命令包本质上依赖 Claude Code 的自定义 slash 命令功能所以需要确保你的版本支持该特性。如果你还在用很老的版本建议先升级。一个合理的判断方式就是在 Claude Code 对话框里输一个/看能不能弹出命令提示列表。2.2 命令文件存放在哪里Claude Code 的命令分两个层级这个一定要搞清楚否则你会出现“明明配了命令却找不到”的情况存储位置路径生效范围全局命令~/.claude/commands/对所有项目生效保留个人习惯用这个项目命令.claude/commands/项目根目录只对当前项目生效适合团队共享我个人的习惯是把通用性强的命令放全局目录比如“代码审查”、“报错分析”这些到了任何项目都能用。跟特定项目绑定的命令比如“生成这个项目的架构说明”就放项目目录下不污染全局。如果你跟团队协作项目目录下的.claude/commands/是可以提交到 Git 仓库里的。这样每个成员 clone 下来自动就有同一套命令AI 编程风格瞬间统一。2.3 命令文件的结构和语法每个 slash 命令其实就是一个带 YAML frontmatter 的 Markdown 文件。文件名决定命令名比如审查代码.md对应的触发命令就是/审查代码。frontmatter 是命令的元信息区域有三个字段比较重要--- description: 命令说明列表里展示用 argument-hint: 参数提示告诉用户要传入什么 allowed-tools: 允许使用的工具集合 ---描述和参数提示是给用户看的allowed-tools 则是限制 AI 在这个命令里能调用哪些工具这个很实用。比如“解释代码”这个命令只需要读文件和搜索代码完全可以禁用编辑权限防止 AI 手滑改掉不该改的东西。frontmatter 下面的正文就是你给 AI 的完整系统指令。注意一点Claude Code 的命令正文支持变量替换$1代表第一个参数$2代表第二个参数$ARGUMENTS代表所有参数。我大部分命令都只用一个参数直接用$1。2.4 快速建出第一个命令光说不练没意思先写一个最实用的“解释代码”命令。在~/.claude/commands/下新建文件解释代码.md--- description: 用通俗的语言逐步解释指定代码 argument-hint: 文件路径或函数名 allowed-tools: Read, Grep --- 你是一位擅长把复杂技术讲清楚的高级工程师。请解释 $1 这段代码。 要求 1. 先概括这段代码的整体职责用一句话说明白 2. 按执行顺序拆解核心逻辑重点解释关键算法和设计思路 3. 遇到难点用生活化类比展开不要堆术语 4. 指出这段代码里可能存在的隐患或改进空间 5. 最终输出“一句话总结” 目标读者是有两年经验的开发者避免过于基础的解释也不要故作高深。保存之后在任意项目里进入 Claude Code输入/解释代码 src/utils/date.ts它就会自动读取命令模板和文件内容给出结构化的代码讲解。3. 十个命令的完整拆解3.1 代码质量类审查、排查、测试第一个重头戏是审查代码.md。这个命令我设置得比较严格因为日常开发中最怕的就是 AI 审查流于表面、只会夸代码写得好。--- description: 对指定范围执行严格代码审查 argument-hint: 文件路径 / Git 改动范围 allowed-tools: Bash, Read, Grep, Edit --- 你是一位具有十年一线研发经验的代码审查专家风格犀利但不刻薄。请审查 $1。 按以下维度逐项检查 - 正确性逻辑边界、空指针、并发问题、异常路径是否处理完整 - 安全性是否存在注入风险、敏感信息泄露、数据校验缺失 - 性能有无不必要的重复计算、全表扫描、大对象常驻内存等问题 - 可维护性命名是否清晰、函数是否过长、模块耦合是否过高 输出格式严格如下 ## 问题列表 每个问题包含严重级别P0/P1/P2、文件与行号、问题描述、修复建议 ## 做得好的地方 简要列出亮点控制在三条以内 ## 修复优先级 给出一个建议的上手顺序 如果问题列表为空也要明确说明“本次审查未发现明显问题”不要硬凑。这个命令的精髓在于最后一句话——“不要硬凑”因为 AI 在没有人要求时往往会出于“表达欲”编造一些不痛不痒的建议。加了这句之后整个审查节奏清爽了很多。第二个命令排查报错.md是解决日常开发里最崩溃的场景——被报错信息卡住。我把排查思路直接固化进命令里--- description: 分析报错信息并定位根因 argument-hint: 报错信息或文件路径 allowed-tools: Bash, Read, Grep --- 你现在是一名背靠完整代码库的调试专家。用户遇到了问题请按以下流程排查 $1 1. 复现先根据上下文复现问题的触发条件 2. 定位找到报错对应的代码位置分析调用链 3. 归因区分是逻辑错误、边界条件、依赖问题还是环境问题 4. 验证给出验证方案包括临时日志、断点或最小复现代码 5. 修复给出具体的修改建议做到可直接落地的程度 输出要求 - 必须基于代码库中的真实文件禁止猜测 - 如果信息不足明确列出还需要补充什么信息 - 最后输出“根因判断”和“最可能的修复路径”第三个编写测试.md是我后加的但用过几次后发现频率极高尤其是在改老代码的时候有测试兜底心里踏实很多。--- description: 为指定函数或模块生成单元测试 argument-hint: 文件路径或函数名 allowed-tools: Bash, Read, Grep, Edit --- 你是一位测试驱动开发的坚定践行者。请为 $1 编写测试。 要求 1. 先分析被测代码的输入输出和外部依赖 2. 列出测试用例设计表覆盖正常路径、边界值、异常输入、依赖失败场景 3. 按表逐一实现测试代码使用项目现有的测试框架和命名规范 4. 优先Mock外部依赖保证测试的稳定性和独立性 5. 最后运行相关测试并汇报结果 注意不要为了覆盖率而编写无意义的测试每个用例必须能捕获一类真实缺陷。3.2 生产提效类重构、提交写代码很容易写“让 AI 帮你重构代码”的提示词很难。因为重构的核心要求是“行为不变”一旦 AI 自由发挥就可能顺手改坏逻辑。所以我的重构代码.md命令把约束写得很死--- description: 在保持行为不变的前提下重构代码 argument-hint: 文件路径或重构目标 allowed-tools: Bash, Read, Grep, Edit --- 你是一位资深重构专家。请对 $1 执行重构。 硬性约束 1. 保持对外接口、返回格式、异常行为完全不变 2. 每步重构都必须保持代码可运行禁止一次性大改 3. 重构前后必须说明改动点和技术理由 推荐方向 - 消除重复代码提取公共函数 - 降低函数复杂度拆解过长的逻辑块 - 优化命名让意图显式化 - 调整数据结构减少不必要的嵌套 输出要求 先输出重构计划表格再逐步执行修改。每完成一步运行一次相关命令或测试验证。 如果重构涉及多个文件要同步更新所有调用方。说到生成提交.md这个命令我能吹一句它直接治好我的提交信息拖延症。Git 提交信息虽然机械但写得不好整个提交历史就是一坨浆糊。--- description: 基于当前 Git 改动生成 commit message argument-hint: [可选] 提交类型如 feat / fix / refactor allowed-tools: Bash, Read, Grep --- 你是一位擅长编写高质量 Git 提交信息的工程师。请执行以下步骤 1. 运行 git status 查看当前改动范围 2. 运行 git diff --stat 了解改动规模 3. 运行 git diff 读取具体改动内容需要时读取文件上下文 基于以上信息生成 5 条候选提交信息 - 每条遵循 Conventional Commits 规范type(scope): subject - 第一条必须包含正文解释“为什么”做这个改动 - 禁止出现“update”、“fix bug”这类含糊描述 - scope 从实际模块名推导type 根据改动性质判断$1 可作为参考 最终直接输出推荐的那一条并附上 10 字以内的候选理由。3.3 工作流管理类拆分任务、每日总结拆分任务.md是我在处理复杂需求时的利器。很多开发者跟 AI 协作效率低就是因为把一个大需求直接丢给 AI导致它无所适从。命令先让它拆解需求再动手--- description: 将功能需求拆解为可执行的任务清单 argument-hint: 需求描述 allowed-tools: Read, Grep --- 你是一位善于结构化思维的项目经理。请将 $1 拆解为可执行任务清单。 拆解原则 1. 从用户价值和交付路径两个维度出发 2. 每项任务必须满足有明确目标、有验收标准、可独立交付 3. 识别任务之间的依赖关系标出关键路径 4. 优先拆出最小可行闭环再做增量迭代 输出格式 - 需求理解一句话复述需求确认理解正确 - 任务总览表编号、任务名、预估复杂度、依赖项 - 执行顺序按依赖关系排序标出适合并行开发的部分 - 风险点需求中模糊或有歧义的地方列出需要澄清的问题每日总结.md是一个我很得意的小设计。它适合固定在每天下班前跑一次让 AI 基于 Git 历史和对话记录生成当日工作总结既是自己的日志也是同步给团队的素材。--- description: 总结当前项目的当日改动和后续计划 argument-hint: [可选] 记录的日期 allowed-tools: Bash, Read, Grep --- 你是一位细致的技术团队助手。请基于当前工作目录生成今日工作总结。 执行步骤 1. 查看 git log --since24 hours ago --prettyformat:%h %s 获取提交记录 2. 查看 git status 确认未提交的改动 3. 结合明显的项目文件变化还原今日工作全貌 输出格式 - 今日完成按功能模块分类列出附上相关 commit - 还未完成列出正在进行中的事项说明卡点 - 明日建议给出 3 条优先级最高的下一步动作 - 需要关注任何潜在风险或技术债务 语气客观不要吹捧也不要贬低只陈述事实。3.4 陌生代码库辅助类项目盘点、解释代码、学习计划我接手的很多项目都来自前人离开后的遗留代码。第一次打开项目时最大的难题就是“这个项目到底在干嘛”。项目盘点.md解决了这个问题--- description: 快速盘点一个项目的整体架构和模块职责 argument-hint: 项目路径 allowed-tools: Bash, Read, Grep --- 你是一位擅长理解陌生系统的资深架构师。请对 $1 执行系统盘点。 盘点流程 1. 先读取 README、package.json / requirements.txt / go.mod 等项目元文件 2. 梳理目录结构识别核心模块和支撑模块 3. 分析主要数据流向请求从入口到存储层经过了哪些环节 4. 统计平均文件行数、核心文件目录判断代码健康状况 5. 识别外部依赖和需要关注的技术栈版本 输出要求 - 项目一句话定位 - 模块地图 核心入口文件标注 - 技术栈清单表 - 最值得观察的 3 个代码文件解释代码.md就是前面 2.4 节写的那个命令不多重复。学习计划.md是我专门给那些“需要快速上手但不想硬啃”的场景准备的。它会结合项目实际结构生成一条渐进学习路线--- description: 为陌生项目生成学习路径 argument-hint: 项目路径或模块名 allowed-tools: Bash, Read, Grep --- 你是一位经验丰富的技术导师。请为 $1 制定一份学习计划目标是让一个不了解该项目的人快速上手开发。 要求 1. 先读取项目基础文件了解架构和技术栈 2. 定义学习阶段全局认知 → 核心链路 → 模块深度 → 扩展实践 3. 每个阶段给出学习目标、具体要读的文件清单、推荐练习任务 4. 标注出新手最容易踩坑的地方 5. 控制在 7 天内可完成 输出格式每个阶段按“目标 / 阅读材料 / 动手任务 / 自测题”四段式呈现。到这里10 个命令就齐了。我把它们整理成一个速查表方便你在自己配置时对照命令名功能典型参数建议工具权限/审查代码严格代码审查文件路径 / 改动范围Read, Grep, Bash/解释代码通俗讲解代码文件路径 / 函数名Read, Grep/重构代码行为不变地重构文件路径 / 目标Read, Edit, Bash/排查报错分析报错根因报错信息 / 文件Read, Grep, Bash/拆分任务需求拆解需求描述Read, Grep/生成提交生成提交信息提交类型Read, Grep, Bash/编写测试生成单元测试文件路径 / 函数名Read, Edit, Bash/生成文档生成项目文档模块名 / 范围Read, Grep/项目盘点梳理项目架构项目路径Read, Grep, Bash/学习计划生成上手路线模块名Read, Grep4. 在真实项目里跑一遍这套流程4.1 场景一提交前自查我跟很多开发者一样以前提交代码前只在心里过一遍觉得“应该没大问题”。后来我养成了一个固定仪式改完代码之后先跑/审查代码 改动让它把git diff里的内容审一遍。等它输出问题列表后我会针对 P0/P1 级别的问题直接改掉。然后跑/编写测试把关键函数补上测试等测试通过后再用/生成提交产出提交信息。这三个命令连起来用效果比单独用好得多。审查结果可以指导测试用例的补充测试跑过的代码提交起来也更有信心生成提交信息时因为前面两者已经理清了改动逻辑AI 写出来的 commit 质量也会更高。整个过程基本不用重复解释“我的项目背景是什么”因为命令模板里已经包含了所有必要的上下文。4.2 场景二接手一个陌生仓库有一回我接手了一个内部工具项目几百个文件没有 README前一个人离职得比较仓促。我没有一头扎进代码里而是先用/项目盘点 .对整个仓库做了一次扫描得到模块地图和核心文件列表。接着用/解释代码 src/main.py把入口逻辑摸清楚又用/学习计划生成了三天的上手路线。这套流程走下来我从“完全陌生”到“能改第一行代码”只花了大半天时间。最值钱的不是少踩了几个坑而是知道坑在哪里。项目盘点直接告诉了我三个最值得关注的文件学习计划又安排了优先级避免了东看一眼西看一眼的低效探索。4.3 场景三需求开发卡壳时开发新功能时最容易出现的状况是需求只说了个大概做到一半发现想法很模糊。我的处理方式是先丢给/拆分任务 “给订单列表增加批量导出功能”让它先把需求拆成最小可行闭环。得到任务清单后从第一个任务开始写。如果中途遇到报错直接复制报错信息丢给/排查报错它会基于整个代码库定位到具体文件。修完之后再按需求给出的验收标准跑测试。这个过程让我从“想到哪做到哪”变成了“按清单推进”开发节奏明显稳了。4.4 这套命令包实际带来的变化可能有人会觉得这不就是把 prompt 存成文件嘛能有多大的效率提升我记录了一下之前每执行一次高质量代码审查从打字到调整 prompt 大概要花两到三分钟而且每次生成的格式还不稳定。用命令之后整个过程压缩到十秒以内输出格式也从“随缘”变成了“稳定可控”。更重要的是质量稳定性。好 prompt 不是每一次都能凭感觉写出来的但命令文件一旦定稿就是稳定的“最佳实践版本”。即使我某天状态很差Claude Code 依然能按照我的高标准去审查代码这个价值远远超过省下的打字时间。5. 踩坑与排查技巧实录5.1 命令文件建好了却找不到我刚开始配置时就翻过车把文件命名为审查代码 .md中间多了个空格结果怎么输/审查代码都触发不了。另外有些终端对中文文件名的支持确实不太稳明明文件存在却显示不出来。我的解决思路分两步第一文件名里别加空格和特殊符号就用简洁的汉字第二如果中文名不生效直接建一个拼音别名文件比如/shencha内容完全一样。千万不要在这个问题上死磕我们要的是能跑起来不是验证理想主义。5.2 frontmatter 格式出错导致命令直接报错YAML frontmatter 的格式非常敏感少了闭合的---或者字段缩进不对Claude Code 会直接拒绝加载。有一次我在 allowed-tools 里的某个工具名后面多了一个空格命令在列表里能看到但点进去就报错。排查了半天才发现是格式问题。建议你每建一个命令文件后马上在对话框里输入/命令名测试一下。如果报错优先检查 frontmatter 的写法。养成写一条验一条的习惯不要攒十个文件一起排错那就太痛苦了。5.3 参数 $1 没有正确传递很多命令要接收参数比如文件路径。我一开始用的写法是$ARGUMENTS结果在命令里同时引用了$1又引用了$ARGUMENTS导致 AI 不知道以哪个为准。后来我统一了规则只有一个参数就用$1需要把整个参数原样塞给 AI 就用$ARGUMENTS两者不混用。这里还有个小技巧参数里包含中文路径时有些终端可能会被转义。如果你发现 AI 拿到的路径货不对板可以考虑先让命令自己运行find或git status来定位文件而不是完全依赖用户传入参数。5.4 工具权限限制了能力怎么办在我的命令设计里有的命令故意没给 Edit 权限比如“解释代码”和“项目盘点”。出现的结果就是AI 想改代码时被安全机制挡住。这个设计是故意的防止它在不该动手的场景乱动代码。但有些人用的时候会觉得命令不够“聪明”比如说“我让它分析完之后顺手把问题修了它说不具备这个权限”。这时你只需要去~/.claude/commands/对应文件里在allowed-tools加上 Edit 就能放开限制。我建议按照命令的用途谨慎放开保持权限边界清晰。5.5 全局命令与项目命令的覆盖关系还有一个使用上容易绕晕的点全局命令和项目命令同名时哪个生效以我的实测经验来说项目级命令会覆盖全局命令。有一次我在全局放了/生成文档模板又在某个项目里放了同名文件结果行为跟预期不一样排查半天才想起来有同名覆盖这回事。所以建议是全局目录只放通用性命令项目目录只放定制化命令尽量避免同名。团队如果想要统一行为最好把所有命令都放进项目的.claude/commands/并提交到 Git这样就不会因为成员本地的全局配置不同而产生奇怪差异。5.6 大型项目里上下文控制Claude Code 的上下文窗口是有限的如果你的命令让 AI 一口气读很多文件比如为了让“项目盘点”读取全仓库的架构信息它会消耗大量上下文后面的对话可能会变得迟钝甚至出现幻觉。我的对策是在命令里明确限制读取范围比如“只读取根目录的文件和 config 文件不要递归读取所有源码”。或者先用Bash工具执行ls和find扫一眼结构再根据结果决定读哪些文件。命令设计得越收敛AI 在长任务中的表现就越稳。最后分享一点我自己的体会这套中文命令包从创建到现在已经被我在好几个项目里反复打磨过。最大的感受就是真正好用的 AI 编程工作流不是靠“问得好”而是靠“把好的问法固化成工具”。你每次重复敲下的那一大段 prompt其实都是你经验的一部分只是没有沉淀下来而已。把命令文件建好相当于把这些经验变成了项目的资产。如果你看完也想动手做一套我的建议是先挑两个你最常用、最痛的需求比如“代码审查”和“生成提交”写出来跑一个礼拜再按实际效果迭代。不用一步到位做十个命令是活着的东西边用边改才是正确打开方式。等到你哪天发现自己已经好几天没有手动打过完整 prompt 的时候这套工作流就算真正建成了。