1. 先搞清楚Claude Code的模板到底是个什么东西1.1 不只是一份提示词模板的三种形态先说个真实场景。我刚开始用Claude Code的时候每次处理代码审查都得打一大段中文来描述背景——这是某某项目的订单模块分支是feature/xxx请重点看并发扣减的问题输出格式要按严重程度分级……打完之后发现AI问出来的问题还是偏宽泛经常需要来回补充信息。后来我才意识到问题根本不在Claude本身而在于我每次都临时组织提示词等于让一个很有经验的同事反复听你讲一个他早该通过项目背景了解到的需求。所谓claude-code-templates简单讲就是给Claude Code准备的一批可复用的标准作业流程。它不是一份孤立的提示词而是由三种形态共同构成的体系CLAUDE.md文件这是Claude Code的长期记忆。放全局的~/.claude/CLAUDE.md里相当于给AI一份通用行为准则比如代码风格偏好、回复语气、默认技术栈放进具体项目的根目录则相当于项目专属手册比如目录结构说明、构建命令、常见坑位提醒。.claude/commands/目录斜杠命令这里放着的是快捷指令。每个Markdown文件对应一个斜杠命令比如/review、/refactor、/test在对话里输入就能触发一个预设好的完整工作流。这是提升效率最明显、也最值得花时间维护的部分。项目内CLAUDE.md与全局CLAUDE.md的配合全局管你是什么风格的工程师项目级管这个项目有哪些特殊性。两者叠加AI才能既懂你的习惯又懂手头的活。三种形态各有侧重但目标一致把那些你每次都要重复说一遍的背景规则输出要求沉淀成一次性的配置。之后每次调用AI都会自动带上这套上下文你只需要给出任务相关的参数省掉大量来回解释的时间。1.2 为什么模板化能显著提升效率和稳定性用生活化一点的类比你雇了一个聪明但刚入职的助手。如果你把公司制度、部门协作方式、项目背景文档都提前整理好放在他桌上你每次只需要说一句帮我把这份合同审一下他就能直接照着规范干活。这就是CLAUDE.md的作用。而模板slash command相当于你提前和助手约定了一套暗号——老规矩三个字他就知道要按哪几个步骤、拿什么标准、产出什么格式的结果。没有模板的时候同样这批活每次都要靠现场描述问题在于上下文浪费。Claude Code能看到的上下文token有限你每次花几百上千token交代背景留给实际代码分析的token就变少了。模板把这些背景提前固化在系统层面实际对话里只需要说重点。风格漂移。同样一个代码审查任务今天输出的格式和明天输出的格式可能完全不同。模板把输出结构固定下来比如按Bug严重程度分表每类附修复建议日拱一卒地迭代模板输出的稳定性会越来越高。入门成本高。如果你带新同事一起用Claude Code没有模板的话每人有一套自己的用法结果五花八门。把模板放在仓库里共享新人clone下来就能用团队产出立刻对齐。我自己统计过把常用任务模板化之后像重构一个函数为一个模块补测试生成规范提交信息这类活儿每次对话的往返次数从平均三四轮压缩到了一两轮整体耗时大概能省个四成。更关键的是输出格式基本稳定我拿到结果后只需要做信息核对而不是重新整理排版。2. 手把手搭建一套可复用的claude-code模板库2.1 先建好目录结构和命名规范搭模板库这件事听起来像是个大工程其实核心就两步建目录、写文件。以我目前比较顺手的一套结构为例大概长这样. ├── CLAUDE.md # 项目级说明放仓库根目录 ├── .claude/ │ ├── CLAUDE.md # 也可以把项目级说明放这里 │ └── commands/ │ ├── review.md # /review 代码审查 │ ├── refactor.md # /refactor 安全重构 │ ├── test.md # /test 测试生成与补充 │ ├── commit.md # /commit 生成提交信息 │ ├── changelog.md # /changelog 更新CHANGELOG │ └── explain.md # /explain 解释一段代码目录本身没有魔法关键是命名规范。我的习惯是命令名统一用动词开头、小写、不加下划线这样在对话里打斜杠命令时记忆成本最低。比如/review比/code_review_v2好记得多后面那些语义重复的东西在CLAUDE.md里配置就行不要在文件名上堆砌。另外建议从一开始就给每个模板文件加上YAML frontmatter。Claude Code读取斜杠命令时会通过frontmatter里的description字段来决定什么时候提示用户使用这个命令。这个字段写清楚之后比如对指定文件或当前分支做代码审查按严重程度输出问题清单AI会在合适的场景主动建议你使用它而不是等你手动触发。注意全局模板放在~/.claude/commands/下项目模板放在项目根的.claude/commands/下。同名的命令项目级会覆盖全局级。我实际用下来更推荐优先把模板放项目仓库里这样提交了之后所有协作者都能共享全局模板只保留那些跟具体项目无关的通用习惯。2.2 怎么写一个重要模板以代码审查模板为例空谈目录结构没意思我拿一个最常用的代码审查模板来拆解。这个命令的用途是让Claude Code对指定文件或当前分支的代码变更做结构化审查。文件内容如下以.claude/commands/review.md为例--- description: 对指定文件或当前分支做代码审查按严重程度输出问题清单与修复建议 argument-hint: 文件路径或分支名留空则审查当前分支 --- 你是一名经验丰富的代码审查者。请基于当前项目的CLAUDE.md背景对以下范围的代码变更进行审查。 审查范围{{$ARGUMENTS:当前分支的全部变更}} 请严格按以下步骤执行 1. 先罗列变更涉及的文件清单并判断每个文件的风险等级高/中/低。 2. 逐个文件审查重点检查 - 正确性边界条件、空指针、并发安全、事务边界 - 安全性输入校验、权限控制、敏感信息、依赖漏洞 - 性能不必要的循环、大对象分配、N1查询、缓存缺失 - 可维护性命名一致性、重复代码、遗留调试代码 3. 输出统一格式 - 总览变更规模、风险等级、是否建议合并 - 问题清单表格严重程度 | 文件 | 行号 | 问题描述 | 修复建议 - 优点摘要这次变更中值得肯定的2-3个点 约束 - 只报告真实存在的问题不为了凑数量而挑刺。 - 如果某个文件没有发现问题不要强行输出直接跳过。 - 不确定的问题标注需人工确认并给出判断依据。这里面的关键设计有三个。一是{{$ARGUMENTS}}变量它会把你在/review src/xxx.ts后面跟着的参数直接注入模板留空时则回退到当前分支这个默认值。这样同一个模板既能审查单个文件也能审查整个分支。二是步骤强制顺序化先列清单再逐文件审查最后统一输出——这一步是为了避免Claude漏看文件或者一上来就抓住一个边角问题猛输出。三是清晰的输出结构用表格收敛问题清单减少来回追问。写模板的时候我特别建议把约束单列一节。约束不是可有可无的话它是防止AI自由发挥的护栏。比如只报告真实存在的问题不凑数这条不加的话AI经常会给出一堆建议考虑优化此处逻辑这种正确的废话加了之后输出质量立刻提上来。2.3 模板里的变量与上下文注入技巧Claude Code的模板不止有$ARGUMENTS这一种变量实际可用的注入方式还挺灵活。以我的经验投入产出比最高的有这几种$ARGUMENTS接收斜杠命令后的参数适合传文件名、分支名、任务描述。$FILE:路径直接把某个文件内容读进来。比如写一个/review模板可以在开头加一句先读取{{$FILE:package.json}}里的依赖信息判断是否存在已知的高危版本让审查更贴合项目实际。~/.claude/CLAUDE.md 项目CLAUDE.md的上下文这些文件里的内容会自动进入Claude的上下文不需要在模板里重复写。所以像项目是微服务架构Python 3.12 FastAPI这种信息应该放在CLAUDE.md而不是塞进每个模板。工具调用结果模板里可以写指令让Claude先跑命令再分析比如先git diff HEAD~1 --stat拿变更概况再决定审查策略。实测下来这个先看全貌再动手的流程能显著降低漏审率。提示模板不是越复杂越好。一个模板如果超过一百行说明你在试图让AI同时干太多事拆成两三个更聚焦的模板效果反而更容易控制。我自己踩过的坑就是把重构测试更新文档塞进一个模板结果每次输出都顾此失彼后来拆成三个独立命令各干各的稳得很。3. 我实际用下来效果最明显的几类模板3.1 重构类模板只换不拆回归稳重构是所有任务里风险最容易失控的一类。人写代码有时候会顺手把逻辑也改了AI重构也经常出现类似问题——重构完看着好看但稍微改变了一点原有的行为。我的重构模板里最核心的一条约束就是只做结构变更不允许改变函数的行为和对外输出。模板里我按这样设计--- description: 对指定文件进行结构重构保持行为不变 argument-hint: 文件路径 --- 对 {{$ARGUMENTS}} 进行重构。 重构原则 1. 只改变代码结构与组织方式不改变任何对外行为。 2. 提取函数/变量时保持命名与当前语义一致不借机改名。 3. 重构完成后依次执行以下检查 - 对比重构前后的关键分支确认等价 - 使用项目现有的测试命令运行测试读取项目CLAUDE.md确定具体命令 - 如果有测试失败优先回滚对应改动不要试图通过改测试来适配代码。 输出 - 重构摘要涉及哪些函数、做了什么调整 - 等价性说明你如何确认行为没有被改变 - 建议测试清单需要人工重点回归的场景这个模板最大的好处是把重构的边界讲得明明白白。很多AI重构翻车不是因为技术不行而是因为不知道边界在哪。你告诉它允许改结构但不允许动行为它就会自觉地用提取函数、拆解条件表达式这类安全手法而不是自作主张把函数重写一遍。实际用下来经过这个模板处理过的改动测试通过率明显高于随手让他重构。3.2 测试生成模板先列边界再写用例让AI补测试最怕的不是它不会写而是它写出来的用例都是顺着实现逻辑编的快乐路径跑一遍全绿但拿去做变异测试全是漏网之鱼。我的测试模板里刻意设计了先分析、后编写的步骤--- description: 为目标函数生成完备的单元测试 argument-hint: 目标函数名或文件路径 --- 请为 {{$ARGUMENTS}} 生成单元测试。 前置分析这一步必须输出不要直接跳到写代码 1. 列出该函数的输入参数、返回值、依赖项。 2. 列出5种以上边界情况空输入、极值、异常类型、并发/重入、超时。 3. 明确每个用例期望断言什么防止只测不报错。 编写要求 - 使用项目现有的测试框架和风格参考项目CLAUDE.md。 - 每个用例单独一个test函数命名格式Test_函数名_场景。 - 不模拟当前函数所在的类/模块内部状态尽量依赖真实输入输出。 - 对私有函数的测试通过公开入口间接覆盖不要用反射/魔法手段。 完成后检查 - 运行测试确保全部通过。 - 如果某个边界条件因架构原因无法直接测试列出原因并给出建议。先列边界再写用例这个步骤极其关键。它逼着AI在动手之前先动脑把边界想清楚。不加这一步的时候它可能直接默不作声地按常规路径写五个用例交差加了之后它会先给你列一个边界清单其中往往有三四条是你自己都没想过的情况。这些边界清单本身就已经是有价值的测试设计产物了。3.3 常规小任务模板git提交信息、CHANGELOG、代码解释除了重型任务日常那些琐碎活也值得模板化虽然单个省不了多少时间但架不住频率高。我常用的三件套# /commit --- description: 根据当前git diff生成符合规范的提交信息 argument-hint: 可填一句话说明本次改动意图 --- 查看当前git diff和git diff --cached按以下规则生成提交信息 - 类型限定为 feat/fix/refactor/test/docs/chore/perf - 正文说明改动原因不重复代码本身做的事情重构了xx函数算重复不是原因 - 如果存在多个逻辑上独立的改动拆分成多条提交建议# /changelog --- description: 生成或更新CHANGELOG条目 argument-hint: 版本号如 v1.4.0 --- 基于最近的git log从上一个tag开始按conventional commits归类生成CHANGELOG段落并追加到CHANGELOG.md。 格式新增 / 变更 / 修复 / 性能优化 / 破坏性变更标注! 注意没有用户可见影响的重构不进入CHANGELOG。# /explain --- description: 用通俗的语言解释一段代码 argument-hint: 文件路径:行号范围 --- 解释 {{$ARGUMENTS}} 这段代码 1. 用一句话说清这段代码整体完成了什么。 2. 按执行顺序拆分解释主要逻辑分支。 3. 指出其中容易被误解的细节和隐式约定比如依赖了外部状态、有副作用。 4. 输出格式先总述再逐段说明最后风险与注意点。3.4 使用一个现成的claude-code-templates项目时该注意什么如果你从网上Clone了一个现成的claude-code-templates仓库我建议先做三件事而不是拿来就全都放进.claude/commands/里逐条审查CLAUDE.md内容。现成模板里的CLAUDE.md往往带作者的个人偏好比如所有代码注释必须用中文禁止使用ESLint disable这类规则。这些规则对你的项目不一定合适直接套用会让AI做出一些莫名其妙的事情。安全做法是把CLAUDE.md当成草稿按自己项目的实际情况增删条目。先跑通一个模板再批量启用。从仓库里挑一个最贴合需求的模板比如代码审查放进.claude/commands/里用一周感受一下输出质量再决定要不要引入其余模板。一次性引入二三十个模板对话时斜杠命令列表就变得臃肿AI也容易糊涂。注意模板里是否有网络请求或shell命令。有些模板会引导Claude去执行特定脚本或请求外部接口。这类模板如果带入了不安全的内容等于让AI替你在终端里执行了潜在风险操作。我的原则是凡是涉及执行命令的模板必须逐行理解它在干什么。4. 模板编写过程中常见的坑和排查方法4.1 常见问题速查表模板用久了遇到的问题其实有很强的规律性。我把常见异常整理成了一张速查表方便对照排查现象可能原因排查与解法斜杠命令没有出现在提示里frontmatter的description缺失或不清晰检查文件头部YAML确保有description字段确认文件在后缀为.md位置正确模板里的命令与项目级CLAUDE.md重复定义全局和项目配置冲突明确优先级项目级覆盖全局级删除重复条目或拆分职责模板执行时忽略中间输出步骤直接给结论步骤描述不够强AI认为可以跳过中间态把每个步骤的要求改成必须输出以下内容...未输出前不要进入下一步$ARGUMENTS传了内容但模板没有识别参数含特殊字符或带空格没有加引号传参时用引号包围路径如/review src/utils/parse.ts或在模板里用eval风格解析多参数模板输出风格和预期差异大模板少了输出格式约束在模板里直接给出输出必须包含以下几节并配一个示例结构模板太大导致上下文被占满单个模板行数过多拆分模板或者把公共背景移到CLAUDE.md不要堆在命令里团队其他人同步模板后不生效文件缓存或Claude Code版本差异确认Claude Code版本一致重启会话检查.claude/commands/路径大小写4.2 模板和CLAUDE.md的平衡别把什么都塞进模板一开始我犯过最大的错误就是想给所有事情都做模板——小的如写一行注释大的如从零搭建一个新服务恨不得全部模板化。实际做了两三个星期之后发现维护成本高得离谱因为每次微调思路都要改一堆文件而且模板本身的自相矛盾也开始出现。比如A模板里写着代码风格遵循Google Java StyleB模板里又说方法命名用camelCase虽然不直接冲突但总归是重复维护。到后面我总结出一个比较舒服的分配原则CLAUDE.md只放不变的事实技术栈、目录结构、命令、代码风格、项目约定。它回答的是这个项目是什么样的。命令模板只放可复用的流程审查要分几步、测试要覆盖哪些边界、提交信息按什么规范写。它回答的是这类任务怎么做。如果一个信息既跟项目有关又跟流程有关优先放CLAUDE.md模板里用一句话引用即可。这样改项目信息时只动一个文件不会连带把一坨模板全部改一遍。这条原则也治好了我看见什么都想模板化的手痒。4.3 模板的版本管理模板也需要纳入git模板这东西最容易出现的情况是改完就忘了改到第四版发现还是第二版好但已经回不去了。所以我强烈建议把所有模板连同CLAUDE.md放进版本管理并且在你每个阶段对模板做了重大调整后把当时的整套配置打一个tag比如templates-v2。这样后续换电脑、带新人、回退实验都是一两分钟的事。另外如果团队里有多人共用一套模板我建议在仓库里加一个TEMPLATE_README.md写清楚每个模板的适用场景、作者和最后一位修改人避免出现上一个同事改的模板还没告诉我我又在他的基础上改了一遍这种情况。别小看这个文档团队协作时模板的磨损率和代码仓库一样都遵循没人维护的东西早晚腐化的规律。5. 让模板持续进化的个人经验5.1 从实际任务中反推模板而不是凭空设计我搭建模板库最有效的方式不是坐下来一口气写十个模板而是把现实中重复第三遍的对话变成模板。具体操作是当我在Claude Code里就同一类任务连续手动输入了三次相似的指令之后就直接把刚才用的那段对话整理成命令模板顺手把这次新踩到的边界条件加进去。这种事后沉淀的模板往往比凭空设计的模板更贴合真实需求因为它是从实际摩擦中长出来的。比如上面提到的测试模板我就是在给一个老项目的工具函数补测试时反复踩快乐路径的坑之后沉淀出来的。那次经历让我意识到让AI先输出边界清单再动笔写代码比任何花哨的指令都管用。5.2 定期复盘和精简模板贵精不贵多模板也应该有季度复盘的概念。我现在每隔一两个月会把.claude/commands/里的文件逐个过一遍问自己三个问题这个模板最近一个月用了几次里面的约束是否需要因为新踩的坑而更新这个模板有没有和别的模板内容重复回答的过程实际上就是去芜存菁。有些模板写的时候觉得巧回头一看纯属炫技比如那种嵌套了七八个变量的极简生成器模板看着酷但用起来维护成本极高。我现在的原则是一个模板如果连续一个月用不到三次就考虑删掉或者合并绝不让模板数量变成自我的慰藉。曾经有一版我的commands目录下有二十多个命令精简到十二个左右之后反而每个命令的质量和命中率都上去了。5.3 团队协作时怎么共享模板如果只有自己一个人用Claude Code那模板怎么写都行。但一旦团队协作模板的共享方式就变成了一种契约管理。我的建议是把模板目录放在项目仓库里而不是个人全局目录里然后通过Pull Request流程来修改模板。这样每一条对CLAUDE.md或commands的变更都能被review不会出现某个成员的私有习惯突然改变所有人的AI行为。团队里不同成员对模板质量的要求还不一样有人喜欢超详细的保姆级模板有人喜欢一句话带过的轻量模板。折中做法是只保留一套标准模板但是在CLAUDE.md里用严格模式/灵活模式做一个switch开关各取所需。当然这个开关实际上也是一个约定性描述不会真的触发什么逻辑分支但实测下来给AI写清楚不同情境下要按不同严格程度行事输出会更贴近每个个体想要的节奏。最后分享一个我最近在用的组合拳每天早上上班我打开Claude Code先跑一个自己写的/standup模板这个模板会自动结合最近的git log和TODO文件生成一份符合团队格式的晨会总结。不到三十秒比我自己敲字快多了而且每天格式统一领导看着也舒服。这就是模板的日常威力。回头看那些觉得写模板太麻烦的日子其实不是写模板麻烦而是还没碰到一个值得反复做三次以上的任务。一旦碰上了把这个任务沉淀成模板它的事后回报会远远超出当时那几分钟的整理成本。