Boris Cherny：Claude Code 與工程的未來｜Acquired Unplugged 訪談完整中文逐字稿
WorkOS 主辦的《Acquired Unplugged》訪談節目，由 Acquired 節目主持人與 Anthropic 的 Boris Cherny 對談，主題為：《Boris Cherny: Claude Code & the Future of Engineering》（影片長度約 29 分 38 秒，影片連結：http://www.youtube.com/watch?v=RkQQ7WEor7w ）。
以下為該訪談的完整中文翻譯全文（無時間戳記、無省略、依對話自然段落分段呈現）：
第一部分：Claude Code 的誕生與 Anthropic 的初衷
主持人： 好的，我們想聽聽起源故事。Claude Code 究竟是從何而來的？順便說一句，來到這裡親耳聽到你們兩位的聲音真的很神奇，因為我平常都是戴著耳機聽你們的節目，而且通常開兩倍速。
主持人： 大概都是兩倍速，還帶著我們剪掉所有口頭禪和贅字後的版本。
Boris Cherny： 沒錯。其實在很多層面上，這算是個意外。我在 2024 年底加入 Anthropic 的一個團隊，那是一個類似原型開發的團隊，叫做 Labs 團隊——我們後來又重啟了這個編制。當時的想法是去探索下一個劃時代的產品是什麼，同時推動模型的前沿發展，並找出該如何改進模型，來為那個尚未被打造出來的未來產品提供最佳支援。
但要弄清楚模型該朝哪個方向演進其實很困難，因為在真正有一款產品去推動前沿之前，你很難確切知道方向。而在那時，有一種非常強烈的「產品積壓感」（product overhang）——也就是說，模型其實已經具備了很多能力，但市面上還沒有任何一款產品真正將其釋放出來。回想當時的程式碼工具，多半只有自動補全工具，或者你可以向 Agent 提問，但它並不能直接寫程式碼。
主持人： 沒錯，直到最近之前，模型的能力確實還不夠好，沒辦法真正做到這點。
Boris Cherny： 所以我們覺得，現在正是全力投入打造一個純粹的「程式設計 Agent」（Coding Agent）產品的時機。於是我們著手打造了它。剛開始的時候其實蠻糟糕的，有一段時間它大概只能替我寫 10% 到 20% 的程式碼。
主持人： 在聊到那一刻之前，快速問一下：在此之前，Anthropic 內部的程式設計狀態是什麼樣的？這件事有多受重視？
Boris Cherny： 在 Anthropic 內部，我們當時依然在使用傳統 IDE。但對 Anthropic 這家公司而言，我們一直都非常重視 Coding、工具調用（Tool Use）以及電腦操控（Computer Use）。這一直都是核心的研究方向。
因為對我們來說，我們存在的目的就是研究 AI 安全（AI Safety），這就是我們存在的理由。如果你在 Anthropic 隨便拉住走廊上的一個人問：「你為什麼在這裡工作？」他們一定會回答「AI 安全」。這是每個人加入這家公司的原因，大家深信不疑，包括我在內，我們認為這是最重要且亟待解決的單一問題。
要解決這個問題有很多切入點：你可以研究機械可解釋性（Mechanistic Interpretability）、做對齊研究（Alignment），有各種各樣在「培養皿」中研究模型的方法。但歸根結底，當模型在各方面看似安全後，你必須把它放到真實世界（in the wild）中觀察它的表現。這正是 Claude Code 發揮作用的地方。
對 Anthropic 來說，公司的方向始終是安全；而研究安全有多個層次，包括將模型放到真實環境中進行測試。那麼，有什麼實用的方法能做到這一點？答案就是程式設計（Coding）。因為這是模型與現實世界互動的方式。如果你想研究各種形式的模型未對齊（misalignment），又想讓它足夠實用以吸引人們使用、從而讓你能夠研究它，那麼程式設計就是一個極其顯而易見的應用場景。所以從一開始，這就是焦點所在。
主持人： 程式設計也是一個極為純粹的領域。因為有大量的訓練資料，程式要麼能運行、要麼不能運行；取決於語言，它要麼能編譯、要麼不能編譯。它有一種非常清晰的通過/失敗（pass/fail）的測試能力。而且正確解的空間是相對有限的。英文中可以有無限多首正確且美麗的詩篇，但解決特定問題的正確程式碼寫法卻不是無限的。把它當作培養皿有一種獨特的優雅。
Boris Cherny： 沒錯。不知道大家知不知道侯世達（Douglas Hofstadter），就是寫《哥德爾、艾雪、巴哈》（GEB）的那位作者？
主持人： 知道，非常棒的一本書。
Boris Cherny： 他在 80 年代寫過另一本非常奇特的書，談論他對邁向人工智慧之路的看法。他是一名教授，在學校教授 AI。他提到認知的基礎、智能的基礎在於模式識別。他研究這一點的方式之一，就是他的嗜好：將詩歌從英文翻譯成法文。直譯很少會是正確的翻譯，其中需要大量的品味與拿捏，有時你得稍微調整修飾，才能讓韻律合適，有各種各樣的處理方式。那是一個非常模糊（fuzzy）的問題。
但程式設計相對更容易解決。此外，它在商業上也非常有價值，這有助於我們建立起健康的商業模式；而這類業務的受眾，正好是我們最重視的客戶：企業、新創公司與機構。這讓我們擁有一種目標高度對齊的商業模式，我們不需要靠廣告維生，可以專注在我們真正關心的安全議題上。
第二部分：從工程工具到模型能力的質變
主持人： 你在加入 Anthropic 之前曾在 Meta 工作，而且在 Meta 也非常專注於程式碼相關領域。回顧過去並將這些點串連起來，你在 Meta 的經驗是如何啟發並影響 Claude Code 的誕生？
Boris Cherny： 對我來說，打造開發者工具（DevTools）一直都像是一種副業或邊車專案，它從來不是我的主要工作。但我認為這其實是打造 DevTools 最佳的方式。因為你的核心焦點應該是解決商業問題、打造人們熱愛且對人們真正有用的東西，這才是我們作為工程師的根本使命——YC 總是把這套理念灌輸給大家，我也深有同感。
主持人： 你以前參加過 YC 嗎？
Boris Cherny： 是的，大概在 2010、2011 年左右，我是某家 YC 新創的第一位員工，那是最初幾期的批次之一。
對我來說，開發者工具一直是這種輔助性質的存在。我專注於打造產品；而在打造產品的過程中，如果發現開發者體驗（DevX）不夠順暢，我就會去寫工具讓它變得好一點。這一向是我的做事方式。
因此在 Anthropic，我只是延續了這種心態：先為自己打造有用的東西，然後希望它對其他人也有用。而當我驚喜地發現它確實對大家很有用時，感覺棒極了。
主持人： 你剛才提到一開始它還挺陽春的，你只敢讓它處理大概 10% 的工作，或者說它只能分擔 10%。初期的瓶頸究竟是什麼？你們是如何突破並讓它變好的？因為據我所知，你在工作中已經有大約六個月沒親自寫過一行程式碼了。
Boris Cherny： 是的。
主持人： 這跟「只能處理 10%」相比，差距實在太大了。中間發生了什麼轉變？
Boris Cherny： 我記得很清楚：五月的時候迎來了 Sonnet 4 與 Opus 4，接著十一月迎來了 Opus 4.5。這完全是底層基礎模型發生的質變。
關鍵就是模型本身。當然，我們在周邊框架（harness）和改進 Claude Code 的體驗上也投入了大量心血。工程師使用工具的習慣各不相同，這正是針對工程師做產品的特點——它不是普通的消費級產品，工程師對於自己喜歡的工具用法有極強的主見。
所以我們一開始只做了命令列介面（CLI），但隨後我們陸續打造了桌面應用程式、行動端 App、iOS 與 Android 版本，還有 Slack 整合與 GitHub 整合。你可以用自己喜歡的任何方式來使用 Claude Code。
這其中包含了大量創新、學習與摸索實用功能的過程，例如「計畫模式」（Plan Mode）就是這樣誕生的，還有許多工具與體驗也是由此演變而來。但歸根結底，當我回顧模型替我撰寫的程式碼比例何時產生飛躍性的階躍變化（step change）時，核心原因依然是模型本身的進步——模型能力提升了，比例就隨之激增。
主持人： 在你可以透露的範圍內，Claude Code 的使用經驗與反饋，與推動 4.0、4.5 等模型研發的工作之間，結合得有多緊密？
Boris Cherny： Anthropic 的每個人每天都在使用 Claude Code。負責構建模型的 AI 研究員在用，負責構建產品的工程團隊也在用。這基本上就是一個自我反饋的閉環。
第三部分：指數型成長與工程效率的顛覆
主持人： 你們是否有任何數據或指標，可以用數字來說明它如何改變了公司的發展軌跡？從外界看來，你們現在交付產品的速度比以往快上非常多，合理推測很大一部分原因是因為全公司內部都在深度使用 Claude Code。我們該如何具體理解這之中有多少歸功於 Claude Code？
Boris Cherny： 身處一家 AI 實驗室，你基本上會習慣以「指數級」（exponential）來思考。幾乎所有的圖表呈現的都是指數成長，我們幾乎所有數據都使用對數線性圖（log-linear charts），也就是 X 軸是線性的，Y 軸是對數的。
一切都在呈指數級上升——營收呈指數成長、使用量呈指數成長，對工程師來說這是最刺激好玩的挑戰，也很感謝大家一路以來的包容。基本上所有指標都在攀升，包括產出的程式碼量。
自從我們推出 Claude Code 以來，Anthropic 內部員工撰寫的程式碼行數與提交的 Pull Request 數量成長了數百個百分點。我記得我們公開分享過的最新數據是成長了大約 3 倍，但那個數據其實已經非常過時了，現在的數字遠高於此。
主持人： 成長 3 倍的是什麼？
Boris Cherny： 是 Anthropic 每位工程師產出的程式碼量。
主持人： 我明白了。所以即使工程團隊規模翻了好幾倍，人均產出依然暴增。通常隨著工程團隊擴大，人均生產力是會下降的。
Boris Cherny： 沒錯。我在 Meta 時的職責之一就是負責所有程式碼庫的程式碼品質。我們之所以重視這個，是因為它直接影響生產力。如果程式碼品質高，工程師效率就高，這一點我們在實證上有充分數據支持。
通常發生的情況是：規模變大導致程式碼品質下降、生產力滑落；另一個因素是新加入的工程師會頻繁詢問老資歷工程師：「這個怎麼做？那個怎麼做？」導致被問的人無法專心寫程式，團隊需要經歷漫長的磨合適應期（ramp-up time）。
但在 Anthropic，我們看到的第一個現象是：新人入職的適應期縮短到了只有兩天。過去通常需要數週，現在只要兩天，因為你只要直接去問 Claude。
我們甚至還得對新加入的同仁做宣導，因為有人會跑來問：「我要怎麼查詢資料庫？」我們的回答是：「打開 Claude，在 Claude 程式碼庫中執行它，讓 Claude 去幫你查資料庫。」因為裡面就有專門查詢資料庫的 Skill，它自己全都知道。
主持人： 那麼在 2026 年新加入的工程師中，有多少人真正親手寫過程式碼？
Boris Cherny： 嗯……這取決於你如何定義「寫程式碼」。
主持人： 等等，你怎麼定義「寫程式碼」？
Boris Cherny： 對我而言，工程的演進一直都是如此。你看，我祖父當年在蘇聯時期是用打孔卡（Punch Cards）寫程式的。對他來說，寫程式就是拿紙卡在上面打孔，然後餵進一台巨大的機器裡，機器轟隆轟隆運轉一陣子之後吐出答案，那就是當年的寫程式。
這就像我父親寫過大量的組合語言（Assembly），他以前可能會嘲笑我寫 Python，說：「你那根本不算寫程式！」
主持人： 沒錯！「那不是真正工程師在做的事，太高階了！」
Boris Cherny： 但這本來就是程式設計的本質——抽象層級（level of abstraction）永遠在向上推升。從實體開關到打孔卡、到組合語言，再到 COBOL、FORTRAN、Java 等高階語言，接著又演進到 JavaScript 和 Python 等超高階語言。這種趨勢從未停止過。我認為我們現在做的事情，只不過是這條演進光譜上的延續。
對我個人而言，一年前我的寫程式方式是：在 IDE 裡藉由自動補全來寫程式碼。到了十一月，我直接把我的 IDE 解除安裝了，因為我根本用不到它。我當時想，過去一個月我一次都沒打開過它，那乾脆直接刪除算了。
在那段時期，我通常會並行跑 5 到 10 個 Claude，我所謂的寫程式就是撰寫 Prompt 引導 Claude 去寫程式。而現在，我覺得抽象層級又更上一層樓了：我甚至不再直接 Prompt Claude 了，而是有自動化的循環（Loops）在持續運行，由這些 Loop 負責去 Prompt Claude 並決定該做什麼。我的工作變成了「寫這些 Loop」。這就是我認為在接下來幾個月、乃至今年底即將發生的下一波轉變。
第四部分：角色界線的消融與 Claude Co-work 的誕生
主持人： 假設台下有一個工程師（假設是我，雖然顯然不是我），想加入 Anthropic 的工程團隊，你今天會如何評估應徵者？
Boris Cherny： 我認為在我們團隊，特別是 Claude Code 團隊，我們非常看重「通才」（Generalists）。
大約半年前我們開始發現，團隊中幾乎已經沒有人在做傳統定義上的純工程工作了——過去的流程是：使用者研究員去訪談使用者，把結論寫成規格文件交給設計師；設計師做出原型圖交給產品經理（PM）定義範圍；最後才交給工程師去實現。
我在微軟工作過，對這種瀑布式流程再熟悉不過了，過去幾十年都是這樣運作的。但我們意識到，團隊現在已經完全不這麼做事了。
我們的團隊一直都比較偏向原型敏捷開發，但大約六個月前我們發現：團隊裡的每位工程師都在做需求範圍定義（Scoping），每個人每天都在直接面對使用者，大家都在做設計；每位工程師都能自如地抓取資料、進行資料科學分析、搭建儀表板。所有的角色似乎正在融合、消融，凝聚成單一的「創造者」（Builder）——我想 Satya Nadella（微軟 CEO）也是用 Builder 這個詞來形容。它有點類似產品工程師（Product Engineer），但你甚至不一定需要具備傳統工程師的背景。
主持人： 沒錯，現在甚至不需要是傳統工程師了。
Boris Cherny： 是的。我們團隊有設計師直接提交上線程式碼、財務人員提交程式碼、幕僚長（Chief of Staff）也在提交程式碼。
主持人： 事實上，我們 Acquired 播客的所有基礎設施現在也迅速轉移到了 Claude Code 上。我能分享一個 Acquired 內部的小趣事嗎？
我們是一個音訊播客，但 YouTube 不允許只上傳純音訊，必須附帶畫面內容，而且畫面得有些看頭。很長一段時間裡，我們的影片就只是一張黑畫面轉成的 MP4。做逐字稿本來是個好主意，但我們之前沒有逐字稿，因為人工製作逐字稿要花上一整週。幸好現在有了 AI。
總之，我用 Claude Code 粗糙地寫了一整套腳本——應該說我和 Claude 一起寫的。然後在某個時間點，我把這套東西甩給 David，跟他說：「你能接手繼續弄這個嗎？」
一開始 David 有點抗拒，但後來他確實打開了終端機。
主持人（David）： 沒錯，自從大學上完資工課之後，我就再也沒打開過終端機了。結果就在那次我被迫打開終端機的隔天，Anthropic 就推出了 Claude Co-work！
Co-work 的主打訴求就是：如果你想要 Claude Code 的強大功能，又不想面對終端機、輸入指令、安裝 npm 等繁瑣步驟，這就是為你準備的。我們當時還開玩笑說，一定是 Anthropic 聽說 David 竟然被迫打開終端機了，於是緊急決定「我們必須在一天之內把它發布出去！」
主持人： 我想藉這個話頭請教：跟我們聊聊 Claude Co-work 的故事吧。因為在我看來，不想打開終端機的人群規模，遠遠大於懂得打開終端機的人群。先推出 Claude Code，過了好長一段時間才推出 Claude Co-work，這背後的脈絡挺耐人尋味的。
Boris Cherny： 確實如此。說實話，現實情況跟你們剛才說的故事非常像。
我記得在四月左右，走進辦公室時，在我們 Claude Code 小組旁邊坐著幾位資料科學家。我走過去看到其中一位資料科學家螢幕上正開著 Claude Code。要知道，當時 Claude Code 還只存在於命令列終端機中，還沒有桌面版，也沒有手機版，你必須真的具備一定技術基礎才能用。
我問 Brandon：「老兄，你在幹嘛？你在幫我們內部試用（dogfooding）、研究這玩意兒是什麼嗎？」因為他才剛加入團隊不久。結果他說：「沒有啊，我正在用它做資料分析。」
他自己摸索出怎麼打開終端機、安裝 Node.js、安裝 Claude Code 並設定好 API Key——當時我們甚至還沒有訂閱制方案——他就直接用它來做資料分析。到了隔週，所有的資料科學家桌上都開著好幾個 Claude Code 視窗在跑分析，因為它在這方面實在太強大了。
快轉到五、六月左右，Twitter 上出現了一位用戶——不知道你們有沒有看到？他用 Claude Code 來幫他種番茄！他架設了一個小網路攝影機去監控番茄盆栽，由 Claude 根據監測畫面調節番茄的養分供給，持續監控了數週。直到某天小番茄發芽結實了，Claude 還回應說：「這太令人欣喜了，我們所有的努力都得到了回報！」
我看到那則推文時心想：「我的天啊，時機成熟了。」我們開始真正打入主流大眾市場。讓工程師理解這項工具花了一段時間，而當他們終於理解後，我們開始看見非工程師的關鍵多數（critical mass）也湧了進來。
當這種潛在需求如此強烈時，就意味著必須專門為其打造一款產品。於是我們開始探索各種想法。Co-work 本身是在大約一週多一點（大概八、九天）的時間內打造出來的，而且是 100% 使用 Claude Code 寫出來的。它當時只是眾多原型點子中的一個，但只要一做出來，我們立刻認定：「就是它了。」
第五部分：產品設計的取捨與人機互動型態
主持人： 你們放棄了哪些其他方案？如果當初的設計目標是「把 Claude Code 的威力賦予那些不想碰終端機的人」，這並非單純的一對一功能平移，你必須在產品設計上做出非常明確的取捨，去定義它該承接哪一部分的工作。
Boris Cherny： 我們嘗試過很多原型，多到我都記不清了。
我們曾嘗試過基於 Slack 的方案，但效果不好，因為打造體驗足夠出色的 Slack 聊天機器人非常困難。我們也嘗試過基於 Web 網頁的多個原型，但沒有一個讓人覺得體驗足夠好。在瀏覽器裡運作總讓人感覺少了點什麼；更重要的是，如果它只跑在瀏覽器裡，它就無法取用你電腦本地的工具。
舉例來說，我的桌面上有個 Word 檔，但我沒辦法直接讓網頁裡的東西讀取它。對本地檔案系統的存取能力是不可或缺的。光是「必須手動把檔案拖曳進瀏覽器」這點微小的阻力，就足以破壞整個流暢體驗。
這又回到了我們對產品的核心思考：我們打造自己真心熱愛的產品。你必須做出連你自己都會愛上、每天都會使用的東西，然後其他使用者才有可能會喜歡，才有可能對大眾有所助益。
主持人： 有一件事讓我挺意外的：由於現在直接在 Claude 網頁對話視窗裡就能自動執行很多 Python 程式碼，我使用 Claude Code 的頻率反而降低了。
我有時會問一些需要大量資料分析的問題，我能看到它在後台自動寫程式分析資料，接著寫出一堆 HTML、CSS 和 JavaScript，當場渲染出一個全新的互動介面讓我把玩。這背後其實調用了大量的 Claude 程式碼生成能力，但我自始至終都沒有直接接觸過 Claude Code 這款獨立產品。
Boris Cherny： 沒錯。這背後有一個有趣的理論問題：你希望計算發生在什麼時機？是在你向模型採樣、進行推論的「即時過程」中？還是希望「預先計算」（precompute）？
也就是說，你可以讓模型寫出一套程式，之後你就可以反覆執行該程式，而反覆執行的過程對你來說是零推論成本的。我們本質上希望盡可能做到後者。
但這很大程度上取決於模型本身。模型本身就是以軟體的形式存在，它需要一種與世界互動的媒介；正因為它本身是軟體，它最自然的互動方式就是「寫程式」，那是它天生講的語言，也是它最理解的邏輯。
從 Claude Code 最初期開始，在第一個版本中，我給了它一個 Bash 命令列工具，讓它可以在我的電腦上執行指令。我完全沒有教它任何工具的使用說明，它自己就搞懂了該怎麼用。
有一個我講過無數次的小故事：有一次我問它「我現在正在聽什麼音樂？」它直接開啟了 Bash 工具，自己寫了一小段 AppleScript 腳本——我這輩子從沒寫過 AppleScript——它執行該腳本打開我的音樂播放器，然後回答我：「你現在正在聽某某歌曲。」在當時那還是 Sonnet 3.5 的時代，以現在的標準來看那還不算非常聰明的模型，但它就已經懂得這麼做了。因此，寫程式碼、調用工具與世界互動，似乎就是模型骨子裡想要做的事情。
第六部分：組織架構、扁平化與「權杖至上」思維
主持人： 我想暫時跳脫具體的產品問題，來聊聊企業文化與組織架構設計。你的職稱是「技術團隊成員」（Member of Technical Staff, MTS），我想很多人也有這個頭銜。這個機制是怎麼回事？有什麼優缺點？你會推薦在座的企業採用嗎？
Boris Cherny： 我剛加入時覺得最糟糕、最困擾的一點是：在 Slack 上傳訊息給某個人，頭銜上全都寫著 MTS，你完全不知道對方是設計師、工程師還是主管，你甚至不知道他們負責什麼業務。
但現在我其實非常喜歡這個設計。我在 Meta 時就很欣賞一點：所有軟體工程師的頭銜都一律是「軟體工程師」，沒有所謂的「資深工程師」或「主任工程師」。
主持人： 真的嗎？
Boris Cherny： 真的沒有這些抬頭。我喜歡這樣的原因在於：當你給了人們資深頭銜時，有時他們提出糟糕的想法，大家會出於對職級的敬畏而盲目採納，但實際上大家應該勇於反駁質疑。將所有人放在同一個起跑點上，是一種非常好的文化約束力。
主持人： 但私底下大家難道不會知道嗎？例如「雖然我們頭銜都一樣，但我很清楚你是高等級別的工程師」。
Boris Cherny： 有時候會知道，但很多時候根本不知道。
當年在 Facebook，我剛加入時只是個 L4 工程師。我有個想法，直接跑去找負責連網業務的副總裁（VP），跟他說：「我有個點子，我們把它做出來吧。」那位 VP 根本不知道我是幾級工程師。雖然那個點子很糟、最後沒成功；後來我找了另一位 VP 又試了一次，也沒成功；但第三次嘗試時成功了。於是我們組建了團隊，開始做專案。
現在在我們團隊，我隨時隨地都能看到這種現象：傳統的年資概念在許多方面已經不再重要了。那些擁有 20 年、30 年經驗的工程師，身上有太多舊習慣必須「忘掉」（unlearn）。你往往得花上數個月幫助他們拋棄那些已經不再適用的舊習慣。相反地，有時剛畢業的新人加入團隊，反而能教我如何更巧妙地使用 Claude Code，因為他們是用原生 AI 思維在思考，而這並不是我直覺的第一反應。加上每次新模型推出時，你都必須重新校準、重新學習。
回到 MTS 頭銜這件事，我認為這非常關鍵。因為工程師、PM、設計師、使用者研究員之間的所有舊有界線，到今年底都將徹底消失。這種扁平的頭銜幫助我們今天就能清晰預見並實踐這一點。在 AI 實驗室裡，你必須推動每個人以這種方式思考未來、以更貼近 AGI 的方式去構建工作流程。
主持人： 針對這點，能不能為在場的所有創辦人與企業做個更宏觀的延伸建議？面對今年底以及未來幾個月的變化，創辦人和企業在思維心態上需要做出什麼轉變？
Boris Cherny： 如果是我，我今天會做的一件事就是：給每位員工盡可能多的 Tokens（運算額度）。雖然身為 AI 實驗室員工我難免會這麼說，但借用黃仁勳的名言：「買得越多，省得越多。」
這是我會著手的第一步：盡可能給員工大量 Tokens，讓他們放手去實驗。
另一件事是：讓所有專案都處於稍微「資源不足」（underfund）的狀態。如果有一個專案你直覺覺得需要 4 位工程師，那就只派 2 位工程師，並給他們大量的 Tokens，讓他們自己想辦法解決。
很有可能他們真的能搞定。因為他們會被迫將許多環節自動化、簡化流程；而正因為他們把流程自動化了，下一次處理時會做得更好、成本會更低。
主持人： 這會產生複利效應——在 Tokens 之外限制其他人力資源，反而會帶來複利成長。
Boris Cherny： 沒錯。在商業與產品營運中，你每天要做出無數決策。擁有一套核心原則是非常好的事，這樣你可以仰賴原則行事，而不需要每次都做臨時決策。創辦人和公司通常會有這種指導原則文件，而現在模型也能夠遵守並運用這些原則，通常這會以 Skills 的形式體現。
當然，如果有某個具體應用場景徹底爆發、消耗了大量 Tokens，那時你再介入進行系統優化、提升效率即可。
主持人： 總結你的建議：減少人員編制，把預算從人力轉移到 Tokens 上。其結果是：前期投入成本看似提高了，但後續的持續營運成本卻大幅降低。這就像是「預先編譯」一樣，你預先完成了一大堆自動化工程，使得後續反覆發生的任務變得輕鬆且高度精簡。
Boris Cherny： 可以這麼理解。而且因為專案投入的人力變少了，代表全公司的員工總體上能做的事情反而變得更多。
主持人： 對團隊構建而言，這讓人感受到極大的衝擊。大家都習慣於擁有自己的職稱和專業領域，為身為優秀的 PM 感到自豪——寫大量的產品架構部落格；或者身為設計師，迫不及待展示漂亮的設計作品集。難道我們所有人在未來 12 個月內，都必須拋棄「我是某某專業」的執念，接受每個人本質上都是一袋「具有彈性的 Token 產生器」嗎？
Boris Cherny： 哇，Ben，你未免太樂觀了吧！
主持人： 這句話應該印成 T 恤！
Boris Cherny： 我的用詞可能會稍微不同，但意思差不多。
就我個人而言，我雖然當工程師有一段時間了，但我一直扮演各種不同的角色。我創辦過新創公司，做過業務商務端、產品端、使用者研究與設計。對我來說，我純粹熱愛打造產品，我並不在乎頭上戴的是不是工程師的帽子。
我現在看到的就是這個趨勢：我們正迎來「通才的黃金時代」。對於那些渴望涉足多個領域、做更多事情的人來說，現在是最有趣、門檻最低的時代。
第七部分：品味（Taste）的未來與結語
主持人： 最後一個問題，想請教你對「品味」（Taste）的看法。無論是你個人還是從 Anthropic 的角度來看，你如何看待品味？
Boris Cherny： 我覺得，每當我自以為我寫程式的方式有什麼獨特之處時，事實往往證明我是錯的。
我過去對程式碼該怎麼寫有各種強烈的執念。例如我非常熱衷於函式語言程式設計（Functional Programming），喜歡 Haskell、Scala 這類奇特的函式語言。在最初期，我為我們的程式碼庫定下一條規矩：整個程式碼庫不准有 Class（類別），只能有 Function（函式），因為這是我寫程式的習慣與品味。
結果到了週末，其他工程師開始偷偷把帶有 Class 的修改提交上線。到了週一我發現後，就會把那些 PR 挑出來說：「不行，不要這樣寫。」
但後來，模型開始接管並撰寫所有的程式碼，而模型預設就開始大量撰寫 Class。那時我心想：「好吧，或許模型才是對的。」也許我個人的堅持有些愚蠢，純粹是我個人的怪癖。更重要的是，商業目標達成了，而且交付速度更快，寫出來的程式碼品質其實也很不錯，並且隨著時間持續進步。
所以每當我覺得自己有某種獨特之處時，通常很快就會被證明是我想多了。
現在針對目前的模型能力，很多人常說：「最後的核心優勢（Alpha）就是產品品味（Product Taste）。」但我認為這個優勢可能也即將消逝。
品味或許是當下的核心優勢，但此時此刻，我已經有數百個 Claude 在後台同時運行各項任務：有的在監控 Twitter 上的反饋、有的在分析 GitHub Issues、有的在爬梳 Slack，幫忙推敲接下來該做什麼功能。目前提出的大多數點子確實還不夠好，但大概有 20% 是非常優秀的。
如果再等待下一代模型——放眼未來三到六個月——大部分產出的點子可能都會變得非常出色。到時候，我們引以為傲的另一座堡壘又會被攻克。
主持人： 你有什麼猜想嗎？人類最後還能有什麼獨特且擅長的事情？
Boris Cherny： 我認為，我們最終要教會模型的東西，是價值觀（Values）。就像我們教導自己的孩子如何成為一個善良正直的人一樣，我們最終要去教會模型：如何成為一個良善有益的模型。
主持人： 太精彩了，這真是一個無比深刻的總結。Boris，非常感謝你，這場對話極具啟發性。
Boris Cherny： 謝謝你們。