企业官网建设流程全解析

最近我把手头的 Claude Code 用法整理成了一套 claude-code-templates，起因挺直接的：团队里用 Claude Code 的人越来越多，但每个人的 CLAUDE.md 都是自己随手写的，命令也各搞一套。有人让它输出中文，有人让它输出英文，有人让它只改代码不写注释，有人要求每个文件都要带解释。AI 编程工具本身没有标准用法，但如果连团队内部都没有一个统一模板，那协作成本比不用 AI 还要高。这套模板项目专门解决这个问题：把高频的 AI 编程任务沉淀为可复用的命令、提示词和配置模板，让新成员拿到仓库之后 10 分钟就能上手，也让 Claude Code 的输出质量从“看运气”变成“可预期”。

这篇文章会把整套模板的设计思路、核心配置、落地案例和踩过的坑完整拆开来讲。如果你在用 Claude Code，或者正准备引入 AI 编程助手到团队里，这篇文章值得看完。

1. 模板项目整体设计与思路拆解

1.1 先搞清楚一个问题：AI 编程助手为什么也需要模板？

很多人觉得，AI 编程助手是对话式的，想到什么问什么，模板有什么用？我一开始也是这么想的。后来发现问题很大：同样一个任务，给 Claude Code 的指令不同，输出质量可能差一个量级。

举个例子。你说“帮我看一下这段代码”，它可能只是泛泛地读一遍，说两句“看起来没问题”。但如果你给它一套审查规则：先检查安全漏洞，再检查性能热点，然后检查可维护性，每项给出严重级别和修改建议，它会严格按这个流程走。AI 的能力上限确实很高，但对普通开发者来说，能不能稳定触发这个上限，取决于输入的质量。模板的本质，就是把“高质量的输入”固化下来。

还有一个更现实的问题：上下文窗口。Claude Code 每次会话能带的上下文是有限的，如果把项目背景、技术栈约定、审查规则、输出格式要求全都靠人工敲进对话里，那聊到一半上下文就满了。模板则可以按需加载，用哪套加载哪套，不占常驻空间。

1.2 模板体系的四大分类

这套 claude-code-templates 在设计时没有把所有东西塞进一个大文件，而是分成了四个层次：

• 项目级模板（project/）：CLAUDE.md、目录结构规范、技术栈约定，解决“Claude 对这个项目不了解”的问题。
• 命令级模板（commands/）：以斜杠命令形式存在的提示词脚本，解决“高频操作不统一”的问题。
• 自动化模板（hooks/）：钩子脚本和校验规则，解决“AI 越权操作或输出不符合预期”的问题。
• 技能级模板（skills/）：带独立说明文件和参考文档的复杂能力包，解决“需要多轮协作的复杂任务”的问题。

分层的好处是可以按需组合。比如一个用 React 的团队，拉取前端技术栈的 CLAUDE.md 模板，配上代码审查命令模板，再挂一个提交信息校验钩子，就是一套相对完整的前端 AI 协作方案。不需要为每个新项目重新写一堆配置文件。

1.3 模板设计的三条原则

我在整理这套模板时给自己定了三条原则，你也可以直接在团队里推行：

第一，可组合。每个模板只负责一件事，模板之间不做强依赖。命令可以单独用，CLAUDE.md 可以单独挂载，hooks 可以随时启停。不要搞一个 500 行的“全能提示词”。

第二，可覆盖。模板提供的是基线，任何团队和个人都应该能覆盖修改。比如项目级模板里的 CLAUDE.md 只是兜底说明，团队自己的规范文件优先级永远更高。Claude Code 的机制本身支持多级 CLAUDE.md 合并，根目录放团队的，子目录放模块的，个人目录放自己的。

第三，可追踪。配置文件尽量用注释说明用途，hooks 脚本必须输出清晰的日志。AI 编程与普通编程一样，出问题了必须能回溯。如果某个模板导致 Claude 行为异常，能快速定位是哪个配置生效了。

这三条原则听着朴素，实际执行起来能省掉大量沟通成本。我见过不少团队 AI 用得乱，不是因为工具不行，而是因为配置体系一团糟，改来改去最后谁也不知道当前生效的规则是哪个。

2. 核心配置解析与实操要点

2.1 CLAUDE.md：项目的第一份指令文件

CLAUDE.md 是 Claude Code 在进入项目时会自动加载的项目说明文件，相当于给 AI 的“入职手册”。这套模板里，项目级模板的核心就是它。

一个合格的 CLAUDE.md 应该包含这几块内容：

• 项目一句话简介和技术栈列表。
• 目录结构的说明，尤其是哪些目录有特殊约定。
• 代码风格的硬性要求，比如缩进、命名、注释语言。
• 常用操作方式，比如启动命令、测试命令、构建命令。
• 明确禁止做和必须做的事，比如“不允许修改 lock 文件”“所有新增公共 API 必须写 JSDoc”。

注意一个关键点：CLAUDE.md 不要写得太长。Claude Code 每次会话启动都会读取它，文件越大占用的上下文就越多。我的经验是控制在 100 行以内，只写“AI 必须知道才能干好活”的信息，而不是把整个项目的 wiki 搬进来。

实操中，我在模板里放了两种版本的 CLAUDE.md：完整版和精简版。完整版用于新项目初始化，包含丰富的分类和示例；精简版用于已运行的项目，只保留关键约定。两种版本通过命令模板一键切换。

2.2 Slash Commands：把高频操作固化成命令

.claude/commands/ 目录下每个 markdown 文件就是一个自定义斜杠命令。文件名的前缀就是命令名，比如在 .claude/commands/ 下创建 review.md，在 Claude Code 对话框中输入 /review 就能触发。

模板项目的命令级模板是按照任务类型划分的：

• /review：代码审查，支持传入文件路径或 commit 范围。
• /test：为指定模块生成测试用例。
• /refactor：代码重构，先规划后执行。
• /explain：解释一段复杂代码或系统设计。
• /changelog：根据 git 提交记录生成变更日志。
• /init：新项目初始化，自动生成配套文件和目录。
• /pair：结对编程模式，Claude 先提问澄清需求再动手。

每个命令文件的头部是 YAML frontmatter，可以声明参数、描述、触发方式。你可以在其中设置参数占位符，比如$FILE和$GOAL，执行时 Claude Code 会提示你补全这些参数。

这里有一个实操要点：命令文件里写的提示词要“宁细勿粗”。同样是 /review，如果命令文件里只写“审查代码”，效果大概率不好；但如果写清楚审查维度、输出格式、严重级别切换规则，输出就稳定很多。我在模板中把 /review 设计为四轮输出：安全审查、性能分析、代码风格、可维护性建议，每一轮都有明确的检查子项和输出格式，实测输出质量远远高于随手敲一句“帮我 review 一下”。

2.3 Hooks：自动化拦截与校验

如果你希望 Claude Code 在做某些操作前自动执行检查，或者在做完操作后自动验证一下，就需要 hooks。这套模板中的自动化部分主要包含四个钩子：

• PreToolUse：在调用工具前触发，可以拦截危险操作，比如禁止 AI 直接改生产环境配置文件。
• PostToolUse：在工具执行后触发，可以用来格式化代码、校验 lint 规则。
• UserPromptSubmit：在用户提交消息前触发，可以自动附加项目约定。
• Stop：在一次会话结束时触发，可以输出本次会话的摘要或自动补提 issue。

这套模板里，我给 hooks 定了很明确的用途：不指望它们做太复杂的事情，只做三件事——拦截、记录、格式化。比如 PreToolUse 阶段如果检测到 AI 要执行 git push 到生产远程，直接中断并给出提示；Stop 阶段把会话中产生的新增文件列表输出到日志里，方便人工复查。

特别提醒：hooks 脚本要写得尽量简单，别在钩子里做重逻辑。钩子如果崩溃，可能会连累整个 Claude Code 会话，这坑我踩过不止一次。正确做法是钩子只负责判断并返回结果，真正的重逻辑放到外部脚本或命令模板里执行。

2.4 Skills：预留的进阶能力

Claude Code 的 Skills 是比命令更重的一种扩展方式，每个技能是一个目录，里面包含 SKILL.md 描述文件和若干参考资源文件。这套模板里的 skills/ 目录是作为可扩展区存在的，默认只放了几个通用的技能模板。

我在实际项目中给 Skills 定了两个策略：基础技能跟随模板仓库走，比如“代码规范检查”和“依赖安全扫描”；团队特定技能单独建库管理，比如某个核心业务模块的重构规范。两者通过 CLAUDE.md 里的引用说明关联起来，不会把大量资源文件堆到同一个仓库里影响加载速度。

如果你团队刚开始用 Skills，我的建议是不要一上来就搞一大堆技能。先把自定义命令玩透，等确实发现某些任务需要在多轮对话中反复用到同一套知识时，再固化成技能。不然维护成本会很高。

3. 实操过程与核心案例实现

3.1 案例一：新项目初始化模板

我在模板仓库里放了一个“新项目初始化”的应用场景，具体操作是输入 /init 命令，Claude Code 会依次完成以下动作：

第一步，询问或确认技术栈和后端服务依赖。第二步，生成项目的目录结构，包括 src、tests、docs、scripts 等基础目录。第三步，写入模板 CLAUDE.md，把技术栈、目录约定、命令规范一次性配好。第四步，生成 .claude/ 目录骨架，包含基础的 commands 和 hooks 占位文件。第五步，创建一份 README.md，说明这个项目能用哪些斜杠命令和钩子规则。

这个命令对应的 markdown 文件内容我简化一下核心逻辑：

--- name: init description: Initialize a new project scaffold for this team argument_hint: project name and optional stack --- You are initializing a new project. The user may provide a name and tech stack. 1. Ask for the project name and confirm tech stack choices. 2. Generate the standard directory structure for a web application. 3. Write a CLAUDE.md at the project root following the team template conventions. Keep it under 100 lines. 4. Create .claude/commands/ with default command stubs for review, test, refactor. 5. Create .claude/hooks/ with the standard validation hook stubs. 6. Write a brief README explaining what was generated.

实操中我试过，这个命令跑完大约一分半钟，Claude Code 会逐条执行并汇报每一步的结果。它最大的价值不是省去mkdir -p这类基础操作，而是保证每个新项目的 AI 配置起点都是一致的，不会出现“新人建的项目根本没有 CLAUDE.md，Claude 进来之后全靠猜”的情况。

3.2 案例二：代码审查与质量门禁模板

这是整个模板库里使用频率最高的一个命令。review 命令的分步设计很关键：

• 第一轮，安全审查。检查是否存在密钥硬编码、SQL 注入、不安全的反序列化、越权访问等常见问题。
• 第二轮，性能分析。关注不必要的循环、N+1 查询、大对象加载、同步阻塞调用。
• 第三轮，可维护性。检查函数长度、职责拆分、命名、重复代码、缺少注释的复杂逻辑。
• 第四轮，汇总输出。每类问题按严重级、建议级、提示级分类，给出文件路径、行号（如果可行）和修改建议。

关键设计点是：命令模板里要求 Claude Code 必须按轮次执行，不要跳级。因为如果让它一口气审查，它的聚焦度会下降，容易只挑出一两个明显的毛病。分轮次执行后，每轮专注一个维度，输出覆盖面明显提升。

这个命令使用方式很直接：在 Claude Code 对话框输入 /review 然后指定文件路径或者 commit 范围。如果是 commit 范围，模板中会明确要求先执行 git log 和 git show 获取变更内容，再基于变更去做审查。

3.3 案例三：测试用例生成模板

测试生成的难点不是“让 AI 写测试”，而是“让 AI 写出符合项目测试规范的测试”。这套模板里的 test 命令内置了测试规范说明：测试框架版本、断言风格、mock 策略、命名习惯、覆盖率目标。

命令的核心提示词大概是这个思路：

You are generating tests for the project. The test conventions for this project are: - Use vitest, not jest. - Use describe/test/it structure. - Follow the naming pattern: should_expectedBehavior_when_condition. - Prefer dependency injection over mocking modules. - Mock only external boundaries, not internal functions. - Coverage target: at least 80% for new code. Read the target file, design test cases based on its behavior, then implement them. Do not modify production code. If the code is difficult to test, suggest refactoring steps instead.

这套模板在团队里的使用率也很高。实测一个常规的 service 层文件，生成测试大概需要两到三分钟，生成完 Claude 会主动运行测试命令，如果失败会继续修复直到通过。需要注意的是，如果项目测试规范不明确，模板就没有抓手，所以用这个命令前最好先确保 CLAUDE.md 里写清楚了测试约定。

3.4 案例四：技术文档与变更日志模板

documentation 这块我拆成了两个独立命令。一个是 /explain，用于让 Claude 阅读复杂模块后输出结构说明，包括模块职责、核心流程、关键函数、依赖关系、常见坑点。另一个是 /changelog，用于根据 git 历史生成变更日志，按 Conventional Commits 的规范格式分类组织。

/changelog 的设计细节：模板会先让 Claude 查看 git log --oneline -n 30 以及对应的 commit message，然后按 feat、fix、docs、style、refactor、perf、test 分类整理。输出的格式对齐主流的 CHANGELOG.md 格式，并在每个变更条目后附上对应的 commit hash。

这里要提一个操作上很有用的技巧：template 里的文档类命令，人可以在输入时附上额外约束，比如“只生成本周的变更”或“忽略依赖更新类提交”，Claude 会把它和模板默认指令合并执行。模板不是一把锁，是一张可裁剪的底图，用户随时可以叠加个性化指令。

3.5 案例五：把模板组合进真实开发流

单独看每个模板可能觉得不复杂，组合起来才真正形成体系。我模拟一个实际场景：下午要重构一个支付模块，负责人打开 Claude Code，先输入 /explain payment/，让 Claude 快速梳理现有模块结构和支付流程，把输出的结构说明存进自己的备忘。然后输入 /refactor，吩咐 Claude 按模板里固化的重构步骤执行：先列出潜在影响面，再小步重构，每步跑测试。重构完成后，输入 /review，让它按四轮规则审查刚才变更的 commit 范围。最后输入 /changelog，直接生成这段重构的变更记录。

你会发现，每个步骤之间信息是连续的。Claude Code 会在会话中记住 /explain 输出的结构说明，后面的 /refactor 是基于这个理解去执行的，到了 /review 阶段它已经掌握完整上下文，审查效率比什么都不知道时强行 review 高得多。这就是命令模板组合使用的核心价值：它不是一个个孤立的提示词，而是一套可以串起来的工作流。

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

4.1 上下文窗口被占满怎么办

这是所有重度使用 Claude Code 的人都躲不过的问题。模板仓库里我已经设置了约定：CLAUDE.md 控制在 100 行以内，command 文件也尽量精简，但实际业务场景中，上下文还是容易在长会话中耗尽。

我的处理策略是：细化命令边界。让 /review 只关注审查，让 /test 只关注测试，避免一个命令承载太多职责。当某个任务确实需要长上下文时，我会主动打断会话，用 /init 或手动方式重新组织一个最小上下文再继续。另外，命令模板里可以追加“请先查看这些文件再提问，不要加载无关文件”这类指令，能显著减少无效内容占据上下文。

4.2 模板在大型仓库中失效

模板指令在中小项目里很灵，但放进一个几百个模块的大型 monorepo 里，经常出现 Claude 找不到对应模块或目录的情况。原因是 CLAUDE.md 是项目根级别加载的，子模块的具体约定没有灌进去。

解决方式是在子模块目录里也放一棵简化版的 CLAUDE.md，或者在命令模板里显式指定路径映射，比如“用户提到的 xxx 模块对应 packages/xxx/src”。这套模板中我额外设计了一个 scan 命令，它会在会话开始时扫描仓库结构，把一级目录和核心模块的入口文件位置写入一个临时上下文文件，之后再执行其它命令时自动带上这个路径映射。

4.3 权限与安全边界

让 AI 编程助手自由调用工具，权限边界一定要提前画好。这套模板的 hooks 里默认做了三个限制：禁止 AI 直接修改 CI 配置，禁止 AI 推送 commit 或打 tag，禁止 AI 读取 .env 类文件。如果出现这些操作，hook 会直接返回终止信号并给出提示。

实际落地时，每个团队可以根据自己的情况调整这些规则。比如有的团队允许 AI 推送特性分支，但不允许推送主干分支。关键是要把规则写在两个地方：CLAUDE.md 里让 Claude 知道，hooks 里让它不可能绕过。两者互为补充，不能只写提示不写拦截。

4.4 团队协作时的模板同步问题

模板仓库要服务于团队多人使用，版本同步是个容易被忽略的问题。我采用的方式是：模板作为独立仓库维护，各项目通过 git submodule 或复制目录的方式引入。对于规模较小的团队，复制目录就够了，简单直接；对于规模较大的团队，建议用 submodule 或脚本同步，同时把模板仓库本身纳入 review 流程。

还有一个细节：如果模板更新了，旧项目里的已有配置不会被自动覆盖，这会导致同一团队里不同项目的 AI 行为不一致。我在模板仓库里写了一个 sync 命令脚本，运行后会比对模板仓库和本地配置的差异，生产一份更新报告，由人工决定是否合并。

4.5 与 CI/CD 和本地工具的衔接

Claude Code 支持 headless 模式运行，这就给模板的使用打开了另一条路。部分模板可以在 CI 中跑，比如合并请求触发时自动执行 /review 并把结果作为评论发回。实测下来，AI 审查在 CI 上的运行效果与本地会话没有明显差别，但需要注意输入数据的格式和权限控制。

headless 模式配合模板的使用有个天然优势：命令模板的输出是结构化的，适合被脚本解析。比如 /review 命令的四轮输出，可以拆成四个 JSON 片段，CI 脚本只需要读取 JSON 并渲染到合并请求评论即可。模板不仅是给人用的，也是给自动化流程用的，这一点在设计命令输出格式时就要预留好。

整理这套 claude-code-templates 让我自己把对 Claude Code 的理解系统化了一遍。最初我只是想省事，给自己的项目写几个固定提示词，后来发现做成模板体系后，团队协作的收益比个人使用大得多。规范化之后，新成员不再需要从零摸索什么样的输入能触发高质量输出，老成员也能在统一的框架下交换命令和配置经验。如果你也想搭一套类似的模板，我的建议是从最小闭环开始：一份精简的 CLAUDE.md，加两三个最常用的命令模板，跑顺手了再慢慢补 hooks 和 skills，别一上来就铺开很大的盘子。最后说一个平时不太注意的小技巧：命名命令模板的时候，尽量用团队口语化的动词而不是标准化的书面名词，团队用起来会觉得这工具是自己的，而不是一套需要额外学习的规范。