企业官网建设流程全解析

如果你和我一样，把 Claude Code 当成日常主力编码工具用了超过一年，你大概率会遇到同一个困扰：同一个模型，昨天生成代码的风格和今天完全不一样；换一个项目目录，它好像"失忆"了；明明是同样的需求，每次都要把上下文重新解释一遍，甚至来回纠错好几次。这其实不是模型变笨了，而是你没有给它一套稳定的行为准则。claude-code-templates 这个项目，本质上是把 Claude Code 的提示词、CLAUDE.md 记忆文件、子代理定义、斜杠命令和钩子规则固化下来，让每次打开终端敲下claude时，面对的都是那个"经验老到的你"，而不是一个从零开始试探的新人。

这篇文章我会从实际使用的角度，把 claude-code-templates 的目录结构、核心模板设计思路、CLAUDE.md 的工作机制、以及接入自己工作流时的踩坑经验全部摊开讲。适合正在用 Claude Code 写生产代码的开发者、想给团队统一 AI 编码规范的负责人，以及任何觉得"AI 写代码不够稳定"但又不确定问题出在哪儿的读者。看完你至少能搭建一套属于自己的模板库，让 AI 的输出从"能跑"变成"像是你写的"。

1. 模板到底解决了什么问题

1.1 默认状态下的"AI 通病"

先聊聊痛点。Claude Code 的默认行为，其实是"什么都懂一点，但不了解你的规矩"。它知道 TypeScript 的类型系统，但它不知道你们团队约定接口返回必须用Result包装；它理解 Docker 的底层原理，但它不知道你的镜像构建规范里禁止用latest标签；它能写出漂亮的 Python 代码，但它不清楚你负责的这个模块历史包袱有多重，哪些地方绝对不能动。

这些问题在单次会话里还不明显，一旦项目变大、成员变多，AI 的"不稳定感"就会被放大。你会看到它这次引用了lodash，下次又自己实现了throttle；这次按你的要求用了pnpm，下次又开始npm install。我不是在说模型能力不行，而是说默认状态下它缺少一个稳定的、跨会话、跨项目的"记忆锚点"。这就是模板存在的第一层意义：把规则外置化，不再依赖模型每次的临场发挥。

1.2 模板 = 给 AI 立规矩

claude-code-templates 的核心不是某一段提示词写得有多华丽，而是它建立了一套机制，让 AI 在每次进入工作环境之前就接收到一套明确的约束。你可以把它想象成一个新员工入职时拿到的员工手册加操作规范再加老员工批注，模板就是这个东西的数字化形态。

具体到机制上有三层：

• 指令层：核心的 system prompt 和工作准则，例如"所有路径必须用绝对导入""禁止在 reducer 里写副作用""日志必须走统一 logger"。
• 行为层：针对特定任务的子代理和斜杠命令，例如"生成数据库迁移脚本时，必须先检查现有表结构变更记录"。
• 校验层：通过钩子对 AI 生成的代码做机器检查，例如"生成文件后自动执行 lint，失败就直接告诉 AI 去修"。

这三层层层递进，最终让 AI 的行为从"自由发挥"变成"有章可循"。拿我自己的体验来说，接入模板之前，每次让 AI 改一个跨模块的公共方法，我要花三百字描述背景；接入之后，它自己在 CLAUDE.md 里就能找到相关上下文，我只需要说一句"按模板走"，剩下的细节它自己补齐。

1.3 真正影响团队的收益

模板对个人开发者是提效工具，对团队来说就是一致性保障。我带过一个六人的前端小组，大家用 Claude Code 的姿势完全不同：有人让它写单测，有人让它重构，有人只是拿它当搜索引擎。结果就是同样的代码规范，AI 在不同人手里产出的代码标准差异极大。

后来我把一套完整的模板放进团队仓库，在根目录的 CLAUDE.md 里写清楚项目架构、编码规范、禁止事项，在.claude/commands/里预置审查、重构、补测试、写文档等常用命令，并给每个命令都配好提示词。效果很直接：新人只需要知道claude /review是走代码审查流程，claude /refactor是执行重构流程，AI 就会严格按照模板设定的步骤执行。团队沟通成本降了，代码风格反而统一了。

你要明白，模板不是限制 AI 的发挥，而是把"什么样的发挥是对的"这件事提前定义清楚。

2. 核心文件结构：一套模板项目的骨架

2.1 典型的目录布局

我先给出一份我实际项目里使用的模板目录结构，你可以直接参照它来搭建自己的模板库：

claude-code-templates/ ├── CLAUDE.md ├── .claude/ │ ├── commands/ │ │ ├── review.md │ │ ├── refactor.md │ │ ├── write-tests.md │ │ ├── add-feature.md │ │ └── fix-bug.md │ ├── agents/ │ │ ├── code-reviewer.md │ │ ├── test-engineer.md │ │ └── tech-writer.md │ └── hooks/ │ ├── post-compile.py │ └── pre-commit.py ├── prompts/ │ ├── code-generation/ │ │ ├── typescript-component.md │ │ ├── python-service.md │ │ └── sql-migration.md │ └── utilities/ │ ├── explain-code.md │ ├── find-bugs.md │ └── security-scan.md └── examples/ ├── claude-code-workflow.md └── team-agents-config.md

这套结构不是凭空拍脑袋定的，每一层都有它的职责边界。

2.2 每个文件类型的具体作用

先看根目录的CLAUDE.md，这是整个模板体系的中枢。Claude Code 在启动时会自动读取这个文件作为长期记忆，相当于每次会话的"基础人设"。里面一般放三类内容：项目简介与架构说明、编码规范与约束清单、以及常见的"不要做"清单。我见过不少人的 CLAUDE.md 只有三行字，那基本起不到约束作用，至少要写到百行级别才有效果。

再看.claude/commands/目录，这里存放的是自定义斜杠命令。每个.md文件就是一个命令，文件名就是命令名。比如review.md可以用/review触发。命令文件里写的是：该命令的目标、执行步骤、输入输出要求、以及判断成功的标准。Claude Code 会根据这个文件的内容来决定调用哪些工具、按什么顺序执行。

.claude/agents/目录定义的是子代理，也就是把某类任务封装成独立角色。比如code-reviewer.md定义一个专门的代码审查代理，它有自己独立的 system prompt，可以调用独立的工具组合。这比在一个会话里反复切换角色要稳定得多，因为子代理不会受到主会话历史上下文的污染。

prompts/目录则是模板的素材库，存放各种可直接复用的提示词片段。这些片段通常不直接触发，而是在特定命令或子代理中被引用。例如sql-migration.md是一段生成数据库迁移脚本的详细指令，/add-feature命令在检测到涉及数据库改动时，会先读取这段提示词再执行任务。

最后的examples/目录用于存放一些完整的示例配置，方便新人理解模板之间如何协同工作。

2.3 为什么要这样分层

我见过一些人把提示词、命令和配置全部塞进一个超大 markdown 文件里，当时觉得方便，后续维护就是灾难。分层设计的核心原因是隔离变化：编码规范经常变，你只需要改 CLAUDE.md；某个命令的步骤变了，你只需动对应的命令文件；提示词需要优化，你完全不需要碰命令配置。

另外，分层还能避免上下文爆炸。Claude Code 的上下文窗口是有限资源，如果全部指令都塞进主会话，聊几轮就快满了，后面生成质量直线下降。分层之后，主会话只加载 CLAUDE.md 和当前命令相关内容，子代理只加载自己的定义文件，剩下的提示词按需读取，上下文利用率高很多。从长期维护角度看，分层还方便做版本管理和团队评审。每次改动都有明确的影响范围，不会出现"改了一行字，整个 AI 行为全变了"的失控感。

3. 核心模板的设计思路与实操要点

3.1 代码生成类模板：把"写代码"变成"按规范填表"

代码生成类模板是使用频率最高的一类。设计它的关键，不是告诉 AI"请写一个漂亮的组件"，而是提供足够多的约束条件，让 AI 自动推导出符合项目规范的代码。实际模板里我建议包含这些要素：

• 输入要求：明确需要哪些信息，例如组件名称、Props 接口、依赖项。
• 代码骨架：先给出目标代码的基础结构，AI 在这个骨架里填充。
• 风格约束：例如函数式组件优先、禁止使用 any、副作用必须放在 useEffect 之外。
• 输出格式：要求同时给出代码、简要说明、以及这个组件可能影响到的现有文件清单。

以 TypeScript 组件模板为例，我会在模板里写清楚：组件必须使用 forwardRef 暴露 ref，必须处理加载态和错误态，事件处理函数必须以handle前缀命名。这些听起来是常识，但默认状态的 AI 真的做不到每次都遵守。有了模板，相当于每次都是同一个"老手"在动手，输出标准自然稳定。

3.2 评审与重构类模板：让 AI 当"别人"，而不是"你自己"

代码评审模板是我个人认为最有价值的一类。原因很简单：让 AI 直接生成代码时，它和写代码的你是同一个思路，很难发现盲区；但把它定义成"评审者"角色时，它会按照你预设的检查清单逐项核对，反而能找到不少真问题。

我常用的review.md命令模板结构大致这样：

# 命令：代码审查 ## 目标 对当前分支的变更代码进行全面的质量审查，输出结构化审查报告。 ## 输入 - 变更文件列表（默认取 git diff 的变更） - 审查重点（可选） ## 检查清单 1. 正确性：是否有潜在 bug、边界条件是否处理。 2. 安全性：是否有注入、越权、敏感信息泄露等问题。 3. 性能：是否有明显低效的实现。 4. 可维护性：命名、结构、复杂度是否合理。 5. 规范一致性：是否遵守 CLAUDE.md 中定义的编码规范。 ## 输出格式 - 按严重程度分级：致命 / 建议 / 可选 - 每条问题包含：文件路径、行号、问题描述、修改建议、示例代码 - 不要啰嗦，不要重复代码，直接给结论 ## 结束条件 审查完毕且报告输出后，向用户确认是否需要自动修复。

这套模板用下来，我最深的体会是：必须把"结束条件"写清楚。如果你不告诉 AI 审查完要做什么，它经常会在报告最后来一句"如果有需要，我可以进一步优化"，然后等你回复。把结束条件写清楚之后，整个流程就自动化了，AI 审完直接问你要不要修，要修就继续走修复流程，不要修就结束会话，不再浪费你的时间。

3.3 测试与文档模板：从"可有可无"到"强制产出"

测试和文档是团队里最容易偷懒的部分，用模板强制产出恰好能补上这块短板。写测试类模板时，我强烈建议把"种子用例"写进去，也就是给 AI 提供一个最典型的测试示例，它在这基础上扩展。这比空口说"请给这个函数写单测"可靠得多。

文档类模板的核心是输出结构固定。比如tech-writer.md这个子代理，我要求它输出的文档必须包含概述、安装方式、API 说明、常见问题、变更记录五个部分。固定结构的好处是文档可以直接进团队的文档站，不需要再花时间排版。这里有个小技巧：模板里可以要求 AI 在输出文档时同步生成 Markdown 目录，方便后续在文档平台中自动渲染导航。

3.4 模板设计的三个常见误区

我自己在折腾模板过程中踩过不少坑，有几类问题尤其典型：

• 提示词写得太绝对。比如"永远不要使用 any"，但项目里恰巧有一个第三方库的类型定义不全，AI 卡在这个规则上死活不编译。后来我改成"尽量避免使用 any，如确需使用必须注释原因"，一下子畅通了。
• 命令步骤设计得太长。一个/refactor命令要求 AI 执行八步操作，每一步还有子条件。结果 AI 跑到第三步就忘了前面说过什么，输出结果四不像。后来我把长流程拆成多个短命令：/refactor-analyze只做分析出方案，/refactor-apply只做代码变更，/refactor-verify只做验证修复，反而流畅得多。
• 忽视输出长度控制。有些模板没写"输出要精简"，AI 会给每个函数生成几十行注释，生成结果是厚厚一本说明书。后来我在模板里统一加了一句"注释只解释为什么，不解释是什么"，这个问题立刻缓解。

4. CLAUDE.md 与自定义指令：让模板真正融入工作流

4.1 CLAUDE.md 的正确打开方式

CLAUDE.md 是模板体系中优先级最高、影响范围最大的文件。很多人把它当成简单的 README 变种，这是误解。README 是给人看的，CLAUDE.md 是给 AI 看的。它的措辞、结构和颗粒度都应该针对 AI 的读取方式优化。

我的 CLAUDE.md 写作经验可以浓缩成四个字：断言优先。用肯定的、简短的、无歧义的短句来描述规则，而不是像写散文一样描述背景。比如：

## 项目架构 - 前端：React + TypeScript + Vite，目录结构见 src/README.md - 后端：Node.js + Express，所有 API 必须走 /api 前缀 - 数据库：PostgreSQL，通过 Prisma 访问，禁止直接写原生查询 ## 编码规范 - 所有组件必须是函数式组件，禁止 class 组件 - 状态管理统一使用 zustand，禁止引入 redux - 调用后端接口必须使用统一的 request 封装，禁止直接 fetch

这些断言式的短句，AI 非常容易解析和遵守。相比之下，如果你写一段"考虑到项目的长期维护需求和团队协作的便利性，我们建议在状态管理层面采用轻量且易于扩展的方案"，AI 读完只会觉得你说得对，但完全不知道具体该怎么做。

我建议 CLAUDE.md 控制在 200-500 行之间。太短覆盖不全，太长会占用大量上下文窗口，影响实际编码过程中的推理质量。并且要定期梳理，把冗余条目清掉，保留有价值的断言。

4.2 自定义斜杠命令：把高频操作固化成流程

自定义命令是我日常使用频率最高的功能。一个设计良好的命令文件，应该像一份"合同"：输入什么、做什么、产出什么、完成后怎么办，全部白纸黑字写清楚。

我举个具体例子，这是我团队的add-feature.md模板核心内容：

# 命令：新增功能 ## 触发条件 用户希望新增一个功能特性，并希望按照团队标准流程执行。 ## 流程 1. 分析功能描述，输出可行方案（方案必须包含改动范围、涉及文件清单、风险评估）。 2. 等待用户确认方案，确认后才可进入下一步。 3. 按方案执行代码变更，变更过程中必须遵循 CLAUDE.md 全部规范。 4. 变更完成后，运行相关测试并执行 lint。 5. 输出变更摘要：修改了哪些文件、新增了哪些测试、如何验证。 ## 注意事项 - 如果方案中涉及数据库结构变更，必须先检查现有迁移脚本目录，确认迁移编号的连续性。 - 如果变更涉及公共 API，必须在摘要中标注"breaking change"。

用下来最大的感受是，命令在"等待用户确认方案"这一步起到了很强的保护作用。默认状态下，你让 AI 加功能，它经常直接闷头改代码，改完发现方向错了又得全部推翻。模板强制它先输出方案，你再确认，看似多了一轮交互，实际上省掉大量返工成本。

4.3 子代理：让专业任务有专业角色

子代理的设计思路值得多说几句。Claude Code 的主会话是一个通用工作环境，它擅长综合处理，但专项能力容易被上下文稀释。子代理相当于给你提供了一个"专项小组"，每个成员只聚焦一类任务。

以test-engineer.md为例，它的 system prompt 里写了：你是一位专注于测试策略的工程师，擅长单元测试、集成测试和测试覆盖率分析。你的职责是为新增代码补充测试，目标是把关键路径的覆盖率提升到 90% 以上。当主会话需要补测试时，会把这个子代理的配置加载进来，由它负责生成测试代码和测试报告。

使用子代理有个重要的配置细节：要给每个子代理定义好输入接口和输出规范。比如你在test-engineer.md里写清楚"输入是需要测试的文件路径，输出是测试文件路径 + 覆盖率报告 + 未覆盖点说明"，这样主会话在调用时就能按规范传递参数，得到规范化的结果。如果没有这些定义，你可能会发现子代理生成了一个测试计划就停下来了，而你想要的是测试代码本身。

4.4 钩子：把校验交给机器，不靠自觉

模板体系里还有一类容易被忽略的部件：钩子（hooks）。钩子可以在特定事件发生时自动执行脚本，例如文件生成后、会话启动前、命令执行完毕后。我目前最常用的是两个场景：

• 文件修改后自动跑 lint：AI 每次写完代码，钩子自动执行 ESLint，如果失败则把错误信息反馈给 AI 自己修复，直到通过为止。
• 会话启动前自动加载项目规范：通过钩子在会话创建时读取最新的 CLAUDE.md 内容，确保 AI 从第一句开始就处于正确的规范环境中。

设置钩子的过程中，我的建议是先让脚本保持简单，用 Python 或 Shell 写一个最小可用版本，能跑通再去加功能。很多人在钩子上追求大而全，结果脚本本身出错导致 Claude Code 起不来，反而拖累日常使用。

5. 实操过程：从零搭建属于你自己的模板库

5.1 第一步：先别急着写模板，盘点你日常的高频动作

动手之前，建议先花 30 分钟做一次"工作复盘"，把你最近两周用 Claude Code 做过的所有事情列出来，分类统计：写新功能、修 bug、重构、补测试、写文档、做代码审查、查资料、解释旧代码。你会发现占比最高的大概只有三四类，这些就是你要优先做模板的场景。

我在项目启动时就是这么做的，统计出来自己 60% 的请求集中在"新增 CRUD 接口"和"修复线上 bug"两个场景。于是我优先做了add-api.md和fix-bug.md两个命令，其他场景先不做。等到这两个跑顺了，再逐步扩展其他模板。

开始写第一个命令时，不用追求完美，先把流程写出来，然后用真实的代码变更去测试它。测试时要刻意给它一些刁钻的输入，比如不完整的描述、有歧义的需求，观察它是否知道怎么处理。模板的鲁棒性都是这样一点点磨出来的。

5.2 第二步：按"输入-流程-输出"三段式写模板

我强烈建议你沿用三段式结构来写每一个模板文件：输入、流程、输出。这个结构清晰、容易维护，AI 也容易理解。

拿fix-bug.md举例，它的输入部分要求用户提供 bug 描述、复现步骤、或者报错日志；流程部分则包括先复现、再定位根因、再修复、最后验证四个阶段；输出部分则要求给出一份说明书，包括根因分析、修复代码、测试结果、以及防止复发的建议。

有一次我发现 AI 在输出阶段总是漏掉"防止复发的建议"，后来在模板结尾加了一句"如果根因属于常见错误类型（如空指针、未处理异步错误），必须附上预防措施"，这个问题就消失了。这就是模板迭代的常态：每发现一个不满意的地方，就回到模板里去补一条规则，而不是每次重新调教 AI。

5.3 第三步：把团队规范沉淀进 CLAUDE.md

如果你们是团队协作，这一步非常关键。先把团队现有的编码规范、行为准则、架构约束整理成文字。注意，不要直接扔进 CLAUDE.md，先压缩成断言式短句。这一步的筛选原则是：只保留那些 AI 必须知道才能正确编码的规则，那些"建议使用好的命名"之类的泛泛之谈直接扔掉。

举个例子，团队规范里有一条"接口返回的数据结构要统一"，这太模糊。断言化之后是"所有 API 返回格式必须是{ code, data, message }结构，禁止使用裸数组作为响应体"，AI 就能准确执行了。规范进 CLAUDE.md 之后，建议先在本地分支上跑一周，观察 AI 的行为差异，再合并到主干。

5.4 常见问题与排查技巧实录

下面是我实际使用中遇到过的问题和对应的排查思路，整理成一张速查表：

还有一个很容易踩的坑，新手特别容易犯：以为模板写完之后就一劳永逸了。实际上代码规范会跟着项目状态变化，CLAUDE.md 里的规则也需要跟着演进。我现在的习惯是每两周集中审查一次模板，看哪条规则已经不再适用、哪条规则产生了反效果、哪类常见任务还缺模板。这种持续迭代的动作，比一次性写一个"完美模板"重要得多。

5.5 扩展思路：团队级模板仓库与自动化联动

如果模板在自己的项目里跑顺了，下一个值得尝试的方向是把模板仓库独立出来，做成团队级的共享配置。这样一两个人维护模板的更新，整个团队都能受益。维护方式上建议借鉴 Git 分支管理：模板仓库的 main 分支保持稳定可发布，用 feature 分支去试验新的模板结构，试验通过后再合并回主干。

另外，模板也可以和 CI/CD 流程做联动。比如某个命令执行完，如果结果符合预期，钩子可以自动触发一次流水线构建。你也可以把审查结果自动提交成一个工单或者合并请求备注，减少人工搬运。我目前还没有做到这一步，但已经在团队里试点"AI 写完代码自动创建 MR 草稿"的流程，效果比预想的省事不少。

根据我的经验，这套模板体系最理想的使用状态是：你打开终端输入一句模糊的需求，比如"把这个列表页的分页改成游标分页"，AI 能自动判断这属于重构还是新功能，选择对应的命令模板，按既定流程执行，最后输出一份清晰的变更报告。你只需要在关键节点确认一下方向，剩下的事情都可以交给模板里的规则去管。这才是模板体系的价值所在。

我个人在实际使用中最深的一个体会是：模板的粒度要小，数量要精，宁可一个场景一个专用模板，也不要做一个"全知全能"的巨型模板。巨型模板看起来覆盖了所有场景，实际用起来每一步都是妥协，最终产出的代码风格仍然不稳定。反过来，把每个模板做小、做专、做透，让每条规则都经得起实际代码的检验，这套体系才能真正成为你编码工作流里最可靠的一部分。