你的 AI 原地打转？硅谷十年工程师，带你稳产 10w 行商业级代码

Claude Code 可能可以算是现在世界上最成功的 AI Agent 产品了：超过百万开发者在使用，贡献了全球 GitHub 4% 的公开代码，年收入超过 25 亿美元。

但这个产品最开始是由一个人创建的，即使到现在，核心团队也不超过 10 个人。约 90% 的 Claude Code 代码是由 Claude Code 自己写的。而且更新速度快到起飞，天天放大招，几乎每隔几天就有重大更新。

📺 视频版：你的 AI 原地打转？硅谷十年工程师，带你稳产 10w 行商业级代码

所以今天我就来和大家聊聊：创造这个工具的团队成员们，他们自己是怎么用 Claude Code 的。

大道至简——这些高手使用的方法，其实反而很简单。我每天在工作中都会用到，我觉得人人都能学会。而且就算你不用 Claude Code，相信你也能从中得到一些启发。

在哪里追新功能？

Claude 团队核心成员的 X 动态，是你跟进 Claude Code 最新功能的最佳渠道。有什么新功能，他们一般都会第一时间在自己的动态上发布，甚至比官方的文档还快。

所以我专门做了一个网站，把核心团队成员的 X 动态都汇总在一起，实时更新——帮你了解第一手资讯，不必再等公众号、自媒体的二手信息。

Claude Code 团队成员动态聚合站

第一招：模型选择——干脆只用 Opus

Claude Code 的创始人加负责人 Boris 说，他只用 Opus。

Opus 虽然更慢更贵，但你需要花更少的时间告诉它具体怎么做。所以到头来，它可能既省你的时间，也省你的 token。

我一开始也是「小农思想」作祟，总觉得应该把钱花在刀刃上，还自己手动去挑：什么任务复杂交给 Opus，什么任务简单交给 Sonnet。后来我发现，真正值钱的、真正让整个项目变慢的，其实是人的注意力。你的时间、你的注意力，才是最值钱的部分。

Boris 在 X 上分享他自己的 Claude Code 配置

所以我现在就改成什么都只用 Opus，并且每次都把 thinking 开到最大。体感真是好了太多。

第二招：用 git worktree 并行开发

这个技巧真的是彻底改变了我开发的方式。它属于那种让你能从「一天完成一两个改动」变成「完成 10 个 20 个」的差别。

如果你对 git worktree 不熟悉——它其实是 git 里一个存在了 10 年的老功能，但在 Coding Agent 时代又重新焕发了生命力。它可以让你同时 checkout 多个 branch，并行修改，互相还不影响。

使用方法非常简单，直接在 claude 命令后面加上 worktree 参数就可以了。

我个人更喜欢用 Worktrunk，因为它有一个内置的设置，可以帮你把 .gitignore 的文件也复制到你的 worktree 里面（比如你的环境变量、还有一些 secrets 什么的），而且是 copy on write，所以复制文件是不花时间的。这对于很多需要预先编译的项目来说，简直就是巨大的福音。

Worktrunk — 为并行 AI Agent workflow 设计的 git worktree 管理器

你只需要在 worktrunk 的配置文件里加一行 [post-start]，每次创建新 worktree，它就会自动帮你把那些 gitignored 文件（.env、secrets 等等）都复制进去——非常省心。

Worktrunk 的 post-start 配置：自动复制 gitignored 文件到新 worktree

我还会设置一个 wsc 这样的别名，每次运行的时候它就自动创建一个 worktree，并且自动帮你启动 Claude Code。

wsc 别名定义：一条命令开 worktree + 启动 Claude Code

当修改全都完成的时候，只需要简单地运行一下 wt merge，所有的变动就都自动回到 main branch 了。

并行开发的好处是速度快了，但问题是真的很累人。我一般最多就开 5 个 Claude——大概是我现在能处理的上限。再多了，脑子真的绕不过来了。

第三招：基于 Spec 的开发

尤其是针对比较大的功能，有 Spec 真的是非常重要。

Claude Code 团队的 Thariq 介绍了他自己的方法：他会先从一个很简单的 spec.md 文件开始，然后再让 Claude 通过 AskUserQuestion 这个工具不断问他问题，直到达到一个完善的状态。

Thariq 分享他基于 Spec 的开发流程

我个人很喜欢用 OpenSpec，非常轻量级。什么变动我都会先从 explore mode 开始，和 Claude 一通头脑风暴。完成之后，再让它把所有的讨论细节都写成 spec 文档，然后开启新 session 开始实现。

相当于是把每一个任务的「计划、确认、需求、设计」这些先行规划步骤，和后面写代码执行的步骤分开来——防止上下文污染。

能不能正确地使用基于 Spec 的开发，我觉得是能区分一个人「是只能用 AI 做小项目，还是做超过 10 万行代码的项目还能高质量完成」的分界线。

第四招：CLAUDE.md 的正确使用姿势

Claude 团队是整个团队共享一个 CLAUDE.md 文件，提交到 git 仓库。每次 Claude 做错什么，就把教训添加到 CLAUDE.md。Boris 称之为 Compounding Engineering——也就是「复利工程」。

这里有几个技巧：

用 init 命令生成基于项目结构的起始 CLAUDE.md
保持在 200 行以内，并且只包含普遍适用的信息（因为每次会话都加载，消耗上下文）
用 @ 引用一个 markdown 文件的方式做渐进式披露
像对待代码一样对待它——出问题时审查、定期修剪
用强调语，比如 IMPORTANT、YOU MUST 等等，提高遵守率

第五招：让 Claude 自己验证完成的结果

Boris 说，这是他最重要的一条建议：

在 Claude 完成工作之后，给它一条 prompt，让它自己去验证结果。

如果你做的是网页应用，可以用 Playwright、Chrome DevTools 这样的工具，让 Claude 自己打开网页验证。如果你做的是移动应用，可以用 Agent Device 这样的工具，让 Claude 打开模拟器验证自己的结果。

更进一步——可以让 Claude 自己验证结果，并让它给出验证的证明。

这里我把我的流程提取成了一个开源项目，叫 ProofRun。你只需要安装这个 skill，它会告诉 Claude：怎么设计测试、启动模拟器来跑验证、然后给你生成一个报告页面。你可以在报告里给出反馈，说「行」还是「不行」——提交之后，它会自动把你的反馈给到 Claude，Claude 看到之后就会进一步修改、再验证、再迭代。

💻 项目源码：rokabytedev/proofrun

ProofRun — 让 AI 给你交作业的同时，附上证明

用了这样的工具之后，我感觉 Claude 完成任务的一次通过率大幅提升，大幅降低了需要手动介入、跟它反复讨论修改 debug 的可能性。非常建议尝试。

好，今天就聊这么多。欢迎你在评论区留言，告诉大家——你有什么独门秘诀？

我是佳楠，我们下期再见。