1. 中文命令的想法是怎么来的从机械敲英文 slash 到顺手的工作流先交代一下起因。我日常用 Claude Code 做编码辅助一开始跟绝大多数人一样把提示词全写成英文slash 命令也沿用默认的那几个。用久了之后我发现两件事第一同一个仓库里的历史项目、交接文档、内部术语混在一起每次启动会话都要重新解释“这个项目的目录结构是什么”“哪些文件是生成的”“测试该跑哪一条”上下文被大量重复述求占掉第二中文母语者在做代码审查、提交信息、排障复盘时思维语言其实是中文硬要把提示词转成英文再喂给模型等于在思维和工具之间加了一道翻译损耗。所以我决定做一件很朴素的事把这套 AI 编程工作流里反复用的动作打包成 10 个中文命令装进 Claude Code 里。这里的“中文命令”不是指自定义 slash 命令的底层实现变成了中文而是命令的触发词、语义逻辑、输出结构全部围绕中文使用场景设计。做完之后最直观的感受是打字从/explain变成/解释从/commit变成/提交从“先写一段英文说明再贴代码”变成直接“给我看看这段到底哪里有问题”。命令本身不复杂但整套工作流的体感完全是另一回事。如果你也在用 Claude Code 这类终端里的 AI 编程工具或者你在用 Codex、其他 AI 编程插件但一直觉得交互不够贴合自己的习惯这篇文章可能正合适。我会把 10 个命令的挂载方式、命令文件内容、前后串联的逻辑、踩过的坑全部摊开讲你照着做就能复现一套自己的中文工作流包。2. Claude Code 命令的挂载机制.claude/commands与全局命令的关系在开始列命令清单之前先把命令是怎么生效的讲清楚。Claude Code 支持两类自定义命令一类是放在项目目录下的.claude/commands/文件夹里只对当前项目生效另一类是放在用户全局目录的~/.claude/commands/里对所有项目生效。命令文件就是普通的 Markdown 文件文件名去掉.md后缀之后就是你在对话里输入的 slash 命令名。这个设计的好处在哪我举个例子。我手头有 A、B 两个项目A 是后端 API 服务B 是前端后台管理。A 项目里我可能需要一个/建表命令让它根据 model 定义生成数据库迁移脚本B 项目里我更需要的是/接口命令让它把后端 Swagger 文档直接转成前端请求函数。如果全部塞进全局命令两个项目里都会出现一堆用不上的命令选择成本反而变高。所以我的策略是全局命令放“所有项目都用得上的通用动作”/解释、/补全、/重构、/提交、/审查。项目命令放“跟当前代码库强相关的动作”/建表、/接口、/日志、/排障。剩下一个/测试我放在全局但命令文件里会根据当前项目自动探测测试框架后面细说。命令文件的头信息是可选的我习惯在文件最上方保留一段 YAML 格式的描述用来写这个命令是干什么的部分版本也支持在头信息里声明参数提示和可用工具。名字可以直接用中文文件名在终端里输入/审查和/code 审查都能触发我实测下来中文文件名在 zsh 和 bash 下都没有兼容问题唯一要注意的是团队协作时如果别人用 macOS 而你在 Windows 上提交文件文件名编码最好保持 UTF-8。实际挂载步骤非常简单# 全局命令目录 mkdir -p ~/.claude/commands # 项目级命令目录 mkdir -p .claude/commands # 查看当前已加载的命令 claude --list-commands这里有一个容易被忽略的坑命令文件名的前缀匹配是严格区分大小写的。我一开始建了个Review.md又建了个review.md结果两个文件同时存在时系统只认其中一个而且不报错。后来我把命令名统一改成小写拼音加中文描述才彻底避开这个歧义。命令名我选择用小写拼音比如shencha、buxian正文输出全部中文这样既保留中文语义又避免在某些终端环境里输入中文斜杠命令时输入法抢占焦点的问题。如果你不怕麻烦直接用中文文件名也可以但我在远程服务器上通过 ssh 操作时遇到过中文输入不进去的情况所以最终方案是拼音触发词。3. 十个命令背后的分工逻辑从补全到排障为什么是这十个一套工作流包不能贪多命令太多记不住等于没用。我筛选命令的原则是“每天至少用一次、覆盖编码闭环的关键节点、命令之间可以串联”。最终留下的十个命令大致分成三类。触发词文件位置作用典型场景/buxian全局补全当前文件中未实现的函数和 TODO写了一半的代码继续填/jieshi全局解释代码片段或整个文件接手旧代码、Code Review 前理解逻辑/chonggou全局小步重构并给出测试建议函数太长、重复逻辑太多/shencha全局审查 git 改动并输出风险清单提交前自查、MR 前检查/ceshi全局根据上下文生成单测用例新功能落地后补测试/tijiao全局生成符合规范的中文提交信息每次 git commit/jiantab项目读取 model 定义生成建表 SQL 或迁移文件后端加数据表/jiekou项目把接口文档转成前端调用函数前后端联调阶段/rizhi项目分析日志文件并给出异常链路排查线上报错/paizhang项目针对当前报错启动多步排查流程本地环境问题定位我特意保留了“提交”这个反直觉的选项。很多人觉得 AI 生成 commit message 是小菜一碟但我实际用下来直接让模型看git diff生成的信息经常出现“改了什么文件”和“为什么这么改”两层信息失真的问题。/tijiao命令在提示词里明确要求模型先读 diff再读最近五条历史提交信息模仿本仓库已有的提交风格最后输出一个不超过三行的中文提交信息。它不会自动执行git commit只把信息生成好放在那里我自己确认后再提交——这是我有意为之的边界设计后面会展开说。3.1 日常编码三件套补全、解释、重构/buxian是我用的最频繁的一个命令。它做的事很简单扫描当前文件的 TODO、pass、NotImplementedError、空函数体、以及明显中断的代码块逐个补全实现。真正让它好用的是我在命令里加了几条约束每次只补一个 TODO补全后必须给出“我改了什么”的摘要如果函数涉及外部服务调用需要先输出依赖说明再输出实现。如果是复杂项目还可以指定上下文文件。这个“逐个处理”的设定很关键如果一次让它补十个地方模型容易在前几处消耗大量上下文后面的补全质量明显下降。/jieshi则是一个“反向”命令。它不是让 AI 写代码而是让 AI 当解说员。这个命令对两类场景特别值钱一是刚接手别人的代码二是看自己两个月前写的代码。命令提示词里我写了固定的输出结构先一句话概括这段代码的职责再按执行顺序拆成列表解释最后指出“如果我要改某个行为应该关注哪几行”。这个结构不是凭空想的早期版本里我让它“随便解释一下”结果它输出一大段教科书式描述我根本抓不住重点。后来强制了输出结构价值立刻出来了。当你拿/jieshi去解释一个文件它生成的往往不是代码逐行翻译而是把模块之间的依赖和设计意图梳理出来这个信息密度比读注释高很多。/chonggou的设计原则是“小步安全重构”。提示词里固定出现三个字“不要跳步”。我见过不少 AI 重构翻车案例原因都是模型一次性给出一个完美但巨大的改动方案看起来很有道理实际上牵一发动全身。所以我的命令要求它先列出候选重构点标出高风险项目然后一次只做一步每步后补上验证命令编译、测试或 lint。这个命令还强制要求模型在重构前先调用 git 创建分支或至少确认当前工作区是干净的。我把它和/ceshi串联起来先重构再补测试效果比单独重构稳定很多。3.2 质量把关四件套审查、测试、提交、排障/shencha是这十个命令里对我工作方式改变最大的一个。以前提交 MR 之前我要么自己肉眼过一遍 diff要么随手写一段英文让 Claude 看常常丢三落四。现在/shencha的命令文件里写死了执行顺序先拿到当前分支相对主分支的文件列表再逐个看 diff按“变更文件-变更摘要-风险点-建议”的格式输出。它还会自动检查有没有把密钥、日志路径、调试代码带进提交。最实用的一个细节是命令里要求它给每个风险点标注严重程度分为“必须处理”“建议处理”“可以忽略”三级。这样我在提交前只处理红色级别的风险就够了不会每个问题都停下来纠结。/ceshi是我反复调教最多次的命令。第一版提示词太简单它生成的测试用例经常是“快乐路径”所有异常分支全部没覆盖。后来我在命令里加入了被测文件上下文、现有测试风格示例、覆盖率优先级三部分。命令会先读取项目中已有的一个测试文件作为风格模板再生成新用例。比如项目里已有 pytest 风格它不会给你生成 unittest 风格的东西。测试用例的数量我控制在“核心逻辑不少于三条正常输入、边界输入、异常输入”避免它一次生成五十条凑数。/tijiao前面说过了关键设计是不自动执行 commit。同样道理也用在/paizhang上。/paizhang是一个多步排查命令它的输入通常是一个报错信息也可能是日志中的异常堆栈。命令会强制模型走“复现-定位-假设-验证-修复建议”五步流程尤其强调前面两步。我遇到过太多次模型跳过复现直接给修复方案结果修复方案本身就有问题。有了五步流程之后它至少会在输出里写清楚“我在当前仓库里找到了哪些线索”“哪些证据还不足”这个收敛感很重要。如果排查对象是本地环境问题它还会检查依赖版本是否匹配。对了/paizhang和/rizhi经常配合使用前者处理单个报错后者做海量日志的异常链路分析。/rizhi单独说一下。这个命令面向的不是实时终端而是项目里收集到的日志文件。命令会先让用户指定一个日志文件路径或目录然后扫描其中的 WARN、ERROR、Exception 关键词把相关行按时间轴聚合再结合当前代码库里的源码栈输出错误链路的可能原因。我把这个命令放在项目级目录因为只有具体项目才清楚自己的日志格式。我曾经把它放在全局目录结果命令面对不同项目五花八门的日志格式时不知所措后来挪到项目级再配合项目的CLAUDE.md里的日志规范说明准确率立刻上来了。3.3 工程协作两件套建表、接口/jiantab和/jiekou是比较偏业务的命令适用范围没有前面几个广但在我参与的后端 API 服务项目和前端后台项目里价值极高。/jiantab做的事情是读取项目里已定义的 model 或实体类生成对应的建表 SQL 或者 ORM 迁移文件。命令里最重要的提示是“先读现有迁移文件的风格再生成新迁移”否则它生成的字段类型、命名规则、索引策略会跟项目历史完全不搭。有过一次教训后我还加了一条“如果 model 里没有注释不允许猜测字段含义必须输出待确认项”。这一条治好了 AI 最致命的毛病——强行合理化。它不知道user_type到底是用户类型还是用户组类型时以前会靠上下文猜一个现在会直接问。/jiekou则是把后端接口文档转成前端可用的请求函数。它支持的输入包括 OpenAPI 的 JSON/YAML 文件、Swagger 页面复制过来的接口说明、甚至后端同事写在文档站里的 Markdown 版接口说明。命令会识别出接口的路径、方法、参数、返回值然后结合前端项目里现有的请求封装库比如 axios 实例、拦截器生成对应的 TypeScript 函数。这个命令最关键的一点是强行绑定现有封装如果没有让它先读src/api/request.ts它生成的代码就像是自己造了一套网络层既没有统一拦截器也没有错误处理。加上这个约束之后生成的代码风格和手写的一致到可以放进 code review。4. 把它们串成工作流一次从需求到合并的最小闭环单独一个命令好用跟把它们串成一条工作流是两种体验。我现在的日常状态基本上是一条命令链接到需求后先jieshi现有代码定位改动位置然后手写或让buxian补全实现写完跑一遍shencha自查必要时chonggou整理结构再ceshi补单测最后tijiao生成提交信息。为什么这个顺序很重要因为每一步的输出都是下一步的输入。shencha输出的风险清单里如果有“这个函数复杂度太高”我会先执行chonggou再补测试而不是先写测试后重构。重构会改变行为吗理论上不该改变但人写的代码和 AI 写的代码都可能出错测试如果建立在重构前的结构上重构后很可能要重写一版。所以我的优先级永远是“结构稳定再补测试”。在联调阶段链路的组织换了一种方式。后端改完表结构jiantab生成迁移文件前端拿到新接口文档jiekou生成请求函数联调报错了rizhi分析后端日志paizhang处理单点异常。整个过程里我不需要反复把人话翻译成英文指令中文命令直接对应具体动作对于团队里的初级工程师来说摸清这条链路的成本也低。我还有一个比较特殊的工作流是用 Claude Code 结合本地模型跑“轻量验证”。项目在 VSCode 里配置好 Claude Code 之后我通常先用本地模型做第一轮代码风格审查再用云端模型做深度重构建议。这个做法有两个好处一是高频小动作不烧额度二是两个模型交叉验证能发现单一模型固定思路下的盲区。如果你也想这么搞可以先在 Claude Code 里配置好本地模型服务地址比如 LM Studio 启动的本地 API把第一轮审查命令指向它。我实际体验下来本地模型对中文命令的理解也很稳定毕竟命令文件里的提示词是完整的中文文本不依赖模型的英文能力。当然如果你没有本地模型的条件这个环节完全可以跳过不影响主流程。5. 实现过程中踩过的坑与适配方案命令不是越多越好而是越收敛越好这十个命令不是一次性设计出来的期间我踩了不少坑有些坑可能你也正在踩。第一个坑是上下文爆炸。早期我把大量项目背景写进全局命令结果每个命令文件动辄三四百行每次调用都要消耗大量上下文。比如/chonggou里我塞了项目编码规范、目录结构、禁止事项看起来面面俱到实际上模型在处理重构任务时根本用不上那么多背景反而因为上下文太长对核心代码的关注度下降了。解决方案是收敛全局命令只放“跟语言无关的动作指令输出格式约束”项目背景交给项目的CLAUDE.md文件去管命令里的提示词保持在 100 到 200 行以内。命令和记忆文件各管一摊这条边界越清楚整体效果越好。第二个坑是命令文件的版本失控。当命令文件进入 git 仓库后团队成员会各自修改。有人喜欢加语气词“请”有人改成命令句式改来改去最终文件被改得面目全非某些人本地的行为跟仓库里的行为对不上。我现在的做法是命令文件一进仓库就设为只读所有修改必须走 MR并且在命令文件头部写一行注释说明这个文件由谁维护。有人觉得这样太重了但对一个多人协作超过三个人的项目来说这种克制能避免大量莫名其妙的“为什么我本地没有这个效果”的问题。第三个坑是输出结构没有强制化。这是我最想提醒的一点。Claude Code 这类工具默认行为是让模型自由发挥但如果一个命令每次调用的输出格式都不一样你就没法在这个命令之上再做自动化。比如/shencha如果一会儿输出 JSON 格式的风险清单一会儿输出散文式的审查报告你就无法在命令结果后面接其他处理。我的做法是每个命令文件都定义明确的输出段落标题例如/paizhang固定输出“1. 复现步骤 2. 定位依据 3. 假设列表 4. 验证命令 5. 修复建议”。这些段落标题本身就是要喂给下一步处理的结构化锚点。第四个坑藏在命令触发词与输入法冲突里。在终端里用中文输入斜杠命令会碰到输入法状态切换的问题。你敲完/之后如果输入法还在中文模式后面的拼音会被直接输入为英文字母命令可能触发失败。我改成拼音触发词之后这个问题就消失了但我们团队里也有人更喜欢英文触发词。我建议你在命名时提前统一策略要么全中文、要么全拼音、要么全英文别混着来否则记忆成本会急剧上升。如果你把命令文件放进项目仓库还要考虑 CI 工具在非交互环境下扫描.claude/commands时对中文文件名的兼容性部分自动化流程里中文文件名会带来不必要的编码问题。第五个坑是你以为给了上下文其实没给到位。/jiekou早期版本在生成前端请求函数时经常写出跟项目封装不一致的代码。我以为它“知道”项目里有个request.ts但实际上我没有在命令文件里明确说“先读 src/api/request.ts”。在 AI 编程工具里上下文不是默认共享的而是需要显式指路的。所谓的指路有两种方式一种是在CLAUDE.md里写好模块地图一种是命令文件里直接要求模型先读取目标文件。我两种方式都用了效果最好的是双管齐下。命令开始时的第一句话往往是“先读取以下文件之后再继续”这句话的输出顺序要非常靠前否则模型可能在读了目标文件之前就开始生成代码。第六个坑跟安全边界有关。很多 AI 编程工作流包喜欢让 AI 自动执行git commit、git push这些操作。我不反对自动化但我的命令设计原则是高风险动作一律半自动。/tijiao只生成信息不跑 commit/chonggou只改代码不动 git/shencha只输出结论不直接改代码。原因很简单AI 执行代码改动时如果改动范围超过预期你至少要在 commit 这一步停下来看一眼。把最后一道闸门握在自己手里整个工作流包的风险会小一个量级。这套“半自动”理念后来也被我用在其他工具链上比如 CI 配置、依赖升级脚本都保留了人工确认步骤。6. 从命令包到个人工作流的迁移建议这套东西搭好之后下一步自然是想把它迁移到其他项目、其他机器上去。如果你也想搭一套自己的中文命令包我建议你按下面的路径来而不是一上来就复制我的命令文件。先盘点自己一周内重复最多的十个动作。用 Claude Code 的人打开终端敲/的时候心里大概都有数哪些指令是高频的是“解释这段代码”还是“帮我写测试”是“看下日志”还是“生成提交信息”不要把别人清单里的命令硬搬过来每个团队、每个项目的痛点不一样。我这份清单里的/jiantab和/jiekou就是明显偏后端业务的项目命令你如果是纯前端项目可能更需要一个/样式命令或/状态命令。第二步是区分全局命令和项目命令。判断标准很简单这个命令换一个项目还能用吗如果答案是“能”放全局如果答案是“不能得结合这个项目的技术栈才行”放项目目录。我刚开始时几乎把全部命令都塞在全局用了两周后发现一半命令在某个项目里完全没有调用过白白占掉命令列表的展示空间。全局命令控制十个以内是比较舒服的上限再多选择成本就高过收益了。第三步是为每个命令写“不可违背的边界”。这里的边界分两种一是动作边界比如“永远不要在执行前就修改文件”“永远不要自动 push”二是输出边界比如“所有风险点必须标注严重级别”“所有解释必须先给结论再给细节”。这些边界用两三行就能写完但它们决定了工具是“可用”还是“好用”。最后命令文件要当成代码去维护。我见过很多人把~/.claude/commands当存放草稿的文件夹想起来就新建一个命令过期了随手删掉从来不进版本库。我的建议是每一个命令文件都进 git 仓库单独放在一个claude-commands/目录下通过软链接或者是部署脚本同步到.claude/commands。这样换新机器、拉新项目、团队协作都有一条确定的同步链路。我的做法是在~/.claude/commands全局目录里放一个README.md记录每个命令的触发词、维护人、最近修改时间这个 README 本身就是一个命令索引帮我快速回忆起每个命令细节。如果还要说一点个人体会我想说这类中文工作流包真正的价值不在于命令数量而在于你终于把“跟 AI 对话的套路”沉淀成了可重复使用的资产。以前我每次打开 Claude Code 都要重新组织语言现在十个命令一放大部分对话都是一句话触发剩下的精力集中在真正需要思考的设计决策上。那种“工具在顺从你的习惯而不是你在迁就工具”的感觉用久了就回不去了。 
长河君 · 2026/10/6 22:08:52 · 阅读 1.2k 用Claude Code打造中文命令工作流：10个自定义Slash命令提升AI编程效率
1. 中文命令的想法是怎么来的从机械敲英文 slash 到顺手的工作流先交代一下起因。我日常用 Claude Code 做编码辅助一开始跟绝大多数人一样把提示词全写成英文slash 命令也沿用默认的那几个。用久了之后我发现两件事第一同一个仓库里的历史项目、交接文档、内部术语混在一起每次启动会话都要重新解释“这个项目的目录结构是什么”“哪些文件是生成的”“测试该跑哪一条”上下文被大量重复述求占掉第二中文母语者在做代码审查、提交信息、排障复盘时思维语言其实是中文硬要把提示词转成英文再喂给模型等于在思维和工具之间加了一道翻译损耗。所以我决定做一件很朴素的事把这套 AI 编程工作流里反复用的动作打包成 10 个中文命令装进 Claude Code 里。这里的“中文命令”不是指自定义 slash 命令的底层实现变成了中文而是命令的触发词、语义逻辑、输出结构全部围绕中文使用场景设计。做完之后最直观的感受是打字从/explain变成/解释从/commit变成/提交从“先写一段英文说明再贴代码”变成直接“给我看看这段到底哪里有问题”。命令本身不复杂但整套工作流的体感完全是另一回事。如果你也在用 Claude Code 这类终端里的 AI 编程工具或者你在用 Codex、其他 AI 编程插件但一直觉得交互不够贴合自己的习惯这篇文章可能正合适。我会把 10 个命令的挂载方式、命令文件内容、前后串联的逻辑、踩过的坑全部摊开讲你照着做就能复现一套自己的中文工作流包。2. Claude Code 命令的挂载机制.claude/commands与全局命令的关系在开始列命令清单之前先把命令是怎么生效的讲清楚。Claude Code 支持两类自定义命令一类是放在项目目录下的.claude/commands/文件夹里只对当前项目生效另一类是放在用户全局目录的~/.claude/commands/里对所有项目生效。命令文件就是普通的 Markdown 文件文件名去掉.md后缀之后就是你在对话里输入的 slash 命令名。这个设计的好处在哪我举个例子。我手头有 A、B 两个项目A 是后端 API 服务B 是前端后台管理。A 项目里我可能需要一个/建表命令让它根据 model 定义生成数据库迁移脚本B 项目里我更需要的是/接口命令让它把后端 Swagger 文档直接转成前端请求函数。如果全部塞进全局命令两个项目里都会出现一堆用不上的命令选择成本反而变高。所以我的策略是全局命令放“所有项目都用得上的通用动作”/解释、/补全、/重构、/提交、/审查。项目命令放“跟当前代码库强相关的动作”/建表、/接口、/日志、/排障。剩下一个/测试我放在全局但命令文件里会根据当前项目自动探测测试框架后面细说。命令文件的头信息是可选的我习惯在文件最上方保留一段 YAML 格式的描述用来写这个命令是干什么的部分版本也支持在头信息里声明参数提示和可用工具。名字可以直接用中文文件名在终端里输入/审查和/code 审查都能触发我实测下来中文文件名在 zsh 和 bash 下都没有兼容问题唯一要注意的是团队协作时如果别人用 macOS 而你在 Windows 上提交文件文件名编码最好保持 UTF-8。实际挂载步骤非常简单# 全局命令目录 mkdir -p ~/.claude/commands # 项目级命令目录 mkdir -p .claude/commands # 查看当前已加载的命令 claude --list-commands这里有一个容易被忽略的坑命令文件名的前缀匹配是严格区分大小写的。我一开始建了个Review.md又建了个review.md结果两个文件同时存在时系统只认其中一个而且不报错。后来我把命令名统一改成小写拼音加中文描述才彻底避开这个歧义。命令名我选择用小写拼音比如shencha、buxian正文输出全部中文这样既保留中文语义又避免在某些终端环境里输入中文斜杠命令时输入法抢占焦点的问题。如果你不怕麻烦直接用中文文件名也可以但我在远程服务器上通过 ssh 操作时遇到过中文输入不进去的情况所以最终方案是拼音触发词。3. 十个命令背后的分工逻辑从补全到排障为什么是这十个一套工作流包不能贪多命令太多记不住等于没用。我筛选命令的原则是“每天至少用一次、覆盖编码闭环的关键节点、命令之间可以串联”。最终留下的十个命令大致分成三类。触发词文件位置作用典型场景/buxian全局补全当前文件中未实现的函数和 TODO写了一半的代码继续填/jieshi全局解释代码片段或整个文件接手旧代码、Code Review 前理解逻辑/chonggou全局小步重构并给出测试建议函数太长、重复逻辑太多/shencha全局审查 git 改动并输出风险清单提交前自查、MR 前检查/ceshi全局根据上下文生成单测用例新功能落地后补测试/tijiao全局生成符合规范的中文提交信息每次 git commit/jiantab项目读取 model 定义生成建表 SQL 或迁移文件后端加数据表/jiekou项目把接口文档转成前端调用函数前后端联调阶段/rizhi项目分析日志文件并给出异常链路排查线上报错/paizhang项目针对当前报错启动多步排查流程本地环境问题定位我特意保留了“提交”这个反直觉的选项。很多人觉得 AI 生成 commit message 是小菜一碟但我实际用下来直接让模型看git diff生成的信息经常出现“改了什么文件”和“为什么这么改”两层信息失真的问题。/tijiao命令在提示词里明确要求模型先读 diff再读最近五条历史提交信息模仿本仓库已有的提交风格最后输出一个不超过三行的中文提交信息。它不会自动执行git commit只把信息生成好放在那里我自己确认后再提交——这是我有意为之的边界设计后面会展开说。3.1 日常编码三件套补全、解释、重构/buxian是我用的最频繁的一个命令。它做的事很简单扫描当前文件的 TODO、pass、NotImplementedError、空函数体、以及明显中断的代码块逐个补全实现。真正让它好用的是我在命令里加了几条约束每次只补一个 TODO补全后必须给出“我改了什么”的摘要如果函数涉及外部服务调用需要先输出依赖说明再输出实现。如果是复杂项目还可以指定上下文文件。这个“逐个处理”的设定很关键如果一次让它补十个地方模型容易在前几处消耗大量上下文后面的补全质量明显下降。/jieshi则是一个“反向”命令。它不是让 AI 写代码而是让 AI 当解说员。这个命令对两类场景特别值钱一是刚接手别人的代码二是看自己两个月前写的代码。命令提示词里我写了固定的输出结构先一句话概括这段代码的职责再按执行顺序拆成列表解释最后指出“如果我要改某个行为应该关注哪几行”。这个结构不是凭空想的早期版本里我让它“随便解释一下”结果它输出一大段教科书式描述我根本抓不住重点。后来强制了输出结构价值立刻出来了。当你拿/jieshi去解释一个文件它生成的往往不是代码逐行翻译而是把模块之间的依赖和设计意图梳理出来这个信息密度比读注释高很多。/chonggou的设计原则是“小步安全重构”。提示词里固定出现三个字“不要跳步”。我见过不少 AI 重构翻车案例原因都是模型一次性给出一个完美但巨大的改动方案看起来很有道理实际上牵一发动全身。所以我的命令要求它先列出候选重构点标出高风险项目然后一次只做一步每步后补上验证命令编译、测试或 lint。这个命令还强制要求模型在重构前先调用 git 创建分支或至少确认当前工作区是干净的。我把它和/ceshi串联起来先重构再补测试效果比单独重构稳定很多。3.2 质量把关四件套审查、测试、提交、排障/shencha是这十个命令里对我工作方式改变最大的一个。以前提交 MR 之前我要么自己肉眼过一遍 diff要么随手写一段英文让 Claude 看常常丢三落四。现在/shencha的命令文件里写死了执行顺序先拿到当前分支相对主分支的文件列表再逐个看 diff按“变更文件-变更摘要-风险点-建议”的格式输出。它还会自动检查有没有把密钥、日志路径、调试代码带进提交。最实用的一个细节是命令里要求它给每个风险点标注严重程度分为“必须处理”“建议处理”“可以忽略”三级。这样我在提交前只处理红色级别的风险就够了不会每个问题都停下来纠结。/ceshi是我反复调教最多次的命令。第一版提示词太简单它生成的测试用例经常是“快乐路径”所有异常分支全部没覆盖。后来我在命令里加入了被测文件上下文、现有测试风格示例、覆盖率优先级三部分。命令会先读取项目中已有的一个测试文件作为风格模板再生成新用例。比如项目里已有 pytest 风格它不会给你生成 unittest 风格的东西。测试用例的数量我控制在“核心逻辑不少于三条正常输入、边界输入、异常输入”避免它一次生成五十条凑数。/tijiao前面说过了关键设计是不自动执行 commit。同样道理也用在/paizhang上。/paizhang是一个多步排查命令它的输入通常是一个报错信息也可能是日志中的异常堆栈。命令会强制模型走“复现-定位-假设-验证-修复建议”五步流程尤其强调前面两步。我遇到过太多次模型跳过复现直接给修复方案结果修复方案本身就有问题。有了五步流程之后它至少会在输出里写清楚“我在当前仓库里找到了哪些线索”“哪些证据还不足”这个收敛感很重要。如果排查对象是本地环境问题它还会检查依赖版本是否匹配。对了/paizhang和/rizhi经常配合使用前者处理单个报错后者做海量日志的异常链路分析。/rizhi单独说一下。这个命令面向的不是实时终端而是项目里收集到的日志文件。命令会先让用户指定一个日志文件路径或目录然后扫描其中的 WARN、ERROR、Exception 关键词把相关行按时间轴聚合再结合当前代码库里的源码栈输出错误链路的可能原因。我把这个命令放在项目级目录因为只有具体项目才清楚自己的日志格式。我曾经把它放在全局目录结果命令面对不同项目五花八门的日志格式时不知所措后来挪到项目级再配合项目的CLAUDE.md里的日志规范说明准确率立刻上来了。3.3 工程协作两件套建表、接口/jiantab和/jiekou是比较偏业务的命令适用范围没有前面几个广但在我参与的后端 API 服务项目和前端后台项目里价值极高。/jiantab做的事情是读取项目里已定义的 model 或实体类生成对应的建表 SQL 或者 ORM 迁移文件。命令里最重要的提示是“先读现有迁移文件的风格再生成新迁移”否则它生成的字段类型、命名规则、索引策略会跟项目历史完全不搭。有过一次教训后我还加了一条“如果 model 里没有注释不允许猜测字段含义必须输出待确认项”。这一条治好了 AI 最致命的毛病——强行合理化。它不知道user_type到底是用户类型还是用户组类型时以前会靠上下文猜一个现在会直接问。/jiekou则是把后端接口文档转成前端可用的请求函数。它支持的输入包括 OpenAPI 的 JSON/YAML 文件、Swagger 页面复制过来的接口说明、甚至后端同事写在文档站里的 Markdown 版接口说明。命令会识别出接口的路径、方法、参数、返回值然后结合前端项目里现有的请求封装库比如 axios 实例、拦截器生成对应的 TypeScript 函数。这个命令最关键的一点是强行绑定现有封装如果没有让它先读src/api/request.ts它生成的代码就像是自己造了一套网络层既没有统一拦截器也没有错误处理。加上这个约束之后生成的代码风格和手写的一致到可以放进 code review。4. 把它们串成工作流一次从需求到合并的最小闭环单独一个命令好用跟把它们串成一条工作流是两种体验。我现在的日常状态基本上是一条命令链接到需求后先jieshi现有代码定位改动位置然后手写或让buxian补全实现写完跑一遍shencha自查必要时chonggou整理结构再ceshi补单测最后tijiao生成提交信息。为什么这个顺序很重要因为每一步的输出都是下一步的输入。shencha输出的风险清单里如果有“这个函数复杂度太高”我会先执行chonggou再补测试而不是先写测试后重构。重构会改变行为吗理论上不该改变但人写的代码和 AI 写的代码都可能出错测试如果建立在重构前的结构上重构后很可能要重写一版。所以我的优先级永远是“结构稳定再补测试”。在联调阶段链路的组织换了一种方式。后端改完表结构jiantab生成迁移文件前端拿到新接口文档jiekou生成请求函数联调报错了rizhi分析后端日志paizhang处理单点异常。整个过程里我不需要反复把人话翻译成英文指令中文命令直接对应具体动作对于团队里的初级工程师来说摸清这条链路的成本也低。我还有一个比较特殊的工作流是用 Claude Code 结合本地模型跑“轻量验证”。项目在 VSCode 里配置好 Claude Code 之后我通常先用本地模型做第一轮代码风格审查再用云端模型做深度重构建议。这个做法有两个好处一是高频小动作不烧额度二是两个模型交叉验证能发现单一模型固定思路下的盲区。如果你也想这么搞可以先在 Claude Code 里配置好本地模型服务地址比如 LM Studio 启动的本地 API把第一轮审查命令指向它。我实际体验下来本地模型对中文命令的理解也很稳定毕竟命令文件里的提示词是完整的中文文本不依赖模型的英文能力。当然如果你没有本地模型的条件这个环节完全可以跳过不影响主流程。5. 实现过程中踩过的坑与适配方案命令不是越多越好而是越收敛越好这十个命令不是一次性设计出来的期间我踩了不少坑有些坑可能你也正在踩。第一个坑是上下文爆炸。早期我把大量项目背景写进全局命令结果每个命令文件动辄三四百行每次调用都要消耗大量上下文。比如/chonggou里我塞了项目编码规范、目录结构、禁止事项看起来面面俱到实际上模型在处理重构任务时根本用不上那么多背景反而因为上下文太长对核心代码的关注度下降了。解决方案是收敛全局命令只放“跟语言无关的动作指令输出格式约束”项目背景交给项目的CLAUDE.md文件去管命令里的提示词保持在 100 到 200 行以内。命令和记忆文件各管一摊这条边界越清楚整体效果越好。第二个坑是命令文件的版本失控。当命令文件进入 git 仓库后团队成员会各自修改。有人喜欢加语气词“请”有人改成命令句式改来改去最终文件被改得面目全非某些人本地的行为跟仓库里的行为对不上。我现在的做法是命令文件一进仓库就设为只读所有修改必须走 MR并且在命令文件头部写一行注释说明这个文件由谁维护。有人觉得这样太重了但对一个多人协作超过三个人的项目来说这种克制能避免大量莫名其妙的“为什么我本地没有这个效果”的问题。第三个坑是输出结构没有强制化。这是我最想提醒的一点。Claude Code 这类工具默认行为是让模型自由发挥但如果一个命令每次调用的输出格式都不一样你就没法在这个命令之上再做自动化。比如/shencha如果一会儿输出 JSON 格式的风险清单一会儿输出散文式的审查报告你就无法在命令结果后面接其他处理。我的做法是每个命令文件都定义明确的输出段落标题例如/paizhang固定输出“1. 复现步骤 2. 定位依据 3. 假设列表 4. 验证命令 5. 修复建议”。这些段落标题本身就是要喂给下一步处理的结构化锚点。第四个坑藏在命令触发词与输入法冲突里。在终端里用中文输入斜杠命令会碰到输入法状态切换的问题。你敲完/之后如果输入法还在中文模式后面的拼音会被直接输入为英文字母命令可能触发失败。我改成拼音触发词之后这个问题就消失了但我们团队里也有人更喜欢英文触发词。我建议你在命名时提前统一策略要么全中文、要么全拼音、要么全英文别混着来否则记忆成本会急剧上升。如果你把命令文件放进项目仓库还要考虑 CI 工具在非交互环境下扫描.claude/commands时对中文文件名的兼容性部分自动化流程里中文文件名会带来不必要的编码问题。第五个坑是你以为给了上下文其实没给到位。/jiekou早期版本在生成前端请求函数时经常写出跟项目封装不一致的代码。我以为它“知道”项目里有个request.ts但实际上我没有在命令文件里明确说“先读 src/api/request.ts”。在 AI 编程工具里上下文不是默认共享的而是需要显式指路的。所谓的指路有两种方式一种是在CLAUDE.md里写好模块地图一种是命令文件里直接要求模型先读取目标文件。我两种方式都用了效果最好的是双管齐下。命令开始时的第一句话往往是“先读取以下文件之后再继续”这句话的输出顺序要非常靠前否则模型可能在读了目标文件之前就开始生成代码。第六个坑跟安全边界有关。很多 AI 编程工作流包喜欢让 AI 自动执行git commit、git push这些操作。我不反对自动化但我的命令设计原则是高风险动作一律半自动。/tijiao只生成信息不跑 commit/chonggou只改代码不动 git/shencha只输出结论不直接改代码。原因很简单AI 执行代码改动时如果改动范围超过预期你至少要在 commit 这一步停下来看一眼。把最后一道闸门握在自己手里整个工作流包的风险会小一个量级。这套“半自动”理念后来也被我用在其他工具链上比如 CI 配置、依赖升级脚本都保留了人工确认步骤。6. 从命令包到个人工作流的迁移建议这套东西搭好之后下一步自然是想把它迁移到其他项目、其他机器上去。如果你也想搭一套自己的中文命令包我建议你按下面的路径来而不是一上来就复制我的命令文件。先盘点自己一周内重复最多的十个动作。用 Claude Code 的人打开终端敲/的时候心里大概都有数哪些指令是高频的是“解释这段代码”还是“帮我写测试”是“看下日志”还是“生成提交信息”不要把别人清单里的命令硬搬过来每个团队、每个项目的痛点不一样。我这份清单里的/jiantab和/jiekou就是明显偏后端业务的项目命令你如果是纯前端项目可能更需要一个/样式命令或/状态命令。第二步是区分全局命令和项目命令。判断标准很简单这个命令换一个项目还能用吗如果答案是“能”放全局如果答案是“不能得结合这个项目的技术栈才行”放项目目录。我刚开始时几乎把全部命令都塞在全局用了两周后发现一半命令在某个项目里完全没有调用过白白占掉命令列表的展示空间。全局命令控制十个以内是比较舒服的上限再多选择成本就高过收益了。第三步是为每个命令写“不可违背的边界”。这里的边界分两种一是动作边界比如“永远不要在执行前就修改文件”“永远不要自动 push”二是输出边界比如“所有风险点必须标注严重级别”“所有解释必须先给结论再给细节”。这些边界用两三行就能写完但它们决定了工具是“可用”还是“好用”。最后命令文件要当成代码去维护。我见过很多人把~/.claude/commands当存放草稿的文件夹想起来就新建一个命令过期了随手删掉从来不进版本库。我的建议是每一个命令文件都进 git 仓库单独放在一个claude-commands/目录下通过软链接或者是部署脚本同步到.claude/commands。这样换新机器、拉新项目、团队协作都有一条确定的同步链路。我的做法是在~/.claude/commands全局目录里放一个README.md记录每个命令的触发词、维护人、最近修改时间这个 README 本身就是一个命令索引帮我快速回忆起每个命令细节。如果还要说一点个人体会我想说这类中文工作流包真正的价值不在于命令数量而在于你终于把“跟 AI 对话的套路”沉淀成了可重复使用的资产。以前我每次打开 Claude Code 都要重新组织语言现在十个命令一放大部分对话都是一句话触发剩下的精力集中在真正需要思考的设计决策上。那种“工具在顺从你的习惯而不是你在迁就工具”的感觉用久了就回不去了。