企业官网建设流程全解析

claude-code-templates 是我最近半年一直在维护的一套 Claude Code 模板仓库。说白了，就是把高频任务、固定角色、标准流程这些经常重复的东西，提前写成文件，让 Claude 在每次对话里直接拿来用，不用我每次重新敲一遍提示词。这篇文章不打算写成教程，我就把我怎么设计、怎么搭建、踩过哪些坑，完整复盘一遍。适合正在用 Claude Code 做日常开发、或者想在团队里推广 AI 辅助编程的人看，哪怕你只是刚接触 CLI 编程助手，也能从这里捋清楚模板到底解决了什么真问题。

模板不是新鲜概念，IDE 有代码模板，脚手架有项目模板，语言有项目生成器。Claude Code 出现以后，我把同样的思路搬到了“提示词”上。你要是不做模板化，每次开新会话都得重新介绍项目背景、技术约束、期望输出，一上午就在重复这些事。而一旦把上下文固化成文件，效果是立竿见影的：输出风格稳定了、错误率降了、新人也能跑出老师傅的流程。

围绕这套模板仓库，我主要做了三件事：分类设计模板、用 CLAUDE.md 做默认上下文、用自定义斜杠命令把模板挂到高频操作上。接下来我把每一步的思考过程都展开讲，包括掉进的坑。

1. 我为什么整理 claude-code-templates：先搞清楚痛点再动手

1.1 默认会话的“失忆感”有多费时间

用 Claude Code 写代码，最大的挫败感不是它不会，而是它“不记得”。同一个仓库，昨天刚给它讲过模块划分、依赖关系、禁用某些库，今天开一个新会话，它又像一个新人对你说：这个目录是干什么的？那语气礼貌得让人头疼。

我可以理解，每个会话确实是一次干净的上下文。但现实是，我的工作量翻倍了：先花 5 分钟贴背景，再花 5 分钟解释规范，然后才敢让它动手。若是多任务切换，比如同时维护 API 服务、前端页面、数据迁移脚本，这种重复解释的成本按天计算就很可观。

所以整理 claude-code-templates 的第一个动机非常简单：把“每次都要重说的项目常识”变成持久化文件。项目根目录放一份 CLAUDE.md，记录技术栈、启动方式、测试命令、代码风格、禁止事项；用户目录放一份通用规范；全局目录再放一份跨项目的通用原则。会话一开，这些内容自动变成 Claude 的上下文，相当于它第一天入职就给你发了一本内部手册。

这个改进的收益远超我的预期。不仅省了重复解释的时间，还避免了“解释不到位导致模型理解跑偏”的问题。省下来的注意力可以放到真正需要判断的地方。

1.2 提示词在团队里靠口口相传，根本沉淀不下来

我身边不少团队用 Claude Code，方式非常原始：每人手里一堆私藏的提示词。代码审查用一段，写测试用一段，生成迁移脚本又一段。这些提示词存在各自笔记里，风格还完全不同。

带来的直接问题是：同一个任务，两位成员交给 Claude 做，产出的质量、格式、口径差别很大。A 的审查只盯着逻辑 bug，B 的审查会连带补测试建议；A 的提交信息简洁，B 喜欢长篇大论。最后汇总时，还是得靠人肉统一。

把提示词模板放进仓库以后，团队就有了共同的工作语言。我把常用的 review、test、refactor、commit 都做成了斜杠命令和 skill 文件，成员直接/review、/test调用，得到的就是同一套规范下的结果。这比开会强调“大家注意统一风格”有用得多。

还有个容易忽略的点：模板让“隐性经验”变成“显性资产”。你们团队里架构师怎么思考模块拆分？资深测试关注哪些边界条件？这些判断如果能沉淀成文档模板，即使该同事休假，新人也能借助模板跑出接近他的工作流。这是我做模板时最看重的长期价值。

1.3 模板化以后，普通同学也能按流程走

做运维和开发最怕“老师傅手艺不外传”。指挥 Claude Code 其实也是手艺活，会问问题的人，能拿到高质量结果；不会问的人，可能得到一篇漂亮但没用的废话。

模板化恰好把这个手艺给“翻译”成人人能用的按钮。比如一个“架构方案评审”模板，内置了并发量评估、数据一致性、扩展性、耦合度这些维度，哪怕提问者对这些维度没什么概念，只要按模板执行，Claude 也会自动按这些维度输出。门槛一下就降下来了。

这让我意识到：模板不仅是效率工具，还是团队的能力杠杆。不需要每个人都变成提示词工程师，只要少数人维护模板，就能让整个团队享受稳定的 AI 协作收益。这也是我会长期迭代这个仓库的根本原因。

2. 模板分类：任务、角色、流程三层模型

模板不能乱堆。我自己吃过亏，刚开始看到好的 prompt 就往仓库塞，很快就堆积了三四十个文件，真正用到的却只有两三个。后来我重新整理，把所有模板分成三层：任务型、角色型、流程型。

2.1 任务型模板：让每个指令都有明确边界

任务型模板针对的是“一次性动作”。比如给函数补注释、生成单测、修复 lint 报错、优化某段查询。这类模板的写法，关键在于定义清楚输入、约束、输出格式，我最常用的是两个：

• /unit-test：给定文件和被测函数，自动生成单测。内置约束包括必须 mock IO、覆盖正常边界异常三种路径、不允许为了覆盖率删断言。
• /refactor-safe：给定重构目标，要求先列影响面、再拆步骤、每步执行完跑一次测试，全程禁止“顺手修改与本次重构无关的逻辑”。

任务型模板最忌讳的是写得过细。你见过那种把预期措辞都写死、一段话恨不得十个“务必”的模板吗？结果就是模型被限制得毫无创造性，遇到真实情况还会卡壳。所以我的经验是：只约束不可违背的原则，比如安全边界、输出结构、禁止事项，把自由度留在中间。

2.2 角色型模板：把“专家人设”塞进上下文

角色型模板的核心不是让模型“扮演”角色，而是让它继承一套特定的审查看法。角色写得好，它输出的东西整体质量会有明显提升。

我维护了四个角色：架构师、代码审查员、安全审计、性能调优。这里分享一个心得：写角色模板时，不要只写“你是资深架构师”，这五个字对模型几乎没意义。真正有用的是对这个角色“评估维度和工作习惯”的描述。比如架构师模板里我会写：先关注模块边界是否清晰，再关注依赖方向是否合理，最后才看实现细节；会主动标注可扩展点的位置，但不会为了“扩展性”强行引入模式。

角色型模板通常还会配一个负面清单。比如安全审计模板明确写：不要只盯着 SQL 注入和 XSS，还要关注越权访问、敏感信息泄露、第三方依赖风险。有了这些约束，Claude 的思维才更像一个经验丰富的审计员，而不是应届生。

2.3 流程型模板：把大目标拆成有序步骤

任务型管单步，角色型管视角，流程型管整条链路。以“从需求到交付”的典型流程为例，我写了一个/feature命令，它会按阶段拆分：

1. 先解析需求：问题陈述、用户场景、验收标准、假设条件。
2. 再输出技术方案：改动点、风险、数据库影响、测试策略。
3. 方案确认后才写代码。
4. 写完之后自动跑测试并生成变更摘要。

流程型模板的难点在于“节奏控制”。Claude Code 默认会一口气往下冲，你让它提方案它就把代码写完了，你让它重构它顺手就把依赖改了。所以流程模板里我会大量使用阶段性确认：每个步骤结束都要求它先向用户汇报结果、等待确认再继续。这让 AI 协作更像真正的协作，而不是放手让脚本乱跑。

2.4 元模板：用来生成模板的模板

“元模板”听着玄乎，其实很简单：既然新模板会持续产生，那我就做一个 template-for-template 的标准模板，避免每次新建模板时重新想结构。它包含统一的 frontmatter 字段、固定的正文章节：背景、输入、约束、输出、负面清单、验证方法。

我在仓库里维护了一个_template.md文件，新建模板时直接复制改名。这可能是我做的最划算的投资。别看只是省一个模板骨架的时间，它最大的价值是让所有模板结构一致，后面做自动化检查、团队评审都方便。

3. 承载模板的三件套：CLAUDE.md、Skills、自定义命令

模板写好之后，得知道怎么挂到 Claude Code 里。这里把三套机制分开讲清楚，很多人混着用，最后一起失效。

3.1 CLAUDE.md 的三级上下文：项目、用户、全局

CLAUDE.md 可以理解为“自动加载的提示词手册”。它有三个层级：

• 项目级：项目根目录/CLAUDE.md或.claude/CLAUDE.md，只在该仓库生效。
• 用户级：~/.claude/CLAUDE.md，对当前账号所有会话生效。
• 全局级：用claude --global启动时会加载全局配置目录里的 CLAUDE.md。

我的用法是分门别类：全局 CLAUDE.md 只放所有项目通用的内容，比如代码风格偏好、回答语言、commit 信息格式；用户级放与个人工作习惯相关的内容；项目级放仓库特有信息，比如技术栈、目录结构、测试命令、常见坑。层级重叠时，项目级优先级最高，这正是我想要的：特殊越具体越优先，谁也覆盖不了谁。

注意一个小坑：项目级 CLAUDE.md 属于仓库的一部分，可以被团队共享，也意味着你改了什么都会进 git diff。所以别把个人日常唠叨写进去，更别把自己的私有习惯写进公共仓库。

3.2 Skills 目录：SKILL.md 是入口，resources 是弹药

如果你只想写几段提示词，CLAUDE.md 够用了。但要是想封装一套“带文件和工具配合”的复合能力，Skills 是更合适的载体。

Skills 的目录结构长这样：

.claude/skills/code-review/SKILL.md .claude/skills/code-review/resources/review-checklist.md

SKILL.md 用 YAML frontmatter 声明元信息：

--- name: code-review description: 当用户要求审查代码、检查 PR、评审 MR 时使用，执行一次规范的变更审查 allowed-tools: View, Bash ---

description 是模型判断“这个 skill 是否适用于当前任务”的关键，写得太宽泛会导致误触发，写得太窄会导致不触发。我一般会在里面放清晰的任务条件和触发词。

resources 目录里的文件不会自动塞进上下文，而是在 Claude 判断需要时，按需引用。这个设计很好，解决了上下文长度问题：你把重资料放在外面，用到时再加载，相当于把硬盘挂在笔记本旁边。

3.3 自定义斜杠命令：把模板压缩成一个/指令

CLAUDE.md 是背景，Skills 是复合能力，自定义斜杠命令则是“最直接的手动入口”。

命令文件放在.claude/commands/，文件名决定指令名。你可以写：

• code-review.md，通过/code-review调用；
• unit-test.md，通过/unit-test调用。

命令文件同样支持 frontmatter。我最常配的是description和allowed-tools，偶尔还会用model强制用小模型或大模型来跑。命令里也可以引用当前目录下的文件，甚至通过$ARGUMENTS接收参数。

说实话，斜杠命令是我日常使用频率最高的部分。它把“模板”变成了肌肉记忆：一进终端，/review，回车，剩下的判断交给模型，我只需要看最后的输出清单。

4. 实操过程：从零搭出一套 claude-code-templates 仓库

理论说了一堆，下面把实操过程完整过一遍。这个仓库到目前为止我每天都会打开，你可以按它的结构照抄一份，再改成自己团队的内容。

4.1 仓库目录规划

这是我的目录结构，已经精简过：

claude-code-templates/ ├── README.md ├── global/ │ └── CLAUDE.md ├── user/ │ └── CLAUDE.md ├── project/ │ └── CLAUDE.md.example ├── commands/ │ ├── code-review.md │ ├── unit-test.md │ ├── refactor.md │ ├── feature.md │ ├── commit.md │ └── _template.md └── skills/ ├── code-review/ │ ├── SKILL.md │ └── resources/review-checklist.md └── git-workflow/ ├── SKILL.md └── resources/commit-conventions.md

分区的思路很简单：global、user、project 对应 CLAUDE.md 的三级位置，commands 放所有斜杠命令，skills 放需要组合的复杂能力。README 写上每个文件的作用和安装方法，避免三个月后自己也忘了。

4.2 写一个 code-review 命令的全过程

以 code-review 为例。创建.claude/commands/code-review.md：

--- description: 对当前分支的变更进行代码审查 allowed-tools: Bash, View --- 你是一位有多年一线经验的代码审查员。当前任务是审查工作区最近的变更。 执行步骤： 1. 先运行 `git diff HEAD`，梳理变更文件清单，并输出给用户确认。 2. 按变更文件逐一审查，对每个文件关注：正确性、可读性、边界条件、安全性、性能、命名一致性。 3. 每条问题必须标注：严重级别（阻塞/建议/可选）、文件与行号、问题描述、修改建议。 4. 审查完成后，输出一份“需要立即修复”的 Top 5 清单。 禁止事项： - 不要直接修改任何代码，本命令只做审查。 - 不要夸大问题，也不要把“风格偏好”当成“阻塞问题”。 - 不要重复列出同一处变更在不同文件里的同一问题。

这个命令我实际用了很久，最关键的设计是第 1 步：先让 Claude 输出变更文件清单并请求确认。这样做有两个好处：一是避免它漏看未跟踪文件，二是我能在审查前快速扫一眼它有没有理解错范围。

allowed-tools我限制为 Bash 和 View，不让它去执行构建或测试，避免审查过程中发生副作用。你如果希望它额外跑单元测试，可以在工具列表里加 Test 工具。

4.3 用 CLAUDE.md 把项目背景做成默认上下文

命令写好了，但如果没有 CLAUDE.md，Claude 还是不知道这个项目的技术栈和规范。我在项目根目录维护一份 CLAUDE.md，内容大概是：

# 项目背景 - 这是一个基于 FastAPI 的订单服务，使用 PostgreSQL 存储，Redis 做缓存。 - 目录说明：services/ 放业务逻辑，api/ 放路由，models/ 放 ORM 模型。 # 开发规范 - 提交信息统一使用 Conventional Commits 格式，如 feat(api): 添加订单查询接口。 - 禁止使用全局异常捕获兜底，必须逐类定义异常。 - 测试运行命令：make test，单测文件命名必须带 _test.py 后缀。 # 常见注意 - 不要同时修改数据库迁移文件和模型定义，应先改模型，后用 migrate 命令生成迁移文件。 - 订单金额相关逻辑涉及精度问题，统一使用 decimal，禁止直接用 float。

这份 CLAUDE.md 放进项目仓库后，每个新会话都会自动加载。它解决的不只是“背景说明”，更重要的是把团队规范写进了 AI 的默认行为里，相当于给 Claude 发了项目入职手册。

注意：CLAUDE.md 不是越长越好。我看到过有人写两百行，结果 Claude 每次都要读，浪费 token 不说，还会稀释重要约束的权重。我建议控制在 30 到 50 行，只放“影响着 AI 输出的约束”，放不下的细节丢进项目文档，需要时再引用。

4.4 Skills 示例：把 code-review 升级成可组合技能

斜杠命令适合手动触发，而 skill 更适合“模型在对话中自觉使用”。我把 code-review 同时做成了 skill，区别在于后者不靠用户下指令，而是当用户的提问触达条件时，模型会主动加载并执行。

SKILL.md 长这样：

--- name: code-review description: 当用户说话中包含“审查代码、review、查一下 PR、评估变更质量”等含义时，自动执行代码审查工作流 allowed-tools: Bash, View --- # Code Review 执行完整的代码审查流程： 1. 运行 git diff HEAD，列出变更文件。 2. 逐一审查变更，关注正确性、可读性、边界条件、安全性、性能、命名一致性。 3. 输出严重级别清晰、可操作的问题清单。 详细维度参见 resources/review-checklist.md。

resource 清单文件就是具体的检查维度，比如“是否处理了空列表”“是否对数据库查询设置了超时”“认证中间件是否在所有路由上生效”等等。这些维度放资源文件里，SKILL.md 里引用它，模型真正执行审查时会按需读取。

4.5 模板参数化：用一块模板闯多个项目

模板要想跨项目复用，必须支持参数。最朴素的方法是用$ARGUMENTS。以 commit 命令为例：

--- description: 根据当前变更生成 Conventional Commits 格式的提交信息 allowed-tools: Bash --- 请运行 git diff --cached，根据暂存区变更生成提交信息。 格式：<type>(<scope>): <subject> type 可选：feat, fix, refactor, test, docs, chore. 如果 $ARGUMENTS 提供了额外要求，把它作为约束条件附加到提交信息里。

我在多个仓库之间复用它，完全不需要改模板内容，因为命令运行时会根据当前仓库的实际 git 状态生成信息。参数化让模板库不用复制多份，这是控制仓库规模的关键。

5. 常见问题与排查避坑实录

模板系统好用归好用，踩坑也不少。下面按出现频率从高到低列几个我记忆深刻的。

5.1 模板没生效？先查这三个地方

模板不生效是最常见的挫败，90% 是低级问题。第一，文件路径。命令必须放在.claude/commands/，技能必须放在.claude/skills/<name>/SKILL.md，放错一个层级就完全不识别。第二，命名冲突。如果你定义了和内置命令同名的命令，内置的永远优先生效，你的文件会被静默忽略。第三，frontmatter 的 description 太宽泛，skill 也可能被错误触发或根本不触发。

排查的时候别靠猜，直接去对应目录ls一次，再看命令里有没有冲突。我自己的习惯是每个模板写好先跑一个最小场景，确认能加载再往仓库里放。

5.2 上下文爆炸：模板里塞了太多内容

模板写多了容易犯“大而全”的毛病。我最初在全项目级 CLAUDE.md 里塞了框架文档、历史决策、埋点规范、日志规范，结果每条会话上下文增长了快一倍，核心约束反而被淹没。

解决思路：CLAUDE.md 只放高频且影响输出行为的规则；长文档放到resources/或项目 docs 目录里，需要时用@path显式引用。SKILL 的 description 也要精简，模型按需加载资源文件而不是一股脑全读。

这里有一条实用的经验值：CLAUDE.md 超过 50 行时，建议做一次削减；当模型频繁出现“遗忘某条规则”，说明那条规则被太多噪音淹没了。

5.3 输出飘了：模型不按模板走怎么办

模板写了不等于模型百分百执行。有时候它自作聪明，跳过了“请求确认”直接改代码；有时候它输出格式不符合预期，比如问题清单里不标注严重级别。

我试过最有效的是两招：第一，在模板里显式写上“不要做什么”，负面约束往往比正面约束更有力；第二，要求模型在正式输出前复述自己的执行计划，比如“先做 XXX，再 YYY，如果你同意我就开始”，这一步能极大减少擅自行动。如果还是有突发状况，把这次执行记录丢回模板，作为反例提示。

5.4 模板维护的版本管理与团队同步

最后说下维护本身。我的仓库用 git 做版本管理，每个大改动打一个 tag。模板变更是隐性的，所以每次修改我都会顺手更新 README 里的变更日志，哪怕只有一行：改了什么、为什么改、影响了哪些命令。

团队同步时，我建议把整个仓库拉下来后，用符号链接把.claude链接到项目根目录，而不是每个人手工复制文件。链接坏了，一个make setup就能重建，不用靠人肉对版本。

最后聊一点个人体会。我做模板的第一反应往往不是“这个指令好”，而是“我最近五天里，这件事我重复做了几次”。重复次数小于三次的，不值得写成模板；重复五次以上、且每次都要解释一大段背景的，才是高质量模板候选。这个标准帮我筛掉了很多一时兴起的想法，也让 claude-code-templates 仓库保持精简可用。

另一个小技巧是：每次使用模板后，如果发现 Claude 的输出方向不对，别急着重写命令。把这次失败记录作为负面示例，追加到命令末尾。几次迭代下来，模板的准确度会肉眼可见地提升。这套东西走到现在，最大的价值反而不是省时间，而是让我的 AI 协作经验被沉淀下来，不再是散落在聊天记录里的一次性灵感。