企业官网建设流程全解析

1. 这个模板项目到底在解决什么问题

1.1 模板不是“复制粘贴”，而是给AI立规矩

先说个真实场景。我用了小半年Claude Code，最明显的感受是：同一个项目，今天让它写接口，明天让它改bug，后天让它补测试，它给出的代码风格、注释习惯、处理边界的方式，经常对不上。更头疼的是，换个人来用同一套工具，出来的代码风格完全是另一个味道。团队里五六个人一起干活的时候，这个问题会被放大到难以忍受。

“claude-code-templates”这个项目，本质上就是在解决这个一致性问题。它不是简单收集一堆提示词让你复制，而是把你在项目里反复交代给AI的那些话——代码规范、文件结构、工作流程、避坑清单——沉淀成一整套可复用的模板体系。有了这套模板，Claude Code每次启动都会自动读取项目约定，不用你每次都把同样的话重复一遍。

我常说一句话：模板是给AI立规矩。你不需要每次告诉它“请用TypeScript写”“请遵循项目命名规范”“请补充单元测试”，这些规则应该提前存在于模板里，让AI一进项目就“心知肚明”。这就像带新人入职，与其每天对着新人重复“我们这边代码要写注释”“数据库操作要走统一封装”，不如给他一本员工手册——模板就是那本员工手册。

这个项目适合谁？三类人最需要。第一类是重度使用Claude Code的独立开发者，一个人维护多个项目，不想每次切换项目都重新交代一遍背景。第二类是开始把AI编程工具引入团队的技术负责人，需要保证多人的代码风格统一。第三类是研究提示词工程的人，模板库本身就是最好的提示词案例集。

1.2 从“一次性对话”升级到“可累积的项目资产”

在没有模板的情况下，你和Claude Code的关系是一次性的。每次开启新会话，它对你的项目几乎一无所知，你要在对话里重新描述技术栈、目录结构、编码习惯。这中间的损耗非常惊人——我实测过，一个中等规模的项目，光是把“项目背景”讲清楚，前几次对话要消耗掉大量上下文窗口，真正干活的token反而没多少。

而模板化之后，项目知识变成了可累积的资产。你写在CLAUDE.md里的每一条约定，都会在每次会话开始时自动导入。今天你发现AI某个行为不对，你调了一下模板；明天另一个会话里，这个修正已经生效了。这就实现了“一次修正，处处受益”。用久了你会发现，模板库本身就像项目的第二份README，只不过它不仅是给人看的，更是给AI看的。

在深入细节之前，先把整个项目的组成说清楚。一个完整的claude-code-templates通常包含三部分：项目级指令文件（CLAUDE.md）、自定义命令（custom commands）、以及配套的hooks和配置。下面我会逐一拆解，并给出可直接复用的实际方案。

2. 模板库的整体架构与设计思路

2.1 目录结构：把模板当成一套可维护的代码库

很多人一开始用模板，就是建了一个CLAUDE.md往项目根目录一扔，完事了。这类“裸奔”方式前期能用，用一个月之后必然失控——文件越来越长，规则互相冲突，AI开始“选择性失明”，你都不知道该从哪儿改起。

我的做法是把模板库当成一套正经的代码库来维护。以一个实际项目为例，我的模板目录结构是这样的：

my-project/ ├── CLAUDE.md # 主指令入口 ├── .claude/ │ ├── settings.json # 权限配置、模型参数 │ ├── commands/ │ │ ├── review.md # /review 代码审查命令 │ │ ├── test.md # /test 测试生成命令 │ │ ├── commit.md # /commit 提交信息生成命令 │ │ └── refactor.md # /refactor 重构命令 │ └── hooks/ │ ├── pre-command.sh # 命令执行前挂钩 │ └── post-command.sh # 命令执行后挂钩 ├── docs/ │ └── ai-workflows.md # 各场景工作流说明 └── .ai-templates/ ├── code-style.md # 代码风格详细约定 ├── api-design.md # 接口设计约定 └── testing-strategy.md # 测试策略约定

这个结构有三个好处。第一，职责分离。CLAUDE.md只放最高层级的项目信息，细节沉淀到.ai-templates子文件里，用“include”语句引入，避免主文件无限膨胀。第二，可插拔。不同技术栈的项目，只需要更换.ai-templates下的子文件即可，命令层和hook层几乎可以通用。第三，可版本化。整个目录都在git里，改了什么、为什么改、何时改的，全都有记录。

2.2 三类核心模板的分工逻辑

模板体系里的每一类东西，扮演的角色完全不同，搞混了就会出问题。

第一类是身份与约束类模板，承载在CLAUDE.md里。它的任务是回答AI三个最基本的问题：你是谁（项目的技术栈是什么）、你在哪（代码库的布局和关键路径在哪）、你该守什么规矩（命名规范、错误处理、注释风格）。这类模板要“少而精”，写进去的每一条都必须是硬约束，不能含糊。比如“用pnpm管理依赖”是硬约束，“尽量写好注释”就太虚，AI无法据此形成稳定行为。

第二类是命令类模板，承载在.claude/commands/里。它的作用是给高频任务定义“快捷键”。你不需要每次用自然语言描述一遍“请帮我审查这段代码，重点关注潜在bug、资源泄漏、边界条件……”，你只需要输入/review，模板里的完整指令就会被带入对话。命令模板的格式一般是YAML头加正文，YAML头定义命令的名称和描述，正文则是指令本体。

第三类是流程类模板，通常配合hooks实现。它的价值是在关键节点自动触发规范动作。比如pre-command hook可以在每次提交前自动检查代码格式，post-command hook可以在AI完成修改后自动运行测试。这类模板把“事后人肉提醒”变成了“事前自动卡点”，是三类模板里最容易提升效率但最难配置的一类。

3. 手把手实操：构建一套可复用的Claude Code模板库

3.1 第一步：设计CLAUDE.md主指令文件

首先说CLAUDE.md的写法。别看它只是一个Markdown文件，它对AI行为的影响不亚于一个精心设计的system prompt。我写CLAUDE.md的原则是：信息分四级，从项目身份到具体约束逐层细化，AI按优先级读取。

以我最近一个Node.js项目为例，CLAUDE.md的核心内容长这样：

# 项目概览 这是一个面向中小企业的工单管理系统后端，采用 Node.js + TypeScript 编写， 数据库为 PostgreSQL，ORM 使用 Prisma，部署环境为 Docker + K8s。 # 技术栈与工具链 - 包管理器：pnpm（禁止使用 npm 或 yarn 安装依赖） - 测试框架：Vitest，覆盖率目标：核心模块 ≥ 80% - 代码检查：ESLint + Prettier，配置见项目根目录 - Node 版本：≥ 20，使用 .nvmrc 锁定 # 代码库导航 - src/modules/：按业务模块划分，每个模块包含 controller、service、repository - src/shared/：跨模块共享代码，包含日志、鉴权、错误处理 - prisma/schema.prisma：数据库模型定义入口 - tests/：单元测试与集成测试，目录结构与 src/ 对齐 # 编码约定 ## 命名规则 - 文件命名：kebab-case（如 user-service.ts） - 类名：PascalCase；函数/变量：camelCase - 数据库字段：snake_case；枚举值：UPPER_SNAKE_CASE ## 错误处理 - 业务错误使用自定义 AppError，禁止在 service 层直接 throw 裸 Error - 所有异步操作必须 try/catch，并确保错误信息包含上下文 ## 注释 - 公共函数和类必须有 JSDoc 注释 - 禁止大面积注释掉的死代码，直接删除

写的时候有三个容易踩的坑。

第一，不要写成散文。我曾经写过一大段“我们希望代码是干净的、可维护的、可读性强的……”这种话，结果AI完全没有行为变化。模板不是说给AI听的道理，而是给AI下的指令，每条都要有可执行性。第二，约束要分优先级。如果一份模板里全是“禁止”，AI会让所有任务都变得畏手畏脚。我习惯把约束分成“必须”“应该”“避免”三档，“必须”级别限制十条以内，“避免”级别用于软的倾向性约定。第三，CLAUDE.md只放“所有模块都适用”的规则。某个模块特有的约定，应该放到模块自己的子文档里，用@import之类的方式按需引入，不要让AI每次读一长篇用不上的内容。

3.2 第二步：自定义命令模板，把高频任务变成斜杠命令

CLAUDE.md解决的是“让AI懂规矩”，而自定义命令解决的是“让AI一键干活”。这个模块的重要性，我实际用下来觉得比CLAUDE.md还高。

命令文件放在.claude/commands/目录下，每个命令是一个Markdown文件，头部用YAML格式声明元信息。下面以我常用的review命令为例：

--- description: 对指定代码进行架构级审查，重点检查耦合度、性能隐患与边界情况 argument-hint: [文件路径或代码范围，可选] allowed-tools: Read, Grep, Glob --- 请你对以下范围的代码进行系统性审查。审查必须覆盖五个维度： 1. 架构一致性：是否符合项目的分层约定（controller → service → repository） 2. 潜在缺陷：重点排查未处理的 Promise、资源泄漏（数据库连接、定时器）、 边界条件（空数组、null输入、超长字符串） 3. 安全风险：SQL注入、敏感信息硬编码、越权访问 4. 性能问题：N+1查询、无索引过滤、循环内异步串行 5. 可维护性：重复代码、过长函数、魔法数字 输出格式要求： - 按“问题严重程度”分类，分为：阻断性问题 / 建议修复 / 可选优化 - 每个问题必须附带：文件路径 + 行号 + 问题原因 + 修改建议 - 最后给出整体评分（1-10）和一句话总评

这里有几个关键点。

description字段虽然对AI来说不是指令，但它决定了你在斜杠菜单里看到这句话能不能想起这个命令是干什么的，同时也用于AI判断何时建议你使用它，值得认真写。argument-hint告诉AI这个命令可以接收什么参数，比如/review src/modules/user/就指定了审查范围。allowed-tools限制命令执行时AI可以调用的工具集合，这个设计非常实用——审查代码时不需要它去写文件，只给读取类权限就好。

我整理命令模板时有一个习惯：每个项目放6到8个命令就够用了。分别是/review（审查）、/test（补测试）、/doc（写文档）、/commit（生成提交信息）、/refactor（重构）、/explain（解释）。命令太多会让你自己都记不住，AI在场景里反而不知道该推荐哪个，与其让AI在多个命令之间猜，不如精简到骨骼。

3.3 第三步：工作流模板与hooks，让规范自动执行

如果说命令是“按需触发”，那么hooks就是“自动触发”。hooks是在特定事件点自动运行的脚本，Claude Code支持pre-command、post-command等几个事件点。我用的最多的场景是这样：

第一个场景是代码格式自动修复。我在post-command hook里配置了一个脚本，AI每轮修改完代码后自动跑一遍ESLint --fix和Prettier：

#!/usr/bin/env bash # .claude/hooks/post-command.sh if [[ "$COMMAND" =~ ^(edit|write|create) ]]; then echo "运行代码格式化..." pnpm exec prettier --write "src/**/*.{ts,tsx}" pnpm exec eslint --fix "src/**/*.{ts,tsx}" fi

这个hook的好处是，AI改完代码后，格式问题不用你再单独提一遍，工具链自动兜底。但要注意COMMAND的匹配逻辑，别啥命令都触发格式化——如果AI本来就在做重构，格式化可能造成意外的大规模diff。

第二个场景是测试自动回归。AI新增或修改了核心模块代码后，自动跑相关测试：

# 判断本次改动涉及哪个模块，只跑对应测试 if git diff --name-only HEAD | grep -q "src/modules/order"; then pnpm vitest run tests/order fi

hooks的配置有一定门槛，尤其是多人协作时，每个成员的本机环境不同，hook脚本路径可能不一致。我的经验是：hooks脚本也要纳入git版本管理，并且脚本里要加环境探测，找不到对应工具时静默退出，不要因为hook挂了阻塞主流程。

3.4 第四步：多项目复用与团队协作的配置思路

大部分人的需求不止一个项目。我维护着三个活跃项目，一个服务端、一个前端、一个CLI工具。如果每个项目的模板都从零维护，维护成本会翻三倍。所以我把模板做了分层：通用层 + 项目层。

通用层放在一个独立的模板仓库里，包含所有项目都适用的规则——比如“禁止提交.env文件”“错误信息必须有上下文ID”“提交信息需要遵循Conventional Commits”。项目层则是技术栈相关的内容，比如数据库项目的Prisma约定、前端项目的组件风格。CLAUDE.md里的写法是：

# 导入通用规范 @import ~/.claude-templates/common/code-hygiene.md @import ~/.claude-templates/common/error-handling.md # 本项目的专属规范 （...项目特有内容...）

这样通用层只需要维护一份，任何时候在通用层加了一条规范，所有项目立刻生效。如果这个团队有五个人、十个项目，这种方式的价值会非常明显——你不需要跑到每个项目里去重复修改模板文件。

团队协作时还有一点很容易被忽略：模板要经过项目成员review再进主分支。我有一次临时在模板里加了一条粗暴规则——“所有函数都不要超过20行”，结果全团队半天内代码风格突然大改，很多正常业务的函数被迫拆成碎片，反而影响了可读性。从那次以后，凡是涉及CLAUDE.md的改动，我都规定必须走PR，至少一个人review过再合入。

4. 模板库维护的常见问题与避坑记录

4.1 模板“污染”问题：无关指令挤占上下文

用模板最大的坑，就是文件越写越长，AI的注意力反而不集中了。Claude Code的上下文窗口是有限的，模板加载后占据的内容过多，留给实际任务的空间就变小。我见过有人把CLAUDE.md写到两万多字，结果AI在这份巨型文档里迷失方向，重要约定反而被遗漏。

解决这个问题的思路是“分层加载，按需注入”。CLAUDE.md本身控制在2000字以内，只写顶层信息。细粒度的规则拆到.ai-templates/下的子文档，并且尽量用“先关注再读取”的模式。我在命令模板里常用这种写法：

在动手之前，先读取 docs/ai-workflows.md 中的“后端接口开发流程”章节， 严格按其中的步骤执行。不要一次性读取所有文档，避免上下文过度占用。

这看起来只是一个小技巧，但在长会话场景里效果显著。有经验的人都知道，模板这东西，加载得越精准，权重越高；一锅端进来，AI反而分不清什么是重点。

4.2 命令写得太细反而失效

自定义命令的另一个常见问题是“过度设计”。我刚开始写命令模板时，总想着把一切都说清楚，一条指令写三四百字，步骤列到十步，输出格式规定到每条必须四行。结果AI执行起来僵得要命——稍微偏离模板定义的任务场景，它就不知道怎么处理了，甚至为了凑输出格式而牺牲了底层逻辑的正确性。

后来我调整了策略：命令模板区分“标准作业流程”和“自由发挥空间”。像/test这类有明确产物的命令，可以步骤化；但像/explain这类需要理解和判断的命令，模板里只给分析框架，不给死步骤。实践中可以按这个思路控制命令的粒度——凡是场景比较固定的，命令就可以写得细；凡是场景相对开放的，命令就只给分析和输出的框架性指导。

4.3 团队协作时的模板同步困境

当模板不是一个人在用，而是团队里人人都在用时，问题就变了。最大的问题是：有人改了模板，但推到了别的分支；有人本地的hooks脚本过期了，行为和主分支不一致；还有人完全不知道自己该用哪些命令，全程还是用自然语言来回沟通。

我的解决办法有两个。第一，模板里加“使用指引”区块，放在CLAUDE.md最显眼的位置，明确写着项目里有哪几条命令、每条是干什么的、什么时候该调用。这相当于给团队每个成员一份“AI工具说明书”。第二，做一个简单的模板版本号标记，比如在CLAUDE.md开头写一行last-updated: 2025-06-15，每次合入变更就更新，让团队成员一眼知道自己本地是不是最新的版本。

4.4 快速排查表：模板不生效的常见原因

最后整理一份速查表，都是我在实际使用中反复踩过的坑。如果你发现模板“好像没起作用”，按这个表逐条排查：

4.5 模板库持续迭代的心得

用“claude-code-templates”这套方法到现在，我最大的感受是：模板库不是写一次就完工的一次性交付物，而是一个需要持续迭代的活体系统。每次和AI协作中发现它的行为不够好，先别急着在对话里重新纠正——停下手里的事，去模板里找原因。是规则没写清楚？是命令缺了边界条件？是hooks没卡到位？把修正沉淀到模板本身，让同一个坑永远不踩第二次。

我保持着每周花十分钟维护模板的习惯。周一看一遍git log，确认这周哪些规则有变动；周末快速浏览AI生成的代码，看看有没有“不规矩”的地方，反推出模板缺漏。坚持一个月之后，你和AI之间的磨合度会到一个非常舒服的状态——多数任务只需要两三轮对话就能搞定，因为你已经把大部分隐性约定都显式写出来了。

最后再分享一个小建议：如果你的模板已经能稳定支撑日常开发，试着给它加一层“场景工作流”文档，把典型需求（比如“新增一个业务模块”“排查线上故障”“优化接口响应速度”）从需求到落地的完整AI交互流程记录下来。这部分内容会变成团队里最有价值的资产——它不再只是规则集合，而是一套真正的AI协作方法论。