1. 先搞清楚Claude Code模板解决的是什么问题这段时间我把 claude-code 当作日常开发的主力帮手来用越用越发现一个道理真正让 AI 产出稳定质量的不是你问得多巧妙而是你有没有一套固定的 templates。说白了模板就是你提前把项目规范、代码风格、审查标准、输出格式这些东西用一套可复用的提示词结构固化下来让每次和 AI 的会话都站在同一个起跑线上。它不是什么玄学就是一份写给 AI 看的入职手册。新人进组要看规章制度AI 进入你的代码库也一样。没有这份手册它每次都是自由发挥而自由发挥的结果就是时好时坏、时详细时敷衍、时而直接改文件时而又只给你一段代码让你自己粘贴。如果你也遇到过这些问题这篇文章就是为你准备的不管你是刚上手 claude-code 的新人还是已经在项目里深度使用它的老手看完之后都能自己动手写出一套顺手的模板。1.1 没有模板时为什么每次都像开盲盒先复盘一个真实的场景。你让 claude-code 给用户模块加一个导出功能没有模板的情况下它的表现通常是这样第一次它很兴奋地给你写了一大段完整代码附带洋洋洒洒的说明改了三个文件第二次同样的问题它只给你核心函数告诉你其余部分自行脑补第三次它甚至直接拒绝了说这个功能涉及数据权限我不能贸然改动。为什么会这样因为 AI 每句话都在做续写这件事。它对你项目背景的理解完全依赖当前会话里你能提供多少上下文。你这次没说数据库表结构它就猜一个你这次没提错误处理规范它就用自己的默认套路。更麻烦的是claude-code 这种终端工具是会真实读写文件的它一旦猜错改出来的代码可能比不改还糟糕。还有上下文窗口的问题。聊到第 20 轮的时候它可能已经忘了你最开始说的不要动 migrations 目录这个要求。你说继续它继续了但是按它自己理解的继续在继续。模板存在的价值恰恰就是把最关键的约束从对话里抽离出来变成每轮都稳定生效的上下文常量而不是靠你一遍遍重复。1.2 模板的构成它到底在约束什么很多人以为模板就是一段长长的提示词其实不对。一个合格的模板至少包含五层内容角色定义、任务描述、约束条件、输出格式、验收标准。这五层各有各的用途。角色定义解决你是谁的问题。让 AI 知道自己是资深 Python 后端工程师还是熟悉 NestJS 的架构师它的用词、关注点会完全不同。任务描述解决干什么的问题这块要写得像一份清晰的工作简报。约束条件是模板的核心相当于项目的红线比如禁止修改哪些文件、必须遵守哪些命名规范、依赖版本锁定在什么范围。输出格式则决定了 AI 返回结果的样子是要表格、代码块还是纯文本的改动清单。验收标准更关键它告诉 AI 什么时候算干完了很多情况下 AI 交出来的东西你觉得不行不是它不会做而是你压根没告诉它什么样的结果才算合格。这五层内容在 claude-code 里通常放在项目根目录的CLAUDE.md文件里它会被自动加载进每次会话。也可以按任务拆成多个独立模板文件在需要的时候通过自定义命令调出来。记住一个原则模板不是靠华丽的词藻说服 AI而是靠清晰的结构减少 AI 的猜测空间。2. 哪几类模板最值得先写说了那么多理论落到实际究竟哪些模板的性价比最高我自己的经验是先写四个。代码生成模板、重构模板、调试排查模板、代码审查与提交信息模板。这四个覆盖了日常开发 80% 以上的 AI 协作场景而且每个都能在写完之后立刻看到效果。2.1 代码生成模板解决看起来对但不一定能跑的问题代码生成是 claude-code 最基础的能力但也是翻车率最高的场景。问题不在 AI 不懂写代码而在于它默认按最一般的情况来写不考虑你项目的实际情况。一份好的代码生成模板要把这些实际情况全部钉死。我给自己的项目写的模板长这样你是一个熟悉 Python 3.12 和 FastAPI 的后端工程师代码风格遵循项目现有代码。 任务根据下面的需求描述完成代码实现。 约束条件 1. 只允许修改 src/app 目录下的文件禁止改动 migrations、tests/fixtures、配置文件。 2. 使用项目已有的数据库会话管理方式见 src/app/db.py不得自行创建新的连接池。 3. 所有新增函数必须包含类型注解和 docstringdocstring 要写明参数含义和返回值。 4. 错误处理统一使用 src/app/errors.py 中定义的异常类型。 5. 依赖新增必须显式标明并在完成后列出需要 pip install 的包名和版本。 输出格式 1. 先给出 200 字以内的实现思路说明。 2. 再用代码块列出新增或修改后的完整文件内容。 3. 最后用表格列出需要更新的测试用例。 验收标准 - 代码能通过项目现有的 ruff 检查。 - 所有新功能都有对应的单元测试。 - 不改变既有接口的对外行为。你发现了吗这个模板几乎没有请帮我这样的礼貌用语全部是规则。它告诉 AI 的不只是写什么更是在哪里写、按什么风格写、写完怎么证明。实测下来加上这个模板之后AI 生成的代码基本能做到开箱即用偶尔有遗漏也是在小细节上不会出现改了不该改的文件这种灾难性事故。2.2 重构模板让改动范围和风险敞口透明化重构比新写代码更危险因为它的核心是行为不变。AI 很容易在重构过程中顺手优化掉一些看似多余实则关键的逻辑。对付这种情况模板里必须强调一件事先列计划再动手。我的重构模板会明确要求 AI 分四步走你是项目的老开发非常熟悉当前代码库的历史演进。 任务重构 {模块名}目标是把业务逻辑和基础设施解耦。 流程要求 1. 第一步先梳理该模块当前的所有调用方列出影响面清单包括被谁调用、调用方式是什么。 2. 第二步给出重构方案用 400 字以内说明重点说明每个步骤如何保持对外行为不变。 3. 第三步在得到我的确认后才开始修改代码。 4. 第四步每完成一步重构运行一次项目测试并把测试结果作为进度汇报的一部分。 红线 - 禁止顺手修改与本次重构无关的代码。 - 禁止移除任何在代码库中仍被引用的函数或变量即使你认为它没用。 - 如果发现某处逻辑无法在不改变行为的前提下重构停下来向我说明原因而不是强行改写。这个模板之所以有效是因为它把重构从一道问答题变成了一套流程。AI 不再被要求一次性交出结果而是被要求先展示计划和风险点。我遇到过很多次这样的情况AI 在第一步就发现某个模块有六个外部调用方远超我最初的估计。如果没有这个流程它可能就直接开干了改完之后六个调用方崩了五个。2.3 调试排查模板把猜变成查调试是 AI 最容易自信地胡说的领域。你贴上一段报错它就开始猜可能是这个问题、可能是那个问题、你试试这样改、你再试试那样改。这种盲猜式的调试运气好能蒙对运气不好就是浪费时间。调试模板要做的就是禁止 AI 猜测强制它按可验证的方式排查你是经验丰富的系统调试专家。在给出任何结论之前必须先完成信息收集。 排查流程 1. 列出你需要的所有信息完整报错堆栈、相关代码片段、运行时环境版本、最近变更记录。信息缺失时明确提问而不是假设。 2. 基于已有信息给出至少 2 个可能的假设并为每个假设说明如果这个假设成立那么什么现象应该被观察到。 3. 针对每种假设提出具体的验证方法查看日志、打印中间变量、编写最小复现脚本。 4. 只有验证结果支持某个假设时才给出修复方案。 5. 修复完成后要求 AI 解释这个 bug 为什么会导致原来的现象确保它真的理解了问题本质。 禁止事项 - 禁止直接输出可能是 xxx 问题而不给出验证依据。 - 禁止在未确认根因的情况下给出代码修改。 - 禁止把试试把版本升级一下作为唯一的解决方案。这个模板用起来最明显的感受是AI 开始像一个正常的工程师在跟你对齐信息而不是一个算命先生。有一次排查一个偶发超时问题它按模板先问了这个现象是随机出现还是特定接口才出现最近有没有部署过新版本这两个问题直接帮我定位到了问题方向整个排查时间缩短了一半。2.4 代码审查与提交信息模板代码审查模板的价值在于统一输出。每个人痛点不同有的希望 AI 重点看 bug有的希望它重点看性能。你可以在模板里定制自己的关注维度。我常用的审查模板长这样你将以下面的标准审查我提交的代码 diff。 审查维度按优先级排列 1. 正确性逻辑是否错误、边界条件是否处理、并发安全是否有隐患。 2. 安全性是否有注入风险、敏感信息是否泄漏、权限校验是否完整。 3. 可维护性命名是否清晰、函数是否过长、重复代码是否明显。 4. 性能是否存在明显的低效查询、N1 问题、不必要的大对象复制。 输出格式 - 每个问题用表格行展示严重级别阻断/建议/疑问、问题位置、问题描述、修改建议。 - 全部问题列出后用 3 句话总结这次代码的整体质量。提交信息模板就简单多了它更像一个格式约束器。我会要求 AI 按type(scope): subject的格式生成提交信息并附上变更原因。这种模板特别适合团队协作因为每个人 AI 生成的提交信息风格都保持一致看 git log 的时候不用再费劲切换脑回路。3. 手写一套模板的全过程光看别人的模板如果不自己动手还是体会不到其中的门道。下面我就拿一个真实场景完整走一遍从零写模板的流程。这个场景是我要让 claude-code 帮我维护一个内部工具库的 API 文档。3.1 第一步先定义输入输出而不是先写提示词大多数人的错误是上来就写请你帮我写文档然后一顿猛输出结果 AI 给的文档根本不是你想要的。正确的顺序是先想清楚三个问题这个模板接收什么输入输出什么产物用什么标准衡量产物合格以生成 API 文档这个任务为例。输入是某个 Python 模块的路径、函数签名、现有 docstring。输出是一份 Markdown 格式的 API 参考文档包含函数列表、参数说明、返回值说明、使用示例。衡量标准是每个公开函数都被覆盖到参数说明和签名一致示例代码可以直接复制运行。想清楚之后模板的任务描述部分自然而然就有了方向。它不再是笼统的生成文档而是精确的从指定模块提取全部公开函数按项目统一的文档格式输出。这个步骤看似简单实际上决定了整个模板的质量上限。输入输出都不清楚后面写的约束条件就是无根之萍。3.2 第二步约束条件要可验证不要可感受写约束条件最容易犯的毛病就是写一堆听起来正确但实际上 AI 无法自我检查的话。比如代码要高质量、文档要清晰易读、保持代码整洁。这些话都对但 AI 没办法拿着尺子量一下到底算不算高质量。可验证的约束长什么样以文档任务为例我写了这么几条只提取src/mylib/下的公开函数不以_开头的函数。每个函数必须包含三层说明功能描述、参数表参数名/类型/是否必填/含义、返回值说明。使用示例必须调用真实的函数签名伪造的函数名和参数会导致示例直接判负。如果函数没有 docstring根据代码逻辑补充并在文档中用根据代码推断标注。你看不以_开头就是一个函数能否被纳入文档的明确判据。AI 在代码里扫一圈符合条件的就写进去不符合的就不写不存在灰色地带。而必须包含三层说明则规定了文档的结构AI 交出来的东西可以逐项核对。写约束的时候你可以在心里模拟一遍如果我是 AI我能不能准确判断自己有没有违反这条如果不能就说明这条约束需要改写得更加具象。3.3 第三步给一到两个 few-shot 范例文字描述再多也不如一个现成的例子来得直观。在模板末尾附上一小段示例输出能让 AI 的输出风格和你的预期迅速对齐。这一步很关键因为 claude-code 的续写特性会强力地模仿你给出的示例格式。给文档模板配的示例大概是这样的示例输出片段 ### calculate_discount(price: float, percent: float, *, rounding: bool True) - float 计算折扣后的价格。 参数 - price (float)原始价格必须大于 0。 - percent (float)折扣百分比取值范围 0 到 100。 - rounding (bool, 可选)是否对结果四舍五入默认 True。 返回值折扣后的价格float。如果 percent 为 0返回原始价格。 示例 python from mylib import calculate_discount calculate_discount(100.0, 20.0) # 80.0这个示例的价值在于它一次性地展示了层级结构、参数描述的格式、返回值说明的方式以及示例代码的写法。AI 看到这个基本就能猜到哦原来你要的是这种风格的文档。这段示例我大概只花了五分钟写却省下了我跟 AI 来回纠正格式的大把时间。 ### 3.4 第四步测试、迭代、版本化 新模板写完不要直接投入到正式任务里先在项目里挑一个小模块试运行一遍。我通常会对比三个东西产出结果的格式是否和示例一致、覆盖范围是否符合预期、有没有出现模板没考虑到的新情况。 第一次测试AI 把 docstring 里原有的 deprecated 标注删掉了。第二次测试它在参数表里手动加了一列默认值而我的示例里没有这列。这些偏差都需要在模板里补充说明要么加一条保留原有的 deprecated 标注要么加一条参数表不允许新增示例之外的列。 这里有一个实践细节把模板文件纳入 git 管理每次修改都提交一次写清楚变更原因。比如 docs: 补充默认值列说明防止AI擅自新增格式。时间长了你的模板本身就是一份项目文档你能看到它的演进历史。而且在 claude-code 的会话里你也可以直接 /git log 查看模板的修改记录方便回退到某个稳定版本。 ## 4. 模板用起来之后的常见坑 模板不是写出来就万事大吉了用的过程中坑还挺多的。我把这段时间踩过的、帮别人排查过的问题集中整理一下基本上每一条都能在模板落地的头两周遇到。 ### 4.1 模板太长效果反而变差 很多人觉得模板越长越详细越好这是一个误区。我见过有人把 CLAUDE.md 写成 2000 行的百科全书结果 AI 的行为反而变得畏手畏脚什么都不敢做。原因是上下文的注意力分布是有限的。当模板里塞了太多规则之后模型会过拟合到某几条词频最高或位置靠前的规则上其他的要么忽略、要么在几个约束之间犹豫不决。 我的经验是全局模板每个会话都加载的控制在 100 行以内集中写项目最核心的红线和风格规范。任务级的专用模板控制在 50 到 80 行一次专注解决一件事。如果你有很多任务模板不要全部堆进 CLAUDE.md而是用斜杠命令的方式让它们在需要的时候被调用。比如我定义的 /refactor 命里只包含重构模板的内容平时不加载只有输入这个命令才触发。 ### 4.2 约束条件互相打架 另一类高频问题是约束自相矛盾。最典型的就是同时要求代码简洁和所有函数都要有详细注释这两个目标在 AI 眼里是冲突的。它可能为了简洁砍掉注释也可能为了注释凑出一堆废话。类似的对子还有不要修改无关代码和顺手修复你发现的小问题。 解决方式是给约束定优先级。我会在模板里直接写如果遇到冲突按以下顺序执行安全性 正确性 可维护性 性能 代码精简。这样 AI 在遇到左右为难的情况时有一个明确的决策依据。你甚至可以故意在模板里放一条本模板的约束以优先级顺序为准后出现的约束不得覆盖先出现的约束给 AI 一个处理矛盾的原则。 ### 4.3 工具调用和权限范围 claude-code 是能执行命令、读写文件的这意味着模板约束的不只是说什么话还包括能碰哪些地方。我在这上面吃过亏模板里只写了不要改 migrations 目录结果 AI 把项目里的一个小工具脚本删了它认为那是无关的临时文件。 现在的做法是模板里明确一个允许操作区和禁止操作区清单。允许区写清具体路径禁止区也要写清具体路径并且在模板开头就声明一条铁律对允许区之外的任何文件系统变更都必须提前征求确认等待用户批准后才能继续。此外涉及执行 git 命令、pip install 这种有副作用的操作我都会在模板里要求 AI 先说明将执行什么命令、目的是什么、可能的影响是什么。这套机制加进去之后误操作的概率低了很多。 ### 4.4 模板需要持续维护不是一劳永逸 模板有效期这事容易被忽略。项目换了数据库、升级了框架、调整了目录结构模板里的约束条件分分钟过期。最典型的例子是我有个模板要求新增代码使用项目原有的 logger后来项目迁移到了新的日志方案旧 logger 已经废弃但模板里没更新AI 按旧规范生成了一堆即将被淘汰的代码。 所以每隔一段时间我是每个迭代周期结束的时候把模板过一遍问几个问题里面提到的目录结构还存在吗引用的工具链还是当前版本吗示例代码还能跑通吗这个维护动作花不了十分钟但能避免模板从助力变成阻力。另外一个值得养成的习惯是当你发现 AI 反复在某类约束上犯错时不要每次都手动纠正而是把它写进模板让模板跟着实际问题一起进化。 写到这里我想强调一点模板最核心的价值不是约束 AI而是逼着你自己把需求想清楚。很多时候你写不出好模板不是不懂提示词技巧而是根本没想明白自己要什么。我在给 claude-code 写模板的过程中对自己项目的理解反而加深了不少。如果你手头还没任何模板今晚就可以挑一个折腾你最久的场景按这篇文章的五个构成要素写一版遇到问题再回来对照常见的坑慢慢你就会有自己的一套体系。
1. 先搞清楚Claude Code模板解决的是什么问题这段时间我把 claude-code 当作日常开发的主力帮手来用越用越发现一个道理真正让 AI 产出稳定质量的不是你问得多巧妙而是你有没有一套固定的 templates。说白了模板就是你提前把项目规范、代码风格、审查标准、输出格式这些东西用一套可复用的提示词结构固化下来让每次和 AI 的会话都站在同一个起跑线上。它不是什么玄学就是一份写给 AI 看的入职手册。新人进组要看规章制度AI 进入你的代码库也一样。没有这份手册它每次都是自由发挥而自由发挥的结果就是时好时坏、时详细时敷衍、时而直接改文件时而又只给你一段代码让你自己粘贴。如果你也遇到过这些问题这篇文章就是为你准备的不管你是刚上手 claude-code 的新人还是已经在项目里深度使用它的老手看完之后都能自己动手写出一套顺手的模板。1.1 没有模板时为什么每次都像开盲盒先复盘一个真实的场景。你让 claude-code 给用户模块加一个导出功能没有模板的情况下它的表现通常是这样第一次它很兴奋地给你写了一大段完整代码附带洋洋洒洒的说明改了三个文件第二次同样的问题它只给你核心函数告诉你其余部分自行脑补第三次它甚至直接拒绝了说这个功能涉及数据权限我不能贸然改动。为什么会这样因为 AI 每句话都在做续写这件事。它对你项目背景的理解完全依赖当前会话里你能提供多少上下文。你这次没说数据库表结构它就猜一个你这次没提错误处理规范它就用自己的默认套路。更麻烦的是claude-code 这种终端工具是会真实读写文件的它一旦猜错改出来的代码可能比不改还糟糕。还有上下文窗口的问题。聊到第 20 轮的时候它可能已经忘了你最开始说的不要动 migrations 目录这个要求。你说继续它继续了但是按它自己理解的继续在继续。模板存在的价值恰恰就是把最关键的约束从对话里抽离出来变成每轮都稳定生效的上下文常量而不是靠你一遍遍重复。1.2 模板的构成它到底在约束什么很多人以为模板就是一段长长的提示词其实不对。一个合格的模板至少包含五层内容角色定义、任务描述、约束条件、输出格式、验收标准。这五层各有各的用途。角色定义解决你是谁的问题。让 AI 知道自己是资深 Python 后端工程师还是熟悉 NestJS 的架构师它的用词、关注点会完全不同。任务描述解决干什么的问题这块要写得像一份清晰的工作简报。约束条件是模板的核心相当于项目的红线比如禁止修改哪些文件、必须遵守哪些命名规范、依赖版本锁定在什么范围。输出格式则决定了 AI 返回结果的样子是要表格、代码块还是纯文本的改动清单。验收标准更关键它告诉 AI 什么时候算干完了很多情况下 AI 交出来的东西你觉得不行不是它不会做而是你压根没告诉它什么样的结果才算合格。这五层内容在 claude-code 里通常放在项目根目录的CLAUDE.md文件里它会被自动加载进每次会话。也可以按任务拆成多个独立模板文件在需要的时候通过自定义命令调出来。记住一个原则模板不是靠华丽的词藻说服 AI而是靠清晰的结构减少 AI 的猜测空间。2. 哪几类模板最值得先写说了那么多理论落到实际究竟哪些模板的性价比最高我自己的经验是先写四个。代码生成模板、重构模板、调试排查模板、代码审查与提交信息模板。这四个覆盖了日常开发 80% 以上的 AI 协作场景而且每个都能在写完之后立刻看到效果。2.1 代码生成模板解决看起来对但不一定能跑的问题代码生成是 claude-code 最基础的能力但也是翻车率最高的场景。问题不在 AI 不懂写代码而在于它默认按最一般的情况来写不考虑你项目的实际情况。一份好的代码生成模板要把这些实际情况全部钉死。我给自己的项目写的模板长这样你是一个熟悉 Python 3.12 和 FastAPI 的后端工程师代码风格遵循项目现有代码。 任务根据下面的需求描述完成代码实现。 约束条件 1. 只允许修改 src/app 目录下的文件禁止改动 migrations、tests/fixtures、配置文件。 2. 使用项目已有的数据库会话管理方式见 src/app/db.py不得自行创建新的连接池。 3. 所有新增函数必须包含类型注解和 docstringdocstring 要写明参数含义和返回值。 4. 错误处理统一使用 src/app/errors.py 中定义的异常类型。 5. 依赖新增必须显式标明并在完成后列出需要 pip install 的包名和版本。 输出格式 1. 先给出 200 字以内的实现思路说明。 2. 再用代码块列出新增或修改后的完整文件内容。 3. 最后用表格列出需要更新的测试用例。 验收标准 - 代码能通过项目现有的 ruff 检查。 - 所有新功能都有对应的单元测试。 - 不改变既有接口的对外行为。你发现了吗这个模板几乎没有请帮我这样的礼貌用语全部是规则。它告诉 AI 的不只是写什么更是在哪里写、按什么风格写、写完怎么证明。实测下来加上这个模板之后AI 生成的代码基本能做到开箱即用偶尔有遗漏也是在小细节上不会出现改了不该改的文件这种灾难性事故。2.2 重构模板让改动范围和风险敞口透明化重构比新写代码更危险因为它的核心是行为不变。AI 很容易在重构过程中顺手优化掉一些看似多余实则关键的逻辑。对付这种情况模板里必须强调一件事先列计划再动手。我的重构模板会明确要求 AI 分四步走你是项目的老开发非常熟悉当前代码库的历史演进。 任务重构 {模块名}目标是把业务逻辑和基础设施解耦。 流程要求 1. 第一步先梳理该模块当前的所有调用方列出影响面清单包括被谁调用、调用方式是什么。 2. 第二步给出重构方案用 400 字以内说明重点说明每个步骤如何保持对外行为不变。 3. 第三步在得到我的确认后才开始修改代码。 4. 第四步每完成一步重构运行一次项目测试并把测试结果作为进度汇报的一部分。 红线 - 禁止顺手修改与本次重构无关的代码。 - 禁止移除任何在代码库中仍被引用的函数或变量即使你认为它没用。 - 如果发现某处逻辑无法在不改变行为的前提下重构停下来向我说明原因而不是强行改写。这个模板之所以有效是因为它把重构从一道问答题变成了一套流程。AI 不再被要求一次性交出结果而是被要求先展示计划和风险点。我遇到过很多次这样的情况AI 在第一步就发现某个模块有六个外部调用方远超我最初的估计。如果没有这个流程它可能就直接开干了改完之后六个调用方崩了五个。2.3 调试排查模板把猜变成查调试是 AI 最容易自信地胡说的领域。你贴上一段报错它就开始猜可能是这个问题、可能是那个问题、你试试这样改、你再试试那样改。这种盲猜式的调试运气好能蒙对运气不好就是浪费时间。调试模板要做的就是禁止 AI 猜测强制它按可验证的方式排查你是经验丰富的系统调试专家。在给出任何结论之前必须先完成信息收集。 排查流程 1. 列出你需要的所有信息完整报错堆栈、相关代码片段、运行时环境版本、最近变更记录。信息缺失时明确提问而不是假设。 2. 基于已有信息给出至少 2 个可能的假设并为每个假设说明如果这个假设成立那么什么现象应该被观察到。 3. 针对每种假设提出具体的验证方法查看日志、打印中间变量、编写最小复现脚本。 4. 只有验证结果支持某个假设时才给出修复方案。 5. 修复完成后要求 AI 解释这个 bug 为什么会导致原来的现象确保它真的理解了问题本质。 禁止事项 - 禁止直接输出可能是 xxx 问题而不给出验证依据。 - 禁止在未确认根因的情况下给出代码修改。 - 禁止把试试把版本升级一下作为唯一的解决方案。这个模板用起来最明显的感受是AI 开始像一个正常的工程师在跟你对齐信息而不是一个算命先生。有一次排查一个偶发超时问题它按模板先问了这个现象是随机出现还是特定接口才出现最近有没有部署过新版本这两个问题直接帮我定位到了问题方向整个排查时间缩短了一半。2.4 代码审查与提交信息模板代码审查模板的价值在于统一输出。每个人痛点不同有的希望 AI 重点看 bug有的希望它重点看性能。你可以在模板里定制自己的关注维度。我常用的审查模板长这样你将以下面的标准审查我提交的代码 diff。 审查维度按优先级排列 1. 正确性逻辑是否错误、边界条件是否处理、并发安全是否有隐患。 2. 安全性是否有注入风险、敏感信息是否泄漏、权限校验是否完整。 3. 可维护性命名是否清晰、函数是否过长、重复代码是否明显。 4. 性能是否存在明显的低效查询、N1 问题、不必要的大对象复制。 输出格式 - 每个问题用表格行展示严重级别阻断/建议/疑问、问题位置、问题描述、修改建议。 - 全部问题列出后用 3 句话总结这次代码的整体质量。提交信息模板就简单多了它更像一个格式约束器。我会要求 AI 按type(scope): subject的格式生成提交信息并附上变更原因。这种模板特别适合团队协作因为每个人 AI 生成的提交信息风格都保持一致看 git log 的时候不用再费劲切换脑回路。3. 手写一套模板的全过程光看别人的模板如果不自己动手还是体会不到其中的门道。下面我就拿一个真实场景完整走一遍从零写模板的流程。这个场景是我要让 claude-code 帮我维护一个内部工具库的 API 文档。3.1 第一步先定义输入输出而不是先写提示词大多数人的错误是上来就写请你帮我写文档然后一顿猛输出结果 AI 给的文档根本不是你想要的。正确的顺序是先想清楚三个问题这个模板接收什么输入输出什么产物用什么标准衡量产物合格以生成 API 文档这个任务为例。输入是某个 Python 模块的路径、函数签名、现有 docstring。输出是一份 Markdown 格式的 API 参考文档包含函数列表、参数说明、返回值说明、使用示例。衡量标准是每个公开函数都被覆盖到参数说明和签名一致示例代码可以直接复制运行。想清楚之后模板的任务描述部分自然而然就有了方向。它不再是笼统的生成文档而是精确的从指定模块提取全部公开函数按项目统一的文档格式输出。这个步骤看似简单实际上决定了整个模板的质量上限。输入输出都不清楚后面写的约束条件就是无根之萍。3.2 第二步约束条件要可验证不要可感受写约束条件最容易犯的毛病就是写一堆听起来正确但实际上 AI 无法自我检查的话。比如代码要高质量、文档要清晰易读、保持代码整洁。这些话都对但 AI 没办法拿着尺子量一下到底算不算高质量。可验证的约束长什么样以文档任务为例我写了这么几条只提取src/mylib/下的公开函数不以_开头的函数。每个函数必须包含三层说明功能描述、参数表参数名/类型/是否必填/含义、返回值说明。使用示例必须调用真实的函数签名伪造的函数名和参数会导致示例直接判负。如果函数没有 docstring根据代码逻辑补充并在文档中用根据代码推断标注。你看不以_开头就是一个函数能否被纳入文档的明确判据。AI 在代码里扫一圈符合条件的就写进去不符合的就不写不存在灰色地带。而必须包含三层说明则规定了文档的结构AI 交出来的东西可以逐项核对。写约束的时候你可以在心里模拟一遍如果我是 AI我能不能准确判断自己有没有违反这条如果不能就说明这条约束需要改写得更加具象。3.3 第三步给一到两个 few-shot 范例文字描述再多也不如一个现成的例子来得直观。在模板末尾附上一小段示例输出能让 AI 的输出风格和你的预期迅速对齐。这一步很关键因为 claude-code 的续写特性会强力地模仿你给出的示例格式。给文档模板配的示例大概是这样的示例输出片段 ### calculate_discount(price: float, percent: float, *, rounding: bool True) - float 计算折扣后的价格。 参数 - price (float)原始价格必须大于 0。 - percent (float)折扣百分比取值范围 0 到 100。 - rounding (bool, 可选)是否对结果四舍五入默认 True。 返回值折扣后的价格float。如果 percent 为 0返回原始价格。 示例 python from mylib import calculate_discount calculate_discount(100.0, 20.0) # 80.0这个示例的价值在于它一次性地展示了层级结构、参数描述的格式、返回值说明的方式以及示例代码的写法。AI 看到这个基本就能猜到哦原来你要的是这种风格的文档。这段示例我大概只花了五分钟写却省下了我跟 AI 来回纠正格式的大把时间。 ### 3.4 第四步测试、迭代、版本化 新模板写完不要直接投入到正式任务里先在项目里挑一个小模块试运行一遍。我通常会对比三个东西产出结果的格式是否和示例一致、覆盖范围是否符合预期、有没有出现模板没考虑到的新情况。 第一次测试AI 把 docstring 里原有的 deprecated 标注删掉了。第二次测试它在参数表里手动加了一列默认值而我的示例里没有这列。这些偏差都需要在模板里补充说明要么加一条保留原有的 deprecated 标注要么加一条参数表不允许新增示例之外的列。 这里有一个实践细节把模板文件纳入 git 管理每次修改都提交一次写清楚变更原因。比如 docs: 补充默认值列说明防止AI擅自新增格式。时间长了你的模板本身就是一份项目文档你能看到它的演进历史。而且在 claude-code 的会话里你也可以直接 /git log 查看模板的修改记录方便回退到某个稳定版本。 ## 4. 模板用起来之后的常见坑 模板不是写出来就万事大吉了用的过程中坑还挺多的。我把这段时间踩过的、帮别人排查过的问题集中整理一下基本上每一条都能在模板落地的头两周遇到。 ### 4.1 模板太长效果反而变差 很多人觉得模板越长越详细越好这是一个误区。我见过有人把 CLAUDE.md 写成 2000 行的百科全书结果 AI 的行为反而变得畏手畏脚什么都不敢做。原因是上下文的注意力分布是有限的。当模板里塞了太多规则之后模型会过拟合到某几条词频最高或位置靠前的规则上其他的要么忽略、要么在几个约束之间犹豫不决。 我的经验是全局模板每个会话都加载的控制在 100 行以内集中写项目最核心的红线和风格规范。任务级的专用模板控制在 50 到 80 行一次专注解决一件事。如果你有很多任务模板不要全部堆进 CLAUDE.md而是用斜杠命令的方式让它们在需要的时候被调用。比如我定义的 /refactor 命里只包含重构模板的内容平时不加载只有输入这个命令才触发。 ### 4.2 约束条件互相打架 另一类高频问题是约束自相矛盾。最典型的就是同时要求代码简洁和所有函数都要有详细注释这两个目标在 AI 眼里是冲突的。它可能为了简洁砍掉注释也可能为了注释凑出一堆废话。类似的对子还有不要修改无关代码和顺手修复你发现的小问题。 解决方式是给约束定优先级。我会在模板里直接写如果遇到冲突按以下顺序执行安全性 正确性 可维护性 性能 代码精简。这样 AI 在遇到左右为难的情况时有一个明确的决策依据。你甚至可以故意在模板里放一条本模板的约束以优先级顺序为准后出现的约束不得覆盖先出现的约束给 AI 一个处理矛盾的原则。 ### 4.3 工具调用和权限范围 claude-code 是能执行命令、读写文件的这意味着模板约束的不只是说什么话还包括能碰哪些地方。我在这上面吃过亏模板里只写了不要改 migrations 目录结果 AI 把项目里的一个小工具脚本删了它认为那是无关的临时文件。 现在的做法是模板里明确一个允许操作区和禁止操作区清单。允许区写清具体路径禁止区也要写清具体路径并且在模板开头就声明一条铁律对允许区之外的任何文件系统变更都必须提前征求确认等待用户批准后才能继续。此外涉及执行 git 命令、pip install 这种有副作用的操作我都会在模板里要求 AI 先说明将执行什么命令、目的是什么、可能的影响是什么。这套机制加进去之后误操作的概率低了很多。 ### 4.4 模板需要持续维护不是一劳永逸 模板有效期这事容易被忽略。项目换了数据库、升级了框架、调整了目录结构模板里的约束条件分分钟过期。最典型的例子是我有个模板要求新增代码使用项目原有的 logger后来项目迁移到了新的日志方案旧 logger 已经废弃但模板里没更新AI 按旧规范生成了一堆即将被淘汰的代码。 所以每隔一段时间我是每个迭代周期结束的时候把模板过一遍问几个问题里面提到的目录结构还存在吗引用的工具链还是当前版本吗示例代码还能跑通吗这个维护动作花不了十分钟但能避免模板从助力变成阻力。另外一个值得养成的习惯是当你发现 AI 反复在某类约束上犯错时不要每次都手动纠正而是把它写进模板让模板跟着实际问题一起进化。 写到这里我想强调一点模板最核心的价值不是约束 AI而是逼着你自己把需求想清楚。很多时候你写不出好模板不是不懂提示词技巧而是根本没想明白自己要什么。我在给 claude-code 写模板的过程中对自己项目的理解反而加深了不少。如果你手头还没任何模板今晚就可以挑一个折腾你最久的场景按这篇文章的五个构成要素写一版遇到问题再回来对照常见的坑慢慢你就会有自己的一套体系。
