企业官网建设流程全解析

如果你用过Claude Code，多半有过这种体验：每天开新会话，都要把项目背景、技术栈、代码约定、当前进度重新讲一遍。模型记性再好，也架不住"从零开始"这四个字。后来我从一个叫claude-code-templates的思路里找到了解法——把项目里那些反复交代的内容、反复执行的流程，全部沉淀成模板文件，让Claude Code一启动就自带上下文，一个斜杠命令就完成一次完整评审或重构。

这篇文章不是翻译官方文档，也不是模板搬运。我会从"为什么要模板化"讲起，把CLAUDE.md、斜杠命令、子代理这三种载体的用途拆开说清楚，然后直接给你一套可以落地的目录结构和完整示例，最后聊聊我实际使用中踩过的坑。无论你是刚接触Claude Code，还是已经用了一阵子觉得"每次都要重新强调规则很烦"，这篇都值得看完。

1. Claude Code模板化：告别每天重复"自我介绍"

1.1 模板到底是什么，Claude Code的"记忆"机制

Claude Code是跑在终端里的AI编程助手，它能读文件、改代码、执行命令。它的能力上限取决于两件事：模型的推理能力和它拿到的上下文质量。上下文质量就是模板要解决的问题。

Claude Code维护上下文的机制其实很朴素：

• CLAUDE.md：放在项目根目录的记忆文件，每次会话启动时自动加载。相当于给AI发了一份"入职手册"。
• 斜杠命令：以/开头的自定义指令，本质上是存放特定提示词的Markdown文件。
• 子代理：拥有独立系统提示词的专职Agent，可以按需调用，相当于给AI配了几个不同工种的同事。
• 挂钩：在特定事件（如文件写入、命令执行）时自动触发的脚本，我后文会提。

这四样东西合在一起，就是"模板"。模板的作用不是教模型写代码，而是把那些不变的部分——项目规则、流程标准、角色设定、工具偏好——固化下来，让每次会话都不必重新解释。

你可以把CLAUDE.md理解成新员工入职时拿到的那本员工手册。没有手册的公司，新人每天都要追着老同事问"咱们代码怎么组织""测试怎么跑""提交信息怎么写"。有了手册，这些问题就有了标准答案，而且不会因为今天带你的老同事心情不好就有两种说法。

1.2 为什么说模板是团队协作效率的分水岭

我先说一个反直觉的结论：模板对个人开发者比对团队更有价值，但模板化对团队协作的影响更大。

个人场景里，模板帮你省的是"解释成本"。你一个人维护三个项目，每项目的技术栈不同、构建命令不同、代码风格不同。没有模板时，切项目如同失忆；有了模板，Claude Code在每个项目里都自动知道该用什么姿势干活。

团队场景里，模板省的是"对齐成本"。代码评审标准、测试覆盖率要求、提交信息规范、目录组织约定，这些如果只存在于某位资深同事的脑子里，那AI永远学不会，新人也很难接上。把它们写进模板，等于把隐性知识变成显性资产。任何一个成员、任何一次AI会话，拿到的都是同一套规则。

另一个容易忽略的价值是稳定复现。人的口头交代有歧义，今天说"代码要写注释"，明天可能变成"核心逻辑写注释就行"。模板里写清楚什么场景注释、注释写到什么程度，AI输出就不会飘。

所以我的建议很直接：哪怕你只是一个人开发，也值得花半小时把项目规则模板化。这笔投入的回报不是一次性的，而是每一次会话都在复利。

2. 模板的三个核心载体：CLAUDE.md、斜杠命令与子代理

2.1 CLAUDE.md：项目的"长期记忆库"

CLAUDE.md放在项目根目录，文件名叫CLAUDE.md。Claude Code启动时会自动读取它，并且在整个会话期间持续参考。它的核心价值是回答四个问题：

1. 这个项目是干什么的？核心模块有哪些？
2. 技术栈和构建/测试命令是什么？
3. 代码组织有哪些约定和禁忌？
4. 当前进度、已知问题、下一步计划是什么？

CLAUDE.md不是越详细越好。写得像流水账，模型反而抓不住重点。我见过有人把五百行的CLAUDE.md丢进去，结果AI每次决策都要从一堆无关信息里筛选，反而拖慢了速度。

有效的CLAUDE.md应该按"优先级"排列。重要的、容易违反的规则放前面，背景介绍放后面。它甚至可以引用其他文件，比如在CLAUDE.md里写@docs/architecture.md，让Claude Code去读取那份详细设计文档。这样主文件保持精简，细节留在专门文档里。

CLAUDE.md还要定期维护。项目重构后目录变了，命令改了，如果不更新记忆文件，AI就会拿着过期的地图找路。我习惯每两周花十分钟过一遍CLAUDE.md，把过时内容删掉、把新约定补进去。

2.2 斜杠命令：把常用流程固化成一键动作

斜杠命令是模板体系里最"轻"也最好上手的一环。它的实体是一个Markdown文件，文件名就是命令名。放在项目里的.claude/commands/目录下，或者放在用户目录~/.claude/commands/下全局生效。

举个例子，你写了一个review.md，那在会话里输入/review就会触发这个命令。命令文本开头有一段YAML格式的头信息，用来声明描述和参数提示：

--- description: 对指定文件或改动范围做代码评审 argument-hint: [可选] 文件路径、提交范围或具体关注点 ---

这里的description很重要，Claude Code会用它来理解什么时候该推荐这个命令。argument-hint告诉用户这个命令可以带什么参数，比如/review src/utils/format.ts。

斜杠命令的实际效果，是把一段固定的高质量指令封装成快捷方式。它适合放那些"每次做都希望按同一套标准执行"的任务：代码评审、测试补全、提交信息生成、CHANGELOG更新、依赖升级前检查。因为它们流程固定、标准统一，写成模板之后每次输出水平都能对齐到最好那次。

2.3 子代理：为不同任务打造专职助手

如果说斜杠命令是"流程模板"，子代理就是"角色模板"。子代理的实体也是Markdown文件，放在.claude/agents/目录下。文件头部同样有YAML头信息，声明名称、描述、可用工具，正文是它的系统提示词。

子代理和当前会话是"两套提示词"。你在主会话里对Claude Code说的所有话，子代理不一定知道，它只看自己的系统提示词和你传入的任务内容。这带来一个好处：每个子代理可以有自己的领域聚焦、自己的输出格式、自己的约束条件，不会因为主会话的上下文太长而"人格漂移"。

我常用的子代理有这么几个：

• reviewer：只做代码评审，输出按"问题严重程度"分级，附带修改建议。
• test-writer：专职补测试，收到功能描述后生成测试用例，遵循项目的测试风格。
• refactor-helper：专做重构，核心约束是"行为不变、结构变好"，禁止顺手加需求。

子代理适合的场景是"任务边界清晰、专业性强、需要反复用"的活儿。跟斜杠命令相比，它更像是长期雇佣的专职顾问，而斜杠命令更像一套标准作业流程。

3. 从零搭建一套模板库：目录结构与可复用的示例

3.1 推荐目录结构：用户级与项目级分开管理

模板管理的核心原则只有一条：通用的放全局，专用的放项目。全局模板放~/.claude/下，项目模板放项目根目录的.claude/下。这样换电脑、换项目都不会丢。

我推荐的完整目录结构长这样：

~/.claude/ ├── CLAUDE.md # 通用个人偏好（比如：不要用emoji写注释） ├── commands/ │ ├── review.md # 通用代码评审 │ ├── commit.md # 生成提交信息 │ └── explain.md # 解释代码逻辑 ├── agents/ │ ├── reviewer.md │ └── test-writer.md └── skills/ # 可选：技能目录 项目根目录/ ├── CLAUDE.md # 项目专属记忆 └── .claude/ ├── commands/ │ └── deploy-check.md # 仅本项目使用的命令 └── agents/ └── schema-migrator.md # 本项目专用的架构助手

这套结构的好处是分层清晰。换新项目时，全局模板自动生效，项目模板单独沉淀这个项目的特殊规则。目录结构本身也是模板的一部分——换了个项目，你照样知道该往哪里放文件。

3.2 一个能直接用的CLAUDE.md模板

直接上一份我打磨过多次的CLAUDE.md模板。它不长，但覆盖了高频需要的信息：

# 项目信息 - 项目定位：内部数据看板，面向运营团队 - 技术栈：TypeScript + React + Vite + Vitest - 包管理：pnpm # 目录约定 - src/components：通用UI组件，按组件名建目录 - src/features：业务模块，按功能划分 - src/utils：纯函数工具，禁止引入React依赖 # 代码规则 - 组件使用函数式写法，hooks优先 - 所有公共函数必须有JSDoc注释，内部函数不强制 - 禁止在业务代码里直接写`console.log`，统一用logger模块 # 常用命令 - 安装依赖：pnpm install - 开发服务：pnpm dev - 单元测试：pnpm test - 类型检查：pnpm typecheck # 当前状态 - 正在做：报表导出功能（feat/export分支） - 已知问题：图表库在Safari下渲染偏移，待查

模板的关键不是字段多，而是每条信息都是Claude Code实际用得上的"操作约束"。比如"禁止在业务代码里直接写console.log"，这就是一条可执行规则，AI在生成代码时会主动避免。而"正在做报表导出功能"这种进度信息，能让AI在改代码前先想想是不是跟当前分支有关。

我给这份模板定了一个原则：每一条规则都必须能直接决定一次代码行为的"是或否"。那些模棱两可的、纯粹背景介绍的内容，要么删掉，要么放到被引用的子文档里。

3.3 两个高频斜杠命令：/review与/cleanup

先看/review命令。它的完整Markdown文件长这样：

--- description: 对代码改动进行系统评审，输出分级问题清单 argument-hint: 文件路径、commit范围或"最近改动" --- 你是一名资深代码评审专家。请按以下流程评审： 1. 先确认评审范围。如果用户提供了文件路径或commit范围，直接使用； 否则查看git status/diff判断最近改动。 2. 阅读改动代码及上下文，重点关注： - 逻辑正确性：边界条件、空值处理、异步竞态 - 可维护性：命名是否准确、函数是否过长、职责是否单一 - 项目规则：检查是否违反CLAUDE.md中的代码约定 - 安全隐患：输入校验、敏感信息泄露、权限问题 3. 输出评审结论，按以下格式组织： - 🔴 严重问题：必须修复，说明原因和修复方向 - 🟡 建议改进：不阻塞合并，但要关注 - 🟢 良好实践：值得肯定的写法 4. 最后给出总体结论：通过 / 需修改 / 大改后重审 注意：只做评审，不要直接修改代码。

这份命令文件的核心是"流程固定+输出格式固定"。不管用户丢什么代码进来，Claude Code都会按这个结构走，不会因为对话跑偏就漏了某一项检查。argument-hint里写了三种常见输入方式，用户一看就知道怎么用，不用翻帮助。

再看/cleanup，这个命令适合代码写多了之后做一轮收尾清理：

--- description: 检查代码中的遗留调试语句、无用导入和临时文件 argument-hint: [可选] 目录或文件范围 --- 执行代码清理检查： 1. 在指定范围（默认整个src目录）内查找： - 调试残留：console.log、debugger、TODO/FIXME注释 - 无用导入：未被引用的import语句 - 死代码：声明但从未调用的函数或变量 2. 对每一项发现，先说明位置和内容，再给出处理建议。 3. 如果项目规则允许自动清理（查看CLAUDE.md），直接询问用户是否执行修改。 4. 若用户确认，请一步一处修改，每处改动前简单说明意图。 输出格式不限，但必须列出完整的清理清单，标注"已处理/待确认"。

这两个命令的写法展示了同一件事：模板文件的本质是"把高质量的一次执行，变成可复用的标准动作"。你不需要每次都重新想"评审该看哪些方面"，模板替你记住了。

4. 高频场景实战：评审、测试和重构的模板写法

4.1 代码评审模板的完整流程设计

评审模板看起来简单，写起来有门道。我见过不少失败案例，模板写得又长又空，比如"请仔细检查代码质量"这种话，模型读了等于没读。真正有效的评审模板，必须满足三个条件：

第一，有明确的角色设定。"资深代码评审专家"这句话看起来虚，但它能触发模型调用更严谨的思维模式，跟"帮我看看代码"生成的输出质量完全不是一个级别。

第二，有可执行的检查清单。不要写"检查代码质量"，要写"检查边界条件、空值处理、异步竞态"。检查项越具体，模型越不容易遗漏。

第三，有固定的输出格式。分级清单（严重/建议/良好）让结果一目了然。如果模型自由发挥，它可能写一堆散文，开发者还得自己提炼重点。

我实际用下来的一个细节是：评审模板的最后一定要加一句"只做评审，不要直接修改代码"。不加这句话，Claude Code经常审着审着就顺手改起来了，结果评审报告和修改混在一起，反而没法用它做基线。

/review模板里的git上下文策略也很关键。大多数时候用户懒得指定路径，直接说"看一下我改了什么"。所以模板里写清楚"先查git status/diff判断范围"，能省掉一轮来回沟通。这是落地时最容易忽略的交互设计：模板不只是约束AI，也是在引导用户用更少的输入获得结果。

4.2 测试生成与补全模板的约束技巧

测试类模板比评审类模板更难写，难在"约束"两个字。没有约束的测试模板，生成的测试要么只测happy path，要么为了覆盖率写出毫无价值的断言。我用的test-writer子代理长这样：

--- name: test-writer description: 为指定函数或模块生成单元测试 tools: Read, Write, Edit, Grep --- 你是一名测试工程师，擅长编写高价值单元测试。目标是让测试真正能防止回归，而不是凑覆盖率。 工作步骤： 1. 先阅读目标源码及其依赖，确认函数输入输出和副作用。 2. 分析需要覆盖的用例清单： - 正常输入与期望输出 - 边界值：空值、超长、负数、最大值/最小值 - 异常输入：非法类型、缺失字段、抛错路径 - 副作用：是否修改外部状态、是否引起接口调用 3. 按项目测试风格（查看CLAUDE.md中的测试约定）编写测试。 4. 每个测试用例必须有明确的意图注释，禁止"为了断言而断言"。 硬性约束： - 不修改被测试的源码文件，只添加测试文件 - 不生成依赖外部服务的集成测试 - 测试命名遵循 describe/it 的结构，语义要完整

这个模板的精华在于第2步的"用例清单"。它逼着模型在写代码之前先想清楚"这个函数到底有哪些边界情况"，而不是上来就写一个expect(fn(1)).toBe(2)。实测中，这样生成的测试平均失败率更低，因为边界情况想得全。

还有一个细节是tools限制。我特意只给了读、写、编辑、搜索类工具，没给执行命令的工具。原因是我遇到过测试模板顺手改了源码、甚至去跑了npm install的情况。限制工具集是子代理模板最有效的行为约束手段，比在提示词里说十遍"不要乱改代码"都管用。

4.3 重构类模板如何避免"越改越糟"

重构是高风险动作，AI尤其容易在重构过程中"顺手改需求"。上一版逻辑没变，接口参数变了，调用方全断。所以重构模板的写法跟评审、测试完全不一样，核心是订规矩：

--- description: 在保持行为不变的前提下，对目标代码进行结构优化 argument-hint: 目标文件路径或函数名 --- 你是重构助手。本次重构的路线是：结构变化，行为不变。 开工前： 1. 阅读目标代码及所有调用方，明确当前对外行为和副作用。 2. 用文字向用户复述你的重构计划，包括：拆成几个步骤、每步改什么、 如何验证行为未变。得到确认后再动手。 执行中： - 一次只做一个原子改动，改完立刻检查该文件是否可编译 - 禁止改变函数签名、返回结构、外部可见的变量名 - 禁止在重构过程中修正无关的bug或风格问题 - 把重构中发现的问题记录在给用户的清单里，不擅自处理 收尾确认： 1. 运行项目类型检查和测试命令（见CLAUDE.md） 2. 向用户汇报：改动文件清单、行为保持的证据、遗留问题

模板里"开工前先复述计划"这一条，我一开始觉得多余，后来发现它是最值钱的。为什么？因为模型经常理解错重构目标。你让它"把这个函数拆小"，它可能理解成"重写这个函数"，导致行为漂移。让它先复述计划，等于加了一道人类确认闸门，绝大多数误操作在这个环节就被拦住了。

"禁止在重构过程中修正无关bug"这条同样重要。模型看到旁边有段代码不顺眼，常常顺手就改了。这在人身上叫"镀金"，在AI身上叫"越权"，都会让评审diff变得不可控。把这条写进模板，重构之后的变更集就干净得多。

5. 使用模板踩过的坑与我的配置习惯

5.1 模板膨胀与指令冲突：两条常见翻车现场

模板用久了，最先遇到的问题是膨胀。一开始写了10条规则，后来加到40条，结果AI执行时每条都想照顾，反而频繁出错。典型表现是：你在CLAUDE.md里写了"禁止使用any类型"，又写了"与第三方库交互时可放宽类型约束"，这两条放在一起，模型就会在不同文件里做出摇摆决策，今天放宽、明天不放宽。

我的解决办法是给规则分优先级。CLAUDE.md里只保留"绝不可违反"的硬规则，软规则挪到子文档里。硬规则通常不超过8条，多了就必然冲突。子文档用@引用加载，需要时生效，不需要时不影响主要决策。

另一个坑是命令与命令之间的上下文污染。比如你先用/review让模型分析了某段代码，紧接着执行/cleanup，cleanup命令会沿用review时建立的上下文，可能把"评审时提到的疑点"当成"必须清理的问题"。这个问题的根源是斜杠命令不隔离上下文，它们共享主会话的记忆。

我的对策是：命令文件里明确写上"忽略此前讨论中与本次任务无关的内容，一切以CLAUDE.md和你读到的代码为准"。这句话看起来很傻，但实测能显著减少跨命令污染。模板写久了你就明白，约束AI和约束人一样，规则必须明确到不需要它"猜"。

5.2 变量与上下文的边界：别让模板自作主张

模板里最危险的，是让AI"根据上下文推断"某些关键信息。比如命令里写"判断当前分支是否为发布分支，若是则执行发布检查"。问题是AI对"发布分支"的理解可能跟你不一样——已经把release/v2合并到了main，它却认为main不是发布分支，跳过了一整套检查。

所以我在模板里立了一条规矩：凡是影响执行结果的判断，必须向用户确认，不允许自作主张。模板会把需要确认的点显式列出来，比如"请确认当前操作是否针对生产环境"。

这个设计既是对AI的约束，也是对用户的保护。它在风险和效率之间选了安全，代价是多一轮对话，但对高风险操作来说，值。

5.3 模板的分层回收：建立个人"模板库"的迭代流程

最后聊聊维护。模板是活的东西，不是写完就完。我的迭代流程很固定：

1. 记录：每次会话里发现AI反复犯同一个错，就记一条"该不该写进模板"。
2. 归类：这条规则是通用的还是本项目专用的？通用的进~/.claude/，专用的进项目.claude/。
3. 去重：如果已有类似规则，检查冲突，合并新规则，删除旧规则里被覆盖的部分。
4. 验证：改完模板后，开一个新会话专门验证一次这条规则是否真的被遵守。

这个流程每两到三周做一次。实测下来，模板库的规模会趋于稳定，因为新规则会挤掉旧规则，而不是无限堆叠。

还有一个维护技巧：给CLAUDE.md加个"最后更新"标记。我见过有人在展开模板评审时，发现项目的测试命令已经从npm test换成了pnpm test，CLAUDE.md里还是旧的。模板一旦和现实脱节，AI操作就会出错，而且错得很隐蔽——命令跑不起来，它还以为是自己理解错了。定期更新模板，跟定期更新依赖一样，是必须的维护成本。

我个人的体会是：模板这套东西，投入产出比极高，但前提是你真把它当"工程资产"来维护，而不是写一次就丢。项目在变，AI在升级，模板也得跟着迭代。等你看到新成员第一次开会话就能说出"这个项目是干嘛的、代码规矩是什么、当前分支在做什么"的时候，你会觉得半小时写这些模板完全值得。