企业官网建设流程全解析

用了半年多 Claude Code 之后，我最大的感受是：这工具真正拉开差距的，不是谁会问花哨的问题，而是谁拥有一套自己的模板体系。所谓 claude-code-templates，说白了就是把你日常反复交代给 AI 的那些话——项目背景、技术约束、验收标准、输出格式——沉淀成结构化的模板文件，让 Claude Code 每次开工都站在同一个基准线上。今天这篇就把我实操下来的完整方案拆给你看，从模板为什么好用，到具体怎么写、怎么落地、怎么避坑，一次说透。

1. 为什么要给 Claude Code 做模板体系

1.1 从“每次重新交代”到“一次配置处处复用”

先聊一个特别常见的场景：一个新项目建好目录，你打开终端敲下 Claude Code，准备让它帮你写第一个模块。你噼里啪啦打了一段话，说项目用什么框架、数据库怎么连、代码风格怎么定、输出的时候要注意什么。AI 听完确实照做了，但问题在于——这些话你明天还要说一遍，换个文件夹还要再说一遍，来了个新同事协作，他也要再敲一遍。

我最初就是这么干的，后来发现效率瓶颈根本不在 AI 的生成能力，而在我的“沟通成本”。每天光是把上下文交给工具就得花掉十几分钟，而且每次口头描述多多少少有出入，今天忘了说约束条件，明天忘了提代码风格，生成的代码五花八门，靠人肉纠偏的成本特别高。

模板体系的本质，就是把“怎么和 AI 协作”这件事本身工程化。你不再靠临场发挥描述需求，而是把规则、约束、偏好、流程全部写进一组模板文件，让 Claude Code 每次启动都先读取这些上下文。这就好比你去一家餐厅，老顾客不用重新报忌口，服务员早就把你的偏好记在档案里了。

1.2 模板解决了哪些具体痛点

我归纳下来，模板体系至少解决四类痛点，这也是我为什么强烈建议团队和个人都搞一套。

第一类是一致性缺失。同一个项目里，今天让 AI 生成接口用的是一种命名风格，明天换了表达方式，生成结果就可能对不上。模板把风格、规范固定下来，生成结果不会跑偏。

第二类是上下文浪费。Claude Code 的对话窗口是有限的，你花大段文字描述背景，留给真正任务的空间就少了。模板相当于把背景知识压缩成引用文件，对话里只需一句话，AI 自己去读模板内容，四两拨千斤。

第三类是验收标准模糊。很多人让 AI 写代码只给一句“帮我写个登录功能”，AI 写完你觉得差得远，来回拉扯好几轮。模板里预先写清楚验收标准，AI 在动手之前就知道什么叫“完成”，返工率直线下降。

第四类是协作门槛高。团队里每个人和 AI 的沟通风格不一样，有人细致有人粗糙，最后代码质量完全取决于个人发挥。有了统一模板，新人上手也能立刻进入状态，经验是沉淀在文件里的，不依赖某个人的表达能力。

1.3 模板体系里都应该放什么

刚接触这个概念的读者，最容易犯的错是把“模板”等同于“一段提示词”。其实完整的模板体系分四层：

第一层是项目指令文件，也就是 CLAUDE.md，描述这个项目的技术栈、目录结构、常用命令、代码规范。这一层是背景知识层，AI 每次都会主动读取。

第二层是任务模板集合，针对高频任务拆分出来的结构化提示词，比如生成新功能、重构旧代码、写单元测试、做代码审查、补技术文档。这一层解决的是“具体怎么干”的问题。

第三层是规则与边界，告诉 AI 哪些动作被禁止、哪些场景需要先问、输出格式必须是什么。这一层是行为约束层，用来卡住 AI 的发挥上限。

第四层是示例与参考，比如你希望 AI 输出的代码风格，可以放一段示例片段；你希望技术文档的格式，可以放一个参考样例。AI 最擅长的就是模仿，给它一个好样本，比描述十句“我想要什么风格”都管用。

这四层结构，就是我整个 claude-code-templates 体系的骨架。下面我在每一层都展开讲讲实操细节和踩坑记录。

2. 核心配置的搭建：CLAUDE.md 与规则边界

2.1 CLAUDE.md 的结构设计

CLAUDE.md 是 Claude Code 的项目级指令文件，等同于是 AI 进入项目后默认阅读的“工作手册”。它的结构设计直接决定了 AI 对项目的理解深度，我用下来觉得最稳妥的模板结构是这样：

# 项目名称：xxxx ## 项目简介 用三四句话说明系统是做什么的、给谁用、核心业务流程。 ## 技术栈 - 语言：TypeScript 5.x - 前端框架：React 18 + Vite - 后端框架：Node.js + Express + Prisma - 数据库：PostgreSQL 16 - 测试框架：Vitest - 包管理器：pnpm ## 目录结构 src/ api/ # 接口层 components/ # UI 组件 pages/ # 页面 services/ # 业务逻辑 utils/ # 工具函数 ## 常用命令 - 启动开发服务：pnpm dev - 运行测试：pnpm test - 类型检查：pnpm typecheck - 代码检查：pnpm lint ## 代码规范 - 函数命名：camelCase - 组件命名：PascalCase - 组件库：项目内统一使用 shadcn/ui - 接口请求：统一使用 src/services/ 下的封装 - 提交信息：遵循 Conventional Commits ## 特殊约定 - 日期处理统一使用 dayjs，不要引入 moment - 金额使用整数分存储，禁止浮点数 - 所有对外接口必须写明错误码

这一份文件看着简单，但每个模块都有讲究。项目简介不是为了给 AI 阅读消遣用的，而是为了让它在做设计决策时有全局观，比如新增一个模块时知道应该放在哪个业务域下面。技术栈是给 AI 划定工具边界，防止它凭空引入你没用过的新依赖。目录结构和代码规范是最大程度减少后续人工整改成本。

2.2 全局指令与项目指令怎么分工

很多人以为 CLAUDE.md 只能放在项目根目录，其实 Claude Code 还支持全局层的配置。我习惯在自己的用户目录下维护一个全局的规则文件，专门放那些跨项目通用的行为约定，而项目根目录的 CLAUDE.md 只放当前项目专属的内容。

举几个典型的全局规则例子：

• 所有代码注释必须说明“为什么”而不是“是什么”
• 生成代码前先确认需求理解，复杂任务必须先列实现方案再动手
• 不要修改与当前任务无关的代码
• 涉及删除操作时必须先展示将删除的文件清单
• 输出内容长度适中，不要过度设计

项目级 CLAUDE.md 则只放技术栈、目录结构、命令这类纯本项目相关的信息。两层分开的好处特别明显：换新项目时全局规则依然生效，而项目级文件可以随手替换。如果全部堆在全局文件里，这类规则在别的项目里就会变成噪音干扰，AI 读进去一堆无关信息，反而影响判断。

2.3 写规则时最容易踩的坑

我自己踩过最大的坑，是把规则写得太空。比如“请写出优雅的代码”，AI 确实不知道怎么执行，因为它对“优雅”没有测量标准。后来我把这类模糊描述全部改成可验证的具体约束，效果天差地别：

• 错误写法：代码要可读、易维护
• 正确写法：单个函数不超过 40 行；逻辑分支超过三层必须抽取为独立函数；工具函数不得引用业务模块

规则的颗粒度要控制好，不是越细越好。我见过有人列了七八十条规范，AI 每次都要消化，反而冲淡了关键指令的权重。我的经验是：全局规则控制在 10 条以内，项目规范控制在 15 条以内，只保留那些违反后会立刻产生问题的硬约束，风格喜好类的软约束用示例来传达，效果比用规则描述好得多。

3. 高频任务模板拆解

3.1 代码生成模板

任务模板是 claude-code-templates 体系里复用频率最高的部分。以代码生成为例，我日常用的模板长这样，所有变量用大括号标记：

背景：{功能背景，来自 PRD 或需求文档} 目标：{本次要实现的功能点} 技术约束： - 必须沿用 {指定模块或既有实现方式} - 遵循项目 CLAUDE.md 中的代码规范 - 接口定义需输出到 {指定文件} 验收标准： 1. {功能行为标准} 2. {边界情况处理标准} 3. 相关单元测试通过 输出要求： - 给出修改涉及的文件清单和说明 - 关键逻辑处附上注释

用这个模板和随便扔一句话的区别，在于它强制 AI 在动手前对齐三件事：做了什么、怎么做、怎么算做完。经常有人问为什么 AI 生成的代码看起来没问题但一集成就炸，绝大多数情况不是代码写错了，而是需求理解偏了。模板里的验收标准就是校准器。

3.2 重构模板

重构是一个非常值得单独沉淀模板的任务类型。因为它和功能开发的约束完全不同：重构不允许改变外部行为，但又要保证代码变好。我把重构模板固定成下面这个结构：

当前问题：{具体的代码痛点，比如函数过长、职责混乱、重复代码} 重构目标：{期望达到的状态，比如拆分职责、消除重复} 影响范围：{哪些模块会被触碰，尽量缩小} 禁止事项：{不能改变哪些行为，不能改动哪些公共接口} 验证方式： - 重构后全部现有测试必须通过 - {额外补充的验证手段} 输出要求： - 分步骤说明重构过程，每步独立可验证 - 明确哪些文件只做“搬动”未做逻辑修改

这个模板的核心价值在“禁止事项”和“验证方式”这两行。如果没有这两行，AI 很可能会在重构时顺手优化业务逻辑，看似好心，实则制造了难以排查的隐性 bug。加上这两条约束之后，重构的可控性明显上升，我后来不管是自己重构还是让 AI 重构，都严格遵循不混入功能修改的原则。

3.3 测试模板

写测试的任务也有模板，而且我强烈建议用一套非常严格的输出结构。测试模板我通常这样定义：

被测对象：{模块或函数名} 测试目标：{覆盖哪些行为} 边界情况：{空值、异常输入、超时、边界值} 参考用例风格：{项目内既有的测试文件示例} 输出要求： - 使用项目既有测试框架，不要新增依赖 - 测试描述使用 xx 场景下应 yy 的句式 - 每个测试文件开头注释说明该文件覆盖的模块 - 运行全部测试并给出结果摘要

这套模板特别有用的一点是“参考用例风格”字段。我见过最好的实践是把一个优秀的测试文件路径直接写进去，AI 会模仿已有文件的命名习惯、断言风格、mock 方式。比你在模板里写“请写规范的单测”强一百倍。

3.4 代码审查模板

让 AI 做代码审查，其实是个被低估的场景。我自己写完代码经常让 AI 先过一遍再合并，审查模板长这样：

审查范围：{分支或文件范围，常见写法是 git diff 与 xxx 的对比} 审查重点： - 逻辑正确性：边界条件和异常路径是否有遗漏 - 安全风险：输入校验、注入、敏感信息泄露 - 性能隐患：不必要的循环、重复请求、复杂度爆炸 - 与既有代码风格的一致性 输出要求： - 按“严重程度”排序，分为必须修复/建议调整/可选优化三档 - 每条问题给出具体文件行号和修复建议 - 不修改代码，只输出审查报告

在“审查重点”上我吃过亏。如果只让 AI “审查一下代码”，它经常会流于表面，指出一些注释风格、命名问题这类无关痛痒的点。把审查重点明确写出来，它才会真正去抠边界条件和异常路径这类隐藏 bug 高发地带。合并前的 AI 审查已经帮我挡掉了好几个线上事故级别的 bug。

3.5 文档模板

最后是文档模板。让 AI 写技术文档、API 文档、变更记录，用模板约束比口头指引要稳得多。我的文档模板结构如下：

文档对象：{模块、接口、或功能} 读者对象：{使用者是谁，决定语气和术语控制} 文档结构： 1. 概述 2. 安装/接入方式 3. 快速开始示例 4. API/配置说明 5. 常见问题 输出要求： - 示例代码必须可直接运行 - 参数表使用表格呈现，包含参数名、类型、必填、默认值、说明 - 禁止粘贴与文档无关的既有代码完整文件

每份文档都从“读者对象”这个字段开始。我发现如果 AI 知道读者是刚入门的新人，它的措辞会自动调整为解释性语气；如果读者是资深工程师，它就会直接给结论、跳过大段铺垫。这个前置设定能把文档的调性校准到一个合理范围。

4. 从零实操：搭建一套可复用的模板仓库

4.1 仓库目录结构怎么设计

理论说完了，现在给你一套可以直接上手抄的目录结构。我自己维护的模板仓库叫 claude-code-templates，目录长这样：

claude-code-templates/ ├── global/ │ ├── CLAUDE.md # 全局规则，放到 ~/.claude/ │ └── rules/ │ └── code-review.md # 审查细则 ├── project/ │ ├── CLAUDE.md # 项目模板，复制到新项目根目录 │ └── samples/ │ ├── api-service.ts # API 层示例 │ └── test-example.ts # 测试示例 ├── tasks/ │ ├── generate.md # 代码生成模板 │ ├── refactor.md # 重构模板 │ ├── test.md # 测试模板 │ ├── review.md # 代码审查模板 │ └── docs.md # 文档模板 └── scripts/ ├── init-project.sh # 一键初始化新项目模板 └── update-global.sh # 同步全局配置

这个结构的分工很清楚：global 管通用规则，project 管项目配置，tasks 管任务模板，scripts 管自动化脚本。tasks 目录下的每个 md 文件，就是你在对话里可以直接粘贴或者让 AI 去读取的任务提示词。

4.2 写模板时变量和格式的约定

模板里的变量我统一用大括号加英文命名，比如 {功能背景}、{影响范围}。这样做的原因是和很多提示词工程的通用规范一致，AI 容易识别出这是一个待填充的位置。同时我会在模板文件头部加一行使用说明：

使用方法：将本模板中的 {变量} 替换为实际内容后，粘贴给 Claude Code， 或直接让 Claude Code 阅读本文件并指认变量对应的真实信息。

这个约定非常重要。我一开始写模板时，变量名和普通文字混在一起，AI 经常把“请实现如下功能”这种模板话术也当成指令的一部分去执行。后来把变量格式统一、在文件头写明使用方法，这个问题基本消失了。

4.3 一键初始化新项目

模板仓库配了一个初始化脚本，作用是把 project/CLAUDE.md 和 sample 文件复制到新项目目录，并按项目信息替换变量。脚本核心逻辑是用 sed 做变量替换，或者更稳妥一点，用一个简单的交互式脚本提示用户输入项目名、技术栈、包管理器，然后生成对应的 CLAUDE.md。

我实际用的脚本逻辑不一定写得有多复杂，核心流程就三步：读入项目名和技术栈参数、替换模板中的占位符、把生成的文件落到当前目录。如果你是初学者，不用追求脚本的通用性，哪怕先手动复制模板再微调也可以。但跑通一次自动初始化流程之后，你就不想再回头手动敲了，因为新建项目时最烦的就是把同一套说明反复输入给 AI，脚本能省掉这五分钟。

4.4 模板仓库也要做版本管理

模板不是写完就一劳永逸的，它会随着你的使用持续演进。我现在给模板仓库建了 git 管理，每次对模板的修改都走提交记录，并且约定了一句话的提交说明，比如“重构模板增加禁止事项字段”、“测试模板补充 mock 规则”。这样做有两个好处。

第一个好处是，当你发现某个模板版本生成的代码质量下降时，可以快速回滚到之前的版本对照排查。第二个好处是，模板修改会带动项目行为变化，有了 git 历史，你就能把“某次模板变更”和“生成结果的变化”关联起来，做归因分析。

我还会定期做一次模板评审，周期大概是每两周到一个月。评审时重点看几件事：哪些模板字段实际使用中从来没人填、哪些规则 AI 反复违背、哪些输出要求和实际项目需要不符。没有用到的字段果断删掉，规则被违背就改写成更明确的表述。模板体系的维护和代码维护是一个道理，不迭代就会腐化。

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

5.1 模板太长导致关键指令失效

这是我最早遇到的问题，也是很多人和我反馈最多的问题。模板写得太长，AI 虽然全读进去了，但注意力的权重会被稀释，结果最关键的约束反而没被执行。

排查方法很简单：让 AI 复述你给它的指令，看看它记住了哪些、忽略了哪些。更直接的办法是精简模板，把规则按“必须遵守”和“仅供参考”分层。我的个人标准是一份任务模板不超过 35 行，超过就要砍掉不重要的描述或者移到单独的参考文件里。如果确实需要提供大量背景知识，那就在模板里写一句“背景细节参见 docs/xxx.md”，让 AI 按需读取，而不是一次性把全部内容塞进上下文。

5.2 AI 不遵守模板里的输出格式

明明模板写了“输出按清单列举”，AI 却长篇大论分析给你看。这类问题通常不是模板写得不清楚，而是模板同时要求了太多事情，AI 在权衡时把“分析过程”当作优先级更高的需求。

我的对策是把“输出要求”这个字段放在任务模板的任何位置，优先级仅低于验收标准。并且要写成强制性的、不带商量余地的句式：

输出要求（必须严格遵守）： 1. 结论先行，再给依据 2. 只输出与任务直接相关的内容 3. 不要输出模板本身，不要解释模板参数

这个“不要输出模板本身”的说明是个小细节，但特别有用。如果某个模板里变量没替换干净，AI 可能会把整个模板结构原样输出出来，加了这个说明能显著减少这类情况。我后来所有任务模板都在输出要求里带上这句，省了不少清理的力气。

5.3 团队协作时模板互相覆盖

项目级 CLAUDE.md 放在根目录，团队的每个人都会读到同一份，这本来是好事，但也带来一个问题：如果某位成员很能折腾，把全局规则塞进了项目文件，其他人下次再启动时上下文就变了，生成行为的差异会让团队困惑。

我建议团队里的项目模板改动走代码评审，和普通代码变更一样。谁要加规则，先提出来说明理由，确认不和其他规则冲突再合入。同时全局规则和项目规则分开维护，前者更关注通用的行为边界，后者只描述技术事实。这样即使有成员想自定义偏好，也只影响他自己的全局配置，不会波及整个项目。

我见过一些团队因为 AI 模板吵起来，本质原因是规则成了个人风格的角力场。所以模板里尽量减少主观偏好表述，多写可验证的技术约束，就事论事，冲突自然变少。

5.4 模板生成的结果不符合预期，如何定位原因

当 AI 输出结果开始不对劲时，不要急着改模板，先把原因定位清楚。我通常按三步排查：

第一步，确认模板是否真的被读取了。可以问 AI“你是否读取了 CLAUDE.md？里面技术栈是什么？”，它能准确答出来说明读取链路正常。

第二步，确认模板里的变量是否替换正确。很多时候问题出在变量没替换干净，AI 拿着占位符发挥，出来的东西自然不对。

第三步，确认流程上是否被后续对话干扰。模板生效只是开工时的状态，如果后面你用了几轮对话不断补充新要求，AI 可能会把模板中的旧约束和新要求冲突的部分丢弃。这个时候不是模板的问题，而是对话上下文漂移了，回到模板重新建立上下文即可。

排查思路搞清楚之后，再决定是改模板、改变量填充方式，还是改自己的沟通习惯。这个顺序反过来，很容易在模板上瞎改一通，越改越乱还找不到根因。

5.5 给模板加“决策记录”字段

最后分享一个小技巧。我所有任务模板的输出要求里都会带上一个可选字段：“若在实现过程中做出和上下文默认方案不同的决策，请说明原因”。这个字段单独看没啥，但它的作用是把 AI 的隐性判断逼出来。

比如生成代码时，AI 原本可以按模板的技术栈来写，但它突然决定引入一个新的库，通常不会主动告诉你。加了这行字段之后，它会把这个决策和原因交代出来，你就能及时发现它是不是跑偏了。这相当于给 AI 加了一个“自我解释”的钩子，在问题发生前就给足了预警信号。我用这个技巧抓到过好几次潜在风险，比事后看代码高效得多。

模板体系的收益是随着使用时间累积的。刚开始搭建的时候，你可能觉得花了不少功夫写规则、调格式，但只要你坚持用上一两个月，把高频任务全部沉淀下来，后面每次和 Claude Code 协作都会变成一件非常顺滑的事。我个人的体会是：模板不是给 AI 设限的枷锁，而是给双方共同的坐标系。你定好方向，它把执行细节填满，配合起来才真正省心。如果你还没开始搭自己的模板仓库，建议今天就新建一个文件夹，把上一个项目里反复交代的话写成第一版模板，迈出这一步之后，后面会越用越顺手。