干活久了你会发现真正拉开效率差距的不是工具本身而是你给工具配的“使用手册”。Claude Code 这类终端里的 AI 编程助手能力很强但大多数人打开终端就开始对话项目背景、代码规范、工具链信息全靠现场口头交代几轮下来上下文就乱了生成的东西总差那么一口气。后来我系统性地给 Claude Code 搭了一套 templates也就是可复用的提示词模板和配置文件体系效果完全不同。这篇就聊聊我搭建 claude-code-templates 的完整思路、核心模板类型、实操步骤和踩过的那些坑。1. 为什么要给 Claude Code 搭建模板体系1.1 模板能力到底指什么先说清楚一个容易混淆的概念Claude Code 的 templates 不是一个单独的功能按钮而是散布在工具各处的自定义机制的总称。按官方能力和社区实践它至少包含四种形态CLAUDE.md 文件这是 Claude Code 的“长期记忆”放在项目根目录或全局配置目录下每次会话开始时会自动被读取用来注入项目背景、技术栈、代码规范、常用命令等核心上下文。自定义斜杠命令通过.claude/commands/目录下的 Markdown 文件定义比如/commit、/review、/test把固定的操作流程固化下来一句话就能触发一整套完整指令。Hooks 钩子在工具执行特定事件如调用 Bash、读取文件、编辑代码前后触发自定义脚本本质上是“事件驱动的自动化模板”。Agents 子代理通过.claude/agents/目录配置带有独立身份和权限的子任务代理相当于为不同类型工作预设“专属员工”。这四类东西合在一起才构成完整的模板体系。单一依赖 CLAUDE.md 远远不够尤其是当项目复杂度上来之后命令模板和 hooks 的价值会迅速超过单纯的记忆文件。1.2 没有模板体系时我遇到的实际痛点我在搭建这套模板之前几乎每个项目都处于“每次从零说明”的状态。最典型的问题有三个第一上下文重复劳动。每开一个新会话都要重新告诉 Claude 这个项目是什么技术栈、启动命令是什么、测试怎么跑、代码规范有哪些。短会话还好项目一多一天可能要重复输入十几次同样的背景信息浪费大量 token 和时间。第二输出风格不稳定。同样是生成一段提交信息有时候 Claude 按 Conventional Commits 格式写有时候又写成一句话尤其在模型更新后行为漂移明显。没有模板固定规则可复现性无从谈起。第三危险操作缺少刹车。让 Claude 直接跑命令是常态但没配 hooks 之前它可能会尝试执行一些影响面很大的操作比如未经确认就git push --force或者删掉 node_modules 之后重新安装却不知道项目有特殊安装脚本。这些问题在添加适当的 hooks 检查后能大幅减少。提示模板的价值本质上是“把人类团队里的 onboarding 文档和团队规范编译成 AI 能消费的格式”。你越是把 Claude Code 当正式成员用就越需要给它正经的入职文档和操作手册。2. 模板体系的整体设计思路2.1 三层结构全局、项目、任务级搭建模板体系的第一件事不是写模板而是想清楚模板怎么分层。我目前使用的是三层结构所有模板文件都严格对号入座层级存放位置作用范围典型内容全局层~/.claude/CLAUDE.md所有项目所有会话通用编码偏好、安全红线、默认工作流项目层项目根目录/CLAUDE.md当前项目项目背景、技术栈、目录结构、构建测试命令任务层.claude/commands/、.claude/agents/按需触发写作规范、审查流程、子任务代理配置为什么要分层核心原因在于上下文精力的有限性。Claude Code 的上下文窗口虽然大但塞入过多无关内容反而会稀释注意力影响关键信息的权重。全局层解决“所有项目通用”的问题项目层解决“这个项目特有”的问题任务层解决“此刻这个任务”的问题三者互补但不重叠这是模板体系能长期稳定的关键。举个例子我全局 CLAUDE.md 里有一条“未经确认不得执行 git push --force”这是所有项目都适用的安全红线项目层 CLAUDE.md 里写“本项目数据库迁移使用 Prisma禁止直接修改 SQL 文件”这是这个项目特有的规则任务层/commit命令只管提交信息格式不涉及项目背景。这样划分之后每一层的信息量都保持精简Claude 能在第一时间抓住关键指令。2.2 模板的原子化拆分原则第二件重要的事是模板不要都写成大而全的“巨型提示词”。我的做法是像拆代码一样拆模板坚持原子化 引用组合两个原则。所谓原子化就是每个命令模板、每段 CLAUDE.md 只负责一件事。比如代码审查模板只写审查标准和检查清单不掺入提交规范提交规范单独拆成一个命令模板。这样做的好处是便于复用和迭代——项目 A 的 CLAUDE.md 里的代码规范段落可以直接挪到项目 B而不用连带一堆无关内容复制过去。所谓引用组合就是在模板里通过文件路径语法引用其他文档把原子化内容组装成更复杂的流程。Claude Code 支持在提示词中用符号引用项目内文件这个特性可以让你把公共规范拆到独立的docs/engineering-guide.md然后在 CLAUDE.md 里只写一行docs/engineering-guide.md完成引用既保持主文件清爽又保证规范内容被完整读取。这套设计思路的底层逻辑和写程序时“高内聚低耦合”是一模一样的。全局修改规范时只改一处引用它的地方自动生效不用满项目去找哪里写了旧条目。3. 核心模板类型解析与实操细节3.1 CLAUDE.md 项目记忆模板CLAUDE.md 是整个模板体系的基石也是配置收益最高的一层。很多人以为它就是写一段项目介绍其实完全不够一份能真正提升 AI 输出质量的 CLAUDE.md 至少应该覆盖以下几个模块。首先是项目身份信息包括项目名称、一句话定位、当前开发阶段。这段不是废话它帮助 Claude 在输出时校准语气和范围避免回答偏离项目定位。其次是技术栈与架构约束要写明关键框架、语言版本、状态管理方案、数据流向、目录结构规范。比如一个 Next.js 项目要明确 App Router 还是 Pages Router、服务端组件默认还是客户端组件默认、样系列用 Tailwind 还是 CSS Modules——这些决策直接决定了 Claude 生成的代码能不能直接跑。再次是命令速查表包括启动、测试、构建、Lint、迁移等常用命令。写清楚命令Claude 就不用在生成代码后瞎猜“怎么运行”而是主动按照你规定的命令来验证。最后是领域规则与禁用事项。这部分最容易被人忽略但价值极大。比如测试模板项目里可以写“所有新增函数必须附带至少一个单元测试”“禁止在生产代码中使用 console.log 排查问题”这样的硬约束一个处理用户资金的仓库里则要写“所有金额运算必须使用 Decimal禁止浮点数直接计算”。这里分享一个我的写法模板直接可以复制改改用# 项目身份 - 项目名称{{PROJECT_NAME}} - 技术栈{{TECH_STACK}} - 最近状态{{RECENT_STATUS}} # 架构约束 - 数据库PostgreSQL通过 Prisma 访问禁止手写 SQL - 前端状态React Query 局部 useState不引入 Redux - 样式方案Tailwind CSS禁止写全局 CSS 覆盖 # 常用命令 - 本地启动npm run dev - 完整测试npm run test - 单独测试npx jest src/xxx - Lint 检查npm run lint # 硬性规则 - 所有时间数据统一存储为 UTC展示时再转时区 - 后端接口一律使用 RESTful 命名禁止自定义动词式 URL - 新依赖必须先说明必要性未经确认不得自行安装3.2 自定义斜杠命令模板.claude/commands/目录下的命令模板是我日常使用频率最高的部分。每个 Markdown 文件就是一个命令文件名去掉.md就是斜杠命令名。执行时会自动读取文件内容作为系统提示词你可以用$ARGUMENTS接收用户输入。下面是我现在一直在用的几个命令模板每个都是从实际需求里长出来的。第一个是/commit生成符合规范的提交信息。这个模板直接解决了我之前提交信息风格漂移的问题--- description: 生成符合 Conventional Commits 规范的提交信息 --- 根据当前 git diff 生成一条提交信息要求 1. 使用 Conventional Commits 格式feat/fix/docs/style/refactor/test/chore 2. 第一行控制在 72 个字符内 3. 正文简述变更内容、影响范围、新增测试 4. 如果 diff 里涉及 breaking change必须在说明中标注 BREAKING CHANGE第二个是/review执行代码审查。这个模板的价值在于把审查清单固化下来不会因为模型状态波动而漏项--- description: 对指定文件或当前分支的改动进行代码审查 --- 审查范围$ARGUMENTS 审查清单 1. 逻辑正确性边界条件、异常分支、并发安全 2. 安全风险注入、越权、敏感信息泄漏 3. 性能不必要的重复计算、N1 查询、大对象传递 4. 可维护性命名清晰、函数单一职责、无重复代码 输出要求按严重程度分 P0/P1/P2 列出问题每条给出修改建议和示例代码。第三个是/test为指定代码生成测试。配合项目的硬性规则使用--- description: 为指定文件生成单元测试 --- 为目标文件生成单元测试 - 测试框架Jest - 覆盖维度正常路径、边界值、异常输入、依赖 mock - 断言风格使用 given/when/then 注释结构 - 禁止测试之间互相依赖、使用真实网络请求、sleep 等待3.3 Hooks 与 Settings 模板Hooks 是模板体系里最能体现“工程化”的部分也是多数人没重视的部分。它的作用是在 Claude Code 执行工具调用前后介入检查本质上是把项目的安全策略和操作规范固化到执行链路里。配置文件位于项目根目录的.claude/settings.json可以针对当前项目设置权限规则和 hooks。比如我可以配置一个 PreToolUse 钩子每次 Claude 要执行 Bash 命令之前都跑一个检查脚本拦截DROP DATABASE、rm -rf /这类危险命令并要求高危命令必须有用户确认标记。另一个常用的 hooks 场景是把代码风格检查接入工具链。比如配置 PostToolUse 钩子在 Claude 编辑完文件后自动跑 ESLint{ hooks: { PostToolUse: [ { matcher: Edit|Write, hooks: [ { type: command, command: ./scripts/lint-after-edit.sh } ] } ] } }配合一段简单的lint-after-edit.sh就能在 Claude 每次修改完代码后自动对改动文件执行npx eslint --fix。这样 AI 生成的代码质量在第一现场就被兜住了而不是等代码审查阶段才发现一堆格式问题。还有权限控制settings.json 里的permissions字段可以明确定义哪些命令需要确认、哪些目录禁止访问。比如禁止 AI 直接修改package-lock.json禁止访问.env文件这些都能写进配置比口头叮嘱可靠得多。4. 从零搭建一套模板的完整实操4.1 初始化目录与全局配置直接用命令初始化整套目录结构我建议放在一个独立目录里做版本管理方便后续迭代mkdir -p ~/.claude/commands mkdir -p ~/.claude/agents mkdir -p ~/.claude/hooks全局 CLAUDE.md 是最先要写好的文件因为所有项目会话都会读取它。我建议第一版不要写太多只放“怎么使用 Claude Code 的核心工作流和绝对不能做的事情”# 我的默认工作偏好 - 修改代码前先说明修改方案再动手 - 禁止执行破坏性操作的命令如强制推送、批量删除 - 生成代码时优先复用项目已有工具链和风格 - 所有问题先看项目文档不要凭空猜测 - 需要在多个文件间修改时先列出影响清单这里要注意的是全局文件和项目文件会合并读取如果项目里有冲突指令要以项目文件为准。因此全局配置保持精简很重要否则每个项目的个性化需求会被淹没在通用偏好里。4.2 编写第一个 CLAUDE.md 项目模板拿一个实际项目举例。假设现在要为每个新项目创建 CLAUDE.md我会先手工写第一版之后再根据项目实际情况持续迭代。新建项目根目录下的CLAUDE.md内容按前面第三部分的五个模块填充。以我最近一个 Node.js TypeScript 后端项目为例# 项目身份 - 项目名称billing-service - 定位计费与订阅管理服务 - 状态开发中已完成支付模块正在进行配额管理模块 # 技术栈与架构 - 运行时Node.js 20TypeScript 5.4 - 框架Fastify路由按 domain 模块划分 - 数据层Prisma PostgreSQL所有迁移通过 prisma migrate - 消息队列RabbitMQ消费失败进入 dead letter queue # 常用命令 - 安装依赖npm ci - 本地开发npm run dev - 类型检查npx tsc --noEmit - 运行测试npm run test - 单测某个文件npx jest tests/billing.spec.ts # 代码与领域规则 - 所有金额计算使用 decimal.js禁止直接 number 运算 - API 错误统一返回 { code, message, details } 结构 - 每个路由 handler 必须调用 validate 函数校验入参 - 禁止关闭 TypeScript 严格模式禁止使用 any 逃逸写完第一版后最好马上开一个新会话实测一下。让 Claude 解释项目架构、让它写一个小功能看它能不能准确引用这些规则。如果项目文件里某些规则没生效大概率是表述太模糊需要改得更具体、更可验证。4.3 注册自定义命令与验证效果命令模板的注册很简单就是往.claude/commands/里扔 Markdown 文件。我先放了三个最基础的随后根据使用频率逐步增加。以/commit为例在.claude/commands/commit.md里写入模板后直接在 Claude Code 会话中输入/commit工具会自动读取当前 git diff按模板生成提交信息。需要带上额外参数时可以直接/commit 重点是数据库迁移$ARGUMENTS会捕获“重点是数据库迁移”这段内容。验证时有个小细节要注意命令模板会在执行时和现有上下文合并。如果你之前在会话里详细讨论过代码逻辑生成的提交信息会更贴合实际改动如果是全新的会话直接执行/commit它也会自动读取 git diff但缺乏上下文生成的信息可能偏保守。所以大量使用前我会先在同一会话中对相关逻辑做过基本讨论再触发命令。4.4 用多项目模板复用代替重复造轮子新项目增多后我改用了“scaffold 方式”来提升效率。也就是说准备一套标准的项目模板文件内容作为起点。新项目初始化时直接把通用骨架复制过去再改项目专属段落。我现在每个新 Node.js 项目都会先放一份.claude/目录骨架project/ ├── CLAUDE.md # 项目专属先复制模板再改 ├── .claude/ │ ├── settings.json # 权限和 hooks 配置 │ ├── commands/ │ │ ├── commit.md │ │ ├── review.md │ │ └── test.md │ └── agents/ │ └── debugger.md # 定位死循环/内存泄漏的专项代理 └── docs/ └── engineering-guide.md # 团队公共规范被 CLAUDE.md 引用这个骨架的好处是新增项目只需要改动 CLAUDE.md 里的技术栈和命令command 模板和 settings 在所有项目之间完全复用。工程规范变更时改docs/engineering-guide.md一处就行不用逐个项目翻。为了这套复用机制我给engineering-guide.md里写好公共规范比如禁止使用any、提交前必须跑 lint、新增 API 必须补测试等然后项目 CLAUDE.md 里引用docs/engineering-guide.md这样两全其美主文件简短规范完整修改集中。目前这套机制我用了大半年稳定性和扩展性都经得起考验。5. 常见问题与排查技巧实录5.1 模板不生效或上下文被忽略刚上手最常见的现象是CLAUDE.md 明明写了一大堆规则Claude 还是输出不符合要求的内容。这时候要先跑一个快速排查流程检查文件命名和位置。CLAUDE.md 必须放在项目根目录大小写敏感。检查文件编码必须是 UTF-8避免中文乱码导致规则读取失败。确认当前工作目录如果是在子目录里启动的 Claude Code它读取的是子目录及向上的 CLAUDE.md可能没读到项目根的那份。把规则写得更“行为化”而不是“态度化”。“请注重代码质量”是无效规则“每个公开函数必须包含 JSDoc 注释”才是有效规则只有具体到动作的描述才能被稳定执行。另外要注意的是Claude Code 官方文档也提到CLAUDE.md 的内容是“上下文”而非“命令”模型在某些情境下可能选择忽略部分上下文尤其是当它认为用户当前的指令优先级更高时。所以关键规则除了写进 CLAUDE.md还应该在具体命令模板里重复出现双保险。5.2 多项目规约冲突全局 CLAUDE.md 和项目 CLAUDE.md 的内容冲突时我的处理原则是“项目层优先”。但实际执行中模型可能不会每次都做出正确取舍我遇到过全局规则“禁止任何破坏性操作”把项目里正常的数据库 reset 命令也给拦了的情况。遇到这类冲突最好的办法是降低全局文件里的“绝对化程度”给它加上“除非项目文件明确授权”这类条件限定词同时把项目内的例外规则写得更具体比如“本项目的 reset 命令仅用于本地开发数据库运行时数据库禁止执行”。在 settings.json 里也可以针对同一命令配置不同的确认策略用工具逻辑兜底而不完全依赖模型判断。5.3 模板过长反而降低输出质量这是个很多人容易踩的坑。模板不是越长越好塞满文档的 CLAUDE.md 会稀释真正重要的信息。我实测下来创建新会话时一次性注入超过 3000 字左右的背景材料后模型对关键指令的遵循度反而下降输出变得“泛泛而谈”。解决办法是分层思维CLAUDE.md 里只放最短的项目事实和最高优先级的规则详细规范、设计方案、历史决策等放到独立文档里用引用。这样既能保证主上下文简洁又能让 Claude 在需要时读取完整资料。按我目前的经验项目 CLAUDE.md 保持在 600-1200 字效果最好命令模板单个控制在 300-600 字之间。5.4 模板长期维护策略最后聊聊维护。模板体系是活的东西需要像代码一样持续重构。我的做法是每两周做一次“模板 review”打开用量记录看哪些命令模板高频使用哪些一次没用过。不常用的标记出来要么重写要么删除频繁触发但需要反复改提示词的模板说明写得不到位需要重新设计。我还在项目里放了一个CHANGELOG.claude.md记录每次模板调整的原因和变更内容。比如这次把/review的审查清单从 6 项压缩到 4 项是因为实测发现项目太多时清单过长会让模型逐项机械输出、缺少深挖。这些记录看似琐碎但对新同事理解模板设计意图以及回溯“为什么某个规则会出现在 CLAUDE.md 里”非常有帮助。我个人在实际操作中的体会是搭建 claude-code-templates 真正的门槛不是技术而是思维方式转变。你不能再把它当成一个聊天的 AI而要当一个可以写入长期记忆、可以配置自动化流程的协作者。模板就是你给这个协作者写的入职文档、操作手册和红线清单。花一个下午把这套体系搭起来后面每一个工作日的效率提升都是实打实能感受到的。如果你已经用上了 Claude Code 但还没建模板强烈建议从这周开始动手先放一个 CLAUDE.md 和两个常用命令跑一个项目后再逐步完善。这套东西维护得越好用起来越省心你也会越来越愿意把更多日常工作交给它。