企业官网建设流程全解析

1. Claude Code Templates：从"能跑"到"稳定产出"的分水岭

真正把 Claude Code 用得顺手的人，几乎都绕不开 Templates 体系。我在终端里写 AI 辅助代码已经大半年了，早期是打开对话就开始问，后来发现同样的审查、同样的测试生成、同样的重构套路，每次都要重新描述一遍需求，而且描述质量时好时坏，输出质量也忽上忽下。直到我把项目里所有重复性的任务全部模板化，才明显感受到什么叫"稳定的产出水平"。

Claude Code Templates 本质上是给 Claude Code 做的预制件：它把命令、上下文、行为规范、角色设定打包成文件，放在项目里，让 AI 每次用同一套标准去执行任务。适合的人群很明确：每天高频使用 Claude Code 的开发者、在团队里推广 AI 编程规范的技术负责人、以及对 prompt 工程有强迫症、希望每次交互都可复现的人。如果你只是偶尔问一句"这个报错什么意思"，那 Templates 可能不是你现在最需要的东西；但只要你开始让 AI 负责一整套任务流程，这套东西就是刚需。

我印象最深的一次转变是：我们团队三个人用同一个模板库做代码审查，Claude 给出的问题列表居然惊人地一致，优先级判断也差不多，于是"AI 审查结果到底靠不靠谱"这个问题第一次变成了"我们定的审查标准到底对不对"。模板不是让 AI 变聪明，而是让 AI 稳定地输出同一水平的结果，这比偶尔的超常发挥更有价值。

2. 模板体系的第一课：先分清四类模板各管什么

很多新手拿到 claude-code-templates 这类项目，第一反应是"把文件复制进.claude就行"，结果发现有些模板生效了，有些怎么都不触发，翻来覆去折腾一晚上。根子在于没搞清楚 Claude Code 的模板其实分成四类，每一类的存放位置、触发方式和更新时机完全不同。

2.1 Slash Command：藏在斜杠里的快捷指令

最常见的模板形式是 Slash Command（斜杠命令）。在 Claude Code 终端里输入/review、/test、/refactor这类命令，就是在调用对应模板。模板本身是 Markdown 文件，放在.claude/commands/目录下，文件名就是命令名，比如.claude/commands/review.md对应/review。

每个命令文件顶部有一个 YAML frontmatter，用来声明 description、参数名、允许使用的工具等元信息。正文就是实际发给模型的指令内容，支持$ARGUMENTS接收用户输入，也支持$1、$2这样的位置参数。这个设计非常贴近 Unix 哲学，一条命令解决一类问题，输入参数可以精细控制。

值得专门说的是NEW.md和TODO.md这两个特殊文件。NEW.md会在每次创建新会话时自动注入，适合放项目核心规则；TODO.md会在每次任务结束时读取，用于维护待办进度。很多团队把整个项目的编码规范、目录结构的说明放在 NEW.md 里，效果比每次手动粘贴要好得多。

2.2 CLAUDE.md：项目的"长期记忆层"

如果说 Slash Command 是单次任务的指令模板，CLAUDE.md 就是项目的长期记忆。Claude Code 在每次会话中都会自动加载这个文件，它告诉模型"这个项目是什么、代码风格是什么、哪些绝对不能碰"。它不是可选的辅助文档，而是 Claude Code 工作方式的核心组成部分。

CLAUDE.md 支持嵌套：放在项目根目录的会对整个项目生效，放在子目录里的则对该目录及子目录生效。这个特性非常实用，比如在frontend/子目录里写一份专注于组件规范和 CSS 惯例的说明，在backend/里写一份关于数据库迁移规则和接口设计约束的说明，互不干扰。嵌套的优先级是子目录覆盖根目录，这为不同模块的差异化约束提供了实现途径。

很多人容易犯的错误是把 CLAUDE.md 当成 wiki 来写，内容动辄几百行。实际上模型的上下文窗口是有限的，每个目录只应写目录内最关键的约定，建议控制在 30 行以内。信息密度比信息数量重要得多，这一点在踩过几次上下文被占满的坑之后体会尤深。

2.3 Agents 与 Subagents：把角色模板化

Templates 的第三类形态是 Agents，即把某种角色设定和行为边界模板化。在.claude/agents/目录下创建 Markdown 文件，定义该 agent 的职责、可用工具、输出风格，然后在对话中用@agent直接引用。

这个机制远比简单的 system prompt 定制要深。比如你可以定义一个@code-reviewer，它只能读文件、不能改文件，只做审查而且必须按项目规范输出问题列表；再定义一个@test-writer，它只负责生成测试代码，输出格式绑定到项目的测试框架。这样做的好处是角色之间的职责边界变得清晰，不会出现"让它写测试结果它顺手把源码也改了"的失控情况。

Subagents 是 Claude Code 在任务执行时自行调用的子代理，通常由主模型根据任务复杂度决定是否需要拆分。通过定义subagent类型的模板，你可以为高频子任务设定专用的模型和工具集，既节省主模型的上下文，又提升并行效率。

2.4 Hooks 与文件模板：藏在自动化里的第三只手

Hooks 是一种事件驱动的模板机制，它和前面三类最大的不同在于：不需要用户主动触发——只要满足特定事件条件，Claude Code 就会自动运行预设的脚本或命令。常见事件包括PreToolUse（工具调用前）、PostToolUse（工具调用后）、Notification（通知时机）等。

例如可以在每次 Claude 修改文件之后自动运行 lint 和格式化，不合格就把信息反馈回上下文，让模型自行修正。这相当于给 AI 加了一道自动质检闸门，比事后人工审查要高效得多。文件模板是另一类轻量机制，通过FileCreation钩子在模型创建新文件时自动应用头注释、许可证声明等固定格式，从源头统一风格。

你不需要一开始就把四类全部用上。大多数人第一步只需要 Slash Command 加 CLAUDE.md，就能覆盖 80% 的重复场景；等跑顺了再引入 Agents 和 Hooks，逐步构建完整的自动化闭环。

3. 单机实战：从零搭建一套自己的模板库

理解了分类之后，最关键的问题就是怎么上手。我建议所有第一次做模板库的人不要直接拷贝别人的模板，而是先理解每一个字段的含义，再写出适合自己的版本。下面是我搭建模板库的完整过程，每一步都有可以直接抄的代码和为什么如此设计的解释。

3.1 目录初始化与 CLAUDE.md 骨架搭建

先在项目根目录创建如下结构：

mkdir -p .claude/commands mkdir -p .claude/agents touch CLAUDE.md

CLAUDE.md 是模板库的地基，它决定了模型对整个项目的基本认知。我的起步版本长这样：

# 项目记忆 ## 项目类型 - 这是一个 Node.js + TypeScript 的 CLI 工具项目 - 包管理器使用 pnpm - 代码目录结构遵循 src/modules 分层 ## 编码规范 - 使用 2 空格缩进，单行不超过 100 字符 - 所有函数必须有 JSDoc 注释 - 禁止使用 any 类型，优先使用 interface 而非 type ## 测试约定 - 测试框架使用 Vitest - 测试文件命名：<module>.test.ts - 测试必须覆盖边界条件和异常分支 ## 禁止事项 - 不要修改 src/vendor 下的任何文件 - 数据库迁移必须生成新的迁移文件，不允许修改已有迁移 - 不要为了通过类型检查而使用 ts-ignore 或类型断言

这里有一个非常关键的设计原则：CLAUDE.md 必须是"可执行"的规范。不要写"代码要保证质量"这种废话，而要写"函数必须用 switch 而非 if-else，超过三个分支必须拆函数"。模型对具体规则的执行力远强于抽象概念。

3.2 Slash Command 模板的 frontmatter 与正文

在.claude/commands/下创建一个review.md，这是最基础的模板形态：

--- description: 对当前改动进行代码审查 model: claude-sonnet-4 --- 请对当前的代码改动执行严格审查，重点检查： 1. 逻辑正确性：是否有边界条件遗漏、空值处理缺失 2. 类型安全：是否有 any 类型、不安全的类型断言 3. 异常处理：错误是否被正确捕获和传递 4. 性能隐患：是否有高复杂度循环、N+1 查询 5. 代码风格：是否符合 CLAUDE.md 中定义的规范 审查标准： - 必须指出具体文件、行号、问题原因、修复建议 - 按严重程度分级输出：Critical / Major / Minor - 如果没有发现问题，必须显式说明"未发现明显问题"

frontmatter 里的description字段会在输入/review时显示给用户，帮助确认命令用途。model字段可以指定该命令使用哪个模型，这对成本控制很有用——简单任务走小模型，复杂重构再上大模型。

正文部分我总结了一条经验：模板越"专制"，结果越稳定。不要给模型太多开放式的自由裁量空间，明确到"按以下五个维度逐项检查""必须输出文件号和行号"，输出质量立刻提升一个档次。

3.3 变量、参数传递与命令组合技巧

Slash Command 模板支持接收用户输入，这大大提升了复用性。看一个测试生成的例子：

--- description: 为指定模块生成单元测试 --- 请为 $ARGUMENTS 对应的模块生成单元测试。 要求： - 测试文件中应包含以下内容： - 正常路径测试 - 边界值（如空字符串、最大值、undefined） - 异常路径测试 - 使用项目已有的测试框架和断言风格 - 测试方法命名遵循 should_xxx_when_xxx 规范 - 不要 mock 内部依赖，优先使用真实实例

使用方法是在聊输入/test src/utils/format.ts，$ARGUMENTS就会被替换成src/utils/format.ts。

模板之间还可以互相引用，在某个模板中键入@review就能调用另一个命令。这个组合能力让流程编排成为可能：比如一个/hotfix模板，第一步让模型分析问题根因，然后调用/test生成验证测试，再调用/fix执行修复，最后调用/review审查。单条命令就能驱动一整套工作流。

还有个容易忽略的细节：凡是以.md结尾的命令文件，文件名中不能包含空格；而命令名与文件名严格一致，这也意味着设计命令名时就要考虑"短、好记、不冲突"。/review、/test、/fix这类单动词名是最优选择。以!或#!开头的命令还能直接执行 bash 命令，例如/update-deps内部先运行git pull再让模型解释变更，这种"先执行、再分析"的模式在自动化巡检时非常实用。

3.4 Agents 模板：定义角色的三个层次

创建一个 agent 模板，本质上是要定义三个层次：身份层、能力层、行为约束层。我在.claude/agents/security-reviewer.md里这样写：

--- name: security-reviewer description: 安全专项代码审查专家，只读模式 tools: Read, Grep, Glob model: claude-sonnet-4 --- 你是一名专注于应用安全审查的高级工程师，关注 Web 应用常见安全漏洞。 ## 职责范围 - 仅负责安全相关审查，不处理业务逻辑、代码风格等非安全议题 - 只使用只读工具，不得修改任何文件 ## 审查清单 1. 注入类漏洞：SQL 注入、命令注入、XSS 2. 认证与授权：越权访问、session 固定、密码存储方式 3. 敏感信息泄露：硬编码密钥、日志中打印敏感数据 4. 依赖安全：已知 CVE 的依赖版本、非法来源的依赖包 ## 输出要求 - 每个问题附带 CVSS 风格的风险评级（高/中/低） - 给出可操作的修复建议，并标明对应文件路径 - 若未发现安全问题，必须显式说明

理解这三个层次，才算真正会用 Agent 模板。身份层决定模型以什么角色思考；能力层通过tools字段限制它能用哪些工具，这是安全边界；行为约束层通过输出格式的明确要求保证结果可用性。

tools字段只接受 Claude Code 内置工具白名单，比如 Read、Write、Edit、Grep、Glob、Bash、WebSearch 等。给 agent 最小权限是最重要的安全实践：审查类 agent 只需 Read 和 Grep，生成测试的 agent 才需要 Write。因为 agent 可能被 prompt injection 攻击诱导进行破坏性操作，权限收得越紧越安全。

角色类模板还有一层容易忽略的进阶玩法：环境和规则引用。在 agent 模板正文中可以用#!bash执行一段命令来动态生成上下文，比如让模型先git diff --stat再看当前分支改动；也可以用@path/to/file引用仓库里的文档，让 agent 在启动时拥有额外的项目情报。动态上下文的引入，极大扩展了模板的"感知范围"。

4. 三个高频场景的模板编写实录

光讲概念不够，我直接把三个打磨过很多轮的模板拿出来，逐行解释为什么这么写，以及实践中踩过的坑。

4.1 代码审查：如何让 AI 审查结果真正可用

很多人写审查模板，写到最后就是一句"请检查代码质量"。这样输出的结果基本没法用，因为模型会泛泛而谈。我的做法是给审查任务套一个刚性框架：

--- description: 对照项目标准审查当前分支的代码改动 model: claude-sonnet-4 --- 执行代码审查，输出格式如下： ## 审查结果 ### Critical（必须修复） - [ ] 问题描述（含文件:行号） - [ ] 修复建议 ### Major（强烈建议修复） - [ ] ... ### Minor（可优化项） - [ ] ... ## 审查依据 - 逐条说明每个问题对应项目的哪条规范或通用最佳实践

关键点在于"审查依据"一节。模型在输出问题后还必须解释"依据是什么"，这能强制它从"看起来像有问题的直觉"走向"规范层面上的判断"。这个设计让审查结果的争议性大幅降低，团队在评审会上讨论的也从"AI 说得对不对"变成了"我们的规范需不需要调整"。

4.2 测试生成：把边界条件和覆盖率写进模板

生成测试是 AI 最擅长的场景之一，问题在于它爱偷懒。我见过不少 AI 生成的测试，正常路径写一堆，边界条件一个都没有。所以测试模板必须把"偷懒路径"堵死：

--- description: 为指定模块生成完整单元测试 --- 请为 $ARGUMENTS 生成单元测试。 ## 必测场景 1. 正常输入-正常输出 2. 空输入：''、[]、{}、null、undefined 3. 边界值：最大值、最小值、长度恰好为 0/1/limit 的情况 4. 异常输入：类型错误、格式非法 5. 依赖失败：mock 第三方依赖抛错时的行为 ## 覆盖率要求 - 语句覆盖率 ≥ 90% - 分支覆盖率 ≥ 80% - 生成后先运行测试，失败则自行修复 ## 测试风格 - 使用项目既有测试框架 - 测试名统一为 should_xxx_when_xxx - 禁止使用 jest.spyOn 监控内部实现，优先测行为而非实现

我特意加了一条"生成后先运行测试，失败则自行修复"，把闭环从"生成代码"延伸到"通过验证"。实测下来，这行字能把首次通过率从 60% 拉到 85% 以上。

4.3 重构模板：给 AI 装上护栏再去动代码

重构是风险最高的操作，AI 很容易在过程中"顺手"改变一些不该变的逻辑。我的重构模板分三步走：

--- description: 执行一次受控的业务逻辑重构 --- 请对 $ARGUMENTS 执行重构，严格按以下流程推进： ## 第一步：建立基线 先阅读目标模块及其所有测试，输出： - 模块职责的简要概述 - 当前实现的问题清单（不含优化建议） - 依赖关系图 ## 第二步：重构计划 等待用户确认后，制定重构计划： - 改动文件清单 - 每项改动的目的（纯移动 / 纯重命名 / 行为变更 / 性能优化） - 预计影响范围 ## 第三步：执行重构 执行时遵守： - 每完成一个文件的改动，必须运行该模块的测试 - 禁止改变模块对外暴露的接口签名 - 禁止在重构过程中新增功能 - 如遇测试失败，回滚该文件改动并以问题报告形式输出

这个流程的核心是"把重构拆成三步，每步都设卡点"。模型在第一步只观察和汇报，不输出代码，这能避免过早动手改错方向。第二步要求等待确认，把决策权留在人手里。第三步的"禁止新增功能"和"回滚"两条约束，是为了防止最常见的 AI 重构事故——改着改着夹带私货。

5. 从模板到工作流：团队级模板库的落地实践

当模板数量超过 10 个、使用人数超过 3 人时，模板管理就从技术问题变成了工程问题。这一节聊聊我在团队推广过程中的经验。

5.1 命令入口设计：让团队成员不需要想"该怎么问"

模板库的核心价值不在于提供更多命令，而在于给团队成员铺一条"标准操作路径"。我在项目里设计了一组互不重叠的命令：/review查质量、/test补覆盖、/refactor做重构、/explain读代码、/ticket拆任务。成员接到任何需求，先在这五个命令里选一个对应的，剩下的事情交给模板引导。

这个设计的巧妙之处在于用命令入口替代提问能力。新人不熟悉 prompt 工程，不知道要怎么描述需求才能让 AI 输出高质量结果，但模板已经替他做了 80% 的描述和约束工作。实践中，新成员在上手第一周就能输出和老手差不多的 AI 协作质量，这在没有模板的时代是不可想象的。

5.2 模板的版本管理：把模板当代码来维护

我强烈建议模板库单独建 Git 仓库，并且把模板变更纳入 Code Review 流程。每次修改模板都要附带"为什么改"的说明，和改业务代码一样严谨。template 的变更往往影响所有使用者的日常行为，一个草率的改动可能让全团队下一周的 AI 输出质量集体下滑。

团队模板管理的另一条铁律是：先讨论规范再改模板。模板是规范的可执行固化，如果团队的代码审查标准本身就模糊，模板怎么写都不会好。优先把"什么算 Critical"这类问题在团队里达成共识，再把它翻译成模板语言。模板只是沉淀规范的工具，规范本身才是本体。

5.3 模板与 Hook 联动：全自动质量闸门

当模板库稳定后，就该引入 Hooks 做自动兜底了。下面是一个实际可用的.claude/settings.json配置片段，用于在编辑文件后自动运行 lint 和格式化：

{ "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "pnpm exec eslint $CLAUDE_FILE_PATH --fix" }, { "type": "command", "command": "pnpm exec prettier --write $CLAUDE_FILE_PATH" } ] } ] } }

这段配置让每次 AI 写完代码后自动执行 ESLint 修复和 Prettier 格式化。模型会在后续上下文中看到 lint 结果，如果 lint 报错，它会继续修复。实测中，加上这道闸门后，merge request 里的"AI 代码风格问题"评论数量几乎降到了零。

Hook 的进阶用法还包括Notification钩子，在每次模型回复结束后自动汇总状态；PreCompact钩子在上下文快满时执行结构化的信息压缩，把关键状态保留到后续继续对话。你可以把 Hook 理解为模板体系的"条件反射"层，它和主动调用的命令模板互补，构成完整的自动化链条。

5.4 模板共享：跨项目复用的正确姿势

最后说说共享。团队内部建议用claude template系列的插件把这些命令打包成一个可分发的插件包，.claude-plugin/marketplace.json定义入口，其他同事一条命令安装。

跨项目复用时需要注意上下文差异。通用的 Slash Command 模板（如 review）可以直接共享，但 CLAUDE.md 必须按项目重写。我给团队建立了一套"三层模板"实践：第一层是纯通用规则（shared 仓库维护），第二层是组织级规范（如安全基线、编码规范），第三层是项目级细节（目录结构、技术栈决策、历史坑位）。每一层严格独立，变更是从上到下逐层渗透的。新人加入时先看第一层，再进项目时自动加载第二、三层，循序渐进，不 overwhelm。

6. 踩坑实录：模板使用中的高频问题排查

用了这么久，我把最常见的几个问题和排查思路整理成一个速查表，碰到问题先对照自己属于哪一类，能省不少时间。

我在实际使用中遇到最诡异的一次是：模板文件在，命令也认了，但输出内容完全忽略模板里的输出格式要求。排查了半天发现是模板文件里混入了一个 BOM 字符，导致 frontmatter 解析异常。用sed -i 's/^\xEF\xBB\xBF//'清理之后一切恢复正常。这种事情只有遇到才会意识到文本编辑器对模板文件的影响，所以模板文件最好用纯命令行编辑器维护，或者至少定期检查编码格式。

还有一个高频踩坑点是$ARGUMENTS的使用时机。有些命令在被@引用时，子模板里的$ARGUMENTS会变成空值，这是因为 command 的上下文传递机制和直接调用不同。如果发现组合命令时参数丢失，可以在父命令中用环境变量的方式传值，或者明确定义子模板的参数接口，不让它依赖隐式注入。

模板依赖顺序也是一个容易忽视的坑。当多个 Agent 协作时，如果 Agent A 依赖 Agent B 的产物，但两者在同一个会话里被同时唤醒，可能会出现空值竞争。我的解法是把这种依赖关系写进模板正文："如果检测到 <依赖文件> 不存在，先调用 @b 生成该文件再继续"，用显式指令消除时序不确定性。

最后想说一个认知层面的坑：模板不是写一次就能一劳永逸的。模型的版本、工具的更新、团队规范的变化都会让旧模板逐渐失效。我现在的习惯是每隔两周花半小时过一遍模板库里的所有命令，删掉不用的、改掉过时的、补上新发现的场景。这个过程比最初搭建模板库更有价值，因为模板只有在持续迭代中才能跟上团队的真实工作流。

我自己的体会是，claude-code-templates 的价值不在于收藏别人的模板，而在于倒逼你把团队的工作方式想清楚，然后用模板固化下来。等模板开始产生复利的时候，你会发现 AI 编程的效率瓶颈早就不在模型能力上，而在你对流程定义有多精确这件事上。