編輯 | 伊風
剛剛，Anthropic 完成了 130 億美元 F 輪融資！
估值一舉飆升至 1830 億美元，距離競對 OpenAI 的 3000 億美元大關又逼近了一步。
圖片
在這條資本狂飆曲線背后，一個關鍵詞不容忽視：Claude Code。
這款今年爆火的 AI 編程神器，已成為 Anthropic 業務增長的核心引擎。官方披露，它的年化收入已突破 5 億美元，僅過去三個月的使用量就暴漲 10 倍。
更巧的是，融資消息剛落地，Anthropic 立刻放出了一期新播客——主角正是 Claude Code 之父 Boris Cherny。主題直指一個關鍵詞：Agentic Coding 的未來。
這似乎已經釋放出明確信號：Anthropic 正在全力押注這個方向。
圖片
播客地址：https://www.youtube.com/watch?v=iF9iV4xponk
說回 Claude Code，它并非一開始就面向市場，而是 Boris 為了讓自己和團隊開發更高效而孵化的內部工具。
在播客里，他首次揭開了 Claude Code 的底層基因：
從最初就追求 “盡量簡單” 與 “盡量可 hack”。
根據Boris的解釋， “可 hack 性”指的是Claude Code具有很強的擴展能力。除了大家熟悉的 claude.md 文件、MCP外，如今還在持續增加新的擴展點，例如 hooks、slash commands 等多個方式。
Boris 還談到了代理式編程的演進、Claude Code 的設計思路，并分享了不少實用的使用技巧。
他在對話中拋出了不少值得摘錄的洞見：
1.Agent Coding這一年來最大的變化是：現在寫代碼，不只是靠 Tab 補全，而是讓模型幫你寫代碼。從“直接操作文本”轉向“由模型替你操作文本”，是一個大的演進趨勢，抽象層還會繼續上移。
2.Claude code如何從內部榨出反饋價值：為了能鼓勵團隊提建議，Boris給自己定了死規矩：只要有人反饋，就第一時間要修復。他說：“我經常一進辦公室就連著修兩三小時 bug，然后立刻在 Slack 頻道回復：已修復。”
3. 展望未來，Claude Code關鍵在于：如何讓其擴展得更容易？如何讓更多人能在它之上開發？如何讓 SDK 對大家更有用？這些才是下一步。
4.Claude 會成為圍繞目標自主推進的智能體：“兩年內，我們可能會看到 Claude 不再執行一堆小任務，而是圍繞一個目標持續推進，就像一個工程師思考下個月的 road map 一樣。”
5.代碼本身不再像過去那樣“珍貴”，盡管寫代碼依然是一門藝術。
6.兩個建議：一是新手別直接讓 Claude 寫代碼，先學會圍繞代碼庫進行提問和研究；二是要先評估清楚任務的難度，再決定用哪種方式讓 Claude Code 參與。
以下是經過整理的播客全文，enjoy：
1.如果Claude 是“馬”，那么Claude Code 就是不可缺少的“馬鞍”
主持人Alex Albert
大家好，我是 Alex，我在 Anthropic 負責公共關系。今天我們要聊的是 Claude Code 以及軟件工程的未來。我身邊這位是我的同事 Boris。
Boris Cherny
我是 Boris，Anthropic 技術團隊成員，同時也是 Claude Code 的創建者。
主持人Alex Albert
過去 12 個月里發生了很多事情，節奏非常快，尤其是在代碼領域。對那些不是每天都盯著新聞、跟進前沿的人來說，可能會有點難跟上——其實我自己有時也很難。能不能幫大家回顧一下最近發生了什么？我們現在處于什么階段？
Boris Cherny
嗯，一年前的編程體驗和今天完全不同。一年前，如果你要寫代碼，就是在 IDE 里，有自動補全功能，然后可能還會開個聊天應用，復制粘貼一些代碼來回倒騰。這就是當時所謂的“AI 編程”最前沿的形態。
大概也是一年前，我們開始看到“代理（agents）”的出現，并且被真正地融入到開發流程里。這已經不只是個噱頭或原型，而是開發過程中真正的一個“內環工具”。
我覺得這一年來最大的變化就是：現在寫代碼時，你會用一個智能體（agent）。你不再直接在 IDE 里編輯文本，不只是靠 Tab 補全，而是讓模型幫你寫代碼。我們看到的趨勢是：從“直接操作文本”轉向“由模型替你操作文本”。我認為這是未來的發展軌跡。
主持人Alex Albert
我明白了，也就是說過去是在網頁應用里復制粘貼代碼、做一些很細微的修改；而現在更多是“放手”——告訴智能體你要什么，讓它自己去做大量修改，甚至有時能獨立生成整個應用。
Boris Cherny
對，沒錯。過去之所以做不到，有幾個原因。大家一直都在嘗試讓 AI 自動化編程，但效果不佳。第一，模型本身當時還不夠強大；第二，模型上層的“支架”（scaffolding）也不夠好。Claude Code 最早的版本大概是去年底，我們用的還是 Sonnet 3.5，不是后來的 3.6 或 3.7。
主持人Alex Albert
就是還沒升級的 Sonnet。
Boris Cherny
對，當時用起來勉強能跑，比如我大概 10% 的代碼能靠它來寫。印象特別深的是，有一次我把它交給核心團隊測試，第二天走進辦公室就看到幾位工程師（包括 Robert）已經在屏幕上用它了。雖然那時模型本身還不夠好，工具也比較粗糙，但居然已經有點用處了。
過去一年，模型在“代理式編程”上變得更強大了，從 3.7 到 4.0，再到 Opus 4.1；同時“支架”——也就是 Claude Code——也進步很多。
所謂支架，就像騎馬時需要馬鞍。Claude 是馬，而 Claude Code 就是鞍，能極大改變騎行體驗。我本人不是騎馬的人（笑），但這個比喻挺形象的。
主持人Alex Albert
我喜歡這個比喻。Claude 是馬，工程師要把它引導到某個方向，就必須有一個“鞍”來掌控。這就是“支架”的作用，它涵蓋了工具、上下文處理等等。
Boris Cherny
沒錯。Claude Code 就是這樣的支架：它包含系統提示（system prompt）、上下文管理、工具接入、MCP 服務器、權限設置等。這些接口決定了模型能看到什么、能輸出什么，從而極大影響表現。過去一年，我們逐漸學會了如何為模型設計這樣的支架。
2.實際上手后的“直覺”，遠比編碼測評指標更直觀
主持人Alex Albert
你剛提到“共同進化”，是說我們在訓練時刻意這么做的嗎？還是說這是個自然過程？
Boris Cherny
其實是很自然的。在 Anthropic，每個人都用 Claude Code，包括研究員。所以在用的過程中，我們會不斷看到模型的限制，比如它在做某些編輯時經常失敗，或者早期版本只能短時間保持“自動運轉”，需要人類頻繁糾偏。而新模型能更長時間保持自主運行。這些體驗反饋都會反過來幫助我們改進模型。
主持人Alex Albert
在評估新模型時，你會不會有一套“直覺測試”或者固定用例？還是說你主要看新特性上線后在支架中的表現？
Boris Cherny
我個人的方法其實很直接，就是自己上手用。
主持人Alex Albert
那你的工作方式是怎樣的呢？
Boris Cherny
對我來說，理想的一天就是整天寫代碼。不管我們在測試的新模型是什么，我都會用它寫代碼，看它表現如何。我沒有固定的測試流程。
主持人Alex Albert
對，你就是直接看它在日常工作中對你有沒有幫助？
Boris Cherny
沒錯，沒錯。因為日常工作里會涉及各種各樣的事情：寫新代碼、修 bug、看 Slack 消息或者 GitHub issue 回復用戶反饋。現在模型能幫上越來越多的忙。如果你只讓模型做某一類事，就會錯過它的新能力，比如通過 MCP 拉取上下文、讀 Slack 消息，或者自動調試 —— 因為它能自動獲取 Sentry 日志。
主持人Alex Albert
所以最好的評估方式，某種意義上就是最接近真實使用場景的方式。直接用它，其實是最有效的評估。
Boris Cherny
對，我們在構建 Claude Code 的時候，也確實嘗試做產品層面的評測。
主持人Alex Albert
嗯。
Boris Cherny
比如說，當我們修改 system prompt 或者別的設置時，就要知道模型有沒有變好。我們確實有一些評測手段，但老實說，做 eval 太難了。最大的信號還是靠直覺 —— 感覺它是不是更聰明了。因為開發任務覆蓋面太廣。
主持人Alex Albert
是啊，開發者經常問我們，想要更多關于 prompt 測試和迭代的指導。我們在不同產品上都嘗試過各種 eval，但對 Claude Code 來說，最核心的還是這個緊密的反饋循環。它比一堆硬編碼的評測指標反而更直觀。
Boris Cherny
我知道大家可能想聽一個更“學術”的答案，但實際上，就是靠感覺。現在模型在各種 benchmark 上都表現很好，比如 SWE-bench 之類的。我們更多是在尋找更難的評測方法，比如 T-bench。只是要找到能覆蓋軟件工程復雜性的“合成型評測”真的很難。
主持人Alex Albert
對對。你覺得我們內部有沒有做了什么特別的事，讓這個反饋循環格外有效？我感覺 Claude Code 的“自用反饋（dogfooding）”循環是我見過最好的。
Boris Cherny
一開始我就是按照做其他產品的方式來做 —— 傾聽用戶，并且盡量讓他們的反饋渠道變得簡單。最初我們只建了一個 Slack 反饋頻道，所有反饋都集中到那里。我還發現，有時人們其實不太愿意提反饋，因為他們覺得沒人會看，反饋會消失在黑洞里。所以我當時做的一個關鍵點就是：只要有人提反饋，我會盡快修復。經常是一進辦公室，我就花 2-3 小時集中修一堆 bug，然后立刻在頻道里回復“已經修復”。這會讓人們更愿意繼續反饋。直到今天，Claude Code 的內部反饋頻道依然是“水管爆裂”一樣的信息流。
主持人Alex Albert
對，真是沒停過。我記得早期（現在也一樣），我一發反饋，你立刻就會用表情回應，或者追問細節。這樣真的讓人覺得“哦，原來反饋有人聽”，于是就更有動力去繼續反饋。
Boris Cherny
是啊，因為老實說，我也不知道自己在做的到底對不對。其實沒人知道該怎么做 AI。我們都是邊做邊探索。而最重要的信號就是用戶的需求，所以必須聽用戶的。
3.Claude Code：“盡量簡單”和“盡量可 hack”原則
主持人Alex Albert
那我們換個話題，現在 Claude Code 產品的現狀如何？有哪些最新功能？你對什么最興奮？
Boris Cherny
Claude Code 從一開始就追求“盡量簡單”和“盡量可 hack”。我覺得“可 hack 性”是我們最近發展很多的一個方向，我對此特別興奮。
Boris Cherny
最初，擴展 Claude Code 的方式是通過 claude.md 文件。它可以放在項目的根目錄，也能放在子目錄，作為額外的上下文信息。它常常會隨著代碼庫一起提交，能讓 Claude Code 更了解你的代碼。
但后來我們加了很多新的擴展點。比如現在有更復雜的設置系統和權限系統。我們還引入了 hooks，這個是我們工程師 Dixon 開發的，他看到很多用戶希望以不同方式擴展，就寫了一個功能非常全面的 hook 系統。
另外還有 MCP，這顯然是一個很棒的擴展點。現在我們還有斜杠命令（slash commands）和子代理（sub-agents）。其中用戶自定義的 slash commands 是我們投入很多的功能。它的形式其實很簡單，就是一個 Markdown 文件放在代碼庫里，可以頻繁復用。比如我有一個“提交代碼”的 slash command，里面寫了如何寫一條好的 Git commit 信息，并且預先允許了提交命令，這樣模型每次都能直接幫我提交，不用我重復確認。我覺得 slash commands 非常有趣，而 sub-agents 可以看作是另一種形式的 slash commands —— 它們像命令，但有獨立的上下文窗口。可以說，agents 和 slash commands 是同一枚硬幣的兩面。
這讓我特別興奮，因為這是擴展 Claude Code 的又一種方式。展望未來，我覺得關鍵就是：我們如何讓 Claude Code 擴展得更容易？如何讓更多人能在它之上開發？如何讓 SDK 對大家更有用？這樣不僅能幫你構建代碼代理，還能應用在其他任何需要 agent 的場景里。SDK 都能用。而且所有這些改進，都受益于我們在提升模型自主性上的努力 —— 讓它能運行更長時間、能更好地遵循指令、能記住更多東西。整個過程互相促進。
4.一年之后，Claude或許能像工程師一樣思考
主持人Alex Albert
那么 6 到 12 個月后，如果我在用 Claude Code 或它的某個版本，我的工作會是什么樣？難道整天都在 review PR 嗎？能幫我們拆解一下日常工作會變成怎樣？
Boris Cherny
我覺得未來還是會有一部分親手寫代碼的工作，這不會消失。不過形式可能會不同。比如現在“親手寫代碼”是直接在 IDE 里改文本，但以后可能是通過 Claude 代替你操作文本。除此之外，還會有另一類工作：Claude 主動做了一些修改，甚至幫你 review 了代碼，而你的職責是判斷要不要接受這些改動。再往后，比如 12 個月或 24 個月后，我們可能會看到 Claude 以“目標”為導向，做更高層的事情，而不是一堆具體的小任務。就像工程師會想：我下個月要實現什么目標？然后逐步做一些修改來實現它。Claude 未來也可能會這樣。
主持人Alex Albert
對，就是逐級抽象上移。從最初讓 Claude 改某個文件里的幾行，到讓 Claude 修改整個 PR，再到讓它圍繞一個目標去構建應用，或者實現別的成果。
Boris Cherny
沒錯。
主持人Alex Albert
挺有意思的。如果我是工程師，聽到這些，感覺未來在很短時間里會有巨大變化，尤其是我的角色和工作內容。你會給正在準備適應這種新世界的人什么建議？他們應該學習哪些東西，培養哪些技能？
Boris Cherny
我會想到自己最早寫代碼的時候。那時我還是初中生，坐在數學課的最后一排，手里有個透明灰色的 Ti-83 Plus 計算器，可以看到電路。我用 Basic 給它編程，因為我發現可以把考試答案寫進去，用來考高分。那種“黑客式”的直覺體驗很震撼：你能想到一個程序，就直接在計算器里寫出來，然后馬上運行。這種快速反饋的循環讓我能做出以前完全做不出來的東西。
而且入門非常容易。但后來，進入“沒有 agent 的時代”，整個技術棧變得特別復雜。比如我想做一個 JavaScript 網站，就得學 React、Next.js，再加三個構建系統和一個部署系統，復雜到嚇人。我覺得智能體的一個很酷的地方就是它正在改變這種狀況。用代碼代理，開始變得很容易。如果你有想法，就能快速實現。而且更多是圍繞“想法本身”，而不是技術細節。Claude Code 自己的代碼我們經常反復重寫，這就是 agent 讓一切變得可能。
所以代碼本身不再像過去那樣“珍貴”，盡管寫代碼依然是一門藝術。有時候我還會手寫代碼。我們團隊的工程師 Lina 也說，她周末會寫 C++，就是因為好玩。作為程序員，這本身是一種樂趣。但未來會越來越偏向于“你做出了什么”，而不是“你是怎么做的”。我給今天學編程的人一個建議：你依然要掌握這門手藝 —— 學會寫代碼、學語言、學編譯器和運行時、學怎么構建 Web 應用、學系統設計，這些都要會。同時，也要更有創造力。如果你有創業點子或產品想法，現在真的可以直接做出來，這是以前根本不可能的。我們還不知道這會帶來什么，但潛力巨大。
5.最佳實踐分享：先讓agent做研究，再寫代碼
主持人Alex Albert
我很喜歡這個建議。以前一個想法可能永遠躺在 backlog，現在幾分鐘就能實現。那在結束之前，作為 Claude Code 的創建者，你有沒有一些“最佳實踐”或者小技巧可以分享？
Boris Cherny
有的，我覺得有兩個小技巧。第一個是，如果你是新用戶，還沒用過 Claude Code，那一開始不要直接拿它來寫代碼。我知道這聽起來有點奇怪，但你要克制住。
先用它來提問，問代碼庫相關的問題。比如：我想加一個新的 logger，要怎么做？Claude Code 會幫你探索代碼庫，找到答案。或者問：為什么這個函數是這樣設計的？Claude Code 可以查 Git 歷史，幫你解釋。先從這種“問問題”開始，而不是直接寫代碼。等你習慣了這種讓 agent 幫你做研究的方式，再逐漸用它來寫代碼。
我覺得第二個建議是：當你真的用 Claude Code 來寫代碼時，要先想清楚你要做的工作是什么、任務有多大。我腦子里大概分成三類：簡單、中等和困難。
- 簡單任務：Claude 基本上一條 prompt 就能完成，比如我現在常常直接在 GitHub 上 @Claude 一個 issue，讓它直接寫一個 PR，這樣我就不用占用終端了。
- 中等任務：我會先在終端里用“計劃模式（plan mode）”，Shift+Tab 進入計劃模式，先和 Claude 對齊一個計劃，等我覺得這個計劃靠譜了，再進入“自動執行（auto acceleration）”讓它去實現。
- 困難任務：這時候還是我在主導，Claude 更像是我的搭檔工具。我主要自己寫代碼，Claude 可以幫我做一些代碼庫研究、原型試驗，或者我會讓它“vibe code”一些選項，幫我探索系統的邊界。但最后大部分實現還是我來寫，Claude 可能幫我寫一些單元測試。
所以我的第二個建議就是：要先評估清楚任務的難度，再決定用哪種方式讓 Claude Code 參與。
主持人Alex Albert
這些技巧太棒了，非常感謝你，Boris，今天聊得很精彩。
Boris Cherny
謝謝，也謝謝你，Alex。
6.寫在最后
播客的內容到此已經結束了。最后，有一個有趣的小插曲。
在這期播客評論區里，畫風卻突然轉向。
不少 Claude Code 用戶在線“維權”，紛紛留言：
能不能談談最近幾周性能大幅下降的問題？
請正面回應一下 Claude Code 性能退化的問題。
圖片
就在不久前，Claude Code 官方剛宣布了啟用每周使用上限，氪金用戶的自由再度收縮。現在又被用戶詬病性能下降問題。
值得注意的是，此前，另一款熱門 AI 編程工具 Cursor 就曾因為性能下滑與限流問題而“翻車”。用戶廣泛吐槽其“無限用”承諾縮水，Pro 版變相加設使用上限，最終引發退訂潮，口碑一度滑坡。
難道，這就是爆款編程產品的宿命？
你是否也有類似感受？
