不是官方文档，不是营销话术。这是一个每天用 AI 写 100% 代码的人，用半年时间摸索出来的真实经验。
写在前面
前五期我们聊了 Claude Code 的起源、架构、记忆系统、技能和多代理协作。这一期换个节奏——不讲理论，只讲实操。
这篇文章的素材来自 Boris Cherny（Claude Code 创造者）在 2026 年 1-4 月发布的四组技巧分享，以及 Anthropic 团队成员 Thariq 关于会话管理的深度指南。我把它们重新组织成 6 个主题，30 条具体可执行的建议。
每一条都有出处，每一条都经过 Anthropic 内部团队的日常验证。
一、并行是一切的起点
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 内部的生产系统。第七期，我们走进真实案例。
Views: 6
Views: 26