Claude Code 創造者 Boris Cherny：寫程式已被解決（Coding Is Solved）｜Sequoia 訪談完整中文逐字稿
紅杉資本（Sequoia Capital）訪談 Anthropic 的 Claude Code 負責人 Boris Cherny 的對談（訪談者為 Lauren Reeder），主題探討「為何寫程式的問題已經被解決（Coding Is Solved），以及未來的走向」。
以下為該訪談對話的完整中文全文翻譯（無省略、未節錄、不含時間戳記）：
開場介紹
引言主持人：
好的，非常興奮能為大家介紹我們的下一位講者。現場請舉手，有誰在使用 Claude Code？好的，再請舉手，現場誰有「Claude Code 精神錯亂症（Claude Code psychosis）」？拜託，大家別害羞，這很正常。我的團隊常常開玩笑說我也有 Claude Code 精神錯亂症，這可能真的，也可能不是真的。
今天我們非常榮幸能邀請到 Boris Cherny 與我們同在。Boris 是 Claude Code 的創造者、也是它的奠基之父。在打造這項產品的過程中，他站在第一排親眼見證並參與了重新發明現代軟體開發方式的歷程。Boris，我們非常感謝你今天撥空前來與我們交流，我們知道整個軟體開發領域彷彿都扛在你的肩上，所以很感謝你抽出一小時的時間。今天負責訪談 Boris 的是我們團隊的 Lauren Reeder，謝謝大家。
第一部分：Claude Code 的誕生背景與起源
Lauren Reeder：
我們先調整一下椅子。你搶了我的開場白，我通常都會先問現場有誰在使用 Claude Code，剛剛看到滿滿都是舉手的人，真是太棒了。Boris，非常感謝你來到現場，能邀請到你真的很特別。面對滿屋子的開發者與創業者，我認為你徹底改變了「構建（building）」的方式。因此我非常好奇想探討你如何看待軟體開發與寫程式的未來，以及未來我們省下來的所有空閒時間應該拿來做什麼。
不過我先為大家稍微介紹一下你的背景，讓大家更了解脈絡。除了創造 Claude Code 之外，Boris 是個徹徹底底的工程師中的工程師（engineer’s engineer）。你在整個職業生涯中寫了大量的程式碼，也撰寫過關於程式設計的教科書，包括《Programming TypeScript》。上次我們聊天時，你提到你在過去一年裡——或者至少在 2026 年到目前為止——自己連一行程式碼都沒寫過，這真的是巨大的轉變。
Boris Cherny：
還有一個鮮為人知的事：早在初中時，我曾寫過一本為 TI-83 Plus 計算機寫 BASIC 語言的指南。我最近搜尋了一下，它居然還掛在網路上，超級令人尷尬，所以請大家千萬不要去搜尋它，但它確實存在。
Lauren Reeder：
我們等一下絕對會把它找出來。那麼我們先從幾個問題開始，或許可以先聊聊 Claude Code 的歷史，你是怎麼開始這個專案的，接著我們會留很多時間開放現場觀眾 Q&A。所以大家現在就可以在腦海中先思考你們想問的問題，等一下會把麥克風交給大家。
Boris Cherny：
好的。另外順便做個快速調查：現場使用 Claude Code 的人，大多是用 CLI（命令列介面）嗎？好的，大部分是 CLI，真的很多人。那主要是用桌面應用的呢？好的。那主要是用 VS Code 或 JetBrains IDE 擴充套件的呢？好的，其實不算多。那其他的呢？像我自己最近大多是用 iOS。好的，太酷了。
關於開始做 Claude Code，在很多方面其實算是一個意外。我在 2024 年底加入這個團隊，當時它是 Anthropic 內部的一個孵化器，叫做 Anthropic Labs。這個團隊基本上完成了它的使命——我們打造了 Claude Code、MCP（Model Context Protocol）以及桌面應用程式。那時團隊只有我們幾個人，非常像是一個純粹的創新團隊。我們打造了自己想做的東西之後，團隊就解散了；而現在這個團隊其實為了第二階段又重新重組了，目前由 Mike Krieger 帶領（他是 Anthropic 的首席產品長，也是 Instagram 的聯合創辦人之一）。
當初我會開始投入 coding 這個方向，是因為我們覺得存在著「產品懸殊/產品過剩（product overhang）」。我猜在座的人可能常聽到這個詞，在我們實驗室內部確實非常常提到這個概念——也就是說，模型明明具備了做許多事情的能力，但目前還沒有任何產品真正把這些能力完全發揮出來。在 2024 年底，當我們審視寫程式這件事時，當時的最先進技術（SOTA）其實只是「打字預測／自動補全（type ahead）」。也就是打開你的 IDE，按下 Tab 鍵，它一次幫你補全一行程式碼，這是當時 Sonnet 3.5 首次實現的能力。但我們的感覺是，我們其實可以走得比這遠得多，模型的實力已經快要準備好迎接下一個重大跨越了——我們不再需要打字補全，而是可以直接讓 Agent（代理）替我們寫出全部的程式碼。
於是我把它做出來了。但在前六個月裡，它真的完全不行，效果非常不好，幾乎難以使用。我自己大概只有 10% 的程式碼會用它來寫。甚至在我們最初發布 Claude Code 時，它也稱不上爆紅。雖然有很多人用，但完全沒有像今天這樣出現指數級增長。
這種爆發是從 5 月釋出的 Opus 4 開始的，我記得很清楚，指數級增長就是從那時候啟動的。隨後每當有新模型推出，成長曲線就會再次向上拐折——從 Opus 4 開始，到 4.5、4.6，再到現在的 4.7，每一次都在加速。但本質上，我們當時是在嘗試打造一個在「產品市場契合度（PMF）」出現之前的產品，我們很清楚在接下來的六個月內都不會有 PMF，因為我們是在為「下一個世代的模型」打造產品。這基本上一直都是我們的核心思路。
對 Anthropic 而言，我們一直都非常專注，始終重視商業、企業端、安全以及程式設計，這向來是我們希望構建的方向。所以在某個時間點，我們很清楚自己想要打造一個產品，只是不確定具體時間，最後這項產品就成了我們押注的成果。
第二部分：為什麼說「寫程式已被解決」與個人工作流
Lauren Reeder：
這真是一個不可思議的故事，特別是它最初居然是個意外。你曾在公開場合表示，你認為「寫程式這件事已經被解決了（Coding is solved）」。如果這是 Anthropic 的三大押注之一，你能跟我們多聊聊你的意思是什麼嗎？還有哪些問題可能尚未解決，或者隨之而來的二階效應會是什麼？
Boris Cherny：
好，我可以再問現場一個問題：現場有誰是 100% 純手工手寫程式碼的？誰是 100% 完全用像 Claude Code 這類的 Agent 來寫程式碼的？那介於兩者之間的呢？好的，看來是 50% 解決了。
對我個人來說，真的是 100% 解決了。Claude Code 的程式碼庫之前外洩過，所以大家都知道了——它其實非常簡單，就是 TypeScript 加上 React，沒有什麼大秘密，也沒有任何複雜的玄機。我們當初選擇 TypeScript 和 React 的原因，是因為它們非常處於模型的「資料分佈中心（on-distribution）」。當我們剛開始搭建這個程式碼庫時，模型還沒有今天這麼聰明，因此程式語言與框架的選擇非常重要。如今模型基本上什麼都能寫，能快速掌握它從未見過的新語言和新框架；但在當時，你必須使用非常處於分佈範圍內的技術。
也正因為如此，我認為我們很早就達到了「讓模型撰寫 100% 程式碼」的境界。對我們來說，這大概發生在去年的 10 月或 11 月。對今天的我來說，模型替我寫 100% 的程式碼。我每天通常會提交幾十個 PR；上週有一天我單日提交了大概 150 個 PR，那算是一個紀錄，我當時只是想測試看看自己究竟能推進到什麼極限。
所以對我而言，這件事就是已經解決了。但當然，並不是所有地方都如此。世界上還有非常龐大、複雜的舊程式碼庫，也有模型目前還不擅長處理的冷門或奇異語言。不過如同在座各位所知道的，它正迅速往那裡前進。通常答案就是：等待下一個模型。
Lauren Reeder：
你能跟我們具體聊聊你的個人工作配置（personal setup）嗎？你前幾天向我們展示過，真的很瘋狂。
Boris Cherny：
好的。大概六個月前我在 Twitter（X）上分享過我的個人配置，有趣的是我當時分享時完全沒意識到這會讓大家感到驚訝，因為對我來說這就是我日常寫程式的方式。不過從那之後它又變了。
現在，我絕大部分的工作都是在「手機」上完成的。我不知道大家看不看得到——我手機上有 Claude App，打開 App 後左側有一個小小的 Code 標籤頁，裡面開了一堆 session。通常我隨時會有大約 5 到 10 個 session 在進行，而每個 session 裡面通常會有一整群 Agent。目前隨時大概有幾百個 Agent 同時在跑；每天晚上通常會有幾千個 Agent 在執行更深度的任務。
管理這些 Agent 有幾種方式：一種是直接讓 Claude 調用一群 Sub-agents（子代理）去執行工作。但其實我發現自己越來越常使用的是「Loop（迴圈機制）」，也就是 sloop。這真的是最酷、也最簡單有效的東西：它的本質只是讓 Claude 利用系統的 cron 來排程未來某個時間點的工作，並且是個重複執行的任務。它可以每分鐘、每五分鐘或每天執行一次，完全依照你排程的頻率。
現在我有幾十個這種 loop 在背景隨時運作。例如，我有個 loop 專門幫我看管我的 PR——負責修復 CI、自動 rebase；我有另一個 loop 專門維持 CI 的健康狀態，如果出現不穩定的測試（flaky test），它就會自己去把它修好；我還有另一個 loop 每 30 分鐘會抓取 Twitter 上的回饋意見並幫我聚類整理好。所以我手頭上隨時都有大量的 loop 在跑。我覺得以目前來說，loop 就是未來。如果你還沒嘗試過，我非常強烈推薦試試看。我們最近也剛推出了「Routines」，概念相同，但是運行在伺服器端，因此就算你把筆電闔上，它依然會繼續運作。
第三部分：未來團隊形態與軟體產業的演變
Lauren Reeder：
這是你個人的配置。那依照你的推想，未來的團隊會是什麼樣子？從你目前的工作方式來推演，你如何讓團隊中的每個人都能持續向前推進並理解全貌？或者你認為我們需要放手讓更多 Agent 來運作？
Boris Cherny：
要做出預測總是很難，但我今天來這裡就是來做預測的，所以我就大膽預測一下。
我認為整體的趨勢是，未來會出現比今天多得多的「通才（generalists）」。今天當我們談到通才時，大多還是指工程師——他們依然在寫程式，可能算是產品工程師，比如能同時搞定 iOS、前端 Web 和後端 Server，這在工程領域被視為通才。
但未來我們將會看到更多「跨領域的通才（cross-disciplinary generalists）」。這些工程師既非常擅長產品工程，同時又極具設計美感；或者既懂產品、資料科學，又精通工程架構。這在我們團隊內部已經開始發生了。實際上，Claude Code 團隊中的許多人都是跨領域的通才。
我們團隊裡的每一個人都在寫程式——我們的工程經理、產品經理、設計師、資料科學家、財務人員、使用者研究員，團隊裡的每一個人都寫程式。雖然他們各自在某個領域是專家，但現在每個人都在寫程式。我看到現場有人在點頭，但我打賭這對在場的人來說其實也不太意外，因為我相信你們也在目睹同樣的現象。
Lauren Reeder：
在開放觀眾提問之前，我還有最後一組問題。我們剛剛聊了寫程式本身的變化，我很好奇你如何看待整個軟體界或軟體產品的變革。當 AI 讓撰寫程式碼的成本便宜了 10 倍甚至 100 倍時，用軟體打造出來的產品其價值會發生什麼變化？我們會迎來一場「SaaS 大末日（SaaS Apocalypse）」嗎？你認為局勢會如何演變？你又必須給出一個預測了。
Boris Cherny：
「SaaS 大末日」是我最喜歡的問題。我認為將會發生兩件事，而且我覺得這兩件事都不是目前大眾普遍在談論的論點。
第一點：現場有人是《Acquired》Podcast 的聽眾嗎？它真的是最棒的 Podcast。前幾週我剛好有機會跟他們錄了一期 Unplugged 節目，我覺得自己像是見到了偶像一樣，那兩位主持人太棒了。他們節目常提到「7 種競爭優勢力量（7 Powers）」，這是 Hamilton Helmer 寫的一本書，探討商業中的七種護城河。我認為隨著 AI 的發展，這些護城河有些會變得更加重要，有些則會變得不那麼重要。
例如，變得比較不重要的護城河是「轉換成本（switching costs）」，因為你隨時可以藉助模型，輕鬆地從一套系統移植遷移到另一套系統。另一個變得不重要的護城河是「流程力量（process power）」，因為對於那些依靠複雜工作流程與規章程序建立護城河的公司來說，Claude 正在變得極度擅長理清與執行各種流程。特別是到了 4.7 模型，它幾乎能夠針對任何目標進行「爬山演算法（hill climb）」式的優化——只要你給它一個目標並讓它持續反覆運算直到完成，它就能搞定。我認為這是第一個具備這種能力長處的模型。因此這些護城河會被削弱。
然而，其他原有的護城河依然非常關鍵——像是「網絡效應（network effects）」、「規模經濟（scale economies）」、「獨佔資源（cornered resources）」等等。這些優勢並不會因為 AI 而改變。
第二點：如果你看過去十年的新創公司數量，我認為在未來十年裡，那些即將徹底顛覆各行各業的新創公司數量將會增長 10 倍。因為現在你即使只是一家規模極小的初創團隊，也能打造出價值比肩大企業的產品，並且能與之正面交鋒競爭。大公司必須去變革他們的業務流程、改變工作方式、重新培訓所有人使用新技術，他們內部會面臨巨大的阻力；但在座的各位完全沒有這種包袱。如果你從零開始，你就可以完全以 AI 原生（AI-natively）的方式從底層架構起整間公司。所以對我來說，我認為現在是打造產品最好的時代，是創立新創公司最好的時代，巨大的顛覆正在來臨。
Lauren Reeder：
看來我們終究還是很有希望的，謝謝 Boris。現在我們開放現場觀眾提問，有誰想發問嗎？Dan。
第四部分：觀眾問答（Q&A）
Q1：Claude Code 的成功，模型能力 vs 產品設計的比重？
提問者（Dan）：
嗨，我很好奇，你剛才提到在找到 PMF 之前的六個月就開始動手做了。但以現在模型的能力已經足夠優秀的情況下，你認為 Claude Code 的成功，有多少應歸功於底層模型本身，又有多少是歸功於產品層面的決策與產品的使用體驗？
Boris Cherny：
我認為兩者都有，大概各佔一半。如果在一年前問我，比例大概是 50/50；如果六個月前問我，可能也是 50/50。
提問者：
那兩年後呢？
Boris Cherny：
兩年後？老兄，我不知道，我們現在的計畫都是只看下週，六個月後對我們來說都算遙遠的未來了。
順帶一提，我認為當初是 50/50 的原因在於：我以前待過 YC（Y Combinator）的公司，是一家 YC 公司的第一號員工，我自己也做過好幾家新創。在創業圈——尤其是在 YC 裡——他們反覆不斷灌輸給你的原則就是：「打造人們熱愛的東西（build something people love）」。所以無論產品是什麼、無論底層模型有多強，最終你依然必須打造出一個人們真心喜愛的東西。這就是為什麼產品設計至關重要。我們對微小的細節傾注了無比的專注，好讓你在整天頻繁使用它時能擁有極佳的體驗。
但我也認為，隨著模型變得越來越聰明，外層的封裝框架（harness）重要性就會相對降低。我們目前在思考的是：我們該如何演進外層框架？比如如何讓 loop 成為一等公民功能？如何讓同時運行大量 Agent 變得更容易？除了子代理之外，我們還在醞釀更多功能。但我認為一年之後，模型本身的對齊能力會強大得多，以至於我們今天針對 Prompt Injection（提示注入）、指令靜態驗證、權限模式、人機協同（human-in-the-loop）所建立的各種安全防護機制都會變得沒那麼關鍵，因為模型本身就能做出正確的判斷。這是我目前的預測。謝謝。
Q2：寫軟體會像傳簡訊或用 Office 一樣全民普及嗎？
提問者（第二位觀眾）：
如果稍微跳脫單純的軟體開發來看，我覺得 Claude Code 在幾個月前掀起了一場文化變革，它讓「打造軟體」這件事走向平民化。你可以看到實體店面的老闆自己寫軟體來管理業務，甚至是去編寫微控制器，讓有人推開店門時燈光會自動亮起。你認為在未來，「打造軟體」會變成像「我會使用 Microsoft Office」那樣的一種基本技能嗎？變成每個人都能做、而不僅限於科技業專屬的技能？
Boris Cherny：
天啊，絕對會，完全正確。我甚至覺得不僅如此，它會變成就像「我知道怎麼傳簡訊」一樣的自然技能。
我平時閱讀主要就兩大類：科幻小說與科技歷史。在科技史上，我認為有一個最清晰的事件可以作為當前局勢的對照，那就是 1400 年代歐洲活字印刷術的發明。在印刷術發明之前，全歐洲大概只有 10% 的人口識字，他們通常受雇於本身不識字的國王或貴族，專門替他們讀書寫信，閱讀與書寫在當時絕非人人普及的技能。印刷機發明之後，在隨後的 50 年間，歐洲出版的文獻總量超過了此前一千年的總和，而在同一時期，書籍的成本下降了約 100 倍。
當然，後來花了幾百年時間普及，因為學會讀寫很難，你需要教育體系、需要政府制度、需要解放農耕人力等等。但在隨後的數百年間，全球識字率上升到了約 70%。如今我們所有人都具備讀寫能力，你不需要讀寫學位就能寫字看書——儘管專業作家依然存在，那依然是一門專業領域。
因此我認為即將發生的轉變——而且速度會遠遠快於 50 年——就是軟體開發將會徹底普及，成為每個人都能做的事。這會帶來許多推論，舉例來說：假設你要打造一套會計軟體，我認為今天最適合寫這套會計軟體的人可能已經不是軟體工程師了，而是一位頂尖的會計師。因為他們極度深刻地理解該領域的專業知識，寫程式反而變成了最容易的部分，領域知識才是最難的。我認為這顯然就是未來。
Q3：Anthropic 內部走在趨勢前端的差距有多大？
提問者（第三位觀眾）：
Greg 先前提過，你們在某種程度上像是「活在未來」，因為你們能搶先接觸到未發布的模型與 Agent 架構，Claude Code 在對外發布前也是內部的工具。那麼在工程領域上，你們與外部世界之間的差距大概是一個月、三個月還是六個月？這個差距隨著時間是在擴大還是縮小？
Boris Cherny：
在內部，我們使用的模型其實跟大家使用的完全一樣。對我們來說，「吃自己的狗糧（dogfooding）」至關重要。所以我們使用的就是現場大家都在用的東西——我們可能會用一點點 Mythos 來測試，但我們大量使用 Opus 4.7 來內部實測並撰寫我們絕大部分的程式碼。因此在「模型層面」，我認為其實沒有什麼差距；Mythos 之後的某個衍生版本最終也都會開放給所有人使用。
我認為真正存在巨大差距的反而是「產品與組織層面」，這與我們徹底改變了所有工作流程有關。如果你去跟 Anthropic 的同仁聊聊，我們幾乎所有事情都用 Claude。我們的各個 Claude 整天都在互相溝通——當我在寫程式時，我的 Claude 代理在 loop 中運作，它們會直接透過 Slack 去跟其他同事正在跑 loop 的 Claude 溝通，互相協調排查未知問題。我們公司全體內部已經沒有任何純手工手寫的程式碼了，所有的 SQL 查詢都是由模型撰寫的，所有的東西都是模型構建出來的。
所以我覺得我們真正領先的地方並非技術本身——因為相同的技術在座各位都能使用，我們本質上是在打造一個平台，因此確保開發者能使用與我們相同的工具、並且對所有推出的東西進行徹底的 dogfooding 對我們極為重要。我認為真正的領先是在於「組織架構」與「組織流程」。這也是為什麼我們希望在類似這樣的活動中多分享，讓所有人都能借鑑並隨之演進。這也是新創公司的優勢所在，因為從零開始導入會容易得多。
Q4：多代理（Multi-agent）並行與 Harness / 模型層面的演進
提問者（Jiren）：
上次我們在另一場活動聊到多代理（multi-agent）時，那時這項概念還很初步，當時你提到有些新功能在籌備中。現在顯然有了 /batch、有了 sloop、有了 sub-teams 與 teams 等功能。你能否談談在模型層面與框架（harness）層面，你們是如何在 harness 中注入先驗知識、模型層面的目標函數又是如何調整，讓委派工作與生成多個 Agent 的體驗變得更好？因為很多工作本質上都是可高度並行化的，可以同時把事情做得更快，但我常常覺得目前還需要依賴我自己的直覺去判斷何時該並行，而不是由模型自主理解這時候應該一口氣啟動幾十個 Agent。
Boris Cherny：
在產品端，說到底主要就是依靠 Prompt Engineering（提示詞工程）。我們會去微調 prompt 來引導模型更多地去進行並行任務。但老實說，隨著模型能力提升，它自己就會自然而然地開始這樣做。
像在 4.7 模型上，我就發現它已經會主動採用 loop 的思維，這非常酷。舉例來說，我有時跟它說：「去撈取這筆資料查詢」，它會主動回我說：「嘿，我注意到這份資料會隨時間變動，我先啟動一個 loop，每 30 分鐘向你報告一次進度好嗎？」我說：「太好了，那你可以把報告發到 Slack 給我嗎？」接著它就直接利用 Slack MCP 把報告發送過來了。
因此我認為，長遠來看，責任不應該在於「教使用者如何更好地操控這些工具」。如果還需要使用者動腦去想要怎麼操作，那本質上是產品設計的失敗，說明我沒有把工作做好。未來的方向必然是模型本身更聰明地處理這一切，而我們只需做好提示引導，讓模型自然地展現這種自主行為。
Q5：雲端集中運算 vs 本地端 AI 代理（Local Agents）
提問者（第四位觀眾）：
目前我們大多數人似乎都是依賴 Claude 或 Codex 這些雲端工具來處理大部分的運算。但社群裡一直有一批強烈的擁護者主張「將 AI 部署在本地（Local AI）」。隨著開源權重模型與技術的追趕，未來每個人在本地獲得高水準的程式輔助是有可能的。我很想知道你對未來幾年的願景：大家會繼續高度依賴雲端中心化的算力，還是會轉向每個人在本地跑自己的 Agent、不會受限於 API 限流且兼顧其他優勢？
Boris Cherny：
這個問題可以從幾個角度回答，但我覺得最根本的回答是：這其實無所謂、不重要。
因為我認為我們現在正邁入一個「模型自己會搞清楚該怎麼做」的階段。大概幾年之內，模型會全面接管撰寫程式、啟動 Agent、搭建執行環境。如果模型判斷「這項任務其實調用本地模型來跑最合適」，那它就會自己去調用本地模型。我不認為這在未來還會是由身為工程師的我們來手動替它做的決策。
Q6：MCP 與 Computer Use 的角色
提問者（Jamie Nester）：
Claude Code 當初最出色的設計之一，就是它善用了開發者工具與工作流程本就多在本地端（Local）的特性。但對於一般知識型工作來說，很多工具都在雲端。好奇你們是如何透過 Co-work 來讓它具備足夠的工具存取權，使其能像 Claude Code 對開發者那樣強大？
Boris Cherny：
這是一個非常棒的問題。我記得以前在大公司工作時，我們花了整整五年的時間把所有的開發環境全部遷移到遠端，在大規模架構下那真的是龐大的工程。但對於知識型工作來說，大部分其實已經在雲端了，例如 Salesforce、Google Docs 等等。
對我們來說，答案永遠是最簡單的那個——那就是 MCP。透過與 Claude AI 中完全相同的 MCP 連接器，你可以直接接入 Salesforce、Google Docs、Google Calendar 等工具。這樣一來，Co-work 可以調用它，Claude CLI 可以調用它，全體 Claude Code 都能調用它。
提問者：
那針對那些目前還沒有提供 MCP 介面的舊系統呢？你認為這會是 Computer Use（電腦操作介面）大展身手的領域嗎？
Boris Cherny：
沒錯，我認為 Computer Use 就像是一個全面兜底的通用解決方案（catch-all）。就我目前所知，Anthropic 在 Computer Use 領域算走得非常前面。如果你透過 Co-work 使用它，它基本上能夠直接操作你電腦上的任何軟體介面。雖然目前速度還偏慢，但執行效果已經相當出色，尤其是在 4.7 模型上。
但在其他情況下，MCP 依然是核心解法。而且老實說，這中間的形式其實不太重要——無論是 MCP、CLI、還是 API，只要能提供某種程式化存取途徑即可，因為對模型來說，底層全部都只是 Token 而已。
Q7：未來 6 到 12 個月因模型提升而變得更強大的產品型態
提問者（Ryan Sean）：
謝謝。你剛才提到了「產品懸殊（product overhang）」的概念——也就是先打造出一款產品，隨著後續模型實力增強，產品會變得更加亮眼與有趣。你是否能用概括的方式描繪一下，今天有什麼樣的產品型態，在未來 6 個月到 1 年隨著模型變得更聰明時，會變得無比強大？
Boris Cherny：
Claude Design 是一個絕佳的例子。它現在已經相當不錯，但未來會變得強大得多。
此外，我們也正在為 Claude Code 緊鑼密鼓籌備幾項新功能，預計在接下來幾週內就會陸續推出，屆時大家就會看到。
再者，我認為圍繞在「大規模並行 Agent（massively parallelizing agents）」的機制——例如 loop、batch 這些功能——絕對會迎來質的飛躍。最後，Computer Use 也是另一個非常有潛力且會變得極其強大的方向。
結語
Lauren Reeder：
好的，Boris，非常感謝你今天前來與我們交流。訪談告一段落，我們等一下還會在現場稍作停留，如果大家還有其他問題也可以私下交流。謝謝大家！
Boris Cherny：
謝謝大家！
