導讀：本文內容整理自 Anthropic 創作者兼 Claude Code 負責人 Boris Cherny 在 Lenny's Podcast 頻道之專訪。
內容提要：Boris Cherny 在 Lenny's Podcast 探討 Claude Code：當程式設計難題被解決後會發生什麼
- AI 驅動的軟體開發革命： Boris Cherny 認為，AI（如 Claude Code）已經並將繼續徹底改變軟體開發。他本人 100% 的程式碼由 AI 生成，且已不再手動編輯程式碼。這種轉變將使每位工程師的生產力提高 200%，甚至可能導致「軟體工程師」這一頭銜消失，取而代之的是「建構者」。
- AI 正在「攻克」程式設計難題： 程式設計本身正在被 AI 大規模解決。AI 不僅能編寫程式碼，還能審閱回饋、查看 Bug 報告，甚至開始主動提出修復 Bug 和發布新功能的想法，正逐漸演變成開發團隊的「同事」。
- 「潛在需求」驅動產品進化： AI 產品（如 Claude Code 和 Cowork）的成功很大程度上源於「潛在需求」原則。即觀察使用者如何以非預期的方式使用工具，然後建構更易於實現這些需求的產品。例如，人們將 Claude Code 用於非技術性任務，從而催生了 Cowork。
- AI 正在重塑非技術性工作： AI 的影響力將從工程領域擴展到產品經理、設計師、資料科學家等與電腦相關的工作。具備工具使用能力的 AI 智能體將成為下一個變革前沿，使非技術人員也能實現自動化操作。
- 未來的關鍵是通用性而非專業性： Boris 強調「苦澀的教訓」原則，即通用模型將始終優於專用模型。建構 AI 產品應著眼於未來，押注更通用的模型，而不是過度優化當前模型或添加僵化的工作流程。
- AI 推動創新的「民主化」： 正如印刷術降低了知識獲取的門檻，AI 也在做類似的事情。未來人人都能程式設計，這將釋放巨大的創造力，但也會帶來巨大的顛覆和陣痛，需要社會共同應對。
- AI 安全性的多層機制： Anthropic 採用三層 AI 安全機制：底層的「對齊」和「機械可解釋性」（理解神經元工作原理），中間層的「評估」（實驗室環境測試），以及頂層的「早期發布」以觀察其在實際應用中的行為。
- 擁抱 AI，成為「通才」： 在 AI 時代取得成功的秘訣在於擁抱 AI 工具，成為好奇心強、跨學科的通才，能夠思考宏觀問題，而不僅僅局限於工程細節。
- 無限 Token 的實驗價值： 鼓勵給工程師提供「無限 Token」，讓他們自由嘗試瘋狂的想法。因為在小規模實驗中，AI 的使用成本相對較低，而其潛力可能帶來革命性的突破。
內容簡介
Boris Cherny 是 Anthropic 的 Claude Code 創作者兼負責人。這一工具在一年前還只是一個基於終端機的簡單原型，如今卻改變了軟體工程的角色，並正日益重塑所有的專業工作。
我們討論了：
- Claude Code 如何從一個快速建構的黑客專案發展到佔據 GitHub 公開提交量的 4%，且日活躍使用者在上個月翻了一番。
- 推動 Claude Code 成功的反直覺產品原則。
- 為什麼 Boris 認為程式設計問題已經被「解決」了。
- 塑造了 Claude Code 和 Cowork 的「潛在需求」。
- 充分利用 Claude Code 和 Cowork 的實用技巧。
- 為什麼讓團隊預算緊缺但提供「無限 Token」能透過 AI 產品帶來更好的結果。
- 為什麼 Boris 短暫離開 Anthropic 加入 Cursor，卻在兩週後回歸。
- Boris 與每一位新團隊成員分享的三個原則。
訪談全文
Boris 與 Claude Code 簡介
Boris Cherny： 我的程式碼 100% 是由 Claude Code 編寫的。自去年 11 月以來，我就沒有親手改過一行程式碼。每天我都會提交 20 到 30 個 Pull Request。所以，目前我有大約五個智能體同時執行。
主持人： 我們在錄音了嗎？好的。你懷念親手寫程式碼的感覺嗎？
Boris Cherny： 我從未像現在這樣享受程式設計，因為我不再需要處理那些瑣碎的細枝末節。每一位工程師的生產力都因此提高了 200%。
總會有人問：「我應該學習程式設計嗎？」再過一兩年，這就不重要了。因為程式設計問題在很大程度上已經被解決了。
我設想未來是一個人人都能程式設計的世界。任何人都可以隨時建構軟體。編寫軟體的下一個巨變是什麼？Claude 正開始主動提出想法。它會審閱回饋、查看 Bug 報告、分析用於修復 Bug 和發布新功能的遙測資料。它越來越像是一個同事，甚至是一群同事。
主持人： 產品經理們聽到這話恐怕要冒冷汗了。
Boris Cherny： 他們確實該緊張了。我認為到今年年底，每個人都會成為產品經理，同時也都能程式設計。「軟體工程師」這個頭銜將開始消失，取而代之的是「建構者」。對很多人來說，這個轉型過程會很痛苦。
主持人： 今天我的嘉賓是 Anthropic 的 Claude Code 負責人 Boris Cherny。很難用言語形容 Claude Code 對世界產生了多大的影響。本集節目播出時，正值 Claude Code 發布一週年。在如此短的時間裡，它已經徹底改變了軟體工程師的工作方式。正如我們稍後會談到的，它現在也開始重塑科技領域許多其他職能的工作。
Claude Code 本身也是 Anthropic 去年整體成長的巨大推動力。公司剛剛為此融資了超過 35 億美元。正如 Boris 所言，Claude Code 的成長仍在加速，僅上個月，其日活躍使用者數就翻了一番。
Boris 本人也是一位非常有趣、有思想且極具深度的思考者。在這次交談中，我們驚喜地發現，我們竟然出生在烏克蘭的同一個城市，這太巧了，我之前對此一無所知。
Boris 為什麼短暫離開 Anthropic 加入 Cursor（以及是什麼讓他回歸）
主持人： Boris，非常感謝你來到節目，歡迎！我想從一個比較犀利的問題開始。大約六個月前，不知道大家是否記得，你實際上離開了 Anthropic 加入了 Cursor，但兩週後又回到了 Anthropic。當時到底發生了什麼？我好像從未聽過真實版本的故事。
Boris Cherny： 這確實是我職業生涯中最快的一次變動。我加入 Cursor 是因為我是該產品的忠實使用者。老實說，我見了他們的團隊，印象非常深刻。他們非常出色，正在建構很酷的東西，而且似乎比許多人更早地看到了 AI 編碼的未來。因此，打造一款好產品的想法當時讓我非常興奮。
但當我真正到了那裡，我開始意識到，我真正懷念的是 Anthropic 的使命。這也是我最初被吸引到 Anthropic 的原因。在加入 Anthropic 之前，我曾在大公司工作。後來我想去一家實驗室性質的機構，希望能親自參與塑造我們正在建構的這個瘋狂事物的未來。
Anthropic 最吸引我的是它的使命——一切為了安全。當你在 Anthropic 的走廊裡隨便找個人，問他們為什麼在這裡，答案永遠是「安全」。這種使命驅動的文化與我個人的價值觀高度契合。我意識到，這不僅是工作的動力，更是我快樂的泉源。
Claude Code 的一週年
我真的很懷念那種感覺。我發現，無論工作內容多麼令人興奮，無論產品多麼酷炫，都無法替代使命感帶來的滿足。 對我來說，這是一個非常明顯的訊號，我很快就意識到我缺失了這一塊。
主持人： 好的，讓我們順著這個話題回到 Anthropic 以及你在那裡所做的工作。這集播客將在 Claude Code 發布一週年之際播出，我想花點時間反思一下你所帶來的影響。最近 SemiAnalysis 發布了一份報告，我相信你肯定看過。報告顯示，現在 GitHub 上有 4% 的程式碼提交是由 Claude Code 編寫的，並預測到今年年底，這一比例將達到 GitHub 所有程式碼提交的五分之一。他們評論道：「就在我們眨眼之間，AI 吞噬了所有的軟體開發。」
就在我們錄音的今天，Spotify 發布了一個頭條新聞，稱他們最優秀的開發者自 12 月以來就沒有寫過一行程式碼，這都要歸功於 AI。越來越多的頂尖資深工程師，包括你，都在分享不再親自寫程式碼的事實——程式碼全是 AI 生成的，甚至很多人連看都不看了。這在很大程度上要歸功於你啟動的這個小專案，以及你的團隊在過去一年裡的擴展。我很想聽聽你對過去一年以及這些影響的反思。
Boris Cherny： 這些數字簡直令人難以置信。全球提交的程式碼中有 4% 來自 Claude Code，這完全超出了我的預期。正如你所說，這感覺僅僅是個開始。這些還只是公開的程式碼提交，如果算上私有儲存庫，我們認為比例會高得多。對我來說，最瘋狂的不是當前的絕對數字，而是成長的速度。Claude Code 的各項指標不僅在成長，而且是在加速成長。
當我剛開始做 Claude Code 時，它只是一個小專案。在 Anthropic 內部，我們普遍認為應該發布某種編碼產品。長期以來，Anthropic 建構安全通用人工智慧（AGI）的心智模型一直是：模型首先要精通程式設計，然後要擅長使用工具，最後要能夠駕馭電腦。 這大概就是我們長期以來的發展軌跡。
我最初加入的團隊叫 Anthropic Labs。Mike Krieger 和 Ben Mann 實際上是第二次重啟了這個團隊。團隊開發了一些非常棒的東西，包括 Claude Code、MCP（模型上下文協議）和桌面應用程式。你可以清晰地看到這個理念的萌芽：先是程式設計，然後是工具使用，最後是電腦操作。
這對 Anthropic 至關重要，核心原因在於安全性。人工智慧正變得越來越強大。在過去一年裡，至少對工程師而言，AI 不僅僅是編寫程式碼或充當對話夥伴，它實際上已經開始使用工具並在現實世界中採取行動。
Claude Code 的起源故事
透過 Computer Use（電腦操作功能），我們也開始看到這種轉變發生在非技術人員身上。對於許多使用對話式 AI 的人來說，這可能是他們第一次體驗到能夠實際執行操作的工具。它可以存取你的 Gmail、你的 Slack，並為你處理各種事務。它在這方面表現出色，且只會越來越好。
很長一段時間以來，Anthropic 內部一直有一種想要創造某種東西的感覺，但具體形態並不明確。因此，當我加入 Anthropic 時，我花了一個月的時間進行探索性開發，建構了許多奇特的原型。大多數都沒有發布，甚至離發布還很遠，但這只是為了探索模型能力的邊界。隨後，我又花了一個月時間研究後訓練，以便從研究角度深入理解它。老實說，作為工程師，想要把工作做好，你就必須深入理解你所建構層級之下的底層邏輯。
在傳統的工程工作中，如果你開發產品，你需要了解基礎設施、執行環境、虛擬機器、程式語言等依賴項。但在從事人工智慧工作時，你必須在一定程度上理解模型本身，才能勝任工作。
所以，我繞了一點路來做這件事，回來後便開始建構最終演變成 Claude Code 的原型。
關於它的第一個版本，我還保留著那個夏天錄製的演示影片，當時它被稱為 Claude CLI。我只是展示了它如何使用一些工具。令我感到最不可思議的是，我只是給了它一個 Bash 工具，它就能利用這個工具編寫程式碼。當我問它「我正在聽什麼音樂」時，它竟然真的給出了答案。這簡直太神奇了，對吧？因為我並未指示模型去使用特定工具完成任務，也沒告訴它「去做任何事」。模型在獲得工具後，自行想出了如何利用它來回答我的問題——實際上，我當時甚至不確定它能否回答「我正在聽什麼音樂」這個問題。
於是我開始了更多的原型開發。我寫了一篇文章並在內部發布，結果只收到了兩個讚。這基本上代表了當時大家的普遍反應。
因為在當時，人們一想到編碼工具，腦海中浮現的都是 IDE（整合開發環境），以及那些相當複雜的環境配置。沒人想過這東西能基於終端機執行。這在當時看來是一種奇怪的設計，而且最初也並非有意為之。
但我從一開始就把它建構在終端機裡，原因很簡單：最初幾個月只有我一個人在開發，這是最省力的建構方式。對我來說，這是一個相當重要的產品教訓：資源受限在初期反而是一種優勢，它能幫你聚焦。
後來當我們考慮開發其他形式時，決定在一段時間內堅持使用終端機。最大的原因是模型進化得太快了，我們覺得任何圖形化介面（GUI）都跟不上它的步伐。老實說，這也是我一直在思考的問題：「我們到底該建構什麼？」在過去的一年裡，Claude Code 佔據了我全部的思考。深夜裡我常想：模型還在不斷進步，我們該怎麼辦？如何才能跟上？老實說，終端機成了我唯一的解法。
結果證明這條路走通了。發布後，它很快在 Anthropic 內部流行起來，日活躍使用者（DAU）直線上升。其實在發布前，Ben Mann 就建議我製作一張日活圖表。我當時還問：「現在是不是太早了？」他說：「不，就現在。」結果那張圖表的曲線幾乎立刻就拉出了一條直線。
二月份，我們將其對外發布。其實大家可能不太記得了，Claude Code 最初發布時並非一炮而紅。確實有一批早期採用者立刻理解了它的價值，但實際上市場花了幾個月的時間才真正理解這到底是什麼。還是那句話，它太與眾不同了。
回過頭看，Claude Code 之所以成功，部分原因在於「潛在需求」——我們將工具帶到了人們所在的地方，讓現有的工作流程變得更順暢。但因為它執行在終端機裡，這有點出人意料，甚至讓人感到有些陌生。你必須保持開放的心態去學習使用它。
當然，現在 Claude Code 已經可以在 iOS 和 Android 的 Claude 應用程式、桌面應用程式、網站、IDE 擴充功能以及 Slack 和 GitHub 中使用了——它滲透到了工程師所在的每一個角落，變得更加熟悉。但這並不是它的起點。
起初，這個東西「能用」就已經是個驚喜了。隨著團隊壯大、產品成熟，它對使用者越來越有價值。從世界各地的小型新創公司到知名大廠都在使用並回饋，這真是一次非常謙卑的經歷。我們不斷從使用者那裡學習。最令人興奮的是，其實沒人確切知道該怎麼做，我們都在與使用者一同摸索。 使用者的回饋最能說明這一點，我已經被驚喜過無數次了。
AI 正以何種速度重塑軟體開發
主持人： 當今世界的變化速度簡直不可思議。你們一年前發布了這個產品，雖然那不是人們第一次用 AI 寫程式碼，但短短一年間，整個軟體工程行業已經發生了翻天覆地的變化。比如，之前到處都是關於「AI 將 100% 接管程式碼編寫」的預測，當時大家都覺得是天方夜譚，說「你在開玩笑嗎？」而現在，正如所言，這一切正在發生。這種發展和變化的速度太快了。
Boris Cherny： 是的，速度極快。回想 2025 年 5 月，在 Anthropic 舉辦的首屆開發者大會「Code with Claude」上，我做了一個簡短演講。在問答環節，有人問我年底的預測是什麼。我當時的回答是：到今年年底，你可能就不再需要 IDE 來寫程式碼了，我們會開始看到工程師放棄這種工作方式。 我記得當時全場觀眾都倒吸了一口氣。
實驗精神：AI 創新的核心
這聽起來是個瘋狂的預測。但在 Anthropic，我們的思維方式是指數級的，這深植於我們的基因之中。我們的聯合創始人中有三位是《縮放定律》論文的前三作者。所以我們確實習慣於指數級思考。如果你觀察當時 Claude 編寫程式碼比例的指數成長曲線，只要順著趨勢線畫下去，就很明顯我們將在年底突破 100%——即使在這當時完全反直覺。我所做的只是順著那條線推演。果然，到了 11 月，對我個人而言，那個時刻真的到來了，並一直持續至今。我們也看到許多客戶出現了類似的情況。
主持人： 你剛才分享的探索過程——那種「只是隨便玩玩，看看會發生什麼」的心態，我覺得非常有趣。這在 OpenAI 的故事裡也經常出現，比如 Peter 只是在嘗試，然後就促成了某些突破。感覺這似乎是 AI 領域許多重大創新的核心要素：人們只是坐下來嘗試各種方法，將模型推向比其他人更遠的地方。
Boris Cherny： 這就是創新的本質，你無法強求。創新沒有既定的路線圖，你只需要給人們空間。 你需要給他們「心理安全感」，讓他們知道失敗是可以接受的。80% 的想法可能都不靠譜，這沒關係。
當然，你也需要有一定的當責機制。如果想法行不通，就及時止損，轉向下一個，而不是無底洞般地投入。
在 Claude Code 早期，我完全不知道這東西會有用。即使在 2 月份發布時，它可能只幫我寫了 20% 的程式碼。哪怕到 5 月份，可能也只有 30%，我當時主要還是用 Cursor 寫程式碼。直到 11 月份才突破 100%。所以這確實花了一段時間。
Boris 的現狀：100% 程式碼由 AI 撰寫
但從最早的時候開始，我就覺得我抓住了某種訣竅。幾乎每個晚上和週末我都在搗鼓它——幸運的是，我的妻子非常支持我。我隱約感覺抓住了某種東西，儘管當時並不清晰。有時候，你發現了一根線頭，就必須順著它拽下去。
主持人： 也就是說，你現在 100% 的程式碼都是由 Claude Code 編寫的，對嗎？這就是你目前的編碼狀態？
Boris Cherny： 是的，我 100% 的程式碼都由 Claude Code 編寫。我是一個相當多產的程式設計師，無論是在 Instagram 工作時，還是現在在 Anthropic，我都是產出最高的工程師之一。
主持人： 哇，即使作為負責人也如此？
Boris Cherny： 是的，我仍然寫大量程式碼。我每天大概會提交 10、20 甚至 30 個 Pull Request（PR）。每天如此。是的，這很瘋狂。所有程式碼 100% 由 Claude Code 編寫，從 11 月份之後，我就沒有手動編輯過一行程式碼。
下一個前沿
當然，我確實會看程式碼。我不認為我們已經到了可以完全放手不管的階段，尤其是在許多人執行程式的情況下，你必須確保它的正確性和安全性。在 Anthropic，Claude 會對所有程式碼進行自動審查，這覆蓋了 100% 的 Pull Requests。之後仍然有一層人工審查。我們需要這些檢查點，除非是那種純粹的原型程式碼，不會在生產環境中執行。
主持人： 那麼下一個前沿是什麼？現在你 100% 的程式碼都由 AI 編寫，這顯然是軟體工程的未來。這曾經是一個瘋狂的里程碑，現在感覺就像「當然了，世界本來就該這樣」。那麼，軟體編寫的下一個重大轉變是什麼？是你的團隊已經在進行的，還是你認為我們將朝哪個方向發展？
Boris Cherny： 我認為現在正在發生的一件事是，Claude 已經開始主動提出想法了。Claude 會查看回饋、Bug 報告、遙測資料等，然後開始提出修復 Bug 和發布新功能的建議。它開始變得有點像一個同事了。
第二件事是，我們開始拓展到純編碼之外的領域。我認為目前可以肯定地說，編碼在很大程度上已經是一個被解決的問題——至少對我所做的那類程式設計來說，Claude 完全可以勝任。所以現在我們開始思考：「接下來是什麼？還有什麼？」有很多工作是與編碼相關的。
我認為這種趨勢即將來臨，但也包括一些通用的任務。比如，我現在每天都使用 Claude 處理各種與編碼無關的事務，並讓它自動完成。例如，前几天我得支付一張停車罰單，我直接讓 Claude 去付了。我團隊的所有專案管理工作也都由 Claude 完成，它可以在電子表格之間同步資料，以及在 Slack、電子郵件等地方與人溝通。我認為下一個前沿不再是編碼本身。因為在我看來，編碼問題基本上已經解決了。未來幾個月，整個行業將見證：無論針對何種程式庫或技術棧，編碼工作都將變得越來越容易被解決。
主持人： 利用 AI 輔助構思工作內容的想法非常有趣。許多聽眾是產品經理，可能正為此焦慮。你是怎麼使用 Claude 的？僅僅是對話嗎？還是有什麼巧妙的方法利用它來構思建構內容？
Boris Cherny： 老實說，最簡單的辦法就是打開 Claude Code，讓它讀取某個 Slack 討論串。比如我們有一個專門收集 Claude Code 內部回饋的頻道。從最初發布甚至早在 2024 年內部測試時起，那裡就積累了海量的回饋。這可是無價之寶。
早期每當有人回饋，我會立刻修復，哪怕是一分鐘、五分鐘內解決。這種極致的快速回饋循環能極大地鼓勵人們提供更多意見。
這至關重要，因為它讓使用者感到被重視。通常如果你回饋後石沉大海，就不會再有下文了。但如果人們覺得自己的聲音被聽到了，他們就會願意貢獻力量，幫助改進產品。
現在我依然遵循這個原則，但大部分工作都由 Claude 代勞了。我只需讓它指向那個頻道，它就會說：「這裡有幾件事我能處理，已經提交了幾個 PR（拉取請求），要看看嗎？」我就說：「好。」
主持人： 你有沒有注意到 AI 在編碼能力上的顯著進步？這簡直是「聖杯」。目前軟體建構的基礎設施問題已經解決，程式碼審查成了新的瓶頸——到處都是待處理的 PR，誰來審查呢？現在的核心問題變成了人類需要思考建構什麼以及如何定優先順序。正如你所說，Claude Code 正是在這方面開始發揮作用。它的效能提升軌跡如何？比如像新版本在這些方面的表現？
Boris Cherny： 是的，進步非常大。部分原因是我們進行了針對編碼的特定訓練。顯然，它是世界上最好的編碼模型，而且還在不斷進化，目前的版本表現就非常出色。
有趣的是，許多非編碼方面的訓練也能很好地遷移。這種「遷移效應」意味著你教會模型做 X，它在 Y 方面也會做得更好。進步幅度簡直不可思議。
比如在 Anthropic，引入 Claude Code 的這一年裡，我們的工程團隊規模大概擴大了四倍。但以 PR 數量衡量的**每位工程師的生產力卻提高了 200%**。對於任何專注於開發者生產力領域的人來說，這個數字都堪稱驚人。
我之前在 Meta 工作時負責全公司的程式碼品質，涉及 Facebook、Instagram、WhatsApp 等龐大的程式庫。我們曾投入數百名工程師，耗時一年，往往只能將生產力提升幾個百分點。而現在看到這種成倍的成長，簡直令人難以置信。
快速創新的雙面刃
主持人： 同樣令人難以置信的是，這一切已經變得多麼常態化。AI 對軟體開發、產品建構乃至整個科技界帶來的前所未有的變化，我們很容易就習以為常。但意識到這一切是多麼「瘋狂」，這一點至關重要。
Boris Cherny： 我也需要偶爾提醒自己。模型更新太快也有弊端，導致我也時常固守舊的思維方式。我發現團隊裡的新人或應屆畢業生，他們看待事物的方式甚至比我更具「AGI（通用人工智慧）導向」。
比如幾個月前，我遇到了一個棘手的記憶體洩漏問題——Claude Code 的記憶體佔用不斷飆升直至崩潰。這是一個經典的工程問題，大多數工程師都偵錯過無數次。傳統做法是取得記憶體快照，放入偵錯工具，搭配特定工具分析。
正當我埋頭研究堆疊追蹤時，團隊裡一位新工程師直接問 Claude：「嘿，好像有記憶體洩漏，你能找出原因嗎？」Claude Code 隨後執行了與我完全相同的任務：取得快照，編寫即時程式進行分析。它找到問題並提交修復 PR 的速度，比我還在手動排查時快得多。
Claude Code 團隊的核心原則
這件事提醒我們要跟上時代，不要停留在過去。模型在不斷進化，不再是以前的版本了，新模型需要我們徹底轉變思維方式。
主持人： 我聽說你們有一些具體的團隊指導原則。其中一條似乎是：「有什麼比自己動手更棒的嗎？那就是讓 Claude 來做。」這聽起來和你剛才說的記憶體洩漏案例如出一轍——你幾乎忘了這個原則，即「先看看 Claude 能不能搞定」。
Boris Cherny： 還有一點很有趣：當你讓團隊處於稍微「資源緊缺」的狀態時，人們就被迫去創新。我們經常看到，哪怕專案只派一名工程師，他們也能快速交付，因為這是發自內心的驅動力——如果你有個好主意，你會想方設法把它實現，這不需要強迫。
所以，如果你擁有 Claude，就可以用它自動化大量工作。因此我們的原則之一就是：保持適度的「資源緊缺」。
另一個原則是鼓勵快速行動。如果今天能做完，就絕不拖到明天。這一點在早期只有我一個人時至關重要，因為速度是我們唯一的優勢。如今，要想快，最好的辦法就是讓 Claude 做更多事。
主持人： 「資源緊缺」這個觀點很有意思。通常人們認為 AI 會讓你不再需要那麼多工程師。但你的意思似乎是：與其說 AI 讓你更快，不如說投入更少的人力，反而能迫使你從 AI 工具中挖掘更多價值。
Boris Cherny： 對，優秀的工程師只要獲得授權，總能找到解決辦法。我常給 CTO 們的建議是：起步階段不要試圖優化成本，盡可能給工程師提供無限的 Token。
在 Anthropic，我們每個人都有海量的 Token 額度。我們開始看到這在一些公司已成為一種福利——入職即享「無限 Token」。
為什麼要給工程師「無限 Token」
我強烈建議這樣做，因為這能解放人們去嘗試那些看似瘋狂的想法。如果想法可行，再考慮如何規模化和優化成本（比如改用 Haiku 或 Sonnet 模型）。但在初期，必須投入大量 Token，給工程師驗證想法的自由。
主持人： 也就是說，對 Token 成本要寬容。最具創新性的想法往往來自於有人將其推向極致，探索邊界。
Boris Cherny： 沒錯。實際上，小規模實驗的 Token 成本相對於工程師薪資或營運成本來說微不足道。只有當專案規模化後，成本才會變得可觀，那時才是優化的時機。不要過早優化。
主持人： 你提到過 Token 成本可能比薪水還高的情況？你認為這會成為一種趨勢嗎？
當 Token 成本超過工程師薪水
Boris Cherny： 在 Anthropic，我們已經看到有個別工程師每月的 Token 花費高達數十萬美元。這種趨勢確實開始出現了。
主持人： 你懷念寫程式碼嗎？作為一名軟體工程師卻不再親自編碼，你會感到失落嗎？
Boris Cherny： 有趣的是，我學習工程學的過程非常注重實踐。我學它的初衷就是為了能親手建構事物。我是一名自學成才的工程師——我在學校主修經濟學，並非電腦科學。但我很早就開始自學工程，中學時就開始程式設計了。
從一開始，程式設計對我就非常實用。我學會寫程式碼甚至是為了在數學考試中作弊。那是我做的第一件事：在我們的圖形計算機（TI-83 Plus）上編寫程式。沒錯，我把答案編進了程式裡。
等到第二年的數學考試，題目太難了，我也無法預知題目把答案存進去。於是我不得不寫一個小型的通用求解器來處理代數題。後來我發現可以用數據線把程式分享給班上其他人，結果全班都拿了 A。當然，後來我們被抓了，老師嚴令禁止。但從那時起，我就意識到：程式設計是建構事物的手段，而非目的本身。
後來，我曾一度沉迷於「程式設計之美」。我寫了一本關於 TypeScript 的書，還組織了當時世界上最大的 TypeScript 聚會，純粹是因為我愛上了這門語言。我也深入研究了函數式程式設計。
我認為很多程式設計師容易因此分心。我也曾覺得程式設計、特別是函數式程式設計和型別系統，具有一種內在美。就像解決複雜數學難題時那種特殊的興奮感，當你平衡好型別定義，或者寫出優雅的程式碼時，也會有同樣的感受。
但那並不是最終目的。對我而言，程式碼終究是工具，是實現目標的手段。
當然，並非每個人都這麼想。例如我們團隊的工程師 Lena，她週末還會手寫 C# 程式碼，純粹因為享受其中的樂趣。每個人都不同。我認為，即使領域在變，總有一方天地留給人們去享受程式設計藝術，去打磨手工藝。
主持人： 你是否擔心作為工程師的技能會退化？還是認為這只是順應了發展的必然？
Boris Cherny： 我認為這是發展的必然，我個人並不擔心。對我來說，程式設計是一個連續演進的過程。
回看歷史，現代軟體編寫方式（執行在虛擬機器上）大約始於 20 世紀 60 年代，已有 60 年歷史。在此之前是打孔卡，再之前是撥動開關，更早是純硬體。而在那之前，所謂的「運算」就是一屋子人拿著紙筆進行數學運算。
程式設計一直在變。雖然理解底層的原理能讓你成為更好的工程師，這在未來一兩年內可能依然成立，但我認為很快它就會變得不再重要。它將像今天的組合語言一樣，隱匿在程式設計師的視野之外。
情感上，我習慣了不斷學習新事物。作為程式設計師，面對新框架、新語言是家常便飯。但也並非所有人都能適應。有些人可能會感到強烈的失落、懷舊，甚至是對技能退化的焦慮。
主持人： 不知道你是否看到伊隆·馬斯克的觀點：為什麼 AI 不能直接生成二進位程式碼？歸根結底，如果 AI 能做到，中間這些程式設計抽象層還有什麼存在的意義？
Boris Cherny： 是的，這是個好問題。理論上，它完全可以做到。
AI 影響如同印刷術革命
主持人： 我常聽到人們問：「我應該學程式設計嗎？學校裡還應該教程式設計嗎？」聽你的意思，似乎一兩年後，這就變得不太必要了？
Boris Cherny： 我的看法是：今天使用程式碼或 AI 智能體的人，仍需理解底層原理。但一兩年後，這確實不再重要。
我們需要將此事置於歷史背景下考量。最貼切的類比，莫過於印刷術。
15 世紀中葉的歐洲，識字率極低，僅約 1%。抄寫員壟斷了讀寫工作，受僱於往往不識字的權貴。古騰堡印刷術問世後的 50 年裡，印刷品數量超過了此前一千年的總和，而成本下降了約 100 倍。
識字率的提升需要時間，因為學習讀寫很難，需要教育體系和閒暇時間，不能整天被農活捆綁。但在隨後的 200 年裡，全球識字率最終攀升至約 70%。
我們可能正在經歷類似的轉變。有一個關於 15 世紀抄寫員的歷史軼事很有趣：他對印刷術感到興奮，因為他其實討厭枯燥的抄寫工作。他真正熱愛的是繪製插圖和書籍裝幀。印刷術讓他得以從繁瑣中解脫，專注於更具藝術感的工藝環節。
作為工程師，我感同身受。我不再需要處理繁瑣的編碼任務——比如管理 Git 和各種工具配置，那些細節耗時且並不令人愉悅。真正的樂趣在於構想我們要建構什麼。 與使用者互動、設計大型系統、思考未來架構、與團隊協作——這才是現在我可以投入更多精力的地方。
主持人： 令人驚嘆的是，您建構的工具讓非技術人員也能做到這一點。我之前做些小專案，遇到困難只要說「幫我解決這個問題」，AI 就能搞定。回想我早年做工程師的那 10 年，大量時間花在處理函式庫和依賴項上，遇到問題只能去 Stack Overflow 翻找。而現在，AI 直接給出步驟「1、2、3、4」，問題就解決了。
AI 將首先顛覆哪些角色？
Boris Cherny： 沒錯。今天我還和一位工程師聊天，他花一個月用 Go 語言寫了個運作良好的服務。但他告訴我：「其實我還是不太懂 Go。」這種情況會越來越多見。只要你能確認它運作正確且高效，就不再需要深究每一處實現細節。
主持人： 軟體工程師的工作已經發生了翻天覆地的變化。您認為在技術領域（如產品經理、設計師）甚至非技術領域，下一個最受 AI 衝擊的角色會是什麼？
Boris Cherny： 我認為工程領域的相鄰崗位（如產品經理、設計、資料科學）將首當其衝。實際上，這種影響將擴展到幾乎任何依賴電腦完成的工作，因為模型能力正日益增強。
協作型產品只是第一步。它將 AI 帶給了從未接觸過它的人群。回想一年前，工程界還沒人真正理解「智能體」，但現在，這已成為我們的工作常態。
觀察現在的非技術或半技術工作，人們主要還在使用對話式 AI（聊天機器人），尚未真正觸及「智能體」。雖然「智能體」這個詞現在被濫用，但它有具體的技術含義：一種能夠使用工具的大型語言模型（LLM）。 它不只是陪聊，而是能實際行動並與系統互動——操作 Google Docs、發送電子郵件、在電腦上執行命令。凡是以此類方式使用電腦工具的工作，都將是下一個被改變的領域。
這既是社會問題，也是行業問題。這也是我在 Anthropic 從事這項工作感到緊迫的原因。我們非常嚴肅地對待此事，聘請了經濟學家、政策專家和社會影響專家進行深入探討。社會需要弄清楚如何應對，因為這不該僅由我們一家公司來決定。
主持人： 您提到了就業問題。有個概念叫「傑文斯悖論」，意指效率提高反而可能增加對資源（或人力）的需求。在 AI 深度介入工程領域的當下，您的團隊招聘情況如何？
Boris Cherny： 實際上，我們的 Claude Code 團隊正在積極招聘。若感興趣，歡迎查看 Anthropic 的招聘頁面。
就個人而言，我從未像今天這樣享受程式設計，因為我從瑣事中解脫了。許多客戶也有同感，他們喜歡 Claude Code，因為它讓編碼重新變得快樂。但很難預測事情最終會如何演變，所以我傾向於借鑑歷史。印刷機的出現是一個絕佳的類比：這項技術曾經只掌握在少數人手中（比如讀寫能力），後來變得人人觸手可及。這本質上是一種民主化。若非如此，文藝復興絕無可能發生——畢竟，文藝復興的核心在於知識的傳播和思想的交流。當時沒有電話，也沒有網路，全靠書面記錄。
所以，關鍵在於「這會通向何方」。我對此持樂觀態度，甚至感到無比興奮。如果當年沒有發明印刷機，我們今天就不可能在這裡交談，麥克風不會存在，周圍的一切都不會存在。沒有這種技術，根本無法協調如此大規模的人類協作。
我設想幾年後的世界，人人皆可程式設計。這將釋放怎樣的潛能？任何人都能隨時建構軟體。正如 15 世紀的人無法想像我們現在的生活，我們現在也難以預見那時的圖景。
在 AI 時代取得成功的秘訣
但我也認為，過渡期將充滿顛覆，甚至讓許多人感到痛苦。再次強調，作為一個社會，我們必須展開對話，共同尋找出路。
主持人： 既然我們即將步入這個瘋狂的動盪期，對於那些希望取得成功的人，你有什麼建議？是多玩玩 AI 工具，精通最新技術嗎？還有什麼能幫助人們保持領先地位？
Boris Cherny： 對，最基本的就是去嘗試、去了解這些工具，不要害怕，直接上手探索它們最前沿的應用。
其次，盡量讓自己成為一名通才。 在學校裡，很多電腦專業的學生只學程式設計，忽略了其他領域，比如系統架構。但我身邊最高效的工程師、產品經理，都具備跨學科能力。以 Claude Code 團隊為例，我們全員都會寫程式碼——產品經理、工程經理、設計師、財務人員，甚至資料科學家，每個人都會寫程式碼。
再看具體的工程師，最出色的人往往也是多面手：既懂產品又懂基礎設施的混合型工程師；擁有出色設計感的工程產品經理；或者是對業務有深刻理解，並能以此決定技術方向的工程師；又或者是熱愛與使用者交流，能真正理解使用者需求以確定下一步方向的工程師。
所以我認為，未來幾年獲益最大的不僅僅是那些精通 AI 工具的原生代，更是那些充滿好奇心、能夠跨越學科邊界的通才。他們不僅思考工程問題，更能著眼於全局，解決更宏觀的難題。
主持人： 你認為工程、設計、產品管理這三個獨立學科的劃分仍然有效嗎？儘管大家現在都在寫程式碼、貢獻想法，你覺得這些角色會一直存在嗎？
Boris Cherny： 長期來看很難說，但短期內它們會持續存在。不過我們開始看到角色間出現了 50% 的重疊，很多人實際上在做同樣的事情。雖然有些人仍有專長——比如我寫程式碼多一些，而其他的 PM 則更多負責協調、規劃或預測——但界限正在模糊。
我認為未來，也許到年底，我們會看到這些界限變得更加模糊。「軟體工程師」這個頭銜可能會逐漸消失，取而代之的是「建構者」。也許每個人都會成為既寫程式碼又懂產品的產品經理。
投票：AI 讓哪個角色的工作更有趣了？
主持人： 你提到現在更喜歡寫程式碼了。實際上我在 Twitter 上針對不同角色做了一個關於「使用 AI 工具後是否更享受工作」的調查。
結果很有趣：70% 的工程師和產品經理（PM）表示更享受工作，只有約 10% 表示不享受。然而，設計師中只有 55% 表示更享受，卻有 20% 表示更不享受。我覺得這個差異非常有意思。
Boris Cherny： 這太有趣了。我很想和這些人聊聊，深入了解背後的原因。你有後續跟進嗎？
主持人： 有幾個人回覆了，我們正在進行後續採訪，連結會放在節目筆記裡。但這確實受很多因素影響。那些表示不享受的設計師並沒有分享太多具體原因，所以我很好奇發生了什麼。
Boris Cherny： 在 Anthropic，我有不同的體會。我們的團隊技術背景很強，招聘時就很看重這一點。即使是非技術崗位，也要經歷很多技術面試。
我們的設計師也會寫程式碼。據我觀察，他們很喜歡這一點，因為現在不必事事去麻煩工程師，自己就能動手寫程式碼解決問題。甚至一些以前不寫程式碼的設計師也開始嘗試了。這對他們來說很棒，因為賦予了他們獨立解決問題的能力。
但我很想聽聽更多人的經歷，因為我相信不同公司的情況肯定不盡相同。
產品開發中的潛在需求原則
主持人： 沒錯。如果你正在聽這個節目，並且發現工作變得更無趣了，請留言告訴我們。因為大多數回饋都表明工作變得更有趣了（70% 的 PM 和工程師），如果你不在此列，也許哪裡出了問題。
Boris Cherny： 是的。我們也觀察到人們使用的工具不同。例如，我們的設計師更多使用 Claude 桌面應用程式來寫程式碼。
你只需下載桌面應用，裡面有一個就在「協作」旁邊的「程式碼」標籤頁。它本質上擁有 Claude Code 的全部功能，是一個強大的代理。這樣你就不需要打開一堆終端機視窗，操作更符合非工程師的習慣。
最重要的是，你可以同時執行任意數量的 Claude 會話，我們稱之為「Multi-Claude」（多 Claude）。
這其實是關於如何把產品帶到使用者面前。你不想強迫使用者改變工作流或付出額外的學習成本。如果能讓他們現有的操作變得更容易，那就是一個更好的產品。這觸及了產品開發中最核心的原則——潛在需求原則。
主持人： 能詳細講講嗎？因為我正想讓你解釋這個原則是什麼，以及當你解鎖這種潛在需求時會發生什麼。
Boris Cherny： 潛在需求是指：如果使用者以一種非預期的方式「破解」或使用你的產品來達成某種目的，這實際上為你指明了產品下一步的演進方向。 Facebook Marketplace 的創始經理 Fiona 經常提到這個例子。
Facebook Marketplace 的誕生源於 2016 年左右的一個觀察：Facebook 群組裡竟然有 40% 的帖子都是買賣資訊。這太驚人了。使用者正在「濫用」群組功能來進行交易。這不是安全意義上的濫用，而是說並沒有人為此設計這項功能，但使用者自己找到了辦法，因為它太有用了。
顯然，如果你建構一個更好的產品來專門服務買賣需求，使用者會喜歡的。Marketplace 的成功是顯而易見的。第一步是買賣群組，第二步就是 Marketplace。
Facebook Dating 的誕生也基於類似的洞察。如果你查看 Facebook 上的個人資料瀏覽量，會發現 60% 的瀏覽來自非好友關係的異性。這就像一種傳統的約會模式，人們只是在互相「窺探」。所以，建構一個專門的產品可能會奏效。
我認為潛在需求的概念非常強大。例如，Cowork 的誕生也源於此。我們注意到，過去半年裡，很多使用 Claude Code 的人並不是用它來寫程式碼。有人用它在 Twitter 上種番茄，有人用來分析基因組，有人用來從損壞的硬碟中恢復婚禮照片，還有人用來分析 MRI 圖像。存在各種各樣完全不相關的用例。這表明，人們即使費勁使用終端機也要做這些事。也許我們應該為他們專門建構一個產品。我們其實很早就留意到了這一點。大概在去年五月，我走進辦公室，看到我們的資料科學家 Brendan 的電腦上開著 Claude Code。他當時只是打開了一個終端機。我很驚訝，問他：「Brendan，你在幹嘛？你竟然學會了用終端機？要知道，這是非常工程化的工具，因為太底層、太繁瑣，甚至很多工程師都不愛用。」
但他不僅學會了，還下載了 Node.js 和 Claude Code，直接在終端機裡進行 SQL 分析。這太瘋狂了。結果隔週，所有的資料科學家都在做同樣的事情。
當你看到人們以這種「破解」產品的方式，用非預期的方法來完成對他們有益的工作時，這強烈暗示你應該去建構這樣的產品——人們會喜歡它，因為它有明確的用途。我認為「潛在需求」現在有第二個有趣的維度。
傳統的理解是：觀察人在做什麼，讓他們的工作變簡單，為他們賦能。而我近六個月體會到的現代理解略有不同：它是關於觀察「模型」試圖做什麼，並讓這件事變得更容易。
當我們開始建構 Claude Code 時，人們設計 LLM（大型語言模型）應用的主流方式是把模型「關在盒子裡」。他們會說：「我想建構這個應用，讓它完成這個任務。模型，你只負責其中一個組件，透過這些 API 和工具進行互動。」
對於 Claude Code，我們反其道而行之。我們主張：產品即模型。我們要把它展現出來，只在周圍搭建最少的腳手架，給它最精簡的工具集，讓它能夠做它需要做的事。它可以自主決定執行哪些工具以及執行順序。
Cowork 如何在短短 10 天內建成
這很大程度上是基於「模型想要做什麼」這一潛在需求。在研究中，我們稱之為「分布內」。你要觀察模型的行為。用產品術語來說，這和「潛在需求」是同一個概念，只是應用對象變成了模型。
主持人： 你提到了 Cowork。記得最初發布時，你說團隊僅用了 10 天就完成了，這太不可思議了。發布後很快就有數百萬人使用。像這樣的產品能在 10 天內建成，除了它是用 Claude Code 建構的之外，背後還有什麼故事嗎？
Boris Cherny： 是的，這很有趣。Claude Code 發布初期並沒有立刻爆紅。它的熱度是隨時間積累的，經歷了幾個轉折點。比如 Claude 3 Opus 的發布讓它真正起飛了。到了十一月，成長曲線變得非常陡峭。但在最初幾個月，很多人並不知道怎麼用它，也不知道它的用途，當時模型也不夠完美。
相比之下，Cowork 一發布就火了，熱度遠超早期的 Claude Code。這很大程度上要歸功於 Felix、Sam、Jenny 以及整個強大的團隊。Cowork 的誕生同樣源於那種潛在需求——我們看到人們用 Claude Code 做非技術性的事情，於是試圖搞清楚該怎麼應對。
團隊探索了幾個月，嘗試了各種方案。最後有人提議：「如果我們把 Claude Code 放進桌面應用程式裡會怎樣？」這招奏效了。於是他們在 10 天內，完全使用 Claude Code 建構出了 Cowork。
Cowork 其實擁有一套非常複雜的安全系統，本質上是為了確保模型行為正確、不偏離軌道的保護措施。例如，我們內建了一個完整的虛擬機器，所有這些程式碼都是 Claude Code 編寫的。我們要考慮的是：「如何讓它對非工程師使用者來說既安全又自主？」這個完全用 Claude Code 實現的過程，大約只花了 10 天。
Anthropic 的三層 AI 安全機制
我們發布得很早，它在細節上還很粗糙。但這正是我們學習的方式——無論是產品還是安全層面，我們必須比預期更早發布，這樣才能獲得回饋，與使用者交流，真正了解人們想要什麼。這將決定產品未來的演進方向。
主持人： 這非常有趣且獨特。大家常說「盡早發布，從使用者回饋中迭代」，但鑑於很難預知 AI 的能力以及人們會如何使用它，這反而成了盡早發布的獨特理由。正如你所說，這有助於發現那些我們尚不了解的「潛在需求」，所以儘管推出去吧。
Boris Cherny： 對，人們到底會用它做什麼？對於 Anthropic 這樣的安全實驗室來說，另一個維度就是安全。研究模型安全有很多不同方式，大致分為三層：
最底層是「對齊」和「機械可解釋性」。 我們在訓練模型時要確保其安全。現在我們有相當先進的技術來追蹤和理解神經元內部的活動。例如，如果有一個與「欺騙」相關的神經元，我們能監控它的啟動情況。這就是最底層的對齊和機械可解釋性。
第二層是「評估」。 這本質上是實驗室環境，模型就像在培養皿中一樣。我們將它置於合成場景中，測試它是否合規、安全。
第三層則是觀察模型在現實世界中的行為。 隨著模型日益複雜，這一點至關重要，因為模型可能在前兩層表現良好，但在第三層翻車。我們很早就發布了 Claude Code，正是為了研究安全性。我們在內部使用了大概四五個月才對外發布，因為當時它是第一批大型智能體，甚至是第一個被廣泛使用的編碼智能體，我們不確定它是否安全。我們在內部做了大量研究，直到覺得可以了才發布。即使那樣，我們在對齊和安全方面學到的經驗，也都反哺回了模型和產品中。
Cowork 的情況也類似。模型處於新環境中，作為代理執行非工程任務。它在內部測試和評估中表現良好，但在現實世界是否安全？這就是我們盡早發布並稱之為「研究預覽」的原因。這是確保持續改進、讓模型長期符合要求並做正確之事的唯一途徑。
主持人： 這是一個競爭激烈、節奏極快的瘋狂領域。同時，人們又擔心某種「超級智慧」會失控造成破壞。找到平衡點一定極難。
據我理解，你們透過這三個層面來處理安全問題：觀察模型的思考方式、透過評估測試模型是否作惡、以及盡早發布。關於第一個層面（機械可解釋性），我想聽聽更多細節。你們似乎擁有能窺探模型內部、觀察其思考過程和走向的可觀測性工具，這太不可思議了。
Boris Cherny： 是的，你應該邀請 Chris Olah 上你的播客，他是該領域的行業專家，開創了「機械可解釋性」領域。核心思想很簡單：就像人類大腦是一堆相互連接的神經元一樣，我們可以從機械層面研究大腦，了解神經元的功能。
令人驚訝的是，這在很大程度上也適用於模型。雖然模型神經元與生物神經元不同，但表現有很多相似之處。我們因此學到了很多：概念是如何編碼的、模型如何規劃、如何進行超前思考。以前我們不確定模型是否只是在預測下一個詞，現在有強有力的證據表明，它在做更深層的事情。
隨著模型變大，結構變得相當複雜。不再是一個神經元對應一個概念，而是一個神經元可能對應十幾個概念，如果它與其他神經元一起被啟動，這被稱為「疊加」。這也是我們一直在探索的領域。
Anthropic 存在的理由，就是以一種對世界安全且有益的方式推動這一領域的發展。這也是大家聚集在這裡的原因。因此，我們將許多工作開源並公開發布，希望能激勵其他實驗室同樣採取安全的方式。
AI 代理不工作時的焦慮感
以 Claude Code 為例，我們在發布時開源了一個沙盒。這是一種安全邊界，確保代理無法存取你系統上的所有內容。這個沙盒適用於任何代理，不僅僅是 Claude Code。這和之前提到的「競賽」原理一樣：我們希望讓其他人也能更容易地實現安全。這就是我們推動行業正向發展的槓桿。
主持人： 太棒了。我絕對想花更多時間探討這點，也會跟進這個建議。我在這個領域觀察到，工程師、產品經理以及其他與 Agent（智能體）協作的人，當 Agent 停止工作時會產生焦慮感。感覺就像是：「天哪，這裡有個問題需要我解決」或者「它卡住了」，又或者覺得「我正在喪失生產力」。感覺像是必須立刻醒來讓它重新執行。你有這種感覺嗎？你的團隊有嗎？你認為這是一個值得關注和思考的問題嗎？
Boris Cherny： 我總有一堆 Agent 在執行。目前我有五個在跑。任何時候，我醒來都會啟動一批。
我醒來第一件事就是想：「我得檢查一下這東西。」所以我打開手機上的 Claude iOS 應用程式，查看程式碼標籤頁和 Agent 狀態等。因為昨天我寫了一些程式碼，當時心想：「等一下，我這樣做對嗎？」有點猶豫，但結果確實是對的。現在做這些太容易了。所以我也說不好，也許確實有一點點焦慮。
我個人並沒有強烈感受到，因為我的 Agent 始終在執行。而且我不再局限於終端機了。現在大約三分之一的程式碼在終端機裡完成，三分之一使用桌面應用程式，還有三分之一透過 iOS 應用程式完成。這太令人驚訝了，因為我完全沒想到這會成為我的編碼方式，即使是展望 2026 年時也沒想到。
主持人： 有意思的是你仍然稱之為「編碼」，儘管你只是在與 Claude Code 對話，讓它為你寫程式碼。有趣的是，這就是現在意義上的「編碼」——編碼現在的定義是描述你想要什麼，而不是親手編寫程式碼。
Boris Cherny： 我很好奇，那些過去使用打孔卡或其他方式編碼的人，如果看到現在的軟體開發方式，會怎麼說。我記得讀過一些資料，也許是很早期的 ACM 雜誌，有人說：「不，這不一樣，這不算真正的編碼。」那時候他們稱之為「Programming」（程式設計）。我認為「Coding」（編碼）是一個相對較新的詞。
這讓我想起一件事。我出生在烏克蘭，來自蘇聯。我的祖父實際上是蘇聯最早的程式設計師之一，他就是用打孔卡程式設計的。我媽媽撫養我時講過這些故事：她小時候，祖父會把厚厚一疊打孔卡帶回家。對她來說，那是用來畫蠟筆畫的玩具，是童年的回憶；但對祖父來說，那就是他的程式設計生涯。
Boris 的烏克蘭根源
他實際上從未見過軟體行業的這種轉變。但不知何時，轉變確實發生了。我想，當時可能有一代老程式設計師不太看得起新軟體，他們會說：「這不算真正的編碼。」但我認為，這個領域一直都在經歷這樣的演變。
主持人： 你可能不知道，其實我也出生在烏克蘭。
Boris Cherny： 真的嗎？什麼時候？我來自敖德薩。
主持人： 哦，我也是。
Boris Cherny： 是的，太瘋狂了。哇，難以置信。多麼巧合。也許在某種程度上有關聯。你的家人是什麼時候離開的？
Boris Cherny： 我們是 95 年來的。
主持人： 好的。我們是 88 年離開的，早一點。如果不離開，生活會有多大不同啊。
Boris Cherny： 是的，我每天都覺得非常幸運能在這裡長大。
主持人： 是的，我的家人只要遇到點小事，就會說：「幸好去了美國。」我就想說：「好了，別再說了。」但一旦你開始真正思考另一種生活的可能性……
Boris Cherny： 是的，確實如此。我們也做同樣的事，不過那是伏特加。
建構 AI 產品的建議
主持人： 絕對還是伏特加。天哪。好的，讓我再問你幾個問題。你分享了一些關於如何最大化利用 AI、如何建構 AI 以及基於 AI 建構優秀產品的精彩技巧。你提到的一點是，讓團隊擁有無限量的 Token，讓他們去實驗。還有一個普遍建議是：朝著模型發展的方向建構，而不是基於今天的模型建構。 對於那些試圖建構 AI 產品的人，你還有什麼其他建議嗎？
Boris Cherny： 我可以分享一些其他觀點。首先，不要試圖將模型「框」死。很多人在使用模型時，本能地試圖讓它表現得非常具體，把它視為「更大系統中的一個組件」。比如，人們會添加非常嚴格的工作流，要求模型必須按順序完成第一步、第二步、第三步，並用一個精密的編排器來執行。
但實際上，如果你只給模型提供工具，設定一個目標，然後讓它自己去解決，幾乎總是能獲得更好的結果。一年前，你確實需要很多這種「腳手架」，但現在不太需要了。
這個原則有點像「不要問模型能為你做什麼，而要思考如何為模型提供完成任務的工具」。不要過度策劃，不要試圖把它框住，也不要一開始就塞給它大量上下文。給它工具，讓它自己獲取所需的上下文，你會得到更好的結果。
第二點，也許是這個原則的更普遍版本，就是「苦澀的教訓」。Claude Code 團隊非常推崇理查德·薩頓大約十年前寫的那篇博文。
他的核心觀點是：更通用的模型終將勝過更具體的模型。 這有很多推論，對我來說最重要的一點是：永遠押注於更通用的模型。從長遠來看，不要試圖用小型模型完成任務，不要試圖進行微調。
雖然有些特定應用有理由這樣做，但如果你有靈活性，一定要押注通用模型。那些在模型周圍添加「腳手架」的工作流，通常只能帶來 10% 到 20% 的效能提升，而這些提升往往會被下一代模型的原生能力瞬間抹平。所以，最好的策略往往是等待下一代模型。
這或許是最終的原則，也是 Claude Code 回過頭看做對的一件事：從一開始，我們就致力於為六個月後的模型而建構，而不是為今天的模型而建構。
在產品早期，它寫的程式碼很少，因為我當時不信任它。那是 Sonnet 3.5 或類似版本的時期，模型寫程式碼的能力還處於早期階段。那時它確實能幫忙做些 Git 操作或自動化任務，但並沒有真正承擔大量編碼工作。
Claude Code 的賭注是：總有一天模型會足夠強大，可以直接編寫大量程式碼。 當我們第一次看到 Opus 4 和 Sonnet 4 時，轉折點出現了。Opus 4 是我們去年五月發布的第一款 ASL3 級別模型。從那時起，大家開始真正使用 Claude Code，我們的成長也呈指數爆發，並保持至今。
這也是我給許多新創公司的建議，儘管這會讓人感到不舒服，因為你的產品市場契合度（PMF）在最初六個月可能很差。但是，如果你為六個月後的模型建構產品，當那個模型問世時，你將立刻佔據先機，產品會迅速起飛。
主持人： 當你說「為六個月後的模型建構」時，人們應該假設會發生什麼？是它會普遍變得更強？還是說針對目前的短板，假設它未來會解決？關於這一點有什麼具體建議嗎？
Boris Cherny： 這是一個好問題。顯然，在 AI 實驗室內部，我們能看到它具體在哪些方面變強，這有點像「作弊」。但也有些通用的預測。
第一個預測是：模型將越來越擅長使用工具和操作電腦。
另一個預測是：它將越來越擅長長時間執行。 這方面有很多研究，但我基於自己的經驗也能看出來。
一年前使用 Sonnet 3.5 時，它可能只能執行 15 到 30 秒就開始失控，你必須時刻指導它完成複雜任務。
但如今，使用 Opus 4.6，它平均可以無人值守執行 10 到 30 分鐘。我可以開啟一個任務，然後去做別的事。正如我所說，我總是有很多個任務在並行執行。
使用 Claude Code 的專業技巧
它們甚至可以執行數小時、數天，有些案例中甚至執行了數週。我認為隨著時間推移，模型長時間獨立執行將成為常態，你不再需要盯著它們了。
主持人： 我們剛才討論了建構 AI 產品的技巧。那麼，對於 Claude Code 的初學者，或者想要進階的使用者，你有什麼建議嗎？能分享幾個專業技巧嗎？
Boris Cherny： 首先我要明確一點，使用 Claude Code 並沒有所謂的「唯一正確方式」。我雖然可以分享一些技巧，但這畢竟是一個開發工具。開發者千差萬別，每個人都有不同的偏好和環境，所以使用方式也是多種多樣的。你必須找到適合自己的路。幸運的是，你可以直接向 Claude Code 提問。它可以提供建議，甚至幫你修改設定。某種程度上它具備自我認知，能為你提供幫助。
不過，我發現有幾個技巧通常非常管用。
第一個技巧：只用最強的模型。 目前是 Opus 4.6。我始終開啟「最大努力模式」。有時人們為了省錢會嘗試使用 Sonnet 等成本較低的模型，但因為它們不夠聰明，最終往往需要消耗更多 Token 才能完成同樣的任務。所以，低成本模型並不一定真省錢。相反，使用能力最強的模型通常成本更低、Token 消耗更少，因為它能更敏捷地完成任務，需要的糾正和指導也更少。
第二個技巧：使用計劃模式。 我大約 80% 的任務都以計劃模式開始。這其實很簡單，只需要在提示詞中加一句：「請暫時不要寫任何程式碼。」就行了。
對於終端機使用者，按兩次 Shift-Tab 鍵就能進入計劃模式；桌面應用程式和網頁版也有專門的按鈕；手機版也即將支援。我們剛剛還為 Slack 整合推出了這一功能。
本質上，模型會先與你溝通思路。一旦計劃確認無誤，你再讓模型執行。有了完善的計劃，加上 Opus 4.6 的能力，它幾乎每次都能一氣呵成，一次性正確完成任務，我只需要接受編輯即可。
第三個技巧：嘗試不同的介面。 很多人提到 Claude Code 就會想到終端機。確實，我們完美支援 Mac、Windows 等所有終端機環境。但我們也支援其他形式，比如 iOS 和 Android 應用程式、桌面應用程式以及 Slack 整合等。無論你在哪裡執行，背後都是同一個 Claude Agent。所以我建議大家多嘗試，找到最適合自己的工作流。
關於 Codex 與行業競爭
主持人： 太棒了。我想再問幾個收尾的問題。您怎麼看 Codex？在這個競爭激烈的編碼代理領域，您如何看待他們的發展方向和競爭力？
Boris Cherny： 實話實說，我還沒怎麼深度使用過它，記得剛發布時稍微試了一下。在我看來，它和 Claude Code 很像，這其實挺讓人欣慰的。我認為競爭是好事，它給使用者提供了選擇，也倒逼我們所有人做得更好。
但我必須坦白，我們團隊只專注於解決使用者的問題，很少花時間關注競爭對手，也鮮少試用其他產品。知道它們的存在固然重要，但我更喜歡直接與使用者交流，根據回饋來打磨產品。歸根結底，關鍵在於打造一款真正優秀的產品。
AGI 之後的生活規劃
主持人： 最後一個問題。我採訪 Anthropic 聯合創始人 Ben Mann 時，他託我問你一個問題：AGI 實現之後你有什麼計劃？當你達成 AGI 時，你的生活會變成什麼樣？
Boris Cherny： 在加入 Anthropic 之前，我住在日本的鄉下，過著截然不同的生活。我是鎮上唯一的工程師，也是唯一的英語使用者。
我每週騎兩三次自行車穿過稻田去農貿市場。那裡的節奏和舊金山完全相反，是一種截然不同的生活速率。
我們融入當地社區的方式之一就是交換醃菜。鎮上幾乎家家戶戶都做味噌和醃菜。我也因此練就了一手做味噌的好手藝，至今仍樂此不疲。
味噌是一種很有趣的食物，它能教會你用長遠的眼光去思考。 這與工程截然不同。一鍋白味噌至少需要三個月，而紅味噌則需要耗時兩三年甚至四五年。你把原料拌好，剩下的就是漫長的等待，必須非常有耐心。我喜歡味噌，正是因為它讓我習慣了這種長週期的思考方式。所以，如果 AGI 實現了，或者我不在 Anthropic 了，我大概會去專心做味噌。
閃電問答與結語
主持人： 我太喜歡這個答案了。Ben 特意讓我問問味噌的事，很高興你也提到了。未來或許就是潛心鑽研味噌製作之道。Boris，這次訪談非常精彩。感覺我們像來自烏克蘭的兄弟一樣投緣。在進入激動的閃電問答之前，你還有什麼想對聽眾分享或再次強調的嗎？
Boris Cherny： 我想強調的是，對於 Anthropic 而言，從編碼到工具使用，再到電腦操作，這是一脈相承的。這是我們思考問題的路徑，是我們認為模型發展的必然方向，也是我們要建構的未來。同時，這也是我們研究和最大程度提升安全性的途徑。
如今，圍繞「程式碼」已經形成了一個龐大的、數十億美元級的產業。我的朋友們都在使用它，網路上關於它的討論也層出不窮。這件事正變得越來越舉足輕重。
從某些方面看，這完全出乎意料，因為我們最初並不知道產品會演變成這樣，也沒想到會從終端機形態開始。但從另一方面看，這又在情理之中，因為這始終是我們公司的信念。
不過，一切感覺才剛剛開始。世界上大多數人還沒開始使用程式碼工具，大多數人還沒使用人工智慧。感覺我們只完成了 1%，路還很長。
主持人： 是的，想想這些數據簡直瘋狂。你們剛融了巨資。據我所知，Claude Code 的收入就達到了 20 億美元，Anthropic 的總收入更是達到了 150 億美元（註：此處原文數字可能存在口誤或指代估值）。想到這一切才剛剛起步，真是令人難以置信。
Boris Cherny： 對，這太瘋狂了。老實說，Claude Code 之所以能持續成長，全是因為使用者。大家充滿熱情，愛上了這個產品，並積極告訴我們需要改進的地方。它不斷進步的唯一原因，就是大家都在用、都在談論、都在回饋。這是最重要的。對我來說，與使用者交流、為他們改進產品，就是我最喜歡的生活方式。
主持人： 還有，做味噌。
Boris Cherny： 對，還有做味噌。其實做味噌並不複雜，你只需要學會等待。
主持人： 真奇妙。好了 Boris，現在進入激動的閃電問答環節。我有五個問題。準備好了嗎？第一個問題：你最常推薦給別人的兩三本書是什麼？
Boris Cherny： 我是個書蟲。第一本是技術書，《Scala 函數式程式設計》。這是我讀過最棒的技術書籍。你可能不會用到 Scala，我也不確定它未來的地位，但函數式程式設計和型別思維有一種優雅之美。這也是我編寫和思考程式碼的方式。你可以把它當作一本歷史文獻，也可以作為提升技能的讀物。
主持人： 我喜歡這個推薦，一本從未被提及過的書，太棒了。
Boris Cherny： 哈哈，太好了。第二本是查爾斯·斯特羅斯的科幻小說 《加速》。這是我最喜歡的科幻作品。這本書節奏極快，速度感層層遞進。我覺得比任何書都更能捕捉我們當下的時代精髓——那就是「速度」。故事從即將發生的起飛開始，逼近奇點，結局是木星軌道上的集體龍蝦意識。而這一切都發生在幾十年內，這種節奏感不可思議。
第三本我推薦劉慈欣的 《流浪地球》。大家可能都知道他的《三體》，雖然《三體》很棒，但我更喜歡他的短篇小說。《流浪地球》這本短篇集裡有一些非常精彩的故事。閱讀中國科幻很有趣，因為這展現了與西方科幻截然不同的視角，至少從他作為作家的思維方式來看是這樣。文筆也非常優美。
主持人： 科幻小說確實能引導我們思考未來的方向。它就像建構了一幅宏偉藍圖，讓我們感覺「我明白了，我曾在書中讀過這樣的世界」。
Boris Cherny： 確實如此。實際上，這正是我加入 Anthropic 的原因。就像我說的，我曾住在鄉村，那裡的一切都很慢，尤其是與科幻小說相比。你在那裡做的一切都圍繞著季節，圍繞著那些需要數月甚至經年累月才能成熟的食物。社會活動通常就是以這種方式組織的，人們的時間安排也是如此。舉個例子，當你去農貿市場時，你會發現現在是「柿子季」。你知道這一點，是因為那裡大概有 20 個攤位都在賣柿子。而到了下週，這個季節就結束了，變成了「葡萄季」，你能直觀地看到這種更替。這就像是一種長遠的時間尺度。
與此同時，我讀了很多科幻小說。正是在那個時期，我開始思考這些宏大的時間尺度。我看到了事物發展的可能性，並覺得我必須為讓未來變得更好而貢獻一份力量。這其實就是我最終加入 Anthropic 的原因。Ben Mann 對此也功不可沒。
主持人： 我真想專門做一集播客，聊聊你在日本的時光，以及 Boris 穿越日本加入 Anthropic 的旅程，但今天我們會簡短一些。如果你還沒讀過，我快速推薦一本科幻小說——你讀過《深淵上的火》嗎？
Boris Cherny： 哦，那是 Vinge（弗諾·文奇）的作品，對吧？是的，我讀過。
主持人： 沒錯，那本書太棒了。從人工智慧和通用人工智慧（AGI）的角度來看，它非常有趣。可惜讀過的人不多，所以我特別推崇它。我經常會想起書裡的內容。
Boris Cherny： 是的，沒錯。我也很喜歡《蒼穹浩瀚》。
主持人： 我覺得那些專案確實是...
Boris Cherny： 對，是的，我認為確實如此。
主持人： 是的，雖然篇幅很長，設定複雜，入門有點難，但非常精彩。好的，我們繼續「閃電輪」提問。你最近有沒有特別喜歡的電影或電視節目？
Boris Cherny： 其實我不太看電視或電影，現在確實沒什麼時間。不過我看了 Netflix 的《三體》劇集，非常喜歡。我認為那是對原著小說系列的一次很棒的改編。
主持人： AI 領域的領導者們普遍都有個共同點，就是沒時間看電視或電影，我完全理解。那你最近有沒有發現什麼特別喜歡的產品？
Boris Cherny： 我想稍微「凡爾賽」一下，推薦一下 Claude。這確實是一個改變了我生活的產品，因為它一直在執行。特別是它的 Chrome 整合功能，真的非常出色。它幫我處理了一張交通罰單，還幫我取消了幾項訂閱。它能幫你解決那麼多繁瑣的工作，真是太棒了。
雖然不知道這算不算產品，但我還想推薦一個我非常喜歡的播客。除了 Lenny（Lenny's Podcast）之外，就是 Ben 和 David 的 Acquired 播客。真的非常非常棒。他們深入剖析商業歷史並使其栩栩如生的方式令人嘆為觀止。如果你還沒聽過，建議從任天堂的那一期開始。
主持人： 極好的建議。關於 Claude，為了讓大家明白——如果還沒試過的話——基本上你輸入你想做的事情，它就可以啟動 Chrome 瀏覽器並為你完成任務。我看到有人在 Anthropic 陪產假時，讓它幫忙填寫繁瑣的醫療表格。面對那些非常惱人的 PDF 檔案，它會自動載入瀏覽器、登入，然後完成填寫。
Boris Cherny： 沒錯，完全正確。而且它現在真的能用了。一年前我們在做實驗時，它還不能很好地工作，因為模型還沒準備好。但現在它非常成熟了。我覺得很多人並沒有真正理解它是什麼，因為他們以前沒有使用過智能體。它給我的感覺非常像一年前的 Claude Code，但正如我所說，它的進化速度比早期的 Claude Code 要快得多。所以，我認為它已經開始嶄露頭角了。
主持人： 還有你提到的那個 Chrome 擴充功能，你可以單獨使用，它會駐留在 Chrome 中。你可以直接對著它說話，讓 Claude 查看你的螢幕、你的瀏覽器，讓它做一些事情，比如告訴你正在瀏覽什麼，或者總結當前的內容等等。
Boris Cherny： 是的，沒錯。對於剛開始使用 Claude 的人，我推薦這樣做：下載 Claude 桌面應用程式。然後轉到 Claude 標籤頁；它就在程式碼標籤頁旁邊。我推薦的入門方法是讓它使用一個工具，比如「清理桌面」或「總結郵件」。或者你可以讓它「回覆我收到的前三封郵件」，它現在甚至可以幫我撰寫回覆。
第二件事是連接工具。如果你連接了相關工具，比如你說「看看我收到的重要郵件」，它可以發送 Slack 訊息，或者將內容填入電子表格等。例如，我用它來管理我所有的專案。我們有一個全團隊的統一電子表格，每位工程師佔一行。每週，每個人都要填寫一份狀態報告。每週一，Claude 就會檢查表格，並給那些沒有在 Slack 上填寫狀態的工程師發送提醒訊息。這樣我就不必親自做這件事了，只需要一個提示詞，它就能搞定一切。
第三件事就是並行執行一系列 Claude 任務。你可以讓它同時處理任意數量的任務。比如，啟動一個專案管理任務，然後讓它做點別的，再做點別的。啟動這些任務後，我去喝杯咖啡，讓它自己執行。
主持人： 我會附上一篇帖子的連結，裡面分享了很多人使用以前被稱為 Claude Code（現在可以直接透過程式碼實現）的各種方式。因為很多時候人們的反應是「哇，我沒想到可以這樣用」。一旦你看到了這些例子，你就會驚嘆：「哇，我不知道我還能用它做這個。」
Boris Cherny： 是的，我認為很多靈感其實是受到了你的啟發，Ani。你曾經發過一篇關於「Claude 的 50 個非技術用例」之類的帖子。實際上，我們的一位產品經理在發布產品之前，就是用那篇帖子來評估 Claude 的。當他們發現 Claude 能夠完成那 50 個用例中的 48 個時，他們就說，「好吧，這已經足夠好了」。
主持人： 哇，我真不知道那篇帖子還有這個作用。我竟然成了評估員？這感覺太棒了。我覺得我對 AI 的未來產生了價值，這簡直是一種反向的突破。
哇，那真是太酷了。好吧，我很想知道最後沒完成的那兩個用例是什麼。總之，還有最後兩個問題。你有沒有一句最喜歡的座右銘，常用來指導你的工作和生活？
Boris Cherny： 運用常識。
我認為在工作環境中看到的很多失敗，往往是因為人們未能運用常識。比如機械地遵循某個流程而不去思考，或者做事不過腦子。又或者他們正在為一個糟糕的產品或不好的想法而努力，只是隨波逐流。
我認為最好的結果，往往來自於那些能夠從第一性原理出發思考，並建構起屬於自己的「常識體系」的人。比如，如果某件事聽起來不對勁，那它大概率就不是個好主意。這是我給同事們最多的建議。
主持人： 我覺得這本身就可以成為一期播客的主題——什麼是常識？如何培養常識？但我們今天先聊到這。最後一個問題：你最近在 Twitter/X 上活躍多了。我很好奇原因是什麼？你在 Twitter 這個世界裡的體驗如何？因為你在上面有很多互動。
Boris Cherny： 很長一段時間我只用 Threads，因為我之前也參與過 Threads 的開發。而且我很喜歡它的設計，那是一個非常簡潔的產品。
我開始使用 Twitter 是因為感到無聊。去年十二月，我和妻子在歐洲各地旅行。我們去了哥本哈根，去了幾個不同的國家。對我來說，這就像一次「編碼假期」。每天都在寫程式碼，這是我最喜歡的度假方式——整天寫程式碼，感覺太棒了。
然後，我突然感到有些無聊，幾個小時內就用光了想法。我想，好吧，接下來該做什麼？於是我打開了 Twitter。我看到有人在討論 Claude Code，就開始回覆。我想，也許我該做的是尋找人們遇到的 Bug，或者收集大家的回饋。
於是我介紹了自己，詢問人們的情況，收集了很多 Bug 和回饋。我認為他們對我們如今能夠如此快速地處理回饋感到驚訝。但對我來說，這太正常了。如果有人遇到 Bug，我可能幾分鐘內就能解決，因為我熟悉 Claude Code，只要描述清楚，它就能執行。解決完一個，我就可以去做別的事情，處理下一個問題。但我認為很多人對此感到非常驚喜。所以這體驗真的很棒。
是的，在 Twitter 上的體驗非常好。與人互動，了解大家的需求，傾聽關於 Bug 和功能的回饋，這一切都很棒。
主持人： 我前几天在 Twitter 上看到 Nikita Bier 抱怨說，你發了很多很長的帖子，結果導致頁面崩了，然後大家都在想「天啊，這是怎麼了？」。
Boris Cherny： 是的，沒錯，那確實是一個 Bug。希望現在已經修好了。
主持人： 太棒了。天啊，Boris，我可以和你聊上幾個小時。我就不打擾你了。非常感謝你來參加這次節目。你太棒了。人們在哪裡可以找到你？聽眾如何才能幫助你？
Boris Cherny： 去 Threads 或 Twitter 找我就行，那是聯繫我最方便的地方。歡迎隨時 @ 我，無論是回饋 Bug 還是提交功能需求。告訴我們產品缺了什麼？還能做些什麼來改進？你們真正想要的是什麼？我很期待聽到大家的聲音。
主持人： Boris，非常感謝你做客我們的節目。
Boris Cherny： 謝謝邀請。
主持人： 再見，各位。感謝大家的收聽。
作者：瓜哥新知
參考資料: