解码 Claude Code（六）— 实战技巧：从 Boris 和团队偷师的 30 条黄金法则

不是官方文档，不是营销话术。这是一个每天用 AI 写 100% 代码的人，用半年时间摸索出来的真实经验。

写在前面

前五期我们聊了 Claude Code 的起源、架构、记忆系统、技能和多代理协作。这一期换个节奏——不讲理论，只讲实操。

这篇文章的素材来自 Boris Cherny（Claude Code 创造者）在 2026 年 1-4 月发布的四组技巧分享，以及 Anthropic 团队成员 Thariq 关于会话管理的深度指南。我把它们重新组织成 6 个主题，30 条具体可执行的建议。

每一条都有出处，每一条都经过 Anthropic 内部团队的日常验证。

Coding Tips

一、并行是一切的起点

Boris 反复强调：并行是最大的生产力提升，没有之一。

1. 同时跑 5 个 Claude

Boris 的日常：5 个终端窗口，每个运行一个独立的 Claude Code 实例。一个重构代码，一个写测试，一个搜索依赖，一个审查 PR，一个处理 bug 报告。

具体操作：用 git worktree 创建 5 个独立的工作树，每个窗口一个。这样 5 个 Claude 互不干扰，各自操作各自的代码副本。

# 创建 worktree
git worktree add ../feature-a feature-a
git worktree add ../feature-b feature-b

# 在每个 worktree 里启动 Claude
cd ../feature-a && claude
cd ../feature-b && claude

或者用更简单的方式：claude -w 一键在 worktree 中启动。

2. 本地 + 云端双线作战

5 个本地 Claude 还不够？再开 5-10 个云端实例。claude.ai/code 支持在浏览器里运行 Claude Code，用 /teleport 可以在本地终端和云端之间无缝切换。

Boris 的组合拳：5 个本地 + 10 个云端 = 同时 15 个 Claude 在干活。

3. 把”每天做两次的事”变成斜杠命令

如果某个操作你一天要做两次以上，把它变成一条斜杠命令。

---
name: commit-push-pr
description: "提交代码、推送、创建 PR"
---

执行以下步骤：
1. 运行测试
2. git add 所有变更
3. 根据变更内容生成 commit message
4. git push
5. 创建 Pull Request

Boris 的 /commit-push-pr 命令可能是他用得最多的一条——每天执行几十次。

4. 用 /loop 把重复工作自动化

/loop 是 Boris 最喜欢的"隐藏功能"之一。它可以让 Claude 按固定间隔自动执行任务，最长持续一周。

他的日常配置：

/loop 5m /babysit          → 每5分钟自动处理PR review
/loop 30m /slack-feedback  → 每30分钟把Slack反馈变成PR
/loop 1h /pr-pruner        → 每小时清理过期PR

把技能和 loop 组合起来，就变成了一个 7x24 小时工作的 AI 助手。

二、验证闭环：最重要的一条

Boris 说过一句话，被整个社区反复引用：

给 Claude 验证自己工作的方式，效果提升 2-3 倍。这是获得高质量输出的最重要单一因素。

5. Claude 测试每一次变更

Boris 每次让 Claude 写完代码后，都会让它自己测试。不是"帮我看看有没有问题"——而是"运行测试，确保通过"。

这是他从 Meta 带来的习惯：代码质量不是审查出来的，是验证出来的。

6. 前端必须给 Claude 浏览器

让 Claude 写前端代码但不给它浏览器，就像让设计师蒙着眼睛画画。

Chrome 扩展是 Boris 做前端时的标配。Claude 写完代码后自动打开浏览器截图，对比设计稿，发现差异后自动修复。这个循环一直持续到页面看起来"对了"为止。

7. 用”挑战式提示”逼迫 Claude 自审

不要只说"帮我写这个功能"。试试这样说：

"审查这段代码，不要创建 PR，直到我通过你的测试。"

或者：

"向我证明这个方案有效。对比 main 分支和当前分支的行为差异。"

Boris 把这叫做"让 Claude 当你的审查者"——反向利用 AI 的能力来提升输出质量。

8. 失败后不要纠正，要重写

当一个修复方案"勉强能用"时，Boris 会说：

"基于你现在知道的一切，扔掉这个方案，实现那个优雅的解法。"

这个技巧的底层逻辑是：Claude 在尝试过程中学到了很多关于代码库的上下文，但它当前的实现可能只是在最初的错误假设上打补丁。让它带着新知识重新来过，往往能得到更好的结果。

9. 让 Claude 修复大多数 bug

不需要手把手教。直接说"修复失败的 CI 测试"，或者把 Slack 里的 bug 线程贴给 Claude，只说一个字："修。"

Claude 可以读日志、分析堆栈、定位代码、提出修复方案、运行测试验证。整个过程你只需要审查最终结果。

三、会话管理：对抗”上下文腐烂”

这一节的素材来自 Thariq（Anthropic 团队成员），他给出了目前最系统的会话管理指南。

10. 理解 Context Rot

即使有 1M token 的上下文窗口，模型性能也不是线性的。大约在 300-400k token 时，模型开始被无关信息干扰——注意力被分散到越来越多的 token 上，旧的不相关内容开始影响当前的判断。

这就是 Context Rot（上下文腐烂）。

11. 每个回合结束都是一个决策点

Claude 完成一个回合后，你有 5 个选择：

选项	上下文保留	适用场景
Continue	保留全部	同一任务，上下文仍然相关
Rewind	保留前半，丢弃后半	Claude 走错方向了
/compact	有损摘要	中期任务，需要清理冗余
/clear	只保留你写的 brief	全新任务
Subagent	主上下文 + 最终结果	会产生大量中间输出的任务

12. Rewind > 纠正

这是 Thariq 最推荐的习惯。

当 Claude 尝试方案 A 失败了，你的直觉可能是说"不对，试方案 B"。但这会把失败的方案 A 和你的纠正都留在上下文里。

更好的做法是 Rewind（双击 Esc）：回退到失败尝试之前，用你学到的信息重新提示。

纠正后：上下文 = 5个文件读取 + 2次失败尝试 + 2次纠正 + 最终修复
回退后：上下文 = 5个文件读取 + 1个有经验的提示 + 最终修复

上下文更干净，模型的注意力更集中。

13. Compact 是中期任务的救星

当会话变长但你不想从头来过，/compact 是最好的选择。它会要求 Claude 摘要当前对话，然后用摘要替换历史。

关键技巧：用提示词引导 compact 的方向。

/compact 保留认证重构的细节，丢弃测试调试的过程

不引导的 compact 可能会丢失重要信息——因为模型在做 compact 时处于"最不聪明"的状态（上下文已经很满了）。

14. 主动 compact，不要等到自动触发

等到自动 compact 触发时，模型已经处于 Context Rot 状态，摘要质量会下降。

正确做法：在你觉得上下文开始膨胀但模型还没变笨的时候，主动执行 /compact，带上方向提示。

四、CLAUDE.md：投资回报率最高的 5 分钟

15. 每次纠错后更新 CLAUDE.md

Boris 的原话：

每次你纠正 Claude 后，以这句话结尾："更新你的 CLAUDE.md，确保你不再犯这个错误。"

Claude 非常擅长为自己写规则。它会精确地提取错误的模式，写成可执行的指令。

16. 团队共享，通过 PR 协作更新

CLAUDE.md 不应该是某个人的私有文件。Boris 的团队把它检入 git，通过 PR 协作更新。

一个更有趣的做法：在同事的 PR 上 @claude，让 Claude 在 review 过程中自动更新 CLAUDE.md。Boris 把这叫做"复利工程"——每次代码审查都在为未来的 AI 辅助投资。

17. 持续迭代直到错误率可测量地下降

CLAUDE.md 不是写一次就完事的。Boris 建议：

用一周时间记录 Claude 犯的所有错误
为每类错误添加一条规则
再用一周观察错误率是否下降
重复直到效果显著

这个过程可能需要几轮迭代，但每一轮都在让 Claude 变得更好。

18. 用 notes 目录积累项目知识

一个 Anthropic 工程师的做法：让 Claude 为每个任务/项目维护一个 notes 目录，每次 PR 后更新。然后在 CLAUDE.md 里指向这个目录。

这样 CLAUDE.md 本身保持简洁（只放规则和约定），而详细的项目知识存在 notes 里，按需加载。

五、工具和环境优化

19. 用 Opus + Thinking 处理一切

这听起来违反直觉——Opus 比 Sonnet 慢，为什么还要用？

Boris 的解释：虽然单次响应更慢，但因为 Opus 犯错更少、工具使用更准确，你需要纠错的次数大幅减少。总耗时反而更短。

这就像开车走高速 vs 走小路：高速看起来绕远了，但因为不用等红灯，总时间更短。

20. 用 PostToolUse Hook 自动格式化代码

Claude 生成的代码通常格式良好，但最后 10% 可能和项目的 lint 规则不一致。一个简单的 Hook 就能解决：

"PostToolUse": [{
  "matcher": "Write|Edit",
  "hooks": [{
    "type": "command",
    "command": "bun run format || true"
  }]
}]

每次 Claude 写入或编辑文件后自动格式化，CI 再也不会因为格式问题失败。

21. 预授权权限，不要跳过权限检查

--dangerously-skip-permissions 看起来很方便，但 Boris 坚决反对。正确做法是用 /permissions 预先授权已知的安全操作：

{
  "permissions": {
    "allow": [
      "Bash(npm test*)",
      "Bash(npm run lint*)",
      "Bash(git status*)",
      "Bash(git diff*)"
    ]
  }
}

把这些规则检入 settings.json，整个团队共享。

22. 给 Claude 接入你所有的工具

通过 MCP，Claude 可以访问 Slack、BigQuery、Sentry、GitHub 等所有团队工具。Boris 已经 6 个月没写过一行 SQL 了——所有数据查询都通过 Claude + BigQuery 完成。

配置方法：在 .mcp.json 中定义 MCP 服务器，检入 git 共享。

23. 语音输入：说得比打得快 3 倍

Boris 大部分代码是"说"出来的，不是"打"出来的。

语音输入的好处不只是速度——它让你的 prompt 自然变得更详细。打字时你会下意识压缩信息，说话时你会自然补充更多上下文。而 prompt 越详细，Claude 的输出越好。

终端里运行 /voice，然后按住空格键说话。macOS 上也可以双击 fn 键触发系统听写。

24. --bare 让 SDK 启动快 10 倍

用 Claude Code 做 CI/CD 或自动化时，默认会搜索所有 CLAUDE.md、settings 和 MCP 配置。加上 --bare 跳过这些搜索，启动速度提升 10 倍：

claude -p "总结这个代码库" \
  --output-format=stream-json \
  --bare

Boris 透露，未来的版本会把 --bare 变成默认行为——因为它在非交互场景下几乎总是更好的选择。

六、高级工作流

25. /batch：大规模变更的核武器

需要把一个重构应用到几十甚至几百个文件？/batch 会先和你确认方案，然后自动分发到数十/数百个 worktree agent 并行执行。

每个 agent 在独立的代码副本上工作，完成后自动合并。这是 Claude Code 处理大规模代码迁移的终极工具。

26. 用 Hooks 挂载到 Agent 生命周期

Hooks 让你在 Claude 的关键节点执行自定义逻辑：

SessionStart：每次启动时动态加载上下文
PreToolUse：记录模型执行的所有 bash 命令
Stop：Claude 停止时"戳"它一下让它继续

第三个特别有用——长时间运行的任务中，Claude 有时会过早停止。用 Stop Hook 自动推送它继续，直到任务真正完成。

27. 子代理不只是”分工”，更是”上下文隔离”

子代理最大的价值不是并行执行——而是上下文隔离。

当你知道接下来的一块工作会产生大量中间输出（20 次文件读取、12 次 grep、3 条死路），而这些输出你之后不再需要——把它交给子代理。只有最终结论会返回主上下文。

判断标准很简单：我之后还需要这些工具输出吗？不需要就丢给子代理。

28. 会话分支：探索不同方向的安全网

用 /branch 从当前会话分叉出一个新方向。原来的会话完好无损，你可以随时切回来。

适用场景：一个方案不确定能不能走通？先 branch 一下，在分支里试。失败了切回来，零损失。

29. 跨仓库工作：--add-dir

当你需要同时操作多个代码仓库时，用 --add-dir 把其他目录加入 Claude 的工作范围：

claude --add-dir ../shared-libs --add-dir ../api-gateway

这不仅让 Claude "看到"这些仓库，还自动授予了操作权限。

30. 用 Explanatory 模式学新东西

Claude Code 不只是写代码的工具，也是学习工具。在 /config 里切换到 "Explanatory" 或 "Learning" 输出风格，Claude 会在每次变更时解释"为什么这么做"。

还可以让它：
- 生成 HTML 幻灯片解释不熟悉的代码
- 画 ASCII 图描述新协议和代码架构
- 构建间隔重复学习技能——你解释理解，Claude 提问补漏洞

总结：30 条法则的底层逻辑

把 30 条技巧摊开看，你会发现它们都围绕三个核心原则：

原则一：给 AI 反馈闭环。 验证工作（5-9）是最重要的一组技巧。没有反馈的 AI 就像没有方向盘的车——动力再强也没用。

原则二：管理上下文就是管理 AI 的"智商"。 会话管理（10-14）、CLAUDE.md（15-18）、子代理（27）都在做同一件事——确保模型的注意力集中在正确的事情上。

原则三：自动化一切重复操作。 斜杠命令（3）、/loop（4）、Hooks（26）、权限预授权（21）——把人类从重复劳动中解放出来，让 AI 处理 AI 最擅长的事。

这三条原则不只适用于 Claude Code。它们是 2026 年"AI 辅助开发"这个领域的通用方法论。不管你用什么工具，只要你记住这三条，就能显著提升 AI 编程的效率和质量。

系列导航

第一期：解码 Claude Code — Anthropic 的 AI 编程革命
第二期：架构哲学 — 为什么终端赢了？
第三期：记忆与上下文 — 如何让 AI 不再"健忘"？（待写）
第四期：技能系统 — 用 Markdown 打造可复用的 AI 能力
第五期：多代理协作 — 从单兵作战到 AI 军团
第六期：实战技巧 — 从 Boris 和团队偷师的 30 条黄金法则（本文）
第七期：深度报告 — 真实项目的完整案例
第八期：未来展望 — Karpathy、Boris 等大佬怎么看 AI 编程的未来

下期预告：真正的项目是怎么用 Claude Code 完成的？从天气应用到大规模重构，从个人 side project 到 Anthropic 内部的生产系统。第七期，我们走进真实案例。

2026 年 6 月
一	二	三	四	五	六	日
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30