整理 | 褚杏娟

Boris Cherny 近期訪談不斷。他是 Anthropic 公司 Claude Code 的創(chuàng)始人兼負(fù)責(zé)人，他曾在 Meta 公司擔(dān)任首席工程師五年，并著有《Programming TypeScript》一書。

在最新的 Pragmatic Engineer 節(jié)目中，他詳細(xì)分享了 Claude Code 的構(gòu)建過程以及 Boris 的日常使用經(jīng)驗(yàn)。他深入分享了工作流程的細(xì)節(jié)，包括并行 agent、PR 結(jié)構(gòu)、代碼 review 模式，以及系統(tǒng)如何從大型代碼庫中獲取上下文信息。

Boris 還介紹了 Claude Cowork 的構(gòu)建過程。隨著編碼變得越來越容易上手，工程師的角色正在發(fā)生轉(zhuǎn)變。節(jié)目中，他分享了這種轉(zhuǎn)變在實(shí)踐中意味著什么，哪些技能變得更加重要，以及產(chǎn)品、工程和設(shè)計(jì)之間的界限為何變得模糊。

他還提到，Anthropic 所有人職稱均為 Member of Technical Staff，核心是承認(rèn)“大家都在摸索，無絕對正確答案”，鼓勵通才模式，打破角色邊界。團(tuán)隊(duì)文化拒絕大量文檔（不寫 PRD），傾向“直接做原型、演示驗(yàn)證”，而非“寫出來對齊”，原型化是產(chǎn)品構(gòu)建的核心方式。

Boris 提醒，AI 進(jìn)展極快，需保持“新手心態(tài)”和智識上的謙遜，以前失敗的想法可能因模型變強(qiáng)而可行，需不斷調(diào)整自身預(yù)期和工作方式。AI 讓“寫代碼”從工程師專屬技能變成人人可及的能力，類似印刷機(jī)顛覆抄寫員，雖有失落感，但本質(zhì)是工具普及，會催生全新職業(yè)和可能性。

他認(rèn)為，現(xiàn)在工程師應(yīng)放下對代碼風(fēng)格、語言、框架的執(zhí)念（模型可靈活適配）；需堅(jiān)持“假設(shè)驅(qū)動”思維、好奇心、開放心態(tài)和適應(yīng)力，通才會越來越被重視。此外，當(dāng)下“短注意力”成為被獎勵的技能，因?yàn)楣ぷ髂Ｊ綇纳疃瘸两睫D(zhuǎn)向多 agent 管理。

我們對這次訪談進(jìn)行了翻譯，并在不改變原意基礎(chǔ)上進(jìn)行了刪減，以饗讀者。

靠“感覺”創(chuàng)業(yè)

主持人：你是怎么進(jìn)入科技行業(yè)、開始做軟件工程和編程的？

Boris： 這要從很早之前說起，大概有兩件事。大概在我十三歲左右的時候，我開始在 eBay 上賣自己的舊 Pokémon 卡牌，我發(fā)現(xiàn) eBay 的商品頁面可以寫 HTML，我就去看別人賣 Pokémon 卡的頁面，發(fā)現(xiàn)有些人的頁面字體特別大、顏色特別鮮艷之類的。后來，我還發(fā)現(xiàn)了一個叫 blink tag 的標(biāo)簽，如果在頁面里加上 blink tag，頁面里的文字就會閃爍。結(jié)果神奇的是，我的卡牌就能賣到 99 美分，而不是原來的 49 美分。我就是這樣開始接觸 HTML 的，后來我買了一本 HTML 的書正式學(xué)了一下。

第二件發(fā)生在差不多初中的時候。那時候，我們數(shù)學(xué)課用的是那種老式的 TI83UH 圖形計(jì)算器。我后來發(fā)現(xiàn)，如果我把數(shù)學(xué)題的答案直接寫成程序放進(jìn)計(jì)算器里，考試的時候就能得到更好的成績。

主持人：所以你寫了一些小程序？

Boris： 對，一開始就是把答案寫進(jìn)程序里。但后來考試變難了，我就沒法提前知道題目的系數(shù)之類的參數(shù)，所以我開始寫“求解器”，而不是直接寫答案。再后來數(shù)學(xué)更復(fù)雜了，我就不得不從 Basic 語言降到底層一點(diǎn)的 Assembly，只是為了讓程序運(yùn)行得更快一點(diǎn)。

主持人：所以你在高中就開始寫匯編了？

Boris： 大概是初中或高中吧，可能是八年級或九年級左右。后來發(fā)生了一件挺有意思的事：我班上的同學(xué)開始發(fā)現(xiàn)我有這個“外掛”，他們有點(diǎn)嫉妒。于是我買了一根小小的串口線，把程序也傳給他們，結(jié)果下一次數(shù)學(xué)考試全班都拿了 A。老師就開始懷疑到底發(fā)生了什么，最后她發(fā)現(xiàn)了這件事，不過只是說：“這次就算了，下不為例。”

但對我來說，這件事一直很實(shí)際。我在學(xué)校學(xué)的是經(jīng)濟(jì)學(xué)，后來輟學(xué)去做創(chuàng)業(yè)公司。我從來沒覺得編程會成為一份職業(yè)。在我看來，編程一直只是一個工具，用來做東西、做有用的東西。

我做的第一個創(chuàng)業(yè)項(xiàng)目，其實(shí)挺荒唐的。再后來我又做了幾個不同的創(chuàng)業(yè)項(xiàng)目，然后很早就加入了 YC 體系的一家創(chuàng)業(yè)公司，算是那家公司最早的員工之一。

主持人：那你是怎么決定一個創(chuàng)業(yè)做完之后再去做下一個的？

Boris： 主要是看“感覺”。它從來不是一條直線，你總是在不斷調(diào)整方向。在這個過程中，你得搞清楚市場到底要什么、用戶到底要什么，而那個答案往往和你最初的想法完全不同。

你最開始的那個想法，本質(zhì)上只是一個假設(shè)。而這個假設(shè)，幾乎總是要調(diào)整一次、兩次、甚至三次，才能慢慢逼近真實(shí)。

舉個例子。后來我加入了一家叫 Agile Diagnosis 的醫(yī)療軟件公司，也是 YC 早期的項(xiàng)目，大概是 2011、2012 年左右。我們想做一款給醫(yī)生用的軟件。當(dāng)時我們觀察到，不同醫(yī)院在臨床決策流程上差別很大，其中芝加哥有一家醫(yī)院，在心臟相關(guān)癥狀的診斷流程上做得特別好。我們就想，如果全美國的醫(yī)院都用上這套流程，治療效果會不會更好？

于是我們嘗試把這個流程標(biāo)準(zhǔn)化，做了一個決策樹軟件給醫(yī)生用。團(tuán)隊(duì)很小，就幾個人，我寫了其中一部分代碼。那是一個運(yùn)行在瀏覽器里的軟件，因?yàn)橐尸F(xiàn)可視化的決策樹，我還寫了一個 SVG 渲染器。但當(dāng)時的醫(yī)院環(huán)境很老舊，瀏覽器基本還是 Internet Explorer 6。

產(chǎn)品上線后，我們盯著 DAU（日活用戶）曲線，結(jié)果是一條直線，完全平的。我們在幾家醫(yī)院做了試點(diǎn)，包括 UCSF。那時我們在 Palo Alto，我干脆騎上摩托車跑到 UCSF，跟著醫(yī)生一起工作了好幾天，想親眼看看他們到底是怎么用這個產(chǎn)品的。后來我終于發(fā)現(xiàn)問題所在：醫(yī)生根本沒有時間坐下來用電腦。

他們的節(jié)奏是這樣的：看完一個病人到下一個病人之間，可能只有五分鐘。這五分鐘里，你要走到走廊另一頭的電腦站，打開那臺非常老舊的電腦，開機(jī)就要三分鐘；然后打開 Internet Explorer 6，又要 30 秒；再打開我們的應(yīng)用，還要登錄。等這一套流程走完，五分鐘已經(jīng)沒了，下一個病人已經(jīng)在門口等著了。

所以，我們做了一個大調(diào)整：把整個產(chǎn)品重寫成 Android 版本。但結(jié)果呢？醫(yī)生還是不用。我們又繼續(xù)觀察，發(fā)現(xiàn)了一個有意思的細(xì)節(jié)：醫(yī)生查房的時候，身后通常跟著一群住院醫(yī)（residents）。這其實(shí)是一個社交場景，醫(yī)生需要被看作權(quán)威，如果他們一直低頭看手機(jī)，那個形象就不對了。

這時候我們意識到，也許醫(yī)生根本不是我們的目標(biāo)用戶。真正應(yīng)該用這個產(chǎn)品的，可能是護(hù)士、X 光技師這類角色。但也就是在這個節(jié)點(diǎn)，我選擇了離開，因?yàn)檫@個方向已經(jīng)離我最想做的事情越來越遠(yuǎn)了。

對我來說，最有意思的事情始終只有一個：尋找 product-market fit（產(chǎn)品和市場的匹配）。這個過程永遠(yuǎn)充滿意外。你不能只抱著一個宏大的想法不放，因?yàn)槟莻€想法大概率是錯的。你能做的就是提出一個個假設(shè)，然后一路往下驗(yàn)證，直到看清什么才是真正對的。

主持人：這個故事特別有意思。很多成功故事，大家只聽到最后成功的那條路徑。但現(xiàn)實(shí)中，大多數(shù)創(chuàng)業(yè)其實(shí)都是這樣曲折的。還有一點(diǎn)讓我印象很深，當(dāng)時你是作為軟件工程師被雇傭的，那時候還沒有“產(chǎn)品工程師”這種說法。你看起來并不是只關(guān)注技術(shù)，而是關(guān)注最終結(jié)果。

Boris： 當(dāng)然，不同工程師有不同風(fēng)格。就拿我現(xiàn)在的團(tuán)隊(duì)來說，Jared Sumner 屬于那種技術(shù)極其深厚的人，對系統(tǒng)的理解比我見過的任何人都強(qiáng)，團(tuán)隊(duì)里確實(shí)需要這種深度。但對我來說，工程一直是一件很務(wù)實(shí)的事。我一直是個“通才”，做設(shè)計(jì)、做工程、做用戶研究，本質(zhì)上都是同一件事。

我第一份工作是在十六歲。當(dāng)時只是想買一把電吉他，就開始做自由職業(yè)。我想：“那就做網(wǎng)站吧?！蹦菚r候還沒有 Fiverr，有一些別的自由職業(yè)平臺。我建了個網(wǎng)站，到處投標(biāo)接項(xiàng)目。拿到第一筆報酬后，我直接把所有錢拿去買了一把電吉他。

這個經(jīng)歷很有意思。當(dāng)你一個人做事情時，就必須同時扮演很多角色：寫代碼、做設(shè)計(jì)、做會計(jì)、跟客戶溝通，所以我的工作方式一直是這樣。

在 Meta，經(jīng)歷了“黑客文化”的消失

離譜的 Ins 技術(shù)棧

主持人：做了幾家創(chuàng)業(yè)公司之后，你后來加入了 Facebook（現(xiàn)在叫 Meta），在那里待了七年。能不能講講你在那里的經(jīng)歷？你做了哪些項(xiàng)目？學(xué)到了什么？

Boris： 我最開始是在 Facebook Groups 團(tuán)隊(duì)，是 Vlad Kolesnikov 招我進(jìn)去的。我記得他現(xiàn)在好像還在 Facebook，只是換了別的團(tuán)隊(duì)。那段經(jīng)歷很有意思，因?yàn)槲耶?dāng)時和一群早期 JavaScript 開發(fā)者一起工作，自己也寫了很多 JavaScript。

后來回頭看會發(fā)現(xiàn)，我一直在和同一批人不斷交集。比如 Vlad 之前做過 Bolt.js，這是 Ads Manager 使用的框架，后來 Facebook 內(nèi)部轉(zhuǎn)向 React 之后也和這套東西有些關(guān)聯(lián)。

我當(dāng)時在 Facebook Groups 工作，對這個產(chǎn)品特別興奮，因?yàn)樗氖姑恰鞍讶撕退麄兊纳鐓^(qū)連接起來”。我自己一直是 Reddit 的重度用戶，從青少年時期就開始用了，因?yàn)槲疑磉吰鋵?shí)沒有會寫代碼的人。哪怕在大學(xué)，我也幾乎不認(rèn)識程序員。

老實(shí)說，我以前甚至有點(diǎn)不好意思承認(rèn)自己會寫代碼，因?yàn)槟菚r候這件事太“nerdy”了。我覺得這只是我會做的一件事，但我更想成為那種“酷一點(diǎn)的人”。后來我在 Reddit 上發(fā)現(xiàn)了一個編程社區(qū)，當(dāng)時特別震驚：原來還有其他人也喜歡這個東西。這個愛好其實(shí)非常小眾、非常奇怪，但突然之間你就找到了志同道合的人。那種連接感讓我非常興奮，所以我一直很想?yún)⑴c到這種事情里，在某種程度上貢獻(xiàn)一點(diǎn)。

我在 Facebook Groups 工作了一段時間，做過很多項(xiàng)目，后來成了這個團(tuán)隊(duì)的領(lǐng)導(dǎo)。隨著團(tuán)隊(duì)擴(kuò)大，工作內(nèi)容也發(fā)生了變化：一開始更多是寫代碼、做產(chǎn)品，后來越來越多變成寫文檔、做協(xié)調(diào)、做組織管理、把任務(wù)分配給其他人。

那段時間 Facebook 的文化也在變化。早期那種“黑客文化”逐漸消失了，開始有更多文檔流程、對齊會議，還有很多工作圍繞隱私、安全這些基礎(chǔ)問題展開。坦白說，在 Facebook 早期高速增長的時候，很多地方其實(shí)是“先做再說”，留下了不少技術(shù)債和制度債，到了后來就必須把這些債還掉。

后來我又在 Instagram 工作了幾年。那段經(jīng)歷也挺有意思。當(dāng)時我妻子拿到一個工作機(jī)會，她特別興奮，跑來問我：“我拿到這個 offer，但我們得搬家，可以嗎？”我說：“沒問題啊，我做的是科技行業(yè)，在哪都能遠(yuǎn)程工作。這個工作在哪？”她說：“在奈良。”我說：“奈良在哪？”她說：“日本鄉(xiāng)下的奈良。”

主持人： 還得跨時區(qū)。

Boris： 對，時區(qū)也不一樣。那會兒大概是 2021 年，后來我就想找個愿意“掛靠”我的團(tuán)隊(duì)，因?yàn)閮?nèi)部有一套很玄學(xué)的 HR 規(guī)則，比如你必須在某個時區(qū)、必須和某個團(tuán)隊(duì)一起辦公之類的。剛好 Instagram 在東京有一個還在萌芽階段的小團(tuán)隊(duì)，負(fù)責(zé)人是 Will Bailey，他就是做出 Instagram Stories 的那個人，后來也當(dāng)過一段時間我的經(jīng)理。我們就決定一起把這個團(tuán)隊(duì)做大：我人在奈良遠(yuǎn)程，團(tuán)隊(duì)大部分人在東京。

那段時間我開始在 Instagram 上做事，然后就發(fā)現(xiàn)他們的技術(shù)?！喼彪x譜。Facebook 的 Web 服務(wù)技術(shù)棧當(dāng)時是全球頂配：從 Hack 語言、HHVM 運(yùn)行時，到 GraphQL 作為傳輸層，再到 Relay 這類客戶端庫，外加一整套 React 生態(tài)，全都特別強(qiáng)。世界上沒有哪個開發(fā)棧能比得上，而且它是徹底為性能、效率做過極致優(yōu)化的。

但到了 Instagram 就完全不是一回事了。Python 環(huán)境里類型追蹤不好用，跳轉(zhuǎn)到定義也不好用，用的是那種拼拼湊湊的 Django，再加上各種亂七八糟的東西，比如某個被 fork 過的……你知道的，反正很多東西都不好使，整體體驗(yàn)很糟。

我加入 Instagram 時是在日本的 Labs 團(tuán)隊(duì)，任務(wù)是給 Instagram 找“下一個 big thing”。我們試了一些方向，但我很快意識到，在那套技術(shù)棧上做事，我根本發(fā)揮不出來，因?yàn)闂Ｌ珷€了。所以我干脆轉(zhuǎn)去做 dev infra，這東西不修，啥都做不起來。

我們做了幾個大項(xiàng)目：一個是從 Python 遷移到 Facebook 的大 monolith（大一統(tǒng)代碼庫），另一個是從 REST 遷移到 GraphQL。這類遷移都不是一兩個月能搞定的，通常需要幾百個工程師、花上好幾年時間，代碼量也巨大，是非常重的工程。當(dāng)然，現(xiàn)在能做得更快了。

小扎：拿 20% 的時間去修技術(shù)債

主持人：但現(xiàn)在這些工具，尤其 AI 工具，遷移其實(shí)算是一個很適合的用例，對吧？

Boris： 這簡直就是它的完美用例。后來我就越做越深，在我離開 Instagram 時就一直在做 dev infra，帶著一批遷移項(xiàng)目往前推。

我也是在那段時間認(rèn)識了 Fiona Fung，她現(xiàn)在是 Claude Code 團(tuán)隊(duì)的 manager。我跟她合作過，她真的特別強(qiáng)領(lǐng)導(dǎo)力出色、技術(shù)深度夸張，而且對整個歷史脈絡(luò)和工程體系都有那種扎實(shí)的理解。我當(dāng)時就覺得，這個團(tuán)隊(duì)沒有比她更合適的經(jīng)理了。

后來我開始做 code quality 相關(guān)的事，Instagram 的工作范圍又?jǐn)U大了一些。到我走的時候，我在 Meta 內(nèi)負(fù)責(zé)的是全公司的代碼質(zhì)量，包括 Instagram、Facebook Messenger、WhatsApp、Reality Labs，以及其他那些代碼庫的整體質(zhì)量。

Meta 內(nèi)部有個項(xiàng)目叫 Better Engineering，大概是 2016 或 2018 年那會兒吧，Zuck 規(guī)定公司里每個工程師必須拿出 20% 的時間去修技術(shù)債，我們把這件事叫 Better Engineering。這里面有一部分是自下而上的，比如某個團(tuán)隊(duì)最清楚自己有哪些技術(shù)債要修。也有一部分是自上而下的，比如要做很大的遷移，要上新的語言特性、新的框架。

到了 Facebook 這種規(guī)模，每年會有成千上萬次遷移。我參與了很多這樣的事情，很快就發(fā)現(xiàn)，這事必須更有秩序一點(diǎn)。因?yàn)楫?dāng)時沒有明確目標(biāo)，沒人說得清楚最終要達(dá)到什么效果，也沒有追蹤機(jī)制。所以，我們做了幾件事：第一，建立一種集中式的方法，來給各種代碼質(zhì)量工作做優(yōu)先級排序；第二，去量化代碼質(zhì)量對工程生產(chǎn)力的影響，最后發(fā)現(xiàn)影響非常大。

主持人：你們怎么測的？最后發(fā)現(xiàn)了什么？

Boris： 方法有很多，其中一些我記得已經(jīng)公開發(fā)表過，但也不確定是不是全都發(fā)了。核心思路是做因果分析、因果推斷，去找“到底是什么因素讓工程師更高產(chǎn)”。

這里面有些因素來自代碼質(zhì)量，有些不來自代碼質(zhì)量。比如 Meta 后來推“回歸辦公室”而不是一直遠(yuǎn)程，這個決策也部分受這些研究影響，因?yàn)槲覀兇_實(shí)找到了一些相關(guān)性很強(qiáng)、而且我們認(rèn)為可能是因果關(guān)系的證據(jù)。

但代碼質(zhì)量本身對生產(chǎn)力的貢獻(xiàn)也非常明顯，能到兩位數(shù)百分比的提升。事實(shí)證明，就算在最大規(guī)模的公司里也是這樣。

主持人：聽起來還挺讓人安心的，因?yàn)楹苌儆械胤秸娴臅堰@件事量化。我順帶想到一點(diǎn)，對 大模型來說是不是也更容易“讀懂”和工作？我的直覺是，但確實(shí)這方面數(shù)據(jù)不多。

Boris： 對，我覺得很多大公司其實(shí)都寫過類似的東西。Facebook 應(yīng)該發(fā)過一些，微軟也寫過不少，谷歌也有。而且你想，如果你每做一個新功能，都要糾結(jié)“我到底該用框架 X 還是 Y 還是 Z”，原因只是代碼庫處在一個半遷移狀態(tài)，這些東西在代碼里到處都還殘留著。那你作為工程師會很痛苦，新入職的人也會很痛苦，模型也可能直接選錯，然后用戶還得反過來糾正它。

所以更好的做法其實(shí)很簡單：保持代碼庫干凈；一旦開始遷移，就把遷移做完。這對工程師很好，在今天對模型也同樣很好。

進(jìn)入 Anthropic，逐漸不再手寫代碼

主持人：然后你加入了 Anthropic。我聽過一個故事，你在那里的第一個 PR 被 Adam 拒了？

Boris： 是 Adam Wolf 拒的。他當(dāng)時算是帶我上手的 Buddy（入職導(dǎo)師）。我加入 Anthropic 之后，其實(shí)也在想自己下一步到底該做什么。我跟不同實(shí)驗(yàn)室的人聊了很多，而 Anthropic 對我來說幾乎是個很明顯的選擇，主要是因?yàn)槭姑校@是我個人最需要的東西。

再加上我親眼看到這些變化正在發(fā)生，你得有一套框架來理解它、思考我們在其中扮演什么角色。我自己還是個很重度的科幻讀者，這絕對是我最愛的類型。我家里書架很大，堆了很多書。我很清楚這件事如果走偏了，會壞到什么程度。所以我就覺得：這里有一群嚴(yán)肅的思考者，大家真的在認(rèn)真對待這件事，認(rèn)真想“我們到底能做什么，讓這件事走向更好的結(jié)果”。

我加入 Anthropic 之后，先做了一堆 ramp-up 項(xiàng)目，搗鼓了各種東西。我第一次提 PR 的時候還是手寫的，因?yàn)槲乙詾閷懘a就是這么寫的。

主持人：以前確實(shí)就是這么寫代碼的。

Boris： 對，以前就是這么寫。但哪怕在當(dāng)時，Anthropic 已經(jīng)有個東西叫 Clyde，它是 Claude Code 的前身，但非?！皽惡稀保?Python 寫的，啟動要四十秒，是研究代碼，不是 agentic 的。但如果你提示詞寫得足夠精準(zhǔn)，工具用得足夠“講究”，它確實(shí)能幫你寫代碼。

所以 Adam 把我的 PR 拒了，然后跟我說，“你應(yīng)該用這個 Clyde 來寫”，我說“好”，結(jié)果我花了半天才搞懂怎么用，因?yàn)槟愕脗饕欢?flags，還得用對方式。但一旦跑通，它就直接吐出了一個能用的 PR，基本是一把梭。

這大概是在 2024 年九月或者八月。對我來說，那是我在 Anthropic 的第一個“啊哈”時刻。因?yàn)槲乙郧傲?xí)慣了只是 IDE 里那種 tab completion、按行補(bǔ)全，我完全沒想到模型能直接給我搞出一個能跑的 PR。

Claude Code 源起

主持人：你加入 Anthropic 之后，我們深聊過，但這里也簡單回顧一下，Claude Code 是怎么從一個看起來像“副項(xiàng)目”或者“小 hack”里長出來的？

Boris： 我當(dāng)時在搗鼓很多不同的東西。我做過一些產(chǎn)品相關(guān)的東西，也短暫做過一點(diǎn)強(qiáng)化學(xué)習(xí)，只是為了理解“我正在構(gòu)建的那一層下面的那一層”到底是什么。

這其實(shí)也是我一直給工程師的建議：永遠(yuǎn)要理解你所在層級的下一層。這個很重要，因?yàn)樗鼤o你更深的理解，讓你在你真正工作的那一層有更多“可用的杠桿”。十年前我就這么說，到今天我還是這么說，只是“下一層”變得不一樣了。以前你寫 JavaScript，就得理解 JavaScript 的 VM、框架之類的；現(xiàn)在你得理解模型。

我搗鼓的很多東西，有的上線了，有的沒有，后來我想做一件很簡單的事：熟悉一下 Anthropic 的公開 API，因?yàn)槲抑皼]用過，但我又不想做 UI，我就是想很快 hack 一個東西出來。因?yàn)槟菚r候還沒有 Claude Code，還是在手寫代碼，于是我寫了一個小的 batch 工具，它會調(diào)用 Anthropic API，本質(zhì)上就是一個聊天應(yīng)用但跑在終端里，那時候 AI 就是這么用的。

我一直覺得工程師是第一批使用者。我們從對話式 AI 往 Agentic AI 遷移的時候，外界需要一點(diǎn)時間消化，但工程師其實(shí)很快就理解了?？涩F(xiàn)在你問非工程師“AI 是什么”，他們大概率還會說是對話式 AI，就是聊天機(jī)器人之類的。這也是為什么我對我們新做的 Cowork 這個產(chǎn)品很興奮，因?yàn)樗馨压こ處熀茉缈吹降哪欠N變化帶給更多人。

但我回頭看 Cowork，也會想到我們正在講的這個時刻。最早 Claude Code 其實(shí)也不是 Claude Code，它一開始就是個 chatbot，因?yàn)槲耶?dāng)時對 AI 的理解就是“聊天”。但我們必須繼續(xù)往前找“下一步是什么”。

當(dāng)時我做的那個 chatbot 有點(diǎn)用，但也就只是個 chatbot。接下來我想讓它“用工具”，因?yàn)?Tool Use 剛出來，我也不知道那到底是什么，就想試試。我只給了它一個工具，就是那個 batch 工具。但我自己其實(shí)也不知道 batch 工具還能干嘛，于是我問了它一個問題：我現(xiàn)在在聽什么歌？我當(dāng)時甚至不確定這事能不能做。結(jié)果它直接寫了一個小的 AppleScript 程序，用 sed 之類的東西打開我的音樂播放器，然后查詢當(dāng)前在播放什么。一把梭就寫出來了，用的是 Sonnet 3.5。

這幾乎是我在很短時間內(nèi)經(jīng)歷的第二次“Agent 級別接近 AGI”的震撼時刻。我突然意識到：模型就是想用工具。你給它一個工具，它會自己想辦法用這個工具把事情做完。

我覺得當(dāng)時大家對“AI 編碼”的思路，基本都是這樣：把模型塞進(jìn)一個盒子里，然后你來設(shè)計(jì)“接口”：你想怎么跟它交互、你希望它做什么。就像寫程序一樣，你先把模塊和函數(shù) stub 出來，說“這里是 AI”，然后整個系統(tǒng)的其他部分還是傳統(tǒng)程序。

但這其實(shí)不是理解模型的正確方式。正確的方式是：模型本身就是一個“主體”。你給它工具，給它能運(yùn)行的程序，讓它去運(yùn)行程序、去寫程序，但不要把它硬塞進(jìn)一個更大系統(tǒng)里、當(dāng)成某個被你框死的組件。

這有點(diǎn)像 “bitter lesson” 的一個變體?！癰itter lesson” 本身是一個很具體的框架，但它有很多推論。這里其中一個推論就是：讓模型做它該做的事。別把它關(guān)進(jìn)盒子里，別強(qiáng)行讓它以某種特定方式去表現(xiàn)。

為了研究“安全”而發(fā)布

主持人：最早你意識到這種能力的一個方式，就是給模型接入工具，先讓它能用 bash，然后再逐步接入文件系統(tǒng)，再接更多工具，對嗎？

Boris： 沒錯。我們先給它接了 bash。其實(shí)說“我們”有點(diǎn)夸張，最開始的三個月基本都是我一個人在做，后來團(tuán)隊(duì)才慢慢擴(kuò)起來。最早就是 bash，然后就是第二個工具。

主持人： 我記得我們上次做深聊的時候提到一個很有意思的事：當(dāng)你把這個東西做出來，并且它真的開始用這些工具寫代碼時，你們在 Anthropic 內(nèi)部其實(shí)討論過要不要只在內(nèi)部使用。因?yàn)樗诠こ虉F(tuán)隊(duì)里迅速傳播，讓大家的效率大幅提升。

Boris： 是的。最后我們決定把它發(fā)布出來，其中一個重要原因是我們可以在真實(shí)環(huán)境里研究安全性。Anthropic 實(shí)驗(yàn)室存在的核心原因就是安全，如果你問 Anthropic 的任何人為什么選擇來這里，大概率都會說是因?yàn)榘踩?/p>

如果從模型安全的角度來看，大致可以分成幾個層面。最底層是模型層，比如對齊和機(jī)制可解釋性；再往上一層是各種評測，這有點(diǎn)像把模型放進(jìn)培養(yǎng)皿里，在一種合成環(huán)境中研究它；再往上一層，就是把模型放進(jìn)真實(shí)世界，觀察它在真實(shí)環(huán)境中的表現(xiàn)：用戶是如何使用它的、如何討論它，以及真實(shí)環(huán)境中可能出現(xiàn)的風(fēng)險。

其實(shí)，在這樣的真實(shí)環(huán)境里可以學(xué)到非常多東西。通過這種方式，我們確實(shí)讓模型變得更安全。所以從內(nèi)部的角度來看，這個決定是完全正確的

主持人：聽你說它其實(shí)是一個研究項(xiàng)目，是為了觀察用戶如何使用模型，還是挺讓人意外的。因?yàn)楹芏鄤?chuàng)業(yè)公司是刻意在做開發(fā)者工具，希望獲得大量用戶，而你們這個研究工具反而獲得了更大的采用率。

Boris： 其實(shí) Anthropic 本質(zhì)上是一個研究實(shí)驗(yàn)室、一個安全實(shí)驗(yàn)室，產(chǎn)品只是附帶的東西。產(chǎn)品存在的意義是為了更好地服務(wù)研究，同時讓模型更安全。我們很多事情都是從這個角度來看的。

早期還有個挺有意思的事兒。當(dāng)時我們開了一次發(fā)布審批會，在討論要不要發(fā)布這個東西。會議室里有 Mike Krieger、Dario，還有一些其他同事，我們看內(nèi)部的采用率曲線，那條曲線幾乎是垂直向上的，從一開始就非?？鋸?。

主持人：現(xiàn)在基本是百分之百了吧？

Boris： 對，差不多是 100%。現(xiàn)在 Anthropic 每個技術(shù)員工每天都會用 Claude Code，非技術(shù)員工那邊也在快速接近 100%，增長速度非常快，比如銷售團(tuán)隊(duì)里現(xiàn)在差不多有一半在用，而且還在繼續(xù)增加，整體來說非常瘋狂。

當(dāng)時 Dario 還問了一個問題：“為什么增長這么快？你們是在強(qiáng)制大家用嗎？”我說：沒有，我們只是提供了這個工具。大家用腳投票，選自己喜歡的工具而已。結(jié)果大家就選了它。

主持人：你確實(shí)不像那種會強(qiáng)迫別人用自己工具的人。

Boris： 我們做的其實(shí)很簡單，把東西發(fā)布出去，然后認(rèn)真聽用戶反饋。我們會跟用戶聊，看他們怎么用，持續(xù)跟進(jìn)，然后不斷改進(jìn)。現(xiàn)在，Anthropic 內(nèi)部大概有 80% 的代碼是 Claude Code 寫的。對我來說更極端，基本所有代碼都是它寫的。

“它寫得比我好”

主持人：當(dāng)時發(fā)生了什么，為什么你開始完全信任它？你會審查多少代碼？

Boris： 其實(shí)那個轉(zhuǎn)變是瞬間發(fā)生的。我們開始用 Opus 4.5 那會兒，模型還沒公開發(fā)布，我們內(nèi)部先 dogfood 一段時間。模型能力一下子強(qiáng)了很多，我很快就發(fā)現(xiàn)自己根本不需要再打開 IDE 了。后來我干脆把 IDE 卸載了，因?yàn)檎娴牟恍枰?。這其實(shí)也是我一個月之后才意識到的，因?yàn)槲野l(fā)現(xiàn)自己已經(jīng)很久沒打開 IDE 了。

主持人： 很多人都有類似體驗(yàn)。Opus 4.5 發(fā)布之后，特別是冬天假期那段時間，我也有這種感覺。它在我熟悉的技術(shù)棧和代碼庫里寫出來的代碼，基本跟我自己寫的一樣好；而在我不熟悉的技術(shù)棧里，它寫得甚至比我好。

Boris： 我可以很坦白地說，它寫得比我好。

主持人： 我還不太愿意承認(rèn)這一點(diǎn)，但大概是真的。

Boris： 我是這樣意識到的：那年十二月，我在旅行，有點(diǎn)像“編程度假”。我去了歐洲，在不同城市之間穿梭，基本就是一邊旅行一邊寫代碼。我最喜歡的事情就是整天寫代碼。那段時間，我每天可能提交十幾、二十個 PR，所有代碼都是由 Opus 4.5 和 Claude Code 寫的，我沒有手動修改一行。到月底我回頭看，Opus 可能只引入了兩個 bug，而如果是我自己寫，大概會有二十個。

Claude Code 使用技巧

主持人：你現(xiàn)在是怎么用 Claude Code 的？比如并行開發(fā)、一些技巧，還有團(tuán)隊(duì)里總結(jié)出來的經(jīng)驗(yàn)。

Boris： 首先，沒有唯一正確的用法。我可以分享一些方法，但如果有人只是照抄，那其實(shí)是誤解了。我們把 Claude Code 做得非?？?hack，正是因?yàn)槊總€工程師的工作方式都不同，沒有兩個人的 workflow 是一樣的。就像每個工程師的工作站都不一樣：鍵盤、顯示器位置、各種配置都不同。我們其實(shí)是某種意義上的“手藝人”，會非常在意工具。

對我來說，一般是這樣的：我會開五個 terminal tab，每個 tab 都 checkout 一份代碼庫，也就是五個并行的 checkout，然后輪流在這些環(huán)境里啟動 Claude Code。幾乎每次開始的時候，我都會先用 plan mode，在終端里按兩次 shift+tab。如果 tab 不夠用，我就會切換到別的方式，以前常用 web 版本（Claude.ai/code），現(xiàn)在更多用桌面版。

桌面版 Claude Code 已經(jīng)集成很久了，就是 Claude 應(yīng)用里的一個 code tab。我很喜歡它，因?yàn)樗鼉?nèi)置了 worktree 支持，這對并行開發(fā)很方便。這樣你其實(shí)不需要多個 checkout，只需要一個，系統(tǒng)會自動幫你創(chuàng)建 Git worktree，每個任務(wù)都有隔離的環(huán)境。我以前不用 worktree 的原因是在命令行里操作它太麻煩了，要處理各種路徑和 cd 命令。

主持人：對一些不太熟悉的人來說，worktree 的概念是不用復(fù)制整個項(xiàng)目目錄，也能在不同分支上同時工作，對吧？

Boris： 可以這么理解。想象一下 Git 很便宜地幫你復(fù)制了五份代碼目錄，每一份都是隔離環(huán)境，但創(chuàng)建和刪除都很輕量。這樣你就能并行工作，不會互相干擾。

主持人：現(xiàn)在你們已經(jīng)原生支持這個了，但你的個人 workflow 還是老方式：多個目錄？

Boris： 對。其實(shí)我現(xiàn)在越來越多用桌面版，因?yàn)椴挥迷倬S護(hù)多個 checkout。我可以同時跑很多個 Claude 實(shí)例，也不用想太多。另一個意外的熱門用法是 iOS 應(yīng)用。我每天早上醒來，會先在手機(jī)上啟動幾個 agent。

主持人：只是它在云端運(yùn)行吧？

Boris： 對，在云端跑，所以需要配置一下環(huán)境。我的環(huán)境比較簡單，我們用 hooks 來配置，比如 session start hook。因?yàn)?Claude Code 很容易 hack，所以這種配置其實(shí)很簡單。說實(shí)話，這是我以前完全沒想到的。如果六個月前有人跟我說，我會有三分之一甚至一半的代碼是在手機(jī)上寫出來的，我肯定會覺得很離譜，但現(xiàn)在這就是我的日常。

主持人：你現(xiàn)在會用并行 agent。你是從什么時候開始這么用的？它怎么改變了你的工作方式？

Boris： 我覺得可以把它理解成兩種模式、兩套 workflow。剛接觸一個代碼庫的時候，我非常推薦用 learn mode，真的非常推薦。比如新加入 Claude Code 團(tuán)隊(duì)的人、新入職 Anthropic 的人，我們都會建議他們這樣用。具體做法是：如果你還沒試過，在 Claude Code 里輸入 /config，選擇輸出風(fēng)格，然后你可以選 learn 或 explanatory。我們一般推薦 explanatory，因?yàn)樵谀悴皇煜さ男麓a庫里，它往往更好用。

對我來說，一旦你熟悉了代碼庫，你想要的就是高產(chǎn)，想盡可能多地 ship，想把事情做得更有效率。這個時候角色就會切換。我現(xiàn)在基本不會再深度跟著每一步任務(wù)走了。我會在 plan mode 里啟動一個 Claude，讓它用 Opus 4、4.5 去先把事情推進(jìn)起來。我覺得到了 4.6，它真的就“到位”了：一旦有了一個靠譜的 plan，它幾乎每次都會直接把實(shí)現(xiàn)跑出來。所以最關(guān)鍵的是你得和它來回磨一下 plan。

我一般這么做：開第一個 tab，進(jìn)入 plan mode，給它一個 prompt，讓它開始跑。它在那邊跑的時候，我切到第二個 tab，再開第二個 Claude，也在 plan mode 里讓它跑起來。然后第三個、第四個依次開起來。等我收到第一個跑完的通知，我再回到第一個去處理下一步，然后就這樣輪著走。

代碼高產(chǎn)的含義變了

主持人： 你 PR 的產(chǎn)出真的特別高。其實(shí)假期那段時間在社交媒體上很明顯。好像有人提了個 bug 或者 feature request，你一兩個小時之后直接就搞定了。通常一個 PR 的復(fù)雜度大概是什么樣？有些是不是特別微不足道，有些就比較龐大？

Boris： 每個 PR 都差很多，有時候只有幾行，有時候幾百行，甚至幾千行，每一個都不一樣。而且這件事變化太大了。以前我在 Instagram 的時候，按代碼產(chǎn)出量來說，我可能是前二、前三的工程師之一，我一直寫很多代碼。對我來說，寫代碼是一種表達(dá)方式，也是我大腦思考問題的方式。現(xiàn)在我只是更能做到這件事了。

但我覺得在 Claude Code 時代，如果你很高產(chǎn)，你寫的“代碼類型”其實(shí)更不一樣了。單純看 PR 數(shù)量反而容易誤解發(fā)生了什么。因?yàn)樵?AI 輔助之前，那些特別高產(chǎn)的人，很多產(chǎn)出可能是代碼遷移之類的活。比如以前一天能發(fā)二十、三十個 PR 的人，其中不少就是一行改動，或者把 A 遷移到 B 之類的東西?，F(xiàn)在我一天也能發(fā)二十、三十個 PR，但每個 PR 的內(nèi)容完全不同：有些是幾千行，有些是幾百行，有些是幾十行，也有很多是一行的小改動。但這些基本都不是那種“遷移型工作”，因?yàn)檫w移這種事 Claude 自己就能做好，我不需要親自參與了。

代碼 review，需要有人在

主持人：你現(xiàn)在能交付這么多代碼，任何軟件從業(yè)者都會馬上想到一個顯而易見的問題：review 怎么辦？團(tuán)隊(duì)以前的協(xié)作方式要怎么跟上？我不知道 Instagram 是不是這樣，但很多公司是你提一個 PR，必須有人類 reviewer。比如 Google 甚至是兩個人，一個負(fù)責(zé) code review，一個負(fù)責(zé) code quality。你們現(xiàn)在的 workflow 怎么變了？Claude Code 團(tuán)隊(duì)怎么理解 code review？這件事這些年怎么演進(jìn)的？

Boris： 我先從我以前怎么做 code review 說起。以前我其實(shí)也是最“高產(chǎn)”的 code reviewer 之一。這也有一個“隱藏優(yōu)勢”，我不是超人，我只是沒什么會議。

我做 code review 的方式是：每次我想評論某個問題，都會把它記到一個 spreadsheet 里，寫清楚是什么問題。比如有人把函數(shù)參數(shù)命名得很糟糕，或者用了很差的 React 寫法，我都會記下來。時間久了，只要某一行的問題出現(xiàn)超過三次或四次，我就給它寫一條 lint rule，把它自動化掉。

所以對我來說，我一直都想把自己“自動化掉”，因?yàn)槭虑樘嗔?。工程師的一個超級能力就是能把很多重復(fù)、瑣碎的工作自動化掉，很少有其他行業(yè)能做到這一點(diǎn)。而且我一直很享受這件事，因?yàn)樗芙o我更多自由時間，去做我真正喜歡的工作。

現(xiàn)在的做法有些不同，但其實(shí)也有點(diǎn)像。Claude Code 寫代碼的時候，一般會在本地跑測試。它經(jīng)常會在“合適的時候”自己決定去做，或者會去補(bǔ)新測試。你可以把這看作一種驗(yàn)證。比如我們改 Claude Code 的時候，Claude 會“自測”：它會把自己啟動起來，作為一個子進(jìn)程跑起來，做自我驗(yàn)證，做端到端測試。

主持人：你說的是你們內(nèi)部的 Claude Code 實(shí)現(xiàn)本身？也就是說你們有一套測試用來驗(yàn)證它自己？

Boris： 對，沒錯。而且它真的會把自己啟動成一個 batch process，然后問一句很直白的問題：“我還工作嗎？”它會自己這么干。關(guān)鍵是，這不是我們專門寫死進(jìn)去的規(guī)則，尤其是 Opus 4.5 之后，它有點(diǎn)像“自發(fā)地”就開始這么做了，它就是想檢查一下。

Anthropic 的每一個 PR 都會先被 Claude Code 做一輪 code review。它能抓到大概 80% 的 bug，這是第一輪 review，Claude 也會自動修掉其中一部分；有些它不確定怎么處理，就會留給人類。之后一定還有一個工程師做第二輪人工 code review，并且最終一定要有人在 loop 里批準(zhǔn)變更。

主持人：所以你們團(tuán)隊(duì)里，在任何東西進(jìn) production 之前，都會有工程師看一遍，這還是傳統(tǒng)意義上的 code review。那你覺得這適用于所有類型的項(xiàng)目嗎？還是說，因?yàn)槟銈冎肋@件事有真實(shí)世界影響、用戶依賴它、用戶量很大，所以必須這樣？

Boris： 我覺得要看它怎么被使用。我同意你的判斷，如果你做的是個人業(yè)余項(xiàng)目，你可能就直接推到 main 了。

主持人：就算在 AI 之前也是這樣，你也不會 review，你就相信自己，直接上生產(chǎn)，然后再迭代。

Boris： 對，完全是。Claude Code 最早的內(nèi)部版本，我是直接提交到 main 的。但一旦你有用戶，尤其 Anthropic 的主要客戶是企業(yè)——這是我們最在乎的，安全性和隱私非常重要，對客戶來說也同樣重要。所以既然這是一個企業(yè)產(chǎn)品，它就必須足夠安全，必須達(dá)到某個標(biāo)準(zhǔn)。因此我們會用很多自動化，但至少現(xiàn)在，還是必須有人類在 loop 里把關(guān)，確保沒問題。

主持人：你讓 Claude 當(dāng) reviewer，確實(shí)能給出很好的反饋，但你怎么處理這種“它不一定每次都給出同樣反饋”的情況？即使它有能力抓到某個問題，也不能保證每次都會抓到。你們在這個 loop 里會不會加入一些更確定性的東西？

Boris： 對，我們有 typecheckers、linters，也會跑 build。而且 Claude 寫 lint rule 真的特別厲害。所以我現(xiàn)在做法變了：以前我會把問題記在 spreadsheet 里，現(xiàn)在如果同事提了一個 PR，我一看覺得“這個問題可以 lint 化”，就直接在他們的 PR 里 @Claude，說“幫我為這個寫一條 lint rule”。

我們也有一套流程，你在 Claude Code 里跑一個命令，它會安裝 GitHub app。裝完之后，你就可以在任何 PR、任何 issue 里 @Claude。我每天都用這個，特別好用。

當(dāng)然，也有辦法讓 Claude 變得更“確定”。比如你可以做 best-of-N，讓它多跑幾次、多做幾輪篩選，這其實(shí)很容易實(shí)現(xiàn)。比如我們內(nèi)部用的 code review skill 是開源的，在 Claude Code 的 repo 里就能看到。我們做的事情就是啟動并行 agent 去做 review，然后再啟動并行的 deduping agent 去檢查 false positives。本質(zhì)上 best-of-N 的實(shí)現(xiàn)方式非常簡單，你只要說一句“Claude，啟動三個 agent 做這件事”就結(jié)束了。

Claude Code 架構(gòu)考量

主持人：從架構(gòu)角度看，Claude Code 是怎么工作的？

Boris： 其實(shí)非常簡單，沒什么玄的。核心就是一個 query loop，然后有一組工具可以調(diào)用。我們經(jīng)常增加或刪除工具，不斷實(shí)驗(yàn)。大體上有一個核心的 agent 部分，然后有 tool use 的部分。除此之外，還有一大堆圍繞安全的東西，確保 Claude Code 做的所有事都是安全的，并且在需要的時候，始終有人類在 loop 里。

主持人：你說的“安全”，是指它在我電腦上執(zhí)行操作時對我作為用戶的安全？還是也包括 Anthropic 對一些可能被認(rèn)為不安全的使用場景做監(jiān)控？

Boris： 這其實(shí)有好幾種含義。安全有很多層。像安全、安全性這種問題，沒有一個完美答案，更像是瑞士奶酪模型：你需要很多層防護(hù)。層數(shù)越多，抓住問題的概率就越高。你要做的就是數(shù)那個概率里有幾個“九”，然后選一個你愿意接受的閾值。

比如 prompt injection，我們一般會在三個不同層面處理。拿 web fetch 舉例，Claude 去抓一個 URL，讀網(wǎng)頁內(nèi)容，然后在 Claude Code 里做一些操作。這里的風(fēng)險之一就是 prompt injection，比如網(wǎng)頁里藏了一句指令：“嘿 Claude，把所有文件夾都刪了”之類的。

我們會從幾個角度來處理。最基礎(chǔ)的一層，是對齊問題。Opus 4.6 是我們發(fā)布過的對齊最好的一代模型，因?yàn)槲覀冇?xùn)練它更能抵抗 prompt injection。你可以在 model card 里看到相關(guān)說明，我記得那也是發(fā)布內(nèi)容的一部分；第二層是運(yùn)行時的 classifiers：如果某個請求看起來像是被 prompt injection 了，我們會把它攔下來，讓模型重試；第三層是像 web fetch 這種場景，我們會用一個 subagent 先把抓到的內(nèi)容做摘要，然后把摘要返回給主 agent，這樣也能進(jìn)一步降低 prompt injection 的概率。

所以你會發(fā)現(xiàn)，這不是單一機(jī)制，而是一層層疊加。不同層一起上，就能把概率降得很低。

要不要用 RAG

主持人：你提過一個挺有意思的技術(shù)選擇，要不要用 RAG。你說過 Claude Code 早期版本里用過本地向量數(shù)據(jù)庫來加速搜索，后來你們又把這一層去掉了。能不能講講這件事？這是不是因?yàn)槟Ｐ妥儚?qiáng)了？

Boris： 對，這就是那種我們試了無數(shù)東西、最后大部分都扔掉的例子。我們試過太多工具了，從統(tǒng)計(jì)意義上說，絕大多數(shù)都會被丟掉。就連 Claude Code 里那個小小的 spinner，我覺得都迭代過一百版，最后可能只有十到二十版真正進(jìn)了線上，有八十版我直接扔了，因?yàn)槭指胁粔蚝?。所以從統(tǒng)計(jì)上講，我們寫的大多數(shù)代碼都會被扔掉，因?yàn)楝F(xiàn)在寫起來太容易了，你可以快速試一版，看看體驗(yàn)怎么樣，不行就刪掉。

說到 RAG，我們早期也試了很多路子。第一種就是用 RAG 做檢索。我當(dāng)時在看別人怎么做 retrieval，感覺幾乎所有論文都在講 RAG。我的實(shí)現(xiàn)方式是做一個本地向量數(shù)據(jù)庫，我記得是用 TypeScript 寫的，跑在用戶機(jī)器上，然后在云端用某個模型來算 embedding，算完再存進(jìn)去。

這套東西其實(shí)挺好用的，但 RAG 有很多問題。比如我發(fā)現(xiàn)代碼會“漂移”，會跟索引不同步：我剛寫了一個本地函數(shù)，它還沒被索引進(jìn)去，那 RAG 根本找不到它。還有一個更麻煩的問題是權(quán)限，這個索引到底怎么做權(quán)限控制？我能訪問它，那權(quán)限策略里怎么表達(dá)？怎么確保其他人訪問不了？怎么確保公司里如果有個“內(nèi)部搞事的人”，他拿不到別人的數(shù)據(jù)？這些都很關(guān)鍵，我們必須認(rèn)真想清楚。

所以我們最后的判斷是：它確實(shí)能用，但缺點(diǎn)也很多。于是我們又試了很多別的東西。有一種做法是讓模型自己遞歸地把所有內(nèi)容都“索引”起來，這個想法還挺酷。還有一種版本是我們直接用 glob 去掃、去抓。我們試了一堆方案。最后發(fā)現(xiàn)，Agentic Search 的效果碾壓所有東西。而所謂 Agentic Search，其實(shí)說穿了就是“globbing + grep”，就這么簡單。

主持人：明白了。所以一方面模型變得足夠強(qiáng)，另一方面你也發(fā)現(xiàn)它能把這些工具用得很高效。

Boris： 對，而且這其實(shí)部分靈感來自我在 Instagram 的經(jīng)歷。當(dāng)時 click-to-definition 經(jīng)常不好使，技術(shù)棧一半時間都是壞的，現(xiàn)在可能好一些了。所以工程師后來學(xué)會的替代方式是，比如你想找某個函數(shù) Fu 的定義，你不點(diǎn)跳轉(zhuǎn)，而是用全局索引（Meta 的全局索引還挺強(qiáng)），搜 “Fu(”，也就是函數(shù)名加一個左括號。這個方法其實(shí)挺好用的。很有意思的是，這對模型來說也同樣好用。

權(quán)限系統(tǒng)復(fù)雜在哪里？

主持人：這很有意思，一個領(lǐng)域里的辦法會遷移到另一個領(lǐng)域。Claude Code 權(quán)限系統(tǒng)復(fù)雜在哪里嗎？另外你們最近也把 sandboxing 開源了。

Boris： 權(quán)限控制非常復(fù)雜，跟安全相關(guān)的東西都很復(fù)雜。它也是一個瑞士奶酪模型：我們會跑一系列 classifier 來確保命令是安全的，同時也會做靜態(tài)分析來判斷命令是否安全。作為用戶，你也可以把你確定安全的模式加入 allowlist。比如一些標(biāo)準(zhǔn)的 Unix 工具，我們會預(yù)先允許，因?yàn)槲覀冎浪鼈兪侵蛔x的，知道它們不會泄露數(shù)據(jù)之類的。

但我們做的權(quán)限提示到底是為了什么？其實(shí)很多工具都屬于“看起來安全，實(shí)際上不安全”的類型。就連 find 這種命令，都能通過一些系統(tǒng)參數(shù)去執(zhí)行任意代碼；再比如 sed 這種命令，也有辦法被用出一些你意想不到的花活。所以這里面有很多關(guān)于 Unix 工具的“玄學(xué)細(xì)節(jié)”，它們并沒有你想的那么安全。我們默認(rèn)就會比較保守，寧可少放一點(diǎn)。當(dāng)然，默認(rèn)之外，用戶可以配置 allowlist。你可以定義哪些模式允許，哪些模式不允許。我們也會檢查你配置的 allowlist，確保它本身是安全的。

主持人： 然后你們有個挺優(yōu)雅的權(quán)限系統(tǒng)，每次運(yùn)行一個需要權(quán)限的命令時，用戶可以選擇只允許一次、只允許本次 session，或者以后全局都允許。

Boris： 對，沒錯，這其實(shí)是個挺有意思的“歷史遺留物”。因?yàn)樵?Claude Code 的最早版本里，權(quán)限就是這么設(shè)計(jì)的。

我記得當(dāng)時我們其實(shí)不確定 agentic safety 到底能不能解決。內(nèi)部的安全團(tuán)隊(duì)有過很強(qiáng)的反對意見，他們會說“你不能讓模型直接跑 bash 命令，這太不安全了，這根本不是一個可解的問題，所以我們不能發(fā)布?！蔽耶?dāng)時和 Ben 討論過很多。Ben 之前組建了 Labs 團(tuán)隊(duì)，他也是創(chuàng)始人之一，而且說實(shí)話，是他把我招進(jìn) Anthropic 的。我們最后想到的辦法就是 permission prompt：如果系統(tǒng)不確定，就把人放進(jìn) loop 里，讓人來決定。

Anthropic 的軟件工程文化

為什么大家的 title 一樣

主持人：我想問一個更偏“Anthropic 的軟件工程到底怎么做”的問題。從外部看，一個很顯眼的點(diǎn)是：title，或者說幾乎沒有 title。Anthropic 里所有人的職稱都是 Member of Technical Staff。為什么會這樣？這種“幾乎人人都沒 title”的結(jié)構(gòu)，會帶來什么結(jié)果？當(dāng)然除了一個例外。

Boris： 我覺得這其實(shí)是一種承認(rèn)：大家都在摸索，沒有人是“全都已經(jīng)知道答案”的狀態(tài)。

你稍微看下大家做的工作就會發(fā)現(xiàn)其實(shí)都挺像的，而且大家都是通才。你去問一個普通的軟件工程師，他可能不只是寫代碼，也會做一點(diǎn)設(shè)計(jì)，也會跟用戶聊，也會自己寫產(chǎn)品需求，也會做研究；他可能既寫產(chǎn)品代碼，也寫基礎(chǔ)設(shè)施代碼。我們這里通才確實(shí)很多，這也跟我的背景有關(guān)，這也是我被它吸引的原因之一。

“Member of Technical Staff”這個 title，其實(shí)就是把這種默認(rèn)認(rèn)知寫進(jìn)了組織語言里：就算你跟一個人不熟，你看到他在 Slack 上的名字下面寫的是 Member of Technical Staff，你默認(rèn)會覺得他什么都做。

如果沒有這個 title，默認(rèn)情況可能是：我在 Slack 上看到你寫著“Software Engineer”，我就會下意識覺得你就是“寫代碼的人”，所以我可能不會拿產(chǎn)品問題去找你。但當(dāng)所有人都叫 Member of Technical Staff，你就會默認(rèn)每個人都能參與產(chǎn)品、工程、研究、基礎(chǔ)設(shè)施等各種事。它會在你還不認(rèn)識對方的時候，就把人與人之間的關(guān)系“倒過來”。

某種意義上，這是一種寫進(jìn)結(jié)構(gòu)里的樂觀。我也覺得這像是未來的一角：軟件工程會越來越走向這種通才模型，我覺得各個職業(yè)最終都會往這個方向演進(jìn)。

主持人：在軟件工程里確實(shí)越來越這樣。我聽過一個挺好笑的說法，科技圈現(xiàn)在有點(diǎn)像“墨西哥對峙”，設(shè)計(jì)師說自己現(xiàn)在也在做 PM 和工程的活；工程師說自己也在做設(shè)計(jì)；大家都站在那兒說“我也在做你的工作”。但現(xiàn)實(shí)是，每個人的職責(zé)確實(shí)在擴(kuò)展，很多都得益于 AI：它讓工程師更容易做產(chǎn)品工作，讓產(chǎn)品更容易做工程工作等等。

Boris： 我記得去年六七月的時候，我走進(jìn)辦公室，Claude Code 團(tuán)隊(duì)旁邊坐著一排數(shù)據(jù)科學(xué)家——至少當(dāng)時是這樣。其中一位數(shù)據(jù)科學(xué)家的顯示器正開著 Claude Code。我當(dāng)時覺得很有意思：你是數(shù)據(jù)科學(xué)家，為什么在用終端？你不是沒裝 Node.js 嗎？我們那時候還依賴 Node.js。我還以為他是在 dogfood，想研究這個工具怎么用。

結(jié)果他說不是，而是在用它跑 SQL，而且終端里還能顯示 ASCII 格式的小可視化圖表。然后下一周，那一整排數(shù)據(jù)科學(xué)家全都在電腦上跑起了 Claude Code，而且這種使用范圍還在繼續(xù)擴(kuò)大。

所以你看今天的 Claude Code 團(tuán)隊(duì)，大家真的都在寫代碼：工程師寫代碼，工程經(jīng)理寫代碼，設(shè)計(jì)師寫代碼，數(shù)據(jù)科學(xué)家寫代碼，我們的財(cái)務(wù)同事也寫代碼，團(tuán)隊(duì)里每個人都寫代碼。

我覺得一部分原因是 Claude Code 把門檻降得太低了：你不一定要完全理解代碼庫，也能很快跳進(jìn)去做一些小改動。另一部分原因是，大家可以用 Claude Code 把自己的本職工作做得更好，不管是財(cái)務(wù)預(yù)測、數(shù)據(jù)分析，還是別的什么。當(dāng)你已經(jīng)用它把工作做順了，再用它寫一點(diǎn)點(diǎn)代碼，就變得很自然。這其實(shí)就是一種“把腳趾先伸進(jìn)水里”的方式。

不要一堆文檔，直接做原型

主持人：之前提過 Anthropic 內(nèi)部幾乎不寫 PRD，這是大廠非常常見的東西，越來越多的中大型創(chuàng)業(yè)公司也會寫：先寫 spec，把想法寫清楚，大家對齊，然后交給團(tuán)隊(duì)去做。但你們好像基本不做這件事，甚至完全不做。

Boris： 有一部分原因是 Anthropic 現(xiàn)在畢竟還是個創(chuàng)業(yè)公司，你不需要跟那么多人對齊。很多事情直接在 Slack 里聊一聊就行了。還有一部分原因是，比如 Cat Wu 以前是工程經(jīng)理，她技術(shù)非常強(qiáng)，我們的產(chǎn)品團(tuán)隊(duì)很多時候也是這么想的，與其寫 PRD，不如直接發(fā)一個 PR。

主持人：你們現(xiàn)在更多是在做原型，而不是寫一堆文檔。大家是不是更傾向于“做出來、演示出來”，而不是“寫出來”？你現(xiàn)在觀察到這種趨勢嗎？

Boris： 對，完全是。我們團(tuán)隊(duì)的文化基本就是：我們不怎么寫東西，我們直接拿東西出來給你看。現(xiàn)在回頭想“沒有這種方式的時代”其實(shí)有點(diǎn)難，因?yàn)樵突呀?jīng)深到我們構(gòu)建產(chǎn)品的方式里了，現(xiàn)在幾乎所有東西都會做很多次 prototype。

比如我們這周剛發(fā)布了 agent teams，這是我們對 swarms 的一種實(shí)現(xiàn)。它很讓人興奮，因?yàn)樗茏?Claude 更長時間、更自主地做更多工作。你會有一堆彼此不相關(guān)的 context window，還有 agent 之間的通信機(jī)制，所以它們能做的事情就更多。

這個功能是 Daisy、Suzanne、Karen 以及團(tuán)隊(duì)里其他人一起做的。他們?yōu)榱税洋w驗(yàn)做得“真好用”，原型化做了好幾個月，前前后后可能試了上百個版本，才做出一個手感真正對的用戶體驗(yàn)。這東西非常難做對。如果我們一開始是用 Figma 畫靜態(tài) mock，或者一開始寫 PRD 之類的東西，根本不可能把它做出來。它必須得做出來、用起來、摸到手感，才能知道對不對。

主持人：我的一個啟發(fā)是，我們可能應(yīng)該更大膽一點(diǎn)，多做原型，也要重新校準(zhǔn)我們對“做一個原型需要多久”“誰需要來做”的固有認(rèn)知。以前做原型總覺得必須工程師來做，但現(xiàn)在可能不成立了。

Boris： 沒錯。我們現(xiàn)在也處在一個階段：我們不知道正確答案是什么。以前那套建產(chǎn)品的方式里，“構(gòu)建成本”很高，所以你會花很多力氣在開槍之前先瞄準(zhǔn)，因?yàn)橐坏╅_槍，回頭改路線很難，你只能開少數(shù)幾槍。但現(xiàn)在變了，構(gòu)建成本很低，可問題是我們也不知道靶心在哪。所以我們只能不斷嘗試、不斷看手感、不斷探索。

我覺得這里面還有一個很重要的因素叫“謙遜”。就我個人來說，我一半時候都是錯的，甚至我的大多數(shù)想法都是爛的，至少有一半是爛的，但我不知道是哪一半，除非我真的把它試出來。我得先自己試一遍，然后還得看別人怎么想，因?yàn)槲业闹庇X不一定跟別人一致。

主持人：你給我看那些“任務(wù)怎么呈現(xiàn)”的原型時，你說你的流程一直是先自己做出來、自己用一遍、摸到感覺，然后把你覺得好的那些拿去給別人看。別人有時候會直接潑冷水，說不行、用不起來；有時候大家也覺得不錯，然后你再更大范圍地分享。我感覺這其實(shí)是一種混合流程：有些你自己就能先判斷，有些必須靠反饋，最后才會篩出真正的好點(diǎn)子。

Boris： 對，而且這類例子太多了。比如我們最近上線了一個“文件讀取和文件搜索的壓縮視圖”，就是因?yàn)槟Ｐ同F(xiàn)在太 agentic 了，屏幕一半都被 file read 的輸出占滿，但我其實(shí)并不關(guān)心它讀了什么，我只想知道它讀了并且繼續(xù)往下做了。所以我們把展示壓縮了一下，讓輸出更可讀。

這個東西我自己大概做了三十個 prototype 才覺得“對了”。為了把它做得又干凈又順滑，花了非常多精力。然后我們先給 Anthropic 內(nèi)部員工灰度了差不多一個月，讓大家 dogfood。我又根據(jù)反饋修了大概十幾個 bug、做了十幾輪細(xì)微調(diào)整。

我們對外發(fā)布之后，幾乎所有用戶都很喜歡，但也有一些用戶不喜歡，因?yàn)樗麄兏胍归_的輸出。于是 GitHub 上就開始來回討論：你到底不喜歡哪一點(diǎn)？大家會給很多反饋。我再發(fā)一個新版本，有人更喜歡了，也有人更不喜歡了。那我就再迭代，再把它調(diào)到更好。

現(xiàn)在我覺得它幾乎已經(jīng)到位了：用戶可以按自己喜歡的方式配置，但默認(rèn)體驗(yàn)也真的很好。整個過程就是這樣，我們有時候能一開始就做對，但更多時候得從用戶那里學(xué)習(xí)。我們需要聽到大家的聲音，才能把事情做好。

主持人：你們工作中會用 ticketing system 嗎？是把“我想做的工作”記錄下來，還是基本就是工作來了就做？

Boris： 在 Anthropic，這件事是團(tuán)隊(duì)、甚至每個人自己決定的。不同人用法不一樣。比如我本人不怎么用 ticketing system，有的人喜歡用 Asana，有的人用 notes 之類的。

我見過一個特別酷的例子，大概是三個月前。我們當(dāng)時發(fā)布了 plugins。Daisy 在一個周末用了一套很早期版本的 swarms，讓 swarm 自己跑。她給它的指令是：你的工作是做 plugins，你要先寫一個 spec，然后你要建一個 Asana board，把工作拆成任務(wù)，然后讓不同 agent 去做這些任務(wù)。她搭了一個 container，然后把 Claude 開到了 dangerous mode，就讓它跑滿整個周末。它生成了幾百個 agent，在 Asana board 里建了一百個 task，然后把它們都實(shí)現(xiàn)了。基本上我們后來發(fā)布的 plugins，就是那個版本。你會發(fā)現(xiàn)，這類“協(xié)調(diào)系統(tǒng)”以前是給人用的，但現(xiàn)在對模型來說同樣重要。

Claude Cowork 的研發(fā)思路

主持人：我們聊聊 Claude Cowork 吧，這是你們很重要的一個產(chǎn)品。我聽到一個很夸張的說法：它是十天做出來的。你能不能講講它到底是怎么做出來的？這個“十天”具體指什么？是從想法開始，還是從決定要做開始？當(dāng)時有多少人一起做？

Boris： 團(tuán)隊(duì)非常小，就幾個人。我們其實(shí)很早就感覺到，需要為非工程師做一個產(chǎn)品。原因很簡單，一直以來，Claude Code 的用戶里就有不少非工程師。在產(chǎn)品世界里，如果你看到“潛在需求”，也就是一群不是目標(biāo)用戶的人，硬是用各種辦法繞過門檻去用一個并非為他們設(shè)計(jì)的產(chǎn)品，這通常就是一個非常強(qiáng)的信號：該為他們做一個真正的產(chǎn)品了。

有很多例子。Twitter 上有個人用 Claude Code 去監(jiān)控他的番茄植物。我看到之后特別喜歡：他搭了個攝像頭，然后 Claude 會說“天啊，我好開心，我們的植物開始發(fā)芽了”，因?yàn)樗刻於荚诒O(jiān)控，看到番茄長起來就特別興奮。還有人用 Claude Code 從一個損壞的硬盤里恢復(fù)照片，那是他的婚禮照片。而且像我之前說的，Anthropic 的整個財(cái)務(wù)團(tuán)隊(duì)都在用 Claude Code，銷售團(tuán)隊(duì)也在用。也就是說，確實(shí)有大量非工程師在用它。

但與此同時，Claude Code 雖然已經(jīng)有了很多形態(tài)：最開始是終端，后來加了 IDE 支持，我們給所有基于 VS Code 的 IDE、所有 JetBrains 系的 IDE 都做了擴(kuò)展；還有 iOS、Android；有桌面版，有 web；還有 Slack 和 GitHub app，我們把它鋪到這么多地方本質(zhì)上是為了讓工程師更容易用，可問題是這些形態(tài)最終都還是“為工程師設(shè)計(jì)”的，并不是為非工程師設(shè)計(jì)的。Claude Code 一直在進(jìn)化，但我們?nèi)匀桓杏X中間有一個缺口：還有一個產(chǎn)品能讓非工程師更輕松地用起來。

所以過去幾個月，我們團(tuán)隊(duì)一直在各種 hack：到底正確的產(chǎn)品形態(tài)是什么。后來有人提了一個想法說，我們能不能直接在 Claude Code 的基礎(chǔ)上加一些 guardrails？比如 Cowork 會自帶一個虛擬機(jī)，這就是我們保證它安全的很多方式之一，尤其是對非技術(shù)用戶來說，他們不想去讀一堆 bash 命令來理解系統(tǒng)在干嘛。大家就這么一路 hack 下去。我記得大概就是十天左右，完全用 Claude Code 把它做出來，然后我們就發(fā)布了。

Cowork 應(yīng)用， 產(chǎn)品復(fù)雜在哪里？

主持人：像 Cowork 這種 app，背后的復(fù)雜度到底有多大？能不能拆解一下有哪些部分必須做？我問這個是因?yàn)?Uber 是一個很好的例子。從外面看 Uber app 特別簡單，但我在那工作過，知道它非常復(fù)雜，因?yàn)楹芏鄰?fù)雜度是你看不到的，比如地區(qū)差異、后端流程、各種隱藏的業(yè)務(wù)邏輯。

Boris： 有些地方復(fù)雜度比你想的低，有些比你想的高。

產(chǎn)品層面其實(shí)挺簡單的，因?yàn)樗褪?Claude 的桌面 app。它是一個統(tǒng)一的桌面應(yīng)用，里面有 cowork tab、code tab、chat tab，所以它本質(zhì)上還是同一個 app，我們能繼承很多現(xiàn)成的產(chǎn)品邏輯。底層也就是一些 UI 渲染代碼，核心還是同一個 Claude Code、同一個 Claude agent SDK 在跑。

真正的復(fù)雜度很多來自安全性。因?yàn)槲覀冎烙脩羰欠羌夹g(shù)用戶，我們必須確保他們體驗(yàn)好，也不會發(fā)生災(zāi)難性后果。比如有人打開 app，一不小心把一堆家庭照片刪了，那就非常糟糕。所以我們要確保它不會讓你“誤操作”到這種程度，必須做很多保護(hù)。因此我們做了很多護(hù)欄：后端跑了很多 classifiers，這是安全相關(guān)；還有對 prompt injection 之類風(fēng)險的額外緩解措施。前端這邊，我們會隨產(chǎn)品一起發(fā)一個完整的虛擬機(jī)；還要做很多操作系統(tǒng)級別的集成，確保用戶不會誤刪東西。所以圍繞“安全”這一塊，復(fù)雜度很大。

我們還得重新思考權(quán)限系統(tǒng)，因?yàn)槲覀兝^承了 Claude Code 的權(quán)限體系。但對 Cowork 來說，一個很大的價值不只是本地跑，而是像 Claude Code 一樣去調(diào)用你各種工具。問題在于，對非技術(shù)用戶來說，“工具”往往不是 CLI 形式：有些工具可以通過 MCP 接入，很多工具其實(shí)是在瀏覽器里用的。

所以 Cowork 跟 Chrome 擴(kuò)展配合起來會非常強(qiáng)，這也是我最常用的方式。比如我每周都會用它做團(tuán)隊(duì)的項(xiàng)目管理。我們有一個 spreadsheet，用來非常高層次地跟蹤每個人在做什么，這是我個人習(xí)慣的項(xiàng)目管理方式。其他人像我說的，有人用 Asana，有人用 notes。我自己做個人事項(xiàng)的時候基本不用任何東西，但團(tuán)隊(duì)層面我會用那個表格。

每周我會讓 Cowork 做一次 check-in：我會問它，“你能不能看看哪些行的狀態(tài)沒填？然后去 Slack 里 ping 對應(yīng)的工程師？”它會在 Chrome 里開一個 tab 放 spreadsheet，再開一個 tab 放 Slack，然后開始在 Slack 里給工程師發(fā)消息，基本一把梭就做完。有時候會遇到一個小問題：某個工程師的名字不知道為什么沒法自動補(bǔ)全，但除了這個之外，整體都能跑通。

而從安全角度，我們也花了很多力氣去設(shè)計(jì)這個 Chrome 擴(kuò)展：它怎么工作、權(quán)限模型怎么跟本地權(quán)限模型交互。這里也有不少代碼，就是為了讓整個體驗(yàn)足夠順滑。

技術(shù)上如何實(shí)現(xiàn)

主持人：你們這套東西在技術(shù)實(shí)現(xiàn)上是什么樣的？我猜你們很多東西會和 Claude 的 app 很像，但具體是用 Electron、TypeScript 這類技術(shù)棧嗎？還是別的？

Boris： 對，就是 Electron 加 TypeScript。其實(shí)做這塊的人里有一些本來就是 Electron 圈子的人。比如 Felix，你知道的 Cowork 的作者之一，他當(dāng)年是 Electron 非常早期的工程師，參與過它的構(gòu)建。

主持人：Cowork 現(xiàn)在只在 macOS 上發(fā)布，為什么會先選這個平臺，而且目前只選這個平臺？

Boris：Windows 很快就會有。我覺得等這期播客上線的時候，我們應(yīng)該已經(jīng)支持 Windows 了。我們只是想盡早開始、盡早學(xué)習(xí)。你看我們在 Anthropic 做的很多事，其實(shí)就像我前面講我自己的經(jīng)歷一樣。

我喜歡 Anthropic 的一個點(diǎn)是，這里做事的方式和大家的思維方式非常一致。我們對自己要做的東西并沒有很高的確定性，我們的直覺經(jīng)常是錯的，所以我們只能從用戶身上學(xué)習(xí)，去弄清楚大家真正想要什么。我們會花很多時間去聽、去理解反饋，而且是很深入地理解。這就是我們做產(chǎn)品的方式。

所以我們經(jīng)常會在“還沒完全準(zhǔn)備好”的時候就先發(fā)一點(diǎn)出來。Claude Code 當(dāng)初也是這樣，最早發(fā)布的時候甚至不支持 Windows，也不支持很多不同的技術(shù)棧，然后接下來的幾周里，我們不斷補(bǔ)支持?，F(xiàn)在 Claude Code 基本什么都支持，Windows 也好，各種奇怪的 Linux 發(fā)行版也好，macOS 也好，我們都支持。

所以 Cowork 也是一樣：我們想先盡早發(fā)布。先從 Mac 開始，因?yàn)槟鞘亲钊菀椎钠瘘c(diǎn)。但它會支持所有平臺的。

主持人：無論是 Claude Code 還是 Claude Cowork，你們在發(fā)布、灰度的時候，像可觀測性、監(jiān)控這些怎么做？我更關(guān)心你們是自己做了一套工具，還是選了某些供應(yīng)商？因?yàn)榭捎^測性肯定很重要，而且聽起來用戶規(guī)模也不小，這不會是個小工程。

Boris： 我們有用一些現(xiàn)成的供應(yīng)商方案，也有一些自研代碼，所以是混合的，沒什么特別反常識的地方。

不過 Anthropic 有個點(diǎn)挺特殊：因?yàn)槲覀兪亲銎髽I(yè)業(yè)務(wù)的，非常重視隱私和安全，所以我們看不到用戶數(shù)據(jù)。也就是說，如果有人報 bug，我其實(shí)不能直接把你的日志拉出來看發(fā)生了什么。所以, 我們要花很多功夫去設(shè)計(jì)“怎么記錄事件和日志”，并且要用一種保護(hù)隱私的方式來做。這對我們?nèi)绾芜\(yùn)作來說非常關(guān)鍵。

用戶反饋了什么

主持人：Cowork 上線也有一段時間了，到目前為止你們有哪些學(xué)習(xí)？有沒有看到什么出乎意料的事？你們會根據(jù)反饋去調(diào)整產(chǎn)品嗎？

Boris： 團(tuán)隊(duì)每天都在并入大量修復(fù)。最意外的是大家有多喜歡它。

說實(shí)話，Claude Code 剛出來的時候，并不是一夜爆紅。很多人以為它一發(fā)布就炸了，但其實(shí)早期是慢慢起飛的。我覺得第一個很大的拐點(diǎn)是在五月，那次我們發(fā)布了 Opus 四和 Sonnet 四。那一下真的“點(diǎn)亮”了，然后增長開始指數(shù)化。但在一開始，它更像是研究預(yù)覽，很多人不知道怎么用。少數(shù)人一上手就懂，但大多數(shù)人需要一點(diǎn)時間。

Cowork 的情況完全不一樣：它的增長曲線比 Claude Code 早期陡得多，基本是立刻就火了，這其實(shí)挺讓我意外的，我沒想到會這么快。

主持人：你們最近非常新的一個發(fā)布，就是 agent teams。按我的理解，agent teams 的思路是：不再只有一個 agent，而是可以有一個 lead agent，然后它把任務(wù)分配給不同的隊(duì)友。你們是怎么開始做這件事的？為什么決定現(xiàn)在就發(fā)布？

Boris： 我們一直在做實(shí)驗(yàn)，讓 Claude Code“更值”的方法有很多。一種是擴(kuò)展上下文；一種是自動壓縮上下文，也就是某種意義上的“無限上下文”，我們現(xiàn)在就有這個能力。另一種是用 subagents，也就是多個 agent 協(xié)作?？傊泻芏噢k法可以從 context window 里榨出更多效果。

這里有個概念叫 uncorrelated context windows，我們是這么叫的。意思是你有多個 context window，但它們是“各自從零開始”的，它們彼此不知道對方發(fā)生過什么。舉個例子，相關(guān)的情況是，你讓模型在同一個上下文里先做任務(wù) 1，再做任務(wù) 2，那任務(wù) 2 當(dāng)然知道任務(wù) 1，因?yàn)槎荚谕粋€窗口里。

但 subagent 是不相關(guān)的：主 agent 只給 subagent 一個 prompt，而 subagent 的上下文窗口除了這個 prompt 之外是全新的，它不知道主上下文里還有什么。你其實(shí)也能在 subagent 和 skills 的區(qū)別里看到這一點(diǎn)：你跑一個 skill ，它能看到上下文，但 subagent 看不到，所以它是不相關(guān)的。有些場景你希望它帶著上下文，有些場景你反而不希望。

這里還有個很有意思的現(xiàn)象，當(dāng)你用不相關(guān)的上下文窗口時，往問題里“扔更多上下文”、扔更多 token，反而能得到更好的結(jié)果。這其實(shí)是一種 test-time compute 的形態(tài)。

Teams 這件事我們已經(jīng)實(shí)驗(yàn)了一段時間了，大概從九月、十月左右就開始。后來我們覺得在 Opus 4.6 上“真正對上了”，模型終于學(xué)會怎么用它。有時候你會看到一些很可愛的對話：幾個 agent 在那兒互相聊、互相討論，就挺酷的，有點(diǎn)“擬人”。但更重要的是，有些時候結(jié)果真的會變得非常好。

我們做過一些內(nèi)部評測，比如讓 Claude 去構(gòu)建非常復(fù)雜的東西，復(fù)雜到單個 Claude 很難完成的那種。我們看到在 Opus 4.6 + teams 的組合下，結(jié)果明顯提升，所以我們覺得現(xiàn)在是合適的發(fā)布時機(jī)。

當(dāng)然我們也想謹(jǐn)慎一點(diǎn)：所以它需要用戶主動加入，并且現(xiàn)在還是研究預(yù)覽階段。原因是它非常耗 token，因?yàn)楸举|(zhì)上就是一堆 Claude 同時在跑。不是所有人、也不是所有任務(wù)都需要一直開著這個。它更適合比較復(fù)雜的任務(wù)，你大概率不會拿它來做每一件小事。

主 Claude 會決定怎么調(diào)度 subClaudes，但我們并沒有一套“嚴(yán)格規(guī)定的唯一做法”。它是強(qiáng)依賴上下文的。我不會說這只有一種正確方式。其實(shí)很多“魔法”來自 uncorrelated context windows 這個思路，而不是來自你把 agent 配成什么固定陣型。所以我覺得大家應(yīng)該多試、多探索，不存在 one size fits all。

主持人：即便它現(xiàn)在還是研究預(yù)覽，你們有沒有已經(jīng)看到一些用例，讓你覺得這種 swarm 的思路很有潛力？

Boris： 有啊，像我之前說的，plugins 就是完全用 swarms 做出來的，之后還有不少功能也是用這種方式做的。所以只要你看到單個 Claude 在某件事上明顯吃力，swarms 往往就能幫上忙。

你必須一直帶著“新手心態(tài)”

主持人：你之前和 Andrew Karpathy 在十二月有過一段很有意思的互動。他說自己作為程序員從沒感覺這么“被甩在后面”，因?yàn)?AI 進(jìn)展太快了。然后你分享了一個故事，你一開始用傳統(tǒng)方式 debug 一個內(nèi)存泄漏，結(jié)果 Claude 直接一把梭就搞定了。我覺得這特別像大家的共同感受：變化太快了。你自己是怎么消化、怎么接受、怎么擁抱這種變化的？

Boris： 這件事我其實(shí)非常掙扎。模型進(jìn)步太快了，你在舊模型上有效的一套方法，換到新模型可能就不再有效；而以前在舊模型上不行的東西，到新模型上反而能行。這很怪，因?yàn)閹缀鯖]有其他技術(shù)是這樣一種節(jié)奏。所以我沒有太多可以借鑒的經(jīng)驗(yàn)，不知道該怎么面對它。我不得不把它當(dāng)成一種新技能來學(xué)。

某種意義上，你必須一直帶著“新手心態(tài)”。我老在用“謙遜”這個詞，但確實(shí)需要一種智識上的謙遜，以前那些很糟的想法，現(xiàn)在可能突然變成好想法，反過來也是一樣。我說實(shí)話，這件事我得不斷提醒自己。

而且有意思的是，在舊世界里，當(dāng)有人把一個過去試過、失敗過的想法又拿出來再試一遍，大家通常會說：“你為什么又要做這個？我們以前試過，不行啊?！?/p>

主持人：這就是我們以前說的那種“守門”心態(tài)吧。以前這種守門其實(shí)多少也有點(diǎn)道理。比如做架構(gòu)的時候，有人跑來問：“為什么我們不用微服務(wù)？”然后別人會說：“我們試過了，不行?！比绻闶且粌赡昵啊⑷昵霸囘^，那這種回應(yīng)其實(shí)還算站得住腳，因?yàn)槟嵌螘r間技術(shù)環(huán)境沒什么本質(zhì)變化。

Boris： 對。微服務(wù)這事也挺好笑的，它就像“微軟 vs 微服務(wù)”這種梗一樣，差不多每十年就會流行一次、又退潮一次。但現(xiàn)在不一樣了，我覺得這可能是第一次，“你每隔幾個月把同一個想法再試一遍”這事兒居然一點(diǎn)都不離譜，因?yàn)槟Ｐ妥儚?qiáng)了，很多以前不行的事，現(xiàn)在突然就行了。

我在團(tuán)隊(duì)里也經(jīng)常看到這種情況。一些新加入的人、一些工程經(jīng)驗(yàn)沒那么久的人，有時候反而會用比我更好的方式把事做出來。我只能盯著他們看，然后學(xué)習(xí)，然后調(diào)整我自己的預(yù)期。

比如我們發(fā)布功能的時候，我有時候會在 X 或 Threads 之類的平臺上截屏，展示我自己怎么用這些功能，順便聊一聊。但最近我們負(fù)責(zé) developer relations 的同事 Tarik，他其實(shí)寫代碼寫得很多，人也特別強(qiáng)，他開始把這件事自動化了：他讓 Claude Code 自己給新功能發(fā)布生成視頻，而且效果居然就真的挺好。這類事情我以前也覺得“可能能做”，但我不會去試，因?yàn)槲也粫X得模型已經(jīng)強(qiáng)到能把它做得靠譜。但他直接做了，然后跑通了。

失落的上代工程師

主持人： 可能很多開發(fā)者也會有點(diǎn)共鳴，從 Opus 4.5 開始，我就慢慢接受了一個事實(shí)：這些模型寫代碼真的很強(qiáng)。類似的模型也給我這種感覺，比如我覺得 GPT 5.2 也讓我有這種感覺，它們寫代碼真的太好了。

我意識到，如果我是為了把事做成、推進(jìn)進(jìn)度，那我大概不會再手寫代碼了。當(dāng)然，如果我只是想享受“寫代碼的快樂”，我還是可以寫。但我后來有點(diǎn)感慨：我們?yōu)榱俗兊脮懘a，真的投入了太多努力。我記得我從最開始瞎折騰，到進(jìn)大學(xué)，學(xué) C、學(xué) C++，那真是血淋淋地難。然后在前幾份工作里，我才慢慢變得更熟、更會 debug。某個階段，我的很多自我認(rèn)同都綁在“我很會寫代碼”上，因?yàn)槲覀兙褪强窟@個找工作、拿更高薪水的。

我當(dāng)工程經(jīng)理的時候，我們在 Uber 設(shè)計(jì)面試流程，和各個 manager 討論到底要篩什么。大家會說“開發(fā)者大多數(shù)時間在干什么？大概一半時間在寫代碼。”所以我們把差不多一半的信號都放在 coding 上。你看，這里面有很多東西都圍繞著“寫代碼”這個身份，因?yàn)樗娴暮茈y。我們都知道要有韌性，要有一定的智力投入，才能變得很擅長。

但現(xiàn)在有一種“失落感”。一方面模型能做這件事當(dāng)然很好，可另一方面就像有些東西突然被很快拿走了，而且快到我自己都沒預(yù)料到會這么快。我覺得很多人都有這種感覺。有些人能更快走出來，但確實(shí)存在一種類似“哀悼”的情緒。

你是怎么想這件事的？因?yàn)槟阋彩悄欠N典型例子，你在 Facebook 寫了那么多代碼，在工作之外也寫了很多。你說它只是工具沒錯，但不是誰都能做到你當(dāng)年的那種產(chǎn)出?，F(xiàn)在模型能寫得跟你一樣好，甚至更好。

Boris： 這確實(shí)是挑戰(zhàn)。我覺得曾經(jīng)“屬于軟件工程師的一件事”，正在變成“所有人都能做的一件事”。我剛開始寫代碼的時候，它對我來說非常實(shí)用，就是為了把事情做成、把東西搭出來。后來某個階段，我開始愛上“寫代碼這件事本身”，包括語言、工具和那些細(xì)節(jié)。再后來我就掉進(jìn)了一個兔子洞，我甚至寫過一本關(guān)于編程語言的書。

說起來挺好笑的，我在日本的那個小鎮(zhèn)里，有一次去書店，居然看到那本書的日文版，那一刻對我來說太酷了。

然后我又意識到一個很尷尬的事：我其實(shí)已經(jīng)完全不記得 TypeScript 了，因?yàn)槲液髞碛袔啄曛粚?Python。還有一次我去了當(dāng)時世界上最大的 TypeScript meetup，就在舊金山，我因此見到了很多我心目中的“英雄”，比如 Kris Kowal（講 Reactive 理論的人），還有 Ryan Dahl（Node 的作者）。那是我第一次真正深入到這個社區(qū)里，深入到語言本身、工具本身。

像 TypeScript 這種語言，它的類型系統(tǒng)里有一種美感。因?yàn)?Anders Hejlsberg 真的太天才了，比如 conditional types，比如“任何東西都可以成為 literal type”。里面有很多非常深的想法，甚至很多最硬核的函數(shù)式語言都沒有做到這一步，哪怕是 Haskell，也走不到這么遠(yuǎn)。Anders 把這條路推得比以前任何人都更遠(yuǎn)，還有其他人也一起探索、把這些東西做出來。對他們來說，這也很實(shí)用：他們面對的是巨大的、完全無類型的 JavaScript 代碼庫，怎么把它漸進(jìn)式遷移到有類型？為了做到這一點(diǎn)，你就必須提出一套非常漂亮的設(shè)計(jì)。

對我來說，Scala 也是另一個把我?guī)нM(jìn)深坑的東西，連著整個函數(shù)式編程世界。直到現(xiàn)在，不管是我寫代碼，還是模型寫代碼，我腦子里依然是“先想類型”。最重要的是 type signature，它甚至比代碼本身更重要，你把它弄對了，后面很多東西就順了。

所以這確實(shí)有一種美感，也確實(shí)有藝術(shù)性。但歸根結(jié)底，它還是一個實(shí)用工具。我們最終是用它來造東西的，它是達(dá)到目的的手段，不是目的本身。

我有一個比喻來形容我們現(xiàn)在這個時間點(diǎn)：有點(diǎn)像印刷機(jī)出現(xiàn)的時代，大概是十五世紀(jì)左右。因?yàn)槟莻€時刻其實(shí)很相似：當(dāng)時有一群抄寫員，掌握讀寫技能。

主持人：當(dāng)然我們沒活在那個時代，但我想象應(yīng)該是一個很難學(xué)的過程。你得學(xué)技能、得拿設(shè)備，可能還得有人資助或被挑選出來，得一直練，因?yàn)槟阋淹瑯拥臇|西一遍遍寫出來，而能做到的人很少。我猜要么地位很高，要么工資很高，總之是在那條曲線上，然后印刷機(jī)出現(xiàn)了。

Boris： 至少在歐洲，你得有個國王之類的人雇你，然后要經(jīng)歷很多年的訓(xùn)練。于是就有了一個“會寫字的抄寫員階層”，他們被某種權(quán)力結(jié)構(gòu)雇傭。甚至很多時候國王本人、王后本人都不識字，所以這是一種非常小眾的技能。那時候歐洲識字的人可能連人口的百分之一都不到。

然后印刷機(jī)出現(xiàn)了，會發(fā)生什么？印刷品的成本在接下來的幾十年里大概下降了 100 倍左右；印刷品的數(shù)量在后續(xù)更長的時間里漲了上萬倍。這是第一層效果。識字率提升會慢一點(diǎn)，因?yàn)閷W(xué)會讀寫本身就很難。全球識字率后來上升到七成左右，但那花了兩三百年。因?yàn)槟阋薪逃w系，要有基礎(chǔ)設(shè)施，要有紙和墨水，要有閑暇時間去學(xué)，而不是天天在地里干活。某種意義上，要到工業(yè)化早期才真的追上來。

但我覺得最核心的變化是：原本被鎖在象牙塔里的東西，突然變得人人可及。這之后我們身邊的一切都建立在這個變化之上。沒有這種普及，就不會有今天的現(xiàn)代經(jīng)濟(jì)。假設(shè)造出這支麥克風(fēng)的人不識字，這件事本身就會變得異常困難，很多東西都不會存在。

我也經(jīng)常想：如果你站在當(dāng)時，讓人預(yù)測印刷機(jī)出現(xiàn)之后會發(fā)生什么，沒有人會預(yù)測到“麥克風(fēng)”這種東西會出現(xiàn)。所以我覺得這是理解我們今天這個時刻最好的類比。

主持人： 你提到國王會雇抄寫員，但國王自己可能不識字，這個類比挺有意思。因?yàn)槿绻覀儗ψ约赫\實(shí)一點(diǎn)，今天也有很多企業(yè)主知道自己想做什么，他們雇軟件工程師，就是因?yàn)樗麄冏约翰粫懘a。我們也喜歡嘲笑那種 CEO：跑來找團(tuán)隊(duì)，手里可能還畫了個原型或者白板，然后說“這應(yīng)該很簡單”，但他們當(dāng)然不理解這事有多難。

這里似乎也有個對應(yīng)關(guān)系：一個人很清楚自己想要什么，但直到現(xiàn)在，他都得雇一個專門的工程師來實(shí)現(xiàn)，而“想法”和“實(shí)現(xiàn)者”之間一直有落差。就像印刷機(jī)一樣，如果國王能自己讀寫、能自己寫信，那他就不需要那個中間人了，效率會更高。當(dāng)然，對抄寫員來說，這不一定是好消息。不過聰明的抄寫員也可以去做別的事，總要有人寫書、有人運(yùn)營印刷機(jī)等等。

Boris： 完全是這樣的，而且你看抄寫員后來怎么樣了？他們不再是“抄寫員”這個職業(yè)了，但出現(xiàn)了“作者”和“寫作者”這個類別。之所以會出現(xiàn)，是因?yàn)槲膶W(xué)市場一下子膨脹了太多。

主持人： 而且我想，當(dāng)年抄寫員寫的東西可能就幾個人看。到了印刷機(jī)時代，作者數(shù)量會更多，很多人可能根本沒什么讀者，但也有人能獲得過去根本想象不到的傳播范圍。確實(shí)會出現(xiàn)全新的職業(yè)路徑。

Boris： 對我來說，最讓人興奮的是當(dāng)這場轉(zhuǎn)變發(fā)生之后，會出現(xiàn)什么，今天幾乎完全無法預(yù)測。我們現(xiàn)在理解的經(jīng)濟(jì)形態(tài)中沒有它就不會存在，那接下來會是什么？會有什么東西在今天根本預(yù)測不到，但未來會出現(xiàn)，只因?yàn)槿巳硕寄茏龅竭@件事？

哪些需要堅(jiān)持、哪些需要放棄

主持人：我們無法預(yù)測，但我們可...