企业官网建设流程全解析

1. 为什么我要折腾这套中文命令工作流

用 Claude Code 做开发的人越来越多，但真正把它用成“顺手工具”的人其实不多。我最初也是把它当成一个高级补全来用，写几行代码、问几个报错，效率提升有限。直到有段时间我同时在维护三个项目，每天在终端里反复敲同样的指令——生成提交信息、解释报错、跑测试、整理变更日志——我才意识到问题不在模型能力，而在于我每次都要重新“告诉它该干什么”。

这个项目标题里的“10 个中文命令”，本质上就是把我日常最高频的十类操作，固化成了 Claude Code 可以直接调用的自定义命令。它们全部用中文命名和触发，覆盖了从代码审查、提交信息生成、报错排查，到文档整理、测试补全、重构建议这一整条链路。做完之后我的体感是：Claude Code 从一个“需要你伺候的对话窗口”，变成了一个“你喊一声它就干活的命令行搭档”。

这套东西适合谁？如果你已经在用 Claude Code，或者正在观望 Codex CLI、各类 AI 编程 CLI 工具，并且每天有大量重复性的编码辅助需求，那这套思路可以直接抄。如果你只是偶尔问两句代码，那可能用不上，但里面关于“命令怎么设计才不鸡肋”的经验，对你理解 AI 编程工作流仍然有价值。下面我会把设计思路、每个命令的实现逻辑、踩过的坑，以及怎么迁移到自己的项目里，全部摊开讲。

2. 整体设计思路：命令不是越多越好，而是要卡在“决策点”上

2.1 为什么选择自定义命令而不是提示词模板

很多人用 AI 编程工具的习惯是：存一堆提示词模板，用的时候复制粘贴。我一开始也这么干，但很快就放弃了。原因很简单——复制粘贴这个动作本身就有摩擦成本。你在终端里改代码，手不离键盘，这时候让你去另一个地方找模板、选中、复制、切回来、粘贴，思路就断了。

Claude Code 的自定义命令机制解决的就是这个摩擦。它允许你把一段预设的指令逻辑写成一个命令文件，之后在会话里直接输入命令名就能触发。我选择中文命名，是因为我的思考语言是中文，输入/审查比输入/review在肌肉记忆上更直接。这不是崇洋媚外与否的问题，纯粹是降低认知负荷。

提示：命令名用中文在部分终端下可能有输入法切换的麻烦。我的做法是给每个中文命令配一个极短的英文别名，比如/审查同时注册/sh，实际用哪个看当时输入法状态。

2.2 十个命令的选取逻辑

我没有拍脑袋凑十个，而是复盘了自己两周内所有和 AI 的交互记录，把高频需求归类，最后收敛到十类。选取标准有三条：第一，每周至少触发三次以上；第二，输入信息可以标准化；第三，输出结果有明确的验收标准。

这十个命令覆盖了“写之前、写之中、写之后”三个阶段。写之前用解释和排查理清现状，写之中用审查、测试、重构保证质量，写之后用提交、文档、变更收尾。报错和迁移则是两个跨阶段的兜底命令。

2.3 命令文件的结构设计

Claude Code 的自定义命令本质上是一个 Markdown 文件，放在特定目录下，文件名就是命令名。文件内容就是你希望 AI 执行的指令。但这里有个关键设计点：命令文件里不能写死具体代码，而要写“处理逻辑”。

我试过两种写法。第一种是把完整提示词写死，比如“请审查以下代码，检查空指针、边界条件、并发安全”。这种写法的问题是，不同语言、不同场景关注的审查点完全不同，写死了反而限制模型发挥。第二种是写元指令，比如“你是资深代码审查员，请根据当前文件的语言和上下文，列出最可能出问题的三个点，并给出修复建议”。实测下来第二种效果好得多，因为它把判断权交给了模型，而模型在具体语境下的判断往往比预设清单更准。

3. 核心命令的细节拆解与实操要点

3.1 审查命令：怎么让 AI 不说废话

代码审查是最容易变成“正确的废话”的场景。你让 AI 审查，它经常回你“建议增加注释”“变量命名可以更清晰”这种没有营养的内容。我的解决办法是在命令里加约束条件。

我的审查命令核心逻辑是这样的：先要求模型识别当前代码的“风险等级”，分为高、中、低三档。高风险指可能导致数据错误、崩溃、安全问题的；中风险指影响可维护性和扩展性的；低风险指风格和命名。然后要求它只输出高风险和中风险，低风险最多提一条。这个约束一加，输出质量立刻上来了。

另一个技巧是要求它给出“反例”。比如审查一个数组遍历，让它构造一个会让这段代码出错的输入。这比单纯说“注意边界条件”有用得多，因为反例是具体的，你能直接拿去写测试。

注意：审查命令不要用在超过 300 行的文件上。模型上下文有限，文件太长它会顾此失彼。我的做法是先让它审查改动部分，用 git diff 的输出作为输入。

3.2 提交命令：生成能过 review 的提交信息

提交信息生成看起来简单，但要生成真正有用的提交信息，需要模型理解“这次改动解决了什么问题”，而不只是“改了哪些文件”。我的提交命令会先让模型读取暂存区的 diff，然后要求它按“类型: 简述”的格式输出，类型限定为 feat、fix、refactor、docs、test、chore 六种。

关键是后面加了一句：如果这次改动包含多个不相关的修改，请拆分成多条提交信息建议。这个设计来自我的真实痛点——有时候我一次改了好几个东西，提交信息写成一条就很笼统，拆开又懒得手动分。让 AI 帮我拆，我只需要决定采纳哪条。

实测下来，这个命令生成的提交信息比我手写的规范得多，而且它经常能发现我自己都没意识到的改动关联性。比如有一次我以为只是改了个 bug，它指出这个改动同时影响了某个接口的返回格式，建议在提交信息里注明，避免后续对接方踩坑。

3.3 报错命令：从堆栈到根因的翻译器

终端报错最烦的是堆栈信息又长又绕，尤其是涉及多层框架调用的时候。我的报错命令设计成两步：第一步，让模型把堆栈信息翻译成“人话”，说清楚是哪一层调用出了问题；第二步，给出最可能的三个原因，按概率排序，每个原因配一个验证方法。

这里有个细节很重要：我要求模型在给出原因时，必须说明“如果是这个原因，你应该能看到什么现象”。比如“如果是依赖版本冲突，你应该在 package-lock 里看到两个不同版本的同一个包”。这个要求逼着模型给出可验证的结论，而不是泛泛而谈。

踩过的坑是：有些报错信息里包含敏感路径或配置，直接贴给模型有泄露风险。我的做法是在命令里加一步预处理，让模型先识别报错信息里是否包含绝对路径、密钥、内网地址，如果有就先用占位符替换再分析。这一步虽然多花几秒，但安全得多。

3.4 解释命令：接手陌生代码的最快路径

接手别人代码时，最怕的是“能看懂每行，但不知道整体在干嘛”。我的解释命令要求模型按三层输出：第一层，用一句话说这个文件/函数的核心职责；第二层，列出它依赖的外部输入和产生的输出；第三层，指出代码里最“反直觉”的三个地方。

第三层是精华。因为常规的代码解释工具只会复述代码逻辑，但真正有价值的是告诉你“这里为什么这么写”。比如一个看起来多余的判空，可能是因为上游某个接口在某些情况下会返回 null。模型在解释时会结合上下文推断这些隐含约定，这比读注释还管用。

提示：解释命令配合“变更”命令使用效果最好。先用变更命令看这次改了什么，再用解释命令理解改动涉及的模块，接手效率翻倍。

3.5 测试命令：补全用例而不是重写测试

很多人用 AI 写测试的问题是，它会把整个测试文件重写一遍，把你原有的测试覆盖掉。我的测试命令明确要求：只补充缺失的用例，不修改已有测试。具体做法是让模型先读取现有测试文件，识别已经覆盖的场景，然后只针对未覆盖的分支生成新用例。

另一个要求是每个新用例必须包含“这个用例在验证什么”的注释。这看起来是小事，但实际维护时非常有用。我见过太多测试文件，用例名是 test1、test2，过两个月谁也不知道在测什么。

参数化测试是模型比较擅长的部分。我会在命令里要求它优先使用参数化写法，把多组输入输出合并成一个用例。这样测试文件更简洁，也更容易看出边界在哪里。

4. 完整实操：从零搭建这套工作流

4.1 环境准备与命令目录结构

Claude Code 的自定义命令默认放在用户目录下的特定文件夹里。我的目录结构是这样的：根目录下按功能分三个子目录，分别是“日常”“质量”“收尾”，每个命令文件用中文命名。这样在输入命令时，虽然 Claude Code 不支持二级命令，但我在命令文件内部做了路由——比如/审查命令会根据当前文件类型自动选择审查策略。

具体操作上，先确认 Claude Code 版本支持自定义命令。然后在终端里创建命令目录，用任意文本编辑器写命令文件。每个文件就是一个 Markdown，第一行是命令描述，后面是具体指令。我建议每个命令文件控制在 200 字以内，太长了模型反而抓不住重点。

4.2 命令文件的编写模板与参数传递

我的命令文件模板分四段：角色设定、任务描述、约束条件、输出格式。角色设定一句话就够，比如“你是资深后端工程师”。任务描述说清楚要做什么。约束条件是最关键的，包括“不要做什么”和“必须做什么”。输出格式规定结果的结构，方便后续处理。

参数传递方面，Claude Code 支持在命令后面跟参数。我的做法是把参数设计成“可选补充说明”。比如/审查 重点关注并发，模型就会在通用审查之外额外关注并发问题。这个设计让命令既有标准流程，又能灵活应对特殊情况。

4.3 十个命令的完整配置清单

下面是我实际在用的配置清单，你可以直接参考修改。每个命令我只列核心指令，具体措辞可以根据你的项目特点调整。

审查命令的核心指令是：识别当前代码风险等级，只输出高、中风险，每个风险配一个反例。提交命令的核心指令是：读取暂存区 diff，按六种类型生成提交信息，多改动时拆分建议。报错命令的核心指令是：翻译堆栈为人话，列三个可能原因及验证方法，预处理敏感信息。解释命令的核心指令是：三层输出，重点说反直觉的地方。测试命令的核心指令是：只补缺失用例，参数化优先，每个用例加说明注释。

重构命令的核心指令是：给出分步重构方案，每步保证代码可运行。文档命令的核心指令是：生成接口说明，包含入参出参和异常情况。变更命令的核心指令是：汇总改动影响面，标注可能受影响的模块。排查命令的核心指令是：列出系统性排查路径，按成本从低到高排序。迁移命令的核心指令是：给出等价改写方案，标注不兼容的地方。

4.4 实测效果与效率对比

我做了个简单对比：同一个功能模块的开发，不用这套命令时，我平均每天要和 AI 交互 40 次左右，其中大概一半是重复性的指令输入。用了这套命令后，交互次数降到 25 次左右，而且每次交互的质量更高，因为命令里已经包含了约束条件，不需要我反复纠正。

时间上的节省更明显。以前生成提交信息要 2 分钟，现在 10 秒。以前排查一个报错要来回问三四轮，现在一轮就能拿到可验证的原因列表。这些零碎时间加起来，每天至少省出半小时。更重要的是心流不被打断，这个价值比时间本身更大。

5. 常见问题与排查技巧实录

5.1 命令不生效或报错怎么办

最常见的问题是命令文件放错目录，或者文件名有特殊字符。Claude Code 对中文文件名的支持在部分系统上不稳定，如果发现命令不生效，先检查文件名是否被转码。我的做法是同时保留中文名和英文别名两个文件，内容一样，哪个能用用哪个。

另一个常见问题是命令执行后模型没有按预期输出。这通常是命令文件里的约束条件不够明确。我的排查方法是：把命令文件内容单独拿出来，在普通对话里测试，看模型是否能理解。如果普通对话里能理解，但作为命令不生效，那就是命令机制的问题，检查文件格式和存放位置。

5.2 模型输出太啰嗦或太简略怎么调

输出长度失控是高频问题。我的经验是，在命令里加一句“如果输出超过 200 字，请先输出摘要，再询问是否需要详细版”。这个设计把控制权交还给用户，避免一次性刷屏。

输出太简略则通常是约束条件太严。比如审查命令如果只让输出高风险，模型可能觉得没什么高风险就只回一句“未发现高风险问题”。我的调整是加一个兜底要求：“如果未发现高风险，请说明你检查了哪些维度”。这样至少你知道它确实检查了，而不是敷衍。

5.3 命令之间的冲突与优先级

十个命令里，审查、重构、测试三个命令有时会给出矛盾的建议。比如审查说“这里应该加判空”，重构说“这个判空是冗余的”。我的处理原则是：审查命令优先于重构命令，因为审查关注的是正确性，重构关注的是可维护性。正确性永远优先。

如果两个命令的建议确实冲突，我会在命令里加一句“如果与其他命令的建议冲突，请说明冲突点并给出你的推荐”。这样模型会主动指出矛盾，而不是默默选一个。

5.4 敏感信息泄露的预防措施

这是最需要警惕的问题。我的做法是在所有涉及代码输入的命令里，加一步预处理：让模型先扫描输入内容，识别是否包含密钥、内网地址、个人路径，如果有就用占位符替换后再分析。这一步虽然增加了 token 消耗，但安全无小事。

另外我建议定期审查命令文件本身，确保没有把敏感信息写死在命令里。命令文件是明文存储的，如果里面包含了项目密钥，那就等于把钥匙挂在门上。

6. 命令工作流的扩展与个人体会

这套东西做完之后，我最大的感受是：AI 编程工具的上限不取决于模型多强，而取决于你怎么把它嵌入自己的工作流。十个命令只是一个起点，真正有价值的是“把重复决策固化成命令”这个思路。

我现在会定期复盘自己的操作记录，发现新的重复模式就加一个命令。比如最近我经常需要把一段代码从一种风格转成另一种风格，就加了个“风格”命令。命令数量不是重点，重点是每个命令都卡在一个真实的决策点上。

如果你也想搭一套，我的建议是从三个命令开始：审查、提交、报错。这三个覆盖了最高频的场景，做完就能感受到效率变化。然后再根据自己项目的技术栈和协作规范，逐步扩展。不要一上来就追求大而全，命令多了记不住反而成了负担。

最后分享一个小技巧：给每个命令写一句“使用场景”备注，放在命令文件的第一行。这样过几个月你回来看，还能快速想起这个命令是干嘛的。我吃过这个亏，早期写的几个命令后来自己都忘了触发条件，白白浪费了。