最近我把 Claude Code 从一个“偶尔惊艳的演示工具”真正用成了每天离不开的编程搭档，越是用得狠，我越明白一件事：效率的瓶颈从来不在模型本身，而在你如何把一套稳定的工作方式固化下来。为此我折腾了一套自己的 claude-code-templates 模板体系，把高频操作、项目规范、复杂任务说明书全部沉淀成文件，让 Claude 每次接手项目的时候，都能按照同一套标准输出，而不是每次靠临时对话碰运气。
这套东西解决的是三个很具体的问题：第一，同一仓库多人协作时，Claude 的表现能保持一致，不会因为谁的提示词写得详细就输出得好；第二，重复性工作不用每次重写长篇提示词，敲一个斜杠命令就能触发；第三，新加入项目的人也能直接获得一套成熟的工作流。如果你正在用 Claude Code 写代码、做代码审查或者维护一个中型以上的仓库，这篇内容应该能帮你在短时间内把它的输出质量和稳定性提升一个档次。
1. 为什么要有一套 Claude Code 模板体系
1.1 从一次性惊艳到稳定复现
先讲我自己的经历。第一次用 Claude Code 的时候，我让它重构一个老模块，它给出的方案干净利落，连我犹豫了很久的依赖问题都顺手解决了，那一刻确实很惊艳。但第二次、第三次让它做类似的事情时，我发现输出质量是明显波动的。有时候它能记住项目里约定俗成的命名方式，有时候它又会凭空造出一些风格完全不一致的代码；同一个审查任务，上一条消息它还严格按严重程度分级，下一条就变成了一段笼统的总结。
问题出在哪？Claude Code 虽然有很强的上下文能力，但每次会话对项目规则的理解，取决于它在上下文里看到了什么，以及你临时说了什么。用户层面每次说的话可能不一样，项目里也没有一个固定的规则文档去告诉它应该按照什么标准工作，于是输出就靠运气。
解决这个问题的思路，不是要求自己每次写提示词都写得无限详细，而是把工作方式沉淀成模板。所谓 claude-code-templates，本质上是把人类团队里的制度与 SOP 翻译成 Claude 能稳定读取的文件。项目规范写进 CLAUDE.md，高频动作做成斜杠命令，复杂任务做成任务说明书，这就是模板体系的底层逻辑。
1.2 模板体系三大件：CLAUDE.md、斜杠命令、任务说明书
我把它拆成三个层次，对应不同的使用场景和稳定程度，也对应不同的维护方式。
| 模板类型 | 存放位置 | 作用 | 稳定性 |
|---|---|---|---|
| CLAUDE.md | 项目根目录 | 定义项目规范、常用命令、代码风格 | 每次会话自动加载，最稳定 |
| 斜杠命令 | .claude/commands/ 目录 | 把固定动作变成一句话快捷指令，支持参数传递 | 手动触发，配合上下文时极高 |
| 任务说明书 | 任意 md 文件，或命令内嵌长 Prompt | 针对复杂任务的完整工作流定义 | 取决于引用方式，适合大任务 |
CLAUDE.md 是地基，它告诉 Claude 这个项目是什么、有哪些约定、运行命令是什么。这部分放在项目根目录，无论谁打开项目，无论哪次新开会话，Claude 都会自动带上这些规则。我习惯把它当成一份入职培训手册来写，新员工第一天看的培训和它要达成的效果是一样的。
斜杠命令则是把高频动作固化成“按钮”，类似你在编辑器里设置的代码片段。比如 /review 触发代码审查，/test 生成测试用例，/refactor 对指定范围做重构。命令文件里可以写完整的 Prompt 流程，还能通过参数传入指定文件或范围，实际用起来比每次手敲一大段要求要可靠得多。
任务说明书是更高层的设计，适合处理需要多阶段判断的任务，比如“从需求描述到输出一整套项目初始化代码”，或者“全仓库错误处理模式统一整改”。这类任务单靠一句话提示词容易失控，我会把它写成结构化文档，然后通过斜杠命令或直接告诉 Claude 读取对应文件来触发。
2. 模板设计原则与关键技术点
2.1 CLAUDE.md：让规则长在项目里
CLAUDE.md 是 Claude Code 的项目级记忆文件，项目根目录下放一个，每次会话启动自动读取。我第一次用的时候只在里面写了项目一句话简介，后来发现这远远不够，真正生效的规则要具体到能让模型直接执行的程度。
我现在的写法是分块组织：项目概述、常用命令、代码风格、工作流程、注意事项。每一块都用简短、祈使句式的描述，不要让它去做阅读理解。比如不要写“本项目的代码风格较为现代，希望在修改时注意保持风格统一”，而应该写“禁止使用 any，所有类型必须显式声明”。前者是模糊期望，后者是可执行约束。
更新机制也踩过坑。最初我把规则写得太满，塞了几十条，结果 Claude 反而抓不住重点。后来我按“真正会影响输出结果”的规则来筛选，一个文件控制在 20 条以内，每一条都要能直接指导行为。规则之间绝不能矛盾，比如前面说“优先复用现有模块”，后面又说“公共方法统一放 src/utils”，如果两个说法暗示的是不同做法，模型就会无所适从。
另外一个很实用的小技巧是：我会在 CLAUDE.md 里增加一条“如果发现更优的项目约定，请在任务收尾时建议更新本文件”。这个小技巧会让它在完成任务后主动提醒你哪些规则该新增、哪些写错了。相当于让模板拥有了自我进化的能力，而不是完全靠人肉维护。
2.2 斜杠命令：把高频操作变成一句话
斜杠命令的机制很直接，在项目根目录的 .claude/commands/ 文件夹里放一个 markdown 文件，文件名对应命令名。review.md 对应 /review，内容就是希望 Claude 执行的 Prompt。命令文件支持参数引用，也支持通过目录层级实现子命令，比如 review/security.md 对应 /review/security。
我常用的是 /review、/test、/refactor、/doc 这四个，但我真正花心思设计的不是命令名字，而是命令文件里的那一大段 Prompt。这里有一个通用结构：先定义角色和执行边界，然后给出一套分步流程，最后写清楚输出格式和验收标准。
拿 /review 举例，我不希望 Claude 随口夸两句“代码看起来不错”就完事，所以模板里明确规定了：先通读结构，再按严重、一般、优化三个等级列出问题，每个问题必须附具体修改建议和代码片段，最后给出一个可执行的结论。这套流程基本是照着最严格的人工 Code Review 流程设计的。实测下来，带上这套模板之后，审查结果的可用性提升非常明显，从“看过一遍但说不出所以然”直接变成“每条意见都定位到问题和修改方案”。
命令参数方面，文件里可以用 $ARGUMENTS 引用用户输入的内容。比如我输入 /review src/utils/format.ts，后面的路径会作为参数被塞进 Prompt。参数里有空格时记得加引号，这是一个很小的细节，却经常导致命令实际执行范围与预期不符。
2.3 复杂任务模板：给 Agent 一张“任务说明书”
有些任务光靠一两条命令描述不清楚，比如“为这个仓库补充完整的单元测试策略并落地首批用例”，这涉及测试框架选择、用例分层、mock 策略、覆盖率要求，还可能要把结果写回多个文件。这时候我会单独写一份任务说明书，然后让 Claude 去读取它。
任务说明书的核心结构是：背景和目标、输入材料范围、执行步骤、输出产物、验收标准。背景和目标解决“为什么要做”，输入材料范围解决“从哪里开始”，执行步骤解决“按什么顺序做”，输出产物解决“做完之后交什么东西”，验收标准解决“怎么才算合格”。
验收标准值得单独强调。很多人在日常对话里让 Claude 干活，等它跑完才发现结果根本不是想要的样子，根本原因是没写清楚完成标准。写验收标准时要用可检查的语句，比如“所有测试文件必须能通过 npx jest --runInBand 执行”“不允许在业务组件中出现硬编码的中文文案”。这种标准越具体，它在过程中就越容易自我纠偏，而不是等做完之后再由人来返工。
3. 从零搭建一套可复用的 Claude Code 模板
下面给出一套可以照抄的落地流程，都是我在真实项目里验证过的。如果你要复现，建议先找一个自己熟悉的中小型仓库练手，不要一上来就套在最复杂的项目上。
3.1 先搭好目录结构
先在项目根目录建立目录结构。注意 .claude 目录本身就是隐藏目录，正常情况下你的 git 仓库也会把它纳入版本管理，这样团队里的所有人都能共享：
project-root/ ├── .claude/ │ └── commands/ │ ├── review.md │ ├── test.md │ ├── refactor.md │ ├── doc.md │ └── review/ │ └── security.md ├── CLAUDE.md └── claude-templates/ ├── task-new-module.md └── task-error-pattern.md.claude/commands/ 目录里装的是斜杠命令；CLAUDE.md 放在项目根目录；claude-templates/ 是我自己约定的目录名，用来放复杂任务说明书，你也可以换名字，只要每次引用时路径一致就行。
一个小细节值得提醒：文件名就是命令名，尽量用短命名，比如 review 而不是 code-review-process-v1。真正长的内容放在文件内部，不要体现在文件名上。命令一旦发布，改名会影响团队的使用习惯，所以起名要克制。
3.2 写一份高质量的 CLAUDE.md
下面这份是我为一个偏 Node.js 的 B 端项目写的精简版，你可以对照改成自己的版本：
# Project: admin-web ## 项目概述 admin-web 是一个基于 Next.js 14 + TypeScript 的 B 端后台管理界面，使用 antd 作为组件库，状态管理使用 zustand。 ## 常用命令 - 启动开发：npm run dev - 运行测试：npm test -- --watch - 静态检查：npm run lint - 构建产物：npm run build ## 代码风格约定 - 组件文件一律使用 PascalCase 命名。 - 禁止使用 any，未知类型用 unknown 并做类型收窄。 - API 请求统一走 src/api 下封装好的 fetch 方法，禁止在组件内直接写 fetch。 - 表格列配置统一抽取为 const columns，放在组件文件同目录的 columns.ts 中。 - 错误提示统一使用 antd 的 message，不使用 window.alert。 ## 工作流程 - 修改已有组件前，先查看该组件目录下的 __tests__ 测试文件，保持测试策略一致。 - 新业务模块默认按页面目录为粒度组织，逻辑复杂时抽 hooks。 ## 注意事项 - 不要修改 ESLint 和 TypeScript 配置文件，如有需要先与负责人确认。 - 数据库字段的枚举值以服务端返回的 type 定义为准，不要在前端自行猜测。 - 如果发现更优的项目约定，在任务收尾时建议更新本文档。这份文件的写法有几个原则必须把握：命令是明确的，风格是可执行的，范围是收敛的。不写“尽量”“通常”这类模糊词，每条规则都要能直接判断对错。比如“命名用 PascalCase”这句话在审查代码时可以被自动校验，但“保持风格统一”不能被校验。
3.3 落地一个斜杠命令
斜杠命令的写法同样不复杂，关键是流程结构。我的 review.md 里放的是这样的内容：
你是一名资深代码审查者。请按以下流程审查用户指定的代码范围： 1. 先通读相关文件，用 3-5 句话概括模块的职责与结构。 2. 按以下等级逐条列出发现的问题： - 严重：可能导致线上事故、数据错误、安全问题或明显的性能瓶颈。 - 一般：边界情况未处理、错误处理缺失、与项目规范不一致。 - 优化：可读性、命名、微性能提升建议。 3. 对每个问题必须给出： - 问题位置（文件与行号区间） - 具体问题说明 - 修改建议，需要时附上代码片段 4. 最后输出结论：建议合并、修改后合并、或返工重写，并列出必改项清单。 审查范围：$ARGUMENTS这里最核心的是第 2 和第 3 条，它们保证了输出不是空洞的赞美或笼统批评，而是直接可以用于修改的逐条意见。实际使用时，我会输入类似 /review src/utils/format.ts src/utils/date.ts 这样的命令，$ARGUMENTS 就会把两个路径都塞进去。
/test 命令模板我通常这样设计：让 Claude 先读取目标文件的依赖关系和已有测试约定，再按基础功能、边界条件、异常输入三个维度生成测试用例，并确保测试通过。重点是要让它遵循项目原有的测试框架和命名习惯，而不是另起炉灶。每个命令的 Prompt 不必过长，但必须把这个“先读约定、再执行任务、最后自检”的闭环写进去。
3.4 用 MCP 把模板和工具链打通
模板本身是纯文本指令，真正让它发挥十倍效果的是和 MCP（Model Context Protocol）结合。MCP 可以理解成让 Claude Code 在执行模板流程时额外具备读取文件、查数据库、拉取远程仓库信息等外部工具能力，把模板从“口头要求”变成“带工具链的完整工作流”。
比如写 /review 命令时，如果想让审查结果更准确，可以在模板开头加一句“先通过 MCP 工具读取该模块的依赖关系，分析影响面”，再挂一个能解析代码图谱的 MCP server。这样它就不只是盯着你给的那几个文件看，而是能看到整条依赖链上的关联模块，审查深度立刻不一样。
同理，在任务说明书里可以指定“使用 MCP 的 git 工具查看最近三次提交记录，总结变更风格”，让模板执行的依据从单次会话的上下文，扩展到真实仓库的历史信息。这个设计思路值得专门去试，但要注意一点：模板里引用的 MCP 工具调用方式要简洁明确，别写成开放式的“随意调用”，否则模型容易把大量时间花在反复切换工具上。
4. 常见问题与排查技巧实录
模板体系的搭建不是一次就能成功的，我自己就反复调整过很多轮。下面把高频问题整理成一张表格，方便你对照排查，后面再分享几个长期受益的实测技巧。
4.1 高频问题速查表
| 现象 | 可能原因 | 解决方法 |
|---|---|---|
| 斜杠命令不被识别 | 文件没有放在 .claude/commands/ 下，或扩展名是 .markdown | 统一使用 .md 扩展名，检查目录是否在项目根 |
| CLAUDE.md 不生效 | 放错了目录层级，或文件里规则太模糊 | 放到项目根目录，规则改成可执行祈使句 |
| $ARGUMENTS 传参异常 | 参数中包含空格，或子命令目录结构不对 | 给含空格的路径加引号，子命令靠目录层级实现 |
| 规则互相冲突 | 模板文件多，前后规则矛盾或冗余 | 每个文件只负责一类职责，定期合并审查模板本体 |
| 输出总是长篇大论 | 模板里没有输出格式限制 | 在模板末尾写明“输出控制在 N 项、每条附一句建议” |
| 命令引用了不存在的工具 | 模板里写了未配置的 MCP 工具或错误路径 | 先在单独会话验证工具可用性，再写入模板 |
这张表背后反映的规律是：绝大多数模板失效，不是模型能力问题，而是模板写得不精确、路径不对、约束不清晰。调试模板最好的方式，是把它当成一段代码那样反复跑、反复看输出、反复修改。我至今仍然每隔两周就会回头看一眼命令文件里有没有过时的描述。
4.2 三个值得长期坚持的避坑习惯
第一个习惯，命令文件要“外短内长”。命令名短，命令文件内容长。命令短是为了让使用者输入成本低，内容长是为了让 Claude 执行时信息足够。别把命令名做成十几个字母的全拼组合，团队根本记不住，最后这条命令就会被冷落。
第二个习惯，每次任务结束都做一次“模板回写”。因为我在 CLAUDE.md 里写上了那条“发现更优约定时建议更新”的提示，所以 Claude 在任务结尾经常会给出模板更新建议。这时候我会手动确认，把它说得对的那几条合并进模板。模板不是静态文档，应该像代码库一样持续迭代。刚开始的时候我很少这么做，导致很多有价值的规则流失在对话历史里，非常可惜。
第三个习惯，给模板加验收门槛。无论是斜杠命令还是任务说明书，最后一步都写上“执行结束后，先对照验收标准逐项自检，再输出结果”。这一步看着轻量，但对输出质量的改善是决定性的。实测中 Claude 在自检后经常自己发现问题并修正，这比事后由你返工要省力得多。
这些习惯不仅适用于个人，当你准备把模板推广到整个团队时，还有几个更关键的节奏问题需要注意。
5. 模板的团队落地与持续演进
5.1 先跑通单人流程，再同步给团队
我见过不少团队拿到新人 AI 工具后，第一反应就是全员推广，结果两周后除了个别人还在用，其他人早就放弃了。根子在于大家的使用场景、习惯、对输出的要求都不一样，你喜欢的模板未必适合所有人。
我的建议是先在个人高频场景里把流程跑通。也就是你自己先连续使用一个星期，把经常用的命令、CLAUDE.md 规则、任务说明书打磨到稳定状态，再挑两三个关系好的同事试用。等他们在自己场景里验证了效果，后面的推广就是自然发生的，而不是被要求发生的。
5.2 用样板仓库沉淀模板资产
模板在不同项目间有大量可复用的部分，比如代码风格约定、测试策略、审查流程。我建了一个内部样板仓库，专门存放跨项目通用的 CLAUDE.md 片段、斜杠命令文件、任务说明书模板。新项目初始化时，从样板仓库复制目录结构，再按项目特性改掉个性化部分，整个模板体系十分钟就能搭起来。
同步方式可以选择最顺手的一种：直接复制、脚本拉取、或者作为 git submodule 引用。重要的是区分通用部分和项目部分。通用模板里只保留跨项目规则，比如 TypeScript 严格模式、提交信息规范这类覆盖绝大多数仓库的约定；项目特有内容留在各自仓库的 CLAUDE.md 里。你会发现这个边界一旦划清，维护成本会大幅下降。
5.3 给团队讲清楚模板的“为什么”
团队落地时最容易犯的错误，是只告诉大家“有这个命令，用就完事”，却不解释为什么模板要这样设计。后果就是，一旦模板和实际场景出现偏差，没有人敢改，因为不懂背后的逻辑。
我在分享模板时通常做一次很小的演示：先不使用模板直接让 Claude 总结一个模块，再使用模板跑同一任务，让对比在团队成员面前自然发生。不用过多解释，差异本身就是最好的说明。同时我会鼓励每个成员往模板仓库提交自己的命令想法，而不是由某个人垄断模板的维护权。模板是大家的协作产物，它的生命力来自持续的更新与讨论。
我们内部会定期 review 模板文件本身，就像 review 普通代码一样。一条命令如果连续一个月没有人用，就删掉或者重构。CLAUDE.md 里的规则如果开始互相矛盾，就当场讨论去留。定期清理的必要性被大多数人低估了，没有清理机制，模板仓库迟早变成一个补丁摞补丁的遗留工程。
最后说一点我自己的真实体会。折腾这套 claude-code-templates 模板体系，最让我有成就感的不是某一次命令用得顺手，而是团队使用 Claude Code 的方式逐渐被统一了。新人进入项目之后，不需要我在旁边不停补充背景，他们只需要敲一个 /review，Claude 就会按照项目里最严格的那套标准去工作。模板是安静的，但它是把 AI 能力从偶然的惊喜变成稳定生产力最实在的抓手。如果你也想搭建自己的模板，我的建议很简单：不要想一步到位，先从一条命令、一份 CLAUDE.md 开始，跑一周，再根据真实输出反推迭代，它很快就会长出适合你自己的形状。
