如果你也把 Claude Code 当成日常主力开发工具应该体会过那种别扭每次新起一个项目都要重新跟它交代背景、技术栈、目录结构事无巨细地解释代码风格和约定。更烦的是同一件事交给不同人调出来的行为差异很大团队协作时互相对不上频道。我花了两个多月折腾 claude-code-templates把 Claude Code 的配置能力拆成一套可复用的模板体系把项目记忆文件、斜杠命令、自动化钩子、权限设置全部沉淀成标准文件新项目直接复制就能用。这套方案主要解决三个问题新项目重复配置的体力活、团队成员指令风格不统一、以及上下文丢失后重新“调教”的成本。适合正在把 Claude Code 当生产力工具、又不想每次都从零开始配置的人。1. 模板存在的意义把“调教经验”固化成项目资产1.1 先理解 Claude Code 的“记忆”机制Claude Code 每次开始干活之前会先读一批文件作为“工作手册”其中最核心的就是CLAUDE.md。这个名字听起来有点像给 AI 看的 README但定位完全不同README 是给人看的项目简介CLAUDE.md 是给模型看的行为准则。启动时 Claude 会按层级依次加载配置文件距离当前工作目录越近的优先级越高项目根目录放一份CLAUDE.md就相当于告诉模型这个项目用什么语言、有哪些常用命令、遵守什么规范、哪里容易出错。这个机制最值钱的地方在于它不是一次性的。只要文件还在项目里每次新开会话、或者上下文被压缩之后Claude 都会重新加载这份记忆。换句话说你费半天劲调教出来的“懂行”状态沉淀成文件之后可以反复使用。模板体系正是建立在这个机制之上的既然模型的行为很大程度上由这些文件决定那为什么不把一份打磨好的文件变成模板放到所有项目里这才是 claude-code-templates 这类实践真正有价值的原因。1.2 模板到底解决了什么问题第一个场景是项目初始化。以前新项目要跟 Claude 说半天技术栈、目录风格、测试命令现在初始化时直接复制模板该有的上下文都在文件里对话体验是“即插即用”的。第二个场景是团队协作。代码规范、提交信息格式、环境变量管理这些最容易产生分歧的地方只要大家共用一份 templates 仓库AI 产出的代码风格就是稳定的评审时的沟通成本会明显下降。第三个场景是“防失忆”。Claude Code 的上下文窗口再大也是有限的会话频繁切换、任务被打断是家常便饭。没有模板的时候重新开一个会话就得原地做一次知识迁移有模板之后只要文件还躺在项目里随时可以无损恢复。我在实际维护中还发现一个更隐性的收益模板会逼迫你把项目里的隐性知识显性化。很多人对“自己的项目”很有把握但要写清楚目录是干嘛的、哪条命令不能乱跑、哪个模块最容易踩坑反而要花点心思。这份思考本身就是价值对后面加入项目的新人尤其友好。1.3 模板不是越全越好一开始很容易陷入一个误区把所有想到的规则都塞进模板恨不得把团队 Wiki 全文搬进去。但 Claude 的上下文处理能力是有限的即使能读进来信息之间也会互相干扰。我曾经在某份 CLAUDE.md 里写了几百行“完整规范”结果模型反而抓不住重点连最基础的要求都会遗漏。后来我把规范砍到核心的二十条左右之前频繁出错的问题反而消失了。模板应该是一份“重点提示卡”不是百科全书。它记录的是模型最容易搞错、以及项目里最不希望它搞砸的事情其他内容应该留给代码本身和常规文档。判断一条规则该不该写进模板有个很简单的标准这条规则如果被 AI 违反了造成的后果严重吗如果严重那就值得占用一个位置如果只是“更好看”放行就行。2. 模板体系的解剖从 CLAUDE.md 到斜杠命令2.1 CLAUDE.md项目记忆体怎么写才有效一份好用的 CLAUDE.md至少包含六个模块项目一句话定位、技术栈与环境要求、常用命令、目录结构说明、编码约定、易错点清单。写的时候有几个讲究。一是语言要直接。Claude 是按字面理解指令的你写“最好使用 TypeScript”它就可能选择不用写成“类型定义必须使用 TypeScript禁止使用 any”约束力立刻不一样。二是按优先级排序把最核心、违反代价最高的规则放在最前面因为长文档后段的内容在上下文处理中更容易被弱化。三是定期维护项目换技术栈、目录重构之后CLAUDE.md 也要跟着更新否则放着不管的模板会逐渐变成“过期地图”。不同层级的配置文件可以叠加生效距离项目越近的优先级越高。我整理了一个速查表方便对照文件位置作用范围典型内容企业级配置如组织的全局 CLAUDE.md整个组织合规要求、通用编码规范项目根目录 CLAUDE.md当前项目技术栈、命令、易错点用户目录 ~/.claude/CLAUDE.md所有项目个人偏好、通用工作流CLAUDE.local.md单个项目补充本地实验性配置不入版本库实际使用中项目级 CLAUDE.md 最容易出现的问题是“野心过大”。我见过有人把公司安全规范、设计模式、命名规范汇总全部写进去结果模型每次行为都变得畏手畏脚。记住一个原则CLAUDE.md 不是给 AI 上刑它服务的核心目标是让 AI 在自由发挥时不踩你项目里真正的红线。2.2 斜杠命令把重复操作固化成可复用指令CLAUDE.md 解决的是“让模型懂项目”斜杠命令解决的是“让模型会做事”。Claude Code 支持自定义斜杠命令把一串复杂的提示词封装成一个指令。项目级放在.claude/commands目录用户级放在~/.claude/commands目录每个.md文件就是一个命令文件名去掉.md就是触发词。命令文件支持 YAML frontmatter可以声明 description、argument-hint 等元信息。你还可以在命令正文里用$ARGUMENTS引用用户输入。比如创建一个commit.md内容是一套提交信息生成规范那么/commit就会直接触发这套流程不再需要每次现场口述。这跟你平时在编辑器里写代码片段是同一个道理只是封装的对象从代码变成了提示词。我建议模板里至少预置四到六个高频命令代码审查、测试修复、生成提交信息、解释陌生代码、生成文档、处理 lint 报错。这些都是每天反复出现的动作封装成命令之后手感和效率完全不一样。我用的最多的还是 review直接上示例--- description: 对指定文件做一轮代码审查 argument-hint: 文件或目录路径可留空 --- 你是一名拥有 10 年经验的代码审查工程师。请对 $ARGUMENTS 指向的内容做全面审查如果为空则审查本次会话内修改过的所有文件。 请按以下清单检查 1. 逻辑正确性与边界情况 2. 潜在 bug 与安全隐患 3. 性能瓶颈与不必要的复杂度 4. 与团队代码风格的偏差 输出格式要求 - 按严重程度排序的问题清单 - 每个问题标明位置、原因、修改建议 - 对高风险问题给出可直接落地的示例代码这个文件只有十几行但每次/review的产出都非常稳定。模板的意义就是把这些交互经验固化成文案不用每次现场组织语言。团队成员之间的斜杠命令保持一致之后哪怕是不同的人在干活AI 给出的审查维度、提交信息风格也会趋同这对代码评审非常有帮助。2.3 Hooks 与 settings给模板装上自动闸门斜杠命令是“按需触发”hooks 则是“自动触发”。Claude Code 在关键节点会执行你配置的 hooks 脚本根据脚本返回结果决定是放行、拦截、还是向用户询问。常用的事件包括 PreToolUse工具调用前、PostToolUse工具调用后、UserPromptSubmit用户提交提示词后、Stop一轮生成结束后等等。你可以利用这些事件做危险命令拦截、命令后自动格式化、生成内容后再做一次检查。settings.json 则是配置的总入口模型选择、权限规则、hooks、MCP 服务器都在这里管理。模板里给一份合理的 settings.json 基线配置能省去很多逐个弹出的权限确认对话框同时保留必要的安全拦截。我见过最典型的用法是加一个 PreToolUse 守护 hook把rm -rf /、git push --force这类危险指令在真正执行前拦下来。配置大概长这样{ hooks: { PreToolUse: [ { matcher: Bash(rm -rf /|git push --force), hooks: [ { type: command, command: python3 .claude/hooks/guard.py } ] } ] } }对应的guard.py会根据工具输入里的命令内容做一次匹配命中危险的模式就直接输出 deny 决策阻断动作。这个能力的意义在于它把“不让 AI 乱来”从口头约定变成了代码层面的硬约束。哪怕某个新成员没有把规则写进 CLAUDE.md只要 hooks 文件还在该拦截的还是会拦。3. 实操从零搭一套 claude-code-templates3.1 模板项目怎么组织我建议用这种结构管理模板仓库兼顾通用与差异化claude-code-templates/ ├── README.md ├── template/ │ ├── CLAUDE.md │ ├── CLAUDE.local.md.example │ └── .claude/ │ ├── commands/ │ │ ├── review.md │ │ ├── test.md │ │ ├── commit.md │ │ └── docs.md │ └── settings.json ├── variants/ │ ├── frontend/ │ │ └── CLAUDE.md │ ├── backend/ │ │ └── CLAUDE.md │ └── data/ │ └── CLAUDE.md └── scripts/ └── init.shtemplate 放通用配置variants 放不同技术栈的差异化 CLAUDE.mdscripts 放一键初始化脚本。这样拆分的好处是通用规则不需要每个项目复制三份差异化内容又能按项目类型灵活选择。还有一个容易被忽略的细节一定要把CLAUDE.local.md.example放进模板它用来承载个人偏好默认不提交版本库新成员复制一下就能建立自己的本地记忆。这个文件我以前的模板里一直没有后来发现大家其实都有自己的操作习惯与其让每个人去查文档弄不如直接在模板里留好样例。3.2 核心文件逐段解析下面是我模板里一份通用 CLAUDE.md看着长其实都是给模型吃的“行为准则”# 项目说明 这是一个 [项目类型] 项目核心目标是 [一句话说清楚做什么]。 ## 技术栈与依赖 - 语言与框架[例如 TypeScript React] - 关键依赖[列出最可能被改动的依赖] - 环境要求[Node 版本、包管理器选择] ## 常用命令 - 安装依赖npm install - 本地开发npm run dev - 运行测试npm test - 代码检查npm run lint - 构建产物npm run build ## 目录结构 src/ 存放源代码其中 components/ 放 UI 组件services/ 放接口调用逻辑utils/ 放通用工具函数 tests/ 存放与源码目录对应的测试文件docs/ 存放设计文档。 ## 编码约定 - 组件与文件命名使用 PascalCase - 函数与变量命名使用 camelCase - 状态管理数据必须在 types/ 目录中声明类型 - 所有对外接口必须有注释说明入参与返回值 - 提交信息遵循 Conventional Commits 规范 ## 易错点清单 - 修改数据库 schema 后必须执行 npm run migrate不要忽略迁移文件 - 本地联调使用 .env.development不要误改 .env 中的生产配置 - 测试环境接口走 mock 数据新增接口时要同步更新 mock 定义模板里的占位符比如[项目类型]初始化的时候替换成真实内容即可。重点不是格式多漂亮而是每条规则都来自真实踩坑。你看“易错点清单”那一节里面没有一条是网上抄来的规范全部是项目里实际出现过的问题。正是这些“只有项目内的人才知道的坑”才是 CLAUDE.md 最不可替代的部分。斜杠命令方面除了上文的 reviewcommit 命令也值得直接抄走--- description: 生成规范的 Git 提交信息 argument-hint: 提交说明可留空 --- 根据当前暂存区git diff --cached的变更内容生成符合 Conventional Commits 规范的提交信息。 格式要求type(scope): subject type 可选feat、fix、refactor、docs、test、chore、perf、ci subject 使用祈使句中文表述控制在 50 字以内。 如果提供了 $ARGUMENTS则优先使用该内容作为 subject并补全 type 与 scope。再配一个 test 命令让 AI 先跑测试、再定位失败原因、修复后重新跑把整个闭环固化成指令。这三条命令基本覆盖了日常最耗精力的重复场景。3.3 一键初始化脚本配置写得再好如果每次都是手动复制粘贴用几次就会嫌烦。我给模板仓库配了一个简单脚本一行命令完成复制和占位替换#!/usr/bin/env bash set -euo pipefail TEMPLATE_DIR$(dirname $0)/../template VARIANT_DIR$(dirname $0)/../variants # 1. 复制通用模板到当前项目 cp -r $TEMPLATE_DIR/. . # 2. 选择技术栈变体 read -p 选择项目变体 (frontend/backend/data/general): variant if [ -f $VARIANT_DIR/$variant/CLAUDE.md ]; then cp $VARIANT_DIR/$variant/CLAUDE.md ./CLAUDE.md fi # 3. 列出待替换的占位符提示人工处理 grep -n \[.*\] CLAUDE.md || true echo 模板初始化完成。请检查 CLAUDE.md 并替换所有占位符。脚本本身并不复杂核心价值在于“把复制模板这个动作本身模板化”。你每次想到这里有一步操作就会真的去用如果初始化都靠手工模板很快会变成仓库里吃灰的文件夹。后续可以再演进成接收参数、自动改占位符、初始化 git 仓库的完整脚手架但一上来没必要做太重够用就好。4. 常见问题与排查技巧实录4.1 模板不生效的排查速查表现象可能原因排查方向/review 提示命令不存在.claude/commands目录下没有对应文件或文件名大小写不一致确认文件存在、扩展名为.md、文件名与命令一致CLAUDE.md 内容完全没生效文件不在项目根目录或命名成了 Claude.md确认文件名完全大写 CLAUDE.md位置在项目根目录模板里的中文规范经常被忽略CLAUDE.md 过长核心规则埋在后面精简篇幅、把最高优先级规则放到文件前部Hooks 一直不触发matcher 正则与工具名/命令不匹配临时去掉 matcher 加日志确认真实触发条件settings.json 改动后行为异常JSON 语法错误或字段覆盖关系搞混用 jq 校验 JSON并检查项目级与用户级的合并规则权限弹窗反复出现permissions.allow 范围太窄或没有匹配上在 settings 中按工具名加 allow 规则但保持 deny 规则严格这里要说一个很实际的坑CLAUDE.md 的名字必须全大写。我曾经在某个项目里写成了 Claude.md结果加载的其实是用户级配置导致项目级规则根本没上过线。这种问题不会报错只会表现成“模型行为不符合预期”非常难排查。后来我把文件名检查直接写进了 init 脚本每次初始化先校验不让错误配置有落地机会。4.2 几条实战经验第一模板要区分“知识”和“规则”。技术栈、目录结构属于知识可以放开让模型自由发挥禁止使用的写法、必须执行的步骤属于规则要写得像口令一样明确。知识写太多会稀释规则最后模型对规则的敏感度会下降。第二定期翻看对话记录里模型反复犯错的地方把高频错误回填到 CLAUDE.md。我维护这块模板的小半年里最常用的一句话就是“这个又搞错了加到易错点里”。模板不是静态文件它会跟着项目的坑一起生长这也是它比一次性配置更有价值的原因。第三团队共用一套 templates 仓库时命令和 CLAUDE.md 的改动要像代码一样走 review。不要小看这个动作它是保证模板质量不滑坡的关键。我自己见过一份被后人东加西加的 CLAUDE.md半年后膨胀到上千行最后基本失去了指导意义。轻量化的模板比大而全的模板耐用得多。最后分享一个让我印象很深的改动。有段时间模板里的“提交信息遵循 Conventional Commits”一直执行得不彻底模型偶尔会 commit 出乱七八糟的信息。我后来没有继续加更多描述而是直接把格式要求写成一个/commit命令并在命令里贴了带 type/scope 示例的模板。从那以后提交信息的规范率肉眼可见地稳定了。这件事给我的体会是模板的价值不在于文件多、配置全而在于把人和 AI 之间那些容易失真的协作细节用文件的形式固化下来让每一次新会话都从上次的教训开始。模板要常改常新但一次只解决一个最痛的问题。
如果你也把 Claude Code 当成日常主力开发工具应该体会过那种别扭每次新起一个项目都要重新跟它交代背景、技术栈、目录结构事无巨细地解释代码风格和约定。更烦的是同一件事交给不同人调出来的行为差异很大团队协作时互相对不上频道。我花了两个多月折腾 claude-code-templates把 Claude Code 的配置能力拆成一套可复用的模板体系把项目记忆文件、斜杠命令、自动化钩子、权限设置全部沉淀成标准文件新项目直接复制就能用。这套方案主要解决三个问题新项目重复配置的体力活、团队成员指令风格不统一、以及上下文丢失后重新“调教”的成本。适合正在把 Claude Code 当生产力工具、又不想每次都从零开始配置的人。1. 模板存在的意义把“调教经验”固化成项目资产1.1 先理解 Claude Code 的“记忆”机制Claude Code 每次开始干活之前会先读一批文件作为“工作手册”其中最核心的就是CLAUDE.md。这个名字听起来有点像给 AI 看的 README但定位完全不同README 是给人看的项目简介CLAUDE.md 是给模型看的行为准则。启动时 Claude 会按层级依次加载配置文件距离当前工作目录越近的优先级越高项目根目录放一份CLAUDE.md就相当于告诉模型这个项目用什么语言、有哪些常用命令、遵守什么规范、哪里容易出错。这个机制最值钱的地方在于它不是一次性的。只要文件还在项目里每次新开会话、或者上下文被压缩之后Claude 都会重新加载这份记忆。换句话说你费半天劲调教出来的“懂行”状态沉淀成文件之后可以反复使用。模板体系正是建立在这个机制之上的既然模型的行为很大程度上由这些文件决定那为什么不把一份打磨好的文件变成模板放到所有项目里这才是 claude-code-templates 这类实践真正有价值的原因。1.2 模板到底解决了什么问题第一个场景是项目初始化。以前新项目要跟 Claude 说半天技术栈、目录风格、测试命令现在初始化时直接复制模板该有的上下文都在文件里对话体验是“即插即用”的。第二个场景是团队协作。代码规范、提交信息格式、环境变量管理这些最容易产生分歧的地方只要大家共用一份 templates 仓库AI 产出的代码风格就是稳定的评审时的沟通成本会明显下降。第三个场景是“防失忆”。Claude Code 的上下文窗口再大也是有限的会话频繁切换、任务被打断是家常便饭。没有模板的时候重新开一个会话就得原地做一次知识迁移有模板之后只要文件还躺在项目里随时可以无损恢复。我在实际维护中还发现一个更隐性的收益模板会逼迫你把项目里的隐性知识显性化。很多人对“自己的项目”很有把握但要写清楚目录是干嘛的、哪条命令不能乱跑、哪个模块最容易踩坑反而要花点心思。这份思考本身就是价值对后面加入项目的新人尤其友好。1.3 模板不是越全越好一开始很容易陷入一个误区把所有想到的规则都塞进模板恨不得把团队 Wiki 全文搬进去。但 Claude 的上下文处理能力是有限的即使能读进来信息之间也会互相干扰。我曾经在某份 CLAUDE.md 里写了几百行“完整规范”结果模型反而抓不住重点连最基础的要求都会遗漏。后来我把规范砍到核心的二十条左右之前频繁出错的问题反而消失了。模板应该是一份“重点提示卡”不是百科全书。它记录的是模型最容易搞错、以及项目里最不希望它搞砸的事情其他内容应该留给代码本身和常规文档。判断一条规则该不该写进模板有个很简单的标准这条规则如果被 AI 违反了造成的后果严重吗如果严重那就值得占用一个位置如果只是“更好看”放行就行。2. 模板体系的解剖从 CLAUDE.md 到斜杠命令2.1 CLAUDE.md项目记忆体怎么写才有效一份好用的 CLAUDE.md至少包含六个模块项目一句话定位、技术栈与环境要求、常用命令、目录结构说明、编码约定、易错点清单。写的时候有几个讲究。一是语言要直接。Claude 是按字面理解指令的你写“最好使用 TypeScript”它就可能选择不用写成“类型定义必须使用 TypeScript禁止使用 any”约束力立刻不一样。二是按优先级排序把最核心、违反代价最高的规则放在最前面因为长文档后段的内容在上下文处理中更容易被弱化。三是定期维护项目换技术栈、目录重构之后CLAUDE.md 也要跟着更新否则放着不管的模板会逐渐变成“过期地图”。不同层级的配置文件可以叠加生效距离项目越近的优先级越高。我整理了一个速查表方便对照文件位置作用范围典型内容企业级配置如组织的全局 CLAUDE.md整个组织合规要求、通用编码规范项目根目录 CLAUDE.md当前项目技术栈、命令、易错点用户目录 ~/.claude/CLAUDE.md所有项目个人偏好、通用工作流CLAUDE.local.md单个项目补充本地实验性配置不入版本库实际使用中项目级 CLAUDE.md 最容易出现的问题是“野心过大”。我见过有人把公司安全规范、设计模式、命名规范汇总全部写进去结果模型每次行为都变得畏手畏脚。记住一个原则CLAUDE.md 不是给 AI 上刑它服务的核心目标是让 AI 在自由发挥时不踩你项目里真正的红线。2.2 斜杠命令把重复操作固化成可复用指令CLAUDE.md 解决的是“让模型懂项目”斜杠命令解决的是“让模型会做事”。Claude Code 支持自定义斜杠命令把一串复杂的提示词封装成一个指令。项目级放在.claude/commands目录用户级放在~/.claude/commands目录每个.md文件就是一个命令文件名去掉.md就是触发词。命令文件支持 YAML frontmatter可以声明 description、argument-hint 等元信息。你还可以在命令正文里用$ARGUMENTS引用用户输入。比如创建一个commit.md内容是一套提交信息生成规范那么/commit就会直接触发这套流程不再需要每次现场口述。这跟你平时在编辑器里写代码片段是同一个道理只是封装的对象从代码变成了提示词。我建议模板里至少预置四到六个高频命令代码审查、测试修复、生成提交信息、解释陌生代码、生成文档、处理 lint 报错。这些都是每天反复出现的动作封装成命令之后手感和效率完全不一样。我用的最多的还是 review直接上示例--- description: 对指定文件做一轮代码审查 argument-hint: 文件或目录路径可留空 --- 你是一名拥有 10 年经验的代码审查工程师。请对 $ARGUMENTS 指向的内容做全面审查如果为空则审查本次会话内修改过的所有文件。 请按以下清单检查 1. 逻辑正确性与边界情况 2. 潜在 bug 与安全隐患 3. 性能瓶颈与不必要的复杂度 4. 与团队代码风格的偏差 输出格式要求 - 按严重程度排序的问题清单 - 每个问题标明位置、原因、修改建议 - 对高风险问题给出可直接落地的示例代码这个文件只有十几行但每次/review的产出都非常稳定。模板的意义就是把这些交互经验固化成文案不用每次现场组织语言。团队成员之间的斜杠命令保持一致之后哪怕是不同的人在干活AI 给出的审查维度、提交信息风格也会趋同这对代码评审非常有帮助。2.3 Hooks 与 settings给模板装上自动闸门斜杠命令是“按需触发”hooks 则是“自动触发”。Claude Code 在关键节点会执行你配置的 hooks 脚本根据脚本返回结果决定是放行、拦截、还是向用户询问。常用的事件包括 PreToolUse工具调用前、PostToolUse工具调用后、UserPromptSubmit用户提交提示词后、Stop一轮生成结束后等等。你可以利用这些事件做危险命令拦截、命令后自动格式化、生成内容后再做一次检查。settings.json 则是配置的总入口模型选择、权限规则、hooks、MCP 服务器都在这里管理。模板里给一份合理的 settings.json 基线配置能省去很多逐个弹出的权限确认对话框同时保留必要的安全拦截。我见过最典型的用法是加一个 PreToolUse 守护 hook把rm -rf /、git push --force这类危险指令在真正执行前拦下来。配置大概长这样{ hooks: { PreToolUse: [ { matcher: Bash(rm -rf /|git push --force), hooks: [ { type: command, command: python3 .claude/hooks/guard.py } ] } ] } }对应的guard.py会根据工具输入里的命令内容做一次匹配命中危险的模式就直接输出 deny 决策阻断动作。这个能力的意义在于它把“不让 AI 乱来”从口头约定变成了代码层面的硬约束。哪怕某个新成员没有把规则写进 CLAUDE.md只要 hooks 文件还在该拦截的还是会拦。3. 实操从零搭一套 claude-code-templates3.1 模板项目怎么组织我建议用这种结构管理模板仓库兼顾通用与差异化claude-code-templates/ ├── README.md ├── template/ │ ├── CLAUDE.md │ ├── CLAUDE.local.md.example │ └── .claude/ │ ├── commands/ │ │ ├── review.md │ │ ├── test.md │ │ ├── commit.md │ │ └── docs.md │ └── settings.json ├── variants/ │ ├── frontend/ │ │ └── CLAUDE.md │ ├── backend/ │ │ └── CLAUDE.md │ └── data/ │ └── CLAUDE.md └── scripts/ └── init.shtemplate 放通用配置variants 放不同技术栈的差异化 CLAUDE.mdscripts 放一键初始化脚本。这样拆分的好处是通用规则不需要每个项目复制三份差异化内容又能按项目类型灵活选择。还有一个容易被忽略的细节一定要把CLAUDE.local.md.example放进模板它用来承载个人偏好默认不提交版本库新成员复制一下就能建立自己的本地记忆。这个文件我以前的模板里一直没有后来发现大家其实都有自己的操作习惯与其让每个人去查文档弄不如直接在模板里留好样例。3.2 核心文件逐段解析下面是我模板里一份通用 CLAUDE.md看着长其实都是给模型吃的“行为准则”# 项目说明 这是一个 [项目类型] 项目核心目标是 [一句话说清楚做什么]。 ## 技术栈与依赖 - 语言与框架[例如 TypeScript React] - 关键依赖[列出最可能被改动的依赖] - 环境要求[Node 版本、包管理器选择] ## 常用命令 - 安装依赖npm install - 本地开发npm run dev - 运行测试npm test - 代码检查npm run lint - 构建产物npm run build ## 目录结构 src/ 存放源代码其中 components/ 放 UI 组件services/ 放接口调用逻辑utils/ 放通用工具函数 tests/ 存放与源码目录对应的测试文件docs/ 存放设计文档。 ## 编码约定 - 组件与文件命名使用 PascalCase - 函数与变量命名使用 camelCase - 状态管理数据必须在 types/ 目录中声明类型 - 所有对外接口必须有注释说明入参与返回值 - 提交信息遵循 Conventional Commits 规范 ## 易错点清单 - 修改数据库 schema 后必须执行 npm run migrate不要忽略迁移文件 - 本地联调使用 .env.development不要误改 .env 中的生产配置 - 测试环境接口走 mock 数据新增接口时要同步更新 mock 定义模板里的占位符比如[项目类型]初始化的时候替换成真实内容即可。重点不是格式多漂亮而是每条规则都来自真实踩坑。你看“易错点清单”那一节里面没有一条是网上抄来的规范全部是项目里实际出现过的问题。正是这些“只有项目内的人才知道的坑”才是 CLAUDE.md 最不可替代的部分。斜杠命令方面除了上文的 reviewcommit 命令也值得直接抄走--- description: 生成规范的 Git 提交信息 argument-hint: 提交说明可留空 --- 根据当前暂存区git diff --cached的变更内容生成符合 Conventional Commits 规范的提交信息。 格式要求type(scope): subject type 可选feat、fix、refactor、docs、test、chore、perf、ci subject 使用祈使句中文表述控制在 50 字以内。 如果提供了 $ARGUMENTS则优先使用该内容作为 subject并补全 type 与 scope。再配一个 test 命令让 AI 先跑测试、再定位失败原因、修复后重新跑把整个闭环固化成指令。这三条命令基本覆盖了日常最耗精力的重复场景。3.3 一键初始化脚本配置写得再好如果每次都是手动复制粘贴用几次就会嫌烦。我给模板仓库配了一个简单脚本一行命令完成复制和占位替换#!/usr/bin/env bash set -euo pipefail TEMPLATE_DIR$(dirname $0)/../template VARIANT_DIR$(dirname $0)/../variants # 1. 复制通用模板到当前项目 cp -r $TEMPLATE_DIR/. . # 2. 选择技术栈变体 read -p 选择项目变体 (frontend/backend/data/general): variant if [ -f $VARIANT_DIR/$variant/CLAUDE.md ]; then cp $VARIANT_DIR/$variant/CLAUDE.md ./CLAUDE.md fi # 3. 列出待替换的占位符提示人工处理 grep -n \[.*\] CLAUDE.md || true echo 模板初始化完成。请检查 CLAUDE.md 并替换所有占位符。脚本本身并不复杂核心价值在于“把复制模板这个动作本身模板化”。你每次想到这里有一步操作就会真的去用如果初始化都靠手工模板很快会变成仓库里吃灰的文件夹。后续可以再演进成接收参数、自动改占位符、初始化 git 仓库的完整脚手架但一上来没必要做太重够用就好。4. 常见问题与排查技巧实录4.1 模板不生效的排查速查表现象可能原因排查方向/review 提示命令不存在.claude/commands目录下没有对应文件或文件名大小写不一致确认文件存在、扩展名为.md、文件名与命令一致CLAUDE.md 内容完全没生效文件不在项目根目录或命名成了 Claude.md确认文件名完全大写 CLAUDE.md位置在项目根目录模板里的中文规范经常被忽略CLAUDE.md 过长核心规则埋在后面精简篇幅、把最高优先级规则放到文件前部Hooks 一直不触发matcher 正则与工具名/命令不匹配临时去掉 matcher 加日志确认真实触发条件settings.json 改动后行为异常JSON 语法错误或字段覆盖关系搞混用 jq 校验 JSON并检查项目级与用户级的合并规则权限弹窗反复出现permissions.allow 范围太窄或没有匹配上在 settings 中按工具名加 allow 规则但保持 deny 规则严格这里要说一个很实际的坑CLAUDE.md 的名字必须全大写。我曾经在某个项目里写成了 Claude.md结果加载的其实是用户级配置导致项目级规则根本没上过线。这种问题不会报错只会表现成“模型行为不符合预期”非常难排查。后来我把文件名检查直接写进了 init 脚本每次初始化先校验不让错误配置有落地机会。4.2 几条实战经验第一模板要区分“知识”和“规则”。技术栈、目录结构属于知识可以放开让模型自由发挥禁止使用的写法、必须执行的步骤属于规则要写得像口令一样明确。知识写太多会稀释规则最后模型对规则的敏感度会下降。第二定期翻看对话记录里模型反复犯错的地方把高频错误回填到 CLAUDE.md。我维护这块模板的小半年里最常用的一句话就是“这个又搞错了加到易错点里”。模板不是静态文件它会跟着项目的坑一起生长这也是它比一次性配置更有价值的原因。第三团队共用一套 templates 仓库时命令和 CLAUDE.md 的改动要像代码一样走 review。不要小看这个动作它是保证模板质量不滑坡的关键。我自己见过一份被后人东加西加的 CLAUDE.md半年后膨胀到上千行最后基本失去了指导意义。轻量化的模板比大而全的模板耐用得多。最后分享一个让我印象很深的改动。有段时间模板里的“提交信息遵循 Conventional Commits”一直执行得不彻底模型偶尔会 commit 出乱七八糟的信息。我后来没有继续加更多描述而是直接把格式要求写成一个/commit命令并在命令里贴了带 type/scope 示例的模板。从那以后提交信息的规范率肉眼可见地稳定了。这件事给我的体会是模板的价值不在于文件多、配置全而在于把人和 AI 之间那些容易失真的协作细节用文件的形式固化下来让每一次新会话都从上次的教训开始。模板要常改常新但一次只解决一个最痛的问题。
