企业官网建设流程全解析

1. 我为什么把 Claude Code 的使用经验沉淀成一套模板库

先说个背景。我大概是从 Claude Code 还比较早期的时候就开始用了，那时候最大的感受是：这东西能力很强，但每次开一个新会话，我都得从零开始交代背景。

最开始我的做法很简单——在项目根目录放一个CLAUDE.md，把自己手头项目的技术栈、目录结构、常用命令写进去。问题是，只写这一份文件远远不够。遇到代码审查、重构、补测试、修 bug 这些高频任务，我每次都要重新敲一大段 prompt，而且写得长不一定效果好。同一个项目，今天给它的指令和昨天风格不一样，Claude Code 的行为就跟着飘。

你可能会问：直接记在备忘里不行吗？行，但记下来的东西是给别人看的，不是给 Claude Code 用的。真正的需求是一个能自动被加载、路径明确、写法和规则都统一的模板集合。这个东西我觉得值得好好做一次，于是就有了claude-code-templates。

这套模板库解决的核心问题，可以浓缩成三个：

• 上下文不稳定。模板统一了项目背景、技术约定、输出风格的加载方式，让 Claude Code 每次会话都能站在同一个起点上干活。
• 指令不收敛。把高频任务拆成模板化的任务指令，审查就是审查的结构，重构就是重构的安全守则，不再每次现场发挥。
• 多项目复用成本高。模板库设计成"一套模板，多项目复用"，新项目 Clone 下来改几行配置就能跑起来，不需要从零再写一遍。

这篇内容适合谁看：正好在用 Claude Code 但觉得每次都很"散"的人，想在团队里统一 AI 编程工具使用方式的工程负责人，以及想把手头项目改造成"AI 可维护"状态的技术人。下面我先说说这套模板库的第一个核心文件，CLAUDE.md到底应该怎么写才算合格。

1.1 一开始的混乱：每个会话都是重新开始

我先讲一段自己的真实经历。有一阵子我在带一个小型的前端项目，目录里有几十个组件，几个 service，还有一堆历史遗留的没写测试的逻辑。每次让 Claude Code 帮我改一个 prop 的传递，它会先花大量时间在代码库里翻找，偶尔还会把它自己猜测的项目结构写在答案里，根本对不上。

那时候我的做法很傻——遇到问题就把相关文件路径贴进 prompt，让它"去看这个文件再看那个文件"。结果就是上下文窗口里的噪音越来越多，真正有用的信息反而被淹没了。最典型的例子是，它会把两个同名但职责完全不同的组件弄混，然后基于错误假设改出一堆代码，review 的时候我差点血压升高。

后来我才意识到，问题不是 Claude Code 不够聪明，而是我没有给它一份结构化的项目地图。人刚入职一个项目还要先看半天文档呢，一个没有记忆的模型，凭什么一上来就能精准干活？

这就是CLAUDE.md存在的意义。它不是让你把整个项目的文档抄进去，而是提供一份"给 AI 看的入职手册"：这个项目是干什么的、代码怎么组织、有没有特殊约束、常用命令是什么、最容易被改坏的地方在哪里。有了这份材料，Claude Code 才算是真正"入职"了。

1.2 模板库的边界：到底沉淀什么、不沉淀什么

做模板库最忌讳的是什么都往里塞。有些人把CLAUDE.md写成了一本几百行的百科全书，从项目背景写到业务细节，甚至把 API 文档全文都贴进去。我实测下来的结果是：上下文太长之后，模型在最关键的决策点上反而更钝，因为关键信息被埋住了。

我自己定的边界是三条：

• 沉淀"稳定信息"。技术栈、目录约定、命令、代码风格、禁止事项，这些属于长期稳定的内容，值得写。某个临时接口的字段说明、某个功能的具体实现，属于易变信息，不写。
• 沉淀"决策偏好"。比如"依赖升级前要先跑全量测试""新增 API 时同步更新 OpenAPI 文档"，这类关乎工程规范和风险控制的内容，模型单靠代码是猜不出来的，必须显式声明。
• 不沉淀"一次性上下文"。比如"这次要改的是支付模块的 xx 文件"，这是会话里临时告诉它的，不需要写进模板，写进去就是污染。

还有一类内容我后来从模板里删掉了：大段的技术栈列举。只写"React 18 + TypeScript 5 + Vite"就够了，后面再跟一句"组件样式使用 Tailwind CSS，禁止引入新 UI 库"，比把package.json里依赖全部列一遍有用得多。原因很简单，模型没那么需要你告诉它 React 是什么，真正需要的是你告诉它"这个项目里有什么特殊约定"，以及"你干活时不许越过的红线在哪里"。

2. CLAUDE.md 模板：把项目记忆写成可复用的规范

CLAUDE.md是整个模板库的地基。地基没打好，任务模板再好也使不上劲。我见过不少项目的CLAUDE.md，写法五花八门，有的像简历，有的像流水账。这里分享一个我自己在模板库里固定下来的结构，你拿去改改就能用。

2.1 一份能打的 CLAUDE.md 长什么样

我的模板按七个区块组织，顺序固定，区块之间有明确的逻辑递进。给一个简化版示例：

# 项目概述 这是一个面向 C 端用户的日历应用，核心功能包含事件创建、提醒推送、团队共享日历。第三方服务仅依赖一个推送服务，其余都是内部实现。 # 技术栈 - 前端：React 18 + TypeScript 5 + Vite - 样式：Tailwind CSS，禁止额外引入 UI 库 - 后端接口：内部 REST API，基地址由环境变量 VITE_API_BASE 提供 - 状态管理：Zustand，不使用 Redux # 常用命令 - 本地开发：npm run dev - 类型检查：npm run typecheck - 全量测试：npm test -- --run - 构建产物：npm run build # 目录约定 - src/components：只放 UI 组件，不写业务逻辑 - src/hooks：自定义 hooks 的集中位置 - src/services：所有接口请求的封装 - src/utils：纯函数工具库，禁止在这里放组件 # 工程约定 - 新功能必须附带对应测试文件 - 类型定义必须显式声明，禁止偷懒用 any - 组件传入参数接口统一以 Props 命名，并导出 - 修改公共组件前先检查所有引用处 # 红线 - 不要修改 src/services 里请求函数的返回结构 - 不要绕开 Zustand 直接修改跨组件共享状态 - 不要使用内联样式，除非 Tailwind 无法实现 # 当前进行中的事项 - 正在重构 EventModal 组件，目的是拆分出可复用的日期选择器 - 本周优先修复提醒推送偶发漏推问题

你可能注意到了，# 当前进行中的事项这块跟在后面。这不是固定模板的一部分，是可以每次会话开始时由你自己更新的一小段"临时记忆"。它让 Claude Code 知道你当下正在忙什么，避免它一头扎进无关逻辑里。

七块内容里，"红线"是我认为最重要也最容易被忽略的。AI 编程工具天然倾向于"按它认为对的方式"改代码，你不说不能碰哪里，它就可能把老接口改成新接口，把测试文件删掉，或者顺带重命名一个别处引用的变量。写清楚红线，相当于给它上了一道保险。

2.2 全局配置和项目配置怎么分工

很多人不知道 Claude Code 的配置其实是分层级的。全局配置放在用户主目录下的~/.claude/CLAUDE.md，项目级配置放在项目根目录的CLAUDE.md，两者可以叠加生效。我的模板库对这个层级做了明确分工。

全局配置只写三件事：默认输出风格、通用工程规范、跨项目的个人偏好。比如我自己的全局配置里有这么几行：

- 回答先说结论，再展开分析，结论不超过三句话 - 涉及修改代码时，先说明改了什么、为什么改，再贴 diff - 不确定的地方要明说，不要猜出一个答案硬撑着 - 涉及删除代码前必须向用户确认，擅自删除代码属于违规行为 - 单元测试断言优先写行为描述，不写实现细节

这些内容放在全局，是因为它跟具体项目无关，是"我这个人的使用习惯"。项目级的CLAUDE.md则只放和项目强相关的信息，技术栈、目录、红线，这些全局配置里一概不写。

分层的原则是：全局管气质，项目管事实。全局配置决定 Claude Code 用什么方式跟你说话，项目配置决定它在这个仓库里能干什么事。如果你的团队里每个人都在做不同的项目，这个分工能省掉很多重复配置。

2.3 写完模板之后的实测效果

把CLAUDE.md结构化之后，最明显的变化是 Claude Code 的行为稳定了很多。

举个例子，之前让它改一个组件 props，它有大约 30% 的概率会把相关文件的类型声明也顺手改掉。加了红线"组件传入参数接口统一以 Props 命名，并导出"之后，这个概率降到了大概 5% 以下。再比如，之前它经常跳过测试文件的更新，加了"新功能必须附带对应测试文件"之后，它会在完成任务时主动检查自己是否漏了测试。

还有一个细节我强烈建议每个人都试一下：在CLAUDE.md里写清楚"常用命令"之后，Claude Code 跑命令的准确性会大幅提高。它不会再猜测测试命令是不是npm test还是npx vitest，而是直接看你写的那一行。这个改进在项目脚本复杂、有多个 package 的时候尤其好用。

3. 任务模板：把每类高频操作做成"开箱即用的 prompt"

CLAUDE.md解决的是"它是谁"的问题，任务模板解决的是"让它干什么"的问题。使用 Claude Code 的一大痛点是同一个任务每次描述方式不一样，行为就不一样。比如你说"帮我看看这段代码有没有问题"，和说"请审查这段代码并列出所有可能引发运行时异常的问题，按严重程度排序"，得到的效果完全不同。

模板库的做法，是把高频任务整理成可复用的 prompt 片段，统一指令结构、输出格式和边界约束。下面说四个我在实际项目里用得最多的任务模板。

3.1 代码审查模板：先建证据链，再给结论

代码审查是高频场景，但很多人让 Claude Code 审查代码，只给一句话"帮我 code review"。结果它给你输出的是一堆万金油意见，什么"建议提取公共函数""注意边界条件"——放在哪个项目里都对，放在你的项目里全都没用。

我的审查模板强制了三个输出区段：事实、风险、建议。而且第一步永远是"列出你对代码的理解"，逼着它先把上下文梳理清楚。模板大致长这样：

你现在担任高级代码审查员。请按以下流程审查我指定的代码： 1. 先简要总结这段代码的职责和核心逻辑（不超过 300 字）， 确保你对代码的理解没有跑偏。 2. 按严重程度从高到低列出发现的问题。每个问题必须包含： - 问题描述：具体是什么场景下会出问题 - 证据：对应的代码行号或具体函数名 - 触发条件：什么输入或调用场景会引发 - 修复建议：具体的改法，不是笼统的方向 3. 明确区分"确定的问题"和"疑似的问题"，疑似问题不要用肯定的语气。 4. 如果代码中没有明显问题，如实说明，不要为了显得专业而硬凑条目。 禁止输出与代码无关的通用建议，例如"提高代码可读性"这类放之四海而皆准的话。

这套提示词最关键的一点是把"严重级别"、"证据"、"触发条件"绑定在一起，让它没办法说空话。实测下来，它给出的很多意见确实能定位到具体问题，例如导出的函数在另一个模块里被当作同步调用，而这里有人在useEffect里 await 它，容易引发竞态。

3.2 重构与迁移模板：三步拆解 + 安全守则

重构是风险很高的操作，让 Claude Code 直接"帮我重构这个文件"非常危险。它会大刀阔斧地改，然后你 diff 一看，根本不敢合。

我的重构模板强制流程分三步：先出计划、再确认范围、最后分步执行。示例：

这是一个重构任务。请严格按以下步骤进行，每一步完成前不要自动进入下一步。 【第一步：理解与计划】 分析给定模块的职责、内部依赖和外部引用，然后输出重构计划。计划必须包含： - 目标状态：重构完成后这个模块的代码结构是什么样的 - 拆分步骤：把整个重构拆成 2-4 个可以独立合并的小步骤 - 风险清单：每一步涉及修改哪些外部引用，可能影响哪些调用方 【第二步：确认范围】 基于第一步的计划，列出本次重构会触碰的所有文件。 单独列出那些你认为"会顺带产生行为变化"的文件。 把这份清单交给用户确认，只有用户明确说继续，才进入下一步。 【第三步：分步执行】 严格按照拆分步骤逐个小步修改。每完成一个小步骤： - 运行一次相关测试或至少做一次类型检查 - 输出这一个小步骤的改动摘要，等用户确认后才继续下一步 整个重构过程中禁止： - 改变原有函数签名，除非计划中明确说明且已被用户确认 - 顺带修改重构范围外的代码格式 - 一步到位提交超大 diff

这套模板一开始执行起来会觉得啰嗦，因为它每一步都在跟你确认。但重构本身就是高风险活，多确认一次比改坏了再回滚划算得多。我用的过程中最大的收获是，Claude Code 自己会先想清楚"这个改动会不会影响其他模块"，而不是直接莽。有一次它甚至主动提出某个计划改动会影响另一个 service 的调用方式，建议换一种方案，这在没有模板约束的情况下基本不会发生。

3.3 修 bug 与补测试模板：从复现到根因

修 bug 是最容易翻车的场景。让 Claude Code 直接"修复这个 bug"，它有很高的概率给你一个只处理了表层现象、没有解决根因的补丁。一旦某个函数被两个地方调用，你以为修好了 A 场景，B 场景反而被改挂了。

我的 bug 修复模板长这样：

这是一个 bug 修复任务。请按以下流程进行： 1. 复现：先说明你认为 bug 出现的完整路径，包括触发条件、 涉及的输入数据和异常现象。如果代码中有明确错误堆栈，先引用堆栈。 2. 定位：从复现路径倒推，找出真正的根因代码位置。 必须解释为什么你认为是这里，而不是别的可疑位置。 3. 修复：提供最小改动方案。修复代码必须清晰标明改动前后对比。 4. 验证：给出至少一种验证手段，可以是测试用例、临时输出或手动操作步骤。 - 如果有必要，同时检查该函数的其他调用方，确认改动不会影响其他场景。 5. 总结：用两到三句话说清楚根因是什么、你为什么选择这个修复方式。 如果经过分析你发现 bug 的根因可能不在当前代码范围， 必须明确说"当前范围内无法定位根因"，并说明还需要哪些信息或哪个文件。 禁止在证据不足的情况下直接猜测一个修复方案。

这里的关键是第一步"复现"。很多 bug 之所以难修，是因为我们根本没有搞清楚它到底在什么条件下触发。强制走复现这一步，Claude Code 会被迫先建立一个因果链，而不是看到报错就猜一个地方开始改。我自己用过一次之后，发现它给的根因分析比之前直接让它修 bug 要准确一大截，很多次我还没看完它的分析，自己就意识到真凶在哪了。

3.4 模板的加载方式：怎么用才不别扭

这些任务模板不需要你复制粘贴到每个会话里。做法是把每个任务模板单独存成一个 md 文件，比如templates/code-review.md、templates/refactor.md，然后在会话中直接执行/code-review这类用 Claude Code 的 slash command 机制注册的自定义命令，或者在 prompt 里引用模板文件路径，让它自己去读取。

目录结构组织好后，模板的加载成本几乎为零。这也是把模板做成库而不是零零散散写在文档里的重要原因：你不需要记住每个模板的内容，只需要知道文件名叫什么。

4. 模板库的工程化落地：目录结构、hooks 与团队协作

光有CLAUDE.md和任务模板还不足以称之为一个"库"，因为它们只是静态文本。真正让这套东西跑起来的，是背后的目录结构、自动化 hooks 和跨项目复用机制。这一节讲工程化落地的细节。

4.1 目录结构：一眼看懂这套模板库

我的claude-code-templates仓库目录结构是这样：

claude-code-templates/ ├── README.md # 使用说明、快速上手 ├── global/ │ └── CLAUDE.md # 全局配置模板，复制到 ~/.claude/CLAUDE.md ├── project/ │ └── CLAUDE.md # 项目级配置模板，复制到目标项目根目录 ├── tasks/ │ ├── code-review.md # 代码审查 │ ├── refactor.md # 重构迁移 │ ├── bug-fix.md # 修 bug │ ├── add-tests.md # 补测试 │ └── write-docs.md # 补文档 ├── hooks/ │ ├── pre-tool-use.md # 工具调用前检查 │ ├── post-tool-use.md # 工具调用后检查 │ └── session-start.md # 会话启动时加载 └── scripts/ └── apply.sh # 一键把模板复制到新项目

这个结构最重要的设计原则是职责分离。global管全局配置，project管项目配置，tasks管具体任务指令，hooks管自动化行为，scripts管部署。每个目录里的东西服务于一个目标，不会互相污染。

4.2 hooks 模板：把质量检查前置到工具调用

Claude Code 支持在工具调用前后插入自定义检查逻辑，这就相当于给你的"AI 员工"设了一道道护栏。hooks 我目前保留了三个：PreToolUse、PostToolUse、SessionStart。

PreToolUse的典型应用场景是拦阻止危险操作。比如在写一个 claude code 的插件 hook 时，我会在 hooks 目录里的配置文件写成这样（实际开发中通常是直接配置命令，这里用伪代码说明意图）：

# 工具调用前检查 if 命令是 Bash 且是删除操作: 检查目标和当前项目是否在仓库目录内 如果目标包含 .git 目录或不在白名单: 拦截，并要求调用者再次确认

这个逻辑其实用 Claude Code 的 hooks 机制完全能实现。我实际保留的一个 hook 就是阻止它直接跑git push，凡是涉及 push 的操作必须先列出来给我看一眼，防止它改完代码顺手推上远程。

PostToolUse的典型场景是每次写完文件后自动检查类型。比如前端项目，我在 hook 里配置了每次写文件后运行一次npm run typecheck -- --noEmit，作用是在它自认为完成任务的瞬间，立刻暴露类型层面的错误。这比自己 review 时再发现错误要快得多，因为上下文还热着，改起来成本很低。

SessionStart的作用则是在会话开始时自动加载任务模板列表。我把它配置成一个启动提示，让 Claude Code 在每次新会话开始时主动问一句："本次会话要处理哪类任务？代码审查、重构、修 bug 还是其他？"这个小改动直接把我的启动成本降到了零。

4.3 多项目复用：硬拷贝还是软链接

模板库建好之后，怎么让它在多个项目里跑起来？两种做法各有取舍。

硬拷贝（把模板文件直接复制到项目里）的好处是每个项目之间完全独立，模板在 A 项目改了不会影响 B 项目。坏处是同步困难，你改了主模板，已经复制出去的项目不会自动更新。

软链接（把模板库里的文件链接到项目目录）反过来，好处是模板库更新之后所有引用它的项目都能立刻生效，坏处是你不能在项目里单独修改这份模板，一改就影响全局。

我个人的推荐是混合策略。项目级的CLAUDE.md用硬拷贝，因为它里面包含了大量项目特有信息，本来就不应该跟模板库联动。而全局配置~/.claude/CLAUDE.md用软链接，这样模板库里对全局规则的修改能即时生效。任务模板我目前的做法是硬拷贝到项目下的.claude/tasks/目录，同时定期手动同步，因为任务模板实际上更新频率很低，一套写好了能用很久，不需要频繁联动。

4.4 团队基线：让每个成员从同一套共识出发

模板库还有一个隐藏的价值——团队协作基线。如果你的团队里有三五个成员都在用 Claude Code，但没有统一模板，每个人写出来的CLAUDE.md风格都不一样，有的写了红线，有的根本不知道这个东西。这种情况在各人负责不同模块时还好，一旦需要交接代码，上下文就断了。

我把模板库直接放在 Git 仓库里维护，团队成员 clone 下来后用scripts/apply.sh一键初始化。apply.sh的逻辑很简单：把模板复制到对应位置，同时把当前项目的技术栈信息填写到一个占位文件上，最后打印一份"我需要你补充哪些项目特有信息"的清单。整个初始化过程不超过两分钟。

团队统一之后最大的收益是沟通成本下降。成员之间可以互相说"我用了仓库里重构模板"，而不是交流一大段自己的提示词。而且当某个人发现了一条新的红线值得加进去时，它只需要提交一次 MR，全团队的模板就同时更新了。

5. 迭代与调优：哪些模板留下来了，哪些被我删了

模板库不是一次建完就结束的东西。我用了大概数周之后回头检视，发现有些模板确实是立竿见影的，有些则被我整个删掉了。这一节讲讲我的真实取舍过程。

5.1 立竿见影的三个模板

第一个留下来的是重构模板。最开始引入它是因为有过太多次被"大刀阔斧重构"吓到的经历。加了"先出计划、再确认范围"这个约束以后，Claude Code 的重构质量和可控性完全是两个级别。现在每次大改动前，它甚至会主动告诉我哪些调用方可能受影响，这个在以前很难指望。

第二个是bug 修复模板。它强制了复现路径和根因说明，杜绝了"看到报错就猜个方案"的坏习惯。实测里最明显的变化不是第一版修复方案更准，而是它给的解释更清楚了，我在 review 的时候能更快判断它到底想干什么，合不是合。

第三个是SessionStarthook。这个不看就知道有效果——每次新会话，它自己会先问你今天要干什么，你甚至不用主动想"我该给它什么上下文"。

5.2 被我删掉或大改的模板

有几个模板是我写了又删的。第一个是超长的"全知全能系统提示词"模板。我早期在网上见过有人分享巨大的 prompt，设定 Claude Code 扮演各种角色、带各种知识库。实际用下来感觉就是——模型没有被 prompt 变聪明，反而被一堆角色设定拖慢了节奏。真正有效的是目标明确的短提示词，不是长篇大论的系统设定。

第二个被改的是代码审查模板。最初的版本有一大堆条目，问题按"性能""可读性""安全性"分类罗列，结果输出像文案拼盘，什么问题都说了，什么问题都没有针对性。后来我改成了先要求它输出"对代码的理解"，再列问题，效果立刻好了。原因在于，AI 工具的判断链应该从理解开始，而不是从贴标签开始。

第三个被大改的是补测试模板。最开始我会指定"用 Jest 的 describe/it 结构、给每个函数至少三个测试用例"，输出结果僵化得很，很多 test case 只是为了凑数。后来我改成让它先找出"最容易出错的行为路径"再写测试，输出的测试质量明显提高。

5.3 我现在的维护节奏

我现在对这套模板库的维护节奏是：每个周五下午花一点时间，把这一周里临时写在会话里的"临时规则"归类，看看有没有值得固化回模板的。如果某条临时规则在三次以上会话里重复出现，比如"记得先跑类型检查再告诉我可以了"，我就会把它固化进全局 CLAUDE.md或对应任务模板里。

这个过程很像整理自己的桌面。平时随手用的东西越多，越需要一个固定的位置放它们。桌面收拾一次，后面每天顺手；模板整理一次，后面每个项目都顺手。而我个人的体会是，真正有价值的不是模板本身，而是整理模板时逼自己想清楚的那些问题——这个项目哪些规则不能碰，哪些测试非写不可，哪些命令是我每次都要用的。

把这些想清楚了，Claude Code 的产出质量自然水涨船高。