企业官网建设流程全解析

我第一次认真研究 claude-code-templates 这个关键词，是在连续三个项目里被同一个问题反复折磨之后。用 Claude Code 干活，前二十分钟效率极高，但越往后越觉得不对劲：它总会忘掉我在项目开头交代过的技术栈约束，或者突然用 npm 去装依赖——明明我重复说过“统一用 pnpm”。当时我的第一反应是“AI 不靠谱”，后来才发现，问题出在我压根没给 Claude Code 一套像样的模板。

所谓 claude-code-templates，说白了就是围绕 Claude Code 的配置体系做出来的“AI 协作说明书”。它不是某个单一文件，而是把 CLAUDE.md、commands、agents、hooks、skills 这些机制提前设计好，组合成一个可复制、可版本化、可随项目演进的骨架。有了这套骨架，每次新开会话时，AI 不用你重新教一遍，打开就知道项目背景、技术约束、常用命令和禁区在哪。

这篇文章适合正在用 Claude Code 但觉得“每次都要重新交底”的人，也适合想在团队里统一 AI 行为规范的负责人，还适合刚从开源仓库拉了一套模板却不知道怎么改的新手。我把这套体系的机械结构拆开，再手把手演示怎么搭一套自己的模板，最后讲讲我踩过的坑。

1. 为什么“模板”才是 Claude Code 的隐藏核心

1.1 没有模板时的真实痛点

我见过太多人把 Claude Code 当成一个“聪明的一次性问答工具”。打开终端，输入一句话让它加个接口，改个Bug，听起来很爽。但真实开发里事情没那么简单：你手里是一个已经有业务约束、历史包袱、目录结构、发布流程的项目，AI 每次新会话都是“裸奔”进入你的代码库。

最典型的表现是这三个：

• 上下文遗忘：你在会话开头说过“不要动 src/migrations 下的文件”，等它处理了二十个文件之后，早把这条约束忘光了。
• 决策漂移：同一个项目，今天用的包管理器是 pnpm，明天你新开一个会话，它可能又默认用 npm，甚至帮你生成一堆锁文件。
• 沟通成本重复：每个会话前 10 分钟都在做同样的事——解释这是什么项目、有什么技术栈、哪些目录不能碰。这些内容明明可以沉淀成文档，却每次都要从头说。

这还没算团队协作的情况。团队里六个人都用 Claude Code，如果我配置一套规则，我的 AI 拒绝动 node_modules；旁边同事没配，他的 AI 把 node_modules 删了重装。最后提交的代码风格都不一样，这锅还真不能全甩给 AI。

1.2 模板的三层价值

把这些问题想清楚之后，“模板”的重要性就浮出水面了。它解决的问题可以拆成三层：

• 上下文压缩：把项目背景、技术栈、约定浓缩成几个文件，让 AI 在会话开始就自动加载，不用口头反复喂。
• 行为约束：给 AI 划出一条清晰的“可做/不可做”边界，并且通过 hooks 等机制强制执行，而不只是“建议性”地写在文档里。
• 团队标准化：模板放进代码仓库，成员拉到本地就是同一套行为基准。谁也没必要私藏自己的 prompt 技巧，配置就是代码，走 Code Review。

换句话说，claude-code-templates 的价值不是“复制一堆配置文件”，而是把你的协作策略从“人肉记忆”升级成“工程化沉淀”。

1.3 templates 到底包含什么

一个完整的 Claude Code 模板骨架，通常围绕 .claude 目录和 CLAUDE.md 展开。我见过不少人以为模板就等于一个很长的 CLAUDE.md，实际上只是拿到了三分之一。

日常用得上的核心配件包括：

下面我逐个拆开讲，这部分是整套模板的地基。

2. 拆解五个核心载体：CLAUDE.md、commands、agents、hooks、skills

2.1 CLAUDE.md：每次会话自动读取的项目说明书

CLAUDE.md 是 Claude Code 的“开机自启文件”。只要你在这个目录下启动会话，它就会自动加载这份文件的内容，作为 AI 的背景知识。你可以把它理解成给 AI 看的 README，但比 README 更关键的是它会被当作指令上下文。

这个文件有层级叠加机制：项目根目录的 CLAUDE.md 是“项目级”，优先级最高；用户目录 ~/.claude/CLAUDE.md 是“用户级”，作用于你本地所有项目；中间还有团队级配置，一般通过 CLAUDE_CONFIG_DIR 指向一个共享路径。优先级不是互相覆盖，而是叠加。也就是说，用户级说“你是个严谨的工程师”，项目级说“这个项目用 pnpm”，AI 会两个都遵守。

我在实战里最推荐的写法是“四段式”：

• 项目概述：两三句话说清楚这个项目是什么，服务谁，边界在哪。
• 技术栈：语言、框架、核心依赖、包管理器，写清楚版本范围。
• 常用命令：开发、测试、构建、迁移、lint 的命令各是什么。
• 关键约束：哪些绝对不能做，哪些必须做，用短句列出来。

这里有个很多人忽略的细节：CLAUDE.md 不是越长越好。AI 对上下文的吸收是有限度的，我后面专门有一节讲这个坑。

2.2 commands：把高频操作变成一条斜杠指令

Claude Code 支持自定义斜杠命令。你只要在 .claude/commands/ 下放一个 markdown 文件，比如 review.md，就能在会话里直接输入 /review 触发一段精心写好的工作流。

这个机制的价值在于，把重复劳动变成“一键式”。比如我最常用的代码评审命令，文件内容大致长这样：

--- description: 对当前分支的改动做一次代码评审 argument-hint: 可选的评审范围说明 allowed-tools: RunTerminalCommand, ReadFile --- 你是一位资深代码评审者。请按以下步骤执行： 1. 运行 `git diff main...HEAD --stat` 查看改动概览 2. 逐个读取改动文件，重点检查：逻辑错误、边界条件、安全问题、性能隐患 3. 输出评审结论，按【阻塞项】【建议项】【亮点】分类 4. 只做分析，不要修改任何文件

注意头部 YAML 里的 allowed-tools 字段，它限定了这个命令能使用哪些工具。这很关键——如果你不想让评审命令顺手改代码，就只给它读和执行的权限。（不同版本的 Claude Code 工具名可能有差异，老版本里是 Bash、Read、Edit，新版本换成 RunTerminalCommand 这类新命名，按你用的版本来。）

我建议每个项目至少沉淀三个命令：/review、/commit、/debug。这三个覆盖了日常开发里 AI 介入最频繁的场景，而且都有固定套路，写成命令之后收益立竿见影。

2.3 agents：专用子代理，隔离上下文和工具权限

如果说 commands 是“给当前会话编排任务”，agents 就是“另开一个上下文去做专业分工”。每个 agent 是一个保存在 .claude/agents/ 下的 markdown 文件，有独立的 name、description、tools 和 model 配置。

举个例子，我想让 Claude Code 有一个专门的“测试分析代理”，就建一个 tester.md：

--- name: tester description: 负责运行测试并分析失败原因，适合在代码改动后调用 tools: RunTerminalCommand, ReadFile model: claude-sonnet-4-5 --- 你是一个严谨的测试执行者。收到任务后依次执行： 1. 运行 pnpm test，先看整体通过率 2. 对失败的用例，读取相关源码和测试文件 3. 区分“断言失败”“环境问题”“编译错误”三类原因 4. 输出简洁的失败摘要，并给出定位建议

为什么推荐用 agent 而不是在主会话里硬干？因为主会话用的模型通常不是最强的，而且上下文会被各种杂事挤占。agent 可以独立指定模型，比如让“测试代理”用更强的模型、只给它跑命令和读文件两个工具，降低它乱改代码的概率。这是模板体系里最接近“组织架构”的设计：你不再指挥一个全能 AI，而是管理一组各有边界的AI员工。

2.4 hooks：在工具调用前后强制拦截和校验

CLAUDE.md 里写的约束是“软约束”，AI 理论上可能漏看、可能理解歪。hooks 是“硬约束”，它挂载在工具调用的生命周期上，比如 PreToolUse 在 Claude 调用工具前触发，PostToolUse 在调用后触发，Stop 在回答结束前触发。

我用的最多的是 PreToolUse 拦截，专门防危险命令。比如我一不小心让它执行了删除数据库或强制推送，钩子直接出手拦下。配置写在 .claude/settings.json 里：

{ "hooks": { "PreToolUse": [ { "matcher": "RunTerminalCommand", "hooks": [ { "type": "command", "command": ".claude/hooks/guard.sh", "timeout": 5 } ] } ] } }

对应的 guard.sh 脚本也很简单：

#!/usr/bin/env bash input=$(cat) if echo "$input" | grep -qE "DROP DATABASE|git push --force|rm -rf /"; then echo '{"decision": "block", "reason": "危险命令已被模板钩子拦截"}' exit 0 fi echo '{"decision": "allow"}'

这种做法等于给 AI 的行为加了安全带。比较常见的用法除了拦截危险命令，还有在 PostToolUse 阶段检查生成文件是否符合规范，在 SessionStart 阶段自动输出项目状态。hooks 的完整事件列表很长，但实用主义优先，先把 PreToolUse 玩熟练，收益最大。

2.5 skills：轻量技能封装

skills 是从 OpenAI 生态舶来的概念，在 Claude Code 里表现为一个包含 SKILL.md 和配套资源的目录。它跟 agents 的区别在于：agents 偏向“执行者的分工”，skills 偏向“知识和方法的注入”。

比如我想让 AI 写的 commit message 符合团队规范，可以建一个 .claude/skills/commit-message/SKILL.md，里面规定格式、放几个范例。当任务涉及提交代码时，Claude 会优先参考这个技能。它的适用场景包括消息格式、文档风格、代码规范、架构模式说明。

我不建议新手一上来就同时搞四个 skills 迷之复杂。先从一个你每天都会用到的场景入手就够了。

2.6 别忘了 settings.json 里的权限清单

最后补一个容易被忽略的东西：settings.json 除了配 hooks，还能配置 permissions 白名单和黑名单，直接控制 Claude 能不能自动执行某些操作。

{ "permissions": { "allow": [ "RunTerminalCommand(pnpm:*)", "ReadFile" ], "deny": [ "RunTerminalCommand(rm:*)", "RunTerminalCommand(git push --force:*)" ] } }

把经常误触的操作直接拉黑，比事后补救省心得多。我在模板里一般都会内置一份“默认 deny 清单”，让 AI 在做危险操作前必须停下来问你。

3. 搭一套自己的模板：从空目录到可直接复制的骨架

3.1 动手之前先回答三个问题

很多人一上来就搜开源模板，复制粘贴完事。我劝你先花十分钟想清楚三个问题，否则模板大概率吃灰：

• 这个项目最频繁的 AI 协作场景是什么？是写业务代码、修 Bug、还是写测试？这决定了 commands 和 agents 的优先级。
• 哪些事绝对不能容忍 AI 做？比如删库、改锁文件、动生成代码。这些必须写进 CLAUDE.md 和 hooks 双重防线。
• 团队里的 AI 使用习惯统一吗？如果大家水平参差，模板就要做得更“霸道”，比如默认 deny 所有敏感操作。

想清楚这三件事，你的模板才不是空中楼阁。

3.2 搭建标准目录骨架

我的模板骨架如下图所示，你也可以理解为我的“默认起点”：

my-project/ ├── CLAUDE.md └── .claude/ ├── settings.json ├── commands/ │ ├── review.md │ ├── commit.md │ └── debug.md ├── agents/ │ ├── tester.md │ └── docs.md ├── hooks/ │ └── guard.sh └── skills/ └── commit-message/ ├── SKILL.md └── examples/ └── good.md

这个结构不算复杂，但已经覆盖了“项目说明书、高频操作、专业分工、安全护栏、知识注入”五个维度。新项目直接复制这个目录，再按项目特色改改内容，五分钟就能上线。

3.3 写一份精简但有战斗力的 CLAUDE.md

我拿一个库存管理服务举例：

# 库存管理服务 ## 项目概述 - 面向仓库管理员的库存查询与盘点工具，提供 Web 控制台和异步任务接口 - 服务端无前端页面，UI 是独立的 React 项目 ## 技术栈 - TypeScript 5 + Node.js 20 + Fastify - PostgreSQL 15 + Prisma ORM - 包管理器统一使用 pnpm - UI 项目：React + Vite ## 常用命令 - 本地开发：pnpm dev - 运行测试：pnpm test -- --watch - 数据库迁移：pnpm prisma migrate dev - 代码检查：pnpm lint ## 关键约束 - 禁止修改 src/migrations/ 下已经发布的迁移文件；新增迁移文件是允许的 - 接口字段命名统一 camelCase，数据库字段统一 snake_case - 不要使用 npm install，统一 pnpm - 修改 schema.prisma 后必须生成新的迁移，并在改动说明中附上迁移 diff

注意几个细节。第一，“禁止修改已发布的迁移文件”这个说法比“不要动 migrations”更精确——如果你只写“不要动 migrations”，AI 可能连新增迁移都畏手畏脚。第二，约束写成“违反 X，应该 Y”的格式，比单纯列禁止清单更好用，因为 AI 能知道正确的替代动作。第三，别在 CLAUDE.md 里写超过三十行的项目背景故事，AI 也是“太长不看”的。

3.4 加上两个高频 commands：commit 和 debug

Commit 命令我几乎每个项目都有，它的核心不是让 AI 跑 git commit，而是让它生成符合规范的提交信息并且帮你确认完整的提交内容：

--- description: 根据当前改动生成规范化的 git commit allowed-tools: RunTerminalCommand, ReadFile --- 1. 运行 `git status` 查看当前工作区改动 2. 运行 `git diff --stat` 查看改动规模 3. 读取关键改动文件，理解改动的目的和影响范围 4. 生成符合 Conventional Commits 规范的提交信息，要求： - 前缀：feat / fix / refactor / test / chore / docs - 正文点到为止，不超过三行 - 不伪造未验证的信息 5. 先展示提交信息，不要直接执行 commit，等我确认

这个命令的精髓是最后一条——让 AI 先展示、等确认，而不是直接动 git。很多次我都是靠这一步拦下了它准备提交的中间态垃圾代码。

Debug 命令正好相反，它的自由度更高：

--- description: 排查最近一次失败的测试或运行报错 allowed-tools: RunTerminalCommand, ReadFile --- 1. 运行 `pnpm test 2>&1 | tail -100`，找到第一个失败用例 2. 读取对应的测试文件和源码 3. 判断失败原因，按优先级排序：断言值错误 > 异步时序 > 环境依赖 > 编译问题 4. 给出定位结论和修复建议，不要直接改代码

这两个命令加起来不到 40 行，却覆盖了日常开发里最高频的两种 AI 协作诉求。

3.5 用 hooks 给模板装上“强制保险”

CLAUDE.md 里的约束写得再好，AI 也有走神的时候。我在模板里默认配了一个 guard.sh，除了前面提过的危险命令拦截，还会拦截“未经确认就修改 lock 文件”的行为——这在高频协作项目里太常见了。

再补充一个容易踩的细节：hooks 脚本必须要有可执行权限，否则会静默失败。我第一次配置完，调了很久才发现是 chmod 没做。调用方式也不要写绝对路径，用相对 .claude/hooks/guard.sh 的形式，这样整个模板目录不管复制到哪个机器上都能跑。

4. 开源模板怎么选：从“抄”到“超”的判断标准

4.1 社区模板的常见形态

GitHub 上搜 claude-code-templates，你会看到五花八门的仓库。按我的经验，主要分三类：

• 技术栈型：专门针对某个技术栈，比如“React + TypeScript 前端模板”“Python FastAPI 后端模板”，里面写好了构建命令、目录约定、lint 规范。
• 规范型：强调编码规范、commit 规范、文档风格，比较适合想统一团队输出的场景。
• 全流程型：把 CLAUDE.md、commands、hooks、agents 全配齐，直接复制就是完整骨架。

三类模板没有谁绝对好，关键看你的阶段。如果是第一次接触模板体系，我建议选第三类里的“小而美”版本，快速感受完整闭环；如果你已经被某个具体问题折磨，比如 commit 信息乱得不行，那就直接挑一个规范型的 commit 模板抄。

4.2 选型判据：文档跟上、更新及时、不过度设计

我筛选开源模板的标准有三个，缺一不可：

第一，文档是不是说清楚了“为什么”。很多模板直接丢一堆配置，但不说每个字段的用途。这种模板抄了也白抄，遇到问题根本无从下手。我倾向于选那些每个文件都有注释、有设计说明的仓库。

第二，更新有没有跟上。Claude Code 的配置体系迭代很快，工具命名、hooks 事件类型都会变。一个半年没更新的模板，大概率里面的 allowed-tools 都是旧版名称，复制进来直接报错。

第三，是否过度设计。有的模板一个项目配十几个 agents、二十个 hooks，看着很专业，实际上负担大于收益。我建议初始模板控制在：一个 CLAUDE.md、两到三个 commands、一个 hook、一个 agent。跑起来顺手了再逐步加。

4.3 不建议照搬的核心理由

我见过太多人把“选模板”做成了“套模板”，复制完目录就再也不看了。但 Claude Code 的模板不像传统脚手架——它不是生成静态代码，而是在塑造 AI 的对话行为。同一套模板，用在“单体服务项目”和“前端组件库项目”上，效果天差地别。

模板必须随项目演化。我的习惯是：每个迭代周期末，花十分钟过一遍 CLAUDE.md，删掉已经不成立的约束，补上这周反复踩过的坑。模板是你的协作契约，契约当然要及时修订。开源模板给了你一个很好的起点，但“超”过它的唯一方式，就是持续维护它。

5. 我踩过的坑和调试心得

5.1 CLAUDE.md 写太长，后半段等于白写

这是我最开始的典型错误。我把项目背景、历史决策、代码风格、常见问题写了三百多行，觉得越详细越好。实测下来，Claude 在处理长会话时对中后段的遵守度明显下降，它甚至会在关键决策时“忘记”后面那堆快两百行的约束。

后来我改成强制“金字塔原则”：最重要的约束放前面，每条不超过一行；细节和背景放后面，宁可不写也不要堆砌。现在我的模板 CLAUDE.md 基本保持在 40 到 60 行以内，遵守率高了一大截。

5.2 hook 脚本权限和返回值的问题

hooks 第一次配置就踩了两个坑。第一个是脚本没加执行权限，hook 全程静默失败，但我还以为防护生效了。反应过来之后，我固定写chmod +x .claude/hooks/*.sh，并且在 README 里加粗提示。

第二个更隐蔽：hook 的 stdout 会作为 JSON 被 Claude Code 解析。如果你在脚本里不小心 echo 了一行调试文本，hook 会直接报解析错误。调试时我都是用cat > /tmp/hook-output.json把 stdout 落盘查看，而不是直接打印到终端。

5.3 commands 目录命名冲突

有一次我加了一个 /test 命令，结果怎么调用都提示“command not found”。排查了半天才发现，.claude/commands/ 下我同时建了 test.md 和一个 test/ 子目录，解析逻辑直接把名字认冲突了。

教训是：一个命令要么是一个文件，要么是一个目录，不要同名混用。目录形式适合那种需要附带多个资源文件的复杂命令，文件形式适合简单指令。新人阶段统一用文件形式最省心。

5.4 用户级和项目级优先级搞混

之前我在用户级 CLAUDE.md 里写了一套通用的 TypeScript 规范，项目级又不小心写了一份类似的。结果两个版本的规范叠加在一起，规则互相打架。后来我才彻底理清：用户级负责“我是谁”，项目级负责“这个项目是什么”，不要把项目特有约束塞进用户级，也不要把个人代码风格塞进项目级。

5.5 模板里的“禁止”也会被 AI 读歪

我原来写过“禁止修改任何 generated 目录下的代码”，本意是保护自动生成的 OpenAPI client。结果 AI 读成了“这个项目的一切生成文件都不能动”，连正常的二次构建都不想执行了。

这种问题特别考验措辞。现在我的写法改成：“generated 目录由脚本生成，新增不修改底层逻辑；如需修改，先说明理由并等我确认。”既划明了边界，又给了出口。如果你的模板里全是冷冰冰的“禁止”“不要”，AI 会越来越保守，最后变成一个什么都想问你确认的低效助手。

如果让我给一个最核心的个人心得，那就是：claude-code-templates 的维护应该和代码维护同等重视。每次你在对话里说出“我不是说过吗”这句话，就说明模板里少了某条约束。把它记下来，补进 CLAUDE.md 或者转成一个 hook，让这个坑变成一个永久消失的问题。工具在升级，你的项目在变化，模板也一样，它不是一份写完就固定的档案，而是你和 AI 之间的活契约。