1. 模板不是约束是让 Claude Code 从聪明变靠谱的杠杆先说一个我自己的真实感受。最早用 Claude Code 的时候我的体验可以用四个字形容飘忽不定。同一个任务如果我把需求描述得足够清楚它能给出接近完美的方案但如果我偷懒只说一句帮我把这个接口改一下它也能交差但交出来的代码风格明显不是这个项目该有的样子——命名习惯不对、错误处理缺失、注释风格也不同。当时我一度以为是模型的问题后来才意识到问题不在模型在我没有给它一套稳定的游戏规则。这个规则就是模板。所谓 claude-code-templates通俗讲就是为 Claude Code 准备的一套可复用的提示词模板、项目级指令文件和命令注册机制。它解决的不是能不能用的问题而是好不好用稳不稳定的问题。举一个类比同样一位厨师给他一份清晰的菜谱和标准化的食材清单他做出来的每道菜都能保持水准如果每次只口头说做道好吃的那结果全看当天心情。Claude Code 其实也一样模板就是那份菜谱。我一直觉得很多开发者对 Claude Code 的使用还停留在聊天式编程的阶段打开终端输入一句话等结果。这种用法不能说错但它完全浪费了 Claude Code 最核心的能力——可编程性。你可以通过模板、配置文件、命令系统把它从一个被动应答的工具变成一个能主动遵循项目规范、理解团队约定、甚至能自动执行固定流程的编码伙伴。这篇博文就把我自己搭建的 claude-code-templates 完整分享出来包括设计思路、分层结构、具体模板内容、安装方式以及迭代过程中踩过的坑。如果你正在用 Claude Code但觉得回答质量不稳定、风格不统一、每次都要反复说同一堆要求这篇文章应该能帮到你。2. 先搞清楚三个层级的模板体系CLAUDE.md、CLAUDE.local.md 与斜杠命令很多人以为模板就是一堆提示词字符串其实不是。我自己的模板体系是三层结构每一层解决不同粒度的问题。理解这三层你才能理解为什么有些模板放对位置能发挥巨大作用放错位置却毫无效果。2.1 第一层CLAUDE.md——全局记忆与项目契约CLAUDE.md 是 Claude Code 在项目根目录下自动读取的指令文件类似给整个会话注入的项目背景知识。每次启动会话它都会把这个文件内容作为上下文的一部分所以这里面应该放的是所有任务都适用的、稳定不变的规范。我当时设计 CLAUDE.md 时里面放了四块内容项目一句话定位这个仓库是干什么的、主要技术栈是什么、目标用户是谁代码风格约束命名规范、目录组织、注释风格、错误处理要求架构边界哪些模块不允许互相依赖、数据流向是什么、核心不可变原则有哪些安全与质量红线比如不允许把密钥写进代码、不允许跳过测试、生产代码必须加日志等。一开始我把 CLAUDE.md 写得非常长恨不得把团队的编码规范书全塞进去。后来发现不行因为上下文空间有限而且太长的规则 AI 根本抓不住重点反而影响其他指令的执行。最终我精简到了不到 60 行只保留那些最容易违反、且违反后代价高昂的规则。举个例子我们项目里有一条禁止在 API 层直接透传数据库异常的约定。这条如果不写在 CLAUDE.md 里Claude 经常会在生成的代码里写catch (Exception e) { throw e; }责任链完全断掉。写进去之后类似的问题几乎绝迹。2.2 第二层CLAUDE.local.md——个人偏好与实验场CLAUDE.local.md 和 CLAUDE.md 的机制类似但它更适合放只对自己生效、不需要提交到版本库的内容。按我的理解它的定位是本地实验场和个人快捷键。我自己会在 CLAUDE.local.md 里放什么比如我最习惯的回复风格先给结论再给细节、我在这个项目里经常使用但团队其他人不用的命令别名、我个人的目录偏好等。这些内容如果放进 CLAUDE.md 提交给团队可能会干扰其他人的使用习惯但放在 local 文件里就恰到好处。还有一点很关键CLAUDE.local.md 默认应该加入 .gitignore。因为它本来就是个人偏好提交到仓库里属于污染共享配置。2.3 第三层斜杠命令模板——把高频动作固化为标准流程这是整套模板体系里最能提升效率的部分也是最容易被忽略的。Claude Code 支持斜杠命令slash commands实现方式是在项目的.claude/commands/目录下放一批 markdown 文件文件名就是命令名。比如建立一个review.md里面写好以资深代码审查者的身份对指定文件进行逐项审查的提示词之后你在终端里输入/review src/foo.ts它就会自动按模板执行。我的 claude-code-templates 项目里核心资产其实就是这些命令文件。它们把高频、重复、且有标准动作的任务固化成了可一键调用的流程。我想强调的是斜杠命令和普通提示词最大的区别是命令本身可以自带逻辑结构。比如一个测试生成命令它不只是简单写一句帮我写测试而是在模板里规定了先分析被测函数的行为边界再列出需要覆盖的分支接着按团队的测试命名规范生成用例最后检查断言完整性并补一个边界条件测试。这样每次调用产出的不是一段能跑的测试代码而是符合团队标准、覆盖完整的测试集。2.4 三层的协作关系一个完整需求是怎么流转的这三层的分工可以这样看CLAUDE.md 管项目人设和底线是会话启动时的背景知识CLAUDE.local.md 管个人适配层是个性化补充斜杠命令管单次动作的执行路径是遇到具体任务时的操作手册。举个例子我让 Claude Code 给一个 API 写单元测试。它会这样运转首先加载 CLAUDE.md知道项目用的是 Jest、测试文件放在__tests__目录、命名格式是*.test.ts然后我调用/test斜杠命令它读取命令模板明白当前任务是对 utils 模块的 dateFormat 函数补测试执行过程中如果遇到风格上的小问题比如我偏好用describe的嵌套层级而不是扁平结构CLAUDE.local.md 里的个人配置会自动修正。这里最核心的心得是模板不是替代你的思考而是把你的思考固化成可重复执行的流程。你只需要花一次时间把流程想清楚之后每一次调用都在复利。3. 我实际在用的五类模板从测试生成到架构评审的完整拆解前两节讲的是框架和原理这一节给你看具体的模板内容。我把自己的模板仓库按场景分成了五类每一类都有明确的适用范围和效果预期。你可以直接抄走再根据自己的情况调整。3.1 测试生成模板让 AI 先列分支再写用例最早让我下定决心做模板的就是测试生成。因为 Claude Code 写 happy path正常路径的测试几乎从不失手但边界条件和异常分支经常漏掉。与其每次补充提醒不如把要求直接固化进模板。这个模板的关键不是最后那段请生成测试的指令而是它强制 AI 先完成一个前置动作列分支清单。模板的核心内容如下.claude/commands/test.md你是一名对质量有执念的测试工程师。针对用户给定的文件或函数按照以下流程生成单元测试 1. 先阅读被测代码列出所有需要覆盖的行为分支包括 - 正常输入路径 - 空值 / 未定义 / 类型异常 - 边界值如 0、负数、超长字符串、最大整数 - 依赖函数抛错时的传播行为 - 对全局状态 / 定时器 / mock 的预期交互 2. 将分支清单展示出来等待用户确认。如果用户没有特别补充直接执行下一步。 3. 按团队成员熟悉的测试风格编写用例使用 Jest 框架文件命名 {name}.test.tsdescribe 嵌套按模块/函数/场景三层组织。每个测试用例必须以中文注释描述行为意图。 4. 断言必须包含正确结果和副作用检查两个维度。例如测试一个缓存函数不仅要断言返回值正确还要断言缓存被写入、写入次数为 1。 5. 所有外部依赖必须显式 mock禁止依赖真实网络请求或时间函数。在使用这个模板之前Claude Code 生成的测试大概能覆盖 60% 的分支用了之后基本稳定在 90% 以上。剩余那 10% 往往是被测代码本身的写法有问题不是模板的问题。3.2 重构模板先出方案确认后再动手重构类任务最容易出事故的地方是AI 太勤快你说帮我优化一下这段代码它直接把整个函数翻了个底朝天行为完全变了你还得手动 review。这非常危险。所以我的重构模板.claude/commands/refactor.md铁律只有一条不许先改代码先写方案。模板在其中强制规定了方案必须包含哪些要素你是资深软件架构师。收到重构请求后严格按下列步骤执行 1. 阅读目标代码及其调用方识别真实职责和隐式耦合。 2. 输出重构方案必须包含以下七个部分 - 现状问题清单按严重程度排序 - 重构目标明确哪些行为不允许改变 - 方案设计包含代码级别的变更要点 - 影响范围分析列出所有受影响调用点 - 风险提示哪些行为可能因重构而变化 - 验证策略如何确认重构不破坏原有行为 - 回滚预案如果出问题如何快速恢复 3. 输出方案后立即停止等待用户明确说开始执行。 4. 执行时必须分步提交每完成一步就展示变更和对应测试结果禁止一次改完整个文件再汇报。这个模板的价值在于把AI 单方面行动变成了人类决策 AI 执行的协作模式。重构这种高风险操作决策权必须留在人手里。我印象很深的一次用它重构一个老模块时AI 在影响范围分析里点出了一个我完全没想到的调用链——有个远程配置文件会通过反射方式调用这个模块里的类名重构后类名变了会导致线上配置失效。这个风险如果没有提前暴露后果很严重。3.3 调试模板用现场信息代替 AI 瞎猜调试是另一种需要纪律的场景。Claude Code 在没有足够信息时会倾向于猜测 建议而不是排查 定位。过去的对话里它经常给我提出十几个可能原因每个看起来都对但就是没一个能直接解决问题。调试模板.claude/commands/debug.md的思路是先收集信息再给出假设后验证假设。模板会强制 AI 按这个顺序行动你是一名严谨的 Debug 专家。用户会提供一个 Bug 现象描述。你的任务顺序是 1. 信息收集阶段不允许越级 - 请用户提供完整错误堆栈、相关代码片段、输入输出样例、环境版本信息。 - 如果信息不足列出需要但缺失的信息清单并明确询问禁止直接开始猜测。 2. 假设生成阶段 - 基于已有信息列出 2-3 个最可能的根因假设每个假设给出置信度。 - 为每个假设设计一个最廉价的验证实验优先选择日志输出或最小复现代码。 3. 验证执行阶段 - 按置信度从高到低逐一验证每验证完一个假设必须记录结果并更新剩余假设的置信度。 4. 根因确认后提供修复方案并在修复后补充一条回归测试用例。这个模板的效果非常显著——它把 AI 的发散性建议强制收敛成了结构化排查。用了一段时间之后我的真实感受是Claude Code 在有纪律的思考模式下准确率比自由发挥模式高一大截。因为它本身就有很强的推理能力只是平日里缺少一个约束它按正确流程思考的框架。模板本质上就是在做这件事。3.4 代码审查模板让 AI 扮演最难搞的同事代码审查是模板收益最直接、最容易量化的场景。我写的审查模板.claude/commands/review.md会系统检查提交代码的多个维度并以表格形式输出结果。模板的核心是定义了审查的维度清单你是代码审查专家。审查用户提供的代码或变更按以下维度逐项评估并以表格输出列维度 / 评分 / 问题描述 / 建议 1. 正确性是否存在逻辑错误、并发问题、边界遗漏。 2. 安全是否有注入、敏感信息泄露、权限缺失、不安全的反序列化。 3. 性能是否有明显性能瓶颈、N1 查询、不必要的重复计算。 4. 可维护性命名是否表意、函数是否过长、职责是否单一。 5. 测试覆盖关键分支是否缺失测试测试断言是否有效。 6. 风格一致性是否符合项目已有的编码约定对照 CLAUDE.md 中的规则。 7. 潜在技术债是否存在可以简化但暂时没简化的写法给出理由。 最终输出必须包含一段总结如果评分低于 7 分明确给出必须修改才能合并的条目7 分以上也要给出至少一个改进建议。这个模板我用得最多因为它是纯只读操作不会改坏代码所以可以放心大胆地在任何规模的项目上跑。对大型 PR 而言它能快速覆盖一些人工容易漏掉的维度虽然不能替代人的判断但作为第一道过滤器非常趁手。3.5 提交信息与变更记录模板收尾工作的自动化很多人忽略提交信息也是一项值得模板化的任务。Claude Code 能通过git diff了解变更内容但默认生成的提交信息经常过于笼统不符合 Conventional Commits约定式提交规范。提交信息模板.claude/commands/commit.md做三件事读取 diff、归类变更类型、按规范生成提交信息。同时在最后会附上一份变更摘要方便直接用于 PR 描述。请根据 git diff如果没有提供自动执行 git diff --stat 和 git diff生成符合 Conventional Commits 规范的提交信息。 要求 - type 根据变更内容选择feat / fix / refactor / docs / test / chore / perf。 - 正文必须包含三个部分变更动机、具体变更内容、影响说明。 - 如果包含破坏性变更BREAKING CHANGE必须在 footer 中标注并说明迁移路径。 - 生成的提交信息控制在 10 行以内header 正文 footer每行不超过 72 字符。 - 变更摘要部分用自然语言概括本次 PR 的影响范围适合直接粘贴到 PR 描述。这类模板对个人项目可能用处不大但如果你在团队里工作提交信息的规范性能省下不少被同事点名修改 commit message的尴尬。4. 模板仓库的工程化落地从手写文件到标准化管理的完整流程有了模板内容之后还有一个工程问题如何管理这些模板文件、如何确保它们在不同项目之间复用、如何迭代升级。这一节把我的落地方式完整拆开讲。4.1 模板仓库的目录结构设计我的 claude-code-templates 仓库采用了如下结构claude-code-templates/ ├── README.md # 使用说明如何安装、如何自定义 ├── commands/ # 斜杠命令模板 │ ├── test.md │ ├── refactor.md │ ├── debug.md │ ├── review.md │ └── commit.md ├── CLAUDE.md # 项目级通用指令模板 └── CLAUDE.local.md.example # 个人配置的示例文件实际操作中我会把这个仓库 clone 到本地然后通过软链接方式把 commands 目录映射到各个项目的.claude/commands/位置这样改一处就能生效于所有项目。命令如下# 在项目根目录下执行 ln -s ~/projects/claude-code-templates/commands .claude/commands如果你不用软链接直接把文件复制过去也行但那样后续更新会很痛苦不建议。有一点要提醒.claude/commands这个目录是否提交到版本库取决于团队。如果团队希望共享这套规范提交进去完全合理如果只是个人习惯建议 gitignore 掉避免给队友制造噪音。4.2 写模板时最容易忽略的细节变量、引用和上下文长度斜杠命令不是纯静态文本Claude Code 支持在命令中引用上下文比如$INPUT代表用户输入$CLAUDE.md可以引用项目指令文件内容你也可以显式引用其他文件。合理使用这些能力能让模板的适用范围成倍扩大。我自己用得最多的引用技巧是在测试模板开头显式引用项目的测试配置文件确保 AI 知道当前项目的测试运行方式。比如请先阅读 tests/jest.config.js 了解当前项目的测试配置再按测试模板执行。在 Claude Code 中使用或$引用文件能直接把文件内容注入上下文。这样一来每个项目的测试风格即使有差异模板也能自适应不需要为每个项目单独维护一份。还有一个细节模板中关于输出格式的约束要具体到结构但不要到措辞。比如以表格输出列包含维度 / 评分 / 问题描述 / 建议是好的约束它会规范格式但如果写必须使用『问题分析』作为标题那是过度约束会让回复变得生硬反而丢失了自然语言的灵活性。4.3 模板的迭代基于真实使用日志做版本升级模板不是一次性写好的它需要随着使用不断迭代。我维护了一个简单的版本记录每次改动都有原因。这套 claude-code-templates 如果说有什么方法论层面的东西那可能就是把模板当代码一样维护有变更就用 git 记录有改进就发布新版本。我自己在迭代中主要依据三个来源使用后检查输出看 AI 有没有遗漏我关心的点查看 Claude Code 的会话记录统计哪些提醒我反复手动补充这些就是模板记忆缺口和团队其他使用者交流收集大家觉得AI 经常做不好的部分反向补充进模板。举一个实际的迭代例子测试模板最初只有生成用例的步骤后来我在使用中发现它生成的 mock 总是写得太理想化没有覆盖资源释放这个点。于是我在模板里加了一条所有涉及文件句柄、连接池、定时器的测试必须验证资源释放分支。 这个改进之后测试质量又上了一个台阶。5. 踩过的坑过度约束、命令滥用与团队协作问题模板体系用得好是杠杆用得不好也会带来新的问题。这一节把我踩过的几个有代表性的坑写出来帮你提前绕开。5.1 模板不是越细越好过度约束会让 AI 变成机器我在早期犯过一个很典型的错误为了让 AI 生成100% 符合团队规范的代码我把模板写成了一本操作手册每一步都规定得死死的。结果代码倒是规范了但出现了新的问题——AI 失去了灵活性遇到模板没覆盖到的情况时不会变通产出反而更差。举一个例子我在测试模板里规定了所有测试必须用 Jest 的describe三层嵌套但有一次需要给一个纯工具函数写单测三层嵌套明显冗余。AI 因为指令约束还是生成了两套嵌套造成了阅读负担。后来我把这类硬性约束改成了默认建议 允许判断的表述比如改为通常使用三层嵌套若被测函数逻辑简单允许用单层结构但需要在注释中说明理由。核心原则是模板要约束的是必须满足的目标和不能违反的底线而不是每一步怎么做。5.2 斜杠命令的滥用命令多了反而不知道用哪个我最初疯狂加命令代码生成、接口设计、架构评审、数据库迁移、文档编写……目录里塞了二十多个命令文件。结果每次打开终端我自己都要想一下该用哪个命令最终反而削弱了使用意愿。后来我做了减法只保留真正每周都会用到的五六个命令其他场景宁可现场写提示词。这个经历给我的启发是模板的覆盖面不是越全越好使用频率才是决定它价值的关键。如果你一个月都用不到一次的命令它存在的意义不大还可能和命令体系里其他文件形成干扰。5.3 团队协作时的模板来源管理同步、覆盖与信任问题如果你在团队里推广这套模板体系要注意一个比较隐蔽的问题每个人的.claude/commands里的模板可能版本不一致。A 改了一句指令B 那边没有同步两个人执行同一命令得到不同的行为这非常容易让人困惑。我现在的做法是模板仓库统一维护发布版本走 git tag各项目通过软链接或安装脚本固定到指定版本。每次模板更新后在群里发一条简短的变更说明让团队成员知道行为发生了哪些变化。信任问题才是最大问题——如果大家不确定模板的质量和更新原则他们会倾向于绕过模板直接手动编写提示词。所以模板的维护人要像维护开源项目一样用心编写文案、留下变更记录、听取反馈。5.4 模板互相冲突CLAUDE.md 与命令文件之间的矛盾最后是一个我自己磨合了一阵子才发现的坑当 CLAUDE.md 里的规范和斜杠命令模板里的指令冲突时Claude Code 会优先听从哪一个这没有标准答案取决于上下文顺序和具体表述。为了避免这种不确定性我给自己定了一条纪律全局规范只放原则具体任务流程一律放在命令模板里两者不建议描述同一个细节。举个例子不要在 CLAUDE.md 里写所有测试生成必须用 Jest 编写因为测试命令模板里肯定也会写。两条都存在时AI 可能会因为表述的微小差别产生行为偏移。整个模板体系内部的一致性比每一份模板单独的正确性重要得多。6. 从我自己的使用感受谈一谈模板让你的 AI 协作真正可积累说到底claude-code-templates 这个项目的价值不只是提供了一批好用的提示词而是提供了一种思路和 AI 协作的方式是可以被沉淀、被复用、被版本化的。最开始用 Claude Code我会觉得每次对话都是一次性的——用完就忘下次再从头交代。有了模板体系之后情况完全不同我对 AI 的要求、标准、流程都变成了仓库里可追溯的文件。今天发现 AI 在某个环节做得不好我改一行模板以后所有会话都受益。这种复利效应是模板给我带来的最大收益。我个人实际使用中的体会是真正值得模板化的不是那些你说得清楚的需求而是那些你经常忘记说清楚的事情。比如测试必须覆盖边界条件重构前先看影响范围提交信息要写清楚破坏性变更这些要求你在第一次对话里大概率会提到但每次都提又烦又累。把它们固化成模板AI 每次都能做到久而久之就变成了团队默认的工作习惯。如果你刚开始尝试我的建议是从一个最让你头疼的场景开始比如测试生成或代码审查写一份最简单的命令模板用一周改三版。这个过程会比你直接下载一百份别人的模板更有收获。毕竟模板的价值不在于数量而在于它是不是真的符合你的使用习惯。 Claude Code 模板体系实战：从项目规范到斜杠命令的工程化落地
1. 模板不是约束是让 Claude Code 从聪明变靠谱的杠杆先说一个我自己的真实感受。最早用 Claude Code 的时候我的体验可以用四个字形容飘忽不定。同一个任务如果我把需求描述得足够清楚它能给出接近完美的方案但如果我偷懒只说一句帮我把这个接口改一下它也能交差但交出来的代码风格明显不是这个项目该有的样子——命名习惯不对、错误处理缺失、注释风格也不同。当时我一度以为是模型的问题后来才意识到问题不在模型在我没有给它一套稳定的游戏规则。这个规则就是模板。所谓 claude-code-templates通俗讲就是为 Claude Code 准备的一套可复用的提示词模板、项目级指令文件和命令注册机制。它解决的不是能不能用的问题而是好不好用稳不稳定的问题。举一个类比同样一位厨师给他一份清晰的菜谱和标准化的食材清单他做出来的每道菜都能保持水准如果每次只口头说做道好吃的那结果全看当天心情。Claude Code 其实也一样模板就是那份菜谱。我一直觉得很多开发者对 Claude Code 的使用还停留在聊天式编程的阶段打开终端输入一句话等结果。这种用法不能说错但它完全浪费了 Claude Code 最核心的能力——可编程性。你可以通过模板、配置文件、命令系统把它从一个被动应答的工具变成一个能主动遵循项目规范、理解团队约定、甚至能自动执行固定流程的编码伙伴。这篇博文就把我自己搭建的 claude-code-templates 完整分享出来包括设计思路、分层结构、具体模板内容、安装方式以及迭代过程中踩过的坑。如果你正在用 Claude Code但觉得回答质量不稳定、风格不统一、每次都要反复说同一堆要求这篇文章应该能帮到你。2. 先搞清楚三个层级的模板体系CLAUDE.md、CLAUDE.local.md 与斜杠命令很多人以为模板就是一堆提示词字符串其实不是。我自己的模板体系是三层结构每一层解决不同粒度的问题。理解这三层你才能理解为什么有些模板放对位置能发挥巨大作用放错位置却毫无效果。2.1 第一层CLAUDE.md——全局记忆与项目契约CLAUDE.md 是 Claude Code 在项目根目录下自动读取的指令文件类似给整个会话注入的项目背景知识。每次启动会话它都会把这个文件内容作为上下文的一部分所以这里面应该放的是所有任务都适用的、稳定不变的规范。我当时设计 CLAUDE.md 时里面放了四块内容项目一句话定位这个仓库是干什么的、主要技术栈是什么、目标用户是谁代码风格约束命名规范、目录组织、注释风格、错误处理要求架构边界哪些模块不允许互相依赖、数据流向是什么、核心不可变原则有哪些安全与质量红线比如不允许把密钥写进代码、不允许跳过测试、生产代码必须加日志等。一开始我把 CLAUDE.md 写得非常长恨不得把团队的编码规范书全塞进去。后来发现不行因为上下文空间有限而且太长的规则 AI 根本抓不住重点反而影响其他指令的执行。最终我精简到了不到 60 行只保留那些最容易违反、且违反后代价高昂的规则。举个例子我们项目里有一条禁止在 API 层直接透传数据库异常的约定。这条如果不写在 CLAUDE.md 里Claude 经常会在生成的代码里写catch (Exception e) { throw e; }责任链完全断掉。写进去之后类似的问题几乎绝迹。2.2 第二层CLAUDE.local.md——个人偏好与实验场CLAUDE.local.md 和 CLAUDE.md 的机制类似但它更适合放只对自己生效、不需要提交到版本库的内容。按我的理解它的定位是本地实验场和个人快捷键。我自己会在 CLAUDE.local.md 里放什么比如我最习惯的回复风格先给结论再给细节、我在这个项目里经常使用但团队其他人不用的命令别名、我个人的目录偏好等。这些内容如果放进 CLAUDE.md 提交给团队可能会干扰其他人的使用习惯但放在 local 文件里就恰到好处。还有一点很关键CLAUDE.local.md 默认应该加入 .gitignore。因为它本来就是个人偏好提交到仓库里属于污染共享配置。2.3 第三层斜杠命令模板——把高频动作固化为标准流程这是整套模板体系里最能提升效率的部分也是最容易被忽略的。Claude Code 支持斜杠命令slash commands实现方式是在项目的.claude/commands/目录下放一批 markdown 文件文件名就是命令名。比如建立一个review.md里面写好以资深代码审查者的身份对指定文件进行逐项审查的提示词之后你在终端里输入/review src/foo.ts它就会自动按模板执行。我的 claude-code-templates 项目里核心资产其实就是这些命令文件。它们把高频、重复、且有标准动作的任务固化成了可一键调用的流程。我想强调的是斜杠命令和普通提示词最大的区别是命令本身可以自带逻辑结构。比如一个测试生成命令它不只是简单写一句帮我写测试而是在模板里规定了先分析被测函数的行为边界再列出需要覆盖的分支接着按团队的测试命名规范生成用例最后检查断言完整性并补一个边界条件测试。这样每次调用产出的不是一段能跑的测试代码而是符合团队标准、覆盖完整的测试集。2.4 三层的协作关系一个完整需求是怎么流转的这三层的分工可以这样看CLAUDE.md 管项目人设和底线是会话启动时的背景知识CLAUDE.local.md 管个人适配层是个性化补充斜杠命令管单次动作的执行路径是遇到具体任务时的操作手册。举个例子我让 Claude Code 给一个 API 写单元测试。它会这样运转首先加载 CLAUDE.md知道项目用的是 Jest、测试文件放在__tests__目录、命名格式是*.test.ts然后我调用/test斜杠命令它读取命令模板明白当前任务是对 utils 模块的 dateFormat 函数补测试执行过程中如果遇到风格上的小问题比如我偏好用describe的嵌套层级而不是扁平结构CLAUDE.local.md 里的个人配置会自动修正。这里最核心的心得是模板不是替代你的思考而是把你的思考固化成可重复执行的流程。你只需要花一次时间把流程想清楚之后每一次调用都在复利。3. 我实际在用的五类模板从测试生成到架构评审的完整拆解前两节讲的是框架和原理这一节给你看具体的模板内容。我把自己的模板仓库按场景分成了五类每一类都有明确的适用范围和效果预期。你可以直接抄走再根据自己的情况调整。3.1 测试生成模板让 AI 先列分支再写用例最早让我下定决心做模板的就是测试生成。因为 Claude Code 写 happy path正常路径的测试几乎从不失手但边界条件和异常分支经常漏掉。与其每次补充提醒不如把要求直接固化进模板。这个模板的关键不是最后那段请生成测试的指令而是它强制 AI 先完成一个前置动作列分支清单。模板的核心内容如下.claude/commands/test.md你是一名对质量有执念的测试工程师。针对用户给定的文件或函数按照以下流程生成单元测试 1. 先阅读被测代码列出所有需要覆盖的行为分支包括 - 正常输入路径 - 空值 / 未定义 / 类型异常 - 边界值如 0、负数、超长字符串、最大整数 - 依赖函数抛错时的传播行为 - 对全局状态 / 定时器 / mock 的预期交互 2. 将分支清单展示出来等待用户确认。如果用户没有特别补充直接执行下一步。 3. 按团队成员熟悉的测试风格编写用例使用 Jest 框架文件命名 {name}.test.tsdescribe 嵌套按模块/函数/场景三层组织。每个测试用例必须以中文注释描述行为意图。 4. 断言必须包含正确结果和副作用检查两个维度。例如测试一个缓存函数不仅要断言返回值正确还要断言缓存被写入、写入次数为 1。 5. 所有外部依赖必须显式 mock禁止依赖真实网络请求或时间函数。在使用这个模板之前Claude Code 生成的测试大概能覆盖 60% 的分支用了之后基本稳定在 90% 以上。剩余那 10% 往往是被测代码本身的写法有问题不是模板的问题。3.2 重构模板先出方案确认后再动手重构类任务最容易出事故的地方是AI 太勤快你说帮我优化一下这段代码它直接把整个函数翻了个底朝天行为完全变了你还得手动 review。这非常危险。所以我的重构模板.claude/commands/refactor.md铁律只有一条不许先改代码先写方案。模板在其中强制规定了方案必须包含哪些要素你是资深软件架构师。收到重构请求后严格按下列步骤执行 1. 阅读目标代码及其调用方识别真实职责和隐式耦合。 2. 输出重构方案必须包含以下七个部分 - 现状问题清单按严重程度排序 - 重构目标明确哪些行为不允许改变 - 方案设计包含代码级别的变更要点 - 影响范围分析列出所有受影响调用点 - 风险提示哪些行为可能因重构而变化 - 验证策略如何确认重构不破坏原有行为 - 回滚预案如果出问题如何快速恢复 3. 输出方案后立即停止等待用户明确说开始执行。 4. 执行时必须分步提交每完成一步就展示变更和对应测试结果禁止一次改完整个文件再汇报。这个模板的价值在于把AI 单方面行动变成了人类决策 AI 执行的协作模式。重构这种高风险操作决策权必须留在人手里。我印象很深的一次用它重构一个老模块时AI 在影响范围分析里点出了一个我完全没想到的调用链——有个远程配置文件会通过反射方式调用这个模块里的类名重构后类名变了会导致线上配置失效。这个风险如果没有提前暴露后果很严重。3.3 调试模板用现场信息代替 AI 瞎猜调试是另一种需要纪律的场景。Claude Code 在没有足够信息时会倾向于猜测 建议而不是排查 定位。过去的对话里它经常给我提出十几个可能原因每个看起来都对但就是没一个能直接解决问题。调试模板.claude/commands/debug.md的思路是先收集信息再给出假设后验证假设。模板会强制 AI 按这个顺序行动你是一名严谨的 Debug 专家。用户会提供一个 Bug 现象描述。你的任务顺序是 1. 信息收集阶段不允许越级 - 请用户提供完整错误堆栈、相关代码片段、输入输出样例、环境版本信息。 - 如果信息不足列出需要但缺失的信息清单并明确询问禁止直接开始猜测。 2. 假设生成阶段 - 基于已有信息列出 2-3 个最可能的根因假设每个假设给出置信度。 - 为每个假设设计一个最廉价的验证实验优先选择日志输出或最小复现代码。 3. 验证执行阶段 - 按置信度从高到低逐一验证每验证完一个假设必须记录结果并更新剩余假设的置信度。 4. 根因确认后提供修复方案并在修复后补充一条回归测试用例。这个模板的效果非常显著——它把 AI 的发散性建议强制收敛成了结构化排查。用了一段时间之后我的真实感受是Claude Code 在有纪律的思考模式下准确率比自由发挥模式高一大截。因为它本身就有很强的推理能力只是平日里缺少一个约束它按正确流程思考的框架。模板本质上就是在做这件事。3.4 代码审查模板让 AI 扮演最难搞的同事代码审查是模板收益最直接、最容易量化的场景。我写的审查模板.claude/commands/review.md会系统检查提交代码的多个维度并以表格形式输出结果。模板的核心是定义了审查的维度清单你是代码审查专家。审查用户提供的代码或变更按以下维度逐项评估并以表格输出列维度 / 评分 / 问题描述 / 建议 1. 正确性是否存在逻辑错误、并发问题、边界遗漏。 2. 安全是否有注入、敏感信息泄露、权限缺失、不安全的反序列化。 3. 性能是否有明显性能瓶颈、N1 查询、不必要的重复计算。 4. 可维护性命名是否表意、函数是否过长、职责是否单一。 5. 测试覆盖关键分支是否缺失测试测试断言是否有效。 6. 风格一致性是否符合项目已有的编码约定对照 CLAUDE.md 中的规则。 7. 潜在技术债是否存在可以简化但暂时没简化的写法给出理由。 最终输出必须包含一段总结如果评分低于 7 分明确给出必须修改才能合并的条目7 分以上也要给出至少一个改进建议。这个模板我用得最多因为它是纯只读操作不会改坏代码所以可以放心大胆地在任何规模的项目上跑。对大型 PR 而言它能快速覆盖一些人工容易漏掉的维度虽然不能替代人的判断但作为第一道过滤器非常趁手。3.5 提交信息与变更记录模板收尾工作的自动化很多人忽略提交信息也是一项值得模板化的任务。Claude Code 能通过git diff了解变更内容但默认生成的提交信息经常过于笼统不符合 Conventional Commits约定式提交规范。提交信息模板.claude/commands/commit.md做三件事读取 diff、归类变更类型、按规范生成提交信息。同时在最后会附上一份变更摘要方便直接用于 PR 描述。请根据 git diff如果没有提供自动执行 git diff --stat 和 git diff生成符合 Conventional Commits 规范的提交信息。 要求 - type 根据变更内容选择feat / fix / refactor / docs / test / chore / perf。 - 正文必须包含三个部分变更动机、具体变更内容、影响说明。 - 如果包含破坏性变更BREAKING CHANGE必须在 footer 中标注并说明迁移路径。 - 生成的提交信息控制在 10 行以内header 正文 footer每行不超过 72 字符。 - 变更摘要部分用自然语言概括本次 PR 的影响范围适合直接粘贴到 PR 描述。这类模板对个人项目可能用处不大但如果你在团队里工作提交信息的规范性能省下不少被同事点名修改 commit message的尴尬。4. 模板仓库的工程化落地从手写文件到标准化管理的完整流程有了模板内容之后还有一个工程问题如何管理这些模板文件、如何确保它们在不同项目之间复用、如何迭代升级。这一节把我的落地方式完整拆开讲。4.1 模板仓库的目录结构设计我的 claude-code-templates 仓库采用了如下结构claude-code-templates/ ├── README.md # 使用说明如何安装、如何自定义 ├── commands/ # 斜杠命令模板 │ ├── test.md │ ├── refactor.md │ ├── debug.md │ ├── review.md │ └── commit.md ├── CLAUDE.md # 项目级通用指令模板 └── CLAUDE.local.md.example # 个人配置的示例文件实际操作中我会把这个仓库 clone 到本地然后通过软链接方式把 commands 目录映射到各个项目的.claude/commands/位置这样改一处就能生效于所有项目。命令如下# 在项目根目录下执行 ln -s ~/projects/claude-code-templates/commands .claude/commands如果你不用软链接直接把文件复制过去也行但那样后续更新会很痛苦不建议。有一点要提醒.claude/commands这个目录是否提交到版本库取决于团队。如果团队希望共享这套规范提交进去完全合理如果只是个人习惯建议 gitignore 掉避免给队友制造噪音。4.2 写模板时最容易忽略的细节变量、引用和上下文长度斜杠命令不是纯静态文本Claude Code 支持在命令中引用上下文比如$INPUT代表用户输入$CLAUDE.md可以引用项目指令文件内容你也可以显式引用其他文件。合理使用这些能力能让模板的适用范围成倍扩大。我自己用得最多的引用技巧是在测试模板开头显式引用项目的测试配置文件确保 AI 知道当前项目的测试运行方式。比如请先阅读 tests/jest.config.js 了解当前项目的测试配置再按测试模板执行。在 Claude Code 中使用或$引用文件能直接把文件内容注入上下文。这样一来每个项目的测试风格即使有差异模板也能自适应不需要为每个项目单独维护一份。还有一个细节模板中关于输出格式的约束要具体到结构但不要到措辞。比如以表格输出列包含维度 / 评分 / 问题描述 / 建议是好的约束它会规范格式但如果写必须使用『问题分析』作为标题那是过度约束会让回复变得生硬反而丢失了自然语言的灵活性。4.3 模板的迭代基于真实使用日志做版本升级模板不是一次性写好的它需要随着使用不断迭代。我维护了一个简单的版本记录每次改动都有原因。这套 claude-code-templates 如果说有什么方法论层面的东西那可能就是把模板当代码一样维护有变更就用 git 记录有改进就发布新版本。我自己在迭代中主要依据三个来源使用后检查输出看 AI 有没有遗漏我关心的点查看 Claude Code 的会话记录统计哪些提醒我反复手动补充这些就是模板记忆缺口和团队其他使用者交流收集大家觉得AI 经常做不好的部分反向补充进模板。举一个实际的迭代例子测试模板最初只有生成用例的步骤后来我在使用中发现它生成的 mock 总是写得太理想化没有覆盖资源释放这个点。于是我在模板里加了一条所有涉及文件句柄、连接池、定时器的测试必须验证资源释放分支。 这个改进之后测试质量又上了一个台阶。5. 踩过的坑过度约束、命令滥用与团队协作问题模板体系用得好是杠杆用得不好也会带来新的问题。这一节把我踩过的几个有代表性的坑写出来帮你提前绕开。5.1 模板不是越细越好过度约束会让 AI 变成机器我在早期犯过一个很典型的错误为了让 AI 生成100% 符合团队规范的代码我把模板写成了一本操作手册每一步都规定得死死的。结果代码倒是规范了但出现了新的问题——AI 失去了灵活性遇到模板没覆盖到的情况时不会变通产出反而更差。举一个例子我在测试模板里规定了所有测试必须用 Jest 的describe三层嵌套但有一次需要给一个纯工具函数写单测三层嵌套明显冗余。AI 因为指令约束还是生成了两套嵌套造成了阅读负担。后来我把这类硬性约束改成了默认建议 允许判断的表述比如改为通常使用三层嵌套若被测函数逻辑简单允许用单层结构但需要在注释中说明理由。核心原则是模板要约束的是必须满足的目标和不能违反的底线而不是每一步怎么做。5.2 斜杠命令的滥用命令多了反而不知道用哪个我最初疯狂加命令代码生成、接口设计、架构评审、数据库迁移、文档编写……目录里塞了二十多个命令文件。结果每次打开终端我自己都要想一下该用哪个命令最终反而削弱了使用意愿。后来我做了减法只保留真正每周都会用到的五六个命令其他场景宁可现场写提示词。这个经历给我的启发是模板的覆盖面不是越全越好使用频率才是决定它价值的关键。如果你一个月都用不到一次的命令它存在的意义不大还可能和命令体系里其他文件形成干扰。5.3 团队协作时的模板来源管理同步、覆盖与信任问题如果你在团队里推广这套模板体系要注意一个比较隐蔽的问题每个人的.claude/commands里的模板可能版本不一致。A 改了一句指令B 那边没有同步两个人执行同一命令得到不同的行为这非常容易让人困惑。我现在的做法是模板仓库统一维护发布版本走 git tag各项目通过软链接或安装脚本固定到指定版本。每次模板更新后在群里发一条简短的变更说明让团队成员知道行为发生了哪些变化。信任问题才是最大问题——如果大家不确定模板的质量和更新原则他们会倾向于绕过模板直接手动编写提示词。所以模板的维护人要像维护开源项目一样用心编写文案、留下变更记录、听取反馈。5.4 模板互相冲突CLAUDE.md 与命令文件之间的矛盾最后是一个我自己磨合了一阵子才发现的坑当 CLAUDE.md 里的规范和斜杠命令模板里的指令冲突时Claude Code 会优先听从哪一个这没有标准答案取决于上下文顺序和具体表述。为了避免这种不确定性我给自己定了一条纪律全局规范只放原则具体任务流程一律放在命令模板里两者不建议描述同一个细节。举个例子不要在 CLAUDE.md 里写所有测试生成必须用 Jest 编写因为测试命令模板里肯定也会写。两条都存在时AI 可能会因为表述的微小差别产生行为偏移。整个模板体系内部的一致性比每一份模板单独的正确性重要得多。6. 从我自己的使用感受谈一谈模板让你的 AI 协作真正可积累说到底claude-code-templates 这个项目的价值不只是提供了一批好用的提示词而是提供了一种思路和 AI 协作的方式是可以被沉淀、被复用、被版本化的。最开始用 Claude Code我会觉得每次对话都是一次性的——用完就忘下次再从头交代。有了模板体系之后情况完全不同我对 AI 的要求、标准、流程都变成了仓库里可追溯的文件。今天发现 AI 在某个环节做得不好我改一行模板以后所有会话都受益。这种复利效应是模板给我带来的最大收益。我个人实际使用中的体会是真正值得模板化的不是那些你说得清楚的需求而是那些你经常忘记说清楚的事情。比如测试必须覆盖边界条件重构前先看影响范围提交信息要写清楚破坏性变更这些要求你在第一次对话里大概率会提到但每次都提又烦又累。把它们固化成模板AI 每次都能做到久而久之就变成了团队默认的工作习惯。如果你刚开始尝试我的建议是从一个最让你头疼的场景开始比如测试生成或代码审查写一份最简单的命令模板用一周改三版。这个过程会比你直接下载一百份别人的模板更有收获。毕竟模板的价值不在于数量而在于它是不是真的符合你的使用习惯。