企业官网建设流程全解析

用Claude Code写代码这件事，我算是比较早开始折腾的那批人。刚开始的几个月，我的使用方式相当“原始”——打开终端，敲claude，进入一段对话，想让它改什么就说什么。项目少的时候还好，等手头同时维护四五个仓库，两个问题就变得非常刺眼：第一，每次切到新仓库，我都得把技术栈、目录结构、代码约定重新讲一遍，讲多了它还会漏；第二，团队里每个人都在用自己的方式跟AI沟通，同一个项目换一个人操作，产出质量差别巨大。于是我开始系统性地把“给AI的说明书”和“常用工作流”沉淀成一套可复用的模板体系，这也是claude-code-templates这套实践的由来。这篇文章就把这套模板化玩法从头到尾拆开讲，包含模板组织的思路、完整的示例文件、初始化脚本，以及我踩过的坑。

如果你只是偶尔拿Claude Code玩一下，模板化未必是必需品；但只要你同时维护几个项目，或者要带团队一起用AI编程，下面这套方法能帮你在重复沟通上省下大量时间，也能让AI产出的稳定度明显上一个台阶。

1. 痛点拆解：为什么自由度越高的工具，越需要模板

Claude Code在设计上给了用户很高的自由度：你几乎可以用自然语言让它做任何事情。这种自由度在单次会话里非常爽，但在真实的工作流里，它带来的问题比大多数人意识到的要严重。

1.1 会话一关，记忆清零

Claude Code的每个会话之间其实是相对独立的。你在这个会话里跟它反复确认过“这个项目使用pnpm，不要用npm”，下一个会话它完全不在乎，尤其是当你切换了目录，或者隔了几天再回来，项目背景信息基本清零。这时候你就是一个人肉上下文注入器，每天开工第一件事就是给AI重新做入职培训。我做了一个痛苦的实验：同一个仓库，在断了三天之后重新开会话，Claude连项目用的什么语言都会问一遍。这种重复沟通不只是浪费时间，还会打断编码心流。

模板化的第一层价值就在这里：把每次都要重新表述的项目背景信息，固化到文件里，让AI启动时自动加载。你不需要再在对话里讲一遍，甚至不用想起来这件事。

1.2 团队里每个人都在“自定义AI”

我观察过团队里几个同事用Claude Code的习惯，差异大到让人怀疑他们用的是不是同一个工具。有人开个会话直接说“帮我写个用户登录接口”，有人会把表结构、返回格式、错误码、日志规范全都列出来。这不是谁对谁错的问题，而是缺少统一约定时，AI产出的标准没办法对齐。最直接的后果是代码Review成本暴涨，因为每次AI交上来的东西风格都不一样，你得花大量精力去纠正本来可以通过约定避免的分歧。

模板在这里扮演的角色是“最低共识”。它不是限制个人发挥，而是保证无论谁触发AI，AI都先读到同一份项目背景和同一套质量标准。个人依然可以在对话里追加要求，只是不会连基线都不一样。

1.3 项目知识沉淀不下来

代码为什么这样写、某个模块有什么历史包袱、数据库迁移踩过什么坑，这些项目里最有价值的信息，目前大多数时候只能躺在人的脑子里，或者散落在聊天记录里。用Claude Code的过程其实一直在产生这些东西，但会话一旦结束，这些知识就跟着消失了。模板体系本质上是在做“版本化的项目记忆”，把一个人脑子里的经验，变成所有参与这个项目的人都能调用的上下文。这一点在团队协作里的收益，远大于个人使用。

1.4 模板化不是限制自由，而是降低沟通成本

很多人一听到“模板”两个字，第一反应是僵化、死板。但实际上，模板化是把你和模型之间的沟通成本系统性地降下来。模型不需要你反复解释的东西越多，它就能把有限的上下文窗口用在真正重要的事情上。这就好比跟一个资深同事配合，他熟门熟路，你只需要说清楚需求；如果每次来的都是实习生，你得从头讲一遍项目背景、代码规范和常见坑。模板就是把这个“实习生”快速变成“资深同事”的手段。

2. CLAUDE.md是模板的地基，但多数人把它写废了

CLAUDE.md是Claude Code启动时自动读取的项目说明文件，官方叫Project Memory（项目记忆）。它相当于一份入职培训手册，在你发出第一条消息之前，Claude已经通过它了解了项目基线。所有模板体系的构建，都应该从这一份文件开始。

2.1 三种常见写法误区

我见过不少项目里的CLAUDE.md，写法五花八门，但问题主要集中在三类。

第一种是写成百科全书，恨不得把每个模块的实现细节都塞进去。后果是文件动辄几千行，Claude每次启动都要处理大量冗余信息，真正关键的约定反而被淹没，还会白白消耗上下文窗口。我见过最夸张的一个CLAUDE.md写了两千多行，实际跑下来的效果比不写还差。

第二种是写成需求文档，全篇都是“我们要做一个XX系统，目标用户是XX”，这些产品层面的信息对写代码的AI来说含金量很低。AI需要知道的是这个代码库长什么样、用什么写的、有哪些约定，而不是产品PPT。

第三种是写成命令列表，把npm run dev、npm run test这类命令简单罗列一遍。它有用，但太浅了，没有解释为什么这样做，也没有说明代码结构的核心约束。命令是“怎么跑”，而CLAUDE.md更需要回答“怎么写”。

2.2 一份健壮的CLAUDE.md应该包含哪几块

我目前使用的模板分为六块，每块内容都不多，但它覆盖了AI实际产出时真正需要的维度。你可以直接照着这个骨架来组织自己的CLAUDE.md。

# 项目名称 ## 项目概述 一句话说明项目做什么，服务谁，当前处于什么阶段。 ## 技术栈 - Web框架：FastAPI 0.110 - 数据库：PostgreSQL 16，通过 SQLAlchemy 2.x 访问 - 任务队列：Celery + Redis - 包管理：Poetry ## 核心架构 - app/api：路由层，只负责参数解析和调 service - app/service：业务逻辑层，不直接触碰数据库 - app/models：SQLAlchemy 模型 - app/tasks：异步任务 - 数据流：api -> service -> models -> db ## 代码约束 - 所有对外接口必须返回统一格式：{"code": 0, "data": ..., "message": ...} - 新增数据库字段必须提供 Alembic 迁移脚本 - 不允许在 service 层直接拼 SQL ## 常用命令 - 启动开发环境：poetry run uvicorn app.main:app --reload - 运行测试：poetry run pytest - 生成迁移：poetry run alembic revision --autogenerate -m "desc" ## 典型工作流 新增一个业务接口时： 1. 在 app/models 定义模型变更 2. 生成迁移脚本并执行 3. 在 app/service 实现业务逻辑 4. 在 app/api 添加路由和校验 5. 在 tests 补接口测试

这里面的关键是“代码约束”和“典型工作流”两块。代码约束要写具体、可检查的条目，比如“所有对外接口必须返回统一格式”，比“代码要规范”这种话有用得多。典型工作流则是把项目里的常用操作路径固定下来，AI拿到这个之后，面对“新增一个接口”这类需求时，能够按正确顺序改文件，而不是自己想当然。

2.3 写好CLAUDE.md的四个检查点

写完模板之后，我会用四个问题来自检：第一，这段信息如果AI不知道，是否会导致它做错事？如果答案是“不会”，就删掉。第二，这段信息是否可以在对话开始时临时补充？如果可以，就没必要放进常驻文件。第三，这段信息是否有明确的检查项，AI能否据此判断自己有没有做错？第四，这个文件是否有超过三个月没更新？如果有，说明它已经开始腐烂了。

CLAUDE.md最怕的不是内容少，而是内容过时。过时的约定比没有约定更糟糕，因为AI会非常自信地按照旧规则工作，而且你很难察觉它用的其实是过时的信息。所以我把模板更新放到项目迭代的节奏里，每个阶段结束顺手过一遍，而不是等出问题再改。

2.4 模板文件别用一套通吃全部项目

一份CLAUDE.md不可能同时适配一个前端脚手架和一个后端微服务。前端的模板要强调组件结构、状态管理、样式方案；后端的模板则要说明数据库访问、鉴权方式、API规范。用同一套模板去初始化不同类型的项目，结果就是AI得到一堆无关信息，真正关键的内容反而没覆盖到。

所以我会在下一节讲，把模板从一个孤立的CLAUDE.md升级成有组织的目录体系，按项目类型维护不同的变体。

3. 按项目类型建立模板库：从单文件到目录体系

把模板升级成一套有组织的模板库，是真正好用的开始。我在家目录下维护了一个~/.claude-templates目录，结构大概是这样：

~/.claude-templates/ ├── base/ │ ├── CLAUDE.md │ └── commands/ ├── web-frontend/ │ ├── CLAUDE.md │ ├── commands/ │ └── hooks/ ├── python-backend/ │ ├── CLAUDE.md │ ├── commands/ │ └── hooks/ ├── devops/ │ ├── CLAUDE.md │ └── commands/ └── init.sh

3.1 模板库的数据结构

每个项目类型对应一个独立目录，里面至少包含CLAUDE.md和一个commands目录。commands目录放的是Slash Command模板，后面会详细讲。hooks目录是可选的，有些类型需要自动化钩子，有些不需要，不强求。

base目录放的是最通用的一份模板，适合那些不好归类的项目，也是所有其他模板的起点。我维护了一个原则：任何公共约定都先落到base，再按项目类型去覆盖和扩展。这样不同模板之间不会出现概念冲突。

3.2 前端仓库的模板重点写什么

前端项目最容易出现的问题是组件混乱和状态管理失控。所以前端模板里我会重点写几件事：组件放哪一层、状态管理用哪个库、接口请求怎么封装、样式方案是什么、UI组件库是哪套。这些信息直接决定了AI生成的前端代码能不能被团队接受。

前端模板的命令部分，我通常放启动、构建、Lint、更新依赖这几条。有个地方要特别强调：包管理器必须写清楚。npm、pnpm、yarn混用会让依赖锁文件变得难以维护，AI如果猜错包管理器，甚至会把整个node_modules状态搞坏。

3.3 后端仓库的模板重点写什么

后端模板的核心是写清楚鉴权方式、API响应格式、错误处理约定、日志规范、数据库访问层约定和迁移方式。这些是后端代码里最容易踩坑、也最需要保持一致的领域。

相比前端，后端模板我特别强调“典型工作流”。比如新增一张表要改哪几个文件，新增一个需要登录的接口要经过哪几层。这类操作在后端项目里高度重复，只要路径固定了，AI产出的代码结构就八九不离十。

3.4 初始化脚本：一条命令铺好模板

目录结构里的init.sh是最实用的部分。它把复制模板、创建.claude目录这些动作全部自动化。我写了一个很简单的Bash脚本：

#!/bin/bash # 用法：./init.sh web-frontend my-project set -e TYPE=$1 PROJECT_DIR=$2 if [ -z "$TYPE" ] || [ -z "$PROJECT_DIR" ]; then echo "用法：$0 <template-type> <project-dir>" exit 1 fi TEMPLATE_DIR="$HOME/.claude-templates/$TYPE" if [ ! -d "$TEMPLATE_DIR" ]; then echo "模板类型不存在：$TYPE" exit 1 fi cd "$PROJECT_DIR" || exit 1 cp "$TEMPLATE_DIR/CLAUDE.md" ./CLAUDE.md mkdir -p .claude/commands .claude/hooks cp "$TEMPLATE_DIR"/commands/* .claude/commands/ 2>/dev/null || true cp "$TEMPLATE_DIR"/hooks/* .claude/hooks/ 2>/dev/null || true echo "模板初始化完成：" echo " - CLAUDE.md" echo " - .claude/commands/" echo " - .claude/hooks/"

脚本里两个细节值得说明。cp "$TEMPLATE_DIR"/commands/* .claude/commands/后面的|| true是为了兼容某些模板没有commands目录的情况，避免脚本因为复制失败而中断。同样，hooks目录也不是每个项目都有，所以复制失败时直接忽略。别小看这两行，真实项目里模板类型一多，这种容错逻辑就是脚本稳定性的关键。

3.5 用户级配置和项目模板的分工

有人会问，Claude Code本身不是有用户级配置吗，为什么还要用项目级模板。其实两者定位完全不同。用户级配置适合放全局偏好，比如“所有项目都用中文回答”“默认不擅自安装依赖”。而CLAUDE.md是项目级的，它要跟着仓库走，纳入版本控制。项目模板跟着仓库走，团队成员拉下来自动获得同一套上下文，这才是团队合作的关键。如果把项目信息放在个人配置里，换一台机器或者换个人，这套知识就断了。

4. 工作流模板化：Slash Command把常用动作变成一句话

CLAUDE.md解决了“AI知不知道项目背景”的问题，但还没解决“AI能不能稳定复现流程”的问题。这时候就需要Slash Command出场。

4.1 命令模板的机制

Claude Code支持在项目的.claude/commands目录下放一系列Markdown文件，每个文件就是一个自定义命令，文件名就是调用时的命令名，文件内容就是插入到对话里的指令模板。调用方式很简单，在对话里输入/命令名，比如/review，Claude就会加载对应的指令模板，按预设动作执行。

命令模板和CLAUDE.md最大的区别在于：CLAUDE.md是常驻上下文，每次启动都会读；命令模板是“用完即走”的动作指令，只有调用时才出现。这正好对应了两种知识类型：背景知识和操作动作。前者需要持续在场，后者只需要在特定场景触发。

4.2 我高频使用的命令模板

先看两个例子。第一个是代码审查命令，我把这个文件放在.claude/commands/review.md：

请对当前分支相对于主分支的变更做一次代码审查。 重点检查：逻辑正确性、边界条件、异常处理、命名可读性、安全隐患。 对每个问题给出严重级别（阻断/建议）和修改方案。 最后用表格汇总输出。

第二个是补测试命令，放在.claude/commands/test.md：

为当前目录下的核心模块生成单元测试。 要求： 1. 优先覆盖公共函数的正常路径和边界值 2. 外部服务调用一律用 mock 3. 测试文件放在 tests/ 目录，按被测模块命名 4. 运行测试并确保通过

这种命令模板最大的价值在于稳定。同一个命令在不同项目里触发，AI执行时的行为高度一致，不会因为换个人、换天心情就换一套标准。命令模板可以带变量占位符，比如让用户输入目标模块名，但我个人建议尽量少用复杂的动态参数。保持命令模板简单，效果反而更稳。

4.3 命令模板和CLAUDE.md的配合原则

我划分的原则很明确：CLAUDE.md放背景知识，命令模板放操作动作。比如CLAUDE.md里写了项目使用pytest、测试放在tests目录、数据库用PostgreSQL，那么命令模板里就不需要重复这些内容，直接写“按项目约定执行代码审查”就行。

这个配合还有一个好处：当项目约定变化时，只需要改CLAUDE.md，命令模板几乎不用动。我见过有人把项目细节大量写进命令模板，结果每次项目一变更，要去改好几条命令，非常反维护。记住一条原则：命令模板要尽可能跟具体项目解耦，内容应该是“审查时看什么”这类通用动作，而不是“本项目用XX框架”这类事实。

4.4 命令库的维护清单

我把自己的命令库按用途分成了几类，下面这个表格可以作为参考：

命令模板不用求多。先把自己日常使用频率最高的三五个沉淀下来，跑顺了再逐步扩展。命令越多，维护成本越高，而且AI在选择命令时反而更容易困惑。

5. 从个人效率到团队规范：模板的共享与版本管理

模板化最大的红利，其实在团队层面。当每个人都用同一套CLAUDE.md和命令模板时，AI产出的风格和标准会自然收敛，Review成本大幅下降。但从“我自己用”变成“大家用”，需要一套共享和管理的机制。

5.1 用独立Git仓库管理模板

我把~/.claude-templates目录初始化为一个Git仓库，推到公司内网的GitLab上。模板本身有了版本历史和变更记录，团队成员通过git pull就能同步最新版本。

这里有一个关键区分：仓库里保存的是公共模板，而个人设备的用户级配置不纳入版本管理。这样每个人都保留自己的偏好，但项目级上下文是统一的。公共模板要维护得干净，不能因为某个人对某个工具有特殊偏好就污染整个模板库。

5.2 模板更新必须有流程

模板一旦被多人使用，就进入了软件维护节奏。我踩过的坑是：有人悄悄改了模板但没有通知别人，结果他推的模板和CLAUDE.md里描述的不一致，其他人用的时候一脸茫然。

后来我们定了三条简单规则。第一，模板变更必须走代码评审，至少两个人看过才能合并。第二，CLAUDE.md和命令模板的变更要分开提交，因为影响范围完全不同——前者影响所有会话，后者只影响特定命令。第三，README里记录每个版本的变更摘要，方便出问题时回退。

5.3 新人接入模板的完整路径

新同事加入时，我给的操作清单是这样的：先clone模板仓库到本地；然后在参与的项目里用init.sh把对应类型模板铺进去；花十分钟浏览CLAUDE.md和命令模板，重点看代码约束和典型工作流；再试跑一次/review和/test，明确AI的输出标准；最后，有任何跟项目实际情况不符的地方，提issue反馈，不要直接改公共模板。

这套流程的核心是把“项目知识传递”从口口相传变成文件驱动。新人不需要追着老人问太多背景，自己看模板就能理解大部分约定，这对远程协作尤其有价值。

5.4 安全红线：不能什么信息都往模板放

CLAUDE.md虽然跟着项目走，但它最终会被Claude读取，也可能被复制到各种环境。所以有一条红线必须划清楚：秘钥、数据库连接串、内部系统地址这类敏感信息绝对不允许出现在模板里。模板只放约定和结构，不放凭证。我在团队里明确过这条规则，谁踩了谁负责删除。

另外，涉及个人信息的内容也要谨慎。模板里不应该出现“XX是负责这个模块的人”这类表述，一方面隐私有问题，另一方面人总会离职调动，写进模板只会变成过时信息。

5.5 维护节奏：按迭代复盘来迭代模板

模板不是写完就一劳永逸的。我个人的维护节奏是：每个项目迭代阶段结束后，回顾一下这个阶段AI最常犯的错误，看能不能通过新增一条CLAUDE.md约束或一条命令模板来兜住。然后每个季度做一次集中整理，把明显过时的内容清理掉。

这个节奏不需要额外花很多时间，但它保证了模板一直处于“跟项目同步”的状态。我见过最惨的情况是模板半年没更新，内容已经和实际代码库脱节，AI按照模板工作反而制造混乱。

6. 踩坑实录：模板化过程中的几个血泪教训

模板化的方向是对的，但过程绝不像上面写得那么顺利。下面这几个坑，都是我实际踩过的，写出来给你当参照。

6.1 模板越长不代表AI越聪明

我刚开始建CLAUDE.md的时候有严重的“收集癖”，觉得写得越多AI越懂我。结果一个项目的CLAUDE.md写了接近两千行，实际跑下来反而变笨了。不相关的信息占用了大量上下文窗口，真正关键的约定经常被淹没，AI偶尔还会一本正经地引用一个已经废弃的规则。

后来我砍到一个原则：CLAUDE.md里只放“AI不知道就会做错”的信息，那些“知道了也差不多”的信息统统删掉。这个判断标准虽然简单，但非常有效。

6.2 “不要做XX”的否定式约束会反向强化

我在代码约束里最早写的是“不要在service层拼SQL”，结果AI反而经常拼SQL。后来我意识到，模型对否定式指令的处理效果有限，它可能记住了“SQL”这个高频词，却忽略了“不要”。解决办法是改成肯定式：“所有数据库访问都通过ORM的Session完成”，并且给出一小段正确的代码示例。代码示例比任何描述都更直接，AI会以示例为模板生成代码。

6.3 动态信息写进模板是灾难

有一段时间我在CLAUDE.md里写了“当前分支是feature/xxx，本周目标是完成支付模块”。这个文件被复制到其他分支和其他项目之后，产生了大量误导。模板里只能写静态事实，动态信息应该放进对话里临时说。这个错误我遇到了两次才彻底改掉。

6.4 Hook自动化的路径与递归陷阱

用hooks做自动化确实很爽，但坑也不少。第一个是路径问题：hooks脚本里如果用了相对路径，在Claude Code从不同子目录启动时行为会非常诡异。应该统一用绝对路径，或者基于项目根目录的完整路径。第二个是防递归：如果hook里又调用了claude命令，可能造成递归调用，必须加执行条件判断，比如检查环境变量或者锁文件。

我后来基本只在PreToolUse阶段做轻量校验，重的逻辑尽量不放hook里。hook的变更评审也要比命令模板更严格，因为它影响所有会话的进出，出了问题影响面很大。

6.5 模板改完不重启会话，等于没改

CLAUDE.md是在会话启动时加载的。很多次我改完模板，继续在旧会话里用，发现AI还是在用旧规则，一度以为模板没生效。其实只要新开一个会话，改动就生效了。所以改模板之后，记得重启会话再验证。这不是什么大坑，但遇到的时候容易让人怀疑人生。

结尾最后再分享一个体会。模板这套东西，本质上就是把我自己的经验固化成AI可以直接读取的内容。我个人感受最深的是，模板化的价值不只是“省时间”——当项目知识从个人脑子搬到CLAUDE.md里，团队的协作方式会悄悄改变。新人不用追着老人问上下文，AI产出和项目标准保持一致，Review意见变少，返工也明显减少。如果你想尝试，别急着一次把模板做全，从你重复讲了超过三次的话开始，先沉淀一个项目的模板，跑顺了再慢慢扩展。这样你的模板库才能始终长在真实需求上，而不是成为一个需要二次维护的负担。