Claude Code跑起来很容易真正跑得好很难。我见过太多团队装完工具的第一周都在“裸聊式”使用——一人一句自然语言丢过去生成的代码乍一看能跑等到改需求、补测试、做审查的时候输出质量就开始上下飘。这个问题的根源通常不在模型本身而在你喂给它的那几句话。于是就有了我想聊的 claude-code-templates它不是某个现成插件而是一套围绕 Claude Code 沉淀下来的提示模板工程方法把团队的编码规范、验收标准、常见任务流程从人脑子里搬到模型能稳定读取的文件里。这篇文章写给两类人一是刚接触 Claude Code、想避免“每次都要现场编 prompt”的开发者二是已经在团队里用 Claude Code、但对输出质量不稳定感到头疼的工程负责人。我会从模板为什么有效讲起再到文件怎么组织、典型场景怎么写最后给一套可以直接照搬的搭建流程和排查经验。1. 为什么需要一套可复用的模板体系1.1 一段真实翻车现场先还原一个场景。你在跑一个微服务项目想让 Claude Code 给某个模块补单元测试。你可能会说“帮我给 OrderService 写点单测。”于是模型开始自作主张Mock 风格一会儿 Mockito 一会儿 MockK测试类名和项目现有命名对不上断言路径跑到数据库层甚至把测试用例覆盖到了五层以外的 Controller。这不是模型笨是你的话太短。模型能推理但它对你的团队约定一无所知。它不知道你们统一用 JUnit 5 AssertJ不知道测试文件必须和被测类放同一个包路径不知道数据库操作要打 Integration 标签而不是在单元测试里连真实库。这些信息不喂进去输出稳定的概率就全靠运气。翻车的代价不只是重写代码。每一次重新生成你都要重新复述一遍背景浪费的是 token消耗的是对 AI 工具的信任。更麻烦的是如果团队里有五个人都在用 Claude Code五个人会编出五种风格的 prompt模型也会给出五种风格的代码。一个人踩过的坑其他人照踩。1.2 模板的本质把隐式经验显式化很多人把模板理解成“一段写好的 prompt复制粘贴用”这没错但格局小了。模板的真正价值是把隐式的团队经验变成显式的可执行文件。开发团队里最难传承的就是隐性知识老工程师知道这个模块历史包袱重不能随便动知道重构时优先保兼容性知道某个目录下的代码不允许直接 import 到 service 层。这些经验平时散落在代码注释、Code Review 留言、群里偶尔冒出来的语音里新人和 AI 都很难学到。模板体系可以承载其中的一部分你用文字把规则写清楚用参数把场景固定下来用模板正文把验收标准列成清单Claude 每次执行都会走一遍这套流程。打个比方老厨师做菜靠手感米其林厨房做菜靠标准食谱。食谱不会让厨师变得更有天赋但它保证每个学徒端出来的菜都稳定在及格线以上而稳定的及格线正是工程化交付的底线。Claude Code 的模板就是从“靠手感”到“标准食谱”的那一步。2. 模板体系的整体设计与文件组织2.1 三类存放位置各有分工搭建模板体系的第一步不是写模板而是决定模板放在哪。Claude Code 支持分层的配置目录按作用范围大致分三类全局个人级放在~/.claude/commands/适合那些和项目无关的通用任务比如语法转译、日志分析、代码解释。项目团队级放在项目根目录的.claude/commands/这是最常用的位置。团队约定、技术栈约束、部署流程都围绕项目展开模板天然应该跟着仓库走。用户自定义 Skill放在.claude/skills/或~/.claude/skills/下的独立目录中每个 Skill 是一个文件夹内部有SKILL.md描述文件。这个机制适合做更重一点的“知识包”把某个领域的方法论一次性灌给模型。我的建议是凡是和当前仓库结构、技术选型相关的模板一律放项目级.claude/commands/纯通用的东西才放用户级。因为项目级目录会随仓库一起提交新成员 clone 下来就直接拥有整套约定不用单独问他“你有那个模板吗”。还有一个容易踩的坑.claude/commands/目录名不要拼错。.claude是隐藏目录很多团队会把模板文件随手放在项目根目录的templates/文件夹然后发现斜杠命令怎么也加载不出来。Claude Code 默认扫描的是.claude/commands/文件名就是命令名review.md对应/reviewgen-test.md对应/gen-test。2.2 模板文件的标准骨架打开一个命令模板文件它通常长这样--- description: 对指定代码段做一轮结构化审查 argument: 要审查的文件路径或代码块 allowed-tools: Bash, Read --- ## 你的角色 资深代码审查者关注正确性、可维护性、安全与性能。 ## 上下文 你正在审查 $ARGUMENTS 对应的代码。 请先阅读该文件必要时查看相关引用文件。 ## 任务 1. 指出所有可能导致线上事故的缺陷 2. 指出违反项目规范的地方并引用规范原文 3. 给出修复建议每个建议标注优先级 ## 输出格式 - 问题清单按严重程度排序 - 每条问题包含文件位置 / 问题描述 / 修复建议 / 预估改动量 - 结尾输出“无阻塞项”或“存在阻塞项”这里有几个关键设计。第一用 YAML frontmatter 声明模板的元信息。description会在斜杠命令建议列表里展示argument说明这个命令需要用户提供什么参数allowed-tools限制模型能调用的工具避免它在只读任务里偷偷执行写操作。第二正文分段必须有结构。角色、上下文、任务、输出格式四段是我最常用的骨架。角色解决“什么立场看问题”上下文解决“基于什么信息表态”任务解决“具体干什么”输出格式解决“结果长什么样”。模型对结构化指令的理解能力远好于一段毫无章法的长文本。第三参数不要贪多。$ARGUMENTS是用户输入的核心参数也可以在文件里定义命名参数但参数越多用户每次用起来越累。最好的模板是只留一个必填参数剩下的靠模板自动读取仓库信息。2.3 CLAUDE.md模板体系的底座很多使用者忽略了一个更底层的东西CLAUDE.md。它的作用不是替代模板而是给所有模板提供公共背景知识。Claude Code 在启动时会自动加载当前项目根目录下的 CLAUDE.md里面的内容相当于给模型做了一次“入职培训”。在这个文件里我会放以下几类内容项目的技术栈与目录结构例如“后端是 Python FastAPI前端是 React TypeScript测试统一用 pytest”代码规范与约定例如“文件名用 snake_case接口注释必须写清楚入参出参”项目中必须遵守的边界例如“不要修改 migrations 目录”、“禁止把业务逻辑写在路由层”常用命令例如“构建命令是make build跑测试用make test”。有了 CLAUDE.md 之后模板文件就不需要再重复这些背景信息了。模板只描述任务流程公共知识由底座统一提供。这个分层设计非常重要否则你会陷入另一种麻烦模板越写越长每个模板里都复制一份技术栈说明改一次架构要同步改五个文件。我习惯把 CLAUDE.md 控制在 100 行以内只写那些“模型不知道就会做错”的硬约束不写空话。比如“保证代码质量”这种话没有执行意义“单元测试覆盖率不得低于 80%”才有执行意义。3. 核心场景模板的编写要点与示例3.1 代码审查模板的写法代码审查是模板收益最高的场景。人工审查时每个人关注点不同有人只挑命名有人只关心性能有人自己都没想清楚就凭感觉“LGTM”。把审查标准写成模板等于强制输出质量的下限。我的审查模板会有这么几层--- description: 结构化审查指定代码 argument: 待审查的文件路径 --- 请从以下四个维度审查 $ARGUMENTS 1. 正确性是否存在空指针、并发竞态、越界访问、未处理异常等隐患。 2. 安全性是否对不可信输入做了校验是否存在注入风险、敏感信息泄露。 3. 可维护性命名是否自解释函数是否过长依赖是否注入合理。 4. 性能是否存在无必要循环、重复查询、资源未释放等问题。 对每个问题请以三级标题列出 - 文件位置xx/xx.java:行号 - 问题严重级阻塞 / 严重 / 一般 / 建议 - 分析过程为什么会出问题触发条件是什么 - 修复建议给出最小改动方案说明改动影响范围 所有问题审查结束后单独输出一段“审查结论”明确写出是否存在必须修复后才能合并的问题。这里最容易被忽略的是“建议模型先读哪里”。如果你只说“审查这段代码”模型可能只看这一个文件就下结论。很多 bug 出现在调用方和被调用方的约定不一致上所以我会在模板里加上一句“先阅读该文件的调用方与依赖接口定义再开始逐行审查”。这一步直接决定审查深度付出的成本只是多读两三个文件。3.2 单元测试生成模板生成单测是高频需求但也是最容易失控的。模板里必须写清楚“测试粒度、Mock 边界、数据准备、断言风格、文件命名”五件事。--- description: 为指定类或函数生成单元测试 argument: 被测类或函数名 --- 为 $ARGUMENTS 生成单元测试遵循以下要求 1. 测试文件放到与被测对象相同的包路径下文件名格式为 xxx_go_test.go / XxxTest.java。 2. 单元测试只验证被测对象自身逻辑外部依赖一律 mock集成逻辑标注 Integration。 3. 每个测试方法使用 Given-When-Then 三段式结构关键步骤必须加注释。 4. 断言使用项目统一的断言库禁止使用裸 assert 表达式。 5. 除正常路径外至少覆盖边界值、异常路径、空值场景。 6. 测试数据在单个测试内部构造不使用共享的全局数据避免测试互相污染。 7. 输出改动文件列表并说明每个测试覆盖到的分支。你可能会问这些信息写在 CLAUDE.md 不是更省事吗对通用规范放 CLAUDE.md但测试生成场景有自己独特的约束逻辑比如“Mock 哪些类、怎么处理测试数据”这些只在该任务时才有意义放模板里可以让 CLAUDE.md 保持精简。实践中我发现一个细节必须要求模型先看被测类的现有测试风格。如果项目里已有测试先模仿一到两个现有测试文件再生成新的。这一步能很大程度避免“新测试和老测试风格分裂”的问题。模板里加上一句“如果同类测试文件已存在先读取一到两个模仿其命名与结构”。3.3 Bug 修复与根因定位模板发生线上 bug 时人容易焦虑模型也一样很容易在没完全理解问题时就开始提修复方案。所以我给 bug 修复场景做了一套强调流程的模板--- description: 排查并修复指定 bug argument: bug 的表现描述 --- 执行以下排查流程不得跳步 1. 先复现根据 $ARGUMENTS 构造最小复现路径说明触发条件。 2. 定位结合日志、调用链、相关文件定位到根因函数。 3. 根因分析用因果关系解释为什么该行为导致预期外的结果不要只贴报错堆栈。 4. 设计修复给出两套方案分别说明改动量、风险与回归测试建议。 5. 实施修复选择推荐方案实施增加或调整测试。 6. 输出变更总结包含根因、修复内容、被影响到的接口列表、回归测试命令。这个模板的核心思想是“先定位后动手”。很多低质量修复是模型直接对着报错信息改了一行代码跑通了就觉得修好了。模板强制它输出根因分析实际上是在逼它做自己的 Code Review。还有一个很实用的约束要求模型在每个方案里标注“如果引入新依赖必须说明理由”。因为修复 bug 时模型经常顺手引入一个新的工具库这在企业项目里往往需要额外的 license 和版本管理流程属于默认不允许的变更。3.4 提交信息与 PR 描述模板这个场景看起来简单但写好了价值很大。提交信息模板的核心不是让模型编一个漂亮的 commit message而是让它基于 diff 的实际情况生成。--- description: 根据当前分支的改动生成类型化提交信息与 PR 描述 --- 先执行 git diff 查看当前分支与基线分支的差异然后生成 1. 提交信息按“类型(scope): 主题”格式类型限定为 feat/fix/refactor/test/docs/chore。 2. 变更说明分点列出用户可见的行为变化不写实现细节。 3. 测试说明列出本改动涉及的测试命令与结果。 4. 风险点说明改动可能影响的模块以及是否需要关注回归。这个模板的价值在于格式统一尤其适合接 CI 工具的团队。只要提交信息格式统一版本发布日志、changelog 生成都可以自动化不用后期人工改来改去。4. 从零搭建一套可用模板的实操过程4.1 第一步盘点你的高频任务别一上来就想写十个模板。最务实的做法是花十五分钟做一次任务盘点把过去两周你在 Claude Code 里聊过的事翻出来按频率排序选出前三个高频任务。常见的三类是读代码解释逻辑、写单元测试、生成 commit message。这三个任务有两个共同点重复性强且输出格式统一。如果你的项目里有某个任务每周至少做三次每次都需要重新描述背景那它就该有模板。一次只做三个模板不仅是为了控制工作量更因为模板需要真实使用场景来打磨。你写完一个模板后只有反复用它处理真实任务才能发现哪些描述有歧义、哪些约束是多余的。4.2 第二步起草模板初稿初稿阶段不需要追求完美按我前面说的四段式骨架写就行角色、上下文、任务、输出格式。先把你会对一个新来的实习生说的那段话写下来然后删掉客套话、保留硬约束。写的过程中有个技巧给模型出“选择题”比出“填空题”更稳。比如你要约束 Mock 策略与其说“合理处理外部依赖”不如列三个选项让它选A. 函数内部直接 new 的依赖不做 mock保留真实逻辑B. 注入到函数参数中的依赖用测试框架 mockC. 静态方法调用使用 mock-static 工具。模型面对明确选项时输出会更符合团队预期。这个思路同样适用于格式约束给出一个期望输出的结构模板比单纯说“输出要结构化”有效得多。4.3 第三步给模板做参数化和知识注入初稿写完后开始处理两个问题哪些信息是每次执行时才变化的哪些信息是固定不变的变化的抽象成参数。例如代码审查模板里的$ARGUMENTS就是文件路径单测生成模板里的$ARGUMENTS就是被测类名。固定不变的知识分两类写一类写进 CLAUDE.md适用于所有场景另一类只在特定场景用到比如“审查时必须检查 SQL 注入风险”写在审查模板里。知识注入的原则是宁少勿多。模板里每多一句约束模型就需要多花一些注意力去平衡它和任务本身的权重。如果你写二十条“必须注意”模型很可能一条都没记住。我倾向于把实际产生过错误的场景写入模板不写想象中的风险。4.4 第四步用真实项目完成验证与迭代模板写好后先自己用一周每次执行后都问一个问题“这次输出里有没有任何一条质量问题其实是可以靠模板避免的”如果有把对应的约束补进去。比如我用审查模板时发现模型对“并发问题”审查很弱经常忽略共享变量的可见性。于是我模板里加了一条“如果审查代码涉及多线程必须检查共享变量的可见性问题并单独列出。”这个补充说明就是教练对你的个性化关怀——不对这叫做“用真实反馈迭代模板”。迭代两三周后你会发现模板逐渐稳定。这个时候再把它分享给团队其他成员。分享时讲清楚每条约束背后的实际案例而不是丢一份模板让大家自己看。只有大家理解约束的来龙去脉才愿意在生成结果不符合预期时去改模板而不是直接绕过模板现场乱加 prompt。5. 常见问题与排查技巧实录5.1 模板写了模型却不照做很多人遇到的第一堵墙是模板写得很完整但模型输出时完全忘记输出格式要求。这种情况在长上下文任务里尤其常见。我的排查顺序是这样的先看是不是 CLAUDE.md 和模板之间出现指令冲突。比如 CLAUDE.md 里写了“优先使用精确断言”模板里又说“使用宽松断言体验更好”模型就会在两难中选一个它认为更合理的。排查方法是把所有涉及任务的文件搜一遍看看有没有互相矛盾的表述。如果发现冲突保留更具体的那条。第二个检查点是模板是不是太长了。超过 150 行的模板核心约束会被大量铺垫冲淡。解决方法是把可省略的细节移到 CLAUDE.md 或参考文件里模板只保留任务主线。第三个检查点是模型上下文窗口。如果此前对话里塞进了大量无关历史模板里的关键约束会被“遗忘”在更早的位置。遇到这种情况不要恋战直接/clear清空上下文在新会话里重新执行模板。5.2 上下文太长模板被“顶端封存”这里要解释一个模型运行中的现实Claude Code 会把 CLAUDE.md 和命令模板的内容放到上下文中但随着会话推进用户消息、工具输出、代码片段都在累积。当总长度逼近上下文窗口早期的内容可能会被压缩甚至截断。你明明写了“禁止修改 migrations 目录”模型却大摇大摆改了一遍 migration 文件大概率就是早期指令已经“封存”了。排查技巧是如果任务比较重第一条消息就用/review xxx类命令把模板触发起来然后马上进入正题不要在模型已经读入大量代码之后才把模板甩进去。如果必须要处理长文件就把文件拆成小段分段交给模型处理。还有一种做法是把关键安全约束写进 Hook。Claude Code 支持配置 hooks在某个事件触发时自动注入约束。比如在/edit之前先跑一个检查脚本如果即将修改的文件路径命中规则就阻止操作。模板管不了的事交给流程脚本兜底。5.3 模板管理混乱最终变成一堆废文件模板写着写着仓库里积累了二十多个.md文件最后没人知道每个命令是干什么的。这个问题几乎每个用模板的团队都会遇到。我用的办法是给模板文件做分类前缀review-、gen-、fix-、doc-四类开头的命名然后在.claude/commands/README.md里维护一个速查表。哪天某个模板不再被使用绝不犹豫地删掉因为没人在用的模板和没人在看的注释一样只会增加后续维护成本。这里我强烈建议把模板写进代码审查流程。PR 里如果改了.claude/commands/下的文件必须像改业务代码一样被审查。否则你很快会发现某个模板被改坏了、参数失效了但没有任何人知道。5.4 敏感信息与访问边界问题最后一个坑也是最需要引起警觉的模板处理的是真实代码而真实代码里往往有密钥、内部地址、客户信息。在团队初始化模板时我建议在 CLAUDE.md 里专门加一条“红线”包含敏感信息的文件内容不要直接粘贴到对话中如果必须处理先对信息做脱敏。更稳妥的做法是给命令模板配置allowed-tools比如代码审查模板只允许读取和搜索不允许执行可能产生文件修改的脚本。还有一点容易被忽略模板文件本身不要写任何真实路径、账号、链接只用占位符。模板是跟着仓库走的仓库可能被分享、被 fork、被打包发布。写好之后检查一遍把软信息清干净再提交。说实话我从“随手写 prompt”到“认真搞模板体系”的转折点就是某次线上事故里模型给出了一个看似合理却违反项目约束的修复方案。自那以后我开始意识到Claude Code 的输出质量不是靠运气也不是靠模型参数的某次升级而是靠你愿意花多少精力把团队已知的经验翻译成结构化的指令。后面我又做了一件事效果也很好每次 Claude Code 在真实任务里犯了一个我没预料到的错我就把这次事件记到 CLAUDE.md 的“已踩坑清单”里。这个清单成了我模板迭代的素材库也让后来加入团队的人少交了很多学费。模板体系这件事不需要一次做到位但一定要开始做而且要带着问题意识去做——你每次发现模型“不够懂你”的时刻其实都是模板升级的最佳提示。
Claude Code高效实战：搭建模板体系获得稳定代码输出
Claude Code跑起来很容易真正跑得好很难。我见过太多团队装完工具的第一周都在“裸聊式”使用——一人一句自然语言丢过去生成的代码乍一看能跑等到改需求、补测试、做审查的时候输出质量就开始上下飘。这个问题的根源通常不在模型本身而在你喂给它的那几句话。于是就有了我想聊的 claude-code-templates它不是某个现成插件而是一套围绕 Claude Code 沉淀下来的提示模板工程方法把团队的编码规范、验收标准、常见任务流程从人脑子里搬到模型能稳定读取的文件里。这篇文章写给两类人一是刚接触 Claude Code、想避免“每次都要现场编 prompt”的开发者二是已经在团队里用 Claude Code、但对输出质量不稳定感到头疼的工程负责人。我会从模板为什么有效讲起再到文件怎么组织、典型场景怎么写最后给一套可以直接照搬的搭建流程和排查经验。1. 为什么需要一套可复用的模板体系1.1 一段真实翻车现场先还原一个场景。你在跑一个微服务项目想让 Claude Code 给某个模块补单元测试。你可能会说“帮我给 OrderService 写点单测。”于是模型开始自作主张Mock 风格一会儿 Mockito 一会儿 MockK测试类名和项目现有命名对不上断言路径跑到数据库层甚至把测试用例覆盖到了五层以外的 Controller。这不是模型笨是你的话太短。模型能推理但它对你的团队约定一无所知。它不知道你们统一用 JUnit 5 AssertJ不知道测试文件必须和被测类放同一个包路径不知道数据库操作要打 Integration 标签而不是在单元测试里连真实库。这些信息不喂进去输出稳定的概率就全靠运气。翻车的代价不只是重写代码。每一次重新生成你都要重新复述一遍背景浪费的是 token消耗的是对 AI 工具的信任。更麻烦的是如果团队里有五个人都在用 Claude Code五个人会编出五种风格的 prompt模型也会给出五种风格的代码。一个人踩过的坑其他人照踩。1.2 模板的本质把隐式经验显式化很多人把模板理解成“一段写好的 prompt复制粘贴用”这没错但格局小了。模板的真正价值是把隐式的团队经验变成显式的可执行文件。开发团队里最难传承的就是隐性知识老工程师知道这个模块历史包袱重不能随便动知道重构时优先保兼容性知道某个目录下的代码不允许直接 import 到 service 层。这些经验平时散落在代码注释、Code Review 留言、群里偶尔冒出来的语音里新人和 AI 都很难学到。模板体系可以承载其中的一部分你用文字把规则写清楚用参数把场景固定下来用模板正文把验收标准列成清单Claude 每次执行都会走一遍这套流程。打个比方老厨师做菜靠手感米其林厨房做菜靠标准食谱。食谱不会让厨师变得更有天赋但它保证每个学徒端出来的菜都稳定在及格线以上而稳定的及格线正是工程化交付的底线。Claude Code 的模板就是从“靠手感”到“标准食谱”的那一步。2. 模板体系的整体设计与文件组织2.1 三类存放位置各有分工搭建模板体系的第一步不是写模板而是决定模板放在哪。Claude Code 支持分层的配置目录按作用范围大致分三类全局个人级放在~/.claude/commands/适合那些和项目无关的通用任务比如语法转译、日志分析、代码解释。项目团队级放在项目根目录的.claude/commands/这是最常用的位置。团队约定、技术栈约束、部署流程都围绕项目展开模板天然应该跟着仓库走。用户自定义 Skill放在.claude/skills/或~/.claude/skills/下的独立目录中每个 Skill 是一个文件夹内部有SKILL.md描述文件。这个机制适合做更重一点的“知识包”把某个领域的方法论一次性灌给模型。我的建议是凡是和当前仓库结构、技术选型相关的模板一律放项目级.claude/commands/纯通用的东西才放用户级。因为项目级目录会随仓库一起提交新成员 clone 下来就直接拥有整套约定不用单独问他“你有那个模板吗”。还有一个容易踩的坑.claude/commands/目录名不要拼错。.claude是隐藏目录很多团队会把模板文件随手放在项目根目录的templates/文件夹然后发现斜杠命令怎么也加载不出来。Claude Code 默认扫描的是.claude/commands/文件名就是命令名review.md对应/reviewgen-test.md对应/gen-test。2.2 模板文件的标准骨架打开一个命令模板文件它通常长这样--- description: 对指定代码段做一轮结构化审查 argument: 要审查的文件路径或代码块 allowed-tools: Bash, Read --- ## 你的角色 资深代码审查者关注正确性、可维护性、安全与性能。 ## 上下文 你正在审查 $ARGUMENTS 对应的代码。 请先阅读该文件必要时查看相关引用文件。 ## 任务 1. 指出所有可能导致线上事故的缺陷 2. 指出违反项目规范的地方并引用规范原文 3. 给出修复建议每个建议标注优先级 ## 输出格式 - 问题清单按严重程度排序 - 每条问题包含文件位置 / 问题描述 / 修复建议 / 预估改动量 - 结尾输出“无阻塞项”或“存在阻塞项”这里有几个关键设计。第一用 YAML frontmatter 声明模板的元信息。description会在斜杠命令建议列表里展示argument说明这个命令需要用户提供什么参数allowed-tools限制模型能调用的工具避免它在只读任务里偷偷执行写操作。第二正文分段必须有结构。角色、上下文、任务、输出格式四段是我最常用的骨架。角色解决“什么立场看问题”上下文解决“基于什么信息表态”任务解决“具体干什么”输出格式解决“结果长什么样”。模型对结构化指令的理解能力远好于一段毫无章法的长文本。第三参数不要贪多。$ARGUMENTS是用户输入的核心参数也可以在文件里定义命名参数但参数越多用户每次用起来越累。最好的模板是只留一个必填参数剩下的靠模板自动读取仓库信息。2.3 CLAUDE.md模板体系的底座很多使用者忽略了一个更底层的东西CLAUDE.md。它的作用不是替代模板而是给所有模板提供公共背景知识。Claude Code 在启动时会自动加载当前项目根目录下的 CLAUDE.md里面的内容相当于给模型做了一次“入职培训”。在这个文件里我会放以下几类内容项目的技术栈与目录结构例如“后端是 Python FastAPI前端是 React TypeScript测试统一用 pytest”代码规范与约定例如“文件名用 snake_case接口注释必须写清楚入参出参”项目中必须遵守的边界例如“不要修改 migrations 目录”、“禁止把业务逻辑写在路由层”常用命令例如“构建命令是make build跑测试用make test”。有了 CLAUDE.md 之后模板文件就不需要再重复这些背景信息了。模板只描述任务流程公共知识由底座统一提供。这个分层设计非常重要否则你会陷入另一种麻烦模板越写越长每个模板里都复制一份技术栈说明改一次架构要同步改五个文件。我习惯把 CLAUDE.md 控制在 100 行以内只写那些“模型不知道就会做错”的硬约束不写空话。比如“保证代码质量”这种话没有执行意义“单元测试覆盖率不得低于 80%”才有执行意义。3. 核心场景模板的编写要点与示例3.1 代码审查模板的写法代码审查是模板收益最高的场景。人工审查时每个人关注点不同有人只挑命名有人只关心性能有人自己都没想清楚就凭感觉“LGTM”。把审查标准写成模板等于强制输出质量的下限。我的审查模板会有这么几层--- description: 结构化审查指定代码 argument: 待审查的文件路径 --- 请从以下四个维度审查 $ARGUMENTS 1. 正确性是否存在空指针、并发竞态、越界访问、未处理异常等隐患。 2. 安全性是否对不可信输入做了校验是否存在注入风险、敏感信息泄露。 3. 可维护性命名是否自解释函数是否过长依赖是否注入合理。 4. 性能是否存在无必要循环、重复查询、资源未释放等问题。 对每个问题请以三级标题列出 - 文件位置xx/xx.java:行号 - 问题严重级阻塞 / 严重 / 一般 / 建议 - 分析过程为什么会出问题触发条件是什么 - 修复建议给出最小改动方案说明改动影响范围 所有问题审查结束后单独输出一段“审查结论”明确写出是否存在必须修复后才能合并的问题。这里最容易被忽略的是“建议模型先读哪里”。如果你只说“审查这段代码”模型可能只看这一个文件就下结论。很多 bug 出现在调用方和被调用方的约定不一致上所以我会在模板里加上一句“先阅读该文件的调用方与依赖接口定义再开始逐行审查”。这一步直接决定审查深度付出的成本只是多读两三个文件。3.2 单元测试生成模板生成单测是高频需求但也是最容易失控的。模板里必须写清楚“测试粒度、Mock 边界、数据准备、断言风格、文件命名”五件事。--- description: 为指定类或函数生成单元测试 argument: 被测类或函数名 --- 为 $ARGUMENTS 生成单元测试遵循以下要求 1. 测试文件放到与被测对象相同的包路径下文件名格式为 xxx_go_test.go / XxxTest.java。 2. 单元测试只验证被测对象自身逻辑外部依赖一律 mock集成逻辑标注 Integration。 3. 每个测试方法使用 Given-When-Then 三段式结构关键步骤必须加注释。 4. 断言使用项目统一的断言库禁止使用裸 assert 表达式。 5. 除正常路径外至少覆盖边界值、异常路径、空值场景。 6. 测试数据在单个测试内部构造不使用共享的全局数据避免测试互相污染。 7. 输出改动文件列表并说明每个测试覆盖到的分支。你可能会问这些信息写在 CLAUDE.md 不是更省事吗对通用规范放 CLAUDE.md但测试生成场景有自己独特的约束逻辑比如“Mock 哪些类、怎么处理测试数据”这些只在该任务时才有意义放模板里可以让 CLAUDE.md 保持精简。实践中我发现一个细节必须要求模型先看被测类的现有测试风格。如果项目里已有测试先模仿一到两个现有测试文件再生成新的。这一步能很大程度避免“新测试和老测试风格分裂”的问题。模板里加上一句“如果同类测试文件已存在先读取一到两个模仿其命名与结构”。3.3 Bug 修复与根因定位模板发生线上 bug 时人容易焦虑模型也一样很容易在没完全理解问题时就开始提修复方案。所以我给 bug 修复场景做了一套强调流程的模板--- description: 排查并修复指定 bug argument: bug 的表现描述 --- 执行以下排查流程不得跳步 1. 先复现根据 $ARGUMENTS 构造最小复现路径说明触发条件。 2. 定位结合日志、调用链、相关文件定位到根因函数。 3. 根因分析用因果关系解释为什么该行为导致预期外的结果不要只贴报错堆栈。 4. 设计修复给出两套方案分别说明改动量、风险与回归测试建议。 5. 实施修复选择推荐方案实施增加或调整测试。 6. 输出变更总结包含根因、修复内容、被影响到的接口列表、回归测试命令。这个模板的核心思想是“先定位后动手”。很多低质量修复是模型直接对着报错信息改了一行代码跑通了就觉得修好了。模板强制它输出根因分析实际上是在逼它做自己的 Code Review。还有一个很实用的约束要求模型在每个方案里标注“如果引入新依赖必须说明理由”。因为修复 bug 时模型经常顺手引入一个新的工具库这在企业项目里往往需要额外的 license 和版本管理流程属于默认不允许的变更。3.4 提交信息与 PR 描述模板这个场景看起来简单但写好了价值很大。提交信息模板的核心不是让模型编一个漂亮的 commit message而是让它基于 diff 的实际情况生成。--- description: 根据当前分支的改动生成类型化提交信息与 PR 描述 --- 先执行 git diff 查看当前分支与基线分支的差异然后生成 1. 提交信息按“类型(scope): 主题”格式类型限定为 feat/fix/refactor/test/docs/chore。 2. 变更说明分点列出用户可见的行为变化不写实现细节。 3. 测试说明列出本改动涉及的测试命令与结果。 4. 风险点说明改动可能影响的模块以及是否需要关注回归。这个模板的价值在于格式统一尤其适合接 CI 工具的团队。只要提交信息格式统一版本发布日志、changelog 生成都可以自动化不用后期人工改来改去。4. 从零搭建一套可用模板的实操过程4.1 第一步盘点你的高频任务别一上来就想写十个模板。最务实的做法是花十五分钟做一次任务盘点把过去两周你在 Claude Code 里聊过的事翻出来按频率排序选出前三个高频任务。常见的三类是读代码解释逻辑、写单元测试、生成 commit message。这三个任务有两个共同点重复性强且输出格式统一。如果你的项目里有某个任务每周至少做三次每次都需要重新描述背景那它就该有模板。一次只做三个模板不仅是为了控制工作量更因为模板需要真实使用场景来打磨。你写完一个模板后只有反复用它处理真实任务才能发现哪些描述有歧义、哪些约束是多余的。4.2 第二步起草模板初稿初稿阶段不需要追求完美按我前面说的四段式骨架写就行角色、上下文、任务、输出格式。先把你会对一个新来的实习生说的那段话写下来然后删掉客套话、保留硬约束。写的过程中有个技巧给模型出“选择题”比出“填空题”更稳。比如你要约束 Mock 策略与其说“合理处理外部依赖”不如列三个选项让它选A. 函数内部直接 new 的依赖不做 mock保留真实逻辑B. 注入到函数参数中的依赖用测试框架 mockC. 静态方法调用使用 mock-static 工具。模型面对明确选项时输出会更符合团队预期。这个思路同样适用于格式约束给出一个期望输出的结构模板比单纯说“输出要结构化”有效得多。4.3 第三步给模板做参数化和知识注入初稿写完后开始处理两个问题哪些信息是每次执行时才变化的哪些信息是固定不变的变化的抽象成参数。例如代码审查模板里的$ARGUMENTS就是文件路径单测生成模板里的$ARGUMENTS就是被测类名。固定不变的知识分两类写一类写进 CLAUDE.md适用于所有场景另一类只在特定场景用到比如“审查时必须检查 SQL 注入风险”写在审查模板里。知识注入的原则是宁少勿多。模板里每多一句约束模型就需要多花一些注意力去平衡它和任务本身的权重。如果你写二十条“必须注意”模型很可能一条都没记住。我倾向于把实际产生过错误的场景写入模板不写想象中的风险。4.4 第四步用真实项目完成验证与迭代模板写好后先自己用一周每次执行后都问一个问题“这次输出里有没有任何一条质量问题其实是可以靠模板避免的”如果有把对应的约束补进去。比如我用审查模板时发现模型对“并发问题”审查很弱经常忽略共享变量的可见性。于是我模板里加了一条“如果审查代码涉及多线程必须检查共享变量的可见性问题并单独列出。”这个补充说明就是教练对你的个性化关怀——不对这叫做“用真实反馈迭代模板”。迭代两三周后你会发现模板逐渐稳定。这个时候再把它分享给团队其他成员。分享时讲清楚每条约束背后的实际案例而不是丢一份模板让大家自己看。只有大家理解约束的来龙去脉才愿意在生成结果不符合预期时去改模板而不是直接绕过模板现场乱加 prompt。5. 常见问题与排查技巧实录5.1 模板写了模型却不照做很多人遇到的第一堵墙是模板写得很完整但模型输出时完全忘记输出格式要求。这种情况在长上下文任务里尤其常见。我的排查顺序是这样的先看是不是 CLAUDE.md 和模板之间出现指令冲突。比如 CLAUDE.md 里写了“优先使用精确断言”模板里又说“使用宽松断言体验更好”模型就会在两难中选一个它认为更合理的。排查方法是把所有涉及任务的文件搜一遍看看有没有互相矛盾的表述。如果发现冲突保留更具体的那条。第二个检查点是模板是不是太长了。超过 150 行的模板核心约束会被大量铺垫冲淡。解决方法是把可省略的细节移到 CLAUDE.md 或参考文件里模板只保留任务主线。第三个检查点是模型上下文窗口。如果此前对话里塞进了大量无关历史模板里的关键约束会被“遗忘”在更早的位置。遇到这种情况不要恋战直接/clear清空上下文在新会话里重新执行模板。5.2 上下文太长模板被“顶端封存”这里要解释一个模型运行中的现实Claude Code 会把 CLAUDE.md 和命令模板的内容放到上下文中但随着会话推进用户消息、工具输出、代码片段都在累积。当总长度逼近上下文窗口早期的内容可能会被压缩甚至截断。你明明写了“禁止修改 migrations 目录”模型却大摇大摆改了一遍 migration 文件大概率就是早期指令已经“封存”了。排查技巧是如果任务比较重第一条消息就用/review xxx类命令把模板触发起来然后马上进入正题不要在模型已经读入大量代码之后才把模板甩进去。如果必须要处理长文件就把文件拆成小段分段交给模型处理。还有一种做法是把关键安全约束写进 Hook。Claude Code 支持配置 hooks在某个事件触发时自动注入约束。比如在/edit之前先跑一个检查脚本如果即将修改的文件路径命中规则就阻止操作。模板管不了的事交给流程脚本兜底。5.3 模板管理混乱最终变成一堆废文件模板写着写着仓库里积累了二十多个.md文件最后没人知道每个命令是干什么的。这个问题几乎每个用模板的团队都会遇到。我用的办法是给模板文件做分类前缀review-、gen-、fix-、doc-四类开头的命名然后在.claude/commands/README.md里维护一个速查表。哪天某个模板不再被使用绝不犹豫地删掉因为没人在用的模板和没人在看的注释一样只会增加后续维护成本。这里我强烈建议把模板写进代码审查流程。PR 里如果改了.claude/commands/下的文件必须像改业务代码一样被审查。否则你很快会发现某个模板被改坏了、参数失效了但没有任何人知道。5.4 敏感信息与访问边界问题最后一个坑也是最需要引起警觉的模板处理的是真实代码而真实代码里往往有密钥、内部地址、客户信息。在团队初始化模板时我建议在 CLAUDE.md 里专门加一条“红线”包含敏感信息的文件内容不要直接粘贴到对话中如果必须处理先对信息做脱敏。更稳妥的做法是给命令模板配置allowed-tools比如代码审查模板只允许读取和搜索不允许执行可能产生文件修改的脚本。还有一点容易被忽略模板文件本身不要写任何真实路径、账号、链接只用占位符。模板是跟着仓库走的仓库可能被分享、被 fork、被打包发布。写好之后检查一遍把软信息清干净再提交。说实话我从“随手写 prompt”到“认真搞模板体系”的转折点就是某次线上事故里模型给出了一个看似合理却违反项目约束的修复方案。自那以后我开始意识到Claude Code 的输出质量不是靠运气也不是靠模型参数的某次升级而是靠你愿意花多少精力把团队已知的经验翻译成结构化的指令。后面我又做了一件事效果也很好每次 Claude Code 在真实任务里犯了一个我没预料到的错我就把这次事件记到 CLAUDE.md 的“已踩坑清单”里。这个清单成了我模板迭代的素材库也让后来加入团队的人少交了很多学费。模板体系这件事不需要一次做到位但一定要开始做而且要带着问题意识去做——你每次发现模型“不够懂你”的时刻其实都是模板升级的最佳提示。