走进 Claude Code：一款意外诞生的终端应用如何成为主流 AI 编程工具

Boris Cherny 最初并没有打算打造 AI 时代最重要的开发者工具。他只是想了解 Anthropic 的 API，并构建了一个小型的终端聊天应用程序来测试它。这个偶然的原型变成了 Claude Code，现在负责全球 4% 的公开提交，并被从最小的 YC 初创公司到 NASA 的火星毅力号团队等组织使用。

意外的起源故事

Anthropic 一直以来的信念是，通往安全 AGI 的道路在于编码：先教模型编码，然后使用工具，最后使用计算机。当 Boris 加入 Anthropic Labs 团队（该团队将推出 Claude Code、MCP 和桌面应用程序）时，没有人要求他构建 CLI。团队隐约知道他们想要一个编码产品，但具体形式由他来决定。

他首先构建了最简单的东西：一个终端聊天应用程序来学习 API。没有 UI，没有设计系统，只有文本输入和文本输出。当工具使用功能发布时，他将 Bash 作为第一个工具插入，完全复制了 Anthropic 文档中的示例，并将其从 Python 移植到 TypeScript。然后他问模型他在听什么音乐。它编写了 AppleScript 来查询他的 Mac 音乐播放器。

“That was my first ever ‘feel the AGI’ moment. The model just wants to use tools. That’s all it wants.” 那是我第一次”感受到 AGI”的时刻。模型只是想使用工具。这就是它想要的全部。

这是 Sonnet 3.5。模型还不能真正编码。但它可以做 Boris 没有预料到的事情。

在第一个原型完成两天后，他开始将其提供给他的团队进行内部测试。第二天早上，另一位名叫 Robert 的工程师已经在他的电脑上安装了 Claude Code，并用它来编码。Boris 告诉他这还没准备好，只是一个原型。但它已经很有用了。

当他们进行发布审查以在外部发布 Claude Code（大约在 2024 年 11 月/12 月）时，Dario Amodei 查看了内部使用情况图表，该图表呈垂直上升趋势，并问道：“你们是否强迫工程师使用它？为什么你们要强制他们？” Boris 回复说，他只是发布了相关信息，人们一直在互相告知。

为六个月后的模型构建

Anthropic 的核心理念，深深地嵌入在 Claude Code 团队的 DNA 中：不要为今天的模型构建，而是为六个月后的模型构建。

当 Claude Code 发布时，模型可能编写了 Boris 10% 的代码。他并没有真正用它来编码；它还不够好。他用它来自动化 git、运行 Bash 命令、操作 Kubernetes。第一个真正的编码用例是编写单元测试，因为风险较低，而且模型在这方面仍然很差。

但这个赌注得到了回报。模型得到了改进，而 Claude Code 已经准备好利用新的功能。

这个理念有一个推论，Boris 称之为“痛苦的教训”，源自 Rich Sutton 的著名文章（Claude Code 团队的座位墙上挂着一份装裱好的副本）。更通用的方法总是胜过更具体的方法。在产品方面：你可以围绕模型构建支架，以在某些维度上将性能提高 10-20%，或者你可以等待几个月，下一个模型就可以原生做到这一点。他们将所有非模型代码称为“支架”，并将其视为本质上是临时的。

“There is no part of Claude Code that was around six months ago. It’s just constantly rewritten.” Claude Code 中没有任何部分是六个月前就存在的。它只是不断地被重写。

他们每隔几周就会取消发布工具，每隔几周就会添加新工具。大约 80% 的代码库不到几个月的时间。

CLAUDE.md：少即是多

Boris 的个人 CLAUDE.md 文件只有两行：

1. 每次提交 PR 时，启用自动合并。
2. 每次提交 PR 时，将其发布到我们的内部团队 Slack 频道中。

其他所有内容都位于项目级别的 CLAUDE.md 中，整个团队都会为其做出贡献，通常每周多次。当 Boris 在某人的 PR 中看到可以避免的错误时，他会在 PR 上标记 Claude 并说“将此添加到 CLAUDE.md 中”。

他对那些 CLAUDE.md 文件变得太长的人的建议是：删除它并重新开始。模型的功能随着每次发布而变化，因此许多旧的指令变得不必要。仅当模型偏离轨道时，才一次添加一条指令。随着每个新模型的出现，你会发现你需要添加的内容越来越少。

潜在需求原则

Boris 将潜在需求称为“产品中最重要的想法”。该原则是：人们只会做他们已经在做的事情。你无法让人们采用全新的行为。如果人们已经在尝试做某事，那就让它变得更容易。但不要试图让他们做不同的事情。

每个主要的 Claude Code 功能都是以这种方式出现的：

CLAUDE.md 来自于观察到用户已经在为自己编写 markdown 文件并让模型读取它们。Boris 只是将这种模式形式化了。

计划模式 诞生于一个星期天晚上 10 点。Boris 正在阅读 GitHub 问题和内部 Slack 反馈频道。他注意到人们在提示 Claude“提出一个想法，计划一下，但不要写任何代码”。他在 30 分钟内构建了计划模式，并在当晚发布了它。它在星期一早上发布了。

“There’s no big secret to plan mode. All it does is add one sentence to the prompt: ‘please don’t code.’ That’s all it is.” 计划模式没有什么大秘密。它所做的只是在提示中添加一句话：”请不要编码。”这就是它的全部。

详细模式 经历了它自己的潜在需求周期。Boris 试图隐藏 bash 输出，并为用户总结它。Anthropic 的员工在一天之内就反抗了。后来，他们隐藏了文件读取和搜索（显示“读取 1 个文件”而不是完整内容），进行了为期一个月的内部测试，然后发布了它。GitHub 用户不喜欢它。他们在 /config 中添加了详细模式作为选项。用户仍然不满意。他们不断迭代。

计划模式的寿命有限

Boris 在大约 80% 的会话中使用计划模式。他的工作流程：在一个终端选项卡中以计划模式开始，移动到第二个选项卡，开始另一个计划，当他用完选项卡时，打开桌面应用程序的代码选项卡并在那里开始更多计划。一旦计划确定，他就会告诉 Claude 执行，并且使用 Opus 4.5/4.6，它几乎每次都能保持在正轨上。

但他预测计划模式的日子屈指可数了。Claude Code 现在可以自行进入计划模式，并且团队正在努力使自动进入的感觉与人类完成时一样好。轨迹是：六个月前，你必须在计划之前和之后进行照看。现在，你只需要在计划之前进行照看。接下来，你根本不需要照看。

“No more need for plan mode in a month.” 一个月内不再需要计划模式。

这是相同的指数追踪。每一代模型都会吸收过去需要产品支架的东西。

超级专家 vs. 超级通才

当 Boris 观察 Claude Code 团队中最有效的工程师时，分布是双峰的：

超级专家：像 Jared Sumar（他发起了一场消除内存泄漏的运动）和 Bun 团队这样的人，他们对 JavaScript 运行时系统和开发工具的理解比任何人都深入。

超级通才：跨越产品和工程、或产品和设计、或产品和用户研究、或产品和业务的工程师。Boris 特别寻找那些“做奇怪的事情”的人，这曾经是一个警告信号（“他们能构建有用的东西吗？”），但现在是最强的信号。

示例：一位名叫 Daisy 的工程师在为 Claude Code 提交 PR 后转到了团队。她没有仅仅添加一个功能，而是首先构建了一个工具，让 Claude Code 可以测试任意工具并验证其是否有效，然后让 Claude 编写自己的工具，而不是自己实现它。Boris 招聘的就是这种横向思维。

他的面试技巧：问“你犯错的例子是什么？” 他正在寻找那些可以事后认识到错误、承认错误并阐明他们学到的东西的人。他估计他自己的一半想法都是不好的。

代理与代理（和人类）对话

Claude Code 团队广泛使用 Claude 代理进行编码以外的自动化。代理自动化代码审查、安全审查、问题标记和引导事物投入生产。

一个揭示性的轶事：当 Boris 要求 Claude 构建某些东西时，它会查看代码库，通过 git blame 找到哪个工程师接触了相关代码，然后在 Slack 上向该工程师发送消息，提出澄清问题。当它得到答案时，它会继续。

插件功能完全是由一群代理在一个周末构建的。一位工程师给了 Claude 一个规范，并告诉它使用 Asana 板。Claude 在 Asana 上创建了工单，生成了子代理，这些代理独立地承担了任务。插件在很大程度上以集群生成的形式发布。

Boris 透露，今天运行的大多数 Claude 代理可能都是由 Claude 本身提示的，以子代理的形式。子代理只是一个递归的 Claude Code 实例，由团队称之为“妈妈 Claude”的东西提示。

1000 倍的生产力声明

Steve Yegge 发布说，Anthropic 的工程师目前的平均生产力是谷歌工程师在谷歌巅峰时期的 1000 倍。Boris 将此置于上下文中：自 Claude Code 发布以来，Anthropic 的每位工程师的生产力提高了 150%，以拉取请求衡量（与提交和提交生命周期进行交叉检查）。团队规模翻了一番，但每位工程师的生产力增长了 70%。

从角度来看：在 Boris 之前在 Meta 的职位上，他负责 Facebook、Instagram 和 WhatsApp 的代码质量，2% 的生产力提升代表数百人一年的工作。

Boris 个人每天提交大约 20 个 PR，自 Opus 4.5 以来，他的 100% 代码都是由 Claude Code 编写的。他卸载了他的 IDE。在 Anthropic，AI 编写的代码范围从 70-90% 不等，具体取决于团队，许多个人的比例为 100%。

协同工作：面向所有人的 Claude Code

协同工作（桌面应用程序中面向非技术用户的 Claude Code）也是纯粹的潜在需求。在内部，每位设计师、整个财务团队和整个数据科学团队都克服了重重困难来安装终端工具，以便他们可以将 Claude Code 用于非编码任务。在外部，人们使用它来监控番茄植物、从损坏的硬盘驱动器中恢复婚礼照片以及管理财务。

Felix，一位早期的 Electron 贡献者，和他的团队在大约 10 天内构建了协同工作，100% 由 Claude Code 编写。在底层，它是同一个代理。面向非技术用户的关键区别在于：代码在虚拟机中运行，有删除保护，以及更多的权限提示和保护措施。

为什么是 Anthropic，为什么是现在

当 AI 开始主导头条新闻时，Boris 住在日本农村，每天早上阅读 Hacker News。他尝试了早期的产品，作为一名构建者，这种感觉让他惊叹不已。这是 Claude 2 时代。

有两件事赢得了他对 Anthropic 的青睐：首先，它作为一个研究实验室运作，产品的地位低于构建安全模型。在多年的产品构建之后，接近模型的开发，而不是产品是最重要的，这引起了他的共鸣。其次，是使命。作为一名狂热的科幻小说读者，他知道事情会变得多么糟糕。在 Anthropic，午餐室里听到的谈话都是关于 AI 安全的。

“If you think back six months ago and what predictions people were making… Dario predicted that 90% of the code at Anthropic would be written by Claude. This is true.” 如果你回想六个月前人们所做的预测……Dario 预测 Anthropic 90% 的代码将由 Claude 编写。这是真的。

一些观察

这次对话是意外产品开发的大师班。有几个值得思考的线索：

• 终端悖论：Boris 认为 CLI 是一个临时的起点。一年后，它仍然是主要的界面，并且他对它的寿命的每一次预测都是错误的。教训不是关于终端的；而是关于最简单的界面通常比任何人预期的都更持久。

• 潜在需求作为一种产品理念：不是“用户应该做什么？”，而是“用户已经在尝试做什么？” 每个主要的 Claude Code 功能（CLAUDE.md、计划模式、详细模式、协同工作）都是在构建之前在用户行为中观察到的。没有任何功能来自产品路线图。

• 支架陷阱：你围绕 AI 模型编写的任何产品代码都是临时的。在知道你会删除它的情况下构建它。Claude Code 团队每隔几个月就会重写所有内容，并且该团队实际上将“痛苦的教训”装裱在他们的墙上作为提醒。

• 双峰团队结构：在 AI 增强的世界中，最有效的人要么是深厚的领域专家，要么是做奇怪事情的广泛通才。“具有强烈意见的可靠的通才工程师”的中间地带可能正在失去其溢价。

• 指数是产品路线图：Anthropic 的三位创始人共同撰写了缩放定律论文。整个 Claude Code 策略只是追踪指数的走向，为尚不存在的模型构建，并愿意在新模型使其过时时删除所有内容。