親歷者講述：Claude Code是怎樣煉成的？

Claude Code有多牛，應(yīng)該不需要再多加介紹。

AI編程繞不開的一座大山，Anthropic最堅實的產(chǎn)品堡壘，Claude模型最能發(fā)揮特長的地方。

2025年2月，Claude Code第一次亮相。它最早是一個跑在終端里的AI編程工具，可以自己讀代碼、改文件、運行命令，再根據(jù)結(jié)果繼續(xù)修改。

2025年5月，Claude Code正式開放使用，并開始進入工程師更熟悉的開發(fā)流程：可以接入代碼編輯器，也可以在GitHub里處理任務(wù)、查看修改。

2025年下半年：Claude Code從“終端里的代碼代理”繼續(xù)長大，開始強調(diào)更自主的工作流、更長任務(wù)、更好的回退與控制能力，并逐漸嵌入團隊的軟件工程流程。

2026年，Claude Code長成了Anthropic最重要的AIAgent樣板之一，成為A社用來證明“AI可以進入真實工作現(xiàn)場”的核心產(chǎn)品。

只是，光看時間線和產(chǎn)品更新，未免有些無趣。

7月7日，Claude官方整理了一份關(guān)于Claude Code的歷史故事，來自它的創(chuàng)造者，也來自那些早期把它用起來、推著它長大的人。

這份歷史最有意思的地方，在于它還原了一個產(chǎn)品被建成的過程：一個早期內(nèi)部工具，怎樣被少數(shù)工程師反復(fù)使用、改造、吐槽、修復(fù)；又怎樣在模型能力跨過門檻之后，突然變成Anthropic最重要的agent樣板之一。

有人說，它像一部情景喜劇的試播集；也有人說，它像一部關(guān)于科技起源的故事。

讓我們一起走進這個故事，看看這個軟件工程師們耳熟能詳、愛不釋手的Claude Code，究竟是怎么建成的？

01

Anthropic很早就盯上了代碼

故事要從2021年講起。

那一年，Claude Code還不存在。

沒有那個全大寫的字符標志，沒有后來被開發(fā)者反復(fù)截圖的紅綠代碼行，也沒有“讓Claude自己進代碼庫干活”這種聽上去已經(jīng)很自然的產(chǎn)品形態(tài)。

那時候，Anthropic才剛剛起步，達里奧·阿莫迪（Dario Amodei）從OpenAI“憤然離席”，要做一個更謹慎、更安全的AI公司。

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

2021年，Dawn Drain加入后，花了很長一段時間讓Claude學會寫代碼。

她后來回憶，自己在Anthropic前三年的主要項目，就是盡可能做出一個會寫代碼的模型——目標很直接：至少要寫得和她一樣好。

目標聽起來很輕巧，真正做起來卻并不容易。

他們先從最簡單的任務(wù)開始，讓模型寫一個小函數(shù)，然后自己測試它對不對。

很多時候，模型寫出來的東西都很糟糕。函數(shù)不對，測試也過不了，研究員們就繼續(xù)拆任務(wù)、改訓練、看失敗樣本，再把模型往前推一點點。

到2022年，Anthropic已經(jīng)開始認真琢磨編程助手了。

Anthropic聯(lián)合創(chuàng)始人Ben Mann回憶，當他們決定開始做產(chǎn)品時，第一個做出來的東西是個編程助手。那時它還只是一個VS Code插件，用戶可以和它聊天，它會針對一個問題給出幾種不同的建議。

它像一個坐在編輯器旁邊的助手：你問它，它回答；你給它一段代碼，它給你幾個可能的改法。

在那時，它還不會自己鉆進代碼庫里翻文件，也不會打開命令行跑測試。

但Anthropic的研究團隊想讓模型“動起來”。光會寫一段代碼不夠，它還得知道代碼能不能運行。光能回答問題也不夠，它要能自己搜索、自己調(diào)用工具、自己在一個環(huán)境里執(zhí)行命令。

于是，工程問題一個接一個地冒了出來。

Dawn和負責強化學習的同事們當時做了一個很關(guān)鍵的事情：在容器里給模型接上一個持續(xù)存在的命令行環(huán)境。這樣，模型不再只是寫一段代碼交卷，它能真的執(zhí)行代碼，看見輸出，遇到超時也能被處理掉。

到2023年，事情開始變得更具體。

Anthropic的研究團隊已經(jīng)不滿足于讓模型寫一個函數(shù)、跑一個測試。他們開始往更開放的方向嘗試。

Shauna的團隊那時進展很快，他們開始給模型接上bash工具，讓它能在命令行里執(zhí)行操作；也開始讓模型擁有搜索能力，可以自己在文件和信息里翻找。

這些東西現(xiàn)在聽起來似乎很基礎(chǔ)，但最基礎(chǔ)的東西才最關(guān)鍵——對一個會寫代碼的模型來說，它們簡直就像手和腳。

那時，Dawn Drain還在和一個很具體的問題較勁：模型到底該怎么“改代碼”。

讓模型生成一段新代碼，和讓模型在一個已有項目里動手修改，是兩回事。已有項目里，代碼不是一張白紙，你不能讓模型每次都重寫整個文件，也不能讓它只在聊天框里說“建議你把這里改一下”。它得準確告訴系統(tǒng)：哪幾行刪掉，哪幾行加上，改動應(yīng)該落在哪里。

最自然的辦法，是讓Claude學會寫diff。

開發(fā)者每天都在看diff，紅色是刪掉的，綠色是加上的，到底動了哪里，看diff一眼就能看出來。

但輪到模型來寫，事情就沒那么順利了。

Dawn后來開玩笑說，她花了“令人尷尬地久”的時間教Claude寫diff。它要寫得像人類開發(fā)者能讀懂的修改記錄，還要能真的被系統(tǒng)應(yīng)用到文件里。

然后，他們開發(fā)出了一個叫clide的命令行工具。

Shauna評價到：clide雖然有些笨拙，但它非常、非常超前。

想讓clide正常工作，需要輸入一堆像咒語一樣的命令。

但奇怪的是，很多人都記住了它，因為它雖然難用，卻有一種神奇的感覺（或許，就像是巫師施咒需要念咒語一樣）。

Dawn曾經(jīng)在編程時掏出clide，用它去回答一個關(guān)于整個文件夾的問題。正常情況下，這種問題根本塞不進模型的上下文窗口，但clide會把任務(wù)派出去，并行叫上一百個Claude Haiku去看，再把結(jié)果收回來。

旁邊的人看見了，總會問她：嘿，你怎么知道這些酷工具的？

Adam Wolff也在clide上加過一個早期代理功能。那時候clide還沒有bash工具，能力有限，但它已經(jīng)可以從一個不完整的改動里推測你想做什么。

第一次跑通的時候，Adam在廚房里高興得跳了起來。

clide最迷人的地方就在于此——它遠遠談不上成熟，啟動很慢，操作繁瑣，能力也有限。可只要有那么一兩次，它真的幫你把事情做成了，你就會很難忘掉那種感覺。

Boris談起第一次被clide擊中的經(jīng)歷，他說，當時他手寫了一個完整的拉取請求，結(jié)果Adam說：你應(yīng)該用clide來做這個。

于是Boris把issue復(fù)制進去，讓clide處理。那只是一個五到十行的小改動，但clide直接寫出了完整的請求。

Boris感嘆到：我以前從沒見過這樣的工具，這真是令人驚嘆，簡直像是未來的科技。

clide像一塊還沒打磨好的原石，它太笨重、太慢、也太像內(nèi)部玩具。可是它已經(jīng)把一個可能性擺到了Anthropic面前：

如果一個難用的命令行工具都能讓工程師感到震撼，那么，一個真正好用的版本會是什么樣？

2024年1月，Ben Mann開始組建Labs團隊。他看到市場上有一個空位：真正能干活的AI編程代理還沒有出現(xiàn)。

同年9月，Boris加入Labs，被分配到了相關(guān)的工作。

剛開始，Boris想做一個代碼檢查工具，他想先從AI編程代理里切下一小塊，做點小而具體的事情。

而Ben的反應(yīng)很堅決：別做小的，要干，就干一票大的。

于是，Claude Code的車輪開始向前。

Boris后來回憶，他當時第一個反應(yīng)是先學會怎么用Anthropic的API。因為那之前，他自己也還沒怎么用過。

于是他開始亂試，打開API，寫一點，跑一點，看看模型到底能做什么。

折騰了一陣后，他做出了一個名叫Claude CLI的demo。

連Boris自己也說，沒人真正理解這個demo是什么——就連他自己也沒有完全理解。

這個demo很奇怪，它已經(jīng)有了后來Claude Code的一些影子，但當時看起來又不像一個清楚的編程產(chǎn)品。

Boris曾經(jīng)讓它去判斷自己正在聽什么音樂。Claude CLI沒有讓他手動輸入歌名，也沒有調(diào)用一個規(guī)整的音樂接口，而是直接截了一張Apple Music的屏幕圖，然后自己讀出來。

Boris說，這個demo大概花了兩天做出來。如果放到今天，用Claude Code重做，可能兩分鐘就夠了。

他把demo發(fā)到了公司的Slack，反應(yīng)不算好，大概只有兩三個贊。

但就在第二天，Boris在辦公室里看到了另一個場景。

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

屏幕上出現(xiàn)了紅色和綠色的代碼改動，那種后來會變得很有辨識度的修改痕跡。Boris一眼就認了出來。

Robert很自然地告訴他：對，它正在幫我寫代碼。

Robert當時做的可能是Claude桌面應(yīng)用里的東西，那個應(yīng)用還很簡單，本質(zhì)上就是一組工具定義、一個循環(huán)，再加上一個簡單的交互界面。

這對Boris的刺激很大。

Claude CLI還遠遠談不上好。它粗糙、不穩(wěn)定，離一個真正能發(fā)布的產(chǎn)品很遠。但Boris感到一種很強的緊迫感。他開始周末也做這件事。

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

他后來形容，那段時間腦子里一直有這個東西。他就是停不下來。而且這種緊迫感，到今天也沒有消失。

02

Claude Code的誕生

那是2024年10月，Boris幾乎把全部精力都撲到了這個工具上。每過一周，他都去找Labs團隊的工程負責人Raphael Lee要人。

“Raph，給我工程師。”

他知道這個東西還很粗糙，但也知道它不能再只是一個內(nèi)部demo了。它已經(jīng)開始有用，已經(jīng)有人在用它寫代碼。再往前一步，它可能會變成一個真正的產(chǎn)品。

Raphael后來回憶，Claude Code幾乎吃掉了整個Anthropic Labs的資源。

盡管處在人才的饑渴狀態(tài)，但團隊并沒有一下子膨脹起來，主要靠內(nèi)部轉(zhuǎn)崗，還有一些很慢、很謹慎的外部招聘。

這里有一個小分歧：Boris想把團隊盡快做大。他需要人，需要速度，需要更多火力。Adam Wolff作為Claude Code團隊的第一位經(jīng)理，卻對此持有相反態(tài)度。

Adam不想讓團隊太快變大。他覺得團隊一旦擴張，流程、文化、產(chǎn)品判斷都會變復(fù)雜。人多當然能多做功能，但也很容易開始過度設(shè)計，開始開很多會，開始為了協(xié)調(diào)而協(xié)調(diào)。

后來Boris回頭看，也承認小團隊反而幫了他們。

人少，沒法鋪很大的架構(gòu)；資源緊，沒法把每件事都做得很重；速度要快，就只能把產(chǎn)品做得更輕，也只能更多地依賴Claude。

Sid是Claude Code的第二位工程師。他2024年8月加入Labs，之前沒有做過開發(fā)者工具，也沒有做過編程工具。

Boris手里有這個很酷的命令行東西，他就跳了進去。

最早那段時間，也就Boris、Sid Bidasaria，再加上“a little bit”Ben Mann，在繼續(xù)開發(fā)這個項目。

他們一邊做Claude Code，一邊用Claude coding（寫代碼）。

到2024年12月，項目終于拿到了綠燈。更多人從Labs和其他團隊跳了進來，大概六七個人，開始最后一輪兩周沖刺。

Sid后來回憶，很多今天還能看到的核心功能，就是那兩周做出來的。比如問題反饋，比如登錄流程。

那時候，他第一次覺得：這個東西真的要變成產(chǎn)品了。

他們的工作方式可以說是相當粗暴。代碼庫沒有嚴格的拉取請求限制，也沒有很重的評審流程。有人發(fā)現(xiàn)問題，他們就直接修。用戶說哪里不好，他們就馬上改。

Boris在早期做了兩個特別重要的東西：自動更新和用戶數(shù)據(jù)。這讓Claude Code的迭代速度變得很夸張。

只要有人跑來抱怨：“這個地方不好用。”幾分鐘后，用戶手里的版本就更新了。

Claude Code本身也幫他們跑得更快——它是一個命令行產(chǎn)品，不是復(fù)雜的網(wǎng)頁應(yīng)用。沒有龐大的前端架構(gòu)，也沒有很多層頁面和服務(wù)要協(xié)調(diào)。

簡單，反而成了優(yōu)勢。

更大的優(yōu)勢是，他們正在做的東西，剛好能讓他們自己變快。

一個bug來了，Claude Code可以幫忙定位；一個功能要改，Claude Code可以一起寫；反饋一來，團隊就馬上試、馬上修、馬上推。

這像一個很早期的飛輪：產(chǎn)品越能用，團隊改產(chǎn)品的速度越快；團隊改得越快，用戶越愿意繼續(xù)反饋；反饋越多，產(chǎn)品越快變得可用。

Ben Mann后來總結(jié)出了這種做模型產(chǎn)品的感覺：你必須先做出一個現(xiàn)在只能成功二三成的東西；等下一代模型出來，它可能就能成功八成；再下一代模型出來，就可能到九成以上。

做這種產(chǎn)品需要很高的忍耐力。你會一遍遍做錯，一遍遍看到它不夠好，還要繼續(xù)把那個未來版本先搭出來。

Ben Mann說：你必須活在當下，同時也要著眼于未來。

Claude Code當時就處在這種狀態(tài)里。

然后，時間被拉到2025年2月——Claude Code正式對外發(fā)布了。

發(fā)布前，它先經(jīng)歷了一輪早期試用。反應(yīng)并沒有想象中熱烈。

產(chǎn)品負責人Cat Wu后來回憶，那時很多人覺得這個想法很酷，但產(chǎn)品的bug很多。它還沒有變成那種一打開就能讓人立刻信服的東西。更多時候，它像一個有潛力的半成品：你能看出方向，但也能看見問題。

但團隊還是決定先把它發(fā)出去。

也是在這次發(fā)布前后，Claude Code從Claude CLI改了名字。

這個名字來自產(chǎn)品營銷團隊的Alex Isken。團隊喜歡它的簡單直接，沒有復(fù)雜概念，也不需要解釋太多。

發(fā)布前的一個深夜，Igor Kofman又給它加了一個小細節(jié)：他突然想到，如果登錄時能有一個字符畫標志，會不會很酷？

于是他和Claude一起填了一些字符畫字體，做出了后來很有辨識度的Claude Code全大寫標志。那是一個很小的產(chǎn)品彩蛋，但對一個命令行工具來說，這種小東西會讓它突然有了性格。

Meaghan Choi也加了一個她很喜歡的東西：終端里的小角色Clawd。

Clawd原本是為Claude 3.5 Sonnet發(fā)布做出來的，把它塞進Claude Code的終端里，多少有點“不務(wù)正業(yè)”，但也讓這個冷冰冰的開發(fā)者工具多了一點可愛。

于是，Claude Code就這樣出現(xiàn)在了外部用戶面前。

03

征服用戶之路

早期的Claude Code并不完美，離后來那個聲勢浩大的Claude Code還差得很遠。

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

Ramp的工程師Austin Ray就是其中一個。

他一直喜歡命令行，職業(yè)生涯里能待在終端就待在終端。Claude Code以研究預(yù)覽版發(fā)布后，他看到有人提到這個工具，就去試了一下。

五分鐘后，他感覺到：這東西會從根本上改變一切。

在Austin看來，只要一個工具能讀、能編輯、能運行bash，它就已經(jīng)擁有了搭建其他一切東西的基礎(chǔ)能力。

于是他開始在Ramp內(nèi)部到處安利。

他給同事發(fā)消息，問誰也在用Claude Code。后來干脆走到別人桌前，讓他們裝上Claude Code，打開終端，把手頭正在做的事直接交給它試試。

這種早期用戶對Claude Code非常重要。Austin后來和Boris、Cat每周都開反饋會，開發(fā)者和用戶之間的關(guān)系，就這樣自然而然地建立起來了。

Bun的創(chuàng)始人Jarred Sumner也很早試了Claude Code。

他讓它給Bun實現(xiàn)websocket客戶端壓縮，還把相關(guān)標準文檔喂給它。Claude Code一開始做得并不好，但在幾輪提示和修正之后，它真的把東西做出來了。

這件事讓Jarred對它上了頭——他甚至改變了Bun的工作優(yōu)先級，讓項目變得更適合Claude Code使用。

后來Bun內(nèi)部有人討論要不要禁用Claude Code，Jarred第一個不同意。

早期的Claude Code可以說是非常分裂：有人覺得它bug多，還不夠穩(wěn)定；有人試了幾分鐘，就開始到處拉同事安裝；有人覺得它暫時幫不上自己；也有人已經(jīng)開始改變團隊的工作方式來適配它。

有趣的是，Anthropic內(nèi)部也有類似的分裂。

Tristan Hume做的是性能工程，任務(wù)需要大量上下文，還涉及一些外部網(wǎng)上沒有公開文檔的加速器內(nèi)核。對他來說，早期Claude Code還不夠好。它不會很好地寫自己的工具，也不太會邊調(diào)查邊學習，所以只能處理很有限的任務(wù)。

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

它讓一部分開發(fā)者震驚，也讓另一部分開發(fā)者覺得不夠用。

但Claude 4讓一切都變得不一樣了。

用AI圈常見的黑話來講，那應(yīng)該能算Claude Code的“ChatGPT時刻”——當然，Anthropic肯定不會愿意被這么形容。

要知道，在模型真正好用之前，產(chǎn)品設(shè)計能做的事情其實相對有限。Claude 4模型更會寫代碼，更會處理任務(wù)，也更像一個能自己往前推進的agent。

Boris后來總結(jié)，Claude Code起飛主要就靠兩件事：模型創(chuàng)新，加上商業(yè)模式創(chuàng)新。

模型讓產(chǎn)品的功能變得成立，訂閱模式推出后，用戶也終于可以更自然、更高頻地使用它。

到這時，Claude Code開始變成了一個真的能被開發(fā)者每天打開的工具。

也正是在這個階段，很多人第一次意識到：Claude Code的作用，可能已經(jīng)不只是提高寫代碼速度。

它正在改變工程師和代碼之間的距離。

Claude 4之后，Boris對Claude Code的使用開始迅速變化：2025年2月，Claude Code 大概只寫他10%的代碼；到5月，這個比例變成了30%、40%。

他記得很清楚，那時他正在Code with Claude開發(fā)者大會。Sonnet 4發(fā)布，他坐在后臺房間里，一邊開會，一邊寫代碼。寫著寫著他突然意識到，這個東西真的變好了。

模型變得更會寫代碼，也更會自己推進任務(wù)。

到了2025年冬天，Boris說，自己的代碼已經(jīng)全部由Claude Code完成。他不再親手寫任何一行代碼。

Shauna Kravec的情況則反了過來：同為Claude Code的重度用戶，她過去幾年本來已經(jīng)不怎么親手寫代碼了，但Claude Code反而讓她重新寫得更多。

因為寫代碼這件事變得更容易了。

她不用重新鉆進每一個細節(jié)里，從空白文件開始把東西一點點敲出來。她可以把任務(wù)拆開，讓Claude先跑起來，再看結(jié)果、調(diào)整方向、繼續(xù)往下推。

她說自己有十二個不同的Claude在四處工作：有的讀文檔，有的更新東西，有的從Slack里拉信息。

而Igor Kofman看到了另一個變化：

當模型和Claude Code繼續(xù)變強，人管理的東西會繼續(xù)往上抽象一層。現(xiàn)在你可能還在管理一堆Claude。再往后，你管理的可能是“管理Claude的那個Claude”。

聽起來像繞口令，但剛好對應(yīng)了后來Claude Code繼續(xù)演化出的兩個方向：一是子代理，讓不同Claude 分頭處理不同任務(wù)；二是Skills甚至Loop Engineering，讓人不再一步步提示AI，而是設(shè)計一套目標、檢查和停止規(guī)則，讓AI自己反復(fù)推進。

說白了，人寫得越來越少，安排得越來越多。

Tristan Hume的感受要更復(fù)雜——在前面說，早期Claude Code對他用處有限。但后來，他看見同事們從Claude Code那里獲得了巨大的杠桿。

Tristan意識到，如果想獲得最高的生產(chǎn)力，寫代碼的方式已經(jīng)變了。

問題是，要跟上這種變化，有時還得先付出一段適應(yīng)成本。他甚至需要先花一周時間，把自己的開發(fā)環(huán)境重新搭好，才能讓Claude Code更好地進入他的工作。

Cat Wu觀察到，Claude Code剛發(fā)布時，用戶會認真閱讀它提出的每一個權(quán)限請求。它要讀什么文件，要改什么東西，要執(zhí)行什么命令，用戶都會一條一條看。

但后來，越來越多用戶開始直接自動接受。

Cat Wu認為這說明Claude Code開始贏得用戶的信任。用戶不再把它當成一個隨時可能闖禍的外來者，而是把它當成一個已經(jīng)熟悉項目、可以先放手去做的工作伙伴。

不過我覺得造成這種情況的主要原因是，Claude Code增加了回退機制。

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