企业官网建设流程全解析

1. 模板资产为什么值得单独建仓：从一次痛苦的Prompt复制说起

过去很长一段时间，我对"AI编程模板"这件事是相当随意的。工作需要让Claude Code做代码审查，就从聊天记录里翻出一条写得还算顺手的Prompt，复制粘贴；需要生成单元测试，又从另一个项目里捞出一段指令。这样凑合着用，表面上省了事，实际上踩了个大坑——今天这条Prompt能用，明天同一句话换个项目语境就完全失效，要么生成一堆废话，要么干脆答非所问。直到我开始认真对待"claude-code-templates"这个思路，把模板当作和代码同等重要的资产来管理，才意识到之前浪费了多少时间。

这个仓库的核心价值，说白了就是把那些"一次性写对了就再也不想重写"的指令固化下来，变成一套可复用、可演进、可共享的资产。它适合的不仅是天天和命令行AI工具打交道的开发者，还包括那些在团队里负责技术规范、想要把最佳实践沉淀下来的技术负责人。模板不是简单的Prompt收藏夹，它更像项目里的测试用例——每个模板都对应一种具体场景，你需要知道它为什么有效、什么时候会失效、怎么维护它。

我最终建立的这套模板体系，围绕Claude Code的机制展开：./claude/目录下的配置、CLAUDE.md这种项目记忆文件、自定义斜杠命令以及hooks。了解这些载体之后，你会发现模板的威力远不止"少打字"这么简单。

1.1 Claude Code模板的承载机制：CLAUDE.md、斜杠命令与hooks的配合

先说CLAUDE.md，这是Claude Code在启动时会自动读取的项目级说明文件。它的作用类似于给AI一份"项目说明书"，告诉它当前的代码库结构、技术栈、编码规范、常用命令。很多人把这个文件写成流水账，几百行的堆砌，结果AI每次启动都要消化大量无用信息，反而干扰判断。我的建议是把它做成索引式的短文档，核心原则是"只描述稳定的约定，不描述正在变化的内容"。

在这个基础上，模板就有了落地的地方。你可以把通用指令做成自定义斜杠命令，比如/review、/test、/refactor，这些命令定义在./claude/commands/目录下，每个命令对应一个Markdown文件。命令文件里写的是完整指令模板，Claude Code会把它注入到上下文中执行。这样做的最大好处是：团队里的每个人都能用同一套指令，而不是各自从聊天记录里翻Prompt。

hooks则负责在特定时机自动触发模板逻辑。比如我设置过这样一个hook：每次生成代码时自动检查是否包含TODO标记，如果包含就要求AI说明遗留原因。这种"主动拦截"比事后审查高效得多，因为问题在产生的那一刻就被处理了。

1.2 模板集合的分层思路：通用层、项目层、个人层

模板建仓的第一步，是先分清三个层次，否则文件一多就会乱成一锅粥。

通用层放那些跨项目成立的模板，比如代码审查、测试生成、提交信息规范、README撰写。这些模板不依赖具体业务，在任何仓库里都能用。项目层放针对当前项目特殊性的模板，比如某个系统里独有的错误码处理规则、数据库迁移流程、部署检查清单。个人层则是你自己习惯的补充，比如我习惯在生成SQL时强制要求输出执行计划分析，这个偏好不值得写进项目规范，但放在个人模板里每次都能生效。

这三层需要分开存放，通用层放全局配置目录，项目层放版本库里，个人层放主目录下的单独区域。这样做的原因很实际：通用模板的价值在于跨项目复用，一旦和项目层混在一起，每次克隆仓库都会把无关指令带进来，污染上下文。项目层则必须进版本库，因为它是和代码配套的，换人来接手项目也必须能看见。个人层不入库，因为那是私有的工作习惯。

这样的分层看起来简单，实际执行中最大的阻力是"懒"。大多数人一开始会把所有模板都塞进CLAUDE.md，因为它最省事。但CLAUDE.md一膨胀，AI每次启动都要消耗大量token去理解那些和当前任务无关的指令，响应质量会明显下滑。我大概是在CLAUDE.md超过200行、AI开始频繁漏读关键约束的时候意识到必须分层的。

2. 仓库骨架设计：目录结构、命名规范与版本同步

如果你去GitHub上翻那些优秀的claude-code-templates仓库，会发现它们做得好的地方首先在于目录结构清晰。模板仓库和代码仓库一样，骨架决定可维护性。我最初建的模板仓很快就失控了，原因就是没有预设结构，今天想到什么问题就新建一个文件，文件名还特别随意，什么review-template.md、tmpl_for_sql.md，过两周根本不知道谁是谁。

后来参考了几个被大量收藏的模板集合，再结合自己的使用习惯，我沉淀出一套稳定的目录设计：

claude-code-templates/ ├── commands/ │ ├── review.md │ ├── unittest.md │ ├── refactor.md │ ├── sql-explain.md │ ├── commit.md │ └── doc-gen.md ├── CLAUDE.md ├── hooks/ │ ├── check-todo.md │ └── post-process.md ├── guidelines/ │ ├── code-quality.md │ └── security-checklist.md └── scripts/ └── validate_templates.py

commands目录放斜杠命令，文件名就是命令名，语义自解释。hooks目录放钩子逻辑的说明文档。guidelines目录放那些不直接触发、但需要AI长期遵循的长篇规范。scripts目录可以放一些维护模板仓库本身的小工具。

2.1 命名规范：动词开头、场景唯一、避免模糊词

模板文件命名是最容易敷衍、长期收益却最高的环节。我踩过的坑是用了review.md和code-review.md这种近义命名，结果自己都分不清该用哪个。现在的命名规则很简单：动词开头、场景唯一、禁止模糊词。

review.md、test.md、refactor.md这类是场景动词，直接对应一个动作。高阶一点的规范是用"动词+对象"组合，比如audit-dependencies.md、migrate-legacy-module.md，这样不仅清楚，而且和斜杠命令的触发词天然对齐。绝对不要用helper.md、useful.md这种名字，除非你想让模板仓库成为只有自己能看懂的暗号本。

2.2 模板文件内部的YAML前置元信息

每个模板文件需要有元信息字段，目的是让AI和人都能快速判断这个模板的适用边界。我用的模板头部结构如下：

--- name: unittest-generator description: 为目标函数生成符合项目风格的单元测试 when: 传入需要测试的函数路径时使用 requires: 函数所属模块的源码路径 disabled: false ---

这些元信息不只是给人看的。Claude Code在加载自定义命令时，会把description和when字段作为触发条件判断的一部分，写清楚了能显著减少"用错模板"的概率。我在团队里推行这套规范后，最直接的改善是：以前同事经常问"这个模板是不是只能在Python项目里用"，现在看一眼元信息就有答案了。

2.3 模板仓库的版本同步与文档配套

模板仓库和代码仓库一样，需要版本管理，也需要README。README的意义不仅是使用说明，它还是模板集合的"入口地图"。一个合格的README应该包含：这个仓库覆盖哪些场景、每个目录的用途、如何安装到Claude Code的配置路径、新增模板的流程。

我在README里放了一张简单的表格，列出场景、命令名、适用项目类型、依赖项，这样新人进来第一眼就知道有没有自己需要的模板，不用一个个文件去翻。版本同步的策略也有讲究：如果公司内部有多个项目同时使用这套模板，建议用Git子模块或者发布固定版本，而不是让每个项目各自复制。我见过最差的实践是把模板文件直接copy到各项目里，后来某项目改了审查规则，其他项目完全不知道，再次合并代码时审查标准五花八门。

3. 五个能直接落地的模板案例拆解

模板光有框架不行，关键看内容。下面这几个模板来自我当前正在用的仓库，是最常用也是打磨次数最多的，每个都附了完整示例和设计思路。

3.1 代码审查模板：从泛泛而谈到逐层收敛

最普通的代码审查Prompt是"请审查这段代码"，AI会给你一堆正确的废话，比如"代码整体质量良好，建议增加注释"。问题出在缺少约束条件。我的代码审查模板给AI指定了审查路径和输出格式：

你正在对以下代码进行审查。审查时严格按以下层次开展： 1. 正确性：先指出任何可能导致逻辑错误或边界条件遗漏的问题，按严重程度排序。 2. 安全与资源管理：检查错误处理是否完整，资源是否确定释放，输入校验是否到位。 3. 可维护性：指出命名、函数长度、重复逻辑等影响后续维护的问题。 4. 性能：只在有明确证据表明存在性能问题时提出，不要做无依据的优化建议。 输出要求： - 每条问题必须给出对应行号或函数名，方便定位。 - 每个问题必须附带一个最小修复思路，不要只提建议不给方案。 - 禁止输出空泛的夸奖，如果没发现问题，明确说"未发现问题"。 - 所有建议按"必要修改、建议修改、可选优化"三级分类。

这个模板的核心设计是"逐层收敛"。如果没有第一层的严重程度排序，AI经常把缩进问题和并发漏洞并列输出，阅读成本极高。第三层"可维护性"和第四层"性能"的顺序也是踩坑换来的——最初我把性能放在第二位，结果AI会对每个循环都建议优化，反而淹没了真正重要的正确性问题。

3.2 单元测试生成模板：注入项目风格约束

单元测试生成是另一个高频场景。默认的"生成测试"结果往往能用，但不完全符合项目风格，比如项目里用的是pytest的类分组，AI却生成了一堆独立函数；数据库操作本来需要mock，AI却直接发起真实调用。测试模板需要显式声明项目里已有的测试基建：

基于以下要求生成单元测试： - 测试框架：pytest（遵循项目现有的测试组织方式，类覆盖同一模块下的相关函数） - 数据库操作：一律使用 mock，禁止发起真实数据库连接；参考 tests/mocks/db_mock.py 的既有写法 - 命名风格：函数名用 test_<被测函数>_<场景>，断言使用 <expected> 优先，不堆砌无关断言 - 覆盖目标：分支覆盖率覆盖到被测函数的所有 return 分支，边界值必须单列测试 - 输出格式：直接返回可运行的测试代码，不要附带解释 被测函数路径：{{function_path}}，请先阅读源码，再列出需要mock的外部依赖，最后生成测试。

模板里用了{{function_path}}这种占位符，我会通过如下的方式与代码库联动，让AI自动识别当前函数位置，然后在命令输入里补全。这个模板的另一个隐藏收益是：AI需要先列出要mock的外部依赖，这一步强制它阅读源码，而不是看了函数签名就直接生成，测试质量明显提升。

3.3 SQL排查模板：用执行计划说话

日常开发中，SQL相关的排查占了我不少时间。这个模板的目标很直接：遇到慢查询或异常SQL时，让AI以DBA的视角而不是普通开发者的视角处理问题。

角色设定：资深数据库工程师，擅长通过执行计划定位SQL性能瓶颈。 任务输入： - SQL语句 - 表结构（可自动读取项目中的schema定义） - 问题描述（慢查询、锁等待、结果集异常） 处理流程： 1. 先分析表结构和查询条件之间的索引匹配情况，指出全表扫描的位置。 2. 无论问题是否与性能相关，先格式化为可读形式，标注出嵌套子查询/临时表位置。 3. 输出优化建议时，必须给出重写后的SQL，并说明为什么新写法可以减少扫描行数。 4. 如果有执行计划文本，逐步解释每个节点的开销来源。 5. 严禁只给建议不给重写后的SQL。

在命令里我会要求AI先读取最近的数据库慢日志文件，把真实SQL作为输入。这样的效果和单独用对话窗口问"这个SQL怎么优化"完全不同，因为AI能结合表结构和具体数据分布给出可落地的方案，而不是泛泛地建议"加索引"。

3.4 提交信息规范模板：把项目约定变成肌肉记忆

提交信息看起来不是技术难点，却是我见过团队规范执行最差的一环。原因是人在准备提交时注意力都在代码上，没人愿意费心思去套格式。这个模板的价值在于把格式约定变成自动化约束：

请根据本次变更内容，生成符合项目Conventional Commits规范的提交信息。 规范要点： - type 使用 feat / fix / docs / style / refactor / perf / test / build / ci / chore / revert - scope 为变更涉及的模块名，按 package 或主目录名填写 - 正文需要描述变更导致的用户可见行为变化，而不是罗列代码操作 - 破坏性变更必须在信息中标记 BREAKING CHANGE，并解释迁移方案 - 不要生成超出实际代码变更范围的承诺性描述

这个模板配合hooks使用效果最佳。我会在pre-commit阶段调用这个模板生成建议信息，让开发者直接采用，而不是每个人自己敲键盘。执行一段时间后，团队里的提交信息不仅格式统一了，可检索性也大幅提升，回溯线上问题时效率高了很多。

3.5 遗留系统重构模板：安全网优先

重构老代码是最依赖上下文的任务。没有约束时，AI很容易兴致勃勃地帮你"改进"代码风格，同时悄悄改变了行为逻辑。重构模板的核心理念是"安全网优先"：

目标：对指定模块进行结构化重构，不改变任何对外行为。 步骤： 1. 先为模块生成覆盖现有行为的关键测试，运行通过后再开始重构。 2. 识别模块与外部系统的所有交互边界（函数入口、事件、数据库读写、API调用），列出清单。 3. 重构过程中，每个步骤保持可编译、可测试状态，每完成一个子模块合理停顿等待确认。 4. 对不可测试的遗留代码，先标注风险区域，不得擅自改写。 5. 重构完成后，提供变更前后结构对照图，并指出行为等价性如何验证。

这个模板的关键词是"每一步保持可运行"。默认情况下AI会更倾向于一次输出大量重构代码，出问题后定位成本极高。这条约束看起来简单，实际执行时能避免很多灾难性后果。

4. 模板调试的完整链路：为什么我的模板有时候"失灵"

模板写出来不是终点，调试才是常态。我维护模板仓库一年多的经验告诉我，一个模板从初版到稳定，至少要经过四五个版本的迭代。而且"失灵"的原因往往不在模板本身，而在加载机制和上下文管理。

4.1 优先级与上下文窗口的博弈：指令互相覆盖

Claude Code加载指令的优先级是有顺序的，如果模板里的指令和相关配置发生冲突，会出现AI"突然忘了"某条规则的情况。我遇到过最典型的例子：代码审查模板要求禁止空泛夸奖，但项目CLAUDE.md里写着"回复时确保语气友好"，两条指令叠加后，AI选择了讨好用户，输出了一大段"整体实现得非常好，我给出以下建议"。

定位这类问题的方法并不神秘。我给Claude Code开了输出日志，在排查时查看对话启动阶段实际加载了哪些指令文件、生效顺序如何。排查后发现优先级规则和我理解的不一样——./claude/commands/下的命令注入位置其实在项目级CLAUDE.md之后，和它冲突的指令会被命令内容覆盖。知道这个顺序后，我调整了相关描述，把"禁止空泛夸奖"这类硬性规则写进了项目CLAUDE.md而不是命令行模板里。

4.2 通过日志和输出反推：建立模板的"信心测试集"

调模板不能只靠肉眼感觉。我会为每个核心模板准备一组小型的"测试输入"，每次修改后都跑一遍，确认输出是否符合预期。比如审查模板的测试输入是一段故意埋了三个问题的小函数，测试模板的测试输入是一个典型的CRUD模块。

这其实借鉴了软件工程里的回归测试思想。模板也是代码，改了一个变量可能影响所有下游。没有测试集，你很难判断这次改动是变好了还是变坏了，全靠主观感觉很容易被一次偶然的好结果误导。

4.3 变量替换与动态拼装：把固定模板变成活模板

模板的终点应该带有参数化能力，而不是固定文本。以我的代码审查模板为例，定义部分输入参数：

• {{function_path}}：目标函数源码路径
• {{review_type}}：取值为routine（日常变更）或critical（核心路径变更）
• {{security_level}}：是否启用额外安全审查（如涉及支付、权限模块）

变量替换的逻辑是让命令入口先做一次轻量分析，根据上下文自动选择模板片段的拼装方式。这样比让用户手动改指令更可靠，减少了使用阻力。

调试这类动态模板，建议一开始不要用AI做全量判断，而是在本地用脚本验证占位符替换后的模板是否完整、有没有残留变量语法。这种问题在小样本下很难暴露，但一旦出现，AI会直接拒绝执行。

5. 这套方法用久了之后：我踩过的坑和沉淀出来的习惯

模板体系运行半年之后，我开始遇到新的问题——这些问题的根源，恰恰是模板太成功了。

5.1 模板膨胀的失控：从资产沦为噪声

模板数量超过30个之后，问题开始浮现。首先是命令触发器冲突，两个模板用同一个动词开头，AI反而不知道该选哪个。其次是上下文污染，模板集合默认会被Claude Code读取，数量越多，每次启动消耗的token越多，响应速度变慢，指令间的干扰也增加。

我的处理方式是给模板分级：一级模板是每天必用的核心指令，必须放在最优先的加载位置；二级模板是每周几次的辅助指令，需要时通过命令主动触发，不参与默认加载；三级模板是低频长尾场景，统一归档到单独目录，需要用的时候再临时指定路径。

这种分级淘汰机制让模板集合维持在相对精简状态。每季度我会做一次"模板淘汰评审"，看每个模板的实际调用次数和输出的使用率，那些调用少且效果模糊的模板直接删掉。模板和代码一样，没有人维护的废弃资产，比没有更糟糕。

5.2 团队共享模板时的权责划分

单独使用模板时，自己就是唯一的维护者，怎么改都行。团队共享后，问题就复杂了。我见过最混乱的局面是：有同事往公共模板集合里塞了自己的个人偏好，结果其他人执行审查时多了一堆和项目无关的检查项，大家又不敢乱删，只能忍受。

现在我在团队里定了一条规则：公共模板只允许放经过至少两人确认的通用规则，任何带个人偏好的内容必须放到个人模板层，用个人配置覆盖全局配置。修改公共模板需要"变更理由+影响范围"说明，并在提交信息里注明，这样出了问题容易回溯。

5.3 关于模板思维的一点坦白

我不认为模板是越多越好，也不建议所有人都去搭一套庞大的模板体系。如果你只是偶尔用一下Claude Code，花半小时写三个和自己工作最相关的小模板就够了，关键是解决重复劳动最集中的场景。

我目前的状态是：模板仓库稳定在15个左右高效命令，CLAUDE.md精简到100行以内，每个模板都有明确的触发场景和边界，团队里新加入的成员可以先看README、再执行两遍核心模板就大致了解项目约定。

这套方法给我的收益是实实在在的："重复的劳动交给模板，判断的事情留给自己"，每次打开终端的时间成本压缩了三分之一，输出的质量反而更稳定。