Related articles
文 | 字母 AI
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 增加了回退机制。
至少用户开始相信，就算它改错了我也能回退，不至于把事情搞到不可收拾。
