1. 项目概述：为什么需要一套 Claude Code 模板

做 AI 编程助手落地有一段时间了，我最大的感受是：Claude Code 本身的底子很好，但真正决定它能帮你干多少活的，不是模型能力，而是你喂给它的那套“工作框架”。同样是让 Claude 写一个后端接口，有人花十分钟描述需求、反复纠正它的小毛病，有人直接甩过去一套项目模板，五分钟拿到一份符合团队规范的代码。差距就在模板上。

claude-code-templates这个项目，本质上是一套可复用的 Prompt 工程方案 + 项目骨架的组合。它不是单个提示词，而是把你在实际开发中反复用到的那套上下文、规则、示例、约束条件，沉淀成标准模板，让 Claude Code 在每次启动时都能“带着记忆”进入工作状态。可以理解为：你给 Claude 配了一份专属的《员工手册》，里面写清楚了团队的代码风格、接口规范、提交格式、测试要求，它不用每次入职都要重新摸索。

这套模板适合谁用？如果你正在用 Claude Code 写业务代码、做代码审查、维护项目文档，或者想把它接入团队协作流程，那模板的价值会非常直接。对新手来说，模板能帮你绕过大量“和 AI 磨合”的坑；对老手来说，模板能把你过去积累的调教经验固化下来，形成可复制、可交接的资产。我见过不少团队，prompt 都写在个人备忘录里，人一走经验就带走了，模板化就是为了解决这种“经验失传”的问题。

这篇文章不会只给你看几个模板文件就完了，我会把每个模板的设计意图、参数选择、踩坑记录都拆开讲清楚。包括：模板应该怎么分层、上下文窗口怎么省、不同场景（新项目初始化、代码续写、重构、Code Review）的模板差异、以及你在实际运行中一定会遇到的典型翻车场景。最后我还会放出一套我实际在用的模板结构，你可以直接抄走改改就用。

2. 模板设计的整体思路：分层、克制、可插拔

2.1 为什么单一大 Prompt 不如分层模板

很多人一开始的做法是写一个超级长的 Prompt，把项目背景、代码规范、工具使用说明全部塞进去。我自己也走过这条路，效果其实不太好。核心问题有两个：

第一，上下文窗口是稀缺资源。Claude 处理长上下文的效率再高，你塞进去 5000 字背景资料，它真正能“记住”并在每次决策时优先调用的，往往是最后部分和开头部分的内容，中间的大段很容易被稀释。这不是模型笨，而是注意力机制的天性。与其把所有东西堆在一起互相干扰，不如按功能拆开，按需加载。

第二，单一 Prompt 难以维护。你改了代码规范，要在大段文字里找到对应段落；团队加了新的工具链，也要手动拼进去。时间一长，这个超级 Prompt 就变成了没人敢动的“祖传代码”。分层之后，你想换工具说明就替换对应文件，想改代码风格就更新独立模板，互不影响。

我的做法是：把模板拆成 基础系统指令 + 项目级上下文 + 任务级操作指令 三层。基础系统指令告诉 Claude 它是什么角色、什么行为边界；项目级上下文描述当前仓库的背景、技术栈、关键词汇；任务级指令则面对具体场景，比如“写一个新功能时你要按这几个步骤走”“做 Code Review 时你要检查这几个维度”。这样组合起来，既不浪费 token，又能按任务类型自由切换。

2.2 模板内容的取舍原则

在设计模板内容时，我一直遵循几个原则，这里分享出来供参考：

• 只写靠经验才能知道的东西。通用知识不需要写进模板，比如“Python 的语法是什么”“HTTP 状态码有哪些”，这些模型本身就懂。模板要写的是你的项目里“约定俗成”的规则：接口返回格式是什么、数据库命名规范、错误码怎么定义。
• 示例比描述更有效。与其写“请写出符合规范的提交信息”，不如直接给两个 good example 和一个 bad example。Claude 对示例的模仿能力远强于对抽象规则的理解。
• 负面约束要明确。“不要使用第三方 HTTP 库”这句话，比“尽量保持简洁”有用得多。我发现给 AI 设定负面清单，能显著降低它“自由发挥”的概率。
• 留出接口而不是写死流程。模板不要把所有操作步骤都钉死，要给 Claude 留出“当情况 A 发生时，可以变通执行 B”的空间。否则你会得到一台只会按剧本走的死板机器。

说句实在话，这四条原则看起来简单，但每一条都是我踩过坑才提炼出来的。“示例比描述更有效”这条，起因是我在模板里写了一堆 API 设计规范，Claude 依然写出风格各异的接口，加了两个示例之后效果立竿见影。后来我意识到，人看规范往往也要看示例才直观，模型本质上也是在做模式匹配，给它好样本，比给它抽象的“应该”更有可能产出好结果。

2.3 模板目录结构规划

这是我现在在用的模板目录结构。你可以理解为模板的“骨架”，后续所有场景的模板都在这个框架下展开：

claude-code-templates/ ├── system/ │ ├── base.md # 基础角色定义与全局行为约束 │ ├── tool-use.md # 工具调用规则（何时执行命令、何时追问） │ └── security.md # 安全边界与敏感操作红线 ├── project/ │ ├── tech-stack.md # 技术栈说明与版本要求 │ ├── code-style.md # 代码风格与命名规范 │ ├── architecture.md # 项目结构说明与模块职责 │ └── glossary.md # 业务术语表 ├── tasks/ │ ├── new-feature.md # 新功能开发的完整流程模板 │ ├── bugfix.md # 缺陷修复专用模板 │ ├── refactor.md # 重构专用模板 │ ├── code-review.md # Code Review 检查模板 │ └── docs.md # 文档编写模板 └── examples/ ├── good-examples/ # 符合预期的示例输出 └── bad-examples/ # 不符合预期的示例输出（用于负面约束）

这个结构为什么这么定？核心考量是**“谁在什么情况下需要什么信息”**。system 层是任何任务都需要的基础，所以放最外层；project 层是项目维度，换项目才需要改；tasks 层是任务维度的操作指令，写不同任务时按需加载。好比一个工具箱：常用的趁手工具放在最上层，不常用的专项工具放在抽屉里，要用再拿，而不是把整个工具箱倒出来铺在桌面上。

3. 模板落地实操：核心文件的写法与关键参数

3.1 基础系统指令：base.md 的写法

base.md是整个模板体系的底座。它需要完成三件事：定义角色、设定行为边界、给出通用工作流。我实际用的核心内容如下，你可以看结构和措辞，不必照抄文字。

# 角色定义 你是本项目的资深开发工程师，你精通当前项目的技术栈，并且熟悉业界最佳实践。 你的目标是帮助我高效、高质量地完成开发任务。在提供代码或建议之前，你会先理解需求背景， 如果有不明确的地方，你会主动向我提问而不是猜测。 # 工作方式 1. 每次接到任务，先复述你对任务的理解，确认没有偏差后再动手。 2. 修改代码前，先说明你的修改计划：涉及哪些文件、影响面是什么、风险在哪里。 3. 写代码时，遵循项目既有的代码风格和架构约定（详见 project/code-style.md 与 project/architecture.md）。 4. 完成后，提供一个简洁的变更摘要，说明改了什么、为什么改、有没有潜在副作用。 # 行为红线 - 不擅自修改与任务无关的文件。 - 不直接执行可能造成破坏性影响的命令（如删除文件、修改数据库结构），必须提前告知并等待确认。 - 不确定的事情，宁可多问一句，不要自己脑补。 - 不要输出超出任务范围的“建议性重构”，除非我明确询问优化空间。

这里有几个值得注意的设计点。第一，“先复述理解再动手”这条，能过滤掉大量因为需求理解偏差导致的无用功。代价是每轮任务多花一点 token，但相比返工成本，这远值得。第二，“不擅自修改无关文件”是针对 Claude 的一个典型毛病——它有时候会顺手帮你“优化”一下无关代码，这种隐性改动上线后很容易出问题。第三，用“你可执行命令”但“需要确认”的措辞，卡住了破坏性操作的默认权限，我用的是“必须先告知并等待确认”，而不是“禁止执行”，这样既安全又保留灵活度。

tool-use.md和security.md作为补充，负责更细粒度的控制。比如tool-use.md里我会写清楚：哪些命令可以直接运行，哪些必须列出命令内容让用户确认；测试任务中什么时候允许自动跑测试，什么时候只允许生成命令不执行。security.md则明确：不输出密钥、不提交环境变量文件、涉及用户隐私数据的代码要脱敏。这些文件共同构成了 Claude 的“职业素养”。

3.2 项目级上下文：为什么技术栈和术语表要分开

project/tech-stack.md和project/glossary.md看起来都属于“项目背景”，但为什么要拆开？因为它们的变化频率不同、用途不同。

tech-stack.md描述的是技术生态，变更频率低，只在项目选型变化时需要更新。我一般是这么写的：

# 技术栈 - 语言：Python 3.11 - Web 框架：FastAPI（同步接口使用，异步任务使用 Celery + Redis） - ORM：SQLAlchemy 2.x + Alembic（禁止使用 Django ORM 风格） - 数据库：PostgreSQL 15，所有表名使用 snake_case，外键命名为 xxx_id - 缓存：Redis 7 - 测试：pytest + httpx（接口测试统一使用 AsyncClient） - 包管理：Poetry（不要直接修改 poetry.lock，如有依赖变更请使用 poetry add/remove）

这个文件的核心价值是帮 Claude 建立“技术选型的边界感”。没有这个文件，它很可能基于自己的偏好建议你引入新的框架，或者写出和你项目不匹配的代码风格。有了它，Claude 至少不会提出太离谱的方案。

glossary.md则是业务术语表，这个文件对业务项目的帮助常被低估。我曾经维护过一个电商项目，Claude 把“SKU”和“SPU”混用，把“优惠券”和“满减活动”的概念弄混，导致生成的业务逻辑完全不对。后来我建了一个术语表，把每个名词的精确含义和关联概念写清楚：

# 业务术语表 - SKU：最小库存单元，一个 SKU 对应一个具体的规格组合（颜色+尺寸），库存按 SKU 维度管理。 注意：SPU 是商品聚合层，SKU 是售卖层，两者不可混用。 - 满减活动：按订单金额满足条件进行减免，可叠加单品直降，但不可与优惠券同用。 - 预售订单：支付定金锁定库存，尾款支付后进入正常订单流程；定金在用户取消订单时不退。 （与“现货订单”的差异：现货订单取消时全额退款到原路）

术语表的价值在于，它把模型的经验盲区补上了。像 SKU 和 SPU 这类概念，模型见过很多电商项目，但每个项目的定义可能存在细微差异。你明确写清楚，它就不会按自己的常识来理解你的业务，这一点对减少“看起来对但实际错”的代码尤其重要。

3.3 任务级模板：new-feature.md 的分步指令

任务级模板是 Claude Code 实际干活时的“操作手册”。以新功能开发为例，我会把它拆成阶段式指令：

# 新功能开发模板 ## 阶段 1：需求澄清 在动手之前，基于需求描述，输出你理解的： - 功能目标与用户价值 - 涉及的数据模型变更（如果有） - 涉及的接口变更（新增/修改/删除） - 边界条件与异常情况 不要在信息不足时自行脑补，请列出你觉得有歧义的问题让我确认。 ## 阶段 2：方案设计 基于确认后的需求，先给实现方案： - 新增/修改哪些文件（按项目架构规范，controller 层 / service 层 / model 层 分离） - 数据表变更和迁移思路 - 接口定义（路径、方法、参数、返回结构，遵循 REST 规范，错误码使用 4xx/5xx 分类） - 测试方案覆盖点 ## 阶段 3：代码实现 按方案逐文件实现，每个文件完成后说明该文件的关键实现点。 代码要求： - 函数拆分合理，单一职责 - 变量命名遵循项目规范 - 关键逻辑必须加注释，说明“为什么”，而不是“是什么” - 不使用未定义的非标准库依赖 ## 阶段 4：自测清单 代码写完后，按以下清单自检： - 是否跑过 lint（使用项目配置的 ruff） - 是否覆盖了正常路径和至少 2 个异常路径的测试 - 是否检查过潜在的性能问题（如 N+1 查询） - 是否对输入做了必要的参数校验

为什么要把新功能开发拆成 4 个阶段？因为 Claude Code 在没有阶段约束时，倾向于“一步到位”地输出所有代码。问题是，如果需求本身有偏差，你会在错误的方向上拿到一大坨代码，改起来非常痛苦。阶段化之后，每个阶段都是一个小交付，偏差可以早期被发现。实际操作中，我会让 Claude 先进入阶段 1 和 2，等我看完确认后，再让它进入阶段 3 和 4。这样可以避免“方向错了还在拼命赶路”的局面。

bugfix.md模板与new-feature.md的逻辑不同，它更强调复现路径和根因排查。我会让 Claude 先根据错误信息判断可能根因，列出猜测清单和验证方法；再让它在修复前输出最小复现用例；最后修复后跑一整套回归测试。重构模板则会更严格地约束“行为不变”原则：任何重构输出，都必须说明“输出行为是否发生变化”，如果变化了，哪里变了。Code Review 模板我单独放一节讲，因为它是模板里最能“立竿见影”的一类。

3.4 把模板注入 Claude Code 的两种方式

模板文件写好了，怎么让 Claude Code 用上？我试过两种方式，各有优劣。

方式一：在 boilerplate 目录下放置 CLAUDE.md

Claude Code 的一个实用性功能是自动加载项目根目录下的CLAUDE.md文件作为全局指令。我在项目根目录放一个精简版的CLAUDE.md，里面通过引用或摘录的方式把模板核心内容带进去。比如：

# CLAUDE.md 你是本项目的资深开发工程师。开始任何任务前，请先阅读 `claude-code-templates/` 目录下的 模板文件，按对应任务的模板流程执行。 基础行为规范见 claude-code-templates/system/base.md 项目技术栈见 claude-code-templates/project/tech-stack.md 编写新功能参考 claude-code-templates/tasks/new-feature.md

这种方式的好处是自动化程度高——每次启动 Claude Code 它都会自动读入CLAUDE.md，不用手动粘贴。缺点是它不能自动递归加载子文件里的内容，更多时候是作为一种“路由入口”，告诉 Claude 有哪些模板可参考，具体内容可能要等 Claude 需要时再读文件。实测下来 Claude 会主动去读被引用的文件，这一点很有用。

方式二：会话开始时手动拼接指令

如果你用 API 方式调 Claude，或者想在交互时灵活控制模板加载，你可以自己拼接 system prompt。我是这么组织的：

# 系统指令 [加载 system/base.md 内容] [加载 project/tech-stack.md 内容] [加载 project/code-style.md 内容] # 任务指令 [按当前任务类型加载 tasks/ 下对应模板内容]

每次会话要拼接哪些文件，可以在模板头部加一行元信息来声明，比如：

--- dependencies: system/base.md, project/tech-stack.md, project/glossary.md ---

这样维护起来也方便——改了一个模板文件，所有依赖它的模板的声明都自动生效。我实际用的是方式二为主，因为我可以按场景精确控制加载内容，不浪费上下文。方式一适合本地开发快速起步，两个可以组合用：CLAUDE.md负责兜底，手动拼接负责精细控制。

4. 模板实战演示：从初始化到 Code Review 的完整流程

4.1 新项目初始化实战

这个场景最适合展示模板的威力。我创建一个新项目时，会在claude-code-templates/下先写好项目级上下文文件，然后让 Claude Code 基于模板初始化项目骨架。给它的指令是我封装的初始化模板：

基于项目初始化模板执行以下任务： 项目名称：order-service 技术栈：Python 3.11 + FastAPI + PostgreSQL 功能概述：订单创建、订单查询、状态流转 请按 tech-stack.md 中声明的技术栈与架构规范，完成： 1. 初始化项目目录结构和基础配置（pyproject.toml、.env.example、docker-compose.yml 等） 2. 搭建 FastAPI 应用入口，配置健康检查接口 /healthz 3. 按 architecture.md 中分层约定创建 controller / service / model / schema 目录 4. 初始化 SQLAlchemy 模型基类和 Alembic 迁移环境 5. 提供一个示例订单模型，包含状态枚举字段 要求： - 所有配置项必须显式声明，不允许使用魔法数字 - 环境变量统一管理，敏感配置只放入 .env.example 的占位符 - 每个文件生成后，简要说明该文件在整体架构中的位置

这段指令词的关键在于“先明确技术约束，再给任务范围”。我还把“环境变量只放入占位符”作为负面约束写进去，防止 Claude 真的生成带有真实密钥的文件。实测下来，Claude Code 能在一次会话里完成大部分初始化工作，目录结构、依赖声明、基础代码都符合预期。

4.2 已有项目接入模板的场景

如果你手头已经有一个成熟项目，想补一套模板，步骤略有不同。我的建议是这样推进：

首先，花一点时间盘点项目，把强制约束写入模板：代码风格、接口规范、目录结构规则、不可使用的依赖。然后，把最容易出错的“业务术语”整理成 glossary，这部分我建议和项目里的老成员一起过一遍，宁可多花半小时，也不要让 AI 用错误的概念写代码。最后，先挑一个低风险、高频的小任务试跑（比如写一个工具函数、补一份接口文档），验证模板效果再逐步扩大使用范围。一个常见的误区是“模板越大越好”，其实模板不是越多越好，而是越准越好。如果一个模板从来没被任务加载过，它就是死重，不如删掉。

4.3 Code Review 模板的实战价值

code-review.md模板是我觉得性价比最高的一类。它不像代码生成那样依赖上下文理解能力，更像是给 Claude 设定一个明确的“检查清单”，输出稳定性非常高。我的模板是这样组织的：

# Code Review 模板 请作为资深 reviewer，按以下维度审查传入的 diff/代码： 1. 功能正确性：是否存在逻辑错误、边界未覆盖、并发问题？ - 重点关注：空值处理、类型假设、数值溢出、时间处理、状态机流转合法性 2. 安全风险：是否存在注入、敏感信息泄露、越权访问、不安全的反序列化？ 3. 性能隐患：是否存在 N+1 查询、循环内 IO、不必要的全表扫描、可预见的缓存穿透？ 4. 代码风格一致性：是否遵循 code-style.md 中的命名、缩进、注释、函数长度约定？ 5. 可测试性：新逻辑是否容易被测试覆盖？如果测试困难，请指出设计上的卡点。 输出格式： - 按严重程度从高到低列出问题：P0（必须修）、P1（建议修）、P2（可选优化） - 每个问题给出：文件位置、问题描述、修改建议、示例代码 - 最后给一个总体结论：可以直接合入 / 小幅修改后合入 / 需要大幅修改

使用这个模板后，我发现 Code Review 的覆盖面显著变宽。以前靠人肉 review 很容易漏掉的边界条件，比如“订单状态流转到已完成之后用户再次点击确认支付”这种场景，Claude 都能按模板主动检查到。而且它的输出格式统一，review 结果直接可以贴在评论里给团队看。

这类模板还有一个隐藏用处：可以用它反向训练团队的代码标准。新人看完 Claude 的 review 输出，相当于免费上了一堂代码规范课，知道哪些问题属于 P0、哪些属于 P2。这个边际收益一开始我没预计到，后来团队内部反馈时大家普遍认可。

4.4 实际会话中的组合加载示例

在实际的 Claude Code 会话里，我一般不会同时加载所有模板。一个典型的 order-service 开发会话，我加载的内容是这样组合的：

基础：system/base.md + system/security.md 项目：project/tech-stack.md + project/glossary.md 任务：tasks/bugfix.md（因为本次任务是修复线上 bug）

这样组合下来，上下文大约 1500~2500 token，加上原始代码上下文，总 token 消耗在可控范围内。我见过一些团队把十几个模板全部塞进CLAUDE.md，结果每个会话光读模板就要花掉不少上下文，真正留给代码推理的空间反而被挤占。模板的意义是“按需投喂”，不是“全量灌入”。

5. 模板运行中的高频问题与排查经验

5.1 模板没生效：Claude 不按模板执行怎么办

这是最常见的翻车场景。你明明写了“先确认再动手”，它还是直接开写。我排查这个问题的经验顺序是：

• 第一，检查模板是否被实际加载了。用方式一（CLAUDE.md）时，如果项目根目录有多个CLAUDE.md位置，或者子目录中存在同名文件覆盖，模板可能根本没进入上下文。可以在会话里直接问 Claude：“你当前的系统指令包含哪些内容”，看它能不能复述出模板要点。复述不出来，说明加载就有问题。
• 第二，检查措辞是否太“软”。模板里写“你尽量”“你应该”这类词，模型会当成参考建议而非强制约束。我把措辞改为“你必须”“禁止”“在不经用户确认的前提下不允许”，后发现行为约束力明显上升。
• 第三，检查模板是否和用户指令冲突。用户临时说“直接改吧，不用确认”，有时会覆盖模板约束。这种冲突要在模板里预先声明优先级：“除非用户明确解除某条限制，否则默认遵守模板规则”，能减少不少随机性。

这里必须诚实地说一句：模板约束不是 100% 可靠的安全机制。Claude 偶尔还是会违反行为红线，尤其是长任务进行到中段时，上下文里的约束信号会被稀释。所以关键操作流程上，我的习惯是让它在执行前汇报将要执行的命令，从流程上兜底，而不只依赖模板约束它自觉。

5.2 上下文过长导致既有约束被“遗忘”

长会话（超过 10 轮）时，模型对模板早期内容的遵从度会下降，这不是你的错觉，而是注意力被后续大量代码内容抢占。处理方案有几个：

• 在关键节点让 Claude 输出“当前任务简报”，把它拉回到任务主线。简报中要包含模板里的核心要求，相当于一次“约束刷新”。
• 把最关键的约束在CLAUDE.md和任务模板里重复声明，双保险。比如 code-style 要求可以在 project 层写一次，在 task 层写一次，重复不会浪费太多 token，但对行为约束的影响很值。
• 一个会话的任务数控制好，如果任务已经面目全非或轮次太多，直接开新会话，重新用模板加载要改动的文件，干净利落。

我实际使用中还有一个习惯：上下文接近红线时，会主动让 Claude 把核心业务文件内容写到临时文件里，新会话里引用。这样既避开上下文限制，又保留了修改基础。

5.3 模板输出“过于模板化”的问题

用了模板之后，偶尔会发现 Claude 输出的东西有一种“模板味”，体现在：开头永远是一段格式化的“我理解了需求，我的计划是……”，结尾永远是“如果有问题请随时反馈”，连注释风格都模式化。这个问题更像是矫枉过正——模板把它的行为约束得太死，牺牲了灵活度。

我的缓解办法是在模板里鼓励多样性。比如在 new-feature 模板的阶段 3 里，加上一句“实现允许创新，只要符合项目规范，不必严格采用示例代码的风格”。同时，示例部分我放两个风格不同的 good examples，避免 Claude 只模仿单一模式。如果你发现模板输出千篇一律，先看看是否 only 给了一个示例，加一两个风格差异大的例子效果会好很多。

5.4 模板维护与版本管理

模板不是一次性建设，需要持续迭代。我自己的维护策略是：每次 Claude Code 出错，解决后的经验要回填到模板里。比如某次它错误地修改了pyproject.toml里我手动维护的依赖分组，我就把这个负面案例写进security.md：“禁止修改 pyproject.toml 中非本次任务直接相关的依赖声明，如需调整请先征得同意。”

模板的版本管理我用 Git 单独管理，每个模板文件有自己的提交历史。换项目时，我可以 checkout 一份新的模板目录，快速定制。还有个实用技巧：在模板文件头部加version字段，会话里让 Claude 在关键输出汇报模板版本，这样能快速判断某次行为异常是否和模板版本变化相关。

5.5 高频问题速查表

第二条“规则偶尔被违反”，我再多说一句。不要因为出现过一两次违反就完全否定模板的价值，它在大多数时间里把行为维持在了正确的轨道上。模板做的不是“绝对控制”，而是“显著提高大多数情况的成功率”。就像代码里的类型检查能减少出错，但任何检查都有漏网之鱼，安全性设计不能只靠一层。

6. 进阶玩法：模板与团队协作、CI 的联动

模板沉淀一段时间后，你会发现它的价值已经不只是“给 Claude 用的说明书”，而是团队知识库的一种结构化载体。这个阶段，可以做几件很实用的扩展。

第一件事，把模板接入团队的 CI 检查。当业务代码更新时，可以用 Claude Code 读取tasks/code-review.md模板，自动对 MR 代码做一次预审查，把 P0/P1 问题标在 MR 评论里。实现方式不复杂：CI 里跑一个脚本，把 diff 和模板作为输入传给 Claude，输出结构化 review 结果。这样开发者在合入前就能拿到 AI 的初审意见，人来 review 时更聚焦。

第二件事，用模板体系做新人培训。新成员入职时，把模板仓库作为第一份必读材料，等于把团队多年积累的“隐性规范”一次性交付。比看代码更快，比听讲座更接近实战。我之前带过一个新人，看模板结构比看三个月代码更能快速理解团队的技术选型逻辑。

第三件事，模板的场景化细分。同一个 code-review 模板，可以拆出安全专项、性能专项、前端专项等子模板，根据 MR 变更文件类型自动选择。这块属于锦上添花，等基础模板稳定后再做也不迟。

最后分享一个我在实际使用中的体会：模板不是一个“写出来就完事”的交付物，它需要和你的使用习惯共同演进。最初版本的模板一定不完美，但只要你保留了“每次出问题就回填经验”的习惯，三个月后回头比较，你会有明显的感觉——Claude Code 的输错率在降，输出质量在涨，而你个人的重复劳动也在明显变少。这就是模板体系的复利效应，越用越顺手，越沉淀越值钱。