这两年 AI 编程工具火得很快Claude Code 算是我用下来综合体验最稳的一个。但它在团队里真正跑起来之前有个绕不开的瓶颈——怎么让 Claude 一进入项目就懂规矩、知背景、能干活而不是每次都要手把手重新交代。我之前踩过不少坑最后干脆整理了一套claude-code-templates把项目初始化、指令文件、斜杠命令、自动化钩子全部模板化。这套东西用顺手之后不只是省时间而是整个工作流的质量都被拉上来了。这篇文章就把这套模板体系的完整思路拆给你看包含每一块配置的含义、我踩过的坑、以及可以直接抄的模板结构。适合已经接触过 Claude Code 但还没建立规范配置的人也适合想把 AI 辅助编程纳入团队流程的工程负责人。1. 为什么要给 Claude Code 做一套模板1.1 先搞清楚 Claude Code 的“记忆”机制Claude Code 能干活的核心不完全是模型本身多聪明而是它能够读取项目里的上下文。这个上下文的主要载体就是CLAUDE.md文件。只要这个文件放在项目根目录Claude 进入项目时就会自动读到并且里面的内容会被持续纳入对话参考。但问题也出在这里。几乎每个人第一次用 Claude Code 时都会犯一个错误——CLAUDE.md 写得像一篇论文事无巨细什么都往里塞。结果就是 Claude 的上下文窗口被无关信息占满真正重要的指令反而被稀释。我见过一个项目CLAUDE.md 写了两千多行翻到最底下才看到构建命令Claude 每次执行任务都要在那个冗长文件里自己提炼关键信息出错率自然居高不下。模板化解决的第一个问题就是让 CLAUDE.md 保持在一个“够用但不臃肿”的状态。把内容拆成几个固定模块每个模块有明确的优先级和字数上限Claude 读起来不累你也知道该往哪个位置补充新内容。还有一个容易忽略的细节Claude Code 支持层级记忆。除了根目录的CLAUDE.md子目录也可以放自己的CLAUDE.md而且同级目录下还可以用CLAUDE.local.md区分本地个人配置。如果团队模板只覆盖根目录子模块的上下文就还是裸奔状态Claude 经常答非所问。模板化需要把这些层级规则固化下来。1.2 模板化解决的三类痛点第一大类是“项目交接”问题。以前同事离职或者换个新项目上手成本少则一两天多则一周。有了标准化的 Claude Code 模板新人进来只需安装好命令行工具项目里已经躺着一份结构清晰的 CLAUDE.md 和命令集Claude 能直接告诉新人这个项目怎么跑、怎么测、怎么部署。这类模板相当于把项目知识外置成了活文档。第二大类是“指令一致性”问题。同一个仓库里有人让 Claude 用 npm 跑测试有人让 Claude 用 pnpm还有人直接跟 Claude 聊天让它猜包管理器。这些不一致小则浪费时间大则产生错误配置。通过模板把测试、构建、代码风格检查等命令统一固化到 CLAUDE.md 里所有会话的行为基线就对齐了。第三大类是“重复劳动”问题。几乎每个项目都要配置 lint、格式化、测试命令、目录说明、架构约束。没有模板的时候每个项目都得重新写一遍还容易漏项。模板化之后从一个基础骨架派生项目配置几分钟就能完成原来半小时的初始化工作。这块节省下来的时间才是模板最大的直接收益。2. 模板的核心组成部分CLAUDE.md 与命令体系2.1 CLAUDE.md 基础模板结构拆解我自己的基础模板把 CLAUDE.md 分成五个模块项目简介、常用命令、目录结构、代码规范、注意事项。每个模块有自己的固定标题层级这样 Claude 解析时信息获取效率最高。项目简介不要写成产品宣传册两到三句话说明项目是干什么的、主要服务对象是谁、核心链路是什么。只写 Claude 干活需要知道的事实不写价值愿景。比如写“这是一个面向商户的订单管理后台处理订单创建、支付回调、退款流程”就比“致力于打造卓越的商户数字化解决方案”有用得多。常用命令模块要列明dev、build、test、lint五类而且尽量写明完整命令而不仅是脚本名比如npm run dev -- --port 3001。这里还有个很容易被忽视的点端口号、环境变量名这类信息平时人眼看不出来但 Claude 执行命令时如果读不到会反复试探。把端口、环境变量、公共 URL 直接写进命令注释里能省掉很多来回。目录结构模块不需要把每个文件都写进去只写容易让 Claude 迷路的目录比如src/api是接口层、src/components是纯展示组件、scripts下哪个脚本是给 CI 跑的。核心逻辑是“只描述需要区分才能理解的部分”大而全的目录树反而是噪音。代码规范模块写的是约定而非命令。比如“禁止在组件内部直接修改 props”、“新接口必须用 zod 做运行时校验”这些 Claude 光靠读代码不一定能推断出来。如果项目里有 ESLint/TS 配置较严格可以直接提示 Claude 先运行 lint再根据 lint 输出自行修正。注意事项模块专门放那些“踩过坑才知道”的规则比如某个目录不要动、某个服务必须在 docker 里跑。这个模块建议控制在十条以内只写硬约束。2.2 自定义斜杠命令模板CLAUDE.md 解决的是“Claude 知不知道”自定义斜杠命令解决的是“Claude 干不干得对”。Claude Code 允许用户在.claude/commands/目录下创建 Markdown 文件每个文件对应一个斜杠命令。比如写了.claude/commands/review.md对话里输入/review就会执行该文件里的指令。这套机制非常适合模板化。我把一套常用命令沉淀成模板后项目里的斜杠命令就变成了标准动作。举个例子.claude/commands/commit.md的模板内容是根据当前的 git diff 和暂存区内容帮我生成一份符合 Conventional Commits 规范的提交信息。 先展示提交类型feat/fix/refactor/docs/test/chore的判断理由再给出最终提交信息。 保持简洁不超过 80 个字符。有了这个命令每次提交代码时不再手写 commit messageClaude 会自己检查 diff 并给出规范化提交信息。还有test.md命令跑测试且帮我分析失败用例explain.md命令让 Claude 解释选中的代码片段。命令模板的关键不在多而在“动词要精确”——spec 里写清楚触发条件、执行步骤、输出格式和边界情况。命令文件支持 YAML frontmatter可以用来配置命令的标题、描述甚至绑定到某个快捷键。模板里我会固定写一个description字段确保斜杠菜单里显示清晰。另外允许多行参数用$ARGUMENTS接收用户输入写命令时务必要处理“用户没给参数”的默认场景。2.3 Hooks 配置模板让 Claude 在关键节点自动守规矩要构建一套完整的模板体系只能被动等待 Claude 响应是不够的。Claude Code 的 hooks 机制允许你在特定事件点挂上自动化校验相当于给 Claude 上了一道保险。配置位置在.claude/settings.json或用户级~/.claude/settings.json常用的有PreToolUse工具调用前触发、PostToolUse工具调用后触发、StopClaude 完成一轮响应后触发、Notification耗时任务完成通知。我最常用的一个 hook 是禁止 Claude 在项目里直接写console.log调试。这个需求听起来简单但靠对话约束效果很弱——Claude 写着写着就忘了。换成 hook 之后每次文件写入前都会检查内容如果检测到调试代码就中断操作并提示原因这才是真正的硬约束。模板里还应该把 notification hook 固化下来尤其是对于长时间运行的 build 或测试任务完成后自动发送桌面通知这样你不需要一直盯着终端。hooks 的逻辑要尽量做成脚本化、可复用的不要写在配置文件里的一大段内联脚本里而是放到scripts/hooks/目录下统一管理和维护。2.4 多环境配置settings 文件的优先级Claude Code 的配置分多个层级模板设计必须清楚这些层级的优先级否则团队和个人的配置就会互相覆盖。优先级从高到低是Enterprise 策略 项目级配置 用户级配置。项目模板应该放在项目级.claude/settings.json个人偏好比如编辑器风格、API key 相关放在~/.claude/settings.json。这里有一个很实用的技巧CLAUDE.local.md天然适合放个人补充信息它不会被提交到 Git可以写一些跟个人工作流相关的背景。团队模板里我通常会把一些敏感度较低但带有个人偏好色彩的内容定向到 local 文件里避免团队配置被个人习惯污染。3. 实操从零搭建 claude-code-templates 项目3.1 模板目录结构设计搭建之前先想清楚目录结构。我自己的模板项目大概是这样的claude-code-templates/ ├── base/ # 基础模板适配所有项目 │ ├── CLAUDE.md │ ├── CLAUDE.local.md │ └── commands/ │ ├── commit.md │ ├── test.md │ ├── explain.md │ └── review.md ├── web-frontend/ # 前端项目模板 │ ├── CLAUDE.md │ └── commands/ │ ├── storybook.md │ └── component.md ├── backend-service/ # 后端服务项目模板 │ ├── CLAUDE.md │ └── commands/ │ ├── migrate.md │ └── debug.md ├── hooks/ # 通用 hooks 脚本 │ ├── pre-commit-check.sh │ └── notify-done.sh ├── scripts/ │ ├── init.sh # 交互式自动初始化项目配置 │ └── sync.sh # 同步模板到现有项目 └── README.mdbase 目录里的内容任何项目都可以直接复制web-frontend 和 backend-service 是在 base 基础上叠加的场景化覆盖。init.sh 是最重要的自动化脚本它先让你选择项目类型然后把对应模板复制到目标目录并按交互输入替换变量。3.2 一个可复制的通用 CLAUDE.md 模板下面这份基础模板我用了将近半年先后在十几个项目里验证过直接拿过去改一改就可以用# 项目概览 [两到三句话说明项目功能、服务对象和核心流程] # 常用命令 - 启动开发服务: npm run dev (端口默认 3001, 可用环境变量 PORT 覆盖) - 生产构建: npm run build (产物在 dist/ 目录) - 运行测试: npm run test (默认 watch 模式) - 单测某个文件: npm run test -- path/to/file - Lint 检查: npm run lint (必须通过后再提交) # 目录结构 - src/api: 接口调用层所有 HTTP 请求封装在这里 - src/components: UI 组件不允许包含业务请求逻辑 - src/utils: 纯函数工具 - scripts/: 工程化脚本其中 sync-db.mjs 专门给 CI 用 # 代码规范 - TypeScript 严格模式禁止使用 any - 组件默认使用 Function Component - 所有接口返回数据必须经过 zod 校验 - 样式使用 CSS Modules不写全局 class # 注意事项 - src/vendor 下的代码是第三方库的拷贝不要改动 - 本地开发依赖 mock 服务请求 baseURL 会自动切换 - 修改数据库表结构前必须执行 migrate 脚本生成迁移文件这里的每一个模块我都尽量控制了字数。项目概览不超过三句话目录结构只列关键目录注意事项只写硬约束。实际使用中 Claude 90% 的行为偏差都能被这份模板覆盖到。3.3 分场景模板前端与后端的差异化补充基础模板只解决通用问题真正让效率提升的是场景化差异。前端项目我会额外加上几条组件开发规范要写清楚命名规则组件文件用 PascalCase、状态管理约定全局状态走 zustand组件内部状态用 useState、路由约定文件路由对应src/pages目录。这些 Claude 自己读代码有时候能猜出来但猜的过程容易出错直接告诉它才是最稳的。后端服务模板则要侧重数据层约束数据库访问必须走 repository 层不允许在 service 里面裸写 SQL所有外部接口调用要有超时和重试机制日志打印必须包含 traceId。这些团队内部约定写不写差距非常大不写的话 Claude 往往会用最直接但最不规范的方式去访问数据库。前端模板我还会配套一个/component命令自动根据描述生成组件文件、样式文件和测试文件并且遵循项目现有的命名约定。后端模板则会配/migrate命令生成数据库迁移文件时自动检查是否包含 down 语句。3.4 模板的版本管理与团队分发模板本身也是一个项目建议用 Git 管理并打 tag 记录版本。版本号变化通常对应命令规范调整或者 CLAUDE.md 结构变化而不是细微文案修改。团队成员更新模板时先拉取最新模板再跑 sync 脚本把变更合并进项目。同步脚本需要注意一个原则覆盖但不抹掉项目里的个性化配置。CLAUDE.md这种应该整体覆盖.claude/commands/下新增命令则采用增量合并。我会用diff对比目标目录和模板目录新增的内容直接复制有冲突的地方列出差异由人工决定。这样就能避免团队里出现“某个人改过本地配置后被模板冲掉”的尴尬。分发时还要考虑安全性。模板里面尽量不要写死带有密钥性质的占位符不要把真实域名、真实 API key 放进去。我见过有人把内部域名写进模板结果项目开源后跟着泄露了。正确的做法是用占位符在 init.sh 里批量替换。4. 常见问题与排查技巧实录4.1 CLAUDE.md 越写越长Claude “记不住”使用一段时间后CLAUDE.md 一定会膨胀。最常见的原因是“这规则很重要我多写点上下文帮 Claude 理解”。但 Claude Code 把 CLAUDE.md 内容纳入上下文的逻辑是全文累计在累计超过阈值后再按相关性裁剪写得过长反而导致关键信息被裁剪掉。我的处理策略是把 CLAUDE.md 限定在一屏半以内能写短句不写长句能用例子说明的不要写抽象描述。如果确实有大量背景信息要补充从 CLAUDE.md 里用path/to/file引入独立文档Claude 会在真正需要时才加载完整的附加文档。这样既不损失信息量又保证了核心指令的显眼度。4.2 自定义命令没生效大概率是文件位置或命名问题斜杠命令放在.claude/commands/目录下文件名就是命令名比如review.md对应/review。最容易踩坑的是 commands 目录被放进了CLAUDE.md引用的其他位置或者文件扩展名写成了.mdx。还有一个细节命令文件里开头的 frontmatter 如果格式写错命令不会出现在斜杠列表里而且终端没有任何报错排查起来非常郁闷。我的做法是在模板里自带一个health.md命令它会输出当前项目里所有可用斜杠命令列表以及版本号。每次配置结束先跑一遍/health能快速验证命令体系是否正常挂载。这个习惯值得推广到团队每个成员。4.3 模板与现有工作流冲突模板把命令写死了但有些项目确实特殊。比如后端模板假设测试用 pytest但项目实际用的是 jest。这种冲突要在初始化时而不是使用中暴露。我在 init.sh 里增加了一个“命令确认”环节把模板里的所有命令列出来逐条确认是否适用不适用就现场修改。这个过程看起来只有几分钟但能避免后面每次调用命令时都出错。还有更隐蔽的冲突是端口号。多个后端服务同时开发时模板里写死的 3001 端口往往会被系统随机分配别的端口。所以 init.sh 里我把端口这类环境相关变量单独抽出来用占位符替换不给它写死的机会。4.4 团队多人协作时配置如何保持一致一个人用模板和团队用模板难度完全不是一回事。团队协作中我遇到过两个人用了不同版本的模板CLAUDE.md 结构不一致结果 Claude 在每个人会话里的行为基线都不一样代码风格很快出现偏差。建议的做法是把模板仓库设为template仓库配合 CI 检查——在 push 时校验CLAUDE.md是否包含必需模块缺少就报错。另外每个项目里放一个TEMPLATE_VERSION文件记录当前使用的模板版本team lead 更新模板后统一在群里同步升级。下面是几个常见配置问题的速查参考症状可能原因解决方案CLAUDE.md 内容没被加载文件不在项目根目录把文件移到根目录确认文件名大小写斜杠命令找不到commands 目录位置错、frontmatter 格式错确认/health命令能列出所有命令hooks 不触发settings.json 事件名拼错对照官方事件名重新检查模板覆盖了个人配置项目级和用户级配置冲突个人偏好统一放到~/.claude/settings.json命令多了上下文太占空间命令文件过长精简到必要动作拆成多个细粒度命令5. 一点后续想法模板体系还可以往哪走说实话claude-code-templates 这套东西我现在已经不只是拿来初始化项目了它慢慢变成了整个 AI 协作工作流的基础设施。新项目接入只要几分钟老项目同步模板也能在半小时内完成而且每次升级模板全家桶所有项目的 Claude 能力跟着一起升级——这比逐个项目去调 prompt 要高效太多。如果你也想把这套思路落地建议从最小的闭环开始先写一份 50 行的 CLAUDE.md配两个斜杠命令一个提交信息、一个跑测试用一周试试水。等适应了这个工作流再逐步把 hooks、场景模板、版本管理加进去。不用一上来就搞全家桶AI 工具这东西用得越贴身边界感越清楚效果才越好。
Claude Code 模板化实践：用 CLAUDE.md 与命令体系构建 AI 编程工作流
这两年 AI 编程工具火得很快Claude Code 算是我用下来综合体验最稳的一个。但它在团队里真正跑起来之前有个绕不开的瓶颈——怎么让 Claude 一进入项目就懂规矩、知背景、能干活而不是每次都要手把手重新交代。我之前踩过不少坑最后干脆整理了一套claude-code-templates把项目初始化、指令文件、斜杠命令、自动化钩子全部模板化。这套东西用顺手之后不只是省时间而是整个工作流的质量都被拉上来了。这篇文章就把这套模板体系的完整思路拆给你看包含每一块配置的含义、我踩过的坑、以及可以直接抄的模板结构。适合已经接触过 Claude Code 但还没建立规范配置的人也适合想把 AI 辅助编程纳入团队流程的工程负责人。1. 为什么要给 Claude Code 做一套模板1.1 先搞清楚 Claude Code 的“记忆”机制Claude Code 能干活的核心不完全是模型本身多聪明而是它能够读取项目里的上下文。这个上下文的主要载体就是CLAUDE.md文件。只要这个文件放在项目根目录Claude 进入项目时就会自动读到并且里面的内容会被持续纳入对话参考。但问题也出在这里。几乎每个人第一次用 Claude Code 时都会犯一个错误——CLAUDE.md 写得像一篇论文事无巨细什么都往里塞。结果就是 Claude 的上下文窗口被无关信息占满真正重要的指令反而被稀释。我见过一个项目CLAUDE.md 写了两千多行翻到最底下才看到构建命令Claude 每次执行任务都要在那个冗长文件里自己提炼关键信息出错率自然居高不下。模板化解决的第一个问题就是让 CLAUDE.md 保持在一个“够用但不臃肿”的状态。把内容拆成几个固定模块每个模块有明确的优先级和字数上限Claude 读起来不累你也知道该往哪个位置补充新内容。还有一个容易忽略的细节Claude Code 支持层级记忆。除了根目录的CLAUDE.md子目录也可以放自己的CLAUDE.md而且同级目录下还可以用CLAUDE.local.md区分本地个人配置。如果团队模板只覆盖根目录子模块的上下文就还是裸奔状态Claude 经常答非所问。模板化需要把这些层级规则固化下来。1.2 模板化解决的三类痛点第一大类是“项目交接”问题。以前同事离职或者换个新项目上手成本少则一两天多则一周。有了标准化的 Claude Code 模板新人进来只需安装好命令行工具项目里已经躺着一份结构清晰的 CLAUDE.md 和命令集Claude 能直接告诉新人这个项目怎么跑、怎么测、怎么部署。这类模板相当于把项目知识外置成了活文档。第二大类是“指令一致性”问题。同一个仓库里有人让 Claude 用 npm 跑测试有人让 Claude 用 pnpm还有人直接跟 Claude 聊天让它猜包管理器。这些不一致小则浪费时间大则产生错误配置。通过模板把测试、构建、代码风格检查等命令统一固化到 CLAUDE.md 里所有会话的行为基线就对齐了。第三大类是“重复劳动”问题。几乎每个项目都要配置 lint、格式化、测试命令、目录说明、架构约束。没有模板的时候每个项目都得重新写一遍还容易漏项。模板化之后从一个基础骨架派生项目配置几分钟就能完成原来半小时的初始化工作。这块节省下来的时间才是模板最大的直接收益。2. 模板的核心组成部分CLAUDE.md 与命令体系2.1 CLAUDE.md 基础模板结构拆解我自己的基础模板把 CLAUDE.md 分成五个模块项目简介、常用命令、目录结构、代码规范、注意事项。每个模块有自己的固定标题层级这样 Claude 解析时信息获取效率最高。项目简介不要写成产品宣传册两到三句话说明项目是干什么的、主要服务对象是谁、核心链路是什么。只写 Claude 干活需要知道的事实不写价值愿景。比如写“这是一个面向商户的订单管理后台处理订单创建、支付回调、退款流程”就比“致力于打造卓越的商户数字化解决方案”有用得多。常用命令模块要列明dev、build、test、lint五类而且尽量写明完整命令而不仅是脚本名比如npm run dev -- --port 3001。这里还有个很容易被忽视的点端口号、环境变量名这类信息平时人眼看不出来但 Claude 执行命令时如果读不到会反复试探。把端口、环境变量、公共 URL 直接写进命令注释里能省掉很多来回。目录结构模块不需要把每个文件都写进去只写容易让 Claude 迷路的目录比如src/api是接口层、src/components是纯展示组件、scripts下哪个脚本是给 CI 跑的。核心逻辑是“只描述需要区分才能理解的部分”大而全的目录树反而是噪音。代码规范模块写的是约定而非命令。比如“禁止在组件内部直接修改 props”、“新接口必须用 zod 做运行时校验”这些 Claude 光靠读代码不一定能推断出来。如果项目里有 ESLint/TS 配置较严格可以直接提示 Claude 先运行 lint再根据 lint 输出自行修正。注意事项模块专门放那些“踩过坑才知道”的规则比如某个目录不要动、某个服务必须在 docker 里跑。这个模块建议控制在十条以内只写硬约束。2.2 自定义斜杠命令模板CLAUDE.md 解决的是“Claude 知不知道”自定义斜杠命令解决的是“Claude 干不干得对”。Claude Code 允许用户在.claude/commands/目录下创建 Markdown 文件每个文件对应一个斜杠命令。比如写了.claude/commands/review.md对话里输入/review就会执行该文件里的指令。这套机制非常适合模板化。我把一套常用命令沉淀成模板后项目里的斜杠命令就变成了标准动作。举个例子.claude/commands/commit.md的模板内容是根据当前的 git diff 和暂存区内容帮我生成一份符合 Conventional Commits 规范的提交信息。 先展示提交类型feat/fix/refactor/docs/test/chore的判断理由再给出最终提交信息。 保持简洁不超过 80 个字符。有了这个命令每次提交代码时不再手写 commit messageClaude 会自己检查 diff 并给出规范化提交信息。还有test.md命令跑测试且帮我分析失败用例explain.md命令让 Claude 解释选中的代码片段。命令模板的关键不在多而在“动词要精确”——spec 里写清楚触发条件、执行步骤、输出格式和边界情况。命令文件支持 YAML frontmatter可以用来配置命令的标题、描述甚至绑定到某个快捷键。模板里我会固定写一个description字段确保斜杠菜单里显示清晰。另外允许多行参数用$ARGUMENTS接收用户输入写命令时务必要处理“用户没给参数”的默认场景。2.3 Hooks 配置模板让 Claude 在关键节点自动守规矩要构建一套完整的模板体系只能被动等待 Claude 响应是不够的。Claude Code 的 hooks 机制允许你在特定事件点挂上自动化校验相当于给 Claude 上了一道保险。配置位置在.claude/settings.json或用户级~/.claude/settings.json常用的有PreToolUse工具调用前触发、PostToolUse工具调用后触发、StopClaude 完成一轮响应后触发、Notification耗时任务完成通知。我最常用的一个 hook 是禁止 Claude 在项目里直接写console.log调试。这个需求听起来简单但靠对话约束效果很弱——Claude 写着写着就忘了。换成 hook 之后每次文件写入前都会检查内容如果检测到调试代码就中断操作并提示原因这才是真正的硬约束。模板里还应该把 notification hook 固化下来尤其是对于长时间运行的 build 或测试任务完成后自动发送桌面通知这样你不需要一直盯着终端。hooks 的逻辑要尽量做成脚本化、可复用的不要写在配置文件里的一大段内联脚本里而是放到scripts/hooks/目录下统一管理和维护。2.4 多环境配置settings 文件的优先级Claude Code 的配置分多个层级模板设计必须清楚这些层级的优先级否则团队和个人的配置就会互相覆盖。优先级从高到低是Enterprise 策略 项目级配置 用户级配置。项目模板应该放在项目级.claude/settings.json个人偏好比如编辑器风格、API key 相关放在~/.claude/settings.json。这里有一个很实用的技巧CLAUDE.local.md天然适合放个人补充信息它不会被提交到 Git可以写一些跟个人工作流相关的背景。团队模板里我通常会把一些敏感度较低但带有个人偏好色彩的内容定向到 local 文件里避免团队配置被个人习惯污染。3. 实操从零搭建 claude-code-templates 项目3.1 模板目录结构设计搭建之前先想清楚目录结构。我自己的模板项目大概是这样的claude-code-templates/ ├── base/ # 基础模板适配所有项目 │ ├── CLAUDE.md │ ├── CLAUDE.local.md │ └── commands/ │ ├── commit.md │ ├── test.md │ ├── explain.md │ └── review.md ├── web-frontend/ # 前端项目模板 │ ├── CLAUDE.md │ └── commands/ │ ├── storybook.md │ └── component.md ├── backend-service/ # 后端服务项目模板 │ ├── CLAUDE.md │ └── commands/ │ ├── migrate.md │ └── debug.md ├── hooks/ # 通用 hooks 脚本 │ ├── pre-commit-check.sh │ └── notify-done.sh ├── scripts/ │ ├── init.sh # 交互式自动初始化项目配置 │ └── sync.sh # 同步模板到现有项目 └── README.mdbase 目录里的内容任何项目都可以直接复制web-frontend 和 backend-service 是在 base 基础上叠加的场景化覆盖。init.sh 是最重要的自动化脚本它先让你选择项目类型然后把对应模板复制到目标目录并按交互输入替换变量。3.2 一个可复制的通用 CLAUDE.md 模板下面这份基础模板我用了将近半年先后在十几个项目里验证过直接拿过去改一改就可以用# 项目概览 [两到三句话说明项目功能、服务对象和核心流程] # 常用命令 - 启动开发服务: npm run dev (端口默认 3001, 可用环境变量 PORT 覆盖) - 生产构建: npm run build (产物在 dist/ 目录) - 运行测试: npm run test (默认 watch 模式) - 单测某个文件: npm run test -- path/to/file - Lint 检查: npm run lint (必须通过后再提交) # 目录结构 - src/api: 接口调用层所有 HTTP 请求封装在这里 - src/components: UI 组件不允许包含业务请求逻辑 - src/utils: 纯函数工具 - scripts/: 工程化脚本其中 sync-db.mjs 专门给 CI 用 # 代码规范 - TypeScript 严格模式禁止使用 any - 组件默认使用 Function Component - 所有接口返回数据必须经过 zod 校验 - 样式使用 CSS Modules不写全局 class # 注意事项 - src/vendor 下的代码是第三方库的拷贝不要改动 - 本地开发依赖 mock 服务请求 baseURL 会自动切换 - 修改数据库表结构前必须执行 migrate 脚本生成迁移文件这里的每一个模块我都尽量控制了字数。项目概览不超过三句话目录结构只列关键目录注意事项只写硬约束。实际使用中 Claude 90% 的行为偏差都能被这份模板覆盖到。3.3 分场景模板前端与后端的差异化补充基础模板只解决通用问题真正让效率提升的是场景化差异。前端项目我会额外加上几条组件开发规范要写清楚命名规则组件文件用 PascalCase、状态管理约定全局状态走 zustand组件内部状态用 useState、路由约定文件路由对应src/pages目录。这些 Claude 自己读代码有时候能猜出来但猜的过程容易出错直接告诉它才是最稳的。后端服务模板则要侧重数据层约束数据库访问必须走 repository 层不允许在 service 里面裸写 SQL所有外部接口调用要有超时和重试机制日志打印必须包含 traceId。这些团队内部约定写不写差距非常大不写的话 Claude 往往会用最直接但最不规范的方式去访问数据库。前端模板我还会配套一个/component命令自动根据描述生成组件文件、样式文件和测试文件并且遵循项目现有的命名约定。后端模板则会配/migrate命令生成数据库迁移文件时自动检查是否包含 down 语句。3.4 模板的版本管理与团队分发模板本身也是一个项目建议用 Git 管理并打 tag 记录版本。版本号变化通常对应命令规范调整或者 CLAUDE.md 结构变化而不是细微文案修改。团队成员更新模板时先拉取最新模板再跑 sync 脚本把变更合并进项目。同步脚本需要注意一个原则覆盖但不抹掉项目里的个性化配置。CLAUDE.md这种应该整体覆盖.claude/commands/下新增命令则采用增量合并。我会用diff对比目标目录和模板目录新增的内容直接复制有冲突的地方列出差异由人工决定。这样就能避免团队里出现“某个人改过本地配置后被模板冲掉”的尴尬。分发时还要考虑安全性。模板里面尽量不要写死带有密钥性质的占位符不要把真实域名、真实 API key 放进去。我见过有人把内部域名写进模板结果项目开源后跟着泄露了。正确的做法是用占位符在 init.sh 里批量替换。4. 常见问题与排查技巧实录4.1 CLAUDE.md 越写越长Claude “记不住”使用一段时间后CLAUDE.md 一定会膨胀。最常见的原因是“这规则很重要我多写点上下文帮 Claude 理解”。但 Claude Code 把 CLAUDE.md 内容纳入上下文的逻辑是全文累计在累计超过阈值后再按相关性裁剪写得过长反而导致关键信息被裁剪掉。我的处理策略是把 CLAUDE.md 限定在一屏半以内能写短句不写长句能用例子说明的不要写抽象描述。如果确实有大量背景信息要补充从 CLAUDE.md 里用path/to/file引入独立文档Claude 会在真正需要时才加载完整的附加文档。这样既不损失信息量又保证了核心指令的显眼度。4.2 自定义命令没生效大概率是文件位置或命名问题斜杠命令放在.claude/commands/目录下文件名就是命令名比如review.md对应/review。最容易踩坑的是 commands 目录被放进了CLAUDE.md引用的其他位置或者文件扩展名写成了.mdx。还有一个细节命令文件里开头的 frontmatter 如果格式写错命令不会出现在斜杠列表里而且终端没有任何报错排查起来非常郁闷。我的做法是在模板里自带一个health.md命令它会输出当前项目里所有可用斜杠命令列表以及版本号。每次配置结束先跑一遍/health能快速验证命令体系是否正常挂载。这个习惯值得推广到团队每个成员。4.3 模板与现有工作流冲突模板把命令写死了但有些项目确实特殊。比如后端模板假设测试用 pytest但项目实际用的是 jest。这种冲突要在初始化时而不是使用中暴露。我在 init.sh 里增加了一个“命令确认”环节把模板里的所有命令列出来逐条确认是否适用不适用就现场修改。这个过程看起来只有几分钟但能避免后面每次调用命令时都出错。还有更隐蔽的冲突是端口号。多个后端服务同时开发时模板里写死的 3001 端口往往会被系统随机分配别的端口。所以 init.sh 里我把端口这类环境相关变量单独抽出来用占位符替换不给它写死的机会。4.4 团队多人协作时配置如何保持一致一个人用模板和团队用模板难度完全不是一回事。团队协作中我遇到过两个人用了不同版本的模板CLAUDE.md 结构不一致结果 Claude 在每个人会话里的行为基线都不一样代码风格很快出现偏差。建议的做法是把模板仓库设为template仓库配合 CI 检查——在 push 时校验CLAUDE.md是否包含必需模块缺少就报错。另外每个项目里放一个TEMPLATE_VERSION文件记录当前使用的模板版本team lead 更新模板后统一在群里同步升级。下面是几个常见配置问题的速查参考症状可能原因解决方案CLAUDE.md 内容没被加载文件不在项目根目录把文件移到根目录确认文件名大小写斜杠命令找不到commands 目录位置错、frontmatter 格式错确认/health命令能列出所有命令hooks 不触发settings.json 事件名拼错对照官方事件名重新检查模板覆盖了个人配置项目级和用户级配置冲突个人偏好统一放到~/.claude/settings.json命令多了上下文太占空间命令文件过长精简到必要动作拆成多个细粒度命令5. 一点后续想法模板体系还可以往哪走说实话claude-code-templates 这套东西我现在已经不只是拿来初始化项目了它慢慢变成了整个 AI 协作工作流的基础设施。新项目接入只要几分钟老项目同步模板也能在半小时内完成而且每次升级模板全家桶所有项目的 Claude 能力跟着一起升级——这比逐个项目去调 prompt 要高效太多。如果你也想把这套思路落地建议从最小的闭环开始先写一份 50 行的 CLAUDE.md配两个斜杠命令一个提交信息、一个跑测试用一周试试水。等适应了这个工作流再逐步把 hooks、场景模板、版本管理加进去。不用一上来就搞全家桶AI 工具这东西用得越贴身边界感越清楚效果才越好。
