skills將成為未來個人生產力資產 | Claude Cowork核心人員對話實錄

3月18日，Anthropic Claude Cowork 項目核心技術人員 Felix Rieseberg 接受了海外播客 Latent Space 主持人 Alessio 與 swyx 的深度訪談。本次對話圍繞 Anthropic 近期發布的Claude Cowork 展開，深入探討了其從 10 天快速原型到正式產品的誕生歷程、虛擬機的底層邏輯、本地計算與云端的權衡、硅谷對本地計算機的認知誤區、AI 漸進式起飛背景下的 Agent 協作范式轉移以及skill如何重塑人類工作流等話題。

Felix Rieseberg指出，Claude Cowork 的核心價值在于為 AI 提供了一臺運行 Linux 系統、具備高度自由度的虛擬機，他認為，硅谷當前嚴重低估了本地計算機的價值，在基礎設施完全適配當前的AI 浪潮前，將電腦克隆到云端存在巨大的認知與技術挑戰，而讓 AI 貼近用戶的本地環境、直接訪問工具與瀏覽器 Cookie，才是現階段實現長程任務委派的高效路徑。

此外，Felix 認為模型實際能力遠超目前的使用方式，這源于開發者未能提供充足的工具。他預測，未來個人的核心生產力資產將從標準化的產品轉向私有的skills庫，通過符號鏈接實現skill在不同 Agent 框架間的無縫映射。

對于 AGI，Felix 認為當 AI 能夠自主處理如 Google Cloud 注冊等高度復雜的流程時，變革實則已經發生。未來，AI Agent 將不再局限于單人模式，而是通過人類現有的社交工具或專用通訊協議，實現 Agent 之間的直接對話與任務交接 。

01

Claude Cowork 的誕生與定位

作為 Cowork 的核心技術人員，能否請你從宏觀層面為那些還沒有嘗試過的人介紹一下，究竟什么是 Claude Cowork？我最近對這個產品非常癡迷，它能幫我處理視頻命名、編輯等所有瑣事，甚至讓我感覺 AGI 已經實現了。雖然你把它定位成一個更易用的版本，但它能與 Chrome 及其他工具集成，它是否更像是一個功能上的“超集”權力用戶工具？

Felix Rieseberg: 官方頭銜是技術核心人員，這個職銜可能會一直伴隨著我。我很想看看那個演示。我工作中最大的樂趣之一，就是觀察用戶如何以各種奇特的方式使用 Cowork。顯然，我們很難針對所有特定的使用場景進行設計，但那些對產品感到最驚艷的用戶，通常是因為 Cowork 完成了一些我從未預料到它能勝任的任務。

我們有一位新設計師，他接手的首批小任務之一是為內部 Slack 頻道設計一個新的 Cowork 表情符號。他畫了一個 SVG 文件并直接交給 Cowork，問它能否為這個表情做個動畫。現在這個表情擁有了一個非常漂亮的循環動畫效果。這證明了你可以利用代碼實現比預期多得多的功能，這種探索對我來說非常有趣，我也很期待看到你們的使用案例。

簡單來說，Claude Cowork 是 Claude Code 的用戶友好版本。我們的核心邏輯是，我們擁有 Claude Code 這一性能強勁的 AI Agent 框架。在去年 12 月，我們注意到越來越多的人開始使用它，即便他們并非技術人員，不習慣使用終端命令行。甚至是一些技術人員，也開始將 Claude Code 用于非編程任務，比如管理開支、整理收據或組織知識庫。

當時很多人對 Obsidian 的聯動感到興奮，我們希望把握住這個趨勢，將這種能力帶給那些非終端原生、不知道如何通過命令行安裝軟件的用戶。因此，Cowork 的本質是在虛擬機中運行的 Claude Code，我們增加了一些緩沖設計和安全護欄，使其對于那些不想一上班就打開終端的用戶來說更加安全、便捷。

（關于權力用戶工具定位）坦白說，我不認為你這種看法有錯，這也是我過去兩周一直在思考的問題。這讓我想起大約 10 到 12 年前我在 Microsoft 的經歷。當時我們開始研發 Electron 以及跨平臺技術，Visual Studio Code 最初其實是一個網站。當時的敘事是 Visual Studio Code 是 Visual Studio 的輕量易用版，甚至有聲音認為嚴肅的開發者不會使用它。但最終，Visual Studio Code 取得了巨大的成功。

我個人的看法是，可定制性和擴展性起到了決定性作用。你可以將 Visual Studio Code 接入幾乎任何工作流，針對它進行二次開發極其容易。我覺得 Cowork 也在經歷類似的過程，它極易擴展且能輕松融入現有工作流。這種便利性雖然是開發者追求的目標，但用戶發現其價值的方式，通常是將其映射到他們日常工作的具體任務中。

02

執行成本趨于零，但底層平臺的可擴展性價值正在增加

去年年底你看到了 Claude Code 出現大量非技術用途，那么決定開發獨立產品 Claude Cowork 而非修改原有程序的觸發點是什么？你們只用了 10 天就把它做出來了，這種設計過程是怎樣的？另外，當人們說軟件的價值將歸零，因為它可以被輕易重造時，你是否覺得擁有一個現成的、可擴展的平臺反而更有價值？人們應該在底層原語上投入更多嗎？

Felix Rieseberg: 在 Anthropic，我們一直在思考如何讓習慣于問答模式的用戶能夠利用 AI 的力量去執行任務。它能為你解決問題，為你構建東西，我們希望將這種能力帶給那些目前只習慣于聊天對話的用戶。其實我們在這個方向上已經做了很多原型，甚至可以追溯到一年半以前，公司內部有很多工程師在研究這個方向。

Anthropic 內部有一種非常推崇原型演示優先的文化，我們有許多未公開的內部原型。Cowork 實際上是從這些已有的原型中挑選出最合適的組件組合而成的。關于 10 天完成開發這個說法，我想加一個重要的限定條件，在項目正式啟動前，內部已經打好了很多基礎。就像你用 React 開發網站一樣，你是在利用現有的工具棧，這與我們當時的情況類似。

在決策路徑上，我們正處在一個執行成本變得極其低廉的新世界。過去我們可能需要產品經理去接觸潛在客戶，低效率地調研他們的痛點，然后起草說明書、做設計、最后執行。但在 Anthropic，我們現在的做法是直接構建，不寫備忘錄，快速把所有可能的方案都做出來，然后從中選出最好的。目前最有影響力的決定，是我們如何在用戶的本地計算機上交付價值。這是一個核心決策點，這個工具最終應該運行在本地還是云端，這其中涉及巨大的權衡。

（關于平臺原語的價值）沒錯。我認為你是對的，整體性的平臺非常有用。這在 AI 領域可能是一個有點反直覺的觀點，我不認為未來會是那種每個人都運行自己專屬定制化軟件的世界。如果每個人都用自己的內部聊天工具，那我們要怎么互相溝通？

在構建 Cowork 的過程中，執行變得廉價并不意味著要重造所有原語（AI 系統提供的最基礎能力），從先驗的角度看，那樣做的價值也不大。我的團隊從一開始就認定核心必須是 Claude Code，然后在此基礎上構建。執行變便宜體現在你如何像玩樂高積木一樣，將這些現有組件以對用戶有意義且有價值的方式組合起來。現在的問題是，你會把哪些功能定義為底層的原語？你是堅持只用公開可用的原語來構建產品，還是保留一些內部核心技術？

我認為模式仍在演化，但我以后可能再也不會在沒有經過用戶測試的情況下，就試圖憑空構思一個產品。這雖然不是新概念，但過去在技術選型或架構路徑上做決定成本很高，而現在我堅信你應該把所有方案都做出來，找一小部分核心用戶試用，看哪個效果好就選哪個。這種工作方式與一年前相比已經發生了巨大變化。

（關于語言實現的靈活性）重點不在于編寫 Electron 的綁定代碼，而在于應用程序內部發生的邏輯。至于用什么語言實現，AI 可以幫我輕松搞定。

03

在 AI Agent 的未來真正到來前，基礎設施需要慢慢追趕

我們能否為 Claude Cowork 建立一個清晰的心智模型？它本質上是 Claude Code，此外還有云端應用和 Chrome 插件。我想澄清一下 Cowork 的主要組成部分，特別是關于規劃功能。此外，既然已經開始在本地機器上深度使用 AI 了，這引發了一個思考：難道不應該一切都以云端優先嗎？

Felix Rieseberg: 你理解得很到位。實際上你可以把規劃這個概念先放一邊。Cowork 中最有價值的部分是虛擬機。我們運行一個輕量級的虛擬機，并將 Claude Code 放入其中。這樣做有很多原因，安全和保密是重中之重。但即使拋開這些不談，給 AI 一臺屬于它自己的計算機也是極其強大的。在架構和交互設計中，將 AI 深度擬人化通常是很有用的。如果是一個真人為你工作，你會給他什么？

我今天早上給我也在用 AI 編程的父親舉了個例子。如果你是一名開發者，雇主卻說不需要給你配電腦，只讓你通過郵件接收和發送代碼，那工作效率會極其低下。而在虛擬機環境下，因為它是一個 Linux 系統，Claude Code 擁有極大的自由度來安裝所需的工具，比如 Python 或 Node.js。雖然我們有嚴格的網絡訪問控制，但用戶可以用自然語言明確系統可以做什么。我們不再需要去咨詢法務或市場部門，詢問是否可以安裝 Homebrew 這種瑣事。

問題與答案的深層影響非常復雜且微妙，并不容易推導，這種復雜性給 AI 帶來了很多干擾，但也讓 Claude 變得非常強大。我們幾乎每周都在增加新功能，你可能已經注意到，這些改進使得 Claude Cowork 在處理某些任務時比基礎版 Claude 更為出色。實際上，大部分優化都體現在系統提示詞中。這些優化的核心在于 AI 如何推導你的工作內容，以及我們如何在系統提示詞中包含特定信息來提升效率。當然，這也離不開 Claude 與 Chrome 的深度集成。隨著模型能力的提升，很多人在面對 MCP 連接器時感到無從下手。我不愿意翻遍幾十個連接器去到處點擊，結果發現有一半功能還無法正常使用。因此，Claude 與 Chrome 的結合非常高效，我們可以直接通過 Chrome 子智能體下達指令，它就會自動完成任務。

在開發 Claude Cowork 的第一周，我發現自己開始用它處理編碼任務，雖然這并非它的初衷。我在內部工具中挑選那些容易修復的 Bug，過濾掉涉及內核損壞或操作系統的復雜問題。我告訴 Claude Cowork，去所有崩潰分析工具中找到可修復的 Bug，然后指派另一個 Claude 實例去修復它們。

swyx： 指派另一個 Claude 是指啟動一個新實例嗎？

Felix Rieseberg: 目前我的做法是讓它通過 Claude Code 遠程訪問目標網站。這相當于一個循環，針對每個 Bug 生成帶提示詞的 Markdown 文件，并為每個文件啟動一個 Claude 會話。雖然 Claude Code 本身有子智能體的概念，但我當時是采用遠程任務的方式運行。這樣我發完任務就能去開會，而遠程端的工作會持續進行。

（關于云端優先的權衡）我認為硅谷整體低估了本地計算機的價值。為什么我們還在用 MacBook 而不是 iPad 或 Chromebook？ 因為 AI 作為助手，需要擁有和你一樣的工具訪問權限，否則它在處理復雜任務時會處處受限。我們可以采取兩種路徑，一種是逐一將工具移入云端，但我沒耐心管理所有權限并保持更新。

另一種路徑是全盤接收并上傳你的所有工作內容到云端。如果點擊一個按鈕就能把整臺電腦克隆到云端，我不確定用戶是否真的想要。這在技術挑戰之前，首先是認知挑戰。在授權下，理論上我們可以讀取你的 Chrome Cookie 并傳到云端，這在技術上很簡單，能讓你在云端完成所有任務。但很多網站一旦檢測到異地登錄身份就會鎖定賬戶，屆時你可能需要帶著護照去銀行柜臺解鎖。盡管大家對 Agent 這個詞已經聽厭了，但在 AI Agent 的未來真正到來前，基礎設施需要慢慢追趕。在此之前，提升效率最好的辦法就是讓 AI 貼近你的工作環境。

04

模型能力沒有完全釋放的原因是沒能給 AI 提供足夠的工具

從定性感覺上，Claude Cowork 的長程能力似乎比 Claude Code 更強。關于評估，你們是進行感性測試還是自動化的程序評估？此外，在失敗模式中，有多少是由于模型智能限制，有多少是由于將智能投入工具的工程化水平導致的？

Felix Rieseberg: 我們會根據評估結果每周調整技巧。Claude Code 和 Claude Cowork 的評估用例完全不同。Claude Code 側重編碼任務，主要通過它在處理軟件工程任務時的表現來衡量。而 Claude Cowork 更多針對金融或法律辦公等知識工作。我個人的用例通常是管理私人事務，比如房貸規劃或家庭財富管理。你感受到的差異其實源于我們對系統提示詞的微調，以及我們通過工具賦予 AI 的引導方向。由于性能權衡客觀存在，Claude Code 會更擅長代碼，而 Claude Cowork 更擅長非編碼任務。這種差距在未來幾代模型中是否還會存在，目前還不確定。因為現在的這些超強優化，我不確定長期來看是否還有必要。

（關于長程任務的處理）實際上，用戶傾向于交給 Claude Cowork 那些時間跨度更長、任務量更大的工作。當工作變長，目標就會變得模糊，所以我們要求 Claude Cowork 大量使用規劃工具和詢問工具。我們希望它先厘清用戶真正想要什么，而不是埋頭干四個小時最后交回一個錯誤的結果。

（關于評估流程）我們所謂的評估是分析整個對話記錄，包括 AI 調用的所有工具，然后根據調整的參數來測量輸出。這個流程貫穿在訓練和開發中。如果把后訓練與外圍的腳手架（Scaffolding）分開看，Claude Cowork 更多存在于腳手架空間，但我們也針對它進行了訓練。評估意味著分析在給定對話記錄下的輸出結果，包括文件輸出和 Token 輸出。

（關于模型能力與工具工程化）我一直在思考的是模型能力冗余問題。模型的實際能力往往遠超用戶的使用方式。部分原因是我們沒能給 AI 提供足夠的工具。但在構建腳手架時，我也會考慮這些復雜的腳手架在未來是否會消失。作為前沿實驗室的工程師，我能更早洞察下一代模型的能力。

我在想，我們是應該投入大量精力去修補腳手架，還是應該盡可能賦予它更多能力，并在確保安全的前提下等待下一代模型發布。我目前更傾向于后者。很多公司在做非常專業的 AI 定制化應用，短期看很有效，但一旦模型的泛化能力進一步提升，這些過度引導的特定用例可能就不再有必要了。這種趨勢在skills功能和 MCP 服務器的演變中已經初見端倪。比如 Barry 最初開發的skills原型，看起來和現在的 Claude Cowork 非常像。他最初是想為非開發者提供類似功能，最典型的用例是數據分析。團隊發現與其為連接數據倉庫構建自定義工具，不如直接告訴 AI 接口端點和 API 的樣子，讓它自己搞定。

隨后 AI 將接管控制權。這就像是在抽象層級上又往上提升了一步。以前你必須明確指令 AI 這是一個 CLI 并要求其調用，或者提供一個符合 MCP 規范的 API 結構，現在你只需要定義終點。如果你想了解某些信息，只需在此發布需求，甚至可以直接發送 SQL 語句，這都能正常運行。這種模式非常有效，開發團隊開始嘗試只給大模型提供一個描述任務需求的 Markdown 文件。這套體系最終演變成了skills系統，我們意識到應該將其封裝成產品，這套方案非常出色。

我想展示一下我使用 Claude Cowork 的方式。起初我并不信任它，但它直接幫我完成了從 Zoom 下載錄音、重命名并上傳至 YouTube 的繁瑣流程，這簡直取代了視頻博主的工作。我甚至讓它自主創建skills，將大任務拆分成子skills并由父級skills統一編排，現在我每周都會運行這些skills。人們上手的路徑通常是先找繁瑣任務替代，隨著信任增加再擴大范圍。你在 Cowork 上有做任何專屬的特殊功能嗎？

Felix Rieseberg: 看到這些應用場景非常有啟發。skills系統最吸引人的一點在于其極低的門檻。任何人都能像發短消息一樣創建一個skills，并且實現高度的個人定制化。這本質上是一個抽象層，我猜你在設置時一定給過它不少指導。這種模式非常優雅。

（關于自動化邏輯）這就像是在現實生活中玩《異星工廠》，你從微小的自動化環節切入，逐漸建立起一個龐大的自動化帝國，讓生活變得越來越輕松。我個人最常用的skills是日歷沖突管理。人們總是在最后一刻塞進來各種會議，處理起來很痛苦。雖然我還沒把它正式發布成skills，但在自定義提示詞里已經寫明了規則。我設定了明確的優先級，比如 Dario 安排的會議絕對不能推掉。它會根據我關心的程度、工作時間偏好來自動協調日歷。這種細微的體驗最能讓用戶產生共鳴。

我們發布 Cowork 時，在 X 平臺上最火的一個案例是清理桌面。你其實并不真的需要一個大模型來整理文件夾，但這種體驗真的很聰明。沒錯，需要給它訪問權限。很高興你喜歡。我們是 Claude Cowork 團隊的，如果你希望這些功能也出現在 Claude Code 里，盡管告訴我們。

05

視覺能力與 Computer Use 的進化

我現在還在嘗試用它做數據分析和設計轉代碼，比如直接丟給它一個 Figma 文件。雖然我寫代碼習慣用終端里的 Claude Code，但 Cowork 的 Chrome 集成在網頁開發和調試方面表現更出色。既然功能相通，為什么它不能同步我之前的 Claude Code 會話呢 ？另外，萬物皆可視覺化是 Computer Use 的核心超能力，剛發布時我覺得它慢且不可靠，但短短一年間的進步確實驚人。

Felix Rieseberg: 我很想聽聽你對桌面版應用中內置 Code 功能的看法，雖然我和他們是同一個大團隊，但我自己從不使用桌面版。我們的內置瀏覽器功能其實是為了給 AI 提供一雙眼睛。當它能實時看到你的工作界面、調試 DOM 樹時，效率會產生質的飛躍。這就是你在 Cowork 中體驗到的強大功能。無論它是調用你的 Chrome 還是使用內置瀏覽器，核心邏輯是一樣的。只要 AI 能看見它正在處理的對象，它就不再需要你反復去跑測試或運行 QA，因為它自己就能實時糾錯。

（關于會話同步）問得好，目前還沒實現，但我們正在努力。這就是 OpenAI 團隊一直在做的那類集成工作。我們的思路是與其重新造一個瀏覽器，不如去集成那些已經足夠優秀的既有工具。我們的目標不是取代你電腦里的應用程序，而是完美地融入你現有的工作流，創造一種全新的協作方式。我們希望在用戶已經在用的地方提供服務，而不是強迫用戶為了使用 AI 而切換瀏覽器。我只想為那些有一堆繁瑣任務、希望通過 Claude 釋放生產力的人構建工具。

（關于操作能力進化）初期它確實幾乎不可用，但這一年來的提升非常顯著。確實，直接編寫執行腳本更具定制化特征，我們正在向架構上層演進。Computer Use 是一個極具潛力的領域。我不認為我們離“AI 高效操作你的個人電腦”還有多遠，它將不再局限于操作一個虛擬的云端環境。

06

讓skills成為跨 Agent 的核心資產

你怎么看skills的可移植性？比如我在其他工具里處理辦公室訪客登記的skills，目前沒法直接在 Cowork 里用。我不希望記憶是通用的，但我希望skills能跨 AI Agent 使用。目前在 MCP 領域，人們也在嘗試做網關或注冊表，我不確定這是否能成為一門生意。

Felix Rieseberg: 對我來說，這又回到了最基礎的原語。我們的skills本質上是基于文件的，而不是鎖死在某個封閉平臺里的私有格式。這種設計天生就具備極強的可移植性。這些skills作為容器格式的一部分，以前統稱為插件。插件在 Claude Code 中的應用非常廣泛，其采用統一的格式，用戶可以方便地安裝。在當前的 cowork 協作環境中，你只需簡單地將整個 GitHub 倉庫添加進去即可實現。

這種模式類似于skills市場或插件市場，是實現便攜性的核心手段。我認為這個領域仍有巨大的增長潛力。目前的挑戰在于如何提高用戶對可編寫skills的認知，并簡化skills的分享流程。如果過于強調連接 GitHub 倉庫等技術細節，往往會令普通的知識工作者感到困惑，因為這不符合通用辦公場景的操作習慣。目前行業內尚未解決的一個關鍵問題是，如何界定skills中哪些部分是通用的便攜組件，哪些部分是與個人強綁定的私有組件。

關于skills的結構化，可以嘗試將公共skills與私人skills進行配對。最直接的實現方式是采用字符串插值（String Interpolation），自動填入用戶名、電話或特定文件路徑。雖然目前的方案還略顯笨重，但未來必然會出現一種既能保留skills便攜性，又極易上手的模式。skills本質上是基于 Markdown 的純文本文件，理想的編寫體驗不應依賴繁瑣的教程，而應像指導新員工訂機票一樣，通過自然語言描述流程，讓 Claude 能夠快速理解并執行。

（關于個性化訂票場景）當然，我們需要將通用流程與個人偏好深度結合。以訂機票為例，我不認為 AI 應該完全接管訂票動作，因為這涉及復雜的個人選擇。訂機票是目前最常見的 Demo，但這其實并不是一個理想的展示場景。我更傾向于自己掌控訂票過程。之所以人們反復提起這個例子，是因為它典型地包含了普適性與個性化兩個維度。普適性體現在追求性價比，個性化則體現在對時間、座位和機場的偏好。如果能將這些需求整合進一種便攜、兼容且易懂的skills格式中，將極具競爭力。

（關于skills云端同步）從數據存儲的角度來看，現在的云端協作環境應該支持符號鏈接（Simlink），將用戶的skills庫無縫映射到所有的 AI Agent 框架中。我們在內部維護了一個名為 Valuable Tokens 的倉庫，存放了所有的命令和子 Agent，并開發了相應的 TUI 工具來實現快速部署。目前的實現手段還比較原始，基本等同于文件復制。理想的體驗應該是，每進入一個新環境，系統就能自動關聯云端文件夾并同步所有skills。目前的現狀是，如果更換 AI Agent，用戶不得不手動尋找并復制這些分散的skills文件。這種尋找成本是目前最大的痛點。未來，個人的核心生產力資產將不再是產品本身，而是這些私有的skills庫。畢竟產品是標準化的，真正的差異化在于用戶如何通過這些配置文件來定制自己的工作流。

（關于行業未來趨勢）我傾向于將 AI Agent 和大語言模型視為協同工作的伙伴。我在 Notion 工作時深知實現信息同步的難度。你所追求的實際上是讓所有的 AI Agent 在用戶的偏好、skills和執行方式上達成共識。未來可能會出現一種類似于skills版 Dropbox 的獨立機構，作為權威的skills托管中心，將鏈接嵌入到各種產品中。盡管商業閉環尚不明確，但這確實是一個極具前景的方向。隨著技術進步，很多傳統業務模式正在瓦解。skills應該能夠在個人生活與職業場景之間進行插值。雖然底層的邏輯架構是一致的，但具體的執行細節會有所不同。作為工程師，最有效的手段依然是符號鏈接。將 AI Agent 讀取 Markdown 文件的過程視為一種鏈接行為，雖然當前有效，但我們需要更智能的方案。你可以直接向 cowork 描述需求，讓它自動完成這些底層的配置工作。

07

垂直行業應用與勞動力市場沖擊

現在正值報稅季，我認為用 Claude 處理財務是一件大事。它現在已經支持原生輸出 Excel 文件了，這是否意味著你們有專門的工程團隊在負責垂直行業方向 ？另外，它通過視覺能力讀取視頻內容理解得越來越深，這種通過截圖識別視頻的邏輯雖然沒有轉錄精準，但也足夠好用了。

Felix Rieseberg: 我們非常看重垂直行業，因此設有專門的垂直行業團隊和企業服務團隊。這些工程師每天都在思考如何讓 Cowork 在特定行業中發揮最大效能，如何讓非技術人員更容易理解并接入 AI，從而獲得與軟件工程師同等的價值。軟件工程師之所以能站在 AI 浪潮的最前沿，是因為我們已經習慣了各種像魯布·戈德堡機械一樣復雜的自動化嵌套系統，自動化本就是我們工作的一部分。Claude 作為模型，其能力與這些數據密集型行業的需求高度契合，因為在這些領域，處理海量數據的準確性至關重要。關于稅務處理，我曾發推特提到 Claude 正在幫我報稅，這確實不可思議。雖然推特受眾可能并不想看我的納稅申報單，但那種體驗確實很酷。

（關于視覺識別邏輯）它是具體怎么實現的？我很好奇。明白，它是截取屏幕截圖，然后通過視覺能力進行識別。我們已經意識到了圖像生成等功能的需求。對我來說，觀察 Claude 的創造力以及它解決問題的獨特方式是非常有趣的。

（關于勞動力市場沖擊）關于行業沖擊，目前存在明顯的短期壓力，即如何將 Token 轉化為實際價值。在編碼和企業搜索領域，所有的初創公司都在向技術棧的上層遷移。如果第一方平臺如 cowork 已經覆蓋了大部分工作流，那么單純的搜索功能將失去議價能力。目前的價值洼地在于規劃。AI Agent 的核心優勢在于針對特定任務的規劃能力和專用工具集。但隨著模型能力的進化，這些功能正逐漸被集成到本地設備端。如果初創公司能穩定交付最終的任務結果，而不只是提供中間工具，那么它依然具備競爭優勢。

Anthropic 非常關注 AI 對勞動力市場，尤其是初級崗位的沖擊。當我們通過自動化消除那些冗余工作時，實際上也消滅了很多初級員工賴以成長的崗位。這是一個嚴肅的社會問題，我們需要思考如何為職場新人提供新的成長路徑。一種可能的方案是創造模擬實戰崗位。在軟件工程領域，初級員工的成長往往是非線性的。我們可以利用 AI 模擬高密度的實戰場景，將原本需要數月的項目經驗壓縮到一周內的速通訓練中。一年內，員工就能積累傳統模式下三年的經驗。雖然這種模式在缺乏反饋閉環的領域較難落地，但在法律或量化金融領域具有極高的可行性，類似于 Jane Street 模擬器，在其中高強度訓練三個月即可具備實戰能力。

（關于教育模式對比）資深工程師在 AI 的助力下正變得更加高效，創造了更大的價值。以滑鐵盧大學的畢業生為例，其核心競爭力在于強制性的實習制度。他們在畢業前就接觸過真實的用戶需求和生產環境，這與純理論的大學教育有本質區別。德國的大學教育往往過于理論化，導致企業必須從頭教起。滑鐵盧大學的學生通過在大廠輪崗實習，在畢業時已經具備了極強的實戰經驗。隨著初級崗位的縮減，這種實戰化教育模型將成為未來的必然選擇。年輕人的優勢在于神經可塑性更高，偏見更少，更容易成為 AI 原生代。但問題在于，未來可能不需要那么多初級員工了。Anthropic 認為 AI 對市場的沖擊將是巨大的，社會各界需要加強對這一議題的討論。通過頻繁發布工具，我們可以讓公眾在漸進式的起飛過程中逐步適應變化，而不是被技術爆發淘汰。

08

AI 變革已經發生，重點在于讓 AI 接手更大規模的任務

剛才提到的清理桌面的計劃任務完成了，它是按文件類型組織的，但我更希望它能按主題進行歸類。目前我需要賦予它讀取視頻文件的skills，讓它明白我的處理習慣。關于 AGI，有人預測是 10 年，有人覺得只要 1 年，你如何看待這個時間點？另外，我發現我已經可以讓它去注冊 Google Cloud 這種復雜操作了，這對我來說意味著實現了 AGI，在那之外還有什么？

Felix Rieseberg: 你可以直接跟進要求它那樣做。你看，它的提案里確實已經包含了相關的建議。雖然你現在用的是 Opus 4.6，但我給用戶的建議是：不必再糾結這些細節，直接告訴 AI 你的需求即可。AI 往往能找到實現路徑，即便那個方法未必是你習慣或預想的方式。我非常好奇 Claude 最終會構思出什么樣的方案。

關于 AGI 還有多少年能實現，大家可以各抒己見，有人預測是 10 年，有人覺得只要 1 年。我不確定自己傾向于哪個時間點，但最終這是否在四五年內發生可能并沒那么重要。如果我們擁有一個性能合格的模型，那變革必然會發生，這是我們必須面對的課題。通過頻繁發布工具，我們可以讓公眾在漸進式的起飛過程中逐步適應變化，而不是被突如其來的技術爆發所淘汰。大家都在期待那個大爆炸時刻，即 AI 的進化形成自我強化循環、 Scaling Law 驅動下的能力加速徹底垂直化的時刻。到那個階段，競爭就會全面爆發，不再有緩慢追趕的余地，你會發現 Claude 在處理任何任務時都表現得異常出色。

（關于 AGI 后的場景）這基本上涉及到一種觀念，你現在仍然必須告訴它去構建你的腳本，你仍然有所參與。雖然這看起來很神奇，但在我看來，這種參與還是太重了。我看到了太多的瑣碎流程，我希望能把這些負擔從用戶身上卸下來。我會繼續沿著技術棧向上突破，讓你的生活越來越輕松。

（關于觀察日常操作的建議）很有趣。在我的職業生涯中，我從不習慣提前預告還在開發中的功能，你應該打好基礎并直接發布，然后再談論它。但令我驚訝的是，你們剛才提到的很多點，在我們看來都是極其顯而易見的方向。應該有人在做那些事情。如果你觀察 Claude Code，我們將要發布的東西可能不會讓你們感到意外。你會說，那顯然是有價值的，顯然我們正在推進。我們的功能越多地屬于那一類，對我們就越好，因為那樣我們就不會最終構建出那些過于專業化、難以駕馭的東西。避免過度專業化非常重要，這讓你保持通用目的，意味著你沒有把眼光局限在某個垂直領域。

09

虛擬機的技術底座與跨平臺權衡

有人抱怨 Claude Cowork 創建的虛擬機體積太大，動輒 12 到 15 GB。此外，如果 AI 正在我的電腦上執行任務，我就沒法同時使用它了，這里存在一個競爭條件。我想提一下，Felix 是真正的虛擬機專家，之前做過 JavaScript 運行 Windows 95 的項目。現在的虛擬機在開發中存在哪些性能權衡？特別是針對 Windows 平臺的支持是如何實現的？

Felix Rieseberg: 這確實是個有趣的話題。在開發 Cowork 初期，我曾構思過讓 Claude 擁有自己的獨立光標。這聽起來很酷，但實際操作中會遇到很多問題，因為無論是 Apple 還是 Microsoft，其操作系統的底層邏輯都是基于單一用戶操作設計的。雖然應用層可以實現前后臺并行，但在操作系統層面實現雙重操作極其困難。我一直在思考 Claude 操作電腦的最佳形態：是為你準備一個獨立的虛擬機環境供你偶爾查看，還是讓它在你離開電腦時接管操作，亦或是完全在云端運行。這取決于你與電腦、與數據之間的親密度。

（關于 Windows 95 項目）代碼還在我的 GitHub 上，那是你個人主頁上最吸睛的項目。那是個非常有趣的項目。我得澄清一下，我并沒有編寫 Windows 95 的底層系統，也沒有編寫那個能模擬 x86 處理器并在 JavaScript 中運行的 V86 引擎。那個項目源于公司內部關于 Electron 優缺點以及是否該用 JavaScript 構建軟件的辯論。我想證明既然我能在 JavaScript 里跑通整個 Windows 95 甚至運行 Excel，而且速度還比很多 SaaS 應用快，那 JavaScript 的性能上限其實很高。我花了一個晚上就把它做出來了，主要是為了調侃 Slack 的同事。

（關于 Cowork 虛擬機的技術細節）那個虛擬機確實很酷，雖然在開發中存在很多性能權衡。很多人問為什么虛擬機占用了 10 GB 空間，其實那是 macOS 顯示的問題，我們通過壓縮鏡像中的空白空間，實際占用的磁盤空間并沒有那么多。但這屬于技術細節，對用戶來說，他們更在意的是 30 秒的啟動時間。無論技術上如何解釋，30 秒的體感啟動時間確實太長了。無論采用哪種方式，性能都會比直接在本地運行 Claude Ultra 慢一些，這種權衡是客觀存在的。

（關于 Windows 平臺實現）在 Windows 平臺上，我們利用了 Windows 主機計算系統 (Host Compute System, HCS)。這套系統也是 WSL2 的運行基石，很多開發者都非常認可這個子系統。它的精妙之處在于，我們需要明確劃分虛擬機的運行空間，并嚴格控制通信權限，因為你賦予了這個虛擬機相當大的權力。我們不僅要優化兩個系統之間的連接，還得確保其他隨機應用無法干擾虛擬機內部 Claude。

上周我們開始編寫一套全新的網絡驅動服務，專門優化 Claude 訪問互聯網的方式。如果你的公司實施了深度包檢測或在內網拆解 SSL 流量，那么簡單版本的 Claude Code 很容易在用戶電腦上崩潰。但我們現在的方案表現非常出色，能兼容絕大多數用戶的環境。我常舉的例子是，我希望這個工具在普通用戶隨手拿起的機器上都能高效運行。而那臺機器很可能沒有安裝 Python 或 Node.js，如果缺少了這兩項環境，從本地運行的角度看，Claude 的效能就會大打折扣。

在 Mac 上，我們利用了 Apple 虛擬化框架，它非常穩健且經過深度優化，調用 API 也非常簡單。一旦你開始發布生產級別的代碼，就必須不斷處理各種邊緣情況。但不得不說，Apple 在虛擬化框架上確實表現極其出色，既快速又可靠。Windows 也是如此，其主機計算系統和 WSL2 堪稱系統中的瑰寶。它是極少數能讓開發者一致好評的功能，接入同一個子系統讓我們更有底氣。無論你的電腦權限被鎖得有多死，哪怕是雇主禁止你安裝任何插件，我們都能正常運行。

（關于隔離的安全性）在很多辦公環境中確實如此。即便在 Anthropic，IT 部門也會嚴格控制安裝權限，這是很多公司的常態。這反而減輕了 IT 部門壓力，因為我們可以將 Claude 的計算環境與用戶的環境隔離開。對于 Claude 的運行環境，你可能會擔心數據丟失、潛在的敵對行為者或數據外泄。一旦你控制了網絡和文件系統層，你就不必再擔心 Claude 編寫的那些 Python 腳本了。真正讓人擔心的是，如果你直接在本地安裝 Python，任何人都能在你的電腦上執行任何操作。而一旦放入虛擬機，這種風險就會大幅降低。

10

Claude Code 的未來是什么？

人們普遍存在審批疲勞，你不可能去核準每一條指令。沙箱化恰恰提供了某種中間地帶。我想知道 Claude Code 的未來是什么？遠程控制在 Claude Code 上能用了嗎？

Felix Rieseberg: 是的。我認為 AI 行業有責任提出更好的方案，而不是簡單地說只要它什么都不做就是安全的。如果你想讓工具真正有用，卻還得讓用戶步步審批，那就失去了意義。計算機使用功能就是一個典型例子。要在宿主機上實現絕對安全的計算機使用，唯一的辦法就是讓你批準每一個動作。比如 AI 模型說它想輸入某個詞，你覺得沒問題，但這就不叫自動化了。你需要實現真正的委派，在授權后可以放心走開，并相信系統不會搞出大亂子。我們不必非要等到系統完美無缺或模型 100% 對齊后才行動。我們可以沿用行業內成熟的瑞士奶酪模型，通過多層防御來降低風險。但我們確實需要加大投入，構建那種無需事事審批的系統。

作為開發者，我們對風險的容忍度可能更高，但也帶有一種自信，覺得如果真的出了大問題，我們也大概率能修補。不只是 Claude，簡單的操作比如 npm install 也是如此。我們都在以全權用戶身份運行它，如果它想讀取 SSH 密鑰，它完全能做到。默認環境竟然如此不安全，這挺瘋狂的。最安全的方法是什么都不做，但我們想要的是強大的產品。在可能的范圍內，我不想反復問你是否允許運行這個腳本，因為我相信，一旦它成為你工作流的一部分，你可能沒有精力去逐行檢查 Python 代碼是否安全。

（關于 Claude Code 的未來）我們還處于起步階段。我們會繼續保持快速迭代，你可以期待每周都會有新功能發布。我會繼續在本地電腦場景下加倍投入，讓你和 Claude 在本地都能高效工作。我們開始更多地應對關于“你的電腦”的定義問題，它必須是擺在你面前的這臺機器，還是你電腦上的虛擬機，或者是云端的某個環境？ 第三點讓我興奮的是，我們正在進行這種逐步爬升式的嘗試，引導那些習慣于提問并獲得答案的用戶學會放手，讓 Claude 接手越來越大的任務，無論在時間跨度還是任務規模上都是如此。

（關于遠程控制）極好的問題。即將推出。如果你想繼續押注在本地電腦上，那是一件顯而易見的事。

11

未來的 AI 將通過人類工具或專用協議進行協作

為什么我們要在一個應用里封裝一個完整版本的 Chromium？直接使用操作系統自帶的 Web 視圖難道不是更容易嗎？此外，我看過 Tauri，你對它有什么看法？ 另外關于協作，如果我的 Claude 協作 AI，它的多人模式是什么樣的？是 AI 之間構建通訊協議，還是直接讓它們使用 Slack 等人類工具？ 最后想聊聊 Anthropic Labs。我一直把實驗室分為模型實驗室和 AI Agent 實驗室。Claude Code 現在就屬于這個內部的 AI Agent 實驗室嗎？

Felix Rieseberg: 答案是肯定的，那樣確實更容易。事實上，我早年參與構建 Slack 應用時就嘗試過這種方案。我在加入 Slack 時，他們已經有一個基于類似 PhoneGap 技術構建的應用，直接調用操作系統的 Web 視圖。但那個方案因為各種原因失敗了，于是團隊決定動用更強大的技術手段，也就是加強對渲染棧的控制。選擇嵌入式渲染引擎的原因在于，直到 2026 年這依然是真理：操作系統的原生渲染引擎做得還不夠好。升級這些引擎的唯一途徑是升級操作系統。

為什么要選 Chromium？盡管它體積巨大，但它是目前為止最出色的工具。像 Unreal Engine 這樣頂級的引擎，如果要渲染文本，底層也會使用 Chromium。Chromium 是工程界的奇跡之一。它能動態渲染 YouTube 視頻、協商比特率、處理極其糟糕的硬件驅動程序。你可以訪問 Chrome 的 gpu 頁面，你會發現密密麻麻的已啟用補丁，全是針對你電腦硬件問題的變通方案。所有這些努力，只是為了確保當開發者要求在這里顯示一個紅色像素時，它能準確無誤地發生。Chrome 之所以偉大，是因為它能極其可靠地運行在用戶扔給它的任何機器上。Electron 的魔力就在于，它能讓你輕松地以最符合業務場景的方式封裝并調用 Chromium。

作為工程師，我們往往假設底層的平臺層是極其穩定的。但當你真正和底層開發者交流時，他們會說其實我們也是在瞎猜。我在 Slack 工作時有個很深的感觸：NVIDIA 是我們的客戶。曾有一個 bug，Slack 里的 YouTube 視頻會出現奇怪的偽影，最終發現那是 Chromium 的一個 bug。這種事在技術棧的每一層都在發生。

（關于 AI 重寫原生應用）這聽起來確實有可能，它會變得越來越強。我一直在等待一個 AGI 時刻：什么時候我們可以說不再需要 Electron 了？ 現在的 AI 模型已經非常有能力把 Electron 應用重寫為 Swift 代碼。但它們能否構建出性能更高、內存占用更少的超優化應用？這需要開發者長期積累的高度優化經驗。我們還沒到那一步，即使是最強的模型，也無法在處理這種極其復雜的任務時做到完全不出錯。現在的 Ultra Think 推理模型在處理這類任務時還有壓力，或者說，我們需要讓它持續思考好幾天。

（關于 AI 協作模式）這非常有趣。這又回到了腳手架的問題：我們是為了過渡而構建臨時的協作框架，還是直接給這些 AI 分配 Gmail 賬號和 Slack 賬號，讓它們像人類一樣交流？ 我們的財務團隊一直在嘗試辦公軟件的集成。以前我們要在 Claude 周圍構建很多技術讓它在 Google Doc 里留言，而現在它能直接在文檔里評論，這就是你與它互動的方式。我還在思考：最好的交互模式是為 AI 之間構建一套定制的通訊協議，還是直接讓它們使用現成的人類工具？比如給它一個 Slack 賬號，這樣它就天然具備了多人協作能力。

而且讓你兩邊的 AI 協作伙伴都能互相交談。雖然這聽起來可能有點令人不安，但技術上是有可能的。我們之前談過skills轉移，如果你的 AI 直接詢問其他 AI 是否有處理這個任務的skills，那將非常強大。我們可以利用低功耗藍牙技術，讓電腦感知彼此的物理距離，從而判斷大家是否在處理同一件事。

（關于 Anthropic Labs）其實團隊成員的流動性很大。實驗室團隊主要研究那些尚未公開、非常前衛甚至看起來不太可能實現的想法，這就是所謂的瘋狂科學。Claude Code 現在已經是一個相當大的團隊了。但我們依然保留了一個獨立的實驗室團隊，而且規模更大了。他們研究的東西極其超前，甚至很多是半成品。實驗室的宗旨就是：只研究那些對普通團隊來說完全沒意義、但極具破壞性的想法。大家快去嘗試協作模式吧，這是我今年感受到的最接近 AGI 的體驗。

| 文章來源：數字開物

【AI技術與應用交流群｜僅限受邀加入】

AI算力領域TOP級從業者專屬圈層

√ 與頭部算力企業深度對話

√ 與AI上下游企業深度對話

√ 獲取一手全球AI與算力產業信息

√ 獲取AI熱點及前沿產業獨家信息

√ 隨時了解全球AI領域高管最新觀點及實錄全文

√ 有機會參與AI主題產業交流活動

掃碼驗證身份（需備注姓名/公司/職務

不止有 DeepSeek，更有 AI產業的未來！

? END ?

【專欄】精品再讀