Claude Code有多牛，应该不需要再多加介绍。

AI编程绕不开的一座大山，Anthropic最坚实的产品堡垒，Claude模型最能发挥特长的地方。

2025年2月，Claude Code第一次亮相。它最早是一个跑在终端里的AI编程工具，可以自己读代码、改文件、运行命令，再根据结果继续修改。

2025年5月，Claude Code正式开放使用，并开始进入工程师更熟悉的开发流程：可以接入代码编辑器，也可以在GitHub里处理任务、查看修改。

2025年下半年：Claude Code从“终端里的代码代理”继续长大，开始强调更自主的工作流、更长任务、更好的回退与控制能力，并逐渐嵌入团队的软件工程流程。

2026年，Claude Code长成了Anthropic最重要的AIAgent样板之一，成为A社用来证明“AI可以进入真实工作现场”的核心产品。

只是，光看时间线和产品更新，未免有些无趣。

7月7日，Claude官方整理了一份关于Claude Code的历史故事，来自它的创造者，也来自那些早期把它用起来、推着它长大的人。

这份历史最有意思的地方，在于它还原了一个产品被建成的过程：一个早期内部工具，怎样被少数工程师反复使用、改造、吐槽、修复；又怎样在模型能力跨过门槛之后，突然变成Anthropic最重要的agent样板之一。

有人说，它像一部情景喜剧的试播集；也有人说，它像一部关于科技起源的故事。

让我们一起走进这个故事，看看这个软件工程师们耳熟能详、爱不释手的Claude Code，究竟是怎么建成的？

Anthropic很早就盯上了代码

故事要从2021年讲起。

那一年，Claude Code还不存在。

没有那个全大写的字符标志，没有后来被开发者反复截图的红绿代码行，也没有“让Claude自己进代码库干活”这种听上去已经很自然的产品形态。

那时候，Anthropic才刚刚起步，达里奥·阿莫迪（Dario Amodei）从OpenAI“愤然离席”，要做一个更谨慎、更安全的AI公司。

而代码，很早就被放在了一个非常重要的位置上。

2021年，Dawn Drain加入后，花了很长一段时间让Claude学会写代码。

她后来回忆，自己在Anthropic前三年的主要项目，就是尽可能做出一个会写代码的模型——目标很直接：至少要写得和她一样好。

目标听起来很轻巧，真正做起来却并不容易。

他们先从最简单的任务开始，让模型写一个小函数，然后自己测试它对不对。

很多时候，模型写出来的东西都很糟糕。函数不对，测试也过不了，研究员们就继续拆任务、改训练、看失败样本，再把模型往前推一点点。

到2022年，Anthropic已经开始认真琢磨编程助手了。

Anthropic联合创始人Ben Mann回忆，当他们决定开始做产品时，第一个做出来的东西是个编程助手。那时它还只是一个VS Code插件，用户可以和它聊天，它会针对一个问题给出几种不同的建议。

它像一个坐在编辑器旁边的助手：你问它，它回答；你给它一段代码，它给你几个可能的改法。

在那时，它还不会自己钻进代码库里翻文件，也不会打开命令行跑测试。

但Anthropic的研究团队想让模型“动起来”。光会写一段代码不够，它还得知道代码能不能运行。光能回答问题也不够，它要能自己搜索、自己调用工具、自己在一个环境里执行命令。

于是，工程问题一个接一个地冒了出来。

Dawn和负责强化学习的同事们当时做了一个很关键的事情：在容器里给模型接上一个持续存在的命令行环境。这样，模型不再只是写一段代码交卷，它能真的执行代码，看见输出，遇到超时也能被处理掉。

到2023年，事情开始变得更具体。

Anthropic的研究团队已经不满足于让模型写一个函数、跑一个测试。他们开始往更开放的方向尝试。

Shauna的团队那时进展很快，他们开始给模型接上bash工具，让它能在命令行里执行操作；也开始让模型拥有搜索能力，可以自己在文件和信息里翻找。

这些东西现在听起来似乎很基础，但最基础的东西才最关键——对一个会写代码的模型来说，它们简直就像手和脚。

那时，Dawn Drain还在和一个很具体的问题较劲：模型到底该怎么“改代码”。

让模型生成一段新代码，和让模型在一个已有项目里动手修改，是两回事。已有项目里，代码不是一张白纸，你不能让模型每次都重写整个文件，也不能让它只在聊天框里说“建议你把这里改一下”。它得准确告诉系统：哪几行删掉，哪几行加上，改动应该落在哪里。

最自然的办法，是让Claude学会写diff。

开发者每天都在看diff，红色是删掉的，绿色是加上的，到底动了哪里，看diff一眼就能看出来。

但轮到模型来写，事情就没那么顺利了。

Dawn后来开玩笑说，她花了“令人尴尬地久”的时间教Claude写diff。它要写得像人类开发者能读懂的修改记录，还要能真的被系统应用到文件里。

然后，他们开发出了一个叫clide的命令行工具。

Shauna评价到：clide虽然有些笨拙，但它非常、非常超前。

想让clide正常工作，需要输入一堆像咒语一样的命令。

但奇怪的是，很多人都记住了它，因为它虽然难用，却有一种神奇的感觉（或许，就像是巫师施咒需要念咒语一样）。

Dawn曾经在编程时掏出clide，用它去回答一个关于整个文件夹的问题。正常情况下，这种问题根本塞不进模型的上下文窗口，但clide会把任务派出去，并行叫上一百个Claude Haiku去看，再把结果收回来。

旁边的人看见了，总会问她：嘿，你怎么知道这些酷工具的？

Adam Wolff也在clide上加过一个早期代理功能。那时候clide还没有bash工具，能力有限，但它已经可以从一个不完整的改动里推测你想做什么。

第一次跑通的时候，Adam在厨房里高兴得跳了起来。

clide最迷人的地方就在于此——它远远谈不上成熟，启动很慢，操作繁琐，能力也有限。可只要有那么一两次，它真的帮你把事情做成了，你就会很难忘掉那种感觉。

Boris谈起第一次被clide击中的经历，他说，当时他手写了一个完整的拉取请求，结果Adam说：你应该用clide来做这个。

于是Boris把issue复制进去，让clide处理。那只是一个五到十行的小改动，但clide直接写出了完整的请求。

Boris感叹到：我以前从没见过这样的工具，这真是令人惊叹，简直像是未来的科技。

clide像一块还没打磨好的原石，它太笨重、太慢、也太像内部玩具。可是它已经把一个可能性摆到了Anthropic面前：

如果一个难用的命令行工具都能让工程师感到震撼，那么，一个真正好用的版本会是什么样？

2024年1月，Ben Mann开始组建Labs团队。他看到市场上有一个空位：真正能干活的AI编程代理还没有出现。

同年9月，Boris加入Labs，被分配到了相关的工作。

刚开始，Boris想做一个代码检查工具，他想先从AI编程代理里切下一小块，做点小而具体的事情。

而Ben的反应很坚决：别做小的，要干，就干一票大的。

于是，Claude Code的车轮开始向前。

Boris后来回忆，他当时第一个反应是先学会怎么用Anthropic的API。因为那之前，他自己也还没怎么用过。

于是他开始乱试，打开API，写一点，跑一点，看看模型到底能做什么。

折腾了一阵后，他做出了一个名叫Claude CLI的demo。

连Boris自己也说，没人真正理解这个demo是什么——就连他自己也没有完全理解。

这个demo很奇怪，它已经有了后来Claude Code的一些影子，但当时看起来又不像一个清楚的编程产品。

Boris曾经让它去判断自己正在听什么音乐。Claude CLI没有让他手动输入歌名，也没有调用一个规整的音乐接口，而是直接截了一张Apple Music的屏幕图，然后自己读出来。

Boris说，这个demo大概花了两天做出来。如果放到今天，用Claude Code重做，可能两分钟就够了。

他把demo发到了公司的Slack，反应不算好，大概只有两三个赞。

但就在第二天，Boris在办公室里看到了另一个场景。

他走进办公室，忽然看到他的同事Robert Boyce正在用Claude CLI干活。

屏幕上出现了红色和绿色的代码改动，那种后来会变得很有辨识度的修改痕迹。Boris一眼就认了出来。

Robert很自然地告诉他：对，它正在帮我写代码。

Robert当时做的可能是Claude桌面应用里的东西，那个应用还很简单，本质上就是一组工具定义、一个循环，再加上一个简单的交互界面。

这对Boris的刺激很大。

Claude CLI还远远谈不上好。它粗糙、不稳定，离一个真正能发布的产品很远。但Boris感到一种很强的紧迫感。他开始周末也做这件事。

朋友叫他出去玩，他也放不下。

他后来形容，那段时间脑子里一直有这个东西。他就是停不下来。而且这种紧迫感，到今天也没有消失。

Claude Code的诞生

那是2024年10月，Boris几乎把全部精力都扑到了这个工具上。每过一周，他都去找Labs团队的工程负责人Raphael Lee要人。

“Raph，给我工程师。”

他知道这个东西还很粗糙，但也知道它不能再只是一个内部demo了。它已经开始有用，已经有人在用它写代码。再往前一步，它可能会变成一个真正的产品。

Raphael后来回忆，Claude Code几乎吃掉了整个Anthropic Labs的资源。

尽管处在人才的饥渴状态，但团队并没有一下子膨胀起来，主要靠内部转岗，还有一些很慢、很谨慎的外部招聘。

这里有一个小分歧：Boris想把团队尽快做大。他需要人，需要速度，需要更多火力。Adam Wolff作为Claude Code团队的第一位经理，却对此持有相反态度。

Adam不想让团队太快变大。他觉得团队一旦扩张，流程、文化、产品判断都会变复杂。人多当然能多做功能，但也很容易开始过度设计，开始开很多会，开始为了协调而协调。

后来Boris回头看，也承认小团队反而帮了他们。

人少，没法铺很大的架构；资源紧，没法把每件事都做得很重；速度要快，就只能把产品做得更轻，也只能更多地依赖Claude。

Sid是Claude Code的第二位工程师。他2024年8月加入Labs，之前没有做过开发者工具，也没有做过编程工具。

Boris手里有这个很酷的命令行东西，他就跳了进去。

最早那段时间，也就Boris、Sid Bidasaria，再加上“a little bit”Ben Mann，在继续开发这个项目。

他们一边做Claude Code，一边用Claude coding（写代码）。

到2024年12月，项目终于拿到了绿灯。更多人从Labs和其他团队跳了进来，大概六七个人，开始最后一轮两周冲刺。

Sid后来回忆，很多今天还能看到的核心功能，就是那两周做出来的。比如问题反馈，比如登录流程。

那时候，他第一次觉得：这个东西真的要变成产品了。

他们的工作方式可以说是相当粗暴。代码库没有严格的拉取请求限制，也没有很重的评审流程。有人发现问题，他们就直接修。用户说哪里不好，他们就马上改。

Boris在早期做了两个特别重要的东西：自动更新和用户数据。这让Claude Code的迭代速度变得很夸张。

只要有人跑来抱怨：“这个地方不好用。”几分钟后，用户手里的版本就更新了。

Claude Code本身也帮他们跑得更快——它是一个命令行产品，不是复杂的网页应用。没有庞大的前端架构，也没有很多层页面和服务要协调。

简单，反而成了优势。

更大的优势是，他们正在做的东西，刚好能让他们自己变快。

一个bug来了，Claude Code可以帮忙定位；一个功能要改，Claude Code可以一起写；反馈一来，团队就马上试、马上修、马上推。

这像一个很早期的飞轮：产品越能用，团队改产品的速度越快；团队改得越快，用户越愿意继续反馈；反馈越多，产品越快变得可用。

Ben Mann后来总结出了这种做模型产品的感觉：你必须先做出一个现在只能成功二三成的东西；等下一代模型出来，它可能就能成功八成；再下一代模型出来，就可能到九成以上。

做这种产品需要很高的忍耐力。你会一遍遍做错，一遍遍看到它不够好，还要继续把那个未来版本先搭出来。

Ben Mann说：你必须活在当下，同时也要着眼于未来。

Claude Code当时就处在这种状态里。

然后，时间被拉到2025年2月——Claude Code正式对外发布了。

发布前，它先经历了一轮早期试用。反应并没有想象中热烈。

产品负责人Cat Wu后来回忆，那时很多人觉得这个想法很酷，但产品的bug很多。它还没有变成那种一打开就能让人立刻信服的东西。更多时候，它像一个有潜力的半成品：你能看出方向，但也能看见问题。

但团队还是决定先把它发出去。

也是在这次发布前后，Claude Code从Claude CLI改了名字。

这个名字来自产品营销团队的Alex Isken。团队喜欢它的简单直接，没有复杂概念，也不需要解释太多。

发布前的一个深夜，Igor Kofman又给它加了一个小细节：他突然想到，如果登录时能有一个字符画标志，会不会很酷？

于是他和Claude一起填了一些字符画字体，做出了后来很有辨识度的Claude Code全大写标志。那是一个很小的产品彩蛋，但对一个命令行工具来说，这种小东西会让它突然有了性格。

Meaghan Choi也加了一个她很喜欢的东西：终端里的小角色Clawd。

Clawd原本是为Claude 3.5 Sonnet发布做出来的，把它塞进Claude Code的终端里，多少有点“不务正业”，但也让这个冷冰冰的开发者工具多了一点可爱。

于是，Claude Code就这样出现在了外部用户面前。

征服用户之路

早期的Claude Code并不完美，离后来那个声势浩大的Claude Code还差得很远。

但有些人很快被它击中了。

Ramp的工程师Austin Ray就是其中一个。

他一直喜欢命令行，职业生涯里能待在终端就待在终端。Claude Code以研究预览版发布后，他看到有人提到这个工具，就去试了一下。

五分钟后，他感觉到：这东西会从根本上改变一切。

在Austin看来，只要一个工具能读、能编辑、能运行bash，它就已经拥有了搭建其他一切东西的基础能力。

于是他开始在Ramp内部到处安利。

他给同事发消息，问谁也在用Claude Code。后来干脆走到别人桌前，让他们装上Claude Code，打开终端，把手头正在做的事直接交给它试试。

这种早期用户对Claude Code非常重要。Austin后来和Boris、Cat每周都开反馈会，开发者和用户之间的关系，就这样自然而然地建立起来了。

Bun的创始人Jarred Sumner也很早试了Claude Code。

他让它给Bun实现websocket客户端压缩，还把相关标准文档喂给它。Claude Code一开始做得并不好，但在几轮提示和修正之后，它真的把东西做出来了。

这件事让Jarred对它上了头——他甚至改变了Bun的工作优先级，让项目变得更适合Claude Code使用。

后来Bun内部有人讨论要不要禁用Claude Code，Jarred第一个不同意。

早期的Claude Code可以说是非常分裂：有人觉得它bug多，还不够稳定；有人试了几分钟，就开始到处拉同事安装；有人觉得它暂时帮不上自己；也有人已经开始改变团队的工作方式来适配它。

有趣的是，Anthropic内部也有类似的分裂。

Tristan Hume做的是性能工程，任务需要大量上下文，还涉及一些外部网上没有公开文档的加速器内核。对他来说，早期Claude Code还不够好。它不会很好地写自己的工具，也不太会边调查边学习，所以只能处理很有限的任务。

2025年2月的Claude Code并没有一下子征服所有人。

它让一部分开发者震惊，也让另一部分开发者觉得不够用。

但Claude 4让一切都变得不一样了。

用AI圈常见的黑话来讲，那应该能算Claude Code的“ChatGPT时刻”——当然，Anthropic肯定不会愿意被这么形容。

要知道，在模型真正好用之前，产品设计能做的事情其实相对有限。Claude 4模型更会写代码，更会处理任务，也更像一个能自己往前推进的agent。

Boris后来总结，Claude Code起飞主要就靠两件事：模型创新，加上商业模式创新。

模型让产品的功能变得成立，订阅模式推出后，用户也终于可以更自然、更高频地使用它。

到这时，Claude Code开始变成了一个真的能被开发者每天打开的工具。

也正是在这个阶段，很多人第一次意识到：Claude Code的作用，可能已经不只是提高写代码速度。

它正在改变工程师和代码之间的距离。

Claude 4之后，Boris对Claude Code的使用开始迅速变化：2025年2月，Claude Code 大概只写他10%的代码；到5月，这个比例变成了30%、40%。

他记得很清楚，那时他正在Code with Claude开发者大会。Sonnet 4发布，他坐在后台房间里，一边开会，一边写代码。写着写着他突然意识到，这个东西真的变好了。

模型变得更会写代码，也更会自己推进任务。

到了2025年冬天，Boris说，自己的代码已经全部由Claude Code完成。他不再亲手写任何一行代码。

Shauna Kravec的情况则反了过来：同为Claude Code的重度用户，她过去几年本来已经不怎么亲手写代码了，但Claude Code反而让她重新写得更多。

因为写代码这件事变得更容易了。

她不用重新钻进每一个细节里，从空白文件开始把东西一点点敲出来。她可以把任务拆开，让Claude先跑起来，再看结果、调整方向、继续往下推。

她说自己有十二个不同的Claude在四处工作：有的读文档，有的更新东西，有的从Slack里拉信息。

而Igor Kofman看到了另一个变化：

当模型和Claude Code继续变强，人管理的东西会继续往上抽象一层。现在你可能还在管理一堆Claude。再往后，你管理的可能是“管理Claude的那个Claude”。

听起来像绕口令，但刚好对应了后来Claude Code继续演化出的两个方向：一是子代理，让不同Claude 分头处理不同任务；二是Skills甚至Loop Engineering，让人不再一步步提示AI，而是设计一套目标、检查和停止规则，让AI自己反复推进。

说白了，人写得越来越少，安排得越来越多。

Tristan Hume的感受要更复杂——在前面说，早期Claude Code对他用处有限。但后来，他看见同事们从Claude Code那里获得了巨大的杠杆。

Tristan意识到，如果想获得最高的生产力，写代码的方式已经变了。

问题是，要跟上这种变化，有时还得先付出一段适应成本。他甚至需要先花一周时间，把自己的开发环境重新搭好，才能让Claude Code更好地进入他的工作。

Cat Wu观察到，Claude Code刚发布时，用户会认真阅读它提出的每一个权限请求。它要读什么文件，要改什么东西，要执行什么命令，用户都会一条一条看。

但后来，越来越多用户开始直接自动接受。

Cat Wu认为这说明Claude Code开始赢得用户的信任。用户不再把它当成一个随时可能闯祸的外来者，而是把它当成一个已经熟悉项目、可以先放手去做的工作伙伴。

不过我觉得造成这种情况的主要原因是，Claude Code增加了回退机制。

至少用户开始相信，就算它改错了我也能回退，不至于把事情搞到不可收拾。