企业官网建设流程全解析

我前前后后折腾 Claude Code 也有几个月了，最开始的体验说实话有点糟心：同一个项目，今天让它改个界面它能精准定位到文件，明天同样的需求它能给你把整个目录结构重新规划一遍。后来我才意识到，问题不在工具本身，而在于我从来没给过它一套稳定、可复用的行为框架。直到我把项目里沉淀出的claude-code-templates模板体系搭起来，Claude Code 才真正从"偶尔灵光乍现"变成了"稳定可用"。

这篇文章就把我这套模板体系的完整思路、文件结构、实际配置过程，以及踩过的坑一次讲清楚。无论你是刚接触 Claude Code 的新手，还是已经用了一段时间、总觉得"时灵时不灵"的老用户，这套方法论都值得你参考。涉及的命令、配置、模板写法，你都可以直接抄走改改再用。

1. 为什么 Claude Code 必须要配模板

很多人刚上手 Claude Code 时，第一反应是"这不就是个能聊天的终端工具吗"，于是直接开始对话、让它干活。几天用下来就发现不对劲：同一个项目里，Claude Code 的行为非常不稳定。

1.1 默认行为的"不可控"才是原罪

Claude Code 底层虽然是大模型，但它跑在一个真实的 shell 环境里，能读文件、能执行命令、能改代码。这在带来强大能力的同时，也把不确定性放到了最大。模型每句话、每次操作都是根据当前上下文现场生成的，这就意味着：

• 你上午对话里提过一句"这里要用 pnpm"，下午新开对话它就忘了，又去用 npm；
• 代码规范你口头说过一次"组件用函数式写法"，它写新组件时大概率用 class 组件；
• 你让它修一个 bug，它改完了不跑测试，直接告诉你"应该好了"。

这不是模型笨，而是它缺少一份稳定的"项目说明书"。人入职新公司还要看文档、问同事，模型进入一个全新代码库时，你如果不主动给它喂规则，它就只能靠猜。

1.2 模板到底解决了什么问题

我在实际使用中总结下来，一套好的模板体系至少能解决四件事：

第一是上下文重塑。每次新对话开始时，模板会自动加载项目背景、技术栈、目录结构、常用命令，让模型不用从头"盲猜"。这就好比给新同事一份入职手册，而不是让他自己去翻几百个文件。

第二是行为一致性。代码风格、提交规范、错误处理方式、测试要求这些规则一旦写进模板，模型每次操作都会先对照规则，输出风格会稳定得多。

第三是减少重复输入。以前每次开新对话，我都要花几百字交代项目背景、目录结构、注意事项。有了模板，这些全部自动注入，省下的时间非常可观。

第四是划定安全边界。什么命令能跑、什么命令绝对禁止、哪些文件只能读不能写，这些都可以在模板中配置好。模型不会越界，你也省得每次都盯着终端确认。

1.3 有模板和没模板，差得不是一点半点

我举一个最典型的例子。没有模板的时候，我让它修一个接口超时问题，它可能直接找到接口文件就开始改超时时间，改完就交差。有模板之后，它会在动手前先做排查：先读 README 了解模块结构，确认是不是数据库慢查询导致的，再定位到具体的 SQL 语句，改完以后还会顺手跑一遍相关的单元测试。

这个差距本质上就是**"项目上下文 + 操作流程"有没有被固化**的区别。一套成熟的claude-code-templates就是把这两样东西用文件的形式固化下来，让模型每次进入项目都能快速进入状态。

2. 模板的组成结构与文件体系

很多人以为模板就是"一段提示词"，这是最大的误解。Claude Code 的模板体系，是一套按约定路径放置、自动加载或按需触发的文件体系。只有理解了这套体系，你才能搭出真正好用的模板。

2.1 CLAUDE.md：项目的"记忆核心"

CLAUDE.md是 Claude Code 最核心的记忆文件。它的加载机制是这样的：当你在某个目录下启动 Claude Code 时，它会自动读取当前目录及其所有父目录下的CLAUDE.md，把这些内容合并进系统上下文。

所以你可以用这个文件来存放：

• 项目是干什么的、用什么技术栈；
• 代码目录结构说明；
• 常用命令（启动、测试、构建、Lint）；
• 代码风格与规范；
• 必须遵守的"红线"（比如"永远不要修改 src/generated 目录"）；
• 当前迭代的上下文信息。

CLAUDE.md可以放在全局目录（~/.claude/CLAUDE.md），也可以放在项目根目录，甚至放在子目录做局部覆盖。这个"就近原则"非常有用，后面我会讲怎么用。

2.2.claude目录：配置、命令与技能

除了CLAUDE.md，项目根目录下的.claude目录携带了更丰富的配置能力。我常用的目录结构是这样的：

.claude/ ├── settings.json # 权限与行为配置 ├── commands/ # 自定义斜杠命令 │ ├── review.md │ └── commit.md └── skills/ # Agent Skills 技能 └── api-debug/ └── SKILL.md

commands目录里放的是斜杠命令，比如输入/review就会触发一个你预先写好的代码审查流程。skills目录放的是技能文件，每个技能包含任务描述、使用场景和详细步骤，Claude Code 会在合适的场景自动调用它们。

2.3 全局模板与项目模板的分层设计

我强烈建议你把模板分成两层：全局层（个人习惯）和项目层（具体项目规则）。

全局模板放在~/.claude/CLAUDE.md和~/.claude/目录里，保存你跨项目通用的规则：你偏好什么代码风格、提交信息怎么写、是否要求每个改动都附带测试、遇到冲突时的处理优先级等。

项目模板放在各个仓库根目录里，只包含该项目特有的信息：技术栈、模块说明、启动命令、部署流程、遗留问题。

这两层会自动合并，全局模板提供"你这个人怎么干活"的底色，项目模板提供"这个项目什么情况"的细节。我在实际项目里还会在项目的docs/里放一份架构文档，并在项目级CLAUDE.md里加一行说明，让 Claude Code 需要时去查询。

2.4 模板不是越厚越好

我见过有人把模板写成几万字的大部头，技术栈、历史沿革、每一行代码的作用全塞进去。结果就是模型上下文被模板占满，真正干活的空间反而所剩无几。

模板的本质是"索引"而不是"百科全书"。好的模板只写规则和关键路径，详细资料用链接或路径指向仓库里的文档。这样既降低了上下文占用，又保证了模型在需要深度信息时有明确的检索路径。

3. 搭建模板前的三个关键决策

动手写模板之前，先别急着堆内容。有三个决策想清楚了，后面会顺畅很多。

3.1 先定场景：通用型还是专项型

你要想清楚这套模板主要服务什么场景。是"什么项目都能套的通用模板"，还是"专为某种技术栈定制的专项模板"？

这两种我都在用。~/.claude/CLAUDE.md是通用型的，只管个人习惯；而每个项目里的模板是专项型的，比如一个 React + Node.js 全栈项目，模板里会明确写前端组件放哪个目录、API 路由前缀是什么、数据库字段变更要走什么流程。

如果你是第一次搭模板，我的建议是从专项模板开始，拿一个你最常写的项目类型下手，效果最直观，也容易迭代。

3.2 再划领域：命令负责"手动触发"，技能负责"自动响应"

很多人容易把commands和skills混为一谈，导致命令文件写得像技能，技能文件写得像命令。

我的划分标准很简单：斜杠命令是"用户主动喊它干活"，比如/review让 Claude Code 做一次完整代码审查；技能是"模型根据场景自动决定怎么干活"，比如当对话中涉及查接口问题时，模型会自动加载api-debug技能的排查步骤。

举个例子你就明白了。你输入/commit，Claude Code 会按命令里的规则帮你生成提交信息；而当你问"为什么前端请求一直 500"时，模型读到了api-debug这个技能描述，觉得匹配，就会自动调用这个技能里的排查清单。两者分工完全不同。

3.3 想清楚"红线"：不让模型做什么

我发现很多人配置模板时只写"要做什么"，很少写"不能做什么"。这其实是最容易踩坑的地方。

模型在无约束的情况下可能会顺手做很多你不想让它做的事：往生产环境打印调试日志、用rm -rf清理目录、改完代码直接git push、在没有测试的情况下重构核心模块。这些行为不是模型"坏"，而是你给了它权限但没给它约束。

所以我会在每套模板里单独拎出一个"禁止事项"区块，明确写出红线。安全相关的规则宁可多写几条，也不要漏。

4. 一套真实项目模板的落地全过程

光讲理论没用，我拿一个实际的内部项目>#>对当前分支的全部改动执行代码审查。审查时按以下步骤进行： 1. 运行 git diff --stat，了解改动涉及的文件范围。 2. 逐个检查关键文件的 diff 内容。 3. 对照项目 CLAUDE.md 中的代码规范，逐项核查： - 是否引入 class 组件 - 是否手写 CSS - 是否绕过 zod 校验 - 是否缺少测试覆盖 4. 输出审查报告，按 [严重][一般][建议] 三级列出问题， 每条问题必须包含：涉及文件、行号、问题描述、修改建议。

这里有一个关键细节：命令文件里的"步骤"要具体到命令级别，比如"运行 git diff --stat"。因为斜杠命令本质上是给模型的"练习题"，你给的步骤越清晰，它执行起来就越不容易跑偏。

同时我再建一个/fix-existing-tests命令，用于专门的测试修复场景。它的核心逻辑是：先看测试失败的输出，定位失败原因，再动手修，修完必须重新跑测试确认。这类命令的价值在于把"你希望模型按什么流程干活"固化了下来，而不是每次重新描述。

4.4 编写技能文件：让模型学会"怎么排查问题"

技能文件是 Claude Code 模板更新后最值得关注的能力。我在.claude/skills/api-debug/SKILL.md里写了前后端联调排查技能：

--- name: api-debug description: 排查前端请求后端接口失败的问题。当用户反馈接口报错、请求超时、返回数据格式不对、状态码异常时使用。 --- ## 背景与适用场景 前端通过 /api/v1 调用后端接口，出现 4xx、5xx、超时或数据结构异常等问题时，使用本技能排查。 ## 排查步骤 1. 先在前端代码里找到对应请求封装文件， 确认请求 URL、方法、参数是否符合接口约定。 2. 检查后端路由是否注册，路由前缀是否为 /api/v1。 3. 检查 z o d 校验逻辑，确认参数校验规则与前端发送的数据是否一致。 4. 检查 services 层和 db 层，确认数据库查询是否有明显的 N+1 或全表扫描问题。 5. 运行后端测试，确认最近一次改动是否破坏了接口行为。 6. 输出排查结论，明确根因与修复建议。 ## 注意事项 - 不要一上来就改代码，先定位根因。 - 如果数据库查询较慢，优先检查 Prisma 查询是否缺少索引相关提示。 - 不要在生产环境下直接运行日志打印调试。

注意到description字段了吗？这非常关键。模型是靠 description 来判断"什么场景下该用这个技能"的，所以描述里要尽量覆盖你实际会遇到的问法。如果描述写得含糊，比如"处理接口问题"，模型很可能在对话里不会触发这个技能。

我还会为每个技能配套一个README.md，解释这个技能的适用范围和用到的背景文档链接。这样模型在不完全确定是否该用某个技能时，可以先读 README 再判断。

4.5 配置权限：让模型在安全边界内行动

在.claude/settings.json里做权限配置，这是模板体系里技术含量较高、也最容易被忽略的一部分。我的配置大致如下：

{ "permissions": { "allow": [ "Read", "Bash(npm run dev)", "Bash(npm run test:*)", "Bash(npm run lint)" ], "deny": [ "Bash(git push *)", "Bash(rm -rf *)", "Bash(git reset --hard *)" ], "additionalDirectories": [] }, "model": "claude-sonnet-4-5", "maxThinkingTokens": 5000 }

这里我解释一下几个字段的思路：

allow里的规则表示"运行这些命令时不需要再次询问我"。我特意把npm run test:*用通配符放行，这样模型跑测试时不会被弹窗打断。deny里明确禁止了推代码和危险删除操作，因为这两个动作一旦发生，补救成本极高。

maxThinkingTokens我一般不开得太大，因为我的模板和命令本身已经很详细，模型不需要过多的自由思考空间，反而能把精力放在执行上。对于复杂重构任务，我会临时调高这个参数。

4.6 模板验证与迭代：实测一场完整对话

模板写完之后，我要做一次完整验证。我通常会先开一个全新对话，输入一句完整但模糊的需求：

"帮我在数据看板里加一个新的折线图，展示最近 30 天用户活跃趋势。"

然后观察 Claude Code 的行为：

• 启动时是否正确加载了CLAUDE.md（可以通过/context查看加载的文件列表）；
• 是否自动选择了合适的技术方案；
• 是否主动运行测试而不是自说自话；
• 是否触碰了红线（比如改错了目录）。

第一次验证总会发现一些问题。比如我的早期模板里漏写了图表库的用法说明，导致模型新增折线图时自己脑补了一套 ECharts 配置，和项目里的旧代码风格不一致。发现问题后，我会把"图表统一使用 ECharts 核心包，封装在 src/components/charts 下"这一条补进CLAUDE.md。

模板是长出来的，不是一次写出来的。每一次新对话中出现不符合预期的行为，我都会问自己一个问题：这是我的模板缺失导致的，还是模型临时抽风？如果是前者，就补规则；如果是后者，就调整命令中的步骤描述。反复几轮之后，模板会越来越贴合你的实际工作方式。

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

模板体系用久了，一定会遇到各种问题。我把踩过的坑和排查思路整理成一张速查表，方便你对照排查。

5.1 模板不生效，最常见的三个原因

我遇到过的"模板不生效"，九成是下面三个原因之一：

第一，文件路径搞错了。CLAUDE.md必须放在项目根目录，commands必须放在.claude/commands/下，skills目录结构必须符合skills/<技能名>/SKILL.md的规范。路径不对，东西就白写。

第二，被父目录模板覆盖。Claude Code 会合并父目录的CLAUDE.md，如果你的~/.claude/CLAUDE.md里写了与项目规则冲突的内容，项目规则可能不会生效。这需要在设计阶段就做好分层，全局模板里不要写技术栈相关的规则。

第三，描述和命令不够精确。技能文件的 description 写得太宽泛，模型不知道该在什么场景调用；命令文件的步骤写得太抽象，模型执行时天马行空。这两种情况都表现为"模板好像没起作用"，本质是模板内容质量问题。

5.2 上下文窗口被打爆，模型变笨

这个是配置模板的人特别容易忽略的坑。模型上下文是有限资源，你把几万字项目文档全写进CLAUDE.md，模型读文档的时间都比干活的时间多，它能不笨吗？

我的经验是：CLAUDE.md必须保持精简，核心规则控制在 50 到 80 行，详细内容全部外链。比如架构设计、接口文档、数据库设计说明这些，放在项目的docs/目录里，然后在CLAUDE.md中写一句"架构细节请参考 docs/architecture.md"。

这样做还有一个额外好处：模型会在需要时主动去读文档，而不是被动地带着几万字背景信息思考。带上真正需要的上下文，比塞满所有可能的上下文要高效得多。

5.3 命令和技能明明写了，却总是"绕开"它们

还有一种常见情况：命令和技能都在，但模型就是不按流程走。我后来发现根源在于指令里的优先级不够明确。

在项目模板里，我会加这么一小段：

## 执行优先级 - 涉及接口问题排查，必须使用 api-debug 技能 - 涉及代码审查，必须使用 review 命令 - 在没收到用户明确指示前，不要跳过上述流程

这段话放在CLAUDE.md的规则区，配合命令和技能文件一起生效。模型看到"必须使用 xx 技能""不要跳过"这种强约束表述后，行为明显收敛了很多。

5.4 多项目之间的模板会"打架"

如果你像一样同时维护好几个项目，一定会遇到模板串味的问题。现象是：在 A 项目里干活，模型却用了 B 项目的目录规范。

这个问题的根源通常是全局模板里放了太多项目相关的内容。我的处理方案是：

• 全局模板只保留"个人工作习惯"：提交信息格式、代码风格偏好、测试覆盖率要求；
• 所有技术栈相关的规则一律下沉到各项目的CLAUDE.md；
• 如果多个项目技术栈相同，可以做一个基础模板副本，复制时改掉项目特有信息。

6. 模板的高阶迭代：从个人资产到团队资产

模板不是搭完就一劳永逸的，它和代码一样需要持续维护。我平时迭代模板主要围绕四个方向。

6.1 从失败的对话里提取新规则

每一次让你不满意的对话，都是模板迭代的素材。我的习惯是：当模型产出了不符合预期的东西，先记录下"它做错了什么"和"它为什么做错"，然后判断这个错误能不能通过模板规则避免。

比如有一次，Claude Code 在修改后端接口时，直接在 route 文件里写了一堆业务逻辑，完全绕过了 services 层。这明显是我在模板里没有强调分层约束导致的。我在CLAUDE.md的代码规范里补上了一条："后端所有业务逻辑必须放在 server/services 层，route 只负责请求分发和参数校验。"

6.2 给模板做版本管理

模板文件本身也是代码，应该纳入版本管理。我的做法是在每个项目里把.claude/和CLAUDE.md加入 Git，和项目代码一起提交。这样任何一次模板变更都有据可查，出问题时也能快速回滚。

个人全局模板我会单独用一个dotfiles仓库管理，方便在不同电脑之间同步。如果你有换机器或者接新项目重新配置的需求，这一步非常值得做。

6.3 定期审查：删减比增补重要

模板会随着时间膨胀，三个月前写的规则可能已经不再适用。我每隔一两个月会做一次模板审查，把已经不相关的规则清理掉。比如某个临时约束是为了某个特定 bug 加的，bug 修完就可以删。

模板瘦身和代码重构一样重要。保留的规则越少，模型的理解成本越低，执行的准确率反而越高。

6.4 团队共享模板

当模板在个人项目里跑稳定了，可以考虑把它推广到团队。我们团队现在的做法是：把公共的CLAUDE.md和.claude/skills/放到一个共享仓库，项目初始化时自动复制进来。每个项目再在本地CLAUDE.md里补充项目特有规则。

团队推广时会遇到一个新的问题：成员的提问习惯不一样，技能描述可能需要覆盖更多问法。这时候我会鼓励大家把"模型没按预期干活"的案例反馈到公共模板仓库，统一迭代。几轮下来，整个团队的 AI 编码质量都会有明显提升。

我在实际项目中体会最深的一件事是：模板的价值不在于写得多么花哨，而在于它能不能稳定地约束模型行为。规则越多不代表越好，真正的关键是让模型在正确的时候知道该做什么、不该做什么。我自己也还在不断迭代这套claude-code-templates，每次新项目都会做一次删减和微调。

最后再分享一个小技巧：你的模板不是给别人看的，是给模型看的行为准则。所以写的时候不妨多站在模型的角度想想——如果你是一个刚入职的程序员，面对这个项目，你最需要哪些信息才能不犯低级错误？把这个视角想明白，你的模板就不会差到哪里去。