Claude Code创始人亲授13招，看完发现我一直在"青铜"操作

今天刷推特的时候，看到 Claude Code 的创造者 Boris Cherny 发了一个长帖子，分享他自己是怎么用 Claude Code 的。3.2M 的浏览量，说明大家对这个话题确实很感兴趣。

国内很多博主已经就这篇帖子写了不少内容，但我有点不一样的想法，想结合我自己的实践经验来聊聊。

Boris 说了啥

先简单梳理一下 Boris 分享的 13 条心得：

1. 并行运行 5 个 Claude

Boris 在终端里同时开 5 个 Claude Code，给 tab 编号 1-5，用系统通知来知道哪个 Claude 需要输入了。

2. 本地+云端并行

除了本地的 5 个，他还在 claude.ai/code 上同时跑 5-10 个。本地和云端之间还会"传送"会话，用 & 把本地会话推到云端继续跑。

3. 只用 Opus 4.5 with thinking

他说这是他用过的最好的编码模型，虽然比 Sonnet 大、慢，但因为不用怎么纠正它，工具使用也更好，最终反而更快。

4. 团队共享 CLAUDE.md

他们整个团队共用一份 CLAUDE.md，提交到 git 里，每周都有人贡献更新。只要发现 Claude 做错了什么，就加到 CLAUDE.md 里，让它下次别再犯。

Boris 分享的 CLAUDE.md 示例：

# Development Workflow

**Always use `bun`, not `npm`.**

# 1. Make changes

# 2. Typecheck (fast)
bun run typecheck

# 3. Run tests
bun run test -- -t "test name"    # Single suite
bun run test:file -- "glob"       # Specific files

# 4. Lint before committing
bun run lint:file -- "file1.ts"   # Specific files
bun run lint                      # All files

# 5. Before creating PR
bun run lint:claude && bun run test

5. 代码审查时更新 CLAUDE.md

审查同事 PR 的时候，会直接 @.claude 让它把某些规范加到 CLAUDE.md 里，用 GitHub Action 自动执行。

6. 大多数会话从 Plan mode 开始

按两下 shift+tab 进入 Plan mode，先和 Claude 来回讨论计划，满意了再切到自动接受模式，通常能一次搞定。

7. 用 slash commands 处理高频操作

那些每天重复做的事情，都封装成 slash commands，比如 /commit-push-pr。命令文件提交到 git 的 .claude/commands/ 目录。

> /commit-push-pr

/commit-push-pr    Commit, push, and open a PR

8. 常用几个 subAgents

code-simplifier 负责简化代码，verify-app 负责端到端测试，build-validator、code-architect 等。

.claude
└── agents
    ├── build-validator.md
    ├── code-architect.md
    ├── code-simplifier.md
    ├── oncall-guide.md
    └── verify-app.md

9. 用 PostToolUse hook 格式化代码

Claude 生成的代码 90% 情况下格式都不错，hook 处理剩下 10%，避免 CI 报格式错误。

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

10. 不用 --dangerously-skip-permissions

而是用 /permissions 预先允许那些他知道安全的命令，配置提交到 .claude/settings.json 和团队共享。

Permissions: [Allow]  Ask  Deny  Workspace

Claude Code won't ask before using allowed tools.

Bash(bq query:*)
Bash(bun run build:*)
Bash(bun run lint:file:*)
Bash(bun run test:*)
Bash(bun run test:file:*)
Bash(bun run typecheck:*)
Bash(bun test:*)
Bash(cc:*)
Bash(comm:*)
Bash(find:*)

11. Claude Code 调用各种工具

通过 MCP 连 Slack、用 bq CLI 跑 BigQuery 查询、从 Sentry 拉错误日志，这些配置都提交到 .mcp.json 共享。

.mcp.json 配置示例：

{
  "mcpServers": {
    "slack": {
      "type": "http",
      "url": "https://slack.mcp.anthropic.com/mcp"
    }
  }
}

12. 长任务用后台 agent 验证

任务跑完后用后台 agent 验证结果，或者用 agent Stop hook，或者用 ralph-wiggum 插件让 Claude 持续迭代。

13. 最重要的一条：给 Claude 验证手段

如果 Claude 能验证自己的工作（比如跑测试），最终结果质量能提升 2-3 倍。Boris 说他落地的每个改动，Claude 都会跑测试。

我的一些不同看法

看完 Boris 的分享，说实话既佩服又有点"不服"。佩服的是他确实把 Claude Code 玩到了极致，不服的是有些做法对我们普通开发者来说不太现实。

关于 CLAUDE.md 迭代

这一点我是完全赞同的，我自己也是这么做的。每次发现 Claude 有什么坏习惯，就往 CLAUDE.md 里加一条。

但说实话，CLAUDE.md 也有不生效的时候。

举个例子，我在 CLAUDE.md 里写过这样的规范：

## 开发规范

每个函数不超过80行
单个代码文件不超过800行，超过就要拆分
使用策略模式解耦多数据库的实现，方便扩展和维护

结果呢？单文件行数这条，Claude Code 就是控制不好，不能完全按要求来。我后来干脆放弃了这个要求，等代码开发得差不多了，再统一按这个标准来优化。

不过有些规范确实很有效，比如我在 CLAUDE.md 里加的文档管理流程：

## 文档管理

- 设计文档位于 `spec/` 目录
- 完成功能后更新对应 spec 文档的验收标准状态（将 `[ ]` 改为 `[x]`）

有了这个，每次开发的时候先改设计文档，再开发，开发完再更新文档，这一套流程下来效率确实很高。

所以我的体会是，CLAUDE.md 不是万能的，有些约束它能遵守，有些它就是记不住。需要自己摸索哪些规范有效，哪些需要换个方式来约束。

关于只用 Opus 4.5

这点我倒不觉得很有必要。

Boris 是 Anthropic 的员工，token 可以敞开用，不用考虑成本。但我们得考虑性价比啊。

我的做法是分场景用不同模型：

• • 复杂的架构设计、疑难 bug，用 Opus
• • 日常的功能开发、简单改动，Sonnet 就够了
• • 快速的代码格式化、简单查询，Haiku 都行

不是每个任务都需要动用最强模型的。这就好比开车，不是所有路况都需要踩地板油。

关于多 Agent 并行

这点我倒是很认同，而且我自己也在用，只是姿势稍有不同。

Boris 是开 5 个甚至 10 个 Claude 同时跑，我没那么激进，通常是 3 个：

• • 一个终端在设计下个模块的功能
• • 一个终端在开发当前模块的功能
• • 一个终端在部署测试

这样形成一个流水线，设计完的交给开发，开发完的交给测试，效率确实比串行高不少。

关于先计划再执行

这点非常认同。Boris 说的 Plan mode 确实好用。

我之前在翻译《How Claude Code is built》那篇文章的时候，就了解到 Boris 如何在两天内用几个小时构建了大约 20 个新功能原型——待办事项列表。那种快速原型迭代的能力，很大程度上来自于先想清楚再动手。

Plan mode 的好处是让 Claude 先输出它的思路，你可以审核、纠正、补充，达成共识后再让它动手。这样避免了 Claude 闷头写一大堆代码，结果方向错了要返工的情况。

关于验证反馈循环

这是 Boris 说的最重要的一点，我也深有体会。

他说的有点像 Codex 的 react 模式了——Claude 写完代码，跑测试，看结果，再改，再跑，形成闭环。

我现在的做法是，开发一个功能之前，先让 Claude 写测试用例，然后再写实现代码，最后跑测试验证。这样 Claude 有了明确的"对错标准"，出来的代码质量确实更高。

手中无剑，心中有剑

说到底，Boris 是大神级别的开发者。

他对 Claude Code 的熟悉程度，比我们任何人都深——毕竟他就是创造者。他知道哪些 prompt 有效，哪些配置能提升效率，哪些功能可以组合使用。这种熟悉程度让他能够"手中无剑，心中有剑"，看似简单的 vanilla 设置，背后是对工具的深刻理解。

但对于我们普通开发者来说，我觉得关键还是实践。

不要看到大神的分享就照搬，每个人的项目不同、习惯不同、场景不同。多去用用，用多了自然有感觉了。踩过的坑、摸索出的技巧，才是真正属于自己的经验。

然后再参考其他人的最佳实践，取其精华，找到适合自己使用 Claude Code 的姿势。

这就好比学武功，招式可以学，但内功得自己练。Boris 分享的是招式，我们得通过大量实践来积累内功。

几点实操建议

基于我自己的经验，给大家几点实操建议：

1. 1. CLAUDE.md 要迭代，但别指望它万能。有些规范能约束，有些约束不了，需要自己摸索。
2. 2. 模型选择要看场景。复杂任务用 Opus，日常开发 Sonnet 够了，别为了追求"最好"而忽视成本。
3. 3. 多终端并行确实有效。但不一定要开太多，3 个形成设计-开发-测试流水线对我来说很够用了。
4. 4. Plan mode 是好习惯。先对齐思路再动手，避免返工。
5. 5. 给 Claude 验证手段。写测试、跑 lint、执行构建，让它能自己检查自己的工作。
6. 6. 把好用的配置提交到 git。slash commands、permissions、MCP 配置，团队共享，一起进步。

最后，Claude Code 这个工具还在快速进化，今天的最佳实践明天可能就过时了。保持学习的心态，持续实践，才是正道。