我真正开始把 Claude Code 当作主力开发工具是半年多以前的事。那时候我还处于“终端里开个会话让它改个函数、写个单测”的阶段新鲜感退得很快因为问题也很明显同一个项目的两次会话它的表现经常像两个不同的人上午刚定下的架构约定下午它就忘得干干净净一旦涉及跨文件重构它自己都停不下来你根本不敢让它跑太久。后来我陆续试过各种项目级提示词、规则文件、任务描述模板折腾了大半个月最终沉淀成了这套claude-code-templates工程。这是一套可以克隆、可以直接改、也可以按团队习惯二次定制的 Claude Code 项目模板核心是把 AI 编程从“人追着模型擦屁股”变成“规则驱动、记忆闭环、流程可控”的工程化工作流。这篇文章会把我的设计思路、关键文件的写法、接入一个真实项目的完整过程以及我踩过的坑一次讲清楚适合已经用上 Claude Code 但总觉得它“不够稳”的开发者也适合正在给团队搭建 AI 辅助编程规范的负责人。1. 为什么需要一套 Claude Code 模板先聊三个失控现场很多人的第一反应是Claude Code 不是天生就能聊吗给它一个终端它自己会读文件、会跑命令、会改代码为什么还要搞一套模板我一开始也这么想直到我连续经历了下面三个典型的失控场景。第一个场景是“规则失忆”。我在项目里用中文在根目录写过一份非常详细的规则文件里面明确写了“所有新增接口必须带 OpenAPI 注释”“错误处理统一走 Result 类型”“禁止直接修改数据库表结构”。会话刚开头的第一轮对话它表现得堪称完美完全照着规则走。但是聊到十几轮之后当问题从“改一个函数”变成“给整个模块增加新接口”时它开始自作主张地把返回类型从 Result 换成了裸对象还顺手动了数据库迁移文件的命名。不是它笨而是长上下文里规则被稀释了模型根本没把几十轮之前的那些“背景约定”当成强约束。后来我发现问题不在模型本身而在于我把规则和任务混在了一起没有做结构化的隔离。第二个场景是“记忆断层”。今天让 Claude Code 做完了用户模块的重构它自己也说了“下次可以从 XX 函数继续拆分”。第二天重新打开终端新会话完全不知道昨天发生过什么。你不得不把昨天聊过的内容重新给它讲一遍讲到一半还会发现有些细节你给不出答案“你昨天不是看过吗”这种对话效率真的低下。Claude Code 本身有一些会话恢复机制但项目级、跨会话的长期记忆如果不主动设计根本不会自己长出来。第三个场景是“流程失控”。我让 Claude Code 帮忙做一次“全项目代码审查”它把每个模块都“审”了一遍输出了一份五十多页的报告。打开一看80% 的内容都是正确的废话比如“建议增强错误处理”“建议补充注释”。真正出问题的两个文件它完全没抓到重点。后来我意识到不是它的能力不够而是我没有给它定义“审查什么、以什么格式输出、哪些问题优先级最高”。AI 编程工具和普通代码的不同就在这普通代码是你写一步它执行一步而 Claude Code 这类工具你的输入质量直接决定它的输出边界。如果你也遇到过类似的情况那么模板解决的问题其实就四个字确定性。不是让 Claude Code 每次都说一模一样的话而是让它在正确的边界内自由发挥。下面这套模板就是围绕这个目标搭的。2. 模板结构拆解每一个文件都有明确职责这套模板的目录结构最初被朋友吐槽“多此一举”用了两个星期之后他又问我能不能直接抄到他团队去。结构其实不复杂但每一层都有清晰的任务边界claude-code-templates/ ├── CLAUDE.md # 全局行为总纲相当于系统提示词落盘 ├── templates/ │ ├── task.md # 单次任务的标准描述模板 │ ├── feature.md # 功能开发任务模板 │ ├── refactor.md # 重构任务模板 │ ├── review.md # 代码审查任务模板 │ └── commit.md # 提交信息生成模板 ├── rules/ │ ├── coding-style.md # 编码风格与语言约定 │ ├── architecture.md # 架构约束与模块边界 │ ├── security.md # 安全红线与数据合规 │ └── workflow.md # 分支策略与提交流程 ├── memory/ │ ├── decisions.md # 重大技术决策记录 │ ├── progress.md # 当前进度与下一步计划 │ ├── learned.md # 经验库踩过的坑与教训 │ └── README.md # 记忆文件使用规范 ├── scripts/ │ ├── init.sh # 一键初始化项目变量 │ ├── update-memory.sh # 会话结束前同步记忆文件 │ └── user-research.sh # 对指定文件做需求澄清 └── config/ ├── commands.yaml # 自定义斜杠命令 └── settings.json # Claude Code 运行参数先说总纲CLAUDE.md。它是 Claude Code 一进项目就会读取的文件相当于它的“入职培训手册”。你可以想象一个新程序员入职第一天你什么都不给他看直接拉他上线改代码他大概率会出事但如果先让他熟读团队规范、了解项目结构、知道找谁问、知道哪些事情绝对不能碰他上手速度和下限都会有保障。CLAUDE.md干的就是这件事它是整个模板的“元规则”其他所有规则文件、模板文件、脚本都是它的子集。templates/目录解决的是“每次任务的起点尽可能好”。很多人用 Claude Code 失败的另一个原因是任务描述写得太随笔比如“把这个按钮改好看点”。这个描述人听了都头大更别提模型。任务模板的价值在于强制你补齐上下文目标、当前状态、约束条件、验收标准、涉及文件。这样模型不用猜它只需要执行而执行恰恰是它的强项。rules/目录是项目规则的细分化拆分。为什么不把所有规则塞进一个文件因为 Claude Code 读取长文件时前面内容的优先级往往高于后面如果CLAUDE.md里写了两百条规则它真正执行时大概率只记得前几十条。拆成coding-style、architecture、security、workflow几个文件然后在CLAUDE.md里通过“按需引入”的方式串起来效果会好很多。这一点我在第 4 节会展开讲。memory/是整个模板的灵魂。前面提到的“第二天失忆”问题就是靠它解决。设计上它模拟了人的工作记忆decisions.md记“为什么这么写”progress.md记“现在写到哪了”learned.md记“哪些东西踩过坑”。每次会话结束前让 Claude Code 调用scripts/update-memory.sh把新信息同步进去下一次会话开局先让它读这三个文件就能实现非常自然的“衔接感”。scripts/目录是模板里的自动化层。Claude Code 本身有很强的工具调用能力所以脚本不需要写得多复杂每一个都是一两句核心逻辑。init.sh用于把模板里的占位符替换成真实项目名update-memory.sh负责汇总会话变更user-research.sh是一个很有意思的脚本它的作用是主动追问需求而不是等着你给指令。这个后面会说到具体实践。一句话总结模板的整体设计**CLAUDE.md定边界rules/定准则templates/定格式memory/定记忆scripts/定流程**。五个维度各自独立又互相咬合。3. 核心干货五个关键文件到底怎么写模板的目录结构清楚了但如果你直接克隆下来一跑大概率还是用不好。因为关键在于每个文件里的内容质量而不只是文件在不在。这里我挑五个最核心的文件直接把我现在项目里在用的内容分享出来并解释为什么这么写。3.1 CLAUDE.md不要写规则要写“决策框架”很多人写CLAUDE.md最大的问题是把它写成了流水账。什么“请遵守项目规范”“请编写高质量代码”“请注意性能和安全”全是废话。模型每句话都读进去了但等于什么都没说。我现在的CLAUDE.md开头是这样的结构# 项目角色 你是一个资深全栈工程师负责本项目claude-code-templates的日常开发与维护。 在动手前先读 memory/README.md了解当前项目状态与历史决策。 # 工作流程按优先级 1. 每当接到任务先判断任务类型功能开发/重构/修复/审查并从 templates/ 中选择对应模板。 2. 如果任务描述不满足模板要求先要求补充不要直接动手。 3. 每次修改代码前先说明你的修改方案和影响面。 4. 每次修改后运行相关测试与构建命令没有测试覆盖的模块必须说明原因。 5. 每次会话结束前调用 scripts/update-memory.sh 更新记忆文件。 # 绝对禁止 1. 不得直接执行破坏性命令rm -rf、drop table、强制 push 等除非用户明确确认。 2. 不得修改 memory/ 之外的记忆文件。 3. 不得绕过 rules/ 中的编码规范包括为了“省事”而复制粘贴重复代码。 4. 不得在没有运行测试的情况下声称“已完成”。 # 决策框架 - 当需求不够清晰时主动列出假设清单并请求确认。 - 当两个技术方案同时可行时优先选择改动范围更小、可回滚性更强的方案。 - 当需要新增依赖时先说明目的、体积、维护状态等待用户确认。你看这里面几乎没有“要写高质量代码”这种话取而代之的是可执行的具体动作和时间点。模型读完之后它的行为模式不是“我要做个好助手”而是“我是这个项目里带约束的工程师先分析、再方案、再执行、最后汇报”。哪怕它遇到没有在规则里明确写的新情况也能通过“决策框架”推断出你应该希望它怎么选。这比穷举规则要高效得多。3.2 task.md 任务模板把模糊需求变成可执行规格任务模板的设计原则是让模型在动手前先自己完成一次需求澄清。很多人觉得模板麻烦但真正跑过一次之后你会发现它省下的时间远超写模板的时间。我日常用的 task.md 是这样的# 任务{一句话描述} ## 背景 {解释这个任务为什么存在现在的痛点是什么} ## 现状 {当前相关代码路径、文件状态、技术栈版本} ## 目标 {期望交付的结果尽量可量化} ## 约束 {必须遵守的规则来自 rules/ 目录的引用} ## 验收标准 - [ ] {标准1} - [ ] {标准2} ## 涉及文件 {预计需要修改/新增的文件清单} ## 风险与影响面 {可能会影响到的模块、接口、数据}这张模板的价值在哪里它把“任务描述”从一段话变成了一个结构化的问题集。模型看任务时会对每一个字段做信息补齐如果背景缺失它会主动问如果验收标准没有它会在方案里补一个再让你确认。这个过程比你想象中更重要因为它把“猜”变成了“确认”。3.3 memory/ 记忆机制让长线项目真正接得上记忆文件的写法很容易走偏。有人把它写成了日志流水账昨天改了什么、今天改了什么全是动作记录。但你要知道模型的记忆机制不是人脑的日记本它需要的是决策上下文和下一步入口。decisions.md的推荐结构是“结论 原因 参与方 时间”比如## 2025-02-10后端返回结构统一为 ResultT - 原因前端多个页面需要统一错误处理直接返回 HttpStatus 造成重复代码 - 影响涉及 user、order、payment 三个模块 - 备注迁移期间保留旧接口兼容层预计一个迭代后删除progress.md的推荐结构是“当前阶段 已完成 待办 阻塞项”。尤其“阻塞项”一定要写否则下一次会话它只会反复尝试已经失败过的事情。learned.md是经验库。比如“项目中不能用 XX 框架的原因因为和 YY 的版本冲突”“测试环境数据库是只读的不能指望写入数据”。这些经验每一条都是从事故里来的写下来之后同一个坑不会再踩第二次。这里有个特别重要的操作技巧记忆文件的更新必须由 Claude Code 自己写而不是你手动编辑。原因很简单它自己写出来的内容会更贴近它的上下文理解你人肉写的东西在它读起来可能缺上下文。用scripts/update-memory.sh触发让它自己把这次会话的信息提炼、去重、归类。3.4 scripts/user-research.sh让 AI 先问问题这个脚本是我自己觉得最“反直觉”但也最实用的一个。传统用法是你给 Claude Code 下命令它干活这个脚本反过来它拿到一个需求之后先向你提问。#!/usr/bin/env bash # 用法: claude 读一下 templates/task.md 和 scripts/user-research.sh然后对下面这个需求执行需求澄清 # 需求: $1 echo 当前需求描述$1 echo echo 请按 task.md 的字段逐个确认 echo 1. 这个任务的背景和动机是什么 echo 2. 当前代码中哪个文件/模块最有可能被影响 echo 3. 可量化的交付标准是什么 echo 4. 有哪些隐藏约束 echo 5. 风险点在哪里真正跑起来之后它的效果超出预期。有一次我丢给它一个含糊的任务“把首页搜索体验优化一下”它没有直接改代码而是问了我五个问题“搜索目前是调后端接口还是前端过滤是否有分页搜索结果的排序规则是什么历史上有没有相关性能问题优化目标主要是速度还是命中率”这些问题每一条都命中了我之前没说出来的关键信息。这种交互模式本质上是把“提示工程”的负担从用户手里转移到了模板和脚本上。3.5 rules/ 拆分规则与按需引用的写法前面提过规则不能全堆在CLAUDE.md里。这里说下我的具体做法。我在CLAUDE.md里写了一段“规则导航”# 规则引用 遇到代码风格问题先读 rules/coding-style.md。 涉及模块划分或依赖方向读 rules/architecture.md。 改动涉及用户数据或权限必须读 rules/security.md。 准备提交代码时读 rules/workflow.md。这样 Claude Code 在做不同任务时会主动去翻阅相关规则文件而不是永远只靠CLAUDE.md里的“核心记忆”。打个比方CLAUDE.md是大脑前额叶负责决策和计划rules/是外挂知识库负责深度知识提取。模型在有明确触发条件的情况下会主动去查外挂知识库这个动作比把知识强行塞进上下文要靠谱得多。经验上每个rules/文件不要超过 80 行。如果超过 80 行说明你写的不是规则而是论文。规则文件越长越容易被模型整体忽略。短文件还有一个好处模型可以自己判断“什么时候该去读”而不是每轮对话都要顶着几千字的规则负担。4. 从模板到实战接入一个真实项目的完整流程光有文件还不够模板要在一个项目里真正起作用需要一套比较讲究的“交接仪式”。这里是我在接入第二个项目时打磨出来的完整流程每一步都踩过坑。第一步克隆模板到项目目录并清理掉示例内容。直接复制文件进来但不要保留模板自带的占位符。运行scripts/init.sh它会统一替换整个模板里的变量名包括项目名称、默认分支、包管理器等。没有这一步后面每新建一个文件都会带着另一个项目的影子。第二步根据项目的技术栈裁剪规则文件。比如你的项目是 Go 微服务那么coding-style.md里关于前端状态的规则就要删掉补上 Go 的 lint 规则如果你的项目是单体 Rails 应用那么architecture.md里关于服务间通信的部分也要改。这一轮裁剪本质是把“通用模板”变成“本项目专用规范”偷懒不得。第三步把项目已有的文档精华吸收进memory/。这是最关键的一步。每个项目几乎都有一些散落在需求文档、架构图、甚至聊天记录里的历史决策花半天时间把这些内容手动整理进decisions.md和learned.md。这会成为新会话的“项目常识”直接决定 Claude Code 上线第一天的表现。不要省这个时间我第一次接入一个老项目时跳过了这一步结果它对着一个已废弃的模块问“这个模块是干什么的”非常尴尬。第四步用一个小任务做“验收测试”。不要一上来就丢一个大重构先让它改一个简单但涉及多文件的 feature比如“给用户列表增加按时间筛选功能”。观察它有没有先读模板、有没有按templates/feature.md的结构做方案、有没有主动查询rules/和memory/。如果它绕过了这些流程大概率是CLAUDE.md里的指示写得不够明确回到第 3.1 节重新调整措辞。第五步开始一个新会话前先发送这样一条指令先读 memory/README.md 和 memory/decisions.md确认你对当前项目的背景和进度已经掌握然后再开始任务。这句话非常短但它会触发 Claude Code 先去加载记忆文件而这个动作会极大减少“我上次不知道我们在做什么”的尴尬。我实测下来加上这句话和直接开聊产出质量差距真的很大。这套流程走完之后项目就算“接入模板”了。真正稳定运行两三天后你会明显感觉到 Claude Code 的行为模式发生了质变它不再是一个“你问一句它答一句”的聊天机器人更像一个知道项目背景、知道边界在哪里、也知道怎么汇报的审查严格的协作者。5. 常见问题排查与避坑技巧实录模板跑了几个月我也在两个团队里推广过遇到过不少典型问题。整理一个故障速查表方便你直接对号入座。现象根因解决方案规则文件完全没生效Claude Code 我行我素CLAUDE.md 里规则太多、太泛模型上下文里被淹没精简 CLAUDE.md 到 40 行内只留流程与红线细则拆分到 rules/同一个问题反复问明明上次已经答过没有更新 memory/learned.md会话间没有共享经验每次会话结束前强制运行 scripts/update-memory.shClaude Code 过度保守什么都不敢改只输出建议不动手安全规则写得过于严密比如把所有命令都列为“禁止”区分“绝对禁止”破坏性命令与“需确认”常规命令给模型留出操作空间记忆文件越写越多最后变成一坨没人看的东西记忆文件缺少目录和摘要更新时没有去重在 memory/README.md 里规定每个文件只保留最近 10 条过期内容归档到 memory/archive/任务模板内容填得太空AI 还是照猜的用户跳过“需求澄清”步骤直接让模型干活用 scripts/user-research.sh 让模型先问问题确认完字段再进入执行模型“忘记”了架构约定自己画了新方案架构约束只存在于旧文档里没有归入 decisions.md每次架构讨论结束后立刻让 Claude Code 更新 decisions.md并标注“下次会话必须读取”5.1 深聊一个关键坑规则太多反而失控很多第一次用模板的人都有一个通病觉得规则写得多就是防御拉满。我在自己第一个项目里就犯过这个错CLAUDE.md一口气写了 150 行涵盖了从“变量命名”到“数据库索引规范”的所有内容。结果呢模型确实“看起来”更乖了但这种乖是虚假的乖因为它在长任务里根本守不住那 150 行规则它开始只执行它最容易记得住的“安全红线”而把大量业务逻辑细节全部忽略。这个现象背后是模型注意力分布的问题上下文窗口虽然是够用的但人对长指令的遵循本身就存在衰减模型也是一样。把规则写得简短、可操作、放在文件头部比堆砌内容更重要。我现在的黄金经验是总规则文件不要超过 60 行细则文件每个不超过 80 行一次会话内让模型主动引用的规则文件不要超过 2 个。超过这个阈值效果就会边际递减。5.2 记忆文件更新的最佳实践谁负责、什么时候负责模板里的update-memory.sh我一开始设计成“每次会话结束前手动运行”但实际用下来人在高强度改代码的时候往往会忘。后来我调整了策略在CLAUDE.md的工作流程里明确写了一句“任务完成并验证通过后自动调用 scripts/update-memory.sh”。同时脚本本身也做了增强它会把自上次更新以来的新增决策、进度变化、踩坑经验先对比现有记忆文件再做去重和合并而不是无脑追加。这里有个实测的小心得模型自己写的记忆记录往往比人更准确因为它是在对话上下文中直接生成的不会遗漏那些“你当时觉得不重要后来才发现很关键”的细节。所以不要嫌它写得啰嗦先让它自由写再定期做一轮人工精简就够了。5.3 模板的二次定制不同技术栈要改哪里模板目前虽然开源给了团队但每个团队最后还是会长成自己的形态这是好事。做定制的时候我建议优先关注以下几个点rules/coding-style.md永远是最需要定制的地方。语言规范、lint 配置、格式化工具不同技术栈差异太大。rules/architecture.md在微服务和单体项目里完全是两回事不要照抄。templates/feature.md也要根据团队流程调整比如你们强制要求先写接口文档那就在模板里加上“接口文档先行”字段。配置方面config/settings.json里我会改模型温 从失控到可控：用Claude Code模板打造工程化AI编程工作流
我真正开始把 Claude Code 当作主力开发工具是半年多以前的事。那时候我还处于“终端里开个会话让它改个函数、写个单测”的阶段新鲜感退得很快因为问题也很明显同一个项目的两次会话它的表现经常像两个不同的人上午刚定下的架构约定下午它就忘得干干净净一旦涉及跨文件重构它自己都停不下来你根本不敢让它跑太久。后来我陆续试过各种项目级提示词、规则文件、任务描述模板折腾了大半个月最终沉淀成了这套claude-code-templates工程。这是一套可以克隆、可以直接改、也可以按团队习惯二次定制的 Claude Code 项目模板核心是把 AI 编程从“人追着模型擦屁股”变成“规则驱动、记忆闭环、流程可控”的工程化工作流。这篇文章会把我的设计思路、关键文件的写法、接入一个真实项目的完整过程以及我踩过的坑一次讲清楚适合已经用上 Claude Code 但总觉得它“不够稳”的开发者也适合正在给团队搭建 AI 辅助编程规范的负责人。1. 为什么需要一套 Claude Code 模板先聊三个失控现场很多人的第一反应是Claude Code 不是天生就能聊吗给它一个终端它自己会读文件、会跑命令、会改代码为什么还要搞一套模板我一开始也这么想直到我连续经历了下面三个典型的失控场景。第一个场景是“规则失忆”。我在项目里用中文在根目录写过一份非常详细的规则文件里面明确写了“所有新增接口必须带 OpenAPI 注释”“错误处理统一走 Result 类型”“禁止直接修改数据库表结构”。会话刚开头的第一轮对话它表现得堪称完美完全照着规则走。但是聊到十几轮之后当问题从“改一个函数”变成“给整个模块增加新接口”时它开始自作主张地把返回类型从 Result 换成了裸对象还顺手动了数据库迁移文件的命名。不是它笨而是长上下文里规则被稀释了模型根本没把几十轮之前的那些“背景约定”当成强约束。后来我发现问题不在模型本身而在于我把规则和任务混在了一起没有做结构化的隔离。第二个场景是“记忆断层”。今天让 Claude Code 做完了用户模块的重构它自己也说了“下次可以从 XX 函数继续拆分”。第二天重新打开终端新会话完全不知道昨天发生过什么。你不得不把昨天聊过的内容重新给它讲一遍讲到一半还会发现有些细节你给不出答案“你昨天不是看过吗”这种对话效率真的低下。Claude Code 本身有一些会话恢复机制但项目级、跨会话的长期记忆如果不主动设计根本不会自己长出来。第三个场景是“流程失控”。我让 Claude Code 帮忙做一次“全项目代码审查”它把每个模块都“审”了一遍输出了一份五十多页的报告。打开一看80% 的内容都是正确的废话比如“建议增强错误处理”“建议补充注释”。真正出问题的两个文件它完全没抓到重点。后来我意识到不是它的能力不够而是我没有给它定义“审查什么、以什么格式输出、哪些问题优先级最高”。AI 编程工具和普通代码的不同就在这普通代码是你写一步它执行一步而 Claude Code 这类工具你的输入质量直接决定它的输出边界。如果你也遇到过类似的情况那么模板解决的问题其实就四个字确定性。不是让 Claude Code 每次都说一模一样的话而是让它在正确的边界内自由发挥。下面这套模板就是围绕这个目标搭的。2. 模板结构拆解每一个文件都有明确职责这套模板的目录结构最初被朋友吐槽“多此一举”用了两个星期之后他又问我能不能直接抄到他团队去。结构其实不复杂但每一层都有清晰的任务边界claude-code-templates/ ├── CLAUDE.md # 全局行为总纲相当于系统提示词落盘 ├── templates/ │ ├── task.md # 单次任务的标准描述模板 │ ├── feature.md # 功能开发任务模板 │ ├── refactor.md # 重构任务模板 │ ├── review.md # 代码审查任务模板 │ └── commit.md # 提交信息生成模板 ├── rules/ │ ├── coding-style.md # 编码风格与语言约定 │ ├── architecture.md # 架构约束与模块边界 │ ├── security.md # 安全红线与数据合规 │ └── workflow.md # 分支策略与提交流程 ├── memory/ │ ├── decisions.md # 重大技术决策记录 │ ├── progress.md # 当前进度与下一步计划 │ ├── learned.md # 经验库踩过的坑与教训 │ └── README.md # 记忆文件使用规范 ├── scripts/ │ ├── init.sh # 一键初始化项目变量 │ ├── update-memory.sh # 会话结束前同步记忆文件 │ └── user-research.sh # 对指定文件做需求澄清 └── config/ ├── commands.yaml # 自定义斜杠命令 └── settings.json # Claude Code 运行参数先说总纲CLAUDE.md。它是 Claude Code 一进项目就会读取的文件相当于它的“入职培训手册”。你可以想象一个新程序员入职第一天你什么都不给他看直接拉他上线改代码他大概率会出事但如果先让他熟读团队规范、了解项目结构、知道找谁问、知道哪些事情绝对不能碰他上手速度和下限都会有保障。CLAUDE.md干的就是这件事它是整个模板的“元规则”其他所有规则文件、模板文件、脚本都是它的子集。templates/目录解决的是“每次任务的起点尽可能好”。很多人用 Claude Code 失败的另一个原因是任务描述写得太随笔比如“把这个按钮改好看点”。这个描述人听了都头大更别提模型。任务模板的价值在于强制你补齐上下文目标、当前状态、约束条件、验收标准、涉及文件。这样模型不用猜它只需要执行而执行恰恰是它的强项。rules/目录是项目规则的细分化拆分。为什么不把所有规则塞进一个文件因为 Claude Code 读取长文件时前面内容的优先级往往高于后面如果CLAUDE.md里写了两百条规则它真正执行时大概率只记得前几十条。拆成coding-style、architecture、security、workflow几个文件然后在CLAUDE.md里通过“按需引入”的方式串起来效果会好很多。这一点我在第 4 节会展开讲。memory/是整个模板的灵魂。前面提到的“第二天失忆”问题就是靠它解决。设计上它模拟了人的工作记忆decisions.md记“为什么这么写”progress.md记“现在写到哪了”learned.md记“哪些东西踩过坑”。每次会话结束前让 Claude Code 调用scripts/update-memory.sh把新信息同步进去下一次会话开局先让它读这三个文件就能实现非常自然的“衔接感”。scripts/目录是模板里的自动化层。Claude Code 本身有很强的工具调用能力所以脚本不需要写得多复杂每一个都是一两句核心逻辑。init.sh用于把模板里的占位符替换成真实项目名update-memory.sh负责汇总会话变更user-research.sh是一个很有意思的脚本它的作用是主动追问需求而不是等着你给指令。这个后面会说到具体实践。一句话总结模板的整体设计**CLAUDE.md定边界rules/定准则templates/定格式memory/定记忆scripts/定流程**。五个维度各自独立又互相咬合。3. 核心干货五个关键文件到底怎么写模板的目录结构清楚了但如果你直接克隆下来一跑大概率还是用不好。因为关键在于每个文件里的内容质量而不只是文件在不在。这里我挑五个最核心的文件直接把我现在项目里在用的内容分享出来并解释为什么这么写。3.1 CLAUDE.md不要写规则要写“决策框架”很多人写CLAUDE.md最大的问题是把它写成了流水账。什么“请遵守项目规范”“请编写高质量代码”“请注意性能和安全”全是废话。模型每句话都读进去了但等于什么都没说。我现在的CLAUDE.md开头是这样的结构# 项目角色 你是一个资深全栈工程师负责本项目claude-code-templates的日常开发与维护。 在动手前先读 memory/README.md了解当前项目状态与历史决策。 # 工作流程按优先级 1. 每当接到任务先判断任务类型功能开发/重构/修复/审查并从 templates/ 中选择对应模板。 2. 如果任务描述不满足模板要求先要求补充不要直接动手。 3. 每次修改代码前先说明你的修改方案和影响面。 4. 每次修改后运行相关测试与构建命令没有测试覆盖的模块必须说明原因。 5. 每次会话结束前调用 scripts/update-memory.sh 更新记忆文件。 # 绝对禁止 1. 不得直接执行破坏性命令rm -rf、drop table、强制 push 等除非用户明确确认。 2. 不得修改 memory/ 之外的记忆文件。 3. 不得绕过 rules/ 中的编码规范包括为了“省事”而复制粘贴重复代码。 4. 不得在没有运行测试的情况下声称“已完成”。 # 决策框架 - 当需求不够清晰时主动列出假设清单并请求确认。 - 当两个技术方案同时可行时优先选择改动范围更小、可回滚性更强的方案。 - 当需要新增依赖时先说明目的、体积、维护状态等待用户确认。你看这里面几乎没有“要写高质量代码”这种话取而代之的是可执行的具体动作和时间点。模型读完之后它的行为模式不是“我要做个好助手”而是“我是这个项目里带约束的工程师先分析、再方案、再执行、最后汇报”。哪怕它遇到没有在规则里明确写的新情况也能通过“决策框架”推断出你应该希望它怎么选。这比穷举规则要高效得多。3.2 task.md 任务模板把模糊需求变成可执行规格任务模板的设计原则是让模型在动手前先自己完成一次需求澄清。很多人觉得模板麻烦但真正跑过一次之后你会发现它省下的时间远超写模板的时间。我日常用的 task.md 是这样的# 任务{一句话描述} ## 背景 {解释这个任务为什么存在现在的痛点是什么} ## 现状 {当前相关代码路径、文件状态、技术栈版本} ## 目标 {期望交付的结果尽量可量化} ## 约束 {必须遵守的规则来自 rules/ 目录的引用} ## 验收标准 - [ ] {标准1} - [ ] {标准2} ## 涉及文件 {预计需要修改/新增的文件清单} ## 风险与影响面 {可能会影响到的模块、接口、数据}这张模板的价值在哪里它把“任务描述”从一段话变成了一个结构化的问题集。模型看任务时会对每一个字段做信息补齐如果背景缺失它会主动问如果验收标准没有它会在方案里补一个再让你确认。这个过程比你想象中更重要因为它把“猜”变成了“确认”。3.3 memory/ 记忆机制让长线项目真正接得上记忆文件的写法很容易走偏。有人把它写成了日志流水账昨天改了什么、今天改了什么全是动作记录。但你要知道模型的记忆机制不是人脑的日记本它需要的是决策上下文和下一步入口。decisions.md的推荐结构是“结论 原因 参与方 时间”比如## 2025-02-10后端返回结构统一为 ResultT - 原因前端多个页面需要统一错误处理直接返回 HttpStatus 造成重复代码 - 影响涉及 user、order、payment 三个模块 - 备注迁移期间保留旧接口兼容层预计一个迭代后删除progress.md的推荐结构是“当前阶段 已完成 待办 阻塞项”。尤其“阻塞项”一定要写否则下一次会话它只会反复尝试已经失败过的事情。learned.md是经验库。比如“项目中不能用 XX 框架的原因因为和 YY 的版本冲突”“测试环境数据库是只读的不能指望写入数据”。这些经验每一条都是从事故里来的写下来之后同一个坑不会再踩第二次。这里有个特别重要的操作技巧记忆文件的更新必须由 Claude Code 自己写而不是你手动编辑。原因很简单它自己写出来的内容会更贴近它的上下文理解你人肉写的东西在它读起来可能缺上下文。用scripts/update-memory.sh触发让它自己把这次会话的信息提炼、去重、归类。3.4 scripts/user-research.sh让 AI 先问问题这个脚本是我自己觉得最“反直觉”但也最实用的一个。传统用法是你给 Claude Code 下命令它干活这个脚本反过来它拿到一个需求之后先向你提问。#!/usr/bin/env bash # 用法: claude 读一下 templates/task.md 和 scripts/user-research.sh然后对下面这个需求执行需求澄清 # 需求: $1 echo 当前需求描述$1 echo echo 请按 task.md 的字段逐个确认 echo 1. 这个任务的背景和动机是什么 echo 2. 当前代码中哪个文件/模块最有可能被影响 echo 3. 可量化的交付标准是什么 echo 4. 有哪些隐藏约束 echo 5. 风险点在哪里真正跑起来之后它的效果超出预期。有一次我丢给它一个含糊的任务“把首页搜索体验优化一下”它没有直接改代码而是问了我五个问题“搜索目前是调后端接口还是前端过滤是否有分页搜索结果的排序规则是什么历史上有没有相关性能问题优化目标主要是速度还是命中率”这些问题每一条都命中了我之前没说出来的关键信息。这种交互模式本质上是把“提示工程”的负担从用户手里转移到了模板和脚本上。3.5 rules/ 拆分规则与按需引用的写法前面提过规则不能全堆在CLAUDE.md里。这里说下我的具体做法。我在CLAUDE.md里写了一段“规则导航”# 规则引用 遇到代码风格问题先读 rules/coding-style.md。 涉及模块划分或依赖方向读 rules/architecture.md。 改动涉及用户数据或权限必须读 rules/security.md。 准备提交代码时读 rules/workflow.md。这样 Claude Code 在做不同任务时会主动去翻阅相关规则文件而不是永远只靠CLAUDE.md里的“核心记忆”。打个比方CLAUDE.md是大脑前额叶负责决策和计划rules/是外挂知识库负责深度知识提取。模型在有明确触发条件的情况下会主动去查外挂知识库这个动作比把知识强行塞进上下文要靠谱得多。经验上每个rules/文件不要超过 80 行。如果超过 80 行说明你写的不是规则而是论文。规则文件越长越容易被模型整体忽略。短文件还有一个好处模型可以自己判断“什么时候该去读”而不是每轮对话都要顶着几千字的规则负担。4. 从模板到实战接入一个真实项目的完整流程光有文件还不够模板要在一个项目里真正起作用需要一套比较讲究的“交接仪式”。这里是我在接入第二个项目时打磨出来的完整流程每一步都踩过坑。第一步克隆模板到项目目录并清理掉示例内容。直接复制文件进来但不要保留模板自带的占位符。运行scripts/init.sh它会统一替换整个模板里的变量名包括项目名称、默认分支、包管理器等。没有这一步后面每新建一个文件都会带着另一个项目的影子。第二步根据项目的技术栈裁剪规则文件。比如你的项目是 Go 微服务那么coding-style.md里关于前端状态的规则就要删掉补上 Go 的 lint 规则如果你的项目是单体 Rails 应用那么architecture.md里关于服务间通信的部分也要改。这一轮裁剪本质是把“通用模板”变成“本项目专用规范”偷懒不得。第三步把项目已有的文档精华吸收进memory/。这是最关键的一步。每个项目几乎都有一些散落在需求文档、架构图、甚至聊天记录里的历史决策花半天时间把这些内容手动整理进decisions.md和learned.md。这会成为新会话的“项目常识”直接决定 Claude Code 上线第一天的表现。不要省这个时间我第一次接入一个老项目时跳过了这一步结果它对着一个已废弃的模块问“这个模块是干什么的”非常尴尬。第四步用一个小任务做“验收测试”。不要一上来就丢一个大重构先让它改一个简单但涉及多文件的 feature比如“给用户列表增加按时间筛选功能”。观察它有没有先读模板、有没有按templates/feature.md的结构做方案、有没有主动查询rules/和memory/。如果它绕过了这些流程大概率是CLAUDE.md里的指示写得不够明确回到第 3.1 节重新调整措辞。第五步开始一个新会话前先发送这样一条指令先读 memory/README.md 和 memory/decisions.md确认你对当前项目的背景和进度已经掌握然后再开始任务。这句话非常短但它会触发 Claude Code 先去加载记忆文件而这个动作会极大减少“我上次不知道我们在做什么”的尴尬。我实测下来加上这句话和直接开聊产出质量差距真的很大。这套流程走完之后项目就算“接入模板”了。真正稳定运行两三天后你会明显感觉到 Claude Code 的行为模式发生了质变它不再是一个“你问一句它答一句”的聊天机器人更像一个知道项目背景、知道边界在哪里、也知道怎么汇报的审查严格的协作者。5. 常见问题排查与避坑技巧实录模板跑了几个月我也在两个团队里推广过遇到过不少典型问题。整理一个故障速查表方便你直接对号入座。现象根因解决方案规则文件完全没生效Claude Code 我行我素CLAUDE.md 里规则太多、太泛模型上下文里被淹没精简 CLAUDE.md 到 40 行内只留流程与红线细则拆分到 rules/同一个问题反复问明明上次已经答过没有更新 memory/learned.md会话间没有共享经验每次会话结束前强制运行 scripts/update-memory.shClaude Code 过度保守什么都不敢改只输出建议不动手安全规则写得过于严密比如把所有命令都列为“禁止”区分“绝对禁止”破坏性命令与“需确认”常规命令给模型留出操作空间记忆文件越写越多最后变成一坨没人看的东西记忆文件缺少目录和摘要更新时没有去重在 memory/README.md 里规定每个文件只保留最近 10 条过期内容归档到 memory/archive/任务模板内容填得太空AI 还是照猜的用户跳过“需求澄清”步骤直接让模型干活用 scripts/user-research.sh 让模型先问问题确认完字段再进入执行模型“忘记”了架构约定自己画了新方案架构约束只存在于旧文档里没有归入 decisions.md每次架构讨论结束后立刻让 Claude Code 更新 decisions.md并标注“下次会话必须读取”5.1 深聊一个关键坑规则太多反而失控很多第一次用模板的人都有一个通病觉得规则写得多就是防御拉满。我在自己第一个项目里就犯过这个错CLAUDE.md一口气写了 150 行涵盖了从“变量命名”到“数据库索引规范”的所有内容。结果呢模型确实“看起来”更乖了但这种乖是虚假的乖因为它在长任务里根本守不住那 150 行规则它开始只执行它最容易记得住的“安全红线”而把大量业务逻辑细节全部忽略。这个现象背后是模型注意力分布的问题上下文窗口虽然是够用的但人对长指令的遵循本身就存在衰减模型也是一样。把规则写得简短、可操作、放在文件头部比堆砌内容更重要。我现在的黄金经验是总规则文件不要超过 60 行细则文件每个不超过 80 行一次会话内让模型主动引用的规则文件不要超过 2 个。超过这个阈值效果就会边际递减。5.2 记忆文件更新的最佳实践谁负责、什么时候负责模板里的update-memory.sh我一开始设计成“每次会话结束前手动运行”但实际用下来人在高强度改代码的时候往往会忘。后来我调整了策略在CLAUDE.md的工作流程里明确写了一句“任务完成并验证通过后自动调用 scripts/update-memory.sh”。同时脚本本身也做了增强它会把自上次更新以来的新增决策、进度变化、踩坑经验先对比现有记忆文件再做去重和合并而不是无脑追加。这里有个实测的小心得模型自己写的记忆记录往往比人更准确因为它是在对话上下文中直接生成的不会遗漏那些“你当时觉得不重要后来才发现很关键”的细节。所以不要嫌它写得啰嗦先让它自由写再定期做一轮人工精简就够了。5.3 模板的二次定制不同技术栈要改哪里模板目前虽然开源给了团队但每个团队最后还是会长成自己的形态这是好事。做定制的时候我建议优先关注以下几个点rules/coding-style.md永远是最需要定制的地方。语言规范、lint 配置、格式化工具不同技术栈差异太大。rules/architecture.md在微服务和单体项目里完全是两回事不要照抄。templates/feature.md也要根据团队流程调整比如你们强制要求先写接口文档那就在模板里加上“接口文档先行”字段。配置方面config/settings.json里我会改模型温