这段时间我把手头的几个项目都切到了 Claude Code 上跑越用越觉得不对劲每次开工都要把同样的背景、同样的要求重新敲一遍尤其是团队里需求文档、评审意见全是中文我却还要在对话框里用英文组织指令一来一回很别扭。后来我索性做了套东西把 10 个中文命令直接装进了 Claude Code做成了一个 AI 编程工作流包。今天这篇就是把这套东西怎么设计、怎么配、踩过哪些坑完整交代一遍给正在折腾 AI 编程工作流的朋友一个能直接抄的参考。这套工作流包解决的核心问题是把“人怎么给 AI 派活”这件事标准化。以前是我现想现写提示词现在是敲一个/拆需求或者/代码走查Claude Code 就知道自己该进入什么角色、按什么步骤干活、产出什么格式的结果。它适合用过 Claude Code 但觉得交互成本高的人也适合想把团队经验沉淀到 AI 工作流里的技术负责人。1. 为什么要把中文命令装进 Claude Code1.1 我之前的痛点英文指令和上下文割裂先说背景。Claude Code 本身是个跑在终端里的 AI 编程 Agent给它一句话它能自己读项目、改代码、跑命令、提交结果。工具是好工具但我实际用了两周后发现三个特别别扭的地方。第一是每次对话都要重新交代背景。这个项目是做什么的、技术栈是什么、代码风格有什么约定、哪些目录不能动这些话我几乎每天都要说一遍。虽然可以把说明写进 CLAUDE.md 让 AI 自动读但“启动一个任务”这件事本身仍然是散的每次都是临场组织语言。第二是英文指令和中文需求之间的翻译损耗。我们的需求文档、PRD、测试用例全是中文但我习惯用英文给 AI 下指令比如 review the auth module and find potential race conditions。这句话 AI 能懂可它返回的评审意见经常是英文我还得再让它“翻译成中文”。一来一回效率就打折了。第三是团队协作时没有统一的“接口”。组里每个人给 AI 下指令的方式都不同有人让它输出表格有人让它分点列有人让它先问问题。这些不一致导致同一个 AI 工具在不同人手里产出质量差别很大。我需要把“优秀用法”固化下来变成大家都能一键触发的东西。1.2 命令机制到底解决什么问题Claude Code 支持自定义命令本质上是把一段精心设计过的提示词注册成一个斜杠命令。你输入/代码走查它就会把后面跟的参数和预设好的提示词拼在一起让 AI 进入一个固定的工作模式。我打个比方命令就是给 AI 的“岗位说明书”。你不需要每次重新解释这个岗位要做什么、工作流程是什么、交付标准是什么只要喊一声岗位名字AI 就自动进入状态。这和“每次现写提示词”的区别就像用模板生成合同和每次手写合同的区别后者不仅慢还容易漏条款。中文命令还有一个额外的好处命令名本身就是团队沟通的词汇。我们说“等下走查一下登录模块”在终端里就能直接敲/代码走查 登录模块口头语言和工具操作完全对齐。这个体验真的很重要尤其对非英语母语的团队。1.3 这套工作流包的整体设计思路我设计这 10 个命令时不是随手编的而是先盘了一遍日常开发里最重复、最值得标准化的操作把它们分成三类需求侧、代码侧、工程侧。需求侧负责把模糊的东西变清晰对应/拆需求和/写测试。代码侧负责质量把关对应/代码走查、/找Bug、/重构、/解释代码。工程侧负责把开发过程中的杂活标准化对应/补文档、/生成提交信息、/查提交、/搭脚手架。每个命令都遵循一个固定套路先定角色再定步骤再定输出格式。角色让 AI 知道用什么样的专业标准来干活步骤让 AI 不要跳步、不要自由发挥输出格式保证结果可以直接用、可以直接贴到 PR 或者文档里。这个“三段式”就是我整个工作流包的骨架。2. 10 个中文命令的完整清单与逻辑拆解2.1 命令一览表先看全景。我把这 10 个命令的名字、文件名、作用列成一张表文件名的命名规则是“数字-中文命令名.md”之所以加数字前缀是为了在文件列表里排序好看也方便一眼看出分类。命令触发场景核心作用/拆需求拿到一段模糊需求描述拆解成任务清单标注依赖和风险/写测试写完新功能准备补测试根据代码生成测试计划和测试用例/代码走查准备提 PR 之前对指定范围做代码评审输出问题清单/找Bug线上或测试环境出问题定位可疑代码复现路径给出修复建议/重构代码可读性差、重复多设计重构方案并小步实施/解释代码新人接手或review他人代码用中文讲清楚一段代码的逻辑/补文档模块完成但文档缺失生成 README、API 说明、使用示例/生成提交信息准备 commit 时根据 git diff 生成规范提交信息/查提交排查回归问题找历史变更分析提交记录列出可能与问题相关的变更/搭脚手架新建项目或模块按团队规范生成目录结构和基础文件这里要强调一下命令名可以完全按照团队习惯改。比如你们叫“评审”不叫“走查”那把文件名改成代码评审.md就行不影响内部逻辑。中文命令的好处就是工具可以迁就你的语言习惯而不是你去迁就工具。2.2 需求侧命令拆需求和写测试/拆需求是我用得最多的命令。它解决的是那种“需求一句话、细节全靠猜”的场景。比如产品经理丢过来一句“给用户中心加个手机号登录”你直接敲/拆需求 用户中心增加手机号验证码登录支持绑定和解绑命令内置的提示词会让 AI 按这个顺序思考先分析需求里有哪些实体和交互再拆出前后端任务标注每个任务之间的依赖关系最后列出可能的风险点——比如验证码服务怎么接、已有账号体系怎么兼容、安全上要防什么。输出格式是一份分级任务清单P0 是必须做的P1 是推荐做的P2 是可以后置的。/写测试则是在功能代码写完后用的。开发里最常见的场景是功能写完了但测试用例不知道从哪下手或者只写了 happy path边界条件全漏了。这个命令会让 AI 先读目标模块的代码梳理出输入、输出、状态变化然后生成单元测试用例每个用例都标明“测什么、为什么测、预期结果”。我最喜欢的一点是它生成用例时会自动考虑边界值比如线程池满、缓存失效、网络超时这类情况比自己硬想全面得多。2.3 代码侧命令走查、找 Bug、重构、解释/代码走查对标的是一个严格的 Code Reviewer。它的提示词里包含了我认为最重要的评审维度正确性有没有明显逻辑错误、并发安全共享状态有没有 race、异常处理错误路径有没有被吞掉、可维护性命名和结构是否清晰、性能隐患有没有不必要的循环或重复查询。/找Bug的用法很特别它不是为了“读代码”而是为了“复现问题”。我会给它提供现象描述它先列出可能导致该现象的代码路径再逐步排除最后给出一个“最可能原因 验证步骤 修复建议”的三段式答案。这个命令最关键的一点是我约束它必须给出验证步骤不能直接上来改代码。否则 AI 很容易凭空猜一个原因就动手改那风险太大。/重构我设置了两个铁律。第一是要先出方案再动手方案里必须包含“影响范围”和“风险点”让我确认以后才开始改。第二是要小步走一次只做一种重构比如这轮只提炼重复代码下轮再改命名不能一口气全包了。因为 AI 自动改代码的能力虽然强但一旦步子迈大了回归测试就会教你做人。/解释代码是给新人准备的。它的提示词很简洁但规则明确用中文先讲整体流程再讲关键细节如果代码里有晦涩的写法必须指出来并说明为什么要这么写。实测下来它对那种几百行的复杂函数特别好用能快速画出逻辑主线比人肉一行行读快太多。2.4 工程侧命令文档、提交信息、查提交、脚手架/补文档解决的是“代码写完了 README 还是空的”这个老大难。它的输出包含三块项目简介和技术栈、本地运行方式和环境变量说明、核心模块的 API 说明和使用示例。这里我特意加了约束文档里的示例代码必须是可运行的不能是伪代码。因为 AI 生成的文档最常见的问题就是说了一堆废话但例子跑不起来加了这条之后质量提升很明显。/生成提交信息是我觉得“性价比”最高的一个命令因为它的提示词最短但每天能帮你省不少脑细胞。你只要在 git add 之后敲一句/生成提交信息AI 会去读 git diff然后生成一个符合 Conventional Commits 规范的提交信息包括类型、作用范围、一句话描述。团队如果对提交信息格式有要求这个命令特别适合统一规范。/查提交和/生成提交信息是配套的。它的典型场景是今天功能坏了但不知道是哪次改动引入的。命令会让 AI 读取最近的提交历史结合你描述的问题现象列出可能与问题相关的提交和文件变更。它还能生成一份git bisect参考思路帮你定位引入问题的提交。/搭脚手架则是把团队的目录规范固化下来。我们项目约定src/、tests/、docs/三个顶层目录模块代码、测试、文档一一对应。这个命令会根据你提供的模块名一键生成整套目录和基础文件连空文件的初始化注释都写好。新同学上手时直接敲这个命令能避免很多“目录结构五花八门”的问题。3. 核心配置实操手把手装好这个工作流包3.1 准备工作确认版本和目录结构在开始配置之前先确认你的 Claude Code 版本不是太老。命令功能在较新版本里已经比较稳定如果输入/之后看不到自定义命令先升级一下版本再继续。工作流包的物理载体是.claude/commands目录Claude Code 会自动扫描这个目录下的 Markdown 文件把文件名注册成斜杠命令。比如你创建一个.claude/commands/找Bug.md那么在对话里输入/找Bug就能触发它。除了项目级的.claude/commands还有两个层级可以放命令用户级的~/.claude/commands适合放所有项目通用的命令比如/生成提交信息、/解释代码项目级的就放和当前项目强相关的比如这个项目特有的/拆需求模板。个人经验是通用命令放用户级避免每个项目里都复制一份项目相关命令放项目级跟着仓库走团队成员 clone 下来就自带这套工作流。3.2 命令文件的标准结构每个命令文件其实就是一个 Markdown 文件头部用 YAML 写元信息下面是提示词正文。我拿/找Bug举例它的完整结构是这样的--- description: 根据现象描述定位可疑代码给出验证步骤和修复建议 argument-hint: 描述你观察到的异常现象例如“登录接口偶发 500日志里有空指针” --- 你是一名经验丰富的后端开发工程师擅长通过代码分析定位线上问题。 用户会提供一个异常现象描述。你的任务分三步 1. 定位根据现象列出所有可能导致该问题的代码路径逐一分析可能性。 2. 验证对可能性最高的路径设计一个最小验证方案比如加日志、写单测、看特定日志关键词不要跳过这一步。 3. 建议在验证方案通过或确认后给出修复建议并说明影响范围。 输出格式严格遵循 【可能原因】 按可能性从高到低列出。 【验证步骤】 可执行的具体操作。 【修复建议】 包含改动文件和大致思路。 禁止直接修改代码除非用户明确说“直接修复”。这个结构里description决定了你在命令菜单里看到的提示语argument-hint告诉用户这个命令需要附带什么参数。这两段一定不要省否则团队其他人用的时候不知道这命令是干嘛的、要传什么参数。正文的提示词我推荐写成“角色定义 任务拆解 输出格式 禁止事项”四段。前三段让 AI 知道怎么做最后一段“禁止事项”非常关键——它可以把 AI 最容易犯的毛病提前堵住。比如找Bug里禁止直接改代码就避免了一上来就瞎改的风险。3.3 逐个写出 10 个命令的提示词因为篇幅关系我不把 10 个文件的完整内容全贴出来那会把这篇文章撑爆。我挑三个有代表性的把提示词正文的关键部分拆开讲。/生成提交信息是我所有命令里提示词最短的--- description: 根据暂存区的 git diff 生成符合 Conventional Commits 规范的提交信息 argument-hint: 无需额外参数确认 git add 后直接使用 --- 读取当前暂存区的 git diff分析改动内容。 生成一条提交信息格式为 type(scope): subject 规则 - type 从 feat / fix / refactor / docs / test / chore 中选择 - scope 是改动主要涉及的模块名 - subject 用中文不超过 50 个字 - 如果 diff 包含多个逻辑改动只概括主要的一项 直接输出提交信息正文不要加解释。这个命令的关键在于“不要加解释”这四个字。默认情况下 AI 会给你一段说明“根据 diff 我生成了……”之类的废话加了这条输出就能直接粘省掉删改的动作。/代码走查的提示词会长一些重点是定义评审维度和输出格式。我要求它分“必须修复”和“建议优化”两级这样比我看到一坨问题要更有头绪。必须修复的项我会强制要求修复后再合代码建议优化的项先记录下来攒一波再统一改。/拆需求的提示词我加了一个很有意思的要求如果需求描述有歧义AI 必须先把歧义列出来而不是自己脑补一个“最合理”的解释。这个对产品需求特别有用因为它会把“你没说清楚的地方”摆到台面上逼着需求方把话说明白。3.4 CLAUDE.md给所有命令打底如果说命令是各个工种的岗位说明书那 CLAUDE.md 就是公司的“员工手册”是所有 AI 行为的总纲。命令负责定义具体任务怎么做CLAUDE.md 负责定义所有任务共享的规则。我在 CLAUDE.md 里写了几类内容项目技术栈和目录结构、代码风格约定比如缩进、命名规范、注释语言必须用中文、绝对不能碰的东西比如不要删migrations目录下的文件、不要直接改package-lock.json、以及通用工作流要求比如改完代码必须跑相关测试。这些内容听上去细碎但对 AI 行为的约束非常大。比如没有“注释语言必须用中文”这条AI 很容易在你要求补注释的时候生成一堆英文注释你还得再让它翻一遍。有了总纲所有命令执行时都会遵循省心很多。3.5 验证配置是否生效配置好后在 Claude Code 对话框里输入/应该能在命令列表里看到这些中文命令。如果没出现第一件事检查文件扩展名是不是.md第二件事看目录名是不是commands第三件事在对话里输入/reload让工具重新扫描。我把这 10 个命令全部配置好之后通常会做一个“冒烟测试”依次触发三四个命令看它们能否正常读取参数、能否按格式输出。这里有个技巧测试/找Bug时不用真的找一个 bug直接说“测试一下描述一个不存在的问题看看输出结构”AI 会按照格式返回一套空模板格式对了就行。4. 实测三场真实任务跑下来效果如何4.1 第一场给遗留项目做代码走查我拿一个三年前的老项目试了/代码走查指定范围是用户认证模块。这个模块是我自己写的说实话我自认为质量还行。结果 AI 半小时内给出了 17 个问题其中 2 个被归为“必须修复”一个是在 session 校验时没有判断 token 是否过期另一个是在并发登录时存在先更新后校验的顺序问题。这两个问题我在代码 review 时都没注意到尤其是第二个隐藏得很深。这件事给我最大的触动是AI 代码走查不是替代人工评审而是给人肉评审兜底。它擅长的是用已知的代码坏味道扫一遍速度快、覆盖面广人的价值在于判断这些发现哪些是真问题、要投入多少精力修。所以我把/代码走查定位成“第一道防线”跑完之后再找同事重点看它的发现。4.2 第二场从零生成一个小功能加测试我给了/拆需求一段很粗糙的需求描述给博客系统增加一个草稿箱功能。AI 输出的任务清单有 12 项从数据表字段设计到接口路由到前端展示分成了 P0/P1/P2 三级。完成拆解后我直接让它进入实现环节代码写完后再用/写测试生成测试用例。中间出了个小插曲。AI 生成的测试用例里有一个用例检查“草稿状态的文章不能被外部访问”但实现里根本没有这个接口测试自然是失败的。我当时有点恼火但回头想想这恰恰暴露了/写测试的一个隐患它会给不存在的功能写测试。后来我在命令里加了一条硬性要求“所有测试对象必须是代码中已存在的函数或接口禁止臆想未实现的逻辑”这个问题就基本消失了。4.3 第三场用/查提交定位一次诡异回归线上有个接口这周开始偶发超时代码这周只合了三次提交。我直接用/查提交 用户反馈导出接口偶发超时这周开始出现。AI 读取了最近 15 条提交记录把改动涉及时序相关逻辑的三次提交列了出来然后结合我描述的“导出接口偶发超时”判断最可疑的是与导出任务队列长度检查相关的那次改动。我用它给出的思路去看了那段代码果然发现了问题。这次体验让我对/查提交建立了信心。它实际上是把“代码考古”这个耗时过程变成了 AI 的先筛一遍。人不需要再看全部 15 条提交只需聚焦 AI 判断为高可疑的 1 到 2 条定位时间从小时级压缩到分钟级。5. 常见问题与排查技巧实录5.1 命令不出现先按顺序排查新手配置命令最常遇到的情况就是文件也建了内容也写了但输入/之后列表里就是没有。我建议按照下面的顺序排查文件扩展名必须是.md不是.md.txtWindows 用户尤其容易踩这个坑。目录名必须是commands注意是英文不是command也不是命令。位置要对项目命令放.claude/commands/全局命令放用户主目录下的.claude/commands/。用/reload重载配置有时候工具不会实时感知新文件。检查文件名编码。在 macOS 和 Linux 上一般没问题Windows 上如果文件名是中文且乱码多半是系统编码问题把文件名改成简短中文或拼音。还有个容易忽略的细节命令文件顶部的 YAML frontmatter 如果语法错误比如description:后面漏了空格这个命令会被静默跳过不报错也不显示。遇到命令消失的情况先检查这块。5.2 中文命令的几个坑中文文件名本身在 Claude Code 里支持得不错但有几个小坑我提一下。第一个是命令名和参数之间必须加空格比如/找Bug 用户登录失败是有效的/找Bug用户登录失败会被当成一个完整命令名大概率匹配不到。第二个是参数尽量简短。如果你传的参数很长比如直接把一整段报错日志贴进去AI 能处理但命令的响应速度会明显变慢。个人建议是参数里写“现象关键词 模块名”具体日志用另外的方式提供比如告诉它日志文件路径让它自己读。第三个是中文标点。有些输入法会在参数里带全角括号或者全角逗号Claude Code 能理解大部分中文标点但保险起见涉及命令参数时我用半角逗号分隔。这个不是硬性要求纯粹是减少歧义的小习惯。5.3 上下文爆炸与命令瘦身命令提示词如果太长会严重挤压对话里能承载的项目代码量。我一开始把/代码走查的提示词写得很长里面包含了十几条评审标准结果每次走查开始后 AI 过一会儿就忘了后半部分的约束回答质量下降。后来我做了“瘦身”把那些通用的、每条命令都用得上的规则全部挪进了 CLAUDE.md命令里只保留这个任务特有的步骤和输出格式。这样命令本身短小精悍AI 启动时 CLAUDE.md 里的规则又已经加载好了两不耽误。如果遇到必须写长提示词的场景建议把核心要求放在提示词的前半部分AI 对开头的注意力是最集中的。5.4 安全边界与敏感操作这是我最想提醒的一块。Claude Code 有很强的工具调用能力它可以执行终端命令、改文件、跑测试。命令本身是提示词它不会限制 AI 的行为边界真正的边界还是靠 CLAUDE.md 和你的确认习惯来兜住。我给自己定了几条铁律。第一涉及删除操作、批量修改文件、改数据库结构的命令执行前必须人工看一眼 diff不要直接让它一条龙搞完。第二在 CLAUDE.md 里把“绝对不能碰的内容”写得明明白白比如密钥文件、生产环境配置、某些自动生成的目录。第三/生成提交信息这种只读命令可以放心交给 AI但/重构这种会真正改动代码的命令我要求它每一步都停下来等我确认。还有一条经验对话窗口里输出的内容如果不确定对不对别急着按下 confirmation 键。Claude Code 会请求执行某个命令的权限一定要看清楚它要执行的是什么再同意。有一次它想直接跑一个我完全不认识的脚本我拦下来一看是它自己生成的清理脚本虽然大概率无害但这个习惯必须有。5.5 多项目复用的技巧命令配置好之后如果换一个项目还要重新配一遍那就太亏了。我的做法是全局命令和项目命令分层管理。/生成提交信息、/解释代码、/代码走查这类所有项目都能用的放在~/.claude/commands里全局生效。/拆需求、/搭脚手架这类和具体业务强相关的放在项目里跟着代码库走。还有一个技巧是把 CLAUDE.md 也做一个“模板本”。我在个人全局配置里放了一份通用版本里面是编程习惯、语言要求、安全红线。每个新项目 clone 下来后把项目相关的技术栈、目录约定追加进去就行。这样既保证每个 AI 会话都自带基础素养又保留项目个性化空间。最后再说几句实在话这套工作流包用了一个多月最大的变化不是“AI 更聪明了”而是“我对 AI 说的话更少了”。以前启动一项任务是写一篇命题作文现在就是喊一声命令的名字。团队里新同学也能很快上手因为他们不需要知道怎么给 Claude Code 写复杂提示词只要会敲那些命令就行。如果让我给一个最重要的经验那就是不要追求命令数量多要追求每一条命令都把“角色、步骤、输出格式、禁止事项”这四件事说清楚。少而精的命令比一百个含糊的命令有用得多。后续我还打算加上一些 hooks比如提交代码前自动跑一遍/代码走查把这套工作流再往前推一步让质量检查从“手动触发”变成“默认行为”。这个方向我觉得值得继续折腾。