企业官网建设流程全解析

1. 为什么我要给 Claude Code 塞进 10 个中文命令

用 Claude Code 写代码这件事，最开始吸引我的是它那种"终端里直接对话改代码"的爽感。但用了两周之后，我发现自己每天在做大量重复动作：让它按固定格式写 commit message、让它先读某个目录再动手、让它把改动整理成一份变更说明、让它按团队规范检查命名。每次都要重新打一遍提示词，效率低得离谱。

后来我意识到，Claude Code 真正被低估的能力不是"对话写代码"，而是它支持把自定义命令做成可复用的工作流入口。你可以在项目里放一组命令文件，用中文命名，敲一个短词就能触发一整套预设行为。这本质上和 Nginx 里 location 匹配的工作流机制是一个思路——请求进来，按规则路由到对应的处理块，只不过这里路由的是"我的意图"，处理块是"一段预设的 AI 行为"。

我把这套东西整理成了 10 个中文命令，覆盖日常开发里最高频的场景。这篇文章不讲虚的，直接把这 10 个命令的设计思路、文件结构、每个命令解决什么问题、怎么落地、踩过哪些坑，全部摊开讲。适合已经在用 Claude Code 或者 Codex CLI 这类终端 AI 编程工具、但还停留在"每次手打提示词"阶段的同学。如果你还没装，我也会在第二节把安装和目录结构讲清楚，照着做就能跑起来。

先说结论：这 10 个命令不是让你少打几个字，而是把"我脑子里的一套流程"固化成了"工具能稳定复现的动作"。这个差别，用过之后回不去。

2. 命令系统的目录结构与加载机制

2.1 Claude Code 自定义命令放在哪

Claude Code 的自定义命令本质上是 Markdown 文件，放在特定目录下，工具启动时会扫描并注册。项目级命令放在项目根目录的.claude/commands/下，用户级命令放在用户主目录的~/.claude/commands/下。项目级的优先级更高，适合团队共享；用户级的适合个人跨项目复用。

我建议的做法是：通用能力放用户级，项目专属的放项目级。比如"生成 commit message"这种到哪都用得上的，放用户级；"按本项目的数据层规范生成 Repository 代码"这种强绑定的，放项目级。

目录长这样：

~/.claude/commands/ ├── 提交.md ├── 审查.md ├── 解释.md ├── 重构.md ├── 测试.md ├── 文档.md ├── 排查.md ├── 梳理.md ├── 补全.md └── 收尾.md

文件名就是命令名。你在 Claude Code 里输入/提交，它就会加载提交.md的内容作为系统提示的一部分，然后结合你后续输入的内容执行。

2.2 命令文件里到底写什么

一个命令文件的核心就是一段结构化的提示词。但要注意，它不是简单的"你是一个资深工程师"这种空话。有效的命令文件通常包含四块：角色设定、输入约定、执行步骤、输出格式。

拿我的审查.md举例，结构是这样的：

你是一名严格的代码审查者，只关注可维护性和潜在缺陷，不做风格吹毛求疵。 ## 输入 用户会给你一个文件路径或一段 diff。 ## 执行步骤 1. 先通读，识别这段代码的核心职责 2. 检查边界条件：空值、越界、并发、异常路径 3. 检查资源释放：文件句柄、连接、锁 4. 检查命名与职责是否匹配 5. 按严重程度排序问题 ## 输出格式 按 [严重] [中等] [建议] 三档列出，每条包含：位置、问题、原因、修改建议。

关键点在于"执行步骤"必须是可操作的动词序列，而不是形容词堆砌。我见过很多人写的命令文件全是"专业、严谨、高质量"这种词，AI 读完根本不知道要干嘛。步骤越具体，输出越稳定。

2.3 中文命令名的实际体验

用中文命名命令，一开始我是犹豫的。担心编码问题、担心输入法切换麻烦。实测下来，Claude Code 对中文命令名的支持没问题，输入/之后打拼音首字母也能联想出来。真正的好处是：中文命令名对"意图"的表达密度更高。

/review和/审查，后者在我脑子里直接对应"挑毛病"这个动作，前者还要在脑子里翻译一下。/explain和/解释，/refactor和/重构，都是同样的道理。每天敲几十次的东西，这点认知负担的差异会被放大。

注意：命令名不要用生僻字或者多音字，否则输入法联想会很痛苦。我一开始想用/稽核，后来改成/审查，就是因为前者打字太慢。

3. 十个命令逐个拆解：每个解决什么真实问题

3.1 提交：把 diff 变成规范的 commit message

/提交是我用得最频繁的一个。它的逻辑是：读取当前 git 暂存区的 diff，按约定式提交规范生成 message，并且自动判断 type（feat、fix、refactor、docs、test、chore）。

为什么不用现成的 commit 工具？因为那些工具只能看 diff 文本，而 Claude Code 能结合上下文理解"这次改动到底在解决什么问题"。比如你改了一个函数签名，工具可能只看到"参数变了"，但 AI 能看出"这是为了支持分页"。

命令文件里的关键步骤：

1. 执行 git diff --staged 获取暂存改动 2. 如果暂存区为空，提示用户先 add 3. 分析改动的意图，而不是逐行描述 4. 生成 message，格式：type(scope): 描述 5. 描述用中文，不超过 50 字 6. 如果改动涉及多个不相关模块，提示用户拆分提交

实测下来，第 6 步是最有价值的。很多时候我一股脑 add 了一堆文件，它会提醒我"这次改动混了 UI 和数据库两层，建议拆成两个 commit"。这种提醒比生成 message 本身更有用。

3.2 审查：只挑真问题，不挑风格

代码审查类命令最容易写废，因为 AI 天生喜欢"面面俱到"，最后给你列 20 条，其中 18 条是"建议加注释"。我的/审查命令里明确写了三条禁令：

• 不评论代码风格（缩进、空格、引号），那是格式化工具的事
• 不建议加注释，除非逻辑确实反直觉
• 不重复指出同一类问题

然后强制它按严重程度分档。这样输出的结果，我基本可以逐条处理，不用先过滤一遍噪音。

一个真实的例子：它曾经在一个并发写缓存的函数里指出"这里先查后写，中间没有锁，高并发下会重复计算"。这个问题我自己 review 时漏了，因为代码逻辑看起来是对的。AI 的优势在于它不会被"看起来对"骗过去，它会顺着执行路径推演。

3.3 解释：把陌生代码翻译成人话

接手老项目时，/解释救过我很多次。用法是给它一个文件路径或者一段代码，它按"这段代码在做什么、为什么这么写、依赖了谁、被谁依赖"四个维度输出。

我特意在命令里加了一条："如果代码里有历史遗留的奇怪写法，推测可能的原因，但明确标注这是推测。" 因为老代码里很多"反模式"其实是有历史原因的，直接说"这样写不好"是耍流氓。

输出格式我固定成：

职责：一句话 流程：编号步骤 关键依赖：列表 可疑点：列表（标注是推测还是确定）

这个格式的好处是，我扫一眼"职责"和"可疑点"就能决定要不要细看。

3.4 重构：先给方案，再动手

/重构和直接让 AI 改代码是两回事。我的命令强制它分两阶段：第一阶段只输出重构方案，不动代码；我确认之后，第二阶段才执行。

为什么这么设计？因为 AI 重构最大的风险是"改着改着把行为改了"。让它先出方案，我能判断它有没有理解错意图。方案里必须包含：重构目标、涉及文件、每一步的中间状态、如何验证行为不变。

命令里有一句关键约束："每一步重构后，代码都应处于可运行状态。" 这防止它一次性大改，改完跑不起来，我还得回滚。

3.5 测试：从实现反推用例

/测试的逻辑是：读一个函数的实现，反推它应该有哪些测试用例，重点覆盖边界和异常。它不会直接生成一堆expect(true).toBe(true)这种废测试，而是先列用例清单，我勾选之后再生成代码。

用例清单的格式：

先看清单再生成代码，能避免它生成一堆我不需要的用例，也能让我发现"哦这个边界我实现里没处理"。

3.6 文档：从代码生成，但不复述代码

/文档生成的不是"这个函数接收两个参数返回一个对象"这种废话文档。它的约束是："描述函数的契约和意图，不描述实现细节。如果实现变了但契约没变，文档不应该需要改。"

这个约束逼着它去思考"这个函数的对外承诺是什么"，而不是"它内部怎么做的"。生成的文档更像 API 契约，而不是代码翻译。

3.7 排查：给现象，让它列假设

/排查是我调试时的第一反应。用法是描述现象（比如"这个接口偶发 500，日志里只有 timeout"），它按"可能原因、验证方法、优先级"输出一个排查清单。

关键设计：它必须给出"如何验证这个假设"，而不是只列原因。比如"可能是连接池耗尽"后面必须跟"查一下连接池的 active 数量监控"。这样我拿到清单就能直接动手，不用再想怎么验证。

3.8 梳理：把散落的改动整理成变更说明

一个需求做完，改动散在十几个文件里。/梳理读取所有改动，按"功能点"而不是"文件"组织，输出一份变更说明。这份说明可以直接贴到 PR 描述里。

它和/提交的区别是：/提交面向单次 commit，/梳理面向整个需求。粒度不同，输出结构也不同。

3.9 补全：按现有风格续写

/补全用于写重复性代码。比如你已经写了 5 个类似的 Handler，让它按同样的风格写第 6 个。命令里强制它先读已有的 2-3 个同类实现，提取模式，再续写。

这条"先读再写"的约束很重要。不读的话，它会按自己的理解写，风格和现有代码对不上，还得手动改。

3.10 收尾：提交前的自检清单

/收尾是提交前的最后一道关。它检查：有没有遗留的 console.log、有没有注释掉的代码、有没有 TODO 没处理、测试是否通过、有没有调试用的硬编码。

这个命令的价值在于"仪式感"。敲一下/收尾，等于强制自己过一遍清单，比靠记忆靠谱。

4. 让命令真正好用的三个设计原则

4.1 步骤要动词化，不要形容词化

这是我在反复调整命令文件后最大的体会。形容词（专业、严谨、高质量）对 AI 没有约束力，因为它无法量化。动词（读取、对比、排序、标注）才是可执行的。

对比一下：

• 差："请专业地审查这段代码"
• 好："按边界条件、资源释放、并发安全三个维度检查，每个维度列出发现的问题"

后者让 AI 有明确的检查清单，输出质量立刻不一样。

4.2 输出格式要固定，方便后续处理

我所有命令的输出格式都是固定的。/审查固定三档分级，/测试固定表格，/排查固定"原因-验证-优先级"三段。固定格式的好处是，我可以快速扫读，也可以把输出直接粘到别的地方。

如果每次输出格式都不一样，我就得重新理解一遍结构，认知成本很高。

4.3 危险操作要分阶段确认

凡是会改代码的命令（/重构、/补全），我都强制分两阶段：先出方案，确认后执行。这不是不信任 AI，而是改代码这件事本身风险就高，多一道确认成本很低，收益很大。

提示：分阶段确认还有一个隐藏好处——你能从方案里看出 AI 有没有理解错你的意图。如果方案就跑偏了，直接纠正，不用等它改完再回滚。

5. 实测中踩过的坑和对应解法

5.1 命令文件太长反而效果差

一开始我把每个命令文件写得非常详细，恨不得把团队规范全塞进去。结果发现 AI 会"抓不住重点"，输出反而变差。后来我把每个命令文件控制在 50 行以内，只保留最核心的步骤和约束，效果明显提升。

原因是：命令文件是系统提示的一部分，太长会稀释关键指令的权重。就像你跟人交代事情，说三句他记得住，说三十句他反而不知道哪句重要。

5.2 中文命令名和参数混用要注意

/审查 src/utils/date.ts这种用法没问题。但如果参数里包含中文路径或者特殊字符，偶尔会有解析问题。我的做法是：参数尽量用相对路径，避免空格，路径里不要有中文。

5.3 命令之间不要互相调用

我一度想让/收尾自动调用/审查和/测试，做成一个"一键全流程"。实测下来效果不好，因为每个命令的上下文需求不同，串起来之后 AI 容易混乱。后来改成手动依次执行，虽然多敲几下，但每步的输出都更干净。

5.4 版本升级后要重新验证命令

Claude Code 更新比较频繁，偶尔会有行为变化。我遇到过升级后/提交不再自动读取暂存区，需要显式在命令里写git diff --staged。所以每次升级后，我会把 10 个命令快速跑一遍，确认行为没变。

5.5 团队共享时的命名冲突

如果团队多人共享项目级命令，命名要约定好前缀。我们后来改成/审-接口、/审-数据层这种带作用域的命名，避免不同人写的命令重名覆盖。

6. 从 10 个命令到一套个人工作流

这 10 个命令跑顺之后，我发现自己改代码的节奏变了。以前是"想一下、打一段提示词、等结果、不满意再打一段"，现在是"敲命令、看输出、确认或纠正"。前者每次都要重新组织语言，后者是触发一个已经调好的流程。

这其实就是把"提示词工程"沉淀成了"工作流资产"。提示词是一次性的，工作流是可复用的。你调好一个命令，未来几十次使用都受益。

如果让我给刚上手的人一个建议：不要一上来就写 10 个。先挑你每天重复最多的那个动作，写一个命令，用一周，改到顺手，再写第二个。命令的质量比数量重要得多。我那 10 个命令里，真正高频使用的其实就 4 个：/提交、/审查、/解释、/排查。剩下的 6 个是特定场景才用，但需要的时候能省不少事。

最后分享一个我最近加的小技巧：在每个命令文件末尾加一行"如果输入不明确，先问我一个澄清问题，不要猜"。这一行让命令的鲁棒性提升了不少，尤其是/重构和/排查这种输入容易模糊的场景，它会先确认再动手，避免白干。