來整理一下 Claude Code 誕生的故事，主要來源是科技博主 Gergely Orosz 採訪 Claude Code 核心成員的文章。 Claude Code 確實了不起，5 億美元年化收入，三個月用戶量漲了 10 倍，現在也是很多程序員首選 Coding Agent 工具。 這個工具最初只是一個能告訴你“現在在聽什麼歌”的命令行小玩具。 🧵

Gergely Orosz 採訪了 Claude Code 的三位核心成員： • 創始工程師 Boris Cherny（17 年從業經驗，前 Meta 主任工程師） • 二號工程師 Sid Bidasaria（Subagents 功能的作者） • 以及產品經理 Cat Wu。 他們聊了 Claude Code 是怎麼從原型變成產品的，技術上做了哪些選擇，以及這個十幾人的小團隊如何做到每人每天發佈 5 個 PR。 這可能是目前最接近“AI 優先工程團隊”的樣本。他們用 AI 寫代碼、寫測試、做代碼審查、排查故障，甚至用 Claude Code 來開發 Claude Code 本身。90% 的代碼是它自己寫的。 我想做的是把這次採訪裡最有意思的部分整理出來，講講這個團隊是怎麼工作的，有什麼可以借鑑的，又有什麼是他們的特殊條件決定的、不能照搬的。 下面分成 7 個小故事，每個都能獨立看，串起來是一個完整的圖景。

【1】一個聽歌小工具，如何變成年入 5 億美元的產品 2024 年 9 月，Boris Cherny 剛加入 Anthropic，閒著沒事寫了個命令行小玩具。 這東西能幹嘛呢？它能用 AppleScript 告訴你現在在聽什麼歌，還能根據你的指令換歌。就這麼簡單。Boris 自己的評價是：“挺酷的 demo，但沒啥意思。”

真正的轉折發生在他和同事 Cat Wu 聊完之後。Cat 當時在研究 AI Agent 的計算機使用能力，聊著聊著，Boris 冒出一個念頭：如果給這個命令行工具更多權限呢？比如讓它能讀寫文件、能執行命令？

他試了。然後，見證奇蹟的時刻來了。 Boris 把這個升級版工具扔進 Anthropic 的代碼庫，隨便問了幾個問題。Claude 開始自己探索文件系統——讀一個文件，看到裡面的 import 語句，就順著去讀被引用的文件，一層層往下挖，直到找到答案。 “這把我震住了，”Boris 回憶說，“我從來沒用過這樣的工具。”

在 AI 領域有個概念叫“product overhang”，翻譯過來就是“產品溢出”。意思是模型其實已經具備某種能力了，但現有的產品形態沒有把這種能力釋放出來。 Boris 發現的，正是一個巨大的“product overhang”，Claude 早就能做到這些，只是沒人給它造個殼子。

Boris 開始每天用這個工具幹活，然後分享給幾個同事。兩個月後的 11 月，他們發佈了一個內部版本。 數據很誇張：第一天，20% 的工程師在用；第五天，50%。

這時候出現了一個有趣的爭論：要不要對外發佈？ 反對的理由很真實：這東西如果真有我們以為的那麼強，留著當“秘密武器”不好嗎？為什麼要把競爭優勢拱手讓人？ 最終，Anthropic 選擇了發佈。邏輯是這樣的：Anthropic 的核心使命是研究模型安全，而研究安全最好的方式是讓人真正使用這些工具。既然內部已經驗證了 Claude Code 會被大量使用，那發佈它就能帶來更多關於模型能力和安全的洞察。

2025 年 5 月，Claude Code 正式公開。三個月後，使用量漲了 10 倍，年化收入超過 5 億美元。 有意思的是，Boris 最初只想著給程序員用——所以才叫“Claude Code”。但有一天他走過數據科學家的工位，發現對方屏幕上也跑著 Claude Code。“你用這個幹嘛？”“我讓它幫我寫查詢、做可視化啊。”現在，Anthropic 的數據科學家們人手一個，有些人同時開好幾個。 一個聽歌小工具，因為多給了幾個權限，變成了一個價值數億美元的產品。這大概是“product overhang”最好的證明，模型能力一直在那兒，等的只是有人把它釋放出來。

【2】90% 的代碼是自己寫的——Claude Code 的技術選型哲學 Claude Code 有 90% 的代碼是它自己寫的。 聽起來像噱頭，但這其實歸功於他們的技術決策邏輯。 先看技術棧：TypeScript 寫主體，React 搭配 Ink 框架做終端 UI，Meta 開源的 Yoga 做佈局系統，Bun 負責構建打包。 為什麼選這些技術棧呢？因為它們“在分佈內”。 “在分佈內”（on distribution）是 AI 領域的術語。意思是模型已經見過大量這類代碼，擅長處理它們。TypeScript 和 React 正是 Claude 的強項。如果選一個冷門框架，模型就得“學習”，效果會打折扣。 這個選擇帶來一個美妙的循環：用 Claude 擅長的技術棧寫 Claude Code，然後用 Claude Code 寫更多 Claude Code。90% 自己寫自己，就是這麼來的。 他們在架構層面的選擇同樣簡潔。 Claude Code 在本地運行。沒有 Docker 容器，沒有雲端沙箱，就是直接在你的電腦上讀寫文件、執行命令。

至於為什麼這樣設計？ Boris 的回答是：“每次做設計決策，我們幾乎都選最簡單的方案。本地運行就是最簡單的答案。” 這種簡單延伸到整個產品哲學：儘可能少寫業務邏輯，讓模型做主角。 “這聽起來可能有點奇怪，”Boris 說，“但我們希望用戶能儘可能“原汁原味”地感受模型。很多 AI 產品會加一堆腳手架——額外的 UI 元素、各種輔助功能——結果反而限制了模型的發揮。我們要做的是讓 UI 儘可能精簡。” 為了保持簡潔，每次 Claude 發佈新模型，他們就會大量精簡代碼。 比如 Claude 4.0 發佈時，他們刪掉了大約一半的系統提示詞，因為新模型不再需要那些“柺杖”了。工具數量也在不斷精簡——能刪就刪，能合併就合併。 整個 Claude Code 架構可以概括為三件事：定義 UI 並暴露給模型修改的接口、暴露工具讓模型調用、然後閃到一邊去。 當然，簡單不意味著沒有複雜的部分。權限系統就是例外。 畢竟讓 AI 在你電腦上執行命令是有風險的。Claude Code 的解決方案是執行前先問你：要不要批准這個操作？可以只批准這一次，也可以以後都批准，或者拒絕。 權限系統支持多層配置——按項目、按用戶、按公司。團隊可以共享配置文件，把常用的安全命令加入白名單。 這套權限設計背後的原則是這樣的： 如果你啟動 Claude Code，它不應該在沒經過你同意的情況下改動任何東西。但同時，也要給用戶“放權”的選擇——在你信任的場景下，可以跳過確認環節。 簡單，但不是簡陋。剋制，但不是功能缺失。

【3】兩天 20 個原型——AI 時代的產品迭代長什麼樣 以前做產品原型，兩天能做出兩個就算效率高了。 Boris 花兩天做了 20 個。 這不是誇張，是他開發 Claude Code 的 todo list 功能時的真實記錄。他甚至把每一步的提示詞和截圖都分享了出來。 我們來看看這 20 個原型是怎麼迭代的。 第一版，他想讓 todo 列表顯示在最近一次工具調用的下方。提示詞很短：“讓 todo 不要隨著輸入出現，而是在輸入框上方顯示一個固定的 todo 列表，標題用灰色顯示 '/todo (1 of 3)'”。 看了看效果，不太滿意。 第二版，改成在每個 todo 更新時內聯顯示。提示詞：“其實不要顯示 todo 列表，改成在模型開始處理一個 todo 時，把工具名稱渲染成粗體標題。保留'step 2 of 4'這樣的進度顯示。” 還是不對。 第三版和第四版，他嘗試做一個“交互式藥丸”——屏幕底部一個小方塊，點開能看進度。“在文字輸入框下面加一個 todo 藥丸，類似後臺任務的樣式，顯示 'todos: 1 of 3'。”然後：“讓這個藥丸可以交互，像後臺任務藥丸那樣。” 有點意思了，但還不夠好。 第五版和第六版，他換了個思路：做個從右邊滑出來的“抽屜”。“把之前的藥丸和標題都撤銷，改成在輸入框右邊顯示 todo 列表，垂直居中，用灰色分隔線隔開。”“有點跳，能不能做成抽屜動畫？” 看起來挺酷，但實用性存疑。 第七到第九版，他又把 todo 列表挪到輸入框上方，試驗不同的截斷方式和標題樣式。“如果超過 5 個就顯示'... and 4 more'”，“加個灰色的 'Todo:' 標題”。 離答案越來越近了。 第十到二十版，他開始琢磨怎麼把 todo 列表和加載動畫結合起來。最後的解決方案是把進度信息放到 spinner（加載指示器）旁邊，最大化可見性。 發佈後，用戶反饋說想看完整的 todo 列表。於是又加了一個迭代：按 Ctrl+T 可以展開全部步驟。 這就是現在線上的版本。

整個過程裡，Boris 的提示詞出奇地簡短——大多數就一兩句話。但每一版都是可以實際運行的原型，不是靜態圖，不是 PPT。他可以真正測試驗證這個功能，感受它順不順手。 傳統的產品開發流程是：想法 → 討論 → 畫線框圖 → 做高保真設計 → 開發 → 測試 → 上線。每一步都要時間，每一步都可能卡住。 現在的流程變成了：想法 → 一句話提示詞 → 可運行的原型 → 感覺不對就再來一版。 這其實要求開發者在思維方式上進行改變，才能適應這種開發流程。 以前，原型的作用是“驗證想法”——因為做原型成本高，你得先想清楚再動手。現在，原型變成了“探索可能性”——因為做原型成本低，你可以先做出來再說，不好就扔掉。 Boris 說，用 Claude Code 的時候，他經常直接跳過畫設計圖的階段，直接做一個能跑的版本，比什麼都直觀。 Claude Code 團隊的日常節奏是：每個工程師每天推大約 5 個 PR，內部每天發佈 60-100 個版本，外部每天發佈 1 個版本。 一天 5 個 PR，這在大多數公司是難以想象的。Uber 在最緊張的重構期，一天能推一個中型 PR 就算不錯了。 工具變了，節奏就變了，思維方式也得跟著變。

【4】重新設計集成 AI 後的命令行終端 命令行終端已經存在了幾十年，為什麼現在需要重新設計？ 因為在 LLM 出現之前，終端並不會太注重交互體驗。 傳統的命令行是一問一答：你輸入命令，它返回結果，完事。沒有對話，沒有上下文，沒有等待時的反饋。你盯著光標閃爍，不知道後臺在幹嘛。 Claude Code 是第一批真正需要思考“終端 UX”的產品。他們加了幾個小細節，看起來不起眼，但用起來感受完全不同。 第一個：上下文加載提示。 當模型在思考時，屏幕上能根據當前任務顯示生成相關的提示：比如“正在閱讀你的代碼結構”或者“正在思考解決方案”。 這是個很小的觸感，但它讓工具有了“人格”。你會覺得它在認真幹活，而不是卡住了。Boris 說，上一次他看到這種讓人愉快的小交互，還是 Slack 的新手引導流程。 第二個：等待時的教學提示。 當 Claude 在執行一個長任務時，屏幕底部會輪流顯示使用技巧，比如“你可以按 Esc 中斷當前任務”或者“試試 /help 看看所有命令”。 命令行用來教命令行，簡單又聰明。 第三個故事更精彩：Markdown 渲染器。 發佈前一天，有工程師抱怨嵌套列表顯示得很醜，段落間距也不對。問題出在 Markdown 渲染器上。Boris 試了市面上所有現成的渲染器，沒一個在終端裡好看的。 於是他用 Claude Code 花了一天時間，從頭寫了一個 Markdown 解析器和渲染器。 對，發佈前一天。對，從頭寫。對，用的是 Claude Code 自己。 結果這個“趕工”出來的渲染器，比所有現成方案都好看。他們直接發佈了。Boris 認為現在沒有任何其他終端有同樣質量的 Markdown 渲染。 這個故事說明了一件事：當你有一個足夠好的 AI 編程工具時，“自己造輪子”的成本會大幅下降。以前“能用就行”的妥協，現在可以變成“那就做一個更好的”。 命令行終端這個古老的界面形態，正在因為 LLM 的加入而煥發新生。終端還是那個終端，只是因為有了 AI 的加入，讓我們需要認真思考：怎麼讓人和終端裡的 AI 更好地對話。

【5】AI 滲透到每個環節——一個工程團隊的“全面 AI 化”實驗 Anthropic 的工程團隊，可能是目前把 AI 工具用得最極致的團隊之一。 不只是體現在寫代碼上，而是是項目中的各個環節。 代碼審查：所有 PR 的第一遍審查由 Claude Code 完成，工程師做第二遍。Boris 說，Claude Code 在第一遍就能發現很多問題。這個功能原本只在內部用，後來他們把它公開了，所有人都能用 Claude Code 做安全審查。 寫測試：Claude Code 的測試套件幾乎全是 Claude Code 寫的。Boris 說：“以前如果有人提 PR 不寫測試，我會猶豫要不要說什麼——感覺像在挑刺。但現在有了 Claude，寫測試就是一句提示詞的事，沒有藉口不寫。” 事故響應：oncall 的工程師會讓 Claude Code 幫忙分析 Root Cause（導致問題最根本的原因）。它能從 Slack 拉相關討論，從 Sentry 拉錯誤日誌，從各種監控系統拉數據，然後綜合分析。Boris 說 Claude Code 在某些場景下找 Root Cause 比人還快。 GitHub issue 分流：每當有新 issue 進來，Claude Code 會先做一遍分析，然後工程師問它“能不能實現一下”。Boris 說，大概 20%-40% 的情況下，它第一次就能搞定。 圖表和查詢：產品數據存在 BigQuery 裡，幾乎所有查詢和可視化都是用 Claude Code 生成的。工程師甚至會讓它直接輸出 ASCII 圖表。

最讓我意外的是 TDD（測試驅動開發）的復興。 TDD 是個老概念了：先寫測試，再寫讓測試通過的代碼。理論上很美好——強迫你先想清楚要什麼。但實際操作中，大多數人覺得它太慢、太麻煩，所以這個方法在過去十幾年慢慢邊緣化了。 但 Boris 說，用 Claude Code 之後，他做了大量 TDD： “我會先讓模型寫一個測試，同時告訴它這個測試現在會失敗，不要試圖讓它通過。然後我再讓它寫代碼實現功能，並且讓測試通過，但不能改測試本身。” “當模型有一個明確的目標去迭代——比如一個單元測試或者一個 mock——它表現得非常好。” 他特別提到，Claude 4.0 是第一個能讓模型寫大部分測試的模型系列。之前的版本可以寫一部分，但需要大量人工干預。 還有一個新概念：multi-clauding。 意思是同時運行多個 Claude Code 實例，讓它們並行處理不同的任務。Sid 說他經常這麼幹——開會的時候啟動幾個 agent，會後回來看結果。 Anthropic 發現，25% 的 Max 訂閱用戶（月費 100-200 美元的高級用戶）每天都在 multi-clauding。 這是一個很有趣的變化。編程一直是“單線程”活動：你一次只能幹一件事，只有等代碼審查或者部署的時候才會切換任務。但現在，“並行編程”成為可能——你可以同時推進好幾件事。 當然，這裡面有很多未知數：並行工作是真的更高效，還是只是感覺更高效？什麼類型的任務適合並行？每個 agent 分到的注意力變少，會不會出問題？ 這些問題還沒有答案。但我們有了一個新工具可以實驗。 最後講一個案例。有家公司要做框架遷移，原本估計需要兩個工程年——一個工程師幹兩年，或者十個工程師幹兩個半月。他們用 Claude Code，一個工程師兩週搞定了。 Boris 說他以前會對這種說法持懷疑態度，但類似的故事他們聽到太多次了。

【6】三天黑客松——Subagents 功能是怎麼誕生的 Subagents 這個功能的靈感，來自 Reddit 上的一條帖子。 有人說他同時開了五個 Claude Code 實例，給每個實例設定不同的角色，然後用文件系統讓它們互相通信。 Sid Bidasaria 看到這條帖子的時候，第一反應是：這個玩法很酷，但用戶不應該需要這麼折騰。我們應該把它做成產品內置的功能。 正好公司有個三天的內部黑客松，Sid 決定用這三天來做這件事。 第一天，團隊興奮地畫出了各種複雜的 Agent 拓撲結構：Agent 之間用消息總線通信、異步模式、多對多交互……圖畫得很漂亮，概念很先進。 第二天，他們意識到這樣做似乎不可行。 問題不是技術實現——那些複雜模式都能做出來。問題是用戶沒法理解。Claude Code 的 UI 就是一個簡單的終端，你怎麼在這麼簡單的界面裡讓用戶明白那些複雜的 Agent 通信模式？ 他們決定推倒重來，回到一個根本問題：普通開發者能用的最簡單形式是什麼？ 他們給自己定了兩條約束： 第一，不發明任何新東西。只用 Claude Code 已有的能力——“/”命令和 .md 文件。 第二，不做 Agent 間通信。改成一個簡單的編排模式：有一個主 Agent，它可以調用子 Agent，子 Agent 完成任務後返回結果，僅此而已。 他們還和 Anthropic 的研究團隊聊了聊。研究人員正在研究多 Agent 模式，但結論是：複雜的 Agent 拓撲是否真的有效，目前還沒有定論。 這給了他們更多信心：既然連研究團隊都說複雜不一定好，那就更應該做簡單的版本。 第三天結束時，他們做出了一個能用的版本。用戶可以在 .md 文件裡定義子 Agent 的角色和能力（比如“前端子 Agent：使用 React 19 和 Next.js”），Claude Code 會在合適的時候調用它們，或者用戶可以手動觸發。 黑客松結束後，稍微打磨了一下，功能就上線了。 現在你可以定義各種專屬子 Agent：有安全審計專長的後端 Agent、熟悉特定框架的前端 Agent、專門寫測試的 QA Agent……它們可以在後臺並行工作，各司其職。 很多團隊在黑客松裡會捨不得推翻自己的複雜方案，畢竟花了一整天畫圖討論，有感情了。能夠承認“這條路走不通”並推翻從頭開始，需要勇氣，也需要對“簡單”的信念。 簡單不是偷懶。簡單是在無數可能性裡找到那個用戶真正能用的形態。

【7】未來的工程團隊會是什麼樣？一些可以借鑑的，和一些不能複製的 Boris 說：“編程現在太有意思了。上一次有這種感覺，還是中學時第一次在圖形計算器上寫代碼。那種魔法般的感覺，我很久沒體驗過了，但現在又回來了。” Sid 的感受類似：“讓我興奮的有兩件事。一是我們發佈的速度——有時候甚至感覺太快了。二是這麼多的實驗空間——以前的工作雖然也快，但做的東西比較套路，知道答案是什麼，就是執行而已。現在不一樣，模型每三個月就變一次，我們得不斷重新思考怎麼做事。” 這些感受很真實，也很有感染力。 但在討論“未來工程團隊會是什麼樣”之前，也不要忘記 Anthropic 的特殊性。 第一，Anthropic 是研究實驗室，不是產品公司。它的核心使命是研究 AI 安全和能力，產品是手段不是目的。這意味著他們對“快速實驗”的容忍度比一般公司高得多。 第二，他們的主要產品是 Claude 模型本身。Claude Code 只是模型的一個“套殼”。所以“刪代碼讓模型做更多事”對他們來說是自然選擇，但對其他公司可能意味著把核心業務邏輯交給一個黑盒。 第三，所有員工都有無限的 Claude 訪問權限，包括最貴的 Opus 模型。在大多數公司，AI 訂閱費是需要爭取的預算項目，不可能人人敞開用。 第四，團隊只有十幾個人，流程極簡。他們幾乎不用 feature flag（功能開關），因為“太慢了”。這在用戶基數大、出錯成本高的產品裡是不可想象的。 所以，直接複製 Claude Code 團隊的做法，對大多數團隊來說不一定現實。 但有些東西是可以借鑑的。 快速原型的思維方式：就算你做不到一天 10 個原型，能不能從“兩週一個”變成“一週三個”？工具已經變了，對“原型應該多快”的預期也該更新了。 AI 輔助代碼審查：讓 AI 做第一遍審查，人做第二遍。這個流程不依賴無限 API 訪問，大多數團隊都能嘗試。 TDD 的復興：如果寫測試變得足夠容易，那“沒時間寫測試”就不再是藉口。這可能是改善代碼質量的一個低成本切入點。 Product-minded engineer (有產品感的工程師) 的價值放大：Claude Code 團隊沒有設計師、沒有 PM，就靠幾個有產品感的工程師。AI 工具讓這種“全棧型人才”能做的事情大幅擴展了。

當然，也有些東西是工具替代不了的。 Boris 能在 20 個原型裡挑出最好的那個，是因為他有判斷力——他知道什麼“感覺對”，什麼只是“看起來能用”。這種品味是 17 年軟件開發經驗的積累，不是 AI 能給的。 團隊第一天做了複雜方案，第二天能狠心推倒重來，這種決斷力也是人的判斷。 知道什麼時候該刪代碼、什麼時候該留著，這種架構直覺同樣如此。 AI 讓執行變快了，但它沒有讓“知道該做什麼”這件事變簡單。相反，因為執行成本下降，“做什麼”的決策變得更重要了——你可以很快做出 20 個版本，但你得知道哪個是對的。 幾年後的軟件工程會是什麼樣子？沒人能準確預測。但 Claude Code 團隊的今天，可能是很多團隊明天的某種預演——更快的迭代、更少的“搬磚”、更多的判斷和決策。 工具在變。不變的是，最終做決定的還是人。