来整理一下 Claude Code 诞生的故事，主要来源是科技博主 Gergely Orosz 采访 Claude Code 核心成员的文章。 Claude Code 确实了不起，5 亿美元年化收入，三个月用户量涨了 10 倍，现在也是很多程序员首选 Coding Agent 工具。 这个工具最初只是一个能告诉你“现在在听什么歌”的命令行小玩具。 🧵

Gergely Orosz 采访了 Claude Code 的三位核心成员： • 创始工程师 Boris Cherny（17 年从业经验，前 Meta 主任工程师） • 二号工程师 Sid Bidasaria（Subagents 功能的作者） • 以及产品经理 Cat Wu。 他们聊了 Claude Code 是怎么从原型变成产品的，技术上做了哪些选择，以及这个十几人的小团队如何做到每人每天发布 5 个 PR。 这可能是目前最接近“AI 优先工程团队”的样本。他们用 AI 写代码、写测试、做代码审查、排查故障，甚至用 Claude Code 来开发 Claude Code 本身。90% 的代码是它自己写的。 我想做的是把这次采访里最有意思的部分整理出来，讲讲这个团队是怎么工作的，有什么可以借鉴的，又有什么是他们的特殊条件决定的、不能照搬的。 下面分成 7 个小故事，每个都能独立看，串起来是一个完整的图景。

【1】一个听歌小工具，如何变成年入 5 亿美元的产品 2024 年 9 月，Boris Cherny 刚加入 Anthropic，闲着没事写了个命令行小玩具。 这东西能干嘛呢？它能用 AppleScript 告诉你现在在听什么歌，还能根据你的指令换歌。就这么简单。Boris 自己的评价是：“挺酷的 demo，但没啥意思。”

真正的转折发生在他和同事 Cat Wu 聊完之后。Cat 当时在研究 AI Agent 的计算机使用能力，聊着聊着，Boris 冒出一个念头：如果给这个命令行工具更多权限呢？比如让它能读写文件、能执行命令？

他试了。然后，见证奇迹的时刻来了。 Boris 把这个升级版工具扔进 Anthropic 的代码库，随便问了几个问题。Claude 开始自己探索文件系统——读一个文件，看到里面的 import 语句，就顺着去读被引用的文件，一层层往下挖，直到找到答案。 “这把我震住了，”Boris 回忆说，“我从来没用过这样的工具。”

在 AI 领域有个概念叫“product overhang”，翻译过来就是“产品溢出”。意思是模型其实已经具备某种能力了，但现有的产品形态没有把这种能力释放出来。 Boris 发现的，正是一个巨大的“product overhang”，Claude 早就能做到这些，只是没人给它造个壳子。

Boris 开始每天用这个工具干活，然后分享给几个同事。两个月后的 11 月，他们发布了一个内部版本。 数据很夸张：第一天，20% 的工程师在用；第五天，50%。

这时候出现了一个有趣的争论：要不要对外发布？ 反对的理由很真实：这东西如果真有我们以为的那么强，留着当“秘密武器”不好吗？为什么要把竞争优势拱手让人？ 最终，Anthropic 选择了发布。逻辑是这样的：Anthropic 的核心使命是研究模型安全，而研究安全最好的方式是让人真正使用这些工具。既然内部已经验证了 Claude Code 会被大量使用，那发布它就能带来更多关于模型能力和安全的洞察。

2025 年 5 月，Claude Code 正式公开。三个月后，使用量涨了 10 倍，年化收入超过 5 亿美元。 有意思的是，Boris 最初只想着给程序员用——所以才叫“Claude Code”。但有一天他走过数据科学家的工位，发现对方屏幕上也跑着 Claude Code。“你用这个干嘛？”“我让它帮我写查询、做可视化啊。”现在，Anthropic 的数据科学家们人手一个，有些人同时开好几个。 一个听歌小工具，因为多给了几个权限，变成了一个价值数亿美元的产品。这大概是“product overhang”最好的证明，模型能力一直在那儿，等的只是有人把它释放出来。

【2】90% 的代码是自己写的——Claude Code 的技术选型哲学 Claude Code 有 90% 的代码是它自己写的。 听起来像噱头，但这其实归功于他们的技术决策逻辑。 先看技术栈：TypeScript 写主体，React 搭配 Ink 框架做终端 UI，Meta 开源的 Yoga 做布局系统，Bun 负责构建打包。 为什么选这些技术栈呢？因为它们“在分布内”。 “在分布内”（on distribution）是 AI 领域的术语。意思是模型已经见过大量这类代码，擅长处理它们。TypeScript 和 React 正是 Claude 的强项。如果选一个冷门框架，模型就得“学习”，效果会打折扣。 这个选择带来一个美妙的循环：用 Claude 擅长的技术栈写 Claude Code，然后用 Claude Code 写更多 Claude Code。90% 自己写自己，就是这么来的。 他们在架构层面的选择同样简洁。 Claude Code 在本地运行。没有 Docker 容器，没有云端沙箱，就是直接在你的电脑上读写文件、执行命令。

至于为什么这样设计？ Boris 的回答是：“每次做设计决策，我们几乎都选最简单的方案。本地运行就是最简单的答案。” 这种简单延伸到整个产品哲学：尽可能少写业务逻辑，让模型做主角。 “这听起来可能有点奇怪，”Boris 说，“但我们希望用户能尽可能“原汁原味”地感受模型。很多 AI 产品会加一堆脚手架——额外的 UI 元素、各种辅助功能——结果反而限制了模型的发挥。我们要做的是让 UI 尽可能精简。” 为了保持简洁，每次 Claude 发布新模型，他们就会大量精简代码。 比如 Claude 4.0 发布时，他们删掉了大约一半的系统提示词，因为新模型不再需要那些“拐杖”了。工具数量也在不断精简——能删就删，能合并就合并。 整个 Claude Code 架构可以概括为三件事：定义 UI 并暴露给模型修改的接口、暴露工具让模型调用、然后闪到一边去。 当然，简单不意味着没有复杂的部分。权限系统就是例外。 毕竟让 AI 在你电脑上执行命令是有风险的。Claude Code 的解决方案是执行前先问你：要不要批准这个操作？可以只批准这一次，也可以以后都批准，或者拒绝。 权限系统支持多层配置——按项目、按用户、按公司。团队可以共享配置文件，把常用的安全命令加入白名单。 这套权限设计背后的原则是这样的： 如果你启动 Claude Code，它不应该在没经过你同意的情况下改动任何东西。但同时，也要给用户“放权”的选择——在你信任的场景下，可以跳过确认环节。 简单，但不是简陋。克制，但不是功能缺失。

【3】两天 20 个原型——AI 时代的产品迭代长什么样 以前做产品原型，两天能做出两个就算效率高了。 Boris 花两天做了 20 个。 这不是夸张，是他开发 Claude Code 的 todo list 功能时的真实记录。他甚至把每一步的提示词和截图都分享了出来。 我们来看看这 20 个原型是怎么迭代的。 第一版，他想让 todo 列表显示在最近一次工具调用的下方。提示词很短：“让 todo 不要随着输入出现，而是在输入框上方显示一个固定的 todo 列表，标题用灰色显示 '/todo (1 of 3)'”。 看了看效果，不太满意。 第二版，改成在每个 todo 更新时内联显示。提示词：“其实不要显示 todo 列表，改成在模型开始处理一个 todo 时，把工具名称渲染成粗体标题。保留'step 2 of 4'这样的进度显示。” 还是不对。 第三版和第四版，他尝试做一个“交互式药丸”——屏幕底部一个小方块，点开能看进度。“在文字输入框下面加一个 todo 药丸，类似后台任务的样式，显示 'todos: 1 of 3'。”然后：“让这个药丸可以交互，像后台任务药丸那样。” 有点意思了，但还不够好。 第五版和第六版，他换了个思路：做个从右边滑出来的“抽屉”。“把之前的药丸和标题都撤销，改成在输入框右边显示 todo 列表，垂直居中，用灰色分隔线隔开。”“有点跳，能不能做成抽屉动画？” 看起来挺酷，但实用性存疑。 第七到第九版，他又把 todo 列表挪到输入框上方，试验不同的截断方式和标题样式。“如果超过 5 个就显示'... and 4 more'”，“加个灰色的 'Todo:' 标题”。 离答案越来越近了。 第十到二十版，他开始琢磨怎么把 todo 列表和加载动画结合起来。最后的解决方案是把进度信息放到 spinner（加载指示器）旁边，最大化可见性。 发布后，用户反馈说想看完整的 todo 列表。于是又加了一个迭代：按 Ctrl+T 可以展开全部步骤。 这就是现在线上的版本。

整个过程里，Boris 的提示词出奇地简短——大多数就一两句话。但每一版都是可以实际运行的原型，不是静态图，不是 PPT。他可以真正测试验证这个功能，感受它顺不顺手。 传统的产品开发流程是：想法 → 讨论 → 画线框图 → 做高保真设计 → 开发 → 测试 → 上线。每一步都要时间，每一步都可能卡住。 现在的流程变成了：想法 → 一句话提示词 → 可运行的原型 → 感觉不对就再来一版。 这其实要求开发者在思维方式上进行改变，才能适应这种开发流程。 以前，原型的作用是“验证想法”——因为做原型成本高，你得先想清楚再动手。现在，原型变成了“探索可能性”——因为做原型成本低，你可以先做出来再说，不好就扔掉。 Boris 说，用 Claude Code 的时候，他经常直接跳过画设计图的阶段，直接做一个能跑的版本，比什么都直观。 Claude Code 团队的日常节奏是：每个工程师每天推大约 5 个 PR，内部每天发布 60-100 个版本，外部每天发布 1 个版本。 一天 5 个 PR，这在大多数公司是难以想象的。Uber 在最紧张的重构期，一天能推一个中型 PR 就算不错了。 工具变了，节奏就变了，思维方式也得跟着变。

【4】重新设计集成 AI 后的命令行终端 命令行终端已经存在了几十年，为什么现在需要重新设计？ 因为在 LLM 出现之前，终端并不会太注重交互体验。 传统的命令行是一问一答：你输入命令，它返回结果，完事。没有对话，没有上下文，没有等待时的反馈。你盯着光标闪烁，不知道后台在干嘛。 Claude Code 是第一批真正需要思考“终端 UX”的产品。他们加了几个小细节，看起来不起眼，但用起来感受完全不同。 第一个：上下文加载提示。 当模型在思考时，屏幕上能根据当前任务显示生成相关的提示：比如“正在阅读你的代码结构”或者“正在思考解决方案”。 这是个很小的触感，但它让工具有了“人格”。你会觉得它在认真干活，而不是卡住了。Boris 说，上一次他看到这种让人愉快的小交互，还是 Slack 的新手引导流程。 第二个：等待时的教学提示。 当 Claude 在执行一个长任务时，屏幕底部会轮流显示使用技巧，比如“你可以按 Esc 中断当前任务”或者“试试 /help 看看所有命令”。 命令行用来教命令行，简单又聪明。 第三个故事更精彩：Markdown 渲染器。 发布前一天，有工程师抱怨嵌套列表显示得很丑，段落间距也不对。问题出在 Markdown 渲染器上。Boris 试了市面上所有现成的渲染器，没一个在终端里好看的。 于是他用 Claude Code 花了一天时间，从头写了一个 Markdown 解析器和渲染器。 对，发布前一天。对，从头写。对，用的是 Claude Code 自己。 结果这个“赶工”出来的渲染器，比所有现成方案都好看。他们直接发布了。Boris 认为现在没有任何其他终端有同样质量的 Markdown 渲染。 这个故事说明了一件事：当你有一个足够好的 AI 编程工具时，“自己造轮子”的成本会大幅下降。以前“能用就行”的妥协，现在可以变成“那就做一个更好的”。 命令行终端这个古老的界面形态，正在因为 LLM 的加入而焕发新生。终端还是那个终端，只是因为有了 AI 的加入，让我们需要认真思考：怎么让人和终端里的 AI 更好地对话。

【5】AI 渗透到每个环节——一个工程团队的“全面 AI 化”实验 Anthropic 的工程团队，可能是目前把 AI 工具用得最极致的团队之一。 不只是体现在写代码上，而是是项目中的各个环节。 代码审查：所有 PR 的第一遍审查由 Claude Code 完成，工程师做第二遍。Boris 说，Claude Code 在第一遍就能发现很多问题。这个功能原本只在内部用，后来他们把它公开了，所有人都能用 Claude Code 做安全审查。 写测试：Claude Code 的测试套件几乎全是 Claude Code 写的。Boris 说：“以前如果有人提 PR 不写测试，我会犹豫要不要说什么——感觉像在挑刺。但现在有了 Claude，写测试就是一句提示词的事，没有借口不写。” 事故响应：oncall 的工程师会让 Claude Code 帮忙分析 Root Cause（导致问题最根本的原因）。它能从 Slack 拉相关讨论，从 Sentry 拉错误日志，从各种监控系统拉数据，然后综合分析。Boris 说 Claude Code 在某些场景下找 Root Cause 比人还快。 GitHub issue 分流：每当有新 issue 进来，Claude Code 会先做一遍分析，然后工程师问它“能不能实现一下”。Boris 说，大概 20%-40% 的情况下，它第一次就能搞定。 图表和查询：产品数据存在 BigQuery 里，几乎所有查询和可视化都是用 Claude Code 生成的。工程师甚至会让它直接输出 ASCII 图表。

最让我意外的是 TDD（测试驱动开发）的复兴。 TDD 是个老概念了：先写测试，再写让测试通过的代码。理论上很美好——强迫你先想清楚要什么。但实际操作中，大多数人觉得它太慢、太麻烦，所以这个方法在过去十几年慢慢边缘化了。 但 Boris 说，用 Claude Code 之后，他做了大量 TDD： “我会先让模型写一个测试，同时告诉它这个测试现在会失败，不要试图让它通过。然后我再让它写代码实现功能，并且让测试通过，但不能改测试本身。” “当模型有一个明确的目标去迭代——比如一个单元测试或者一个 mock——它表现得非常好。” 他特别提到，Claude 4.0 是第一个能让模型写大部分测试的模型系列。之前的版本可以写一部分，但需要大量人工干预。 还有一个新概念：multi-clauding。 意思是同时运行多个 Claude Code 实例，让它们并行处理不同的任务。Sid 说他经常这么干——开会的时候启动几个 agent，会后回来看结果。 Anthropic 发现，25% 的 Max 订阅用户（月费 100-200 美元的高级用户）每天都在 multi-clauding。 这是一个很有趣的变化。编程一直是“单线程”活动：你一次只能干一件事，只有等代码审查或者部署的时候才会切换任务。但现在，“并行编程”成为可能——你可以同时推进好几件事。 当然，这里面有很多未知数：并行工作是真的更高效，还是只是感觉更高效？什么类型的任务适合并行？每个 agent 分到的注意力变少，会不会出问题？ 这些问题还没有答案。但我们有了一个新工具可以实验。 最后讲一个案例。有家公司要做框架迁移，原本估计需要两个工程年——一个工程师干两年，或者十个工程师干两个半月。他们用 Claude Code，一个工程师两周搞定了。 Boris 说他以前会对这种说法持怀疑态度，但类似的故事他们听到太多次了。

【6】三天黑客松——Subagents 功能是怎么诞生的 Subagents 这个功能的灵感，来自 Reddit 上的一条帖子。 有人说他同时开了五个 Claude Code 实例，给每个实例设定不同的角色，然后用文件系统让它们互相通信。 Sid Bidasaria 看到这条帖子的时候，第一反应是：这个玩法很酷，但用户不应该需要这么折腾。我们应该把它做成产品内置的功能。 正好公司有个三天的内部黑客松，Sid 决定用这三天来做这件事。 第一天，团队兴奋地画出了各种复杂的 Agent 拓扑结构：Agent 之间用消息总线通信、异步模式、多对多交互……图画得很漂亮，概念很先进。 第二天，他们意识到这样做似乎不可行。 问题不是技术实现——那些复杂模式都能做出来。问题是用户没法理解。Claude Code 的 UI 就是一个简单的终端，你怎么在这么简单的界面里让用户明白那些复杂的 Agent 通信模式？ 他们决定推倒重来，回到一个根本问题：普通开发者能用的最简单形式是什么？ 他们给自己定了两条约束： 第一，不发明任何新东西。只用 Claude Code 已有的能力——“/”命令和 .md 文件。 第二，不做 Agent 间通信。改成一个简单的编排模式：有一个主 Agent，它可以调用子 Agent，子 Agent 完成任务后返回结果，仅此而已。 他们还和 Anthropic 的研究团队聊了聊。研究人员正在研究多 Agent 模式，但结论是：复杂的 Agent 拓扑是否真的有效，目前还没有定论。 这给了他们更多信心：既然连研究团队都说复杂不一定好，那就更应该做简单的版本。 第三天结束时，他们做出了一个能用的版本。用户可以在 .md 文件里定义子 Agent 的角色和能力（比如“前端子 Agent：使用 React 19 和 Next.js”），Claude Code 会在合适的时候调用它们，或者用户可以手动触发。 黑客松结束后，稍微打磨了一下，功能就上线了。 现在你可以定义各种专属子 Agent：有安全审计专长的后端 Agent、熟悉特定框架的前端 Agent、专门写测试的 QA Agent……它们可以在后台并行工作，各司其职。 很多团队在黑客松里会舍不得推翻自己的复杂方案，毕竟花了一整天画图讨论，有感情了。能够承认“这条路走不通”并推翻从头开始，需要勇气，也需要对“简单”的信念。 简单不是偷懒。简单是在无数可能性里找到那个用户真正能用的形态。

【7】未来的工程团队会是什么样？一些可以借鉴的，和一些不能复制的 Boris 说：“编程现在太有意思了。上一次有这种感觉，还是中学时第一次在图形计算器上写代码。那种魔法般的感觉，我很久没体验过了，但现在又回来了。” Sid 的感受类似：“让我兴奋的有两件事。一是我们发布的速度——有时候甚至感觉太快了。二是这么多的实验空间——以前的工作虽然也快，但做的东西比较套路，知道答案是什么，就是执行而已。现在不一样，模型每三个月就变一次，我们得不断重新思考怎么做事。” 这些感受很真实，也很有感染力。 但在讨论“未来工程团队会是什么样”之前，也不要忘记 Anthropic 的特殊性。 第一，Anthropic 是研究实验室，不是产品公司。它的核心使命是研究 AI 安全和能力，产品是手段不是目的。这意味着他们对“快速实验”的容忍度比一般公司高得多。 第二，他们的主要产品是 Claude 模型本身。Claude Code 只是模型的一个“套壳”。所以“删代码让模型做更多事”对他们来说是自然选择，但对其他公司可能意味着把核心业务逻辑交给一个黑盒。 第三，所有员工都有无限的 Claude 访问权限，包括最贵的 Opus 模型。在大多数公司，AI 订阅费是需要争取的预算项目，不可能人人敞开用。 第四，团队只有十几个人，流程极简。他们几乎不用 feature flag（功能开关），因为“太慢了”。这在用户基数大、出错成本高的产品里是不可想象的。 所以，直接复制 Claude Code 团队的做法，对大多数团队来说不一定现实。 但有些东西是可以借鉴的。 快速原型的思维方式：就算你做不到一天 10 个原型，能不能从“两周一个”变成“一周三个”？工具已经变了，对“原型应该多快”的预期也该更新了。 AI 辅助代码审查：让 AI 做第一遍审查，人做第二遍。这个流程不依赖无限 API 访问，大多数团队都能尝试。 TDD 的复兴：如果写测试变得足够容易，那“没时间写测试”就不再是借口。这可能是改善代码质量的一个低成本切入点。 Product-minded engineer (有产品感的工程师) 的价值放大：Claude Code 团队没有设计师、没有 PM，就靠几个有产品感的工程师。AI 工具让这种“全栈型人才”能做的事情大幅扩展了。

当然，也有些东西是工具替代不了的。 Boris 能在 20 个原型里挑出最好的那个，是因为他有判断力——他知道什么“感觉对”，什么只是“看起来能用”。这种品味是 17 年软件开发经验的积累，不是 AI 能给的。 团队第一天做了复杂方案，第二天能狠心推倒重来，这种决断力也是人的判断。 知道什么时候该删代码、什么时候该留着，这种架构直觉同样如此。 AI 让执行变快了，但它没有让“知道该做什么”这件事变简单。相反，因为执行成本下降，“做什么”的决策变得更重要了——你可以很快做出 20 个版本，但你得知道哪个是对的。 几年后的软件工程会是什么样子？没人能准确预测。但 Claude Code 团队的今天，可能是很多团队明天的某种预演——更快的迭代、更少的“搬砖”、更多的判断和决策。 工具在变。不变的是，最终做决定的还是人。