企业官网建设流程全解析

1. 从"每次重复交代太累"说起：没有模板的 Claude Code 有多难用

用过 Claude Code 的人大概都有过这种经历：第一天兴致勃勃在终端里跑起来，让它读代码、改 bug、写测试，觉得"这才是编程该有的样子"。到了第三天，你发现自己在重复输入一堆几乎一模一样的话——"先看一下这个项目的结构，文件不要乱动""按我们团队的规范写测试，不要用那个 XXX 框架""提交之前把变更摘要列一下"。这些指令本身不难，但每次都要重新敲一遍、重新解释一遍上下文，时间就这么悄悄没了。

更麻烦的是，AI 是"失忆"的。你周一跟它说好的约定，周三新开一个会话，它又"不记得"了。你周三辛辛苦苦建立的规则，周五换个分支再来，它又"不记得"了。这时候就会意识到：单靠对话里的自然语言，根本沉淀不下来东西。真正解决问题的思路，是围绕 claude-code-templates 搭出一套模板体系——把高频指令、项目约定、甚至整套项目脚手架都固化到文件里，让 Claude Code 每次启动时自动加载，让一条斜杠命令替你完成原来十分钟的重复沟通。

这篇文章就是我基于 claude-code-templates 整理的实战记录。里面不只有模板文件的写法，还包括我为什么这样设计、踩过哪些坑、后来怎么补救。适合所有正在用 Claude Code 干活、又不想在重复对话上浪费生命的人。无论你是第一次接触模板，还是已经写了几个 CLAUDE.md 但感觉效果不稳定，这篇文章都能给你一些可以直接抄走的思路。

先给结论：模板的本质，不是给 AI 写一份长篇大论的要求文档，而是把"你希望在每次会话中保持一致的上下文和行为"变成可复用的资产。搞懂这一点，后面所有设计逻辑都会顺起来。

2. 模板的三个层次：CLAUDE.md、命令块与脚手架

我开始误以为"模板"就是一份精心写好的提示词文件。后来实际用下来发现，Claude Code 的模板体系其实可以拆成三个层次，各管一摊：第一层管"每次对话的默认上下文"，第二层管"可调用的复用指令"，第三层管"从零生成整套代码骨架"。三者合在一起，才算是一套完整的 claude-code-templates 工程化方案。

2.1 第一层：CLAUDE.md 项目记忆文件

CLAUDE.md 是 Claude Code 的项目记忆文件，放在项目根目录（也可以放在子目录，作用于子目录范围）。每次会话启动时，Claude Code 会自动读取这个文件，把它作为长期上下文的一部分参与整个对话。你可以把它理解成"上岗前给 AI 看的入职手册"——里面写着这个项目是什么、技术栈是什么、默认怎么组织、哪些事绝对不能做。

除了项目级的 CLAUDE.md，还有全局级的文件：放在~/.claude/CLAUDE.md里，对所有项目生效。我通常会放一些与具体技术栈无关的通用偏好，比如"所有回答不要用 emoji""生成的代码必须有注释""遇到不确定的事项先问我而不是猜"，而把具体技术细节放在项目级文件里。这样切到任何一个仓库，AI 至少能保持一套稳定的基础行为习惯。

这一层的核心价值在于"不用每次都说"。只要 CLAUDE.md 写得清楚，你新开一个会话直接说"帮我修一下登录接口的 bug"，AI 也知道登录接口在哪个目录、日志规范是什么、测试该怎么跑，而不是先问三句废话、再瞎猜五分钟。

2.2 第二层：.claude/commands 命令模板

第二层是命令模板，放在项目里的.claude/commands/目录（也可以是全局的~/.claude/commands/）。目录里每个.md文件，就对应一条斜杠命令。比如你建一个review.md，在 Claude Code 对话里输入/review，它就会执行这个模板中定义的指令序列。

这条命令和普通对话的区别在于：过程完全可复用、可版本控制。你把一整套代码审查流程写进命令模板，以后每次跑/review，AI 都按固定流程走一遍，不会时紧时松，不会因为今天你少说了一句"请先看变动文件"就漏掉一个环节。

命令模板的语法我后面会细讲，这里先说它解决什么问题：把"你经常做、但步骤琐碎、每次都需要重复交代"的事情固化下来。代码审查、补测试、跑规范化、生成日报，都适合变成命令模板。

2.3 第三层：脚手架模板

第三层不是给 Claude Code 看的内容，而是让 Claude Code 帮你生成真实项目骨架的流程模板。这层通常结合前面两层一起用：一个new-project.md命令模板，里面定义了初始化项目时 AI 应该依次做哪些事——问清需求、建目录、生成配置、写最小可运行代码、补 README、跑通测试。

第三层和普通生成项目的区别在于"顺序与边界被锁死"。没有模板时，AI 可能先写了一堆代码才发现连目录结构都没建；有模板时，它会严格按照你预设的阶段走，每个阶段完成再进入下一个。这套思路特别适合团队内部需要统一产出规范、又希望保留一定灵活性的场景。

三个层次的关系可以这么理解：CLAUDE.md 决定 AI"平时怎么想"，commands 决定 AI"特定动作怎么做"，脚手架模板决定 AI"从零开始怎么建新世界"。三者叠加，才是完整的一套 claude-code-templates。

3. 手写一套能落地的 CLAUDE.md：我的结构和写法

先把我现在实际在用的项目级 CLAUDE.md 模板贴出来，再逐个模块拆解。这份文件我迭代了大半年，从最初的三千字"论文版"，慢慢浓缩到了同样有效但轻量许多的版本。

# 项目：session-metrics 会话分析服务 ## 技术栈与目录定位 - 语言：Go 1.22；框架：gin；数据库：PostgreSQL - cmd/ 只放 main.go，internal/ 放业务代码，pkg/ 放可复用公共库 - 配置文件统一放 configs/，禁止散落在根目录 ## 开发约定 - 每次改动必须补充单元测试，测试文件与源码同名加 _test.go - 接口错误统一返回 { "code": int, "message": string } 结构，禁止混用格式 - 业务代码中禁止使用 fmt.Println，日志统一走 logrus - 数据库迁移文件按序号命名：0001_init.sql、0002_add_users.sql，禁止修改已执行文件 ## 常用命令 - /review：审查当前分支的变更内容 - /test：生成或补齐单元测试 - /run：本地启动服务并验证 /healthz 健康检查 - /build：编译并输出二进制到 bin/ ## 红线 - 未经过确认，不要修改 public API 签名 - 不要删除 migration 历史文件

这份模板常见的错误是写成"需求说明书"，里面啰里啰嗦描述项目背景、业务目标、用户故事，AI 读完之后该干什么还是不知道。我这份模板只保留四类内容：项目是什么、代码怎么组织、常用命令有哪些、哪些事情绝对不许做。原则很简单——CLAUDE.md 不是给 AI 讲故事的，是给 AI 划边界的。

3.1 "技术栈与目录定位"为什么放第一位

放在第一位，是因为 AI 在回答任何代码问题时，第一反应应该是"这段代码在哪个位置、属于什么模块"。如果它不知道 cmd、internal、pkg 的划分，那它生成的代码很可能出现在奇怪的位置，或者它会假设所有文件都在根目录。很多新项目跑两天就乱，乱源不在写代码的人，而在 AI 出手的第一秒。

这个模块要写得"具体到目录级别"。光说"清晰的项目结构"没有意义，AI 并不知道"清晰"在你心里是什么样。直接把目录名字写出来，把每个目录的职责写出来，它才有据可循。我也建议把数据库类型和访问方式写进来，这样 AI 生成 SQL 时不会出现 PostgreSQL 项目里写 MySQL 语法的情况。

3.2 "开发约定"要写成可以自动检查的规则

开发约定这部分最见水平。差的写法是"代码质量要高""注意健壮性"这类纯主观描述，AI 每次执行都会产生不同的解释，你根本没法稳定复现。好的写法是可以被自动检查的规则：错误统一返回什么结构、日志走什么库、测试文件如何命名。这些规则具备"可验证性"，AI 违反之后你能立刻发现，也可以把规则写进代码检查工具里形成双保险。

比如"接口错误统一返回 { code, message }"，这条约定直接让 AI 写的所有 handler 保持一致；如果哪次它顺手返回了{"msg":"error"}，我很可能在 code review 时一眼看到，然后回退重新生成。可验证规则的价值不在于"描述愿望"，而在于"让偏差可视化"。

3.3 在 CLAUDE.md 里登记"常用命令"的必要性

很多人不理解为什么要在 CLAUDE.md 里写"常用命令"。原因是：CLAUDE.md 作为长期上下文，可以让 AI 提早知道项目里有哪些斜杠命令可用。当你输入/review时，命令模板会执行；但如果 CLAUDE.md 里没有登记，AI 可能对命令模板的上下文衔接得没那么自然，尤其是命令模板需要项目背景时。

我在实际使用中发现，把命令名和一句话说明写进 CLAUDE.md，AI 使用命令配合其他任务时的准确度会提升。比如你让它"先 /test 再帮我跑一遍 /run"，它能清楚知道中间流程，而不是把两者当成毫无关联的动作。花三行文字登记一下，收益很直接。

3.4 红线的写法：少而狠

红线是 CLAUDE.md 里最容易被忽略、但实际最救命的部分。AI 默认行为是"尽力帮你把事情做完"，这既是优点也是隐患——它会在你没要求的情况下修改 public API、清理"看起来没用"的文件。所以红线必须写得少而狠，每一条都是你无法接受的底线。

我见过有人把红线写了两百多条，那没有意义，AI 记不住，还会挤占上下文空间。真正有效的红线就是三五条：不许动什么、不许删什么、未确认前不许做什么。密度低，执行率高。

3.5 关于全局 CLAUDE.md 的补充

全局~/.claude/CLAUDE.md我建议只放通用的、与任何项目都无关的行为偏好。我自己在用的是下面这份：

# 全局偏好 - 所有回答使用中文，代码注释也使用中文 - 不要使用 emoji - 涉及修改文件的请求，先列出将要修改的文件清单，再开始动手 - 无法确定的事项先提问，不要猜测 - 生成的代码必须保持简洁，删除未使用的导入和变量

这里的关键是"和项目无关"。一旦某条偏好只对特定项目有效，就不该放全局文件，否则会串味。比如"接口错误返回统一结构"只适用于后端项目，拿到前端项目里反而干扰判断。

4. 可复用命令模板：把高频操作压缩成一条斜杠指令

如果你只打算从 claude-code-templates 里带走一个概念，那我最推荐的就是命令模板。这是投入产出比最高的一环：写一个文件，就可以无限次使用，还能让 AI 的行为稳定在某一水平线上。

4.1 命令模板的组成与基本语法

命令模板是一个带 YAML frontmatter 的 Markdown 文件，放在.claude/commands/下。文件名就是命令名，比如review.md对应/review。frontmatter 里可以配置命令的元信息，正文是给 AI 的完整指令，指令里通过$ARGUMENTS接收用户在命令后输入的参数。

举个最简单的例子，.claude/commands/health.md：

--- description: 检查本地服务是否健康 model: sonnet --- 调用本地健康检查接口，确认服务启动状态。 如果服务未启动，使用 go run ./cmd/server 启动，然后等待 3 秒后再次请求 /healthz。 若返回 200，输出服务状态摘要；否则报告失败原因和最近的日志。

frontmatter 里的description会显示在命令列表里，相当于给用户看的一句话说明；model是可选的，可以指定这个命令强制使用某个模型，这对稳定流程有帮助。$ARGUMENTS会把用户在/health 8080里输入的8080传给指令。此外还支持$CLAUDE_GLOBAL_GIT_ROOT这类的内置变量，用来获取仓库根目录等信息。我在团队里的习惯是：凡是命令中涉及具体路径、端口、分支名的位置，一律走$ARGUMENTS，不要写死在模板里，否则复用性会大打折扣。

4.2 把一个"好用的 review 命令"拆开看

代码审查是最适合命令模板化的场景，因为人工审查有一整套固定动作。我现在的/review命令长这样：

--- description: 审查当前分支变更，提供逐文件 review 结论 model: sonnet --- 请对 $ARGUMENTS 或当前分支相对主干的最新变更进行代码审查，严格按以下步骤执行： 1. 先抓取变更文件列表，按"核心逻辑、配置、测试、文档"分类； 2. 逐个文件阅读 diff，重点检查：潜在 bug、边界条件缺失、不符合 CLAUDE.md 约定的写法； 3. 对每个文件输出以下格式： - 风险等级：high / medium / low - 问题描述（一句话） - 建议修复方式（只给思路，不要直接改） 4. 最后汇总所有 high 风险问题清单； 5. 如果变更文件包含测试，确认测试是否覆盖了主要分支。 额外规则： - 不要修改任何文件，仅输出审查结论； - 不要把审查建议写成"代码可以更简洁"这类空话，必须给出具体位置和修改思路。

这个命令值得注意的点是"分阶段执行"和"输出强制结构化"。很多审查命令效果差，是因为步骤没拆开、输出没结构，AI 像个临时工一样东看一眼西看一眼。你把流程拆成五步、每步的输出格式也定了，它就变成了一条稳定的流水线。

4.3 让命令模板产出"可对比的结果"

我后来给模板加了一条硬规则：输出内容尽量结构化，最好能用表格或固定清单表达。原因是，只有结构化的输出才能被对比。你连着一周跑/review，如果每天输出格式都不一样，你根本看不出项目质量是在变好还是变坏；但如果每次都是同样的字段、同样的风险等级体系，你可以直接对照周一和周五的审查结论。

实践中我甚至会把 review 结论重定向到文件里保存下来，月底翻一翻，就能看出哪些模块反复出风险、哪些约定一直被打破。这些数据反过来又能指导 CLAUDE.md 的更新——这个循环才是模板体系真正的长期价值。

4.4 命令模板的命名与冲突规避

Claude Code 自身带了一批内置命令，比如/init、/compact、/clear等。自己新建命令模板时，如果起了同名命令，行为可能会互相覆盖或混淆。我的建议是：自定义命令一律加前缀，比如/zc-review、/zc-test，或者直接用项目缩写。这看起来多敲了几个字母，但省掉了"这个命令到底是谁的"这种排查时间。

另外，命令模板是否生效取决于它所在的目录：项目级放.claude/commands/，全局级放~/.claude/commands/。如果你的某个工作流只在特定项目里用，就不要放全局目录，否则其他项目里也会多出一堆无关命令，干扰命令列表的呈现。

5. 从0到1的项目初始化：让模板替你完成脚手架

模板体系里最容易被低估的是"项目初始化"。很多人觉得让 AI 生成一个项目不是打字就行了吗，还需要模板？等你试过几次就会明白：没有模板时，AI 生成的项目风格一天一变，今天生成 Python 项目放在 src/ 下，明天生成同样的项目却放在 app/ 下；今天生成的配置是 YAML，明天变成 TOML。这些差异单个看都不是致命问题，但如果你要让 5 个新人各自用 Claude Code 建项目，最后你会得到 5 种完全不同的风格，维护成本直接失控。

5.1 把初始化流程编成一条 new-project 命令

我在团队里做了一条new-project命令模板，效果是把项目初始化从"随缘生成"变成"流水线作业"。这条命令的流程是：

--- description: 初始化一个新项目，按团队标准生成脚手架 --- 请根据 $ARGUMENTS 描述的项目类型，按以下阶段初始化项目： 阶段一：需求确认 1. 如果描述中缺少"语言/框架/目标目录"中的任何一项，必须提问确认，不得猜测； 2. 确认后，输出将要创建的文件清单，等待用户确认。 阶段二：项目骨架 3. 按 CLAUDE.md 中约定的目录规范创建目录结构； 4. 生成基础配置文件（语言相关的包管理、lint 配置、.gitignore）； 5. 生成一份最小可运行的主程序入口。 阶段三：验证闭环 6. 创建 README.md，包含项目简介、启动命令、目录结构说明； 7. 跑通一次构建或启动命令，确保项目可以正常运行； 8. 输出项目文件树和下一步开发建议。

这个模板之所以按三个阶段执行，是因为"确认后动手"和"每一步验证通过再走下一步"是初始化是否可靠的关键。没有阶段控制时，AI 经常出现项目生成完结果根本跑不起来的情况，而且你很难定位是哪一步出了问题。有了阶段拆分，至少你能在"骨架"阶段就拦下错误，不用最后推翻重来。

5.2 初始化模板里的"团队规范"应该引用 CLAUDE.md 而不是复述

要特别注意一点：初始化模板里不要复制大段的产品规范。比如"我们的 API 要统一返回 code/message 结构"，这类内容写进命令模板也可以，但更好的做法是让命令模板引用 CLAUDE.md 里的约定，写法类似"按本文档所在项目 CLAUDE.md 中约定的接口规范生成代码"。原因是同一份约定如果出现在两个文件里，改的时候很容易漏掉一处，过一阵两份文件内容不一致，AI 行为就开始飘。保持单一事实来源，是模板体系长期可维护的基本功。

5.3 初始化完成后的"人工验收清单"

我把初始化模板的最后一个阶段固定为"输出验收清单"，让 AI 不只是交付代码，还要清楚地告诉你哪些文件是它创建的、哪些命令需要你手动运行、哪些假设需要你确认。这个习惯帮我挡掉了不少麻烦，比如 AI 自作主张初始化了 git 仓库、但团队真正想用的是 monorepo 子目录这种场景。

下面的表格是我在实际验收时对照的检查项：

第五点是我后来才加的。初始化的纪录比代码本身更具长期价值，因为三个月后你回头看，只有记录能告诉你当初为什么没有用另一个框架。这一切都可以让 AI 在初始化结束时自动生成。

6. 踩坑实录：模板太大、太模糊、太陈旧的三次事故

模板不是写出来就完事，真正的麻烦都在使用过程中浮现。我这半年踩过三个大坑，逐个复盘一下，希望你能绕过。

6.1 模板太长，AI 一半时间在"读上下文"

我第一次写 CLAUDE.md 时，恨不得把整个项目的设计文档都塞进去，最终文件接近三千字。结果很直观：每次会话的反应速度明显变慢，而且 AI 回答问题时会优先引用后面那些长篇背景，而不是前面几条关键约定。原因不复杂，CLAUDE.md 是作为上下文进入每次请求的，它越长，单次对话消耗的 token 越多，AI 的"注意力"也会被分散。

后来我花了一个晚上做减法，把所有"背景介绍""业务目标"全部删掉，只保留可执行的规则和必须知道的结构定位。三千字砍到五百字左右，反应速度和回答质量同时回升。这次教训让我定了一条规矩：CLAUDE.md 只放"AI 必须照做"的内容，解释性的东西另开文档，等 AI 问起来再读。

6.2 模板描述太模糊，AI 的"自由发挥"远超想象

早期我在开发约定里写过一句"保持代码整洁"。结果每次让 AI 重构，它都有不同的理解：有时它觉得"整洁"意味着把所有函数都合并成一个文件，有时又觉得"整洁"是把变量名改得奇短。折腾几次后，我把"保持代码整洁"换成了可以验证的列表："函数不超过 80 行""必须有 docstring""不允许未使用的导入"。同样一句话，行为立刻稳定下来。

这给我一个很深的体会：模板不是写给 AI 看的作文，是写给 AI 执行的规则。所有主观形容词都需要翻译成可判断的条件。你心里想的"整洁"，在 AI 那里并不存在，但"函数不超过 80 行"这种条件它是能严格执行的。

6.3 模板不更新，AI 拿着旧规则打新仗

还有一次翻车是项目从单仓库结构变成了多模块结构，目录规范变了，但 CLAUDE.md 还是旧的。结果 AI 生成的新模块代码全部按照旧目录布局放，最后只能人工迁移。这次的教训是：模板文件必须和代码一起进版本控制、一起走评审，而且结构发生重大变化时，第一件事就是同步更新 CLAUDE.md 和命令模板，而不是先写代码。

我现在的做法是每次代码评审时都会顺带问一句"这次的变更是否影响 CLAUDE.md 里的约定"，如果影响，当场更新模板文件，和功能代码一起提交。模板文件不是圣旨，它需要持续迭代才能保持新鲜度。

7. 把模板变成团队资产：Git管理、评审与持续迭代

你个人用模板是一回事，几个人一起用就是另一回事了。团队里用模板，最大的问题不是写不出来，而是改不动、同步不了、标准越来越乱。这块我最后聊一下。

7.1 模板应该独立成仓库，还是跟着项目走

我的答案是分两类管理：通用模板（和具体项目无关的命令、规范）放一个独立仓库，比如team-claude-templates；项目专属的 CLAUDE.md 和项目级命令，放进各自项目的仓库。独立仓库可以通过 git submodule 或者同步脚本拉到本地，项目仓库里的模板则直接随代码评审迭代。

通用模板独立成仓有几个好处：diff 清晰、变更记录完整、新人可以一次性 clone 一个模板库就获得团队全部规范。坏处是要额外维护一套同步机制，对几个人规模的小团队来说成本略高。我自己现在用的是折中方案：通用模板数量很少，直接放在全局目录~/.claude/commands和~/.claude/CLAUDE.md，通过一个 shell 脚本从 git 仓库拉取更新；项目级模板随项目走，不额外设置同步。

7.2 模板的 review 比代码 review 更重要

很多人不把模板文件当代码看，更新全凭自觉，这是最大的隐患。模板一旦出错，影响的不只是一次性代码生成，而是后续所有新老会话的行为偏移。所以我在团队里定了规矩：CLAUDE.md 和命令模板的变更必须走 code review，而且 review 重点不是"措辞对不对"，而是"新增的规则是否可验证、是否与现有规则冲突"。

下面是我们 review 模板时的对照清单：

7.3 让模板跟着项目一起"演进"

模板最怕的不是一开始写不好，而是写完就再也不动。项目是活的，技术栈会换、目录会拆、规范会细化，模板必须同步跟上。我个人的习惯是给每个模板文件加一个"最近更新"备注，同时把模板变更记录到项目的 CHANGELOG 里，这样任何人在任何时候都能回看"这条约定是为什么变成现在这样的"。

演进过程中还需要警惕"过度模板化"：不是所有事情都要写进模板。我见过有人把"运行时如果端口被占用就换端口"这种细枝末节也写进 CLAUDE.md，结果模板膨胀到大家都懒得读。我的判断标准很简单：这条规则能不能被木头人自动检查？如果一句话能被代码、脚本或 lint 工具自动兜住，就不需要出现在模板里；只有那些需要 AI 靠理解力去判断、但又必须保持一致的内容，才值得占用模板空间。

7.4 最终的一点个人体会

claude-code-templates 这套玩法的核心其实不在于文件格式、语法糖，甚至不在于具体某条命令怎么设计。它真正的价值是：把你在终端里跟 AI 的一次次临时对话，沉淀成可复用、可评审、可持续迭代的工程资产。模板不是给 AI 看的说明书，而是你和 AI 之间的契约。只要这个契约写得清晰、维护得及时，AI 就能稳定地变成你团队里那个"从不忘记规矩"的同事。

如果你现在还没建任何模板，我建议你不用一次搞全套，先把项目里的 CLAUDE.md 写上 5 条可验证的规则，再加一条/review命令，用一周感受一下变化。等习惯了这个节奏，再慢慢扩展到脚手架和团队资产层面。模板这件事，动手比完美重要得多。