Claude Code 一旦正确配置，简直逆天。这是完整攻略。

大多数开发者打开 Claude Code，粘贴提示词，然后祈祷。

有些人花 300 美元买课程，但这些课程甚至还没涵盖 Anthropic 免费放出的内容。

还有一小群人，他们一年前就看了 Claude Code 创作者展示的工作流程。从那以后，他们一直在积累优势。

差距开始显现。

AI 圈的推特每隔几个月就会重新发现这套攻略。视频发布已超过一年。2025年5月22日。130万次观看。零字幕。大多数人就是不肯看。

下面的这套攻略，正是那些几周内就能交付产品的开发者，与困在提示循环中的开发者之间的分水岭。也是大多数人在 2026 年仍然错过的东西。

以下是 Boris Cherny 在 Anthropic 实际运行系统的完整解析。以及你不该跳过的部分。

这段 28 分钟的视频已在 YouTube 上免费放置超过一年。

这套攻略到底是什么

这不是一个提示词列表。也不是那种 50 条技巧的帖子。这是一个与 Claude Code 配合工作的完整操作系统。

Boris 在视频中演示的核心思想，他称之为复合工程。每一个错误都变成一条永久规则。每一个重复任务都变成一个可复用命令。每一个冗长任务都变成一个子智能体。每一个验证步骤都变成一个钩子。系统在每次会话中变得越来越聪明，因为上下文、命令和例程都存在于代码库中。

他的个人设置出奇地基础。开箱即用的 Claude Code 完成了大部分工作。杠杆来源于叠加在其上的五样东西。

→ 通过 CLAUDE.md 文件实现的持久化上下文

→ 通过斜杠命令和子智能体实现的可复用工作流

→ 通过钩子实现的确定性后置操作

→ 通过 Git 工作树实现的并行执行

→ 先计划、始终验证的纪律

这就是整个攻略。剩下的就是执行。

这套体系突然又随处可见，因为 Hermes Agent 集群、SOUL.md 模板和 Claude Routines 都运行在这 5 个基本要素上。协调器变了。基础没有。只需设置一次，2026 年出现的每一个新智能体工具都将接入你现有的基础设施。

大多数人使用 Claude Code 的问题所在

以下是大多数开发者的做法。

他们打开 Claude Code。粘贴一个功能请求。发现有些不对劲。再次提示。换个角度。粘贴更多上下文。会话内存耗尽。重新开始。重新解释代码库。重新解释约定。重新解释昨天解释过的同一个边缘情况。

这就是人们说“氛围编码”不起作用时的意思。

模型不是问题。Opus 是有史以来最好的编码模型。问题是工作流程。每一次恐慌提示会话都从零上下文开始，输出漂移，到了早上 Claude 已经忘记了你教给它的一切。

Boris 在一个技术栈中修复了所有五个问题。而且这些部分甚至不是隐藏的。它们就存在于 Claude Code 本身。

你只需实际使用它们。

第一步：CLAUDE.md 作为活着的机构记忆

这是你要设置的第一件事。也是大多数开发者认为可选的部分。

CLAUDE.md 是一个 Markdown 文件，Claude 在每次会话开始时读取它。它告诉 Claude 你的代码库如何工作，遵循什么约定，避免哪些错误，以及你的团队使用什么快捷方式。

Boris 使用了三个版本。

→ 一个项目根目录的 CLAUDE.md，提交到 Git。整个团队共享。每周更新多次。

→ 一个用户级别的 ~/.claude/CLAUDE.md，用于跨所有项目的个人偏好。

→ 一个 CLAUDE.local.md，保留在 Git 之外，用于个人覆盖。

团队共享的那个才是神奇发生的地方。

Boris 说过一句话，应该纹在每个开发者的屏幕上。

“每当我们发现 Claude 做错了什么，我们就会把它加到 CLAUDE.md 里，这样 Claude 下次就不会再犯了。”

这就是完整的思维模型。每一个 Claude 的错误都是一次性税。添加规则。永远不用再付。

内容很简单。比如：

→ 始终使用 bun，而不是 npm

→ 优先使用 type 而非 interface。绝不用 enum。使用字符串字面量联合类型

→ 编号的开发工作流程。类型检查。测试。Lint。然后 PR

→ 未经确认，绝不触碰 migrations 文件夹

在 @ignytlabs，我们团队的 CLAUDE.md 现在大约有 90 行。每一行都是真实客户项目上真实错误的伤疤。每一行都让我们免于再次犯同样的错误。

快速提一下大小。Boris 故意保持简短。他个人的文件大约 100 行，2500 个 token。臃肿的 CLAUDE.md 文件是一个真正的反模式。文件越大，真正重要规则的效力就越被稀释。要无情地修剪。

你可以通过 Claude Code 中的 /init 命令快速启动。它会扫描你的代码库并为你写一个入门文件。之后，随着你的开发进行实时编辑。

第二步：用于内部循环工作的自定义斜杠命令

下一个杠杆点。斜杠命令。

这些是可重用的工作流配方，存储在 .claude/commands/ 目录下的 Markdown 文件中。你用 /commandname 调用它们，Claude 会运行完整的配方。任何你一天做五次的事情都应该放在这里。

Boris 在视频中提到的命令。

→ /commit-push-pr 暂存更改，写提交信息，推送分支，打开 PR。每天使用。

→ /techdebt 在会话结束时运行。查找重复、死代码和不一致。清理它们。

→ 上下文同步命令，在进行多文件更改前，将相关文件的最新状态拉入上下文。

你不需要从头写这些。你让 Claude 帮你写。描述一次工作流。Claude 写出命令文件。你提交它。现在你的整个团队都有了相同的快捷方式。

这是大多数开发者停滞的部分。他们每次都手动提示相同的五步序列。Boris 把每一个这样的序列都变成了一个单一的斜杠命令，随仓库一起发布。

在我们机构，我们标准的 MVP 启动器里有大约 12 个斜杠命令。我们每天使用的四个。

→ /plan 为下一个功能发起一个仅计划的会话

→ /ship 运行完整的提交、推送和 PR 流程，遵循我们的提交约定

→ /audit 让 Claude 在整个仓库中查找未使用的导出、漂移和明显错误

→ /sync 将最新的设计令牌从我们的设计源头拉入代码库

你只做一次。你永远用它。

第三步：用于关注点分离的子智能体

这时工作流不再像提示，而开始像基础设施。

子智能体是一个专门的 Claude 实例，拥有自己的角色、提示和指令。它作为 Markdown 文件存在于 .claude/agents/ 中。你的主 Claude 会话像调用函数一样调用这些子智能体。子智能体在隔离中运行，完成工作，将结果交回，你的主上下文保持干净。

Boris 演示了几个。

→ code-simplifier.md 在最终的 diff 上运行，移除 Claude 过度设计的所有“聪明”代码

→ verify-app.md 对刚发布的功能运行完整的端到端测试

→ build-validator.md 确认构建在所有支持的环境中通过

→ code-architect.md 在计划模式下使用，在任何代码编写之前思考结构决策

这之所以重要，是因为上下文膨胀。一个同时处理规划、编码、测试、审查和文档的 Claude 会话，最终会达到上下文限制，并开始忘记早期的决定。子智能体是你在繁重任务上扩展计算能力而不使主会话膨胀的方式。

你可以显式调用它们。“使用 3 个并行子智能体，为这个认证流程头脑风暴三种不同方法。比较它们。选择最佳方案。”

或者你可以链式调用。计划智能体交给编码智能体。编码智能体交给验证智能体。验证智能体交给简化智能体。每个智能体只有一个工作。每个智能体对每个功能都是可复用的。

这是整个攻略中最像运行一个小型工程团队的部分。只不过每个团队成员并行交付，而且从不睡觉。

第四步：用于确定性后置操作的钩子

钩子是攻略中无聊的部分。它们也是每周安静地节省数小时的部分。

钩子是在 Claude Code 事件上触发的确定性操作。你在项目设置中配置它们。Boris 最常使用的两个事件。

→ PostToolUse 在 Claude 编辑文件后触发。Boris 在这里运行 bun run format，以在进入 CI 之前捕获格式边缘情况。

→ Stop 或 agent-stop 在智能体完成任务时触发。Boris 在这里运行验证。测试。类型检查。任何在你信任输出之前必须通过的东西。

钩子和斜杠命令的区别在于谁负责。斜杠命令是你调用的。钩子是自动触发的。你设置一次。它们永远运行。

这就是把 Claude Code 从工具变成基础设施的东西。模型可以写任何它想写的代码。你的钩子决定这些代码是否允许发布。

如果你曾经把一个 Claude 的 diff 发布到生产环境，然后看着 CI 因为缺少格式检查而崩溃，钩子可以永久修复那个问题。它们是你将买到的最便宜的保险。

第五步：使用 Git 工作树的并行会话

这是整个视频中最大的单一生产力提升。Boris 说这是他团队获益最多的设置。

设置方式。打开三到五个终端标签页。每个标签页是一个不同的 Git 工作树，指向同一个仓库但不同的分支。每个标签页运行自己的 Claude Code 会话。每个会话同时处理不同的任务。

一个标签页处理新功能。一个标签页处理前一个功能的测试套件。一个标签页重构旧模块。一个标签页写文档。一个标签页调试生产问题。

Boris 还混合使用 Web 端 claude.ai/code 和移动端应用。你在桌面开始工作。移交给 Web。从移动端检查进度。智能体不在乎你在哪个客户端。工作继续。

工作树之所以重要，是因为冲突隔离。五个 Claude 会话写入同一个检出版本会冲突。五个 Claude 会话写入五个工作树不会。每个智能体都有自己的干净工作目录。你准备好了再合并。

这是 Claude Code 不再像编码助手，而开始像与你的代码库进行实时战略的时刻。你进行协调。每个智能体执行。瓶颈不再是你能多快提示，而是你能多快规划。

在 @ignytlabs，我们在每个活跃客户项目上平均运行 3 个并行会话。一个处理功能工作。一个处理测试。第三个处理文档。我们现在交付客户更快了。相同的质量，相同的范围，更少的天数。瓶颈从提示转移到了规划。

第六步：先计划。始终验证。然后执行。

攻略的最后一部分是不出现在任何文件中的部分。它是一种纪律。

Boris 在视频中强调了两次。

“一个好的计划对于避免后续问题非常重要。”

还有一句应该是每个开发者首先阅读的话。

“给 Claude 一种验证其工作的方法。如果 Claude 有这个反馈循环，最终结果的质量会提高 2-3 倍。”

以下是工作流程。

→ 每个非平凡的任务都从计划模式开始。按 Shift+Tab 两次。Claude 切换到只读思考模式。不进行任何编辑。你迭代计划直到它稳固。然后你切换到自动接受，Claude 一次性完成实现。

→ 在声明完成之前，始终给 Claude 一种检查其自身工作的方法。测试是最明显的。UI 工作用浏览器截图。移动端用模拟器。类型化代码用类型检查器。样式用 linter。任何反馈循环都比没有反馈循环好。

→ 当事情出错时，重新计划。不要继续更用力地推行错误的计划。

这就是氛围编码与架构设计之间的区别。提示是最后一步，而不是第一步。80% 的工作发生在你告诉 Claude 执行之前。执行本身通常只有一两个提示。

如果你跳过这一步，你会花整个下午与 Claude 搏斗。如果你尊重它，Claude 一次就交付正确的东西，然后你继续前进。

这套攻略何时不起作用

这并非适合每个团队的正确设置。对适用性诚实。

适用场景：

→ 你每周使用 Claude Code 交付生产代码超过一次

→ 你的团队有不止一个工程师使用 Claude

→ 你反复纠正同一个 Claude 错误

→ 你的代码库有真正值得强制执行的约定

→ 你并行交付多个功能

跳过场景：

→ 你只是在周末项目上“嗨”，不在乎一致性

→ 你使用 Claude 写一次性脚本，从不触及真实仓库

→ 你的代码库太小，CLAUDE.md 比代码本身还重

对于大多数交付真实产品的开发者来说，这套攻略值得设置一次。投入大约一天。复利效果是永久的。

需要注意什么

在运行此攻略之前，有四个诚实的警告。

CLAUDE.md 膨胀是真实存在的。Boris 故意保持简短。一个 500 行的 CLAUDE.md 会稀释真正重要的规则。要无情地修剪。每条规则都应该凭本事赢得一席之地。

子智能体不是免费的。每次子智能体调用都会消耗 token。要计划它们的使用。不要在一个精心提示的主会话就能处理的任务上链式调用六个子智能体。

钩子可能掩盖问题。一个自动格式化的 PostToolUse 钩子可能隐藏 Claude 如何结构化代码的微妙错误。要阅读你的 diff。不要相信钩子能抓住一切。

并行会话需要清晰的头脑。五个 Claude 会话在五个工作树上，只有在你能够跟踪每个会话在做什么时才强大。如果你做不到，你会合并冲突的工作并浪费时间。从两个并行会话开始。等你能够干净地协调它们时再加更多。

这实际上意味着什么

以下是我诚实的看法。

2026 年胜出的开发者，不是那些能接触到更好模型的人。现在每个人都能接触到最好的模型。Opus 4.7。Composer 2.5。Gemini 3。随便选。

胜出的开发者是那些在模型之上堆叠了真正工作流的人。持久化上下文。可重用命令。专用子智能体。确定性钩子。并行执行。先计划纪律。

这就是恐慌提示与交付之间的区别。模型没有变。围绕它的系统变了。

Claude Code 的创作者一年前就告诉了我们这些。大多数开发者没有听。那些听了的人现在正在以一半的时间交付两倍质量的产品。

2026 年对那些早早设置好这套系统的开发者来说将是极其不公平的。差距已经在扩大。收藏这套攻略。本周设置好它。

太长不看版

→ 那个“病毒式传播”的 Boris Cherny 视频已经超过一年了。这套攻略一直免费。大多数开发者只是没看。