企业官网建设流程全解析

1. 为什么我要给 Claude Code 装一套中文命令

用 Claude Code 写代码这件事，最开始吸引我的是它的终端交互体验——不用切窗口、不用复制粘贴，直接在项目目录里用自然语言描述需求，它就能读文件、改代码、跑测试。但用久了之后，我发现自己每天在重复输入大量相似的指令：让它按规范提交代码、让它审查某个文件的改动、让它生成接口文档、让它把一段逻辑重构成更清晰的结构。每次都要重新打一遍提示词，既费时间又容易漏掉关键约束。

于是我开始琢磨一件事：能不能把这些高频操作固化成一套命令，用中文触发，一键执行？这就是我后来做的“10 个中文命令工作流包”。它的本质是一组放在项目.claude/commands/目录下的 Markdown 文件，每个文件对应一个自定义斜杠命令，文件名就是命令名，文件内容就是发给模型的提示词模板。你在 Claude Code 里输入/提交、/审查、/文档这样的中文命令，它就会加载对应模板并执行。

这套东西解决的核心问题是把重复的提示词工程沉淀成可复用的团队资产。以前每个人写提示词的水平参差不齐，现在把最佳实践写进命令文件，提交到仓库，所有人用同一套标准。适合谁参考？三类人：一是已经在用 Claude Code 但还在手打长提示词的开发者；二是想把 AI 编程规范落地到团队的技术负责人；三是刚接触 AI 编程 CLI、想找个现成模板快速上手的新手。

需要说明的是，Claude Code 的自定义命令机制本身是官方支持的，我做的只是把中文场景和高频工作流结合起来。下面我会从设计思路、每个命令的实现细节、完整实操过程、踩坑记录四个维度展开，把整套方案拆到你能直接抄作业的程度。

2. 工作流包的整体设计与命令选型逻辑

2.1 自定义命令的底层机制

Claude Code 的自定义命令走的是文件系统约定。项目根目录下建.claude/commands/文件夹，里面每个.md文件就是一个命令。文件名去掉扩展名就是命令名，比如提交.md对应/提交。文件内容支持参数占位符$ARGUMENTS，也支持用!前缀执行 shell 命令并把输出注入提示词，还支持@引用文件内容。

这个机制的关键在于：命令文件本质是提示词模板，不是脚本。它不会执行逻辑判断，只是把预设的文字和动态参数拼成一段完整的提示词发给模型。理解这一点很重要，因为它决定了你的命令设计思路——你要写的是“给模型的清晰指令”，而不是“给机器的程序”。

我选中文命令名而不是英文，原因有三。第一，中文触发词在终端里辨识度高，/提交比/commit更符合母语直觉，减少输入时的认知负担。第二，团队里非英语母语的成员更容易记住和传播。第三，中文命令名和英文命令名可以共存，不冲突，比如官方内置的/help、/clear依然可用。

2.2 十个命令的选型依据

我没有随便凑十个命令，而是按“日常开发高频动作”来筛。统计了自己两周内的 AI 交互记录，出现频率最高的动作依次是：提交代码、代码审查、写文档、重构、写测试、排查报错、解释代码、生成提交信息、检查规范、总结改动。这十个动作覆盖了从编码到提交的完整链路，每个都值得固化成命令。

选型时我遵循一个原则：只固化那些“提示词结构稳定、约束条件明确”的动作。比如“提交代码”这个动作，提示词里需要包含提交信息格式、是否要跑测试、是否要检查敏感文件，这些约束每次都一样，适合固化。而“帮我实现一个功能”这种需求，每次描述差异太大，固化成命令反而限制发挥，就不适合。

十个命令的清单如下，后面会逐个拆解实现：

2.3 目录结构与版本管理

整套命令放在项目仓库里，目录结构是这样的：

项目根目录/ ├── .claude/ │ └── commands/ │ ├── 提交.md │ ├── 审查.md │ ├── 文档.md │ ├── 重构.md │ ├── 测试.md │ ├── 排查.md │ ├── 解释.md │ ├── 规范.md │ ├── 总结.md │ └── 清理.md ├── CLAUDE.md └── src/

把命令文件提交到 Git 仓库，团队每个人拉下来就能用。这比在聊天工具里发提示词模板靠谱得多，因为命令文件可以走代码审查流程，改了什么一目了然。CLAUDE.md是 Claude Code 的项目级记忆文件，我会在里面写项目背景、技术栈、代码规范，命令文件里可以引用它，避免重复描述。

注意：.claude/commands/是项目级命令，只对当前项目生效。如果你想要全局命令，需要放到用户主目录下的~/.claude/commands/。我的建议是项目相关的放项目里，个人通用的放全局，两者可以同名，项目级优先。

3. 十个命令的逐个拆解与实现细节

3.1 提交命令：把提交规范写死在提示词里

提交.md是我用得最频繁的命令。它的核心是把团队的提交信息规范固化下来，避免每次都要提醒模型“用 Conventional Commits 格式”。

请帮我提交当前改动。 要求： 1. 先执行 `git status` 和 `git diff` 查看改动 2. 提交信息格式：<type>(<scope>): <subject> - type 取值：feat/fix/docs/style/refactor/test/chore - subject 用中文，不超过 50 字 3. 提交前检查是否有 .env、密钥、token 等敏感文件被误加入 4. 如果有敏感文件，停止提交并提示我 5. 提交信息正文说明改动的动机，不只是罗列改了什么 $ARGUMENTS

这里有几个设计考量。第一，用!执行 git 命令还是让模型自己执行？我选择在提示词里明确要求模型执行，因为 Claude Code 本身有执行 shell 的能力，让它自己判断时机更灵活。第二，敏感文件检查是硬性要求，写在提示词里比靠人记靠谱。第三，$ARGUMENTS放在最后，允许我追加临时要求，比如/提交 这次改动比较大，正文写详细点。

实测下来，这个命令把提交信息的规范率从大概六成提到了接近百分之百。以前模型经常写出“更新代码”这种无意义的提交信息，现在基本都能按格式来。

3.2 审查命令：让 AI 用审查清单逐项过

审查.md的设计思路是给模型一份审查清单，而不是笼统地说“帮我看看代码有没有问题”。清单式提示词能显著提升审查的覆盖度。

请审查以下代码：$ARGUMENTS 按以下清单逐项检查，每项给出结论： 1. 正确性：逻辑是否有边界问题、空值处理、并发隐患 2. 安全性：是否有注入风险、敏感信息泄露、权限校验缺失 3. 性能：是否有 N+1 查询、不必要的循环、内存泄漏 4. 可读性：命名是否清晰、函数是否过长、注释是否必要 5. 可测试性：是否难以 mock、是否有隐藏依赖 6. 规范符合度：是否符合 CLAUDE.md 中的项目规范 输出格式： - 每个问题标注严重程度（阻断/建议/提示） - 给出具体行号和修改建议 - 如果某项没问题，明确说“通过”

这个命令的关键是要求模型对每项给出明确结论。如果不要求，模型倾向于只挑几个明显问题说，剩下的默不作声，你会误以为都检查过了。要求逐项表态后，审查的完整性大幅提升。

3.3 文档命令：从代码反向生成接口文档

文档.md解决的是“代码写完了但文档没人写”的老问题。它的提示词要求模型先读代码，再按固定模板输出。

请为以下代码生成接口文档：$ARGUMENTS 文档格式要求： 1. 接口名称和一句话描述 2. 请求方法、路径、认证方式 3. 请求参数表格：参数名、类型、必填、说明、示例 4. 响应参数表格：字段名、类型、说明 5. 至少一个请求示例和一个响应示例 6. 异常情况说明：可能的错误码和触发条件 如果代码中有注释，以注释为准；注释和实现冲突时，以实现为准并标注出来。

最后那句“以实现为准并标注出来”很重要。我遇到过注释和实际逻辑不一致的情况，模型如果盲信注释，生成的文档就是错的。要求它标注冲突，等于让它顺便做了一次注释准确性检查。

3.4 重构命令：约束边界，防止改坏

重构是最容易出事的操作，模型可能顺手改了不该改的东西。重构.md的核心是明确边界。

请重构以下代码：$ARGUMENTS 重构目标：$ARGUMENTS 中描述的目标 硬性约束： 1. 不改变对外接口签名 2. 不改变现有测试的预期结果 3. 不引入新的外部依赖 4. 每次只做一类重构，不要混合多种改动 5. 重构后必须能通过现有测试 执行步骤： 1. 先说明你打算怎么改，等我确认 2. 确认后再动手 3. 改完运行测试验证

“先说明再动手”这个设计救过我好几次。有一次模型打算把一个工具函数拆成三个，我看了方案发现其中一个拆分会导致循环依赖，及时叫停了。如果它直接改，我得花时间回滚。

3.5 测试命令：生成能跑的测试而不是摆设

测试.md的目标是生成真正能跑、有断言价值的测试，而不是那种只调用不断言的假测试。

请为以下代码生成单元测试：$ARGUMENTS 要求： 1. 使用项目现有的测试框架（参考 CLAUDE.md） 2. 覆盖正常路径、边界条件、异常路径 3. 每个测试用例只断言一件事 4. mock 外部依赖，不 mock 被测代码本身 5. 测试命名用中文描述场景，如“当输入为空时返回默认值” 6. 生成后实际运行测试，确保全部通过 如果发现代码本身难以测试，先指出设计问题，再给测试方案。

第 6 条“实际运行测试”是必须的。模型生成的测试经常有导入路径错误、断言写反之类的问题，不跑一遍根本发现不了。让它自己跑，能过滤掉大部分低级错误。

3.6 排查命令：结构化分析报错

排查.md针对的是“贴一段报错让 AI 猜原因”的场景。直接贴报错，模型容易给出泛泛的猜测。结构化提示词能引导它做系统分析。

请分析以下报错：$ARGUMENTS 分析步骤： 1. 提取报错的关键信息：错误类型、位置、触发条件 2. 列出 3 个最可能的原因，按可能性排序 3. 针对每个原因，给出验证方法（怎么确认是不是这个原因） 4. 给出修复方案，标注每个方案的副作用 5. 如果不确定，明确说“需要更多信息”，并列出需要什么信息 不要直接给修复代码，先给分析。

“不要直接给修复代码”这条是刻意加的。模型有个坏习惯，看到报错就急着给修复方案，但往往没搞清楚根因。强制它先分析，能避免治标不治本。

3.7 解释命令：逐层拆解代码逻辑

解释.md适合接手陌生代码库时用。它的提示词要求模型按层次解释，而不是逐行翻译。

请解释以下代码：$ARGUMENTS 按三个层次解释： 1. 整体职责：这段代码在整个系统里扮演什么角色 2. 执行流程：按调用顺序说明主要步骤 3. 关键细节：容易误解的地方、隐含假设、边界处理 解释时用生活化类比说明复杂逻辑。 如果代码有潜在问题，在最后单独列出。

分三层是为了适配不同深度的需求。有时候我只想知道这段代码干嘛的，看第一层就够了；有时候要改它，就得看第三层。

3.8 规范命令：项目规范的自动检查

规范.md依赖CLAUDE.md里定义的项目规范。它把规范检查从人工 review 变成一键执行。

请检查当前项目的代码是否符合 CLAUDE.md 中定义的规范。 检查范围：$ARGUMENTS（不填则检查最近改动的文件） 检查项： 1. 命名规范（文件、变量、函数、类） 2. 目录结构规范 3. 导入顺序和分组 4. 注释和文档要求 5. 错误处理模式 6. 日志规范 输出：违规项列表，每项包含文件、行号、违规内容、修正建议。

3.9 总结命令：会话改动的自动归档

总结.md在长会话结束时用，把这次会话改了什么、为什么改、还有什么没做，整理成一份记录。

请总结本次会话的所有改动。 输出格式： 1. 改动文件清单：每个文件改了什么 2. 改动动机：为什么做这些改动 3. 未完成事项：有哪些遗留问题 4. 后续建议：接下来应该做什么 如果本次会话有讨论但未实施的方案，也列出来。

这份总结可以直接贴到 PR 描述里，省去手写的时间。

3.10 清理命令：提交前的最后一道关

清理.md是提交前的收尾命令，专门清理调试残留。

请检查并清理以下内容： 1. console.log / print / 调试输出 2. 注释掉的代码块 3. TODO/FIXME 中已完成的项 4. 临时文件和测试数据 5. 未使用的导入和变量 清理前先列出将要删除的内容，等我确认。 不要删除 TODO/FIXME 中未完成的项。

“等我确认”和“不删未完成的 TODO”这两条是防止误删的关键。我有次差点让模型删掉一个标记着“等接口联调后移除”的临时兼容代码，幸好加了确认步骤。

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

4.1 环境准备与 Claude Code 安装

先说安装。Claude Code 通过 npm 分发，前提是你机器上有 Node.js 环境。我实测 Node 18 和 Node 20 都能跑，建议用 Node 20 以上的 LTS 版本。

# 检查 Node 版本 node -v # 全局安装 Claude Code npm install -g @anthropic-ai/claude-code # 验证安装 claude --version

安装过程中最常见的坑是 npm 全局目录权限问题。如果你看到no write permission to npm prefix这类报错，说明 npm 的全局安装目录当前用户没有写权限。解决办法是重新配置 npm 的全局目录到用户目录下：

# 查看当前全局目录 npm config get prefix # 改到用户目录 npm config set prefix ~/.npm-global # 把 ~/.npm-global/bin 加入 PATH export PATH=~/.npm-global/bin:$PATH

把上面那行 export 写进~/.bashrc或~/.zshrc，否则每次开新终端都要重新设置。这个坑我踩过，当时以为是安装包的问题，折腾了半天才发现是权限。

安装完成后，在项目目录下运行claude就能进入交互界面。首次使用需要完成账号登录流程，按终端提示操作即可。

4.2 创建命令目录与第一个命令

进入你的项目根目录，创建命令文件夹：

mkdir -p .claude/commands

然后创建第一个命令文件。我用提交.md举例，你可以用任何文本编辑器创建：

touch .claude/commands/提交.md

把前面 3.1 节的内容写进去。保存后，在 Claude Code 里输入/，你应该能在命令列表里看到“提交”。如果没看到，检查两点：文件名是否正确、文件是否在.claude/commands/目录下。

提示：命令名支持中文，但文件名不要带空格和特殊符号。如果命令没生效，试试重启 Claude Code 会话，有时候它需要重新扫描目录。

4.3 配置 CLAUDE.md 让命令更聪明

CLAUDE.md是项目级记忆文件，放在项目根目录。它会在每次会话开始时被加载，相当于给模型的“项目说明书”。我的CLAUDE.md大概长这样：

# 项目说明 ## 技术栈 - 语言：TypeScript 5.x - 框架：React 18 + Vite - 测试：Vitest - 包管理：pnpm ## 代码规范 - 组件文件用 PascalCase，工具函数用 camelCase - 导入顺序：内置模块 → 第三方 → 项目内部 → 相对路径 - 禁止使用 any，必要时用 unknown 加类型守卫 - 所有导出函数必须有 JSDoc 注释 ## 提交规范 - 遵循 Conventional Commits - subject 用中文 - 每个提交只做一件事 ## 常用命令 - 开发：pnpm dev - 测试：pnpm test - 构建：pnpm build - 检查：pnpm lint

有了这个文件，规范.md和测试.md里的“参考 CLAUDE.md”才有实际内容可参考。很多人配了命令但没写CLAUDE.md，结果命令执行时模型不知道项目规范是什么，效果大打折扣。

4.4 命令的参数传递与动态内容

$ARGUMENTS是命令里最常用的占位符。当你在 Claude Code 里输入/审查 src/utils/date.ts，$ARGUMENTS就会被替换成src/utils/date.ts。如果输入/审查不带参数，$ARGUMENTS就是空字符串。

除了$ARGUMENTS，还有两个有用的语法。一是!前缀执行 shell 命令，比如：

当前 git 分支：!`git branch --show-current` 最近一次提交：!`git log -1 --oneline`

执行命令时，这两个 shell 命令会先跑，输出注入到提示词里。这个特性适合做“上下文自动收集”，比如让模型知道当前在哪个分支、最近改了什么。

二是@引用文件，比如@src/config.ts会把文件内容读进来。不过我更倾向于用$ARGUMENTS传路径让模型自己读，因为这样更灵活，模型可以决定读哪些相关文件。

4.5 实测：用这套命令完成一次完整开发

我拿一个真实的小需求走一遍流程，让你看到命令是怎么串起来的。

需求是给一个日期工具函数加时区支持。流程如下：

第一步，用/解释 src/utils/date.ts让模型先解释现有代码。输出告诉我这个文件有三个函数，其中formatDate硬编码了本地时区。

第二步，用/重构 src/utils/date.ts 给 formatDate 增加时区参数，默认保持现有行为。模型先给了重构方案，我确认后它动手改，改完跑了测试。

第三步，用/测试 src/utils/date.ts生成新参数的测试用例。模型生成了五个用例，覆盖了默认时区、指定时区、无效时区、夏令时边界、空输入。跑下来全过。

第四步，用/文档 src/utils/date.ts生成更新后的接口文档，贴到项目 wiki。

第五步，用/审查 src/utils/date.ts做最后检查。模型指出一个边界问题：时区参数传空字符串时行为不明确。我补了个判断。

第六步，用/提交提交。模型生成了feat(date): formatDate 支持指定时区的提交信息，检查了没有敏感文件，提交完成。

整个流程下来，我手打的提示词不超过二十个字，其余全靠命令触发。这就是工作流包的价值——把注意力从“怎么跟 AI 说”转移到“要做什么”。

5. 踩坑记录与常见问题排查

5.1 命令不生效的几种情况

最常见的问题是命令文件建好了但输入/看不到。排查顺序如下：

我遇到过一次命令名带了下划线导致识别异常，改成纯中文后就正常了。命令名尽量用简单的中文词，别用生僻字或符号。

5.2 模型不按提示词执行怎么办

有时候模型会忽略命令里的某些要求，比如让它“先说明再动手”，它直接就开始改了。这种情况通常是提示词里的约束不够强硬。

我的经验是：把关键约束放在提示词开头和结尾各说一遍。模型对首尾内容的注意力更高。另外，用“必须”“禁止”“硬性约束”这类词比“请”“建议”更有效。如果某个约束特别重要，可以单独成段并加粗。

还有一种情况是提示词太长，模型顾此失彼。这时候要拆分命令，一个命令只做一件事。我最初把“审查+修复”放在一个命令里，结果模型经常跳过审查直接修。拆成两个命令后就正常了。

5.3 中文命令的编码问题

在 Windows 环境下，中文文件名偶尔会出现编码问题，导致 Claude Code 读不到命令。如果你在 Windows 上遇到这个情况，有两个办法：一是把终端编码改成 UTF-8，二是命令文件名用英文，但在文件内容第一行写中文别名说明。

我自己的主力环境是 macOS 和 Linux，中文文件名没遇到过问题。Windows 用户如果实在搞不定编码，建议命令名用拼音或英文，触发时一样方便。

5.4 命令与项目规范的同步维护

命令文件是活的，项目规范变了，命令里的约束也要跟着改。我吃过一次亏：项目从 Jest 换到 Vitest，但测试.md里还写着 Jest 的配置，导致生成的测试跑不起来。

解决办法是把易变的配置抽到CLAUDE.md里，命令文件只写“参考 CLAUDE.md 的测试框架配置”。这样换框架时只改一个地方。命令文件里尽量写稳定的流程约束，不写具体的版本号和配置细节。

5.5 常见问题速查表

实操心得：命令文件写完后，先自己用一周，把不顺的地方改掉，再提交给团队。直接推给团队的命令如果有问题，别人用一次就不信了，后面再推很难。

6. 命令的扩展方向与个人体会

这套十个命令跑顺之后，我又做了几个扩展。一个是把命令按场景分组，比如“日常开发”组和“代码审查”组，通过子目录组织，.claude/commands/审查/安全.md对应/审查:安全。另一个是给命令加“前置检查”，比如提交命令执行前先跑 lint，不通过就拦住。

还有个方向是把命令和 CI 打通。比如/审查命令的输出格式固定后，可以把它接到 PR 的自动评论里，每次提 PR 自动跑一遍 AI 审查。这个我还在试，主要问题是审查结果的稳定性还需要调。

我个人在实际操作中的体会是：命令的价值不在于省那几秒打字时间，而在于把“怎么做才对”这件事标准化了。以前团队里每个人让 AI 写代码的方式都不一样，产出质量参差不齐。现在命令文件就是一份可执行的规范文档，新人拉下代码就能用同样的标准工作。这比写一堆 Markdown 规范文档管用得多，因为文档没人看，命令天天用。

最后分享一个小技巧：定期回顾你的命令使用记录，把三个月没用过的命令删掉，把高频但还没固化的操作补上。命令集不是越多越好，十个精挑细选的命令，比三十个用不上的命令有价值得多。我现在维持在十二个左右，每季度清理一次，保持这套工作流的锋利度。