文章作者、来源：0x9999in1，ME News



TL;DR

• Claude Code 不是规划出来的产品。它起点是一个工程师为了学 API、几天写出来的终端小玩具，第一个"魔法时刻"是它自己写 AppleScript 去读音乐播放器，告诉主人正在听什么歌。
• 真正让它起飞的不是产品设计，是模型。Sonnet 3.5 时代它只能算花哨自动补全，Sonnet 4 一上来，玩具直接变成生产力工具。
• 它的传播路径很诚实：内部发布首日约 20% 工程师用，五天内半数工程师用。没有营销，就是好用。
• 2025 年 12 月，负责人 Boris Cherny 公开说过去 30 天他 100% 的代码贡献都由 Claude Code 写。到 2026 年，他已经六个多月没手写一行代码。
• 2026 年 6 月 Anthropic 官方数据：合并进生产环境的代码里，80% 以上出自 Claude。有些产品线接近 100%。
• 结论没那么科幻，也没那么轻松。"编码被解决了"是有前提的一句话，前提是"我做的那种编码"。真正难的部分——判断、品味、跟人打交道——还在人手里。

先说结论：这不是一个天才产品经理的胜利

我想把最想说的一句话放最前面。

Claude Code 的故事，最容易被讲成一个英雄叙事。天才工程师加入前沿实验室，灵光一闪，改变行业。听着爽，但不真。

真相更朴素，也更有意思：它是一个几乎没人看好的小实验，靠着一件事活了下来——它真的有用。

Boris Cherny 2024 年 9 月加入 Anthropic。他不是被派去做编程产品的。没人给他这个任务。他进的是一个叫 Labs 的小团队，团队小到什么程度？他做了 Claude Code，另一个人做了 MCP，一个人做 Skills，两个人做桌面端。就这么点人，几个月里堆出一堆"怪点子",没人知道哪个能成。

他自己想干嘛？想熟悉一下公司的 API。仅此而已。

于是他做了"能做出来的最便宜的东西"——一个跑在终端里的小程序。为什么选终端？因为不用做界面，不用做 App，几天就能出活。

你看，起点没有宏图,只有一个想偷懒又想学东西的工程师。这才是它值得复盘的地方。

那个"听歌"的时刻，到底神在哪被反复讲的那个桥段，是 Claude 告诉 Boris 他正在听什么歌。

听起来像个无聊的派对把戏。但你得站在 2024 年底那个时间点去看它。

当时的模型是 Sonnet 3.5。市面上所有编程产品是什么样？全是 IDE 或者 IDE 插件。为什么？因为模型能力就那样，最多做个花哨的自动补全——你写半行，它补全后半行。仅此而已。

Boris 问 Claude：我在听什么歌？

Claude 没有回答"我不知道"。它写了一段 AppleScript，去打开音乐播放器，读界面，然后告诉他答案。

关键在哪？AppleScript 这门语言，Boris 自己都不会写。而且作为一个工程师，他根本不会想到"用写代码的方式"去回答一个听歌的问题。

但 Claude 想到了。它用一种人类工程师不会选的路径，把问题解决了。

这就是那个信号。不是"模型会聊天了",而是"模型会自己动手,用我想不到的方式动手"。Boris 把这段演示录了视频,发在 Slack 里,只收到两个表情回应。没人看懂这意味着什么。

后来这段视频被捐给了一家计算机博物馆。一个被两个表情打发掉的下午,成了历史文物。你说讽刺不讽刺?

Boris 自己有个说法,我觉得特别准:产品悬垂(product overhang)。意思是,模型早就能做某件事了,只是没有哪个产品让它去做。他说直到今天,这种感觉都没变——模型能做的事,远比现在的产品让它做的多。

它是怎么在公司里"病毒式"蔓延的产品好不好,别看发布会,看留存。

Claude Code 内部发布那天,大约 20% 的 Anthropic 工程师开始用它。注意,这是第一天。五天之内,半数工程团队在用。

没有推广。没有 KPI 摊派。传播路径像剥洋葱:先是坐在 Boris 旁边那几个人,然后是外面一圈,几周后大半个公司每天都在用。

这里有个特别反直觉的点。终端,是最"工程师"的东西,很多工程师其实碰都不想碰。一个跑在终端里的丑陋原型,按理说应该劝退大多数人。

但他们用了。而且天天用。

为什么?因为它省事。因为它真能干活。一个东西如果好用到让人愿意忍受它的丑,那它大概率是对的。

这段时间 Boris 是什么状态?每个晚上、每个周末都扑在上面。他开始做关于 Claude Code 的梦。他说到现在还是只梦这个:下一步做什么,接下来建什么。

一个人被一个想法彻底占据的样子,大概就是这样。

转折点不是产品,是 Claude 4我必须把这句话说清楚,因为它最容易被忽略。

让 Claude Code 从玩具变成武器的,不是某次产品迭代,是模型本身的跃迁。

Sonnet 3.5 时代,它是个有趣的小东西。Claude 4 (Sonnet 4)一上来,一切都变了。原本像玩具的工具,突然爆发出惊人的迭代速度。

这里有个架构上的巧思值得说。因为它是命令行工具,极度轻量,不用维护复杂的网页端,团队几分钟就能完成一次热更新。模型能力涨一截,产品马上就能跟上一截。模型和产品之间几乎没有延迟。

2025 年 2 月,它公开测试,正式定名 Claude Code。

然后它成了——按多数口径——全球增长最快的 AI 编程工具。

我想在这儿下个判断:**Claude Code 最大的护城河从来不是产品形态,是它离模型足够近。**它跑在 Anthropic 自己的模型上,模型每进步一步,它第一个吃到红利。别的工具要等 API、要适配,它不用。这种贴身距离,别人很难复制。

"100% 代码由 Claude 写",这话到底该怎么理解2025 年 12 月,Boris 发了一条帖子:过去三十天,他对 Claude Code 的贡献里,100% 由 Claude Code 写成。

到 2026 年,他已经六个多月没手写过一行代码。用户提供的素材里还有个画面:他和家人在沙发上闲坐,靠对话指挥,让 Claude Code 一天内自动提交了几十个 commit。他和核心成员 Igor Kofman 都实现了代码 100% 交给 Claude 写。

这话很容易被拿去做惊悚标题。所以我想替他把上下文补全,因为他自己也强调过——这句话老被断章取义。

完整版是:"编码被解决了"针对的是我做的那种编码。

Boris 做的是什么?Claude CLI 是个挺新的代码库,桌面和移动 App 也是小而简单的代码库。这类活,模型确实能包圆。

但他紧接着说:公司现在有大量企业客户,其中不乏最大的那些企业。NASA 就是客户之一。他们的代码库又大又复杂,对他们来说,编码远没被解决,模型还会犯错,写出来的代码不总是完美。

所以那个刷屏的"coding is solved",真实含义是:对特定类型、特定复杂度的代码,解决了;对整个软件工程,远没有。

这个区别,决定了你该兴奋还是该焦虑。

官方数据:80%,不是 100%2026 年 6 月,Anthropic 发布报告,给了一个更冷静的数字。

合并进生产环境的代码里,80% 以上由 Claude 写成。而在 Claude Code 2025 年 2 月发布之前,这个比例还是个位数低位。十五个月左右,从个位数到八成。

为什么官方说 80%,而领导层的说法有时是 90% 甚至 100%?

因为口径不同。如果把脚本、实验性代码都算进去,比例更高;但"合并进生产、且确认由 Claude 署名"的这个保守口径,是 80%。有些产品线——比如 Claude Code 自己、Cowork——确实接近或达到 100%。

我更信 80% 这个数。不是因为它更小,是因为它更诚实。它区分了"玩票的代码"和"真正扛生产的代码"。一个能扛住生产的 80%,比一个什么都算的 100% 有说服力得多。

Anthropic 自己也划了条线:这还不算"递归自我改进"。它谨慎地不去碰那个更吓人的词。这种克制,反而比大喊大叫可信。

那"软件工程师"这个词,真要消失吗Boris 有个大胆预测:"software engineer"这个头衔,可能今年就开始淡出,慢慢变成类似"builder"(构建者)的东西。

证据是他身边活生生的例子。他们的主管 Fiona,15 年没写过代码,加入 Claude Code 后开始写了。产品经理 Kat 在写代码。设计师 Megan 也在写。团队里人人都在写代码——你不再必须是工程师才能写代码。

顺着这个趋势推:不是工程师的人,会写更多代码;像 Boris 这样的工程师,会写更少代码。所有角色,正在融合成一件事。叫它 builder,叫它工程师,叫它产品经理,都行,反正角色变了。

但这里我要泼一点冷水,而且 Boris 自己也泼了。

他被问到"工程师担心手艺荒废"时,承认这个批评"完全对"。编码从来不只是打字。判断、品味、批判性思维,agent 在这些上面还很糟。他自己也说过,当年他一天可能只有 50% 时间在真正敲代码,另外 50% 是跟用户聊、头脑风暴、调试、想清楚一件事怎么运作、做规划。

所以当敲代码这部分被模型接管,人被释放去做的,恰恰是那些"更像人"的部分。

这不是"人被取代",是"人被重新分配"。至少现在这个阶段是。

就业:他既悲观又乐观,而且不装懂关于最尖锐的问题——会不会大规模失业——Boris 的回答我很欣赏,因为他老实。

他说,趋势是指数级的,而人类特别不擅长用指数思考。任何说自己知道答案的人,都是在猜;有些是基于观察和历史的"受过教育的猜测"。

他给了个特别克制的双向判断。一方面,很多公司会需要更少的工程师,因为每个人产能更高,同样的活不需要那么多人。另一方面,很多公司会需要多得多的工程师,因为每个人产能更高,公司能做的事更多,能开更多产品、更多业务线。他甚至预测:如果算上所有"用 agent 写代码"的人,未来的"工程师"数量可能是今天的 100 倍。

他讲了个拖拉机的故事。拖拉机 1890 年代就发明了,但直到 1960 年代,美国的拖拉机数量才超过马。花了大约 70 年。为什么这么慢?技术是神奇的,可农民得培训,早期拖拉机贵,很多时候养马还更便宜,而且拖拉机一开始也不好用——能收麦子不能收玉米,得慢慢改。

他说,我们现在看到的是同一件事的加速版——但那些老问题,一个没少。

还有洗衣机的故事。以前洗一次衣服要五六个小时,要走上千英尺去打水,烧水、搓洗、拧干,一家人的衣服天天洗。洗衣机省下每天大约三小时。这多出来的时间,有人陪孩子,有人遛狗,有人读书,但很多人的答案是:我准备好去工作了。技术给的不是"少干活",是"多一个选择"。

这套历史类比里藏着他真正的立场:**技术带来的从来不是"你可以少干",而是"你会干更多"。**因为能做的事变多了,你就把更多事塞进同样的时间里。他自己就是活例子——生产力暴涨,工作量一点没减。

他还提到 Solow 悖论:1980 年代经济学家发现,"计算机时代随处可见,唯独不见于生产率统计"。计算机铺得到处都是,人却没变得更能干。直到企业围绕新技术重构了工作流程,收益才姗姗来迟。1990 年那篇著名的《哈佛商业评论》文章说得更狠:真正提效的公司,是把纸、文件柜、笔全扔了,让计算机成为一切的中心;而把计算机摆在角落只干一件事的公司,没提上去。

Anthropic 现在就是把 Claude 摆在中心。新人有代码问题,问 Claude;报销怎么弄,问 Claude;下个假期什么时候,问 Claude。Boris 的判断是:真正吃到红利的公司,是把 Claude 放正中间的那些,不是摆在边上的。而重构所有业务流程,需要时间。

收尾判断复盘完这一整段,脑子里剩下的不是"AI 好猛",而是几个更冷的念头。

第一,Claude Code 证明了一件反直觉的事:最好的 AI 产品,可能是模型能力"溢出"时自然长出来的,而不是精心规划出来的。Boris 那个"产品悬垂"的说法,是这整个故事的钥匙。模型早就能做,只差有人做个入口。

第二,别被"100% 由 AI 写代码"唬住。这句话有严格前提——简单代码库、清晰任务、还有一个懂行的人在旁边判断对错。NASA 那种又大又复杂的系统,仍然是没被解决的硬骨头。"解决了"和"我做的那种解决了",中间隔着整个真实世界。

第三,焦虑的方向可能错了。真要担心,担心的不该是"AI 会不会写代码",而是"当写代码不再是稀缺技能,我剩下的价值是什么"。判断、品味、跟人打交道、想清楚该做什么——这些 Boris 反复强调 agent 还很糟的东西,恰恰是接下来最值钱的东西。

一个几天写出来的终端玩具,先是让主人知道自己在听什么歌,后来让主人再也不用亲手写代码。

它没有终点。Boris 自己在发布这段往事时说了句话:还有太多要做,我们才完成了 1%。

玩具会长大。问题是,你打算长成给它打下手的人,还是指挥它的人?

• 参考来源The Making of Claude Code, Anthropic, 2026
• How Claude Code is built, Gergely Orosz, The Pragmatic Engineer Newsletter, 2025-10-01
• Claude Code's creator on the end of the software engineer, Casey Newton, Platformer, 2026-05-27
• The head of Claude Code hasn't 'written a line of code by hand' anymore, Fortune, 2026-06-11
• Source Code for Anthropic's Claude Code Leaks at the Exact Wrong Time, Gizmodo, 2026
• Head of Claude Code: What happens after coding is solved (Boris Cherny), Lenny's Newsletter, 2026-04-13
• Building Claude Code (Boris Cherny), Y Combinator Lightcone Podcast, 2026-02-17
• Reengineering Work: Don't Automate, Obliterate, Harvard Business Review, 1990-07