企业官网建设流程全解析

1. Claude Code 模板到底是什么，为什么值得单独拿出来聊

很多人第一次接触 Claude Code 的时候，第一反应是"这不就是个能读代码、能改文件的终端助手吗"，然后就开始直接丢需求让它干活。用了一阵子之后你会发现，同一个 Claude Code，在不同项目里的表现差距可以非常大——在 A 项目里它像个熟悉你代码风格的老同事，在 B 项目里它就像个第一天入职、什么都要问的新人。

拉开这个差距的，就是模板。

Claude Code 的模板，本质上是一组预先写好的指令文件，用来统一告诉模型"这个项目是怎么组织的、代码规范是什么、遇到什么情况应该怎么处理"。你可以把它理解成给新员工准备的入职手册加工作手册：入职手册告诉它公司有多大、部门怎么划分；工作手册告诉它提交代码之前要跑哪些检查、线上出问题该找谁。Claude Code 读懂了这些，干活的稳定性和质量就会完全不一样。

这篇内容适合谁？如果你已经用上了 Claude Code，但总觉得它"不够懂你"、每次都要反复纠正它才能干对活，那你需要看这篇文章。如果你正准备在团队里推广 Claude Code，想让大家的行为风格统一，模板更是绕不开的基础设施。我会从模板的分类、目录结构、编写实操、进阶玩法到常见坑位，完整过一遍，最后给出一套可以直接抄走的模板参考。

2. 先认清模板的四种形态，别一上来就只盯着 CLAUDE.md

很多教程提到 Claude Code 模板，张口就是 CLAUDE.md，好像有了这一个文件就万事大吉。实际上模板在 Claude Code 里有四层形态，它们的加载机制、作用范围和适用场景完全不同。把这四种形态分清楚，你才能知道什么时候该用哪个，而不是把所有的东西都塞进一个文件里。

2.1 CLAUDE.md：项目的"宪法"

CLAUDE.md 是 Claude Code 每轮对话开始时都会自动加载的项目记忆文件。它放在项目根目录下，作用范围覆盖整个仓库。简单说，只要你在项目里启动 Claude Code，它就会先读这个文件，然后带着文件里的约束去理解你的所有指令。

它的特点是"常驻"：每次对话都会生效，不管你这个会话是来写代码、查 bug 还是做代码评审。所以 CLAUDE.md 适合放那些"通用、稳定、高频"的约束——项目技术栈是什么、目录怎么组织的、代码风格习惯、构建测试命令、部署注意事项。

我见过不少人把 CLAUDE.md 写成了长篇大论，从公司规章制度写到团队协作流程，结果模型每次对话都要消耗大量上下文去读这些内容，反而影响了对当前任务的专注度。CLAUDE.md 的正确写法是"少而准"，只放那些 Claude Code 每次干活都必须知道的东西。

2.2 自定义命令：把常用操作固化成"快捷键"

自定义命令就是斜杠命令，比如你输入 /review，Claude Code 就会执行一段预设好的操作流程。它们放在 .claude/commands/ 目录下，使用绝对路径的还是项目级命令取决于放在哪里。

这个形态解决的是"高频重复操作"的问题。比如我们团队每天都要做代码评审，以前每次都要手动输入"请帮我看一下这个 PR 的改动，注意检查边界条件和错误处理，按严重程度分类反馈"，字多且每次表述都不一致。把它写成一个 /review 命令之后，输入三个字符就搞定了，评审的标准也统一了。

和 CLAUDE.md 相比，命令是"按需触发"的。你不调用它，它就不消耗上下文。这非常关键——不是所有东西都需要常驻记忆，很多标准流程只需要在用到的时候调出来就行。

2.3 子代理：为特定任务准备的"专家分身"

子代理是 Claude Code 3.7 之后引入的能力，本质上是在主对话之外，定义一个拥有独立系统提示词的"专家角色"。在 Agent SDK 的语境里，你甚至可以为它指定专属的模型参数。子代理的模板文件放在 .claude/agents/ 目录下，每个 Markdown 文件定义一个角色。

和自定义命令的区别在于：命令只是一段指令，执行的时候还是主模型在干活；子代理则是一个独立的全新上下文窗口，它只带着自己的角色设定和任务描述去处理工作，处理完把结果汇报给主对话。

这个设计很聪明，它解决了上下文隔离的问题。比如你要让 Claude Code 审查代码安全性，如果直接在主对话里做，它会带着整个项目的背景和当前任务的各种细节去思考，容易受干扰。但如果你派一个 security-auditor 子代理去，它只专注安全检查这一件事，产出质量会高很多。

2.4 模板目录：整套复用与分发的"打包层"

除了上面三种单文件形态，还有一种统称意义上的"模板"——把 CLAUDE.md、commands、agents、hooks 组合成一个完整的模板目录，像项目脚手架一样，新建项目时直接拷进去就能用。

这种形态适合团队标准化和开源分享。比如你的团队统一用 TypeScript + React + 微前端架构，那你可以做一套完整的 Claude Code 模板包，新建前端项目的时候整套复制过来，所有成员的 Claude Code 行为就从"各自为战"变成了"一个模子刻出来的"。

我认为这是模板最有价值的形态，因为它把"单点配置"升级成了"工程化基础设施"。后面我会专门讲怎么搭建这样一套可复用的模板目录。

3. 从零搭建模板库：目录结构、文件编写与参数设计

说了这么多类型，现在落到实操。我会用一个真实的场景来演示：假设我们要为团队的前端项目搭建一套 Claude Code 模板库，包含 CLAUDE.md、自定义命令和子代理三层结构。

3.1 先规划目录结构，再动手写文件

一套完整的模板库，目录结构大概是这样的：

project-root/ ├── CLAUDE.md ├── .claude/ │ ├── commands/ │ │ ├── review.md │ │ ├── test.md │ │ └── commit.md │ ├── agents/ │ │ ├── code-reviewer.md │ │ └── bug-hunter.md │ └── hooks/ │ └── pre-tool-use.md

这个结构的原则是"各司其职"：CLAUDE.md 放通用约束，commands 放按需操作流程，agents 放专项专家角色，hooks 放自动化拦截逻辑。你不需要一上来就全建，建议按需添加，用到一个领域再加一个文件，避免前期过度设计。

3.2 写一份"不废话"的 CLAUDE.md

CLAUDE.md 的核心是精准，不是全面。我给你的参考结构是四段式：

# 项目概览与命令 ## 项目概览 - 项目名称与一句话定位 - 核心技术在技术栈树：前端 React 18 + TypeScript 5，后端 Node.js 22 + Fastify，数据库 PostgreSQL 16 - 目录结构摘要：src/ 业务代码，libs/ 可复用模块，tests/ 单元测试 ## 常用命令 - 安装依赖: npm install - 启动开发服务: npm run dev - 运行测试: npm test - 构建生产包: npm run build - 代码检查: npm run lint && npm run typecheck ## 代码规范 - 函数必须有明确的输入输出类型，禁止使用 any - 组件使用函数式写法 + hooks，不使用 class 组件 - 提交信息遵循 conventional commits 规范 ## 注意事项 - 修改数据库 schema 后必须生成迁移文件 - 删除代码前先全局搜索确认没有残留引用 - 涉及支付、权限相关改动，必须补充安全测试用例

注意我特意没写"团队文化""日报周报"这些东西。CLAUDE.md 只服务于一个目标：让 Claude Code 在这个项目里的每一次操作都符合项目的基本规则。冗余内容只会稀释它真正的约束力。

写完这个文件之后，你可以做一次快速验证：启动 Claude Code，直接问它"这个项目的测试命令是什么"，它应该能准确回答。如果它答错了或者答得含糊，说明你的文件写得太含糊，需要改得更具体。

3.3 自定义命令怎么编写，参数怎么设计

命令文件是 Markdown 格式，包含 YAML frontmatter 和正文两部分。frontmatter 里定义命令的元信息，正文就是实际操作指令。

给你看一个代码评审命令的完整示例：

--- description: 对当前分支的改动进行代码评审，按严重程度输出问题列表 argument-hint: 可选，指定评审关注点（如：安全、性能、可读性） --- 对当前分支相对于主分支的改动进行代码评审。 评审流程： 1. 先运行 git diff main...HEAD 拿到完整改动列表 2. 从改动中识别出核心逻辑变更，逐一分析 3. 重点关注：边界条件处理、错误分支遗漏、资源未释放、日志缺失 4. 对每个问题标注严重程度（阻塞/重要/建议），并给出修改方案 关注点无论，则按以上通用维度评审； 如果有用户输入，优先围绕用户指定的维度展开。 输出格式： - 头部归纳本次改动涉及的功能模块 - 按严重程度排序，每类下用列表输出问题 - 每个问题包含：文件位置、代码片段、问题描述、修改建议

这个文件里有三个关键设计：第一，argument-hint 告诉用户这个命令可以接收可选参数；第二，正文里明确规定了评审流程，模型就会按照这个流程一步步执行，而不是自由发挥；第三，输出格式的要求保证了每次评审结果的结构化，方便团队成员浏览。

命令启动之后，模型会先读取这个 Markdown 文件，然后按照里面的指令执行。所以你的指令写得越"可操作"，执行效果就越稳定。别写"请认真评审"这种话，要写"先执行 xx，再分析 xx，最后按 xx 格式输出"。

3.4 子代理模板的编写要点

子代理文件的核心是角色定义和能力边界。我给你看一个代码评审子代理的例子：

--- name: code-reviewer description: 资深前端代码评审专家，专注发现逻辑缺陷与安全隐患 tools: Read, Grep, Glob model: sonnet --- 你是一位拥有十年经验的前端架构师，专注代码评审。 你的工作原则： 1. 只评审代码质量问题，不讨论业务需求是否合理 2. 从调用链的角度分析问题，不止看单个函数 3. 对每个问题给出可操作的修复建议，禁止说空话 4. 发现数字敏感信息相关代码时，额外标注安全风险 工作流程： - 先理解改动文件的调用关系 - 再逐文件审查 - 最后输出一份结构化评审报告

注意看 frontmatter 里的model字段，这是子代理一个很实用的特性。你可以让简单的子代理用速度更快的模型跑，让复杂的分析任务用更强模型跑，这样既能保证质量，又能控制成本。

agents 目录的子代理文件很容易理解：你在主对话里输入 @code-reviewer 来调用它，它会在自己独立的上下文里处理任务。子代理的 System Prompt 就是这个 Markdown 文件的内容，所以你的描述会直接影响它的表现。

4. 进阶玩法：Hooks 自动化、条件模板与团队分发

基础模板搞定之后，接下来是真正拉开体验差距的进阶内容。这里要说的不是怎么继续堆文件，而是怎么让模板体系"动起来"，以及怎么在团队里规模化落地。

4.1 用 Hooks 做自动化拦截

Hooks 是模板体系里最容易被忽视、但最能体现工程化水平的部分。它允许你在 Claude Code 的某些生命周期事件上挂脚本，比如每次工具调用之前、每次会话结束之后。

一个很典型的场景是：规范代码格式。你在 CLAUDE.md 里写了"代码必须通过 eslint"，但模型偶尔还是会忘。这时候可以加一个 hook，在 Claude Code 每次执行写完文件工具之前，自动跑一下 lint，发现问题就拦截下来提示模型修正。

--- hook-name: pre-lint-check --- 当 Claude Code 准备写入或修改 .ts/.tsx 文件时，先执行 npm run lint -- <目标文件路径>，如果 lint 失败，将错误信息反馈给主对话，要求修正后再重新写入。

Hooks 的最大价值在于"它不依赖模型自觉"。模型再聪明也有注意力漂移的时候，但 hooks 是确定性的拦截逻辑，只要挂了就一定会执行。把那些"必须做、容易忘"的操作交给 hooks，比在 CLAUDE.md 里反复强调一百遍都管用。

4.2 条件模板：同一个文件，不同分支表现

Claude Code 的模板文件支持一定的条件语义。你可以在文本里写如果你想做的事属于 A 情况，请按以下步骤……，模型会自己判断当前任务属于哪条分支。这不是编程语言里的 if-else，但对模型来说已经够用了。

比如在 CLAUDE.md 里写：

## 按场景处理 - 如果改动涉及数据库迁移：必须先生成迁移文件，并在本地数据库执行验证通过后才算完成 - 如果改动涉及第三方 API 调用：需要检查超时配置与错误重试逻辑 - 如果改动涉及对外接口：需要同步更新接口文档与类型定义

这种写法把"项目里不同领域的特殊规则"放进了同一个模板，模型会根据任务内容自动匹配。好处是你的模板文件数量不会爆炸——不需要为每个领域维护一份独立的 CLAUDE.md，一份文件里写清楚分支规则就行。

4.3 团队分发：模板怎么变成基础设施

当你的模板自己用着顺手了，接下来就是团队复制的问题。我给两种分发路径。

第一种是硬拷贝：把整套模板目录打包，通过内部文档或脚手架工具分发给成员。这种方式简单直接，但有一个问题——模板后续更新了，成员本地的不一定同步。适合小团队或者刚开始推的阶段。

第二种是模板生成器：写一个命令行工具，命名为create-claude-config之类的，运行后根据用户输入生成定制化模板。团队技术栈不同，生成器的前端参数和后端参数也不同。这个路径适合有一定工程能力的团队把模板变成公司内部的代码生成器，长期维护成本更低。

无论哪种方式，有一点逃不掉：模板必须持续迭代。我见过太多团队，模板放出去三个月没动过，项目技术栈都升级换代了，模板还在教模型用旧方案。让这个体系里有专人负责维护，定期根据成员反馈和实际使用效果更新模板内容。

5. 实操中踩过的坑与对应解法

模板这个东西，看起来就是一个 Markdown 文件，好像没什么技术含量。但真正用起来，坑多得很。我把自己在实际操作中遇到的高频问题整理成一张速查表，每个问题后面附上我验证过的解法。

5.1 上下文膨胀：模板体系的隐形杀手

这是我最想强调的一个坑。CLAUDE.md 是每轮对话都常驻的，内容越多，模型用于思考当前问题的"注意力"就越少。有人测试过，把 CLAUDE.md 写到 8000 字之后，模型对当前任务的理解和执行质量会明显下降，因为它脑子里塞满了背景资料。

我的经验值是：项目级 CLAUDE.md 控制在 300-500 行以内，超过这个量就要开始拆分。拆分的顺序是：先把操作流程类的拆到 commands，再把需要专家视角的内容拆到 agents，最后只留真正的"宪法性"内容在 CLAUDE.md 里。

5.2 "模板万能论"的误判

还有一个认知层面的坑：以为模板写得越详细，模型表现就越好。实际恰恰相反。模板的核心是给模型提供"约束和边界"，而不是替它把每一步都安排好。如果你的模板详细到"第一步打开这个文件，第二步找到那个函数"，那模型出错的概率反而更高——因为实际代码和你的描述之间总有偏差，模型会被你那些过时的细节误导。

好的模板应该管住"方向和标准"，不碰"具体路径和实现"。比如规定"改动公共接口必须同步更新调用方"，而不是规定"改了 utils/api.ts 之后要去 utils/types.ts 里加一段类型"。前者是规则，无论代码怎么演化都有效；后者是快照，代码一变就失效。

5.3 模板调试的实用套路

模板出了问题怎么排查？我的套路是三步走。第一步，单独测试：新开会话，只问模板相关的问题，确认它是否能正确执行。第二步，去掉无关变量：如果你同时改了模板和代码，模板不生效了，先恢复代码，排除干扰。第三步，用命令手动触发：自定义命令可以直接在终端里输入命令名触发，会比自然语言对话更容易暴露问题。

调试时有一个小技巧：直接在对话中让 Claude Code"总结你当前掌握的关于本项目的规范和命令"，它会从已加载的模板中把关键信息复述出来。你一眼就能看出它到底读到没读到、读对了多少。这个方法我强烈推荐，每次改完模板先跑一遍这个验证，能省下大量反复对话的调试时间。

6. 一套可直接参考的模板范例：Web 项目通用型

最后，我放一套自己在实际项目中用着很顺的模板目录结构，你可以直接参考着搭建。这套模板针对的是"TypeScript Web 全栈项目"，但改动一下技术栈关键词就能适配其他场景。

# CLAUDE.md（项目根目录） ## 项目信息 - 全栈 TypeScript 项目，前端 React + Vite，后端 Fastify，数据库 PostgreSQL - 代码目录：apps/web（前端）、apps/api（后端）、packages/shared（共享类型与工具） ## 常用命令 - 安装依赖: pnpm install - 启动全部服务: pnpm dev - 运行全部测试: pnpm test - 类型检查: pnpm typecheck - Lint: pnpm lint ## 开发规范 - 所有跨端共享类型放在 packages/shared/src - 错误处理使用统一 AppError 类，禁止裸 throw string - 组件目录结构遵循 feature-based 模式 - 提交信息遵循 conventional commits ## 按场景处理 - 修改数据库 schema 后：生成迁移文件并本地验证 - 新增 API 端点后：同步更新 OpenAPI 文档与前端类型 - 修改鉴权逻辑时：必须补充权限边界测试用例

# .claude/commands/review.md --- description: 对当前分支改动进行代码评审 --- 对当前分支（对比 main 分支）的改动执行评审。 流程： 1. git diff main...HEAD 拿到改动列表 2. 分析核心逻辑变更 3. 检查边界条件、错误处理、性能问题 4. 按 阻塞/重要/建议 三级输出问题清单，每个问题给出修改方案

# .claude/agents/api-designer.md --- name: api-designer description: API 设计专家，专注于设计清晰、安全、可扩展的接口 tools: Read, Grep, Glob --- 你是 API 设计专家，负责评审和设计 RESTful 接口。 工作原则： 1. 路径命名遵循 REST 资源语义，不使用动词路径 2. 对所有输入做严格的类型校验和边界验证 3. 分页参数必须包含 limit/offset，并设置上限 4. 错误响应统一使用 { code, message, details } 结构 输出要求： - 对每个端点列出请求参数、校验规则、成功与失败响应示例 - 对设计不合理处直接给出修改后的方案

这三个文件各司其职：CLAUDE.md 管全局约束，review 命令管代码评审流程，api-designer 子代理管接口设计专项任务。你从这套结构起步，根据自己项目的实际情况增删内容，会比从零开始写要快得多。

这个模板体系的扩展方向也很多。你可以加一个 /commit 命令，规定提交信息的生成规则；可以加一个测试专家子代理，专门负责补测试用例；还可以加 hooks，在写入文件时自动跑类型检查。无论怎么扩展，记住那条核心原则：模板是给模型划边界的，不是替你干活的。边界划清楚，剩下的事交给模型自己发挥，它的表现会超出你的预期。