企业官网建设流程全解析

1. 模板不是锦上添花，而是把 Claude Code 从“玩具”变成“生产力”的关键

先说一个我观察到的现象：很多人第一次接触 Claude Code，都会在终端里惊叹“它居然能自己改代码、跑测试、提交 commit”，那种感觉确实震撼。但用上三五天之后，大家遇到的问题惊人地一致——对话越来越啰嗦，上下文越塞越满，同一个项目里它今天记得你的规范、明天就忘了，每次开新会话都要重新把背景讲一遍。于是许多人得出结论：这东西只能写点一次性脚本，没法用在正经项目里。

这个结论我不同意。问题的根源不在模型能力，而在你不会给 Claude Code 立规矩、搭模板。

所谓 claude-code-templates，说白了就是一套提前写好的“工作说明书”：什么时候让模型做什么、按什么顺序做、输出长什么样、哪些事禁止做。它不是提示词的堆砌，而是把人的工程经验、项目规范、团队协作习惯，固化成一堆可复用的文件，让每次对话都站在同一个起跑线上，而不是从零开始“调教”。

这篇文章我想分享的是我自己在真实项目中沉淀下来的模板仓库搭建方法。它包含四层内容：项目级规则文件 CLAUDE.md、斜杠命令模板、按任务拆分的提示词模板、以及防止模型“野路子”操作的钩子与流程约束。无论你是在个人项目里用，还是打算把它推广到团队，这套思路都值得参考。我会尽量把每一步的“为什么这么做”也讲清楚，而不是只丢一堆配置让你抄。

2. 先搞清楚 Claude Code 的“记忆机制”：所有模板的地基

在设计模板之前，必须先理解 Claude Code 是怎么“记住”你的项目的。很多人上来就写一堆模板文件，结果发现模型根本不按模板走，原因就是没搞懂它的读取顺序和工作方式。

2.1 项目上下文从哪里来

Claude Code 每次会话启动时，会主动加载项目根目录下的 CLAUDE.md 文件，把它当作项目级的“长期记忆”。你在文件里写的技术栈说明、目录结构、编码规范、常用命令，它会作为对话的基础上下文一直保留。这相当于给模型提前“喂”了一份项目说明书。

除了项目根目录的 CLAUDE.md，它还支持在子目录里放局部的 CLAUDE.md，比如src/CLAUDE.md，模型在操作那个目录下的文件时会优先参考对应的局部规则。这一条很容易被忽略，但实际用起来非常有用——可以把某个模块特有的约定写在它自己的目录里，避免所有规则都堆在根目录一份大文件里。

2.2 斜杠命令是按需加载的“技能包”

CLAUDE.md 是常驻记忆，但你不能把所有规则都塞进去——上下文窗口有限，塞得越多，留给实际任务的空间越少。所以更聪明的做法是：高频且必须时刻遵守的内容放进 CLAUDE.md，低频但遇到就要用的内容，做成/命令。

.claude/commands/目录下每一个 Markdown 文件，就是一个斜杠命令。你在终端里输入/review、/plan、/deploy，模型就会读取对应文件里的指令，然后按你说的流程执行。这就像给模型准备了一个工具箱，平时不占地方，需要哪个就抽哪个。

2.3 模板的分工：规则文件管“纪律”，命令模板管“流程”，提示词模板管“任务”

很多初学者的误区是：把所有东西全写在一个“万能提示词”里，让模型“自己看着办”。结果就是纪律和流程搅在一起，模型执行的时候权重混乱，该守的规矩没守住，该跑的流程走了捷径。

我把模板体系拆成三个角色：

• CLAUDE.md（规约层）：定义“你是谁、项目是什么、永远不能做什么”。类似于员工手册。
• 斜杠命令（流程层）：定义“遇到某类任务时，按什么步骤执行”。类似于标准作业程序（SOP）。
• 提示词模板（任务层）：定义“某个具体任务的输入格式、输出格式、验收标准”。类似于工单模板。

三者各司其职。纪律常驻，流程按需触发，任务模板负责把模糊的需求变成结构化输入。

提示：结构上要理解“CLAUDE.md 是规则，commands 是技能，templates 是表单”，这决定了你后面所有文件的组织方式。把这三层混在一起，是模板仓库最常踩的坑。

3. 从零搭建一套可落地的模板仓库：目录结构、文件写法与配置细节

这一节我直接给出一套我实测下来比较顺手的模板仓库结构，然后逐个文件说明怎么写、为什么这么写。你不需要完全照搬，按你项目的规模增减即可。

3.1 整体目录结构

以一个中型的 Web 项目为例，我建议的模板仓库大概是这样的：

project-root/ ├── CLAUDE.md ├── .claude/ │ ├── settings.json │ ├── commands/ │ │ ├── plan.md │ │ ├── review.md │ │ ├── test.md │ │ ├── fix.md │ │ └── docs.md │ └── templates/ │ ├── bug-report.md │ ├── feature-request.md │ ├── refactor-task.md │ └── code-review.md └── src/ ├── CLAUDE.md └── ...

为什么把 commands 和 templates 分开？因为它们的调用方式不一样。commands 里的文件会直接注册成斜杠命令，而 templates 更像是一个“内容仓库”，供命令或 CLAUDE.md 引用。比如你有一个feature-request.md模板，当执行/plan命令时，命令会引导模型按照这个模板收集信息，然后产出方案。

3.2 先写 CLAUDE.md：给模型立的第一条规矩

CLAUDE.md 是整个模板体系里最重要的文件。我的写法是把它分成四块。

第一块是项目概述，两三句话讲清项目是什么、技术栈是什么、目录结构大致如何。这一块的意义在于让模型每次对话都能快速“定位”，知道自己在什么项目里工作。

第二块是编码规范与约束。这一块最容易写得太长太细，导致模型在具体任务中过度拘束。我建议只保留那些“违反会造成严重后果”的规则，比如：禁止修改公共接口签名、禁止直接向生产分支推送、测试必须通过后才能提交。对于风格层面的偏好（缩进、命名风格），用一两句话概括即可。

第三块是常用命令与工作流。包括项目的安装命令、测试命令、构建命令、Lint 命令。这能避免模型在尝试“运行测试”时，不自觉地发明一个npm run test-all之类的命令。

第四块是沟通协作约定。比如：回答问题前先展示关键文件路径；修改代码必须说明改动理由；遇到不确定的需求时，先提问而不是猜测。

下面是一个简化版的示例：

# 项目：订单管理系统 ## 项目概述 - 技术栈：TypeScript + Next.js + PostgreSQL - 目录结构：`/src/app` 放页面路由，`/src/lib` 放业务逻辑，`/src/components` 放 UI 组件 - 包管理器：pnpm ## 编码规范 - 禁止修改 `/src/lib/api.ts` 中已导出的函数签名 - 禁止使用 `any` 类型，除非有明确注释说明原因 - 所有数据库访问必须经过 `src/lib/db.ts` 中的封装函数 - 推送到主分支前必须通过 `pnpm test` ## 常用命令 - 安装依赖：`pnpm install` - 运行开发服务器：`pnpm dev` - 运行测试：`pnpm test` - 代码检查：`pnpm lint` ## 协作约定 - 在修改文件之前，先列出将要修改的文件路径和改动要点 - 如果需求描述有歧义，先向用户提问确认，不要自行假设 - 完成一个子任务后，用一句话总结结果，再继续下一步

这份文件看着简单，但每一行都是我实际踩坑后精简下来的。原先我写过一个 200 行的 CLAUDE.md，里面充斥着“请务必”“一定要”这种没有约束力的废话。后来发现模型处理长文档时会“选择性失忆”，真正管用的反而是这二三十行直接可执行的硬规则。

提示：写规则时用“禁止/必须/不允许”这类强约束词，效果远好于“尽量/建议/最好”。Claude Code 对弱约束词的理解是概率性的，只有强约束词才会真正进入它的决策逻辑。

3.3 配置 settings.json：决定模型能做什么、不能做什么

.claude/settings.json是 Claude Code 的权限配置文件。默认情况下，模型使用很多工具（比如写文件、执行终端命令）都会先询问你，这在实际使用中频繁打断心流。你可以通过配置放行一部分可信操作，让流程更顺畅。

{ "permissions": { "allow": [ "Read", "Glob", "Grep", "Write", "Edit", "Bash(pnpm run lint)", "Bash(pnpm test)" ], "deny": [ "Bash(rm -rf *)", "Bash(git push origin main)" ] }, "model": "claude-sonnet-4-5" }

注意，我这里的配置方式是按“规则”放行，而不是全放开。写文件和运行 lint、test 这类操作频率高、风险低，放行后效率提升明显；而rm -rf、强制推送这类高风险操作，放在 deny 里保命。

配置这一项需要你根据自己的项目情况调整。如果你做的项目涉及生产环境数据，宁可多几次确认，也别把危险命令放行。

3.4 写斜杠命令：把固定流程固化成“肌肉记忆”

斜杠命令的价值在于：把那些每次都要“重新说一遍”的流程，变成一句话触发。

以/plan为例，这是我认为最有价值的一个命令。很多人在让 Claude Code 干活时，上来就是“帮我实现一个用户登录功能”。模型确实能做，但大概率是想到哪改到哪——先加个页面，又补个接口，最后发现缺个数据库表，再回头改。这套流程混乱且难以维护。

/plan命令的职责，就是强制模型在动手之前先做完整的设计和推演。

--- description: 先出方案再写代码，适用于新功能开发 --- 你是一位资深技术负责人。在当前项目环境下，执行以下步骤： 1. 阅读项目根目录的 CLAUDE.md，了解项目背景与规范。 2. 分析用户需求（对不明确处提出澄清问题）。 3. 定位可能需要修改的所有文件，列出调用链。 4. 输出一份改动方案，包含： - 目标：用一句话描述最终实现的功能。 - 改动点清单：文件路径 + 改动内容摘要。 - 数据层变更：涉及的表、字段、迁移脚本。 - 风险与副作用：哪些已有功能可能受影响。 - 测试方案：需要补充或调整的测试用例。 5. 停止，等待用户确认方案后再动手写代码。

这里最关键的其实是第 5 步——“停止，等待用户确认”。如果你不写这句话，模型很容易把“制定计划”当作“执行计划”的省略形式，直接开干。加了这句话，它就会老老实实等你点头。

类似的，我还写了/review（代码审查）、/test（补测试）、/docs（更新文档）、/fix（修复 bug）。每一个的套路都一样：明确输入来源、规定步骤、约束输出格式、设定结束条件。

命令文件的命名会直接变成斜杠命令名。plan.md就是/plan。文件头的description字段会在你输入/时显示命令用途，建议写清楚，方便自己和团队其他成员记忆。

3.5 写好任务模板：让需求输入变成填空题

模板的第二个层级是任务级提示词。它解决的是“需求描述得太模糊”的问题。

比如一个 Bug 修复模板bug-report.md，我可以这样写：

## Bug 描述 （请描述：现象、触发条件、期望行为与实际行为的差异） ## 复现步骤 1. 2. 3. ## 影响范围 （哪个功能模块受影响？影响哪些用户？） ## 环境信息 - 浏览器/Node 版本： - 操作系统： - 相关分支： ## 日志与截图 （粘贴关键报错信息或截图） ## 已尝试的排查 （简要说明已经做过哪些定位尝试，避免重复工作）

这个模板不是给 Claude Code 用的，而是给你自己或团队提需求时用的。当需求信息不齐全时，模型可以向提问人收集，填充到模板里再开始工作。这能显著减少“信息来回拉扯”的情况。

4. 模板的高级用法：多角色分工、动态变量与复杂流程编排

基础模板能让你从“手忙脚乱”变成“有条不紊”，但真正让 Claude Code 发挥上限的是高级编排。这一节讲三个进阶技巧，也是我自己从“会用”到“好用”过程中收获最大的部分。

4.1 多角色协同：让模型在“提问者回答者”和“执行者”之间切换

Claude Code 一个会话里只能有一个角色，但你可以通过命令设计，让它在不同阶段扮演不同角色。

举个例子，我在feature-request.md模板里设计了两个角色：需求分析师和开发工程师。需求不清楚时，它扮演分析师向用户提问收集信息；需求清晰后，它切换成工程师角色输出方案。

实现方式很简单，在命令文件中显式声明“角色切换点”：

--- description: 新功能需求到实现的完整链路 --- # 阶段一：需求澄清（角色：需求分析师） - 对照下方模板，逐项询问缺失信息 - 不急于提出实现方案，只专注理解需求 需求模板： （此处引用 feature-request.md 的内容结构） # 阶段二：方案设计（角色：技术负责人） - 确认需求无歧义后，进入方案设计 - 输出改动点、依赖关系、风险分析 # 阶段三：代码实现（角色：开发工程师） - 按方案逐步实现 - 每完成一个模块，运行相关测试 - 确保全部测试通过后，汇报结果

这种多阶段角色切换，比“一个角色干到底”的效果好得多，因为模型在不同角色下关注的点不一样——做分析师时它不会急于写代码，做工程师时它不会反复纠结需求。你可以理解为它执行任务时的“思考框架”切换了。

4.2 动态变量：让模板在不同场景下复用

命令文件支持变量插值，比如$ARGUMENTS表示你在命令后面输入的所有内容，$1、$2表示第一个、第二个参数。

用法举例，我写了一个/gen命令用于生成新组件：

--- description: 生成一个新组件（用法：/gen 组件名 组件类型） --- 根据 $ARGUMENTS，生成本项目风格的组件。 - 组件名称：$1 - 组件类型：$2（可从：页面 / UI组件 / 布局组件 中选择） - 生成位置：src/components/$1/ - 必须包含：组件代码、props 类型定义、单元测试、index.ts 导出 - 参考项目内同名风格的已有组件保持一致性

当我在终端输入/gen UserCard ui，模型就会自动把UserCard和ui填充到变量位置，按既定规则生成。

这种做法的好处是模板文件本身保持通用性，不需要为每个业务组件单独写一份模板。你要维护的只是“生成组件”这一个通用流程。

4.3 流程编排：把模板连成一条流水线

单个命令解决单个问题，但真实开发里任务往往是链式的。比如开发一个功能，正常路径是：需求澄清 → 方案设计 → 代码实现 → 测试 → 代码审查 → 文档更新。

你可以让命令之间互相引用，形成流水线。在/plan方案确认后，提示模型“下一步请执行/implement命令”，或者在命令文件里写“方案确认后，主动建议用户运行/test”。

实际文档里更推荐的方式是在一个总命令里串联多个阶段的指令，让模型依次执行，完成后进入下一阶段。这个方案的好处是用户只需要输入一次命令，坏处是每个步骤之间缺少人工确认的节点，容易翻车。

我的实践是：方案设计必须人工确认，后续的执行可以串联。也就是说/plan之后必须停，后续/implement、/test可以串成一条。这既保证了安全性，又减少了打断次数。

4.4 用 Hooks 做自动守门员：在关键节点插入强制检查

Claude Code 的 Hooks 机制值得单独拿出来说。你可以在某些工具调用之前或之后，让模型执行一段脚本或检查逻辑。最常见的用途是：

• 在每次 Edit 工具调用前，检查目标文件是否在“允许修改清单”中。
• 在每次 Bash 调用前，检查命令是否包含危险操作。
• 每次会话结束时，自动生成一份“本次改动摘要”，写入日志文件。

Hooks 的配置在settings.json中：

{ "hooks": { "PreToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "node .claude/hooks/guard-file-change.mjs" } ] } ] } }

这个机制相当于给 Claude Code 加了一层业务规则防火墙。比如你的项目里有个核心配置文件，任何改动都可能引发生产事故，那就可以在 guard 脚本里检测文件路径，如果命中就把工具调用拦下来。

注意：Hooks 是模板仓库里“隐形”的规则层，它不直接指导模型怎么干活，而是防止它干出越界的事。在生产项目中，这层守门员往往比命令模板更能避免事故。

5. 模板调试与避坑指南：那些文档里不会明说的经验

模板写出来不是终点，调试才是真正花时间的部分。这一节整理我在实践过程中踩过的坑。

5.1 规则冲突：最隐蔽的“精神分裂”问题

当 CLAUDE.md、子目录 CLAUDE.md、命令模板、Hooks 多个来源的规则同时生效时，很可能出现相互矛盾的情况。比如根目录 CLAUDE.md 说“所有数据库访问必须经过 db.ts”，但某个子目录的 CLAUDE.md 里又写了自己直连数据库的示例代码，模型就会犹豫甚至摇摆。

解决办法：给规则增加一个优先级约定。在根目录的 CLAUDE.md 里明确写一条：

## 规则优先级 当本文件与其他子目录规则冲突时，以本文件为准。

然后在所有命令模板的头部也加上一句话：“本命令的执行不得违背 CLAUDE.md 中的硬性约束。”这样模型在遇到规则冲突时，就有一个明确的裁决依据。

5.2 模板过长：token 浪费与注意力稀释

很多人的模板仓库越写越厚，最后每条命令的指令都长达几百行。结果是每次触发命令，模型要读一大段文字，真正干活的 token 预算反而被压缩了。

解决思路是“把细节下沉，不重复堆叠”。比如代码风格规范，已经写在了 CLAUDE.md 里，命令文件里就不要重复描述风格细节，只需要写“按 CLAUDE.md 中的编码规范执行”。让不同文件各司其职，不重复表述，既省 token 又避免矛盾。

另外一个技巧是：把低频、但触发时需要大量背景知识的指令放在独立文件中，通过命令文件中的相对引用去读取。比如/docs命令可以引用docs-style-guide.md，而不是把整套文档规范内联在命令里。

5.3 斜杠命令不生效：先检查这三个地方

斜杠命令失效或者行为异常，90% 是这三种情况：

第一，文件放错了目录。命令文件必须放在.claude/commands/目录下，放错位置不生效。

第二，文件名与用途不匹配。斜杠命令名就是文件名，如果有空格或中划线，输入时要原样输出，容易手误。

第三，命令文件里的指令写得“太开放”。比如只写了“请审查当前代码”，模型不知道审查范围、审查标准、输出格式，结果就五花八门。命令文件的设计一定要收敛：明确范围、明确步骤、明确产出物。

5.4 模型总是自作主张？问题往往出在边界没说清

这是初学者最容易问的问题：“我明明让它只要做 X，它怎么还做了 Y？”原因通常是你的模板里没有定义“边界外行为”。

在命令文件里，一定要有一个“禁止事项”或“边界”字段。比如：

## 禁止事项 - 未经确认，不得修改 package.json 中的依赖版本 - 未经确认，不得执行数据库迁移命令 - 完成后不要自行 git commit，除非用户明确要求

我自己早期写模板的时候，觉得“它应该知道不要乱提交”，实际上模型并不知道。你把边界画在哪里，它才会守在哪里。这种边界字段，加得越明确，后续返工越少。

5.5 模板的版本管理与团队复用

模板仓库本身不是什么神秘的东西，它就是项目里的一个普通文件集合。既然它管理的是项目的工程规则，那它也应该被版本管理、被评审、被迭代。我建议把.claude/和CLAUDE.md一并放进 Git 仓库，随项目一起提交。

团队协作时，模板变化应该走 PR 评审而不是个人直接修改。因为模型的行为受模板直接影响，一次不谨慎的模板变更，可能让所有人下一天的工作全乱套。我在团队里推行的规则是：涉及模板的改动必须附带“变更说明”，说明为什么改、预期效果是什么、如何验证。

6. 实操心得：我如何用这套模板把重复沟通压缩到原来的三分之一

最后分享一点个人的使用感受。

第一版模板仓库我是在一个老项目里搭建的，当时面对的是几千行代码的遗留系统，各种历史包袱很重。第一版 CLAUDE.md 我写了大几十条规则，结果模型在执行任务时经常被规则束缚，表现得过于保守，一个简单的改动也要反复确认。后来我做了减法：只保留“绝对不能做”的强约束，把“建议怎么做”的内容全部下沉到命令模板中，按需触发。改动之后，模型的行为立刻变得更干脆了，效率和遵守纪律之间终于取得了平衡。

还有一件事让我印象很深。过去我写新功能，自己和模型沟通需求，至少要来回讲三四轮背景：项目结构是什么、相关文件在哪里、接口怎么设计的、测试怎么跑。用了/plan命令之后，这些背景信息都从模板里自动带出来了，我只需要把新需求描述清楚，模型就能在一个完整的上下文里工作。同样的工作量，沟通次数减少了不止一半，产出的方案质量也比“临场发挥”稳定得多。

如果你刚开始接触这一块，我的建议是不要一上来就搭一套大而全的体系。先从一个/plan命令开始，把“动手前先出方案”这一个流程固化下来，用两周感受一下它带来的变化，再逐步补充/review、/fix这些命令。模板的价值是慢慢累积的，它不追求一次到位，而在于把每一次有效的协作方式沉淀下来，让下一次对话站在上一步的肩膀上。

另外提一个操作细节：建议每次和 Claude Code 协作完一个完整任务后，回看一眼对话，把那些“如果当时提前交代就好了”的信息记录下来，补进对应的模板里。这种持续迭代，比任何一次性的“完美模板”都更实用。模板仓库的生命力在于它跟着项目一起成长，而这也正是 claude-code-templates 这个思路最值得投入的地方。