企业官网建设流程全解析

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. 十个命令背后的分工逻辑：从补全到排障，为什么是这十个

一套工作流包不能贪多，命令太多记不住等于没用。我筛选命令的原则是“每天至少用一次、覆盖编码闭环的关键节点、命令之间可以串联”。最终留下的十个命令，大致分成三类。

我特意保留了“提交”这个反直觉的选项。很多人觉得 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 都要重新组织语言，现在十个命令一放，大部分对话都是一句话触发，剩下的精力集中在真正需要思考的设计决策上。那种“工具在顺从你的习惯，而不是你在迁就工具”的感觉，用久了就回不去了。