企业官网建设流程全解析

如果你和我一样，每天要在终端里和 Claude Code 打交道超过五六个小时，那你迟早会面对一个问题：同样的项目规范、同样的工作流、同样的指令，为什么每次开新项目都要重新教一遍？我说的不是"记住上次聊天"，而是真正把上下文固化下来，让 Claude Code 一进项目就知道该怎么干活。这就涉及到模板工程化。

我得先说清楚一件事：Claude Code 本身只是一个 CLI 编程助手，它能读代码、改文件、跑命令、执行测试，但你指望它每次自动理解你的项目约定，那不太现实。真正的差距不在于模型能力，而在于你给了它多少可复用的上下文。模板，或者说 templates，就是把这份上下文沉淀成文件的过程。这篇文章我会把我自己维护的一套 claude-code-templates 从设计思路到落地细节完整拆一遍，包括目录怎么组织、命令模板怎么写、哪些坑我踩过，以及怎么让它变成一个团队都能用起来的资产。

1. 为什么要折腾模板：CLAUDE.md 是 Claude Code 的"入职手册"

先说结论：Claude Code 的工作记忆来自两个层面的文件。一个是项目根目录下的CLAUDE.md，它定义了当前仓库的全局背景，比如技术栈、目录结构、代码风格、构建方式；另一个是用户主目录下的~/.claude/CLAUDE.md，它承载跨项目的个人偏好，比如"我所有项目的测试命令都要用 pnpm"，属于和具体仓库无关的习惯层。

CLAUDE.md 这名字起得很误导人，它并不是给 Claude 看的帮助文档，而是给 Claude 下发的"入职手册"。想象你公司来了个新工程师，你丢给他一份说明文档，里面写清楚：这个项目是 Node + TypeScript，用 Turborepo 管理 monorepo，lint 规则不许绕过，push 之前必须过完单测。新人照着做，能少问十句废话。Claude Code 每次启动、每次 resume、每次你切换会话时，它都会主动读取这个文件来初始化自己的上下文。

那为什么大多数人不写或用不好？因为我见过太多项目的 CLAUDE.md 长成了产品需求文档，五千字，从公司愿景写到技术选型背景。这就完全用错了。Claude Code 的上下文窗口有限，而 CLAUDE.md 是每轮对话都要被塞进上下文的，写得越长，token 消耗越大，真正重要的指令反而会被稀释。

所以我做 claude-code-templates 的第一条原则是：CLAUDE.md 只放常驻信息，把非常驻信息拆到 commands、skills 和子目录文档里，按需加载。

具体来说，常驻信息包括下面四类：

• 一句话说明这个项目是干什么的，避免模型对上下文产生误判；
• 技术栈与关键依赖版本，尤其是包管理器、语言版本、框架版本；
• 一条完整的启动命令和一条完整的测试命令，写清楚执行入口；
• 代码风格硬规则，比如"禁止修改 public 目录下的文件""新增 API 必须带 Zod 校验"。

我见过一些很激进的模板，会把"不允许使用 any"这种 lint 规则也写进去。没问题，但如果团队根本跑不起严格 TS 配置，这种指令就会和实际代码冲突，Claude Code 反而会陷入困惑。模板必须服务于真实项目，不是服务于理想项目。

2. 拆开 claude-code-templates 的目录结构：按需加载才是核心

我在维护的这套模板，不是单文件，而是一组可复制的目录骨架。我第一次整理时也偷懒，把所有东西塞进根目录一个 CLAUDE.md，结果项目一复杂，每次对话都要背上大量无关指令，慢且不稳定。后来我重构成了这样：

project-root/ ├── CLAUDE.md ├── .claude/ │ ├── commands/ │ │ ├── plan.md │ │ ├── implement.md │ │ ├── review.md │ │ └── test-run.md │ ├── skills/ │ │ └── frontend-refactor.md │ └── settings.json └── docs/ └── architecture.md

根目录的 CLAUDE.md 只留前面说的四类全局信息，控制在 50 行上下。.claude/commands底下放的是自定义斜杠命令，Claude Code 会在输入/时自动列出这些命令，相当于你给 Claude 预置的快捷指令。.claude/skills放的是结构化技能，通常是一个带说明文档和脚本的任务包，只有在相关任务真正出现时才会被检索加载。.claude/settings.json管控权限、危险命令列表和模型参数。

这样做的收益非常直观：默认上下文很小，跑起来省 token，响应速度快；需要特定能力时，用户通过斜杠命令或者 Claude 自动匹配技能的方式，把对应的指令临时注入。这个过程很像你电脑里不把所有软件堆在桌面，而是装进开始菜单，要用才点开。

我再补充一个细节：settings.json里我通常会这么写：

{ "permissions": { "allow": [ "Bash(npm run lint)", "Bash(pnpm test)" ], "deny": [ "Bash(rm -rf *)" ] }, "model": "claude-sonnet-4-20250514" }

权限管控是模板最容易被人忽略的部分。很多团队模板只教 Claude 怎么做正确的事，却没教它哪些命令绝对不能动。在权限层把危险操作堵死，比事后看 log 补救踏实得多。注意，权限的白名单应该跟着项目走，而不是跟着全局走，我吃过亏，后面详聊。

3. 命令模板的实战写法：从 plan 到 implement 再到 review

命令模板是 claude-code-templates 里最出效果的模块，也是我后来在团队内推广时大家最快接受的部分。说白了，就是把高频操作固化成固定格式，让 Claude Code 每次执行同类型任务时都走同一套标准动作，省去你一段段重复描述需求的时间。

3.1 Plan 命令：任务还没开始之前先把话说清楚

我先写/plan。它解决的核心问题是"你刚丢给 Claude 一段模糊需求，它立刻开始改代码"。如果你用过几周 Claude Code，你肯定经历过它自作主张实现了一个和你预期完全不同的方案。这不是模型蠢，是任务定义不清。

我的 plan.md 大致长这样：

你是项目的技术负责人。当用户给出需求时，你按以下顺序处理： 1. 阅读根目录 CLAUDE.md，理解技术栈与既有约定； 2. 在 docs/architecture.md 中确认涉及模块的现状； 3. 用 200 字以内复述你理解的需求，向用户确认； 4. 列出改动涉及的文件清单和风险点； 5. 输出实施计划，分阶段，每阶段可独立验证； 6. 未经用户确认，禁止修改任何源文件。

关键在于第 3 步和第 6 步。复述需求，逼着 Claude 在动手前先对齐信息；禁止修改文件，把"计划模式"和"执行模式"从流程上切开。我在实际使用中观察到，加了这两条之后，需求返工率明显下降，尤其当需求描述本身就是一大段混乱文字时，Claude 自己都会先提问，而不是硬猜。

3.2 Implement 命令：把计划变成可执行的改动

/implement和 plan 配对使用。这个模板最重要的设计是强制分阶段提交，而不是一股脑把所有文件改完。

严格按用户提供的实施计划执行： 1. 每完成一个阶段，运行一次相关测试； 2. 提交信息遵循 conventional commits 规范； 3. 如果中途发现计划与现状冲突，停下来向用户说明； 4. 完成后输出变更摘要，包括新增/修改/删除的文件列表。

这一段在真实项目里非常救命。第一次做模板时我没写"冲突要停下来"这条，结果 Claude 遇到一个被计划遗漏的接口调用，自作主张改了接口签名，连带影响了三个模块。你自己盯着还好，一旦并行交几个任务，这种偏离很容易被忽略。

3.3 Review 命令：让 Claude 自己审自己的代码

review 模板是为了快速迭代加的。原生的 Claude Code 本身能读 diff，但如果没有统一标准，review 的质量完全看运气。我在这里面把我的个人 code review 清单固化了：

针对当前分支的改动执行代码评审： 1. 检查是否存在未处理的边界条件； 2. 检查类型推导是否存在偷懒的 any 或类型断言； 3. 检查是否引入了重复逻辑； 4. 检查错误分支是否吞掉异常； 5. 输出评审意见，按 severity 排序，只列可执行建议，不评论语气。

说句实在话，Claude 的代码评审不能替代真人，但作为提交 commit 之前的一道自动关卡，它足够糙也足够快。很多低级错误在这一步就会被截住。

4. 技能模板与多 Agent 协作：当模板不再只是一堆提示词

如果你关注过 Claude Code 最近的更新，应该知道它有了一系列围绕"Agent"和"Skill"的能力扩展。Skill 的粒度比命令更小、更聚焦，通常是一个包含指令文档和执行脚本的目录，被 Claude 在合适场景下自动唤醒。我的 templates 仓库里放了不少这类技能，最有代表性的一个是frontend-refactor。

这个 Skill 的职责是"识别前端组件中的反模式，并提出重构方案"。它的目录结构如下：

skills/ └── frontend-refactor/ ├── SKILL.md └── scripts/ └── scan-imports.js

SKILL.md 里用 YAML frontmatter 声明了触发场景，比如"当用户希望重构某个 React 组件，或发现组件文件超过 300 行时加载本技能"。正文里写了具体的分析路径：先跑 imports 扫描脚本，再锁定重复渲染区域，再给重构步骤。这样当我在某个项目里说"帮我看下 dashboard 页面为什么这么乱"，Claude 会自行判断需要加载这个 Skill，然后主动执行脚本，而不是只给我一段泛泛的建议。

这里有个容易误解的点：Skill 不是命令，它不是你主动调用的快捷操作，而是让 Claude 在合适时机自动采集的上下文模块。所以它的文档质量非常重要，描述必须足够具体，不然模型要么该加载时不加载，要么在无关任务里强行调用。我在写 SKILL.md 时，会把触发条件写得很苛刻，宁可漏触发，不能误触发。

再说多 Agent 协作。Claude Code 现在支持把一个大任务拆给多个子 Agent 并行执行，模板在这个场景里承担的是"角色说明书"。我维护了一套 team 模板，里面把 Agent 分为 orchestrator、planner、implementer、reviewer 四类，每一类有独立的角色指令和输出约定。orchestrator 只负责任务分解和汇总，不能自己写代码；implementer 只做执行，不允许修改全局设计文档；reviewer 则专门检查实现者的改动是否符合公共约定。

这套东西在没有模板的情况下几乎跑不起来，因为你每次都要重新给每个 Agent 解释背景和边界。一旦把角色定义写成文件，加载团队模板后，分拆任务就变成填空式操作。

5. 从踩坑到修补：模板项目里的关键教训

任何模板系统都不是一次写完就完事，我在自己的仓库里迭代了快半年，积累了不少教训。挑几个最典型的说，这些几乎每个做 Claude Code 模板的人都会遇到。

5.1 模板太长等于没有模板

最开始我的 CLAUDE.md 写了三百多行，包含所有模块的路径映射、数据库表结构、第三方 SDK 的使用说明。看起来全面，实际上 Claude 在运行时会频繁引用这些信息，推理速度变慢，且偶尔出现指令冲突。后来我删掉了所有能从代码里直接读到的信息，比如表结构，让 Claude 需要时自己去 schema 文件里查。留下来的只有代码里无法自然呈现的约定和流程，行数立刻降到 60 行以内，响应质量反而提升。

这条经验背后的原理是：模板和 codebase 是互补关系，凡是代码仓库自带的信息，都不该重复写进模板，写了反而可能因为版本漂移造成误导。

5.2 模板里不要写入动态信息

我有一次在模板里写了"当前迭代周期的目标是优化首屏加载时间"，结果两周后 Claude 还把这个旧目标当成最高优先级，导致它在新任务里频繁倾向于改动性能相关代码。动态目标这类信息应该放到任务正文里，通过命令行参数或临时指令传入，而不是固化到模板文件。同理，日期、分支名、当前版本号，都别写进模板。

5.3 不要用模板管理密钥或个人信息

这个坑看起来低级，但在团队协作场景里很容易变味。有人会把内部服务地址、账号信息直接写进 CLAUDE.md，图方便让 Claude 自己连数据库查数据。我坚决反对。Claude Code 的会话内容会随对话保留在本地，但如果团队仓库是公开的，或机器被共享，这些信息就裸奔了。模板只放配置的读取方式，比如"数据库连接串存于 .env，由用户提供"，不放真实值。

5.4 命令模板之间的边界要清晰

plan、implement、review 这三个命令，模板里职责描述必须互相不重叠。我见过有人把 review 逻辑直接塞进 implement，导致 Claude 每完成一个小改动就开始长篇大论地自评，既浪费 token 又拖慢节奏。边界清晰的意思是：让 Claude 在执行时不需要判断"该不该做这一步"，模板已经替它做了这个判断。

6. 让模板成为团队资产：版本管理、共享与持续演进

最后说下这套 claude-code-templates 怎么从个人配置升级成团队基建。我做这件事时的核心思路是：模板必须进 git 仓库，并且要区分"模板源"和"项目副本"。

我在团队里是这么落地的：单独建一个claude-code-templates仓库，里面维护所有标准模板和技能。项目接入时不是复制粘贴，而是执行一个同步脚本，把模板源里的文件软链到项目的.claude目录。这样模板源更新后，所有项目可以一键拉新，不会出现每个项目各自维护一份逐渐失联的副本。

# sync-templates.sh TEMPLATE_REPO="$HOME/src/claude-code-templates" PROJECT_ROOT="$1" ln -sfn "$TEMPLATE_REPO/CLAUDE.md" "$PROJECT_ROOT/CLAUDE.md" ln -sfn "$TEMPLATE_REPO/.claude/commands" "$PROJECT_ROOT/.claude/commands" ln -sfn "$TEMPLATE_REPO/.claude/skills" "$PROJECT_ROOT/.claude/skills"

要注意的是，不同项目需要保留个性化覆盖能力。我的做法是：公共模板走软链，项目特定的补充内容放在.claude/project-local.md，在根 CLAUDE.md 里通过一行@import引入。这样既统一又不僵化。

团队落地时还有一个前提条件：模板仓库要有清晰的版本记录和变更说明。每次修改模板，都要在 commit message 里写清动机，否则团队成员看到模板变了却不知为何，信任感会流失。我自己每次调整 plan 模板后，都会顺手更新配套的使用说明到仓库 README，写清楚"什么时候会用到、触发后会发生什么、预期输出是什么"。这一步对非重度用户特别友好，能让模板不被当成黑盒。

到目前为止，这套模板体系已经服务了好几个工程团队。它谈不上什么颠覆性创新，真正的价值在于把那些本来要反复口头叮嘱的约定，变成了文件，让每次对话都从相同的基线出发。如果你也想弄一套自己的 claude-code-templates，我的建议是从一个只有 CLAUDE.md 和三个命令模板的最小集开始，用起来之后再逐步追加 Skill 和团队同步机制，别一上来就想覆盖所有场景。