企业官网建设流程全解析

真正让 Claude Code 这类命令行 AI 工具拉开体验差距的，往往不是模型配置得多花哨，而是你有没有一套沉淀下来的模板体系。claude-code-templates 这个名字，听起来像某个开源仓库，其实我把它理解为一件事：把每次重复敲给 AI 的提示词、项目规范、场景指令，整理成有结构、可复用、能维护的文件资产。用了大半年，我的体会是，模板才是决定"队友型 AI"和"一次性问答机器人"之间的分水岭。

这篇文章会先讲模板体系的设计思路和目录骨架，再拆五个高频实战场景的模板写法，然后聊变量注入与多项目适配，最后把我在维护模板仓库时踩过的坑拿出来晒一晒。适合正在用 Claude Code、但觉得每次对话都要重新教一遍的人，也适合想从零搭一套团队共享模板的开发者。

1. 从零散提示词到模板资产：Claude Code 用久了才会懂的事

1.1 模板到底在解决什么

刚开始用 Claude Code 的时候，我的习惯和大多数人一样：在交互框里把需求写清楚，比如"审查一下 src/auth/ 下的代码，重点看安全问题，输出按严重程度分级"。第一次挺爽，第二次也还行，到第五次就烦了——因为同样的审查标准、同样的输出格式、同样的上下文说明，每天都在重复输入。

这里有个容易被忽略的认知：Claude 本身有很强的理解能力，但它是无状态的。每次新对话，它不知道你上个项目里定过什么代码规范，不知道你的测试命令是什么，更不知道你喜欢什么风格的 review 输出。CLI 工具的效率损耗，很大一部分就耗在"重新说明上下文"这件事上。

模板的意义不是"少打字"，而是把团队的知识沉淀变成可执行文件。你在模板里写清楚审查维度、输出格式、禁止事项，Claude 每次调用时就会严格按这套标准执行。模板是格式化的"操作手册"，而不是一句"好好审查"的空话。

1.2 提示词收藏夹和模板体系的本质区别

很多人会把模板理解成"收集一堆好用的提示词"。这个思路错在哪？收藏夹里的提示词是孤立的、没有上下文的，换一个项目可能就失效。而模板体系包含几层结构：项目记忆文件（CLAUDE.md）定义项目的全局规则，自定义命令模板定义场景动作，hook 脚本定义自动化触发的行为，settings 定义权限和边界。

打个比方：提示词收藏夹像是抽屉里的零散零件，模板体系则是一套带图纸的工具墙。零件只有当你要修某一类东西时才想起来翻，工具墙则是你每次走进工作室就能顺手拿对工具。

我建议所有 Claude Code 用户按这个路径演进：

1. 第一阶段：直接在命令行把提示词写全，先把单个任务跑通。
2. 第二阶段：把重复 3 次以上的提示词提炼成命令模板，放到.claude/commands/目录。
3. 第三阶段：补齐 CLAUDE.md、hooks、settings，让模板之间形成配合，形成完整的项目工作流。

这篇文章讨论的就是第三阶段的形态——一个可以持续维护、可以放进 Git 仓库、可以团队共享的模板资产。

2. 先搭骨架：.claude 目录、CLAUDE.md 与 commands 的协作关系

2.1 一张图看懂模板仓库的文件结构

我维护的 claude-code-templates 仓库，核心目录结构长这样：

claude-code-templates/ ├── CLAUDE.md # 全局个人偏好文件（放 ~/.claude/ 下） ├── .claude/ │ ├── commands/ # 自定义斜杠命令模板 │ │ ├── review.md │ │ ├── refactor.md │ │ ├── test.md │ │ ├── init.md │ │ └── debug.md │ ├── hooks/ # 事件钩子脚本 │ │ ├── post-tool-use.sh │ │ └── pre-tool-use.sh │ └── settings.json # 权限、模型、默认行为配置 └── projects/ ├── service-a/ │ └── CLAUDE.md # 项目级记忆文件 └── service-b/ └── CLAUDE.md

这套结构里，commands/是模板的主战场，每个.md文件对应一个斜杠命令。文件名不叫"审查代码.md"而是review.md，因为文件名直接决定了你输入的命令名——/review。

CLAUDE.md则分两个层级：项目根目录的 CLAUDE.md 描述这个仓库自己的技术栈、结构、开发命令，供 Claude 在操作这个项目时参考；用户主目录下的~/.claude/CLAUDE.md描述你的个人偏好，比如"永远不要修改锁文件""所有代码必须写注释"这类跨项目通用的规则。

2.2 命令模板的构成：frontmatter 加正文

每个命令模板都由两块拼接而成。顶部是 YAML frontmatter，用来声明这条命令的元信息；往下是 Markdown 正文，就是实际发给 Claude 的提示词。

下面是我常用的 review 模板开头：

--- description: 执行代码审查，输出结构化审查意见 argument-hint: 审查范围，例如 app/services/order.py 或 src/modules/* allowed-tools: Read, Grep, Glob ---

• description会出现在命令帮助列表中，方便你和其他使用者快速理解这条命令是干嘛的。
• argument-hint是用户敲/review之后按 Tab 或等待时展示的参数提示，能有效降低使用门槛。
• allowed-tools限制这条命令可以调用的工具，防止审查任务跑去执行其他危险操作。

有两点容易被忽略。第一，frontmatter 里还可以配置模型名或禁用某些工具，但这个我建议谨慎使用——模板一旦绑定模型，换版本时会很痛苦。第二，正文部分不需要写"你是一个代码审查专家"这类没有信息量的话，真正有价值的是你在正文中定义的审查维度、工作步骤、输出格式、禁止行为。

2.3 配置层和自动化层，别一上来就整花活

很多模板仓库博主会急着展示复杂的 hooks——比如每次 Claude 读完文件就自动跑一遍 lint。我的建议相反：先别整花活。hooks 和 settings 在模板体系里是"加强配置"，不是"起步配置"。

settings.json最重要的字段是permissions，它决定了 Claude 能做哪些事。比如Bash(npm test)表示只允许它执行 npm test，其他 shell 命令必须先向你确认。这个文件的价值在于给模板划了一条安全边界——模板写得再好，权限越界也会闯祸。

hooks 则是事件触发脚本，典型场景包括：每次 Claude 调用Read工具时记录日志、每条消息结束之后自动执行格式化。但我见过太多人把 hooks 写成了"每次操作都拖慢响应速度"的罪魁祸首。hooks 的调试成本比普通模板高一个量级，建议等你的核心命令模板稳定运行两周之后，再逐步引入。

3. 五个高频场景的模板实战拆解

3.1 代码审查模板：从"随便看看"到"结构化审查"

代码审查是我日常使用频率最高的场景，也是最能体现模板价值的一个。没有模板的时候，我会写"帮我看看这段代码有什么问题"，Claude 给的答案通常比较散，想到哪说到哪，而且经常漏掉安全相关的检查点。

我的 review 模板正文分了四个区块：

对 $ARGUMENTS 指定的文件或目录执行代码审查。 审查维度（按优先级排列）： 1. 安全风险：注入、敏感信息泄露、越权、依赖漏洞。 2. 正确性：边界条件、并发状态、错误处理路径。 3. 性能：热点路径、N+1 查询、无谓的重复计算。 4. 一致性：与项目现有代码风格、命名约定、架构模式的匹配度。 输出格式： 按【阻断】、【建议】、【提示】三级输出。 每条问题必须给出：文件路径+行号、问题描述、触发场景、修改示例。 禁止直接修改代码。审查结束后用一句话概括整体代码质量，并列出最需要优先处理的 3 个问题。

为什么这样设计？第一，审查维度按优先级排列，是因为 Claude 的注意力是有限的，你不排序，它就会平均用力，最后安全和正确性这种高代价问题反而被淹没。第二，强制 "文件路径+行号" 的硬性输出格式，让审查结果可以直接转给开发者，不需要再逐条翻查。第三，明确"禁止直接修改代码"，是对权限边界的事先声明——审查和修改是两件事，混在一起容易夹带私货。

实测的体会是，加一行"最需要优先处理的 3 个问题"比很多人想象的更重要。Claude 默认会把输出写得面面俱到，但人最需要的往往是"先告诉我哪里最疼"。

3.2 重构模板：先摸清依赖，再动手，顺序错了会翻车

重构模板是我在真实项目中试错最多次的一个。核心教训是：不能让 Claude 拿到任务就直接开干。重构的第一步永远是理解现状，而不是修改代码。

先不要修改任何代码，按以下顺序执行： 1. 读取目标模块的全部源码，输出该模块的依赖关系图（被谁引用、引用了谁）。 2. 查看项目中的测试文件，列出与目标模块相关的测试覆盖情况。 3. 基于以上分析，输出重构方案，标注方案的风险等级和预期收益。 4. 得到我的确认后，分步骤执行重构。每一步执行完，必须运行项目测试命令确认无回归。

这模板隐藏的关键是"分步执行 + 每步验证"。Claude Code 在长上下文里容易只顾往前改，改到一半自己都忘了改了什么。强制它每步跑测试，相当于给它装了一个"安全检查点"，一旦某一步失败，它可以及时报告而不是硬着头皮继续。

还有一个小技巧：重构模板里的$ARGUMENTS我通常要求输入目标模块路径，而不是整个项目。范围越小，重构的成功率越高。哪怕一个大型 service 需要动多个目录，也建议拆成多次会话，每次只重构一个被$ARGUMENTS锁定的范围。

3.3 测试生成模板：先列用例矩阵，再写代码

让 Claude 生成测试代码这件事，看起来很诱人，但直接让它"给这个函数写测试"往往会得到一堆边界覆盖不足、断言不痛不痒的用例。测试模板的要点是逼它先把测试设计做出来，再落地代码。

为 $ARGUMENTS 中的函数或模块生成测试文件。 步骤： 1. 阅读被测代码，识别所有输入参数、返回值、异常分支和隐式前置条件。 2. 输出用例矩阵表格：用例名称、输入数据、预期行为、覆盖目标（正常/边界/异常）。 3. 按用例矩阵生成测试代码，遵循项目已有的测试框架和命名规范。 4. 运行测试并报告结果。失败用例必须逐条定位原因，不允许跳过。 禁止做的事： - 不允许为了通过测试而修改被测函数。 - 不允许生成不包含断言的空测试。

用例矩阵这一步特别重要。Claude 一旦先把表格列出来，你再审视一眼就能快速发现它漏了哪些边界条件——你补一行表格，它后面生成的代码就自动按新表格来，这就是"设计先行"的实际价值。

我还习惯在模板里加上"不允许为通过测试而修改被测函数"这一条。因为 Claude 的默认行为里有很强的"取悦用户"倾向，遇到测试失败，它想的是怎么让测试变绿，而不是怎么暴露真实 bug。这一行规则能有效遏制这种倾向。

3.4 项目脚手架模板：把初始化流程标准化

第一次让我意识到模板仓库价值的是/init。它解决的不只是"生成一个 README"这种小事，而是把整个项目初始化流程变成一段可复现的对话。

当前目录为空（或 $ARGUMENTS 指定的目标目录）。请执行项目初始化： 1. 交互式询问：项目类型是 API 服务、前端应用、CLI 工具还是库？ 2. 根据回答生成目录结构（src、tests、docs、scripts 等）。 3. 生成基础配置文件：包管理器配置、lint 规则、编辑器统一配置。 4. 初始化版本控制，创建 .gitignore，提交初始 commit。 5. 生成最小可运行示例，并启动一次构建验证。 所有生成的文件必须以"项目泛化"为原则，不包含本项目特有的业务信息。

这里的核心设计是"交互式询问"。Claude Code 支持在命令中提出澄清问题，而你只需要在模板里写上"请先询问项目类型"，Claude 就会自动与用户交互。这使得同一个模板在 Django 后端项目和 React 前端项目里都能用，不会生硬套壳。

初始化的最后一步我改成"启动一次构建验证"，是因为吃过亏：生成的项目结构看着没问题，实际跑起来报缺依赖。让 AI 在初始化阶段就自我验证一次，比事后排查高效得多。

3.5 Bug 排查模板：逼它从现象走向根因

排查 bug 时，人们最容易犯的错是让 Claude 直接读代码猜原因。读代码当然有用，但一个靠谱的排查模板必须强迫它走完整证据链。

针对 $ARGUMENTS 中给出的报错信息或异常堆栈，执行以下排查流程： 1. 先列出你需要的证据：完整报错堆栈、相关日志、复现步骤、最近的代码变更。 2. 基于已有信息列出三个最可能的根因假设，并按可能性排序。 3. 对排第一的假设，用 Grep 和 Read 定位相关代码，输出验证过程。 4. 如果证据不足以得出结论，明确说明还需要哪些信息，而不是凭空猜测。 5. 最终输出：根因、证据链、修复方案、验证方式。

这模板的思路是"假设驱动 + 验证前置"。Claude 默认倾向是直接跳到"看起来像是 X 导致的，建议改成 Y"，如果没有第 4 条的约束，它常常用一个大致说得过去但未经确认的原因敷衍过去。有了"假设排序"和"验证过程输出"，排查质量会有肉眼可见的提升。

我在模板末尾还会加一句："如果排查超过 5 分钟仍无结论，主动建议开启详细日志或逐步断点调试，而不是继续静态读代码。" 这是对任务时限的显式设定，避免长对话里越绕越深。

4. 变量注入与多项目适配：让通用模板不僵化

4.1 $ARGUMENTS 和其他内置变量

如果不使用变量，每个模板就必须为特定项目定制，那就失去了复用价值。Claude Code 的模板体系内置了几个关键变量，理解它们就能写出"一次编写、处处运行"的命令。

• $ARGUMENTS：命令名称后面的参数，比如/review src/auth中$ARGUMENTS的值就是src/auth。这是最常用的变量，也是命令模板与具体项目之间的对接点。
• $CLAUDE_PROJECT_DIR：当前项目的根目录路径。当你的命令需要访问项目根级文件时，用它做路径锚点。
• 环境变量与 shell 命令插值：模板正文中可以写$(git branch --show-current)这类命令。例如当前分支是 $(git branch --show-current)，请重点检查该分支的改动，能让模板自动感知当前上下文，而不需要用户手动输入。

内置变量的本质是"把输入成本从用户转移到系统"。你写模板时多花一分钟思考"这个信息能不能自动获取"，就能少让使用者敲十次重复内容。

4.2 项目级命令放置策略：全局命令与局部命令

命令模板可以放在两个位置：项目内部的.claude/commands/和用户主目录的~/.claude/commands/。前者只对当前项目生效，后者对所有项目生效。维护模板仓库时，要刻意区分两类命令。

全局命令放"行为习惯类"的东西，比如代码审查格式、统一的行为准则、通用工程流程；项目局部命令放"业务相关"的指令，比如"这个项目的模块划分规则""部署命令是 xx"。一条命令如果在多个项目中使用时都需要微调，就说明它应该接受$ARGUMENTS作为输入，而不是拆成好几份复制到不同项目。

另外要注意：项目内.claude/commands/是应该提交进 Git 的，这样团队成员 clone 下来就能共享同一套命令。我会在仓库的 README 里写清楚"新增命令的步骤"和"命令命名规范"，避免名称冲突。

4.3 CLAUDE.md 与命令模板的边界划分

这是模板体系里最容易被搞混的地方。很多人把所有项目规矩都堆进 CLAUDE.md，结果这文件变成了两千行的"百科全书"，上下文被大量占用，响应速度直线下降。

我的分界原则是：

• CLAUDE.md 只放"切换上下文后依然需要生效的静态规则"：技术栈、目录结构、编码风格、构建测试命令、禁止事项。
• 命令模板放"某个动作触发时的动态流程"：审查步骤、重构流程、初始化流程。

举个例子，"项目使用 Poetry 管理依赖"写进 CLAUDE.md，因为它影响所有任务；而"重构前必须先输出依赖关系图"只存在于/refactor命令里，因为它只影响重构这个动作。静态规则与动态流程分开，模板才能各司其职，不会互相污染上下文。

5. 模板维护中的翻车现场与补救经验

5.1 翻车之一：模板写太宽，输出变套话

我第一版 review 模板只有一句："审查 $ARGUMENTS 并给出意见。" 结果可想而知——输出全是正确的废话："代码整体结构清晰，但可以考虑增加注释。" 这类建议对任何项目都成立，等于没提。

这也是模板体系最常见的翻车模式：模板越短越抽象，AI 输出越泛。补救思路是强制增加"可验证的具体要求"，比如"每条建议必须给出文件路径+行号"，"安全部分必须逐项检查是否有未过滤的用户输入"。"空话"在必须引用具体行号的约束下无处遁形。

修改模板时要警惕另一种极端——模板写得像合同条款，密密麻麻全是规则。实测中模板正文超过 1500 字后，上下文占用会明显拖慢速度，而且 Claude 对长模板后面部分的遵循度会下降。我的经验是单文件正文控制在 600 到 1000 字，内容再多的部分拆成多个命令。

5.2 翻车之二：上下文过载，把模板变成累赘

维护模板仓库一段时间后，我发现有些命令的执行质量反而变差了。排查下来发现原因不是 Claude 变笨了，而是我的模板太长，加上项目 CLAUDE.md 的内容，一次完整的代码审查要把几千字的记忆文件全塞进上下文，模型的有效注意力被稀释。

解决这个问题，靠的是"分级上下文"策略：CLAUDE.md 只保留最核心的 20 条规则；命令模板里不重复 CLAUDE.md 已有的内容；需要更详细的规范时，在模板里写"读取 docs/CODING_STANDARD.md 并遵循"，而不是把规范全文复制进模板。这就像你在工作时不会把整本《代码大全》摆在桌面上，而是需要哪章翻哪章。

5.3 翻车之三：版本漂移，模板随着 CLI 更新慢慢失效

Claude Code 本身的更新节奏很快，我遇到过几次典型的版本漂移：

• 内置变量的Grammar变化，导致模板中的变量引用失效。
• 工具权限模型调整，旧模板里allowed-tools声明了新版本不再识别的工具名。
• 新增了更高效的工具（比如更完善的文件编辑功能），老模板还在用旧的读写方式，效率和稳定性都差一截。

补救的方法是给模板仓库加版本管理习惯。我通常每两周做一次"体检"：选出 5 个最常用的命令，逐一跑一遍最小示例，确认没问题再更新 README 里的兼容版本说明。这个方法听起来原始，但比任何自动检查都可靠。

5.4 翻车之四：团队共用时，模板格式开始分叉

当团队其他人也开始使用这套模板时，新问题出现了：有人喜欢在 review 输出里加总结评分，有人把测试模板改得面目全非，还有人新增了命名风格完全不同的命令。如果不好好管理，模板仓库很快就会变得难以维护。

我在团队里定了几条规约，效果不错：

1. 所有命令模板必须带description，并在 README 索引里登记。
2. 新增命令必须使用统一的命名规范：小写、动词开头。
3. 修改共享命令时，改动必须提交 commit message 注明影响范围。
4. 每人自己的偏好模板放在全局目录~/.claude/commands/，不许覆盖项目级模板。

模板的本质是共识的显式化。团队用同一套模板，意味着大家用同一种标准审查代码、同一套流程初始化项目，代码质量和协作效率都会向好的方向收敛。但前提是，这套模板本身必须有清晰的所有权和变更流程，否则就会从"团队资产"退化回"个人收藏夹"。

最后分享一点经验

维护 claude-code-templates 这样的模板仓库，最关键的不是写模板，而是建立"不断迭代"的习惯。我会定期翻看每条命令的历史使用频率和实际输出质量，把用得最少的那条拿出来拷问：是不是不好记？是不是参数太复杂？是不是替代了更简单的方案？模板和代码一样，没人维护就会腐烂。

另外，一个被很多人忽视的小技巧是：给命令模板取一个"好输入"的名字。/r这样的短命令太多容易混，/review就足够短且明确；/generate-tests太长，/test则容易和项目自身的测试运行命令混淆。命令名的输入体验，直接决定了团队成员愿不愿意用它。

如果你刚开始建模板，不要一上来就追求全场景覆盖。先把你每周重复最多的那个场景固化成第一条命令，用两周，把它磨顺，再往下扩展。模板体系的收益是复利式的，越早开始，后面越省力。