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

## 親歷者講述：Claude Code是怎樣煉成的？最好的工具，總是首先為了滿足使用者的自身需求而設計的。這句話放在Claude Code身上，再適合不過。作為AI編程領域難以繞過的高峰，Claude Code不僅是Anthropic最堅實的產品堡壘，更是Claude模型最能發揮特長的地方。然而，這款如今被無數開發者愛不釋手的工具，其誕生過程卻是一部充滿嘗試、挫敗與堅持的故事。時間回到2025年2月，Claude Code首次亮相。它最初是一個運行在終端裡的AI編程工具，能夠自主讀取程式碼、修改文件、執行命令，並根據結果持續調整。

同年5月，Claude Code正式對外開放，並開始融入工程師更熟悉的開發流程，可以接入程式碼編輯器，也能在GitHub中處理任務、查看修改。進入2025年下半年，Claude Code從「終端內的程式碼代理」持續進化，開始強調更自主的工作流程、更長時間的任務處理，以及更好的回退與控制能力，逐漸嵌入團隊的軟體工程流程。到了2026年，Claude Code已成長為Anthropic最重要的AI Agent典範之一，成為這家AI公司用來證明「AI可以進入真實工作現場」的核心產品。然而，只看產品更新日誌與時間線，未免有些無趣。

2026年7月7日，Anthropic官方整理了一份關於Claude Code的歷史故事，來自於它的創造者，也來自於那些早期將其投入使用、推動它成長的人們。這份歷史最有趣的地方，在於它還原了一個產品從無到有的建成過程：一個早期內部工具，如何被少數工程師反覆使用、改造、吐槽、修復；又如何在模型能力跨過門檻之後，突然變成Anthropic最重要的AI Agent樣板之一。有人說，它像一部情境喜劇的試播集；也有人說，它像一部關於科技起源的故事。Anthropic很早就盯上了程式碼。故事要從2021年講起，那時候Claude Code還不存在。

當時Anthropic才剛剛起步，創辦人Dario Amodei從OpenAI出走，決心打造一個更謹慎、更安全的AI公司。而程式碼，從一開始就被放在了非常重要的位置。2021年，Dawn Drain加入後，花了很長一段時間讓Claude學會寫程式碼。她後來回憶，自己在Anthropic前三年的主要任務，就是盡可能做出一個會寫程式碼的模型，目標非常直接：至少要寫得和她一樣好。這個目標聽起來輕巧，真正做起來卻並不容易。他們從最簡單的任務開始，讓模型寫一個小函數，然後自己測試它是否正確。很多時候，模型寫出來的東西都很糟糕，函數不對，測試也過不了。

研究員們就繼續拆解任務、調整訓練、分析失敗樣本，再將模型往前推一點點。到2022年，Anthropic已經開始認真琢磨程式碼助手。聯合創始人Ben Mann回憶，當他們決定開始做產品時，第一個做出來的東西就是一個程式碼助手。那時它只是一個VS Code外掛，用戶可以和它聊天，它會針對問題給出幾種不同的建議，就像一個坐在編輯器旁邊的助手：你問它，它回答；你給它一段程式碼，它給你幾個可能的改法。那時候，它還不會自己鑽進程式碼庫裡翻檔案，也不會打開命令列跑測試。但Anthropic的研究團隊想讓模型「動起來」。光會寫一段程式碼不夠，它還得知道程式碼能不能運行。

光能回答問題也不夠，它要能自己搜索、自己呼叫工具、自己在一個環境裡執行命令。於是，工程問題一個接一個地冒了出來。Dawn和負責強化學習的同事們當時做了一個很關鍵的事情：在容器裡給模型接上一個持續存在的命令列環境。這樣，模型不再只是寫一段程式碼交卷，它能真的執行程式碼，看見輸出，遇到超時也能被處理掉。到2023年，事情開始變得更具體。研究團隊已經不滿足於讓模型寫一個函數、跑一個測試，他們開始往更開放的方向嘗試。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幹活。螢幕上出現了紅色和綠色的程式碼改動，那種後來會變得很有辨識度的修改痕跡。Robert很自然地告訴他：對，它正在幫我寫程式碼。這對Boris的刺激很大。Claude CLI還遠遠談不上好，它粗糙、不穩定，離一個真正能發佈的產品很遠。但Boris感到一種很強的緊迫感，他開始週末也做這件事，朋友叫他出去玩，他也放不下。他後來形容，那段時間腦子裡一直有這個東西，他就是停不下來。而且這種緊迫感，到今天也沒有消失。那是2024年10月，Boris幾乎把全部精力都撲到了這個工具上。

每過一週，他都去找Labs團隊的工程負責人Raphael Lee要人。他知道這個東西還很粗糙，但也知道它不能再只是一個內部demo了。它已經開始有用，已經有人在用它寫程式碼，再往前一步，它可能會變成一個真正的產品。Raphael後來回憶，Claude Code幾乎吃掉了整個Anthropic Labs的資源。儘管處在人才的飢渴狀態，但團隊並沒有一下子膨脹起來，主要靠內部轉崗，還有一些很慢、很謹慎的外部招聘。團隊內部有一個小分歧：Boris想把團隊儘快做大，他需要人，需要速度，需要更多火力。而Adam Wolff作為Claude Code團隊的第一位經理，卻對此持有相反態度。

Adam不想讓團隊太快變大，他覺得團隊一旦擴張，流程、文化、產品判斷都會變複雜。人多當然能多做功能，但也很容易開始過度設計，開始開很多會，開始為了協調而協調。後來Boris回頭看，也承認小團隊反而幫了他們。人少，沒法鋪很大的架構；資源緊，沒法把每件事都做得很重；速度要快，就只能把產品做得更輕，也只能更多地依賴Claude。到2024年12月，專案終於拿到了綠燈。更多人從Labs和其他團隊跳了進來，大概六七個人，開始最後一輪兩週衝刺。Sid後來回憶，很多今天還能看到的核心功能，就是那兩週做出來的，比如問題反饋，比如登錄流程。那時候，他第一次覺得：這個東西真的要變成產品了。

他們的工作方式可以說是相當粗暴。程式碼庫沒有嚴格的拉取請求限制，也沒有很重的評審流程。有人發現問題，他們就直接修。用戶說哪裡不好，他們就馬上改。Boris在早期做了兩個特別重要的東西：自動更新和用戶數據。這讓Claude Code的迭代速度變得很誇張。只要有人跑來抱怨「這個地方不好用」，幾分鐘後，用戶手裡的版本就更新了。Claude Code本身也幫他們跑得更快——它是一個命令列產品，不是複雜的網頁應用，沒有龐大的前端架構，也沒有很多層頁面和服務要協調，簡單反而成了優勢。更大的優勢是，他們正在做的東西，剛好能讓他們自己變快。

一個bug來了，Claude Code可以幫忙定位；一個功能要改，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並不完美，離後來那個聲勢浩大的產品還差得很遠。但有些人很快被它擊中了。Ramp的工程師Austin Ray就是其中一個。他一直喜歡命令列，Claude Code以研究預覽版發佈後，他看到有人提到這個工具，就去試了一下。五分鐘後，他感覺到：這東西會從根本上改變一切。在Austin看來，只要一個工具能讀、能編輯、能運行bash，它就已經擁有了搭建其他一切東西的基礎能力。

於是他開始在Ramp內部到處推廣。他給同事發消息，問誰也在用Claude Code，後來乾脆走到別人桌前，讓他們裝上Claude Code，打開終端，把手頭正在做的事直接交給它試試。這種早期用戶對Claude Code非常重要，Austin後來和Boris、Cat每週都開反饋會，開發者和用戶之間的關係，就這樣自然而然地建立起來了。然而，真正讓Claude Code起飛的關鍵，是模型能力的突破。在模型真正好用之前，產品設計能做的事情其實相對有限。Claude 4模型的出現，讓一切都變得不同了。Claude 4更會寫程式碼，更會處理任務，也更像一個能自己往前推進的Agent。

Boris後來總結，Claude Code起飛主要就靠兩件事：模型創新，加上商業模式創新。模型讓產品的功能變得成立，訂閱模式推出後，用戶也終於可以更自然、更高頻地使用它。到這時，Claude Code開始變成了一個真的能被開發者每天打開的工具。也正是在這個階段，很多人第一次意識到：Claude Code的作用，可能已經不只是提高寫程式碼速度。它正在改變工程師和程式碼之間的距離。有人開始全部由Claude Code來完成程式碼工作，不再親手寫任何一行程式碼；也有人因為Claude Code，反而重新開始寫更多的程式碼，因為寫程式碼這件事變得更容易了。

而更遠的未來，當模型和Claude Code繼續變強，人管理的東西會繼續往上抽象一層，從管理Claude，變成管理「管理Claude的那個Claude」。