企业官网建设流程全解析

1. 为什么我最终沉淀出一套 Claude Code 模板体系

先说结论：Claude Code 这类 AI 编程助手，真正拉开使用差距的从来不是模型本身，而是你喂给它的"上下文质量"。而模板，就是批量生产高质量上下文最直接的手段。

我在用 Claude Code 做项目开发、代码重构、脚本调试几个月之后，发现一个很典型的场景：同样是让 AI 帮忙排查问题，有的人能得到精准的根因分析和修复建议，有的人只会得到一堆正确的废话。差别在哪里？差别在于你启动对话时是否给了足够清晰的"任务框架"——项目背景、目标文件、约束条件、期望输出格式。这些信息每次都在重复输入，但每次输入的质量又参差不齐，所以我开始系统性收集和整理自己的 claude-code-templates，把高频操作固化成模板，效果立竿见影。

这篇文章不是讲 Claude Code 基础安装和登录那点事，而是专注在 templates 这个点上：命令模板、提示词模板、项目模板分别怎么设计、怎么用、避哪些坑。适合已经用过 Claude Code、但感觉"用得不够顺"的人，也适合刚接触 Claude Code、想直接站上高起点的朋友。你不需要一次性读完，但建议把关键示例复制下来，跑一遍，再改成你自己的。

2. 模板目录设计与初始化配置：先搭骨架，再谈技巧

很多人的 Claude Code 模板是散落在系统里的零散文件，今天想起一个写在临时目录，明天想起一个放在~/.claude/，要用的时候翻半天。我的建议是：开工前花十分钟，把模板的存放规范和加载机制定下来，后面所有体验都会顺畅很多。

2.1 模板存放的目录规范

Claude Code 会自动加载~/.claude/目录下的配置和命令模板，对单个项目则读取项目根目录下的.claude/目录。我的习惯是两套并存：

• 个人级通用模板放在~/.claude/，例如"提交信息规范化生成""代码 review 清单""技术方案设计"这类与具体项目无关的能力；
• 项目级专用模板放在<项目>/.claude/，例如"本项目的测试命令""本项目特有的目录结构和编码约定"。

这样区分的好处很明显：个人模板是长期积累的资产，换项目不丢；项目模板跟随仓库走，团队协作时所有人都能共享同一套约定，不至于出现"A 的 Claude Code 能跑，B 的跑不了"这种尴尬。

# 我的 ~/.claude/ 目录结构 ~/.claude/ ├── CLAUDE.md ├── commands/ │ ├── commit.md │ ├── review.md │ └── design.md └── ... # 项目级目录结构 <project>/ ├── .claude/ │ ├── commands/ │ │ ├── test.md │ │ └── build.md │ └── CLAUDE.md └── src/

2.2 权限与内建命令的加载逻辑

初次使用 Claude Code 时，/install命令会在~/.claude/commands/下生成几个内置示例命令文件（比如review.md、commit.md），这些是官方给的样例。你可以直接修改它们，也可以删除，Claude Code 发现文件存在就以文件内容为准，不存在就回到内置默认行为。

这里有个值得注意的细节：命令模板文件本身是 Markdown 格式，但文件名决定了斜杠命令的名字。例如~/.claude/commands/commit.md对应/commit，~/.claude/commands/review.md对应/review。命名时尽量用短横线连接的小写单词，比如generate-test.md对应/generate-test，不要用空格和特殊字符，否则调用时容易出歧义。

权限上，Claude Code 对命令模板有自动批准机制：命令文件头部的 YAML frontmatter 可以声明allowed-tools，列出的工具在本次命令执行中自动放行，不用每次确认。这个能力是把双刃剑，我会在后面的避坑章节专门说。

2.3 用 CLAUDE.md 建立"长期记忆"

CLAUDE.md是 Claude Code 的核心记忆文件，每次对话开始时自动加载，相当于给 Claude 一份"项目说明书"。很多人的 CLAUDE.md 写得像招聘 JD——堆了一堆空话。我的建议是把它当成"新人入职第一天最需要知道的 10 件事"来写：

• 项目是什么、技术栈是什么；
• 目录结构说明，哪些目录是核心，哪些是自动生成的；
• 常用的构建、测试、运行命令；
• 编码约定和必须遵守的规范（例如"禁止直接改数据库迁移文件"）；
• 当前项目的架构约束（例如"所有外部请求必须走 service 层"）。

项目级CLAUDE.md放仓库根目录，团队所有人共享。个人级~/.claude/CLAUDE.md则写自己的通用偏好，例如你习惯的代码风格、常用工具的用法、希望 Claude 在回答时遵守的格式约定。两级记忆文件优先级：项目目录下的CLAUDE.md效力高于用户目录下的~/.claude/CLAUDE.md，更具体的规则覆盖更通用的规则。

3. 命令模板的语法机制与实战案例

命令模板是整个 claude-code-templates 体系里最直接提升效率的部分。你只需要把一段精心设计的 Prompt 放进commands/目录，之后输入/命令名 + 参数就能触发一次高质量对话。但前提是你得理解它的语法，而不是把模板当成一个普通文本来用。

3.1 $ARGUMENTS 与 @arguments 的区别：小符号大学问

命令模板文件里最核心的就是参数引用语法。它有两种写法：

• $ARGUMENTS：接收命令后跟的全部原始字符串；
• @arguments（或$1、$2等带索引的写法）：接收按空格拆分的第 N 个参数。

$ARGUMENTS适合"整段传入"的场景，比如/commit 这里是这次的改动说明，包括原因和影响范围，模板拿到的是完整的一句话。$1、$2适合结构化的多参数场景，比如/generate-test src/utils/format.ts api，模板可以明确区分"目标文件"和"测试类型"两个维度。

--- description: 生成单元测试 allowed-tools: Write, Read --- 请为 `$1` 路径下的代码生成单元测试。 测试类型为 `$2`，对应的测试框架约定如下： - 常规单测：使用 Vitest - API 单测：使用 supertest + Vitest 要求： 1. 覆盖正常路径、边界条件和异常分支 2. 测试命名遵循「方法名_场景_预期结果」 3. 生成完成后用样例输入跑一遍，确认可以执行

上面这个模板里，$1是目标文件路径，$2是测试类型。调用方式是/generate-test src/utils/format.ts api。如果只有一个占位符需要一长段描述，就用$ARGUMENTS代替。

3.2 上下文注入：让 Claude 在已有文件基础上工作

命令模板不只是"把一段话传给 Claude"那么简单。Claude Code 的命令模板天然具备读取当前文件、读取项目索引、查看已打开文件的能力。问题是，你要在模板里明确告诉它"先干什么、再看什么"。

我常用的review.md模板开场是这样写的：

--- description: 对当前文件进行代码 review --- 先读取当前工作区已打开的文件，理解完整改动。 然后按以下维度逐项检查： 1. 边界条件是否处理完整（空值、超长、并发）； 2. 是否存在内存泄漏或资源未关闭的隐患； 3. 是否有明显的安全性问题（注入、越权、硬编码密钥）； 4. 错误处理是否合理，可观测性有没有做好； 5. 代码是否符合当前项目的编码规范（参考根目录 CLAUDE.md）。 输出格式： - 每个问题标注严重程度：阻塞 / 重要 / 建议 - 每个问题给出最小化修复示例 - 如果发现问题少于 2 个，直接说「整体质量不错」，不要为了凑问题而凑问题

注意最后一句「不要为了凑问题而凑问题」。这是我在实际使用中总结出来的关键点——AI 在没有明确约束时，倾向于给出泛泛的建议来显得"专业"，但你真正需要的是它能判断当前代码到底有没有问题。模板里加一句质量约束，输出质量会有明显变化。

3.3 几个我实际在用的命令模板

分享两个我团队内部使用频率最高的模板。一个是commit.md，用于规范 git commit 信息。用命令模板而不是直接让 AI 写提交信息，最大的价值在于"格式稳定"——你可以在模板里写死 commit 格式规范，保证每个提交信息都符合 Conventional Commits 标准。

--- description: 根据当前 git diff 生成规范 commit message allowed-tools: Bash --- 先执行 `git diff --stat`，再执行 `git diff` 查看完整改动。 基于改动内容，生成符合 Conventional Commits 规范的提交信息： - 格式：<type>(<scope>): <subject> - type 必须是 feat / fix / docs / style / refactor / perf / test / chore 之一 - subject 用中文，不超过 30 字，祈使句，不带句号 - 如果改动较大，body 里列出关键变更点，每点一行 请直接输出最终的 commit message，不要输出任何解释。

另一个是explain.md，用于快速理解陌生代码：

--- description: 解释当前文件或指定路径的代码逻辑 --- 请解释 `$ARGUMENTS` 指定的代码逻辑。 要求： 1. 先用一句话概括这是个干什么的模块； 2. 按调用链拆解：入口在哪里、核心函数有哪些、数据怎么流转； 3. 标出容易踩坑的地方（例如隐藏的副作用、顺序依赖、全局状态）； 4. 输出结构：模块概览 -> 函数拆解 -> 调用关系 -> 潜在风险。

这类模板的价值在于：它把"如何阅读代码"的思考框架写死了。每次调用都自动带上这一套审查框架，而不是让 Claude 自由发挥。稳定，可预期，这就是模板化最大的意义。

4. 提示词模板：从一次性的 Prompt 到可复用资产

命令模板解决的是"斜杠命令入口"的问题，但日常对话中还有大量场景不适合做成命令，而是需要一段精心设计的提示词模板。很多人觉得提示词模板就是"把常用 Prompt 存个文档"，实际上没那么简单。

4.1 变量替换的三种方式

提示词模板中需要根据情况变化的部分，一般有三种处理方式：

• 占位符替换：模板里写{{文件路径}}这种占位符，使用时手动替换。优点是直观可控，缺点是需要动手编辑，适合低频场景；
• 多选分支：模板里写明"如果 A 场景走这段要求，如果 B 场景走那段要求"，让 Claude 自己判断。适合场景边界模糊的情况；
• 模块拼接：把模板拆成"背景块 + 任务块 + 约束块 "，使用时只替换任务块。这种做法可复用性最强，是我最推荐的方式。

举个例子，我需要让 Claude Code 帮我分析一段线上问题日志。固定的是背景块和输出格式块，变化的是任务目标。所以我把它拆成三段：模板开头是固定的背景说明（项目类型、技术栈、环境），中间是本次分析的具体任务，结尾是固定输出要求（原因分析、影响范围、修复建议、验证方案）。每次对话时，中间那段随手改，首尾不动。这样既能保证 Claude 得到足够的项目背景，又不至于为每个新任务重写整个 Prompt。

4.2 带示例的提示词模板：Few-shot 的力量

提示词模板里最值得投入时间打磨的是"示例"。一个常见的误区是模板只写要求不写例子。我自己的实测是：同样的一个 Prompt，加两个示例之后，输出质量的稳定性明显提升。

比如我有个"改写为销售话术"的提示词模板，模板里会放一个改前和改后的对比。Claude 就是通过对这个例子的模仿来建立输出的风格基准线。如果只说"要口语化、要有说服力"，它会输出一堆情感充沛但结构松散的废话；有了例子，它至少格式和语感能对齐。这就是 Few-shot 提示：与其长篇大论描述你想要什么，不如直接给它看一个标准答案。

## 背景 你是一个熟悉技术产品卖点的文案助手。下面是一段产品原始描述，请按业务场景改写。 ## 原始描述 {原始描述} ## 改写要求 1. 不改变事实，只调整表达角度 2. 面向一线销售口头介绍，控制在一分钟内能讲完 3. 输出格式：先说结论亮点，再给支撑细节，最后给一句行动号召 ## 示例 原始描述：该网关支持每秒 10 万并发连接，延迟在 5 毫秒以下。 改写：我们这套网关，单机就能扛住十万并发，延迟五毫秒。也就是说，哪怕你们电商大促流量翻十倍，也不用担心网关变成瓶颈。要不要安排一次压测验证一下？

4.3 模板的"组合"策略：像积木一样搭对话

更进阶的用法，是把模板当成"积木块"，根据场景动态组合。Claude Code 的对话是支持多轮上下文的，所以你不必一次把全部信息塞进第一句话，而是可以设计一个"开场模板"先建立背景，再用若干"追问模板"逐步深入。

我的做法是：所有模板都按"背景类、任务类、约束类、输出格式类"打标签。低优先级任务调用时只挑必要的几块拼进去，高优先级任务才全量拼接。模板化并不等于僵化，它只是帮你省下重复思考的脑力，让你把注意力放在真正需要判断的地方。

5. 项目模板的搭建与团队复用

5.1 项目模板不等于脚手架

这里要区分一个概念：Claude Code 的项目模板不是指create-react-app那种代码脚手架，而是指"Claude Code 在一个项目里工作时的预设上下文"。它解决的问题是：当 Claude 开始在这个仓库里帮你写代码时，它应该知道什么。

所以项目模板的核心产出物是.claude/CLAUDE.md。把这个文件写透彻，相当于给这个项目的 AI 协作流程打了地基。我见过很多团队上周还在讨论"要不要用 AI 编程"，下周就让 Claude 直接上手改代码，然后 Claude 改崩了，结论是"AI 不行"。根本问题不是 AI 不行，是项目里没有一份让 AI 遵循的说明书。

5.2 一个标准项目 CLAUDE.md 应该包含哪些内容

我把自己常用的模板结构整理如下，你可以直接复制调整：

# 项目说明 一句话描述项目解决什么问题，用什么语言和框架。 # 常用命令 - 开发启动：npm run dev - 测试执行：npm test - 构建产物：npm run build - 代码检查：npx eslint src/ # 目录结构 - src/ 源代码主目录 - modules/ 按业务域划分的模块 - shared/ 跨模块共享的公共代码 - types/ 全局类型定义 - tests/ 单元测试 - configs/ 环境配置 # 关键约定 - commit 使用 Conventional Commits 规范 - 新增功能必须带单元测试 - 禁止直接修改 shared/ 下的公共类型，需要先讨论 - 所有异步请求都要做超时和错误处理 # 架构约束 - 业务逻辑必须写在 service 层，controller 只做参数校验和响应封装 - 数据库操作全部通过 repository 层封装，禁止在业务代码里直接写 SQL - 外部 API 的调用必须走统一的 httpClient

写到这里其实可以停一下反思：这个文件写的质量，决定了 Claude 在这个项目里的下限。如果你连测试命令都不写，它每次想跑测试都靠猜；如果你不说明目录约束，它改代码时可能把业务逻辑直接堆进组件里。项目模板就是在"训练"你的 AI 协作对象，值得认真对待。

5.3 模板的版本管理与团队共享

项目模板文件跟随 git 仓库走，天然有版本控制，这个不用多说。真正需要设计的是个人模板库的同步方式。我的做法是把~/.claude/整个目录做成一个 git 仓库，推到私有远端。换机器时git clone下来直接生效。团队内部可以在仓库里加一个共享目录，例如team-shared/，按命令名拆分，新成员拉取后统一合并到自己目录。

注意一个细节：~/.claude/目录下有一些与机器相关的文件，例如历史聊天记录、本地缓存文件。所以我在~/.claude/下只把commands/、CLAUDE.md等有效模板文件纳入 git 管理，其他文件全部加进.gitignore。模板库是"资产"，但本地状态是"环境变量"，两者不能混。

6. 踩坑实录：模板使用中常见的五个问题

再好的模板体系，用起来也难免踩坑。下面这几个问题是我自己和团队同事都真实遇到过的，整理出来供你对照排查。

6.1 路径和权限问题：模板里的工具调用被拒绝

命令模板中如果写了allowed-tools: Bash，模板可以自动执行 bash 命令；如果漏了，Claude 每次尝试执行命令时都会弹权限确认，造成中断。

我的建议是：模板中的allowed-tools越保守越好。只声明当前模板真正需要的工具，而不是把全部工具列上。例如commit.md只需要 Bash 和 Read，就没必要给 Write 权限。安全性和便利性要权衡，不要图省事。

6.2 上下文爆炸：模板太长导致 Claude 丢失重点

模板不是越长越好。我早期写过一份很"全面"的代码 review 模板，清单拆了十多项，每项下面还有子项。实际用下来，Claude 反而容易出现"每项都沾一点但每项都没说透"的结果。后期精简成 5 个核心维度 + 1 条铁律，效果反而稳定。

原因是 Claude 在长上下文里对信息重要度的判断与人类完全不同。信息密度越高，它越倾向于均匀分配注意力，反而丢失了重点。所以模板设计的核心不是"塞满所有要求"，而是"做减法、分清主次"。如果你发现某一类任务反复出现质量不稳定，优先怀疑模板过长而不是能力不够。

6.3 依赖模型版本特性：某些模板新版本失效

Claude Code 版本更新后，一些模板语法或工具行为会变化，尤其是权限模型和历史版本之间的兼容问题。建议每次升级 Claude Code 后，先跑一遍你最常用的 3 个命令模板，确认输出格式没有异常。

6.4 模板与项目的割裂：个人模板再好也要对齐项目约定

最大的坑不是模板写不好，而是模板写得很"通用"，完全没考虑项目特性。比如你的个人模板里要求"函数式组件用 hooks 管理状态"，但当前项目还在用 class 组件，那模板产出就直接不可用。所以项目级模板一定要单独维护，不要偷懒全部复用个人级模板。我的经验是：个人级模板管"格式和表达"，项目级模板管"技术栈和架构约束"，两层结合才可靠。

7. 从"能跑"到"好用"：打磨模板的三个阶段

这是我个人在使用 claude-code-templates 过程中体会最深的三个阶段，分享出来供你参考。

第一个阶段是"让模板跑起来"。别追求完美，先把手头最高频的 5 个场景做成模板——提交代码、代码 review、生成测试、解释代码、写技术方案。能用就行，格式不统一也无所谓。这个阶段的目的是建立习惯，让你感受"斜杠命令带参数"的工作流比每次重新写 Prompt 舒服多少。

第二个阶段是"让模板稳定"。稳定是指同一份模板在不同项目、不同时间的输出质量波动小。做法是给每个模板补齐三件事：明确的输出格式说明、必要的示例、质量约束（例如"不要为了凑问题而凑问题"）。此时你会开始区分命令模板和提示词模板的使用边界，也能体会到$ARGUMENTS与$1的语义差异带来的控制力提升。

第三个阶段是"让模板沉淀成团队资产"。把个人模板库 Git 化，在团队内共享目录约定，新成员加入时 10 分钟配置完一套完整模板体系。你会发现团队协作时，Claude Code 的输出质量下限被整体抬高，因为大家共享的是同一套"协作说明书"，而不是各聊各的。

我在实际使用中还有一个很深的体会：模板是 AI 协作里少数可积累的资产。模型会更新、工具会变化，但你整理出来的这套模板体系，能让你在任何一次新模型、新版本发布后快速切换。与其纠结于"哪个版本的模型更强"，不如先把模板这座护城河挖好。希望这篇文章的排查链路和实战案例，能帮你早日建立属于自己的 Claude Code 模板体系。