企业官网建设流程全解析

整理 Claude Code 配置这件事，我一开始是很随意的：今天往 CLAUDE.md 里塞一段规范，明天在 .claude/commands 下丢一个脚本，后天又从某个项目里复制一条命令到另一个项目。直到文件越攒越多、各项目之间的配置开始互相打架，我才认真起来，把它们统一收进了一个叫 claude-code-templates 的仓库里统一管理。这篇文章就把这套模板体系的组织思路写出来：Claude Code 的模板到底分几类、每类怎么写才不容易失效、出了问题是应该怎么排查，以及从零搭一个自己的模板仓库时该从哪下手。内容偏实践经验，适合已经用过一段 Claude Code、但还没系统整理过配置的开发者参考。

1. 先把模板分清楚：记忆、命令、技能这三层不能混

很多人听到 claude-code templates，第一反应就是"哦，CLAUDE.md 嘛"。实际用下来你会发现，这个工具里能被称作"模板"的东西至少有三类：CLAUDE.md 长期记忆文件、自定义 Slash 命令、Skills 能力包。这三者解决的问题完全不同，混在一起写，配置很快就会变得臃肿且难以维护。

1.1 CLAUDE.md：项目的"长期记忆"，比 README 更讲究

CLAUDE.md 是 Claude Code 每次启动会话时自动加载的项目说明文件，相当于给 AI 助理的一份入职手册。它记录的是"这个项目是怎么运转的"：构建命令、测试入口、目录结构、代码风格、哪些操作有风险。它的核心价值在于让 Claude 在每轮对话中保持对项目的一致理解，不需要你反复重新介绍背景。

我把 CLAUDE.md 和 README 做过一次对比之后，才真正理解它的定位：README 是给人看的项目介绍，可以讲愿景、讲架构、讲设计取舍；CLAUDE.md 是给模型看的操作手册，应该讲"遇到什么情况怎么做""哪些事情不能做"。写的时候要克制，别把技术博客的内容搬进去，重点回答三个问题：命令怎么跑、规矩有哪些、出错先查哪。

1.2 自定义 Slash 命令：把高频动作固化成快捷方式

如果你发现自己每隔几天就让 Claude 做同一件事，比如 review 改动、生成 commit message、整理 changelog，这类重复流程就应该做成自定义命令。它们存放在项目的 .claude/commands/ 目录（或用户级 ~/.claude/commands/）下，每个 Markdown 文件就是一条命令。在对话框里输入斜杠命令加上参数，Claude 就会按照你预设的步骤执行。

这层模板的价值在于流程标准化。一个人写的 review 步骤和另一个人写的可能差别很大，但一旦固化成命令，团队所有人都能照着同一个标准去跑。而且命令可以限制允许使用的工具，从机制上防止 AI 在某个环节跑偏。

1.3 Skills：可移植的"专业能力包"，能夹带脚本和数据

Skills 是比 Slash 命令更重的一层模板，它除了提示词，还可以包含可执行脚本、参考资料、数据文件。适合场景是：某个能力你希望 Claude 在多个项目里都会用，而且需要工具配合，比如性能分析、依赖审查、特定格式的数据转换。

这三者的关系我常用一个类比：CLAUDE.md 是长期记忆，slash 命令是肌肉记忆，Skill 是随身工具箱。日常协作中，记忆负责稳定发挥，命令负责提效，工具箱负责处理需要专业知识的场合。最好把它们分层管理，而不是堆在一个文件里。

三类模板的对比我用一张表总结，方便你规划自己的配置：

2. CLAUDE.md 的具体写法：层级、导入和内容筛选

CLAUDE.md 看起来是个纯文本文件，但写出"不吵架"的配置还是有套路。我踩过不少次配置文件互相覆盖的坑，后来才把层级和写法理顺。

2.1 三层记忆结构：用户级、项目级、本地级各司其职

Claude Code 的长期记忆是分层的，我实际用下来至少有三层：

• 用户级：~/.claude/CLAUDE.md，记录你个人的通用偏好，比如"我习惯用 pnpm""提交信息遵循 conventional commits""回答问题时优先给精简方案"。它跨项目生效，相当于个人总纲。
• 项目级：项目根目录下的 CLAUDE.md，记录这个仓库独有的信息，比如模块划分、测试命令、发布流程。它是团队共享的，应该提交到版本控制里。
• 本地级：CLAUDE.local.md，与项目级同目录，但它只对本地生效，通常不提交。适合放你本机的数据库连接方式、临时调试脚本路径等私货。

我见过最典型的错误，是把个人偏好写进项目级 CLAUDE.md，结果同事接手时被迫继承你的行文习惯；反过来说，把项目独有的路径信息放到用户级模板，换个项目就会误导 Claude。判断标准很简单：内容换个环境还成立吗？成立就往上放，不成立就往下放。

2.2 用 @import 把大文件拆小，别让记忆文件膨胀

项目一大，CLAUDE.md 很容易写到几百行。能用，但没必要。因为这份文件每次对话都会被加载进上下文，里面塞满低频信息反而会稀释真正的重点。我的做法是把它拆成多个片段，在主文件里用 @import 引用。

主文件大概长这样：

# 项目记忆 开发命令见 @docs/build-and-test.md 代码规范见 @docs/conventions.md 发布流程见 @docs/release.md

这样拆完之后，主文件只保留最高优先级的规则，细节都放到对应片段里。更新时也只改对应文件，比在一个几百行的文档里找位置修改省心很多。拆分粒度我按"一个文件只讲一类事"来定：接口约定单独一个，部署流程单独一个，CI 说明单独一个。

2.3 什么内容值得写进记忆，什么内容应该坚决不写

写 CLAUDE.md 最大的成本不是写字，而是它每次都要被加载。所以内容质量远比数量重要。我自己有三条筛选标准：

• 写会重复发生的事：构建命令、测试命令、提交规范、目录说明。
• 写容易踩坑的警告：哪个目录不能删、哪个服务只有特定环境才有、哪个依赖必须走内部源。
• 不写一次性信息：某个 bug 的完整分析过程、临时任务的细节、还在讨论中的方案。

另外，CLAUDE.md 是有时效性的。我基本保持每一两周过一遍的节奏，把项目中已经变化的内容同步进去。如果你发现 Claude 的行为变得古怪，比如项目已经换了构建工具它还按旧命令执行，第一反应应该是检查 CLAUDE.md 是不是漏改了。

3. Slash 命令模板：把高频操作压缩成一条斜杠

如果说 CLAUDE.md 提供的是背景知识，那自定义命令就是动作模板。前者让 Claude 知道规则，后者让 Claude 按固定流程执行。这一节讲命令文件的具体结构和几个值得收藏的模板。

3.1 命令文件的结构与关键元信息

一条命令就是一个带 YAML frontmatter 的 Markdown 文件，文件名即命令名。frontmatter 里我常用这三个字段：

• description：在命令列表里展示的简介。务必写清楚这条命令是干什么的，越具体越好，这既方便人识别，也方便模型判断什么时候该调用。
• argument-hint：提示用户应该输入什么参数，比如 " " 或 "[filename]"。
• allowed-tools：限制这条命令能使用的工具。对权限敏感的流程来说，这个字段比文件内容更重要。

文件正文部分就是给 Claude 的指令，可以直接按对话的方式写步骤。比如我常用的 review 命令长这样：

--- description: Review current branch changes against team standards argument-hint: [可选：指定检查范围] allowed-tools: Git, Read, Grep --- 先运行 git status 和 git diff --stat 确认改动范围。 如果用户提供了检查范围，只审查该范围内文件。 按照团队代码规范逐项检查：依赖引入是否合理、错误处理是否完整、命名是否符合项目风格。 最后输出一份 review 结论，每条问题标注严重程度和建议修改方式。

注意 allowed-tools 里我刻意没给写文件和执行修改相关的工具。这样 review 流程从机制上就被限定成只读操作，AI 不会在审查过程中自作主张去改代码。

3.2 四类可以直接改用的命令模板

我在模板仓库里维护的命令大致可以分成四类：

• 流程类：/review 负责审查改动，/commit 负责按规范生成提交信息，/test 负责跑测试并解读失败原因，/refactor 负责按指定方向重构。
• 检索类：/explain 让 Claude 先定位相关文件再解释一段逻辑，/find 让它按职责而不是按关键字搜索代码，适合在陌生代码库里快速上手。
• 输出类：/changelog 把一段时间内的改动整理成发布说明，/summary 把长对话或长 diff 提炼成周报素材。
• 初始化类：/add-command、/add-rule 这种"自举"命令，让 Claude 帮你把新的命令和规则写进模板文件。我已经用它生成了好几条新命令，比自己手写快多了。

3.3 参数传递的细节：$ARGUMENTS 不是万能的

命令文件里可以通过 $ARGUMENTS 拿到用户在命令后输入的整段内容，也会解析出 $1、$2 这样的位置参数。比如有人敲 /commit 只改测试，模板里就能写"本次提交的重点是 $ARGUMENTS，请据此调整提交信息措辞"。

但这个机制有个容易踩的点：如果参数里带了引号或特殊字符，直接嵌入模板文本可能解析出错，尤其是涉及 shell 拼接的时候。我的处理方式是，在模板中明确要求 Claude 不要拿参数去做 shell 拼接，而是先读取相关文件内容再决定执行动作。把参数的"语义"交给模型理解，而不是机械替换。这样既安全又灵活。

4. Skills 模板：把脚本、知识和流程打包带走

Skill 和 Slash 命令最大的区别在于它可以携带脚本和参考资料，是一套"附带上手材料"的能力包。当你要在多个仓库里重复使用同一套专业流程时，把它做成 Skill 是最划算的。

4.1 SKILL.md 的最小可用结构

一个 Skill 本质上就是 .claude/skills/<名称>/ 目录下的 SKILL.md 文件，frontmatter 里声明 name 和 description。其中 description 要写得像"给 AI 的广告语"，因为它直接决定了模型在什么场景下会主动想到调用这个 Skill。

例如描述写"当用户询问页面加载缓慢时使用，能系统性检查资源体积、请求链路和渲染瓶颈并给出分级优化建议"，就比笼统写"性能分析工具"要管用得多。模型的调用判断依赖这个描述，写得模糊，Skill 大概率会被晾在一边。

SKILL.md 的正文写使用步骤，旁边还可以放 references 目录存详细资料、scripts 目录存可执行脚本。Claude 启用 Skill 时会按正文指引去读取这些资源，所以模板不再只是一段话，而是带数据的完整工作流。

4.2 一个可复用的 Skill 示例

举个例子，我让 Claude 在检查前端性能时有一套固定打法，就建一个 .claude/skills/perf-check/SKILL.md。正文里规定每次先收集关键资源加载时间，再检查图片体积、脚本拆分情况、接口串行情况，最后输出分级优化建议。scripts 里放一个抓取性能数据的脚本，references 里放团队的性能预算说明。

这样到了新项目，把整个目录复制到新项目的 .claude/skills 下，把描述里的项目名改一下，这个能力就迁移过去了。相比每次手动粘贴一长串提示词，Skill 的可复用性和稳定性都好很多。

4.3 模板仓库怎么组织这些内容才不乱

既然标题叫 claude-code-templates，我就直接说这个仓库的布局。我的仓库根目录分成三个区：

claude-code-templates/ ├── memory/ # CLAUDE.md 片段，按领域拆分 ├── commands/ # 已验证可用的 slash 命令 └── skills/ # 可跨项目迁移的能力包

每个区里再按用途细分目录。同步到具体项目时，我不会把整个仓库一股脑复制过去，而是各取所需：memory 里的片段按项目情况选择性导入，commands 按团队需要拷贝，skills 按项目岗位拷贝。仓库本身是"原材料市场"，项目目录才是"实际使用现场"，两者分开反而好维护，至少不会出现改命令时误伤某个正在用的项目。

5. 模板不生效时的排查链路：我踩过的坑

模板写得再漂亮，不生效就白搭。这一节记录几个我高频遇到的排查场景，按问题现象分，方便你对号入座。

5.1 命令列表里找不到新命令

新加了一条 slash 命令，重启后列表里却没有。我遇到过的原因有几种：文件名忘了 .md 后缀、frontmatter 里的冒号打成了全角、命令放错了目录层级。尤其是目录层级——.claude/commands/ 下的一级文件名才直接对应命令名；如果你建了子目录，比如 .claude/commands/code-review/review.md，那命令名会变成 /code-review:review，调用的时候要带上前缀。

这个设计其实是刻意的，因为团队命令多了之后用子目录分组很清晰，但新手容易卡在这里。想改命令名最简单的方法就是改文件名，不用去其他地方绕。

5.2 @import 的内容疑似没生效

用了 @import 之后，感觉 Claude 完全没按导入的内容办事。这种情况要分两头查。第一，路径问题。相对路径在不同目录层级里的解析结果可能和你想的不一样，排查时直接在对话里让 Claude 查看那个文件是否存在，确认路径没写错。第二，内容过长。Claude 处理上下文时有取舍，导入的文件越长，被完整读取的概率就越低。所以拆分文件时要控制单个文件的行数，我的经验是单个片段不超过 50 行，超过就继续拆。

顺带说一句，导入文件的内容也要和主 CLAUDE.md 一样克制。就算路径全对，往导入文件里塞一堆废话，模型在实际执行时还是会忽略。

5.3 frontmatter 语法静默失败：写一条验一条

YAML frontmatter 看着简单，但坑不少。布尔值、引号、特殊字符，任何一个出问题都可能导致命令解析失败，而且很多失败是静默的，不报错，只是命令不可用。我的习惯是写完一条命令立刻跑一遍，而不是攒一批再统一验证。配合日志排查，基本能定位到是哪一行 YAML 出了问题。

还有一个容易被忽略的点：description 写得太模糊，会导致模型在对话中"自作主张"地调用命令。表面上看命令生效了，但调用时机完全不对。所以 description 要写得足够明确，把适用边界讲清楚，这反而能减少误触发。

如果你排查多层配置的时候拿不准是哪个文件生效，打开调试模式看加载了哪些文件是最直接的方式。模板类问题大多出在路径、命名、加载顺序这三件事上，按这个顺序查，基本都能定位。

6. 搭一个属于你自己的 claude-code-templates 仓库

最后聊落地。标题里既然有 templates，那这篇文章的终点必然是搭出个真能用的仓库。我不建议上来就搞大而全，正确的起步姿势其实很轻。

6.1 初始化：先建三目录，再填第一条命令

先建好 memory、commands、skills 三个空目录，然后只做两件事：把最近一个月重复做过的事情列出来，挑频率最高的三条做成命令模板；再把项目里最常被问起的五条约定写进 CLAUDE.md。有了骨架和第一批内容，后续就是增量更新了，不会有面对空白仓库不知从何下手的焦虑。

6.2 分发与更新：个人自用和团队共享是两套节奏

个人使用的话，git clone 到本地，项目里用符号链接或拷贝对应文件都行。但团队场景建议走正式流程：模板仓库单独开分支，改动提 PR，至少让另一个人确认过 frontmatter 格式和命令的实际行为再合并。原因很简单，团队里读过你命令的人都会默认它是验证过的，未经验证的模板发布出去，比没有模板危害更大。

模板仓库还一定要和具体项目解耦。我见过有人直接在项目里改模板，项目删除后所有沉淀全没了。正确做法是回到模板仓库里改，改完再同步到项目；如果项目里发现了更好的写法，也要反向同步回仓库。双向同步这条规则看似麻烦，实际是防止配置漂移的关键。

6.3 定期做减法：模板是有半衰期的

模板会过时、命令会失效、规范会更新、脚本会跑不动。我大概每三四周做一次全量审查，把不再使用的命令标记删除，把重复的 Skill 合并掉。删模板比写模板更需要决心，但一个精简的仓库，使用体验远好于一个堆满"可能有用"文件的仓库。

最后说点个人体会。模板真正的价值不在于你写了多少文件，而在于每次开新项目时少重复多少话。我现在每接手一个新仓库，会先花半小时把 CLAUDE.md 和常用命令配齐，之后的工作里，能明显感觉到 Claude 和我在沟通上的废话少了很多。工具版本会一直更新，但把工作方法沉淀成模板这个习惯，放哪个工具上都不过时。