Claude Code 发布以来，"怎么用好它"一直是开发者圈子里的热门话题。最近，Claude Code 的创建者 Boris Cherny 在 X 上分享了他和团队的内部工作流——不是那种泛泛的 tips，而是他们每天实际在用的实践。社区随后将这些散落的讨论整理成了一份结构化的 CLAUDE.md 模板。
这份文档的价值不在于格式，而在于它背后的思维模型：怎样用规则约束 AI agent，让它从"能干活"变成"干得靠谱"。
我把核心内容拆解重构如下，加了一些自己的理解。
工作流编排：别让 AI 一路莽到底
先规划，再动手
对任何非平凡任务（3 步以上或涉及架构决策），默认进入规划模式。这不是保守，是降低返工成本。
关键点：
- 出了问题立刻停下来重新规划——最怕的是 AI 一条路走到黑，越错越远
- 规划不只是用来"建"的，验证步骤也值得提前规划
- 前期写清楚详细规格，能大幅减少歧义和反复
这跟我们做工程项目的逻辑完全一致：设计阶段多花 1 小时，执行阶段少花 1 天。
大胆用子任务
用子 agent 来保持主上下文窗口的干净——这是 Boris 团队的核心策略之一。
实践建议：
- 调研、探索、并行分析都丢给子 agent
- 复杂问题直接用更多算力堆，不要省
- 一个子 agent 只做一件事，聚焦才能高质量
本质上这是"分治法"在 AI 工作流中的应用。上下文窗口是稀缺资源，塞太多东西进去，AI 的注意力就分散了。
自我迭代闭环
这是整份文档中我认为最有价值的部分——让 AI 建立"错误记忆"。
工作方式：
- 每次被用户纠正后，把错误模式写入 <code>lessons.md</code>
- 为自己编写规则来防止同样的错误再次发生
- 每次会话开始时回顾相关教训
这不是什么新概念，但把它系统化地嵌入 CLAUDE.md 后，效果完全不同。AI 不再是每次从零开始的工具，而是一个会积累经验的协作者。
完成 ≠ 交付
永远不要在没有证明可用的情况下标记任务完成。
验证清单：
- 改动前后做 diff 对比
- 问自己："一个 Staff Engineer 会批准这个吗？"
- 跑测试、查日志、展示正确性
这条规则简单粗暴但极其有效。多少 bug 是因为开发者"觉得应该没问题"就提交了？AI agent 也一样。
追求优雅，但别过度
Boris 团队的态度很务实：
- 非平凡改动：停下来想想"有没有更优雅的方式？"
- 感觉方案很 hacky："在我已知的所有信息下，实现那个优雅的方案"
- 简单明显的修复：直接做，别过度设计
这个平衡点很重要。追求代码质量是对的，但把一个三行 hotfix 搞成架构重构就是病。
自主修 Bug：别来回问
理想状态下，给 AI 一个 bug 报告，它应该：
- 定位日志、错误信息、失败的测试
- 直接修复
- 不需要用户手把手指导
- 零上下文切换成本
这对 CLAUDE.md 的配置要求是：给 AI 足够的权限和上下文去自主排查，同时设好边界别让它乱改。
任务管理：用文件当看板
tasks/todo.md → 可勾选的任务清单
tasks/lessons.md → 纠错记录工作流：
- 把计划写成可勾选项
- 开始实现前先检查一遍
- 完成一项勾一项
- 每一步给出高层摘要
- 加一个 review section
- 被纠正后更新 lessons
不需要 Jira、不需要 Notion，一个 Markdown 文件就够了。简单到不可能不执行，这才是好的流程设计。
三条核心原则
简单优先
每次改动都尽可能简单，影响尽可能少的代码。
不偷懒
找到根因，不打临时补丁，用高级工程师的标准要求自己。
最小影响
只动该动的地方，避免引入新问题。
这三条看似朴素，但它们共同指向一个目标：可控性。AI 最让人不放心的就是"一改改一片"，这三条原则就是在从根本上解决这个信任问题。
我的实践体会
我在自己的 AI 工作流中大量使用了类似的模式（虽然文件叫 AGENTS.md 而不是 CLAUDE.md），几个月下来有几点体会：
- 崩溃恢复机制是刚需——AI 会话随时可能中断，<code>active-tasks.md</code> 这类文件能让它无缝续上
- 子 agent 验证很关键——构建者不能当审核者，这条规则修复了 80% 的质量问题
- 经验积累需要结构化——散乱的 lessons 没人看，按模式分类才有用
- 模型路由要分级——不是所有任务都需要最强模型，简单任务用轻量模型既省钱又快
CLAUDE.md 本质上是给 AI 写的工作手册。就像新员工入职时需要一份清晰的 onboarding 文档一样，AI agent 也需要明确知道：你的工作流程是什么、犯了错怎么办、质量标准是什么。
写好这份文档，比换一个更强的模型更有用。
拿走即用：完整 CLAUDE.md 模板
下面这份模板整合了上述所有实践，你可以直接复制到项目根目录，根据自己的项目情况微调即可。
CLAUDE.md
> 本文件是 Claude Code 的项目级指令。每次会话启动时自动加载。
## 项目概述
- **项目名称**: [你的项目名]
- **技术栈**: [语言/框架/数据库等]
- **仓库结构**: [简要描述目录布局]
## 工作流规则
### 规划优先
- 任何 3 步以上的任务或涉及架构决策的改动，先进入 plan mode
- 遇到问题时立即停下重新规划，不要硬推
- 验证步骤也要提前规划，不要事后补
- 开始编码前先写清楚实现规格，减少歧义
### 子任务拆分
- 调研、探索、并行分析交给 subagent 处理
- 一个 subagent 只负责一件事
- 保持主上下文窗口干净，只留核心逻辑
### 验证标准
- 永远不要在没有验证的情况下标记任务完成
- 改动前后做 diff 对比，确认行为符合预期
- 问自己："一个 Staff Engineer 会批准这段代码吗？"
- 跑测试、查日志、展示正确性
### 代码质量
- 非平凡改动：先想想有没有更优雅的实现
- 感觉 hacky 时：退一步，用已知信息重新设计
- 简单修复：直接做，不过度设计
- 每次改动尽可能简单，只动该动的代码
### 自主修 Bug
- 收到 bug 报告后直接排查修复，不要来回问
- 定位日志、错误、失败测试 → 修复 → 验证
- 目标：用户零上下文切换
## 任务管理
把计划写到 <code>tasks/todo.md</code>，用可勾选列表：
- [ ] 实现用户认证模块
- [ ] 编写单元测试
- [x] 数据库 schema 设计
工作流：
1. 写计划 → <code>tasks/todo.md</code>
2. 开始前检查一遍任务列表
3. 完成一项勾一项
4. 每步给出简要进度摘要
5. 最后加 review section 自查
## 自我迭代
### 纠错记录
被用户纠正后，**立即**更新 <code>tasks/lessons.md</code>：
## [日期] [错误类型]
- **场景**: 什么情况下犯的错
- **错误**: 做错了什么
- **正确做法**: 应该怎么做
- **规则**: 用一句话总结防范规则
### 会话开始
每次新会话启动时：
1. 读取 <code>tasks/todo.md</code> 了解当前进度
2. 读取 <code>tasks/lessons.md</code> 回顾相关教训
3. 如有未完成任务，自动继续而非重新询问
## 核心原则
1. **简单优先** — 改动尽可能小，影响尽可能少
2. **不偷懒** — 找根因，不打补丁，Senior 标准
3. **最小影响** — 只动必要的代码，不引入新问题
## 项目特定规则
<!-- 在这里添加你的项目特有约定 -->
<!-- 例如：命名规范、分支策略、部署流程等 -->使用说明
- 复制模板：把上面的内容保存为项目根目录下的 <code>CLAUDE.md</code>
- 填写项目信息：替换 <code>[你的项目名]</code>、<code>[语言/框架/数据库等]</code> 等占位符
- 创建任务目录：在项目中建 <code>tasks/</code> 目录，放入 <code>todo.md</code> 和 <code>lessons.md</code>
- 补充项目规则：在"项目特定规则"区域加入你团队自己的约定
- 持续迭代：用了一段时间后根据实际情况调整规则，这是一份活文档
模板的设计原则是开箱即用但不过度约束——它提供了经过验证的框架，同时留够了定制空间。最好的 CLAUDE.md 不是最全的，而是最适合你项目的。