今天刷推特的时候，看到 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 test5. 代码审查时更新 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 PR8. 常用几个 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.md9. 用 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. CLAUDE.md 要迭代，但别指望它万能。有些规范能约束，有些约束不了，需要自己摸索。 2. 模型选择要看场景。复杂任务用 Opus，日常开发 Sonnet 够了，别为了追求"最好"而忽视成本。 3. 多终端并行确实有效。但不一定要开太多，3 个形成设计-开发-测试流水线对我来说很够用了。 4. Plan mode 是好习惯。先对齐思路再动手，避免返工。 5. 给 Claude 验证手段。写测试、跑 lint、执行构建，让它能自己检查自己的工作。 6. 把好用的配置提交到 git。slash commands、permissions、MCP 配置，团队共享，一起进步。
最后，Claude Code 这个工具还在快速进化，今天的最佳实践明天可能就过时了。保持学习的心态，持续实践，才是正道。
