編輯 | 聽雨

出品 | 51CTO技術棧（微信號：blog51cto）

自從 5 月份正式開放以來，Claude Code 已經在開發者圈掀起了風暴。

據統計，這款工具目前的年度化收入超過 5 億美元，僅僅在發布后三個月內，使用量就激增了 10 倍以上。

那它到底怎么構建的？

小編最近看了一篇深度專訪，作者 Gergely Orosz，采訪了 Claude Code 的幾位聯合創始工程師和產品經理，信息密度頗為巨大。三位可以說都是CC元老級員工。

Boris Cherny，該項目的首位工程師，也是最初原型的設計者；Sid Bidasaria， Claude Code 的第二位工程師，也是 “Claude Code 子代理（subagents）” 的創建者；

Cat Wu，首位產品經理。

討論中，他們分享了 Claude Code 的構建方式，也洞察了一個成功的“AI 優先工程團隊”是如何運作的。

作者甚至形容自己提前窺見了未來，窺見了一個高速運轉的初創公司可能的工作方式。

“值得慶幸的是，在這個未來里，軟件工程師仍然非常吃香。”

可以說內容非常稀有，為此小編特地為大家整理了這篇采訪文章。

我們這篇文章會聊以下這些，enjoy：

1. Claude Code 的起源
2. 它的技術棧 & 架構
3. 怎么做到幾天交一個功能
4. 交互體驗：終端 UX 的“進化”
5. “AI 優先”工程團隊是什么樣子
6. 子代理（subagents）功能是怎么煉成的
7. 對未來 AI 輔助工程團隊的一些展望

好，話不多說，咱們開整！

1.起源：怎么從“聽歌小工具”演變成開發神器

最早，Boris 在 Anthropic 工作，想著用 Claude 模型寫個命令行工具：讓它讀出開發者在工作時在聽什么歌，還能控制音樂。

最初版本很簡陋：不能讀文件，也不能執行 shell 命令，只能做極基礎的“問答＋控制音樂”的操作。

但后來，Boris 想：要是讓這個工具有讀寫文件、執行批處理命令、瀏覽代碼能力呢？于是他給它“下了工具包”：

• 它能讀、寫文件
• 它能執行 shell / batch 命令

它能瀏覽項目里的文件結構、讀 import 的模塊、進入子文件夾查找依賴的代碼……

于是，這工具就從“小打小鬧”進化成“能自己探索代碼庫、自己找答案”的智能助手。Boris 覺得，這就是“產品滯后”——模型其實有能力了，但市場上還沒一個產品把這個能力展現出來。

內部開始了 dogfooding（內部使用）。在 2024 年 11 月，Claude Code 的第一個內部版本問世：第一天就有 20% 的工程師用了，五天后漲到 50%。

當時團隊內部還在爭論要不要公開它，因為這可能成 Anthropic 的“秘密武器”。最后他們決定發布：既能讓更多人用，也能在實際使用中學習模型的安全與能力。

團隊從最初只有 Boris，一直到 Sid 加入，后來擴展到設計、產品、數據科學等角色，慢慢變成一個完整產品組。

有意思的是：雖然 “Code” 二字暗示這是給開發者用的，但現在很多數據科學家、分析師也開始用了，他們讓 Claude Code 寫查詢、生成可視化……簡單講，就是“原本只是給碼農用的工具，竟然被別人截胡了”。

有個很酷的指標：Anthropic 在工程人數翻倍時，通常 PR（pull request）數/人 會下降，因為老員工要帶新人等。但引入 Claude Code 后，他們反而 PR 數/人 +67%，也就是每個人產能反而上去了。

作者自己也用了這個工具，覺得寫東西快、進度好，也能跑測試、做驗證。

2.技術棧 & 架構：最小 “外殼＋模型” 設計

技術棧選型：讓 Claude 自己寫自己

Claude Code 用了這些技術組合：

• TypeScript
• React + Ink（Ink 是一個用來在命令行里寫 UI 的 React 庫）
• Yoga（一個布局系統，支持不同終端尺寸）
• Bun（打包、構建方案）

為什么選這些？一句話：on-distribution。也就是說，這些技術模型本身就很擅長（模型本來就懂 JS / TypeScript / React 這些東西），不是它要重新“學”的。

團隊的目標是：讓 Claude Code 盡量由 Claude 自己寫。Boris 提到：“90% 的Claude Code 是由 Claude Code 自己寫的?！?/p>

架構之道：最輕、最透明的外殼

雖然 Claude Code 外表看起來做很多事，但實際上內部業務邏輯／客戶端復雜度被壓得非常低。為什么？因為模型做大部分工作。

外殼主要負責三件事：

• 定義 UI，讓模型有接口可以操控界面
• 暴露一些工具（讀文件、執行命令等）給模型調用
• 然后“退后”，不要干涉模型太多

團隊相信：很多產品會給模型添“腳鐐”——用很多中間層、限制、UI 交互，使模型被束縛住。但 Claude Code 想盡量少加這些包袱，讓模型“自由地”發揮。

一句經典話：每當模型能力升級，他們就會刪掉一些之前寫的代碼。比如模型更強了，以前要通過系統 prompt 寫的東西，有時候可以直接去掉。至于運行方式，Claude Code 在本地運行，不走虛擬機也不跑云端。為什么？因為最簡單的方案往往是最可靠的。

本地執行批命令、讀寫文件、交互都發生在用戶機器上，沒有特殊容器或沙箱。這樣設計雖然有風險（誤操作可能傷害系統），但便利性、安全性的權衡團隊覺得最合理。

權限系統：用“問你”機制

在本地直接操作，有風險。比如模型可能想「刪文件」。Claude Code 的解決方案：在執行敏感操作前必須問用戶：

• 本次允許
• 今后允許（記住這個項目／全局）
• 拒絕

他們還做靜態分析：如果命令在用戶的 settings.json 里已被授權，就不再詢問。settings.json 可以按項目 / 用戶 / 組織層面共享配置。

3.功能開發：幾天就出一個功能

在 Claude Code 團隊里，速度就是生命力。

• 內部：每天約 60–100 個內部版本（改一點就發包，讓整個團隊都試）
• 外部：幾乎每天會有一個新版本上線給用戶看
• 每位工程師一天能提交約5個PR（pull request）

更神奇的是：原型設計極其快速。他們在兩天里能產出 10+ 個原型版本——比如 “todo list” 功能就是這樣一步步迭代的。

原型演化過程很有意思：

• 原型 ??#1??：把 todos 列表放在命令行下面
• ??#2??：嘗試把 todos 信息插入當前行中
• ??#3?? / ??#4??：嘗試把 todos 做成可展開的“pill”卡片
• …
• 到 ??#20?? 左右，他們才定下來最終效果：spinner （轉圈加載器）里顯示 todos + Ctrl+T 切換顯示/隱藏

整個過程中，用 prompt（向模型下指令）＋人工調試＋同事反饋，循環迭代非?？?。

以前一個功能可能要幾天／幾周才能夠有雛形，現在 AI 助手加速下來，這類原型幾小時就能搞很多版本出來。

4.終端 UX 重塑：讓交互升級

Claude Code 最酷的一點在于：它把「終端（Terminal）」從靜態工具，變成一個「可以互動、有反饋」的界面。以下是幾個有意思的交互設計方向：

• Todo / 任務跟蹤：當模型執行多個子步驟時，用戶可以看到進度、折疊／展開細節
• Hooks：用戶可以自定義 shell 命令，讓 Claude Code 調用這些命令
• 多種輸出格式：比如 “解釋型”（解釋模型為什么這么寫）、“學習型”（讓用戶親自參與一些小步驟以便理解）等風格
• GitHub / GitLab 集成、CI/CD、配置系統、MCP（模型上下文協議）連接等功能

總之，它不只是一個 “在終端里跑模型” 的工具，而是把「交互」這個維度拉進來，讓用戶感覺像和一個聰明搭檔在對話。

5.“AI 優先”工程團隊：未來工程師的工作方式？

Claude Code 本身就是一個“AI 優先”的產品，而背后的團隊運作也體現這種思路：

• 用 AI 做代碼審查、做測試
• 強調 TDD（測試驅動開發）+ 自動化
• 自動化應急響應、監控
• 小心使用 feature flags（功能開關）來控制風險

團隊愿意讓模型直接進入代碼流程，而不是只作為輔助工具。這個模式是否會成為未來大部分工程團隊的標準？目前還不好說，但 Claude Code 給了一個強烈暗示。

不過，有一點要注意：這種方式在 Anthropic 能行，在別的公司能不能復制，還取決于模型能力、團隊文化、基礎設施安全等因素。

6.子代理（subagents）：3 天做出來的“代理代理”

“子代理”是 Claude Code 的一個擴展機制：基本邏輯是讓模型為某個子任務分配一個“子代理”去跑。

有趣的是，他們花了三天搞出來這個功能，其中兩天做的東西直接砍掉重來。團隊并沒有一步到位，而是用快速原型 + 模型反饋 + 拆解方式，最終把這個功能打磨出來。

這個過程體現了整個團隊在 AI 助力下，做“嘗試—失敗—重做—驗證”循環的能力。

7.對未來的展望：AI 輔助開發還會走到哪里？

從 Claude Code 可以看出一些趨勢：

• 工程師并不會被取代，但角色可能演變得更像“監督 + 指揮者”，把細節交給模型
• 快速原型、快速迭代將成為常態
• 交互設計、權限、安全體系會比以前更重要
• 不同公司復制這種 AI-first 模式的難度可能很高 ——模型能力、團隊文化、資源等都是門檻

總的來說，Claude Code 是一個非常勇敢、前瞻的嘗試。它展示了 AI 在工程生產力提升上的可能性，也給我們一個窗口看看“工程師＋AI 協作”的未來可能長什么樣子。

本文轉載自??51CTO技術棧??，作者：聽雨