Claude Code如何更加高效使用？Claude Code创始人分享的13条Claude Code实践经验总结
480 views
加载中...
加载中...
Follow DataLearner WeChat for the latest AI updates
Claude Code 诞生于 Anthropic，应该是2025年最吸引人的大模型产品之一。正式发布3个月后使用了增长10倍，年收入接近10亿美元。但Claude Code并不是那种“先想清楚定位，再设计用户用法”的产品。而是先被一群工程师当成生产工具用起来，再逐渐长成一个系统。
今天，Claude Code 的创建者 Boris 发了一条很长的 thread，第一次比较完整地讲了他自己是怎么使用 Claude Code 的。共13条总结，我们这里总结一下，供大家参考。
很多人用 Claude Code 的方式，和用 ChatGPT 没什么本质区别：开一个会话，盯着它想、写、跑，然后等结果。
Boris 的做法不是这样的，在他的终端里，常年开着 5 个 Claude 会话。不是为了炫技，而是因为单会话写代码本身就不合理。因为一个 Claude 在思考、改文件、跑命令的时候，你的人是空出来的；如果只有一个会话，空闲时间会被不断浪费。
他做的事情很简单：把 Claude 当成可以并行调度的工程资源。每个 tab 固定编号，用系统通知提醒哪个 Claude 需要输入。
你不再“盯着它干活”，而是让它在后台推进任务，你在前台切换注意力。不过，这个消耗也是巨大的，我们普通用户可能也没那么大成本去做这个事情，不过如果同时使用量大的其它产品如Codex、Antigravity也许可以。
在 Boris 的工作流里，Claude 并不固定存在于终端、Web 或手机中的某一个地方。
他会在终端里跑着 Claude，同时也在 Web 上再开一批；写代码写到一半，如果觉得某个任务更适合在 Web 里继续，他就直接把会话交过去；有时候反过来，再切回本地继续。
甚至在不坐在电脑前的时候，他也会在手机上启动几个 Claude，让它们先跑着，等有空再回来查看结果。 Claude 在这里更像是可迁移的异步任务，而不是一次性的对话窗口。
Boris 几乎所有事情都用 Opus 4.5，而且是带 thinking 的版本。这并不是因为它“最强”，而是因为它最不容易跑偏。
即便它看起来更慢、更重，他也觉得更省时间。原因很现实：这种模型更少跑偏，更少需要你中途接管，也更擅长把工具用对。对他来说，真正浪费时间的从来不是“多等几秒”，而是反复纠正和返工。
不过，这对于我们普通用户不显示，毕竟额度有限！
如果只看前面几条，你可能会觉得这只是“多开 + 强模型”。
但从 CLAUDE.md 开始，Claude Code 的工程属性才真正显露出来。他们整个团队共享一个 CLAUDE.md 文件，直接提交到仓库。
它不是文档，更像是Claude 的长期记忆外置层。
只要 Claude 在某个场景下做错了事，团队成员就会把“不要这么做 / 下次应该怎么做”写进这个文件。下一次、再下一次，Claude 会自动带着这些约束进入工作。这样就能把团队对代码风格、工程习惯、风险边界的共识，固定下来。
这套机制甚至被嵌进了代码评审。Boris 会在同事的 PR 里直接 @.claude，要求把新发现的问题补充进 CLAUDE.md，并作为 PR 的一部分提交。
换句话说：**每一次 Review，不只是改代码，也在更新 Claude 的行为边界。**他把这件事类比为一种工程经验的“复利累积”，这个比喻非常贴切。
Boris 很少让 Claude “直接改代码”。相反，他会先进入 Plan Mode，反复推敲方案本身：
只有当这个计划本身让他满意，他才会切换到自动接受修改，让 Claude 一次性把改动落完。这样做最大的原因是Boris认为计划不是拖慢节奏，而是在避免更大的返工。
用 Claude Code 写久了，我们通常会发现有一些工作也很烦。不是模型不行，而是你开始一天几十次地对它说同样的话，比如“看下 git 状态”、“帮我写 commit”、“push 并开 PR”之类的。
自然语言在这里变成了累赘。Boris 的做法是，把这些高频内循环全部变成 Slash Commands。这些命令不是“快捷提示”，而是可以被版本控制、可以共享、可以预先计算上下文的工程流程。这里说的Slash Command就是斜杠命令，用户可以在Claude Code中自定义这种斜杠命令，然后就可以节省很多时间了。
比如可以自定义一个 /commit-push-pr：命令里会用 bash 先算好 git 状态、diff 信息，避免 Claude 再来回追问。
有些事情几乎每个 PR 都要做，如代码简化、端到端验证、基本自检等。如果每次都靠人记，很容易忘；如果每次都混在主会话里，又容易干扰主要任务。
Boris 会把这些事情交给专门的 Subagent。这样它们就变成了默认会发生的步骤，而不是“希望别忘了做的事”。
CI（持续集成）本来是用来帮你自动检查代码质量的，比如跑测试、检查格式、做基础校验，但在实际工程里，它也经常因为一些很小的细节反复失败。
Claude 生成的代码大多数时候已经很干净了，但最后那点格式问题，依然可能让 CI 挂掉，导致一次很小的改动也要来回修好几轮。
与其每次等 CI 失败后再补救，不如在流程里直接把这些事情自动处理掉。 Boris 用 PostToolUse hook 在 Claude 调用工具之后做一次收尾格式化，让这些问题在后台被消化掉。
这不是在追求“更聪明的模型”，而是在减少工程系统里的无意义摩擦。
--dangerously-skip-permissions是Claude Code中一个非常高效的参数，就是你可以让Claude Code直接执行所有的命令而不需要确认，可以省去很多麻烦，但是这也可能会导致出现删除根目录这种无法挽回的错误。
Boris 明确说，他不会直接用 --dangerously-skip-permissions。取而代之的是，用 /permissions 预先放行一批确认安全的命令，并把配置写进共享的 settings。
虽然这牺牲了一点效率，但是确保不会发送系统性风险。
在他的日常里，Claude Code会帮他搜 Slack、查 Sentry 错误、跑 BigQuery 查询。这些能力通过 MCP server 接进来，配置写在 .mcp.json，团队共享。
Claude 在这里已经不是“代码助手”，而是被接入到真实工程系统里的一个执行节点。
有些任务并不是几分钟就能跑完的，比如大范围改动、复杂验证或者端到端测试。如果默认假设“Claude 跑完的时候，人正好坐在电脑前确认”，这个流程在现实里很容易失效。
Boris 不太接受这种不确定性。
他的做法是：在任务真正结束之前，强制加一道固定的收尾检查。有时候是让 Claude 在完成后再跑一次验证；有时候是用 Stop hook，确保 Claude 在“准备停下来”之前，一定会执行预先定义好的检查步骤。
这样一来，任务是否可靠，不再取决于“人有没有盯着”，而是由流程本身保证。Claude 可以自己跑、自己停、自己给出一个可以验收的结果。
Boris 最后反复强调的一点是：一定要让 Claude 能验证自己的工作。
在 Claude Code 本身的开发中，Claude 会自动打开浏览器、测试 UI、反复调整，直到功能真的跑通、体验也说得过去。有了这样的反馈回路，结果质量会明显提升。
这不是某个技巧，而是一条使用原则。他的结论很直接：有验证闭环，结果质量能提升 2–3 倍。
Boris这些技巧乍一看好像普普通通，但是这是开发过程中一些可能容易忽视的地方。这条 thread 真正展示的，不是一堆技巧。它展示的是：
当你把 Claude Code 当成工程系统，而不是聊天工具时，它会自然演化出的样子。
并行、约束、验证——Boris 的所有习惯，几乎都围绕这三个词展开。Claude Code这种自然语言的工程虽然极大提高效率，但也因为边界模糊、结果难以验证可能被很多人不看好。但是显然，随着这些工作的发展，可能有一套与传统写代码不一样的工程规范也在形成。