全靠Claude Code 10天趕工上線，Cowork 刪用戶11G文件不含糊！核心研發(fā)：長時間打磨再發(fā)布很難成功

整理 | 褚杏娟

Anthropic 發(fā)布 Claude Cowork 研究預覽版沒多久，就被曝出了刪用戶文件、竊取文件等問題。

近日，博主 James McAulay 在測試 Cowork 功能中，選擇“整理文件夾”這一基礎且高頻的場景，同時還與 Claude Code 進行對比。當 James 正在對比兩款工具的整理進度時，Claude Cowork 突然觸發(fā)了致命錯誤：在整理過程中擅自刪除了約 11GB 文件。

更令人崩潰的是，這些文件并未進入回收站，而是被執(zhí)行了“rm -rf”不可逆刪除命令。James 緊急讓 Claude Cowork 導出操作日志，確認該命令的執(zhí)行記錄后，咨詢 Claude Code 能否恢復，得到的卻是“無法恢復，屬于致命操作”的回復。

事后復盤發(fā)現(xiàn)，James 在 Claude Cowork 詢問文件操作權限時，點擊了“全部允許”或“始終允許”，但沒有預料到它會無視明確的“保留文件”指令，更沒想到會執(zhí)行不可逆刪除操作。萬幸的是，此次被刪除的均為過往上傳記錄，并非核心重要文件，未造成嚴重損失，但這一安全隱患足以讓用戶對其望而卻步。

James 還指出，Cowork 與 Claude Code 相比，存在兩點不足：

首先是交互的繁瑣性。發(fā)出“整理文件夾”的指令后，Claude Cowork 并未直接行動，而是要求先啟動新任務并手動選擇目標文件夾；Claude Code 則直接定位文件夾并開始分析，僅需授予一次權限即可推進。Claude Cowork 通過反復交互確認整理細節(jié)，比如詢問“文件按什么維度分類”“用戶數(shù)據(jù)文件夾如何處理”，即便明確回復“用戶數(shù)據(jù)文件夾暫不刪除、保留”，它仍在待辦清單中標記“刪除用戶數(shù)據(jù)文件夾：已完成”，雖后續(xù)未實際執(zhí)行該刪除操作，但也暴露了指令響應的漏洞。

其次是效率的滯后性。整理過程中，Claude Cowork 運行命令多次停頓，節(jié)奏拖沓；而同期用 Claude Code 整理“音樂文件夾”，智能體快速給出“專輯和迷你專輯、單曲、Demo、翻唱”的分類建議，確認后即刻推進整理，全程僅需數(shù)十秒。即便兩者均搭載 Opus 4.5 模型，Claude Cowork 的響應速度和執(zhí)行效率仍明顯落后，甚至讓簡單的文件夾整理變成了“持久戰(zhàn)”。

除此之外，AI 安全公司 PromptArmor 還發(fā)現(xiàn)，由于 Claude 代碼執(zhí)行環(huán)境中存在已知但未解決的隔離缺陷，Claude Cowork 易受通過間接提示注入實施的文件竊取攻擊。

據(jù)悉，這是一個最早由 Johann Rehberger 在 Cowork 尚未出現(xiàn)之前、于 Claude.ai 聊天環(huán)境中發(fā)現(xiàn)的漏洞，已經(jīng)擴展到 Cowork 中。Anthropic 對該漏洞進行了確認，但并未進行修復。

Anthropic 提醒用戶：“Cowork 是一個研究預覽版，由于其 agentic 的特性以及可訪問互聯(lián)網(wǎng)，存在獨特風險。”官方建議用戶警惕“可能表明存在提示注入的可疑行為”。然而，由于該功能面向的是普通大眾而非僅限技術用戶，PromptArmor 表示認同 Simon Willison 的觀點：“要求普通、非程序員用戶去警惕‘可能表明提示注入的可疑行為’，這是不公平的！”

此前，Every 團隊提前獲得權限，Dan Shipper、Kieran Klaassen 直播測試了該產(chǎn)品并分享了使用體驗。期間，Anthropic Claude Cowork 項目核心成員 Felix Rieseberg 參與解讀了產(chǎn)品設計思路。Felix 介紹，Cowork 是一個快速上線、先交給大家看怎么應用的產(chǎn)品，只用了 1.5 周就完成了開發(fā)，F(xiàn)elix 表示未來將以用戶反饋為核心快速迭代。此外，工程師 Boris Cherny 還在 X 上透露，該產(chǎn)品的全部代碼都是由 Claude Code 編寫的。

在直播中，F(xiàn)elix 表示，產(chǎn)品工作流可拆分為 “非確定性（依賴模型智能）” 和 “穩(wěn)定可重復（編寫工具）” 兩類，按需取舍。Skills 是平衡 “模型靈活性” 與 “工作流穩(wěn)定性” 的關鍵，能沉淀可復用知識，還能催生涌現(xiàn)能力。

他認為，未來 Agent 類應用界面會趨簡，用統(tǒng)一的 “泛化入口” 覆蓋更多場景，而非專用化輸入框堆砌。下面是三人對話部分內容，我們進行了翻譯，并且在不改變原意基礎上進行了刪減，以饗讀者。

一周半沖刺、先上線再說

Felix：這是我們團隊做的產(chǎn)品。我們在最近大概一周半的時間里全力沖刺，把它做出來了。

Dan：一周半？

Felix：對，不過我想澄清一下：其實很多人早就有一個共識：如果能有一個“給非程序員用的 Claude Code”，那一定會非常有幫助、也很有價值。我們真正想做的，是幫助人把事情做完，不管是生活里還是公司工作中。

在這之前，我們其實已經(jīng)做過好幾個原型，尤其是在圣誕節(jié)前。但假期期間我們觀察到一件事，我相信很多人也注意到了：越來越多的人開始用 Claude Code 做幾乎所有事情，某種程度上，大家是在用它“自動化自己的人生”。

于是我們就在想：有沒有一個足夠小、足夠早期的形態(tài)，可以先做出來給大家用，然后和用戶一起快速迭代，真正搞清楚什么樣的用戶體驗才是對的、我們到底應該構建什么。

現(xiàn)在你們看到的這個就是答案。它是一個 research preview，非常早期的 alpha 版本，有很多不完善的地方、很多毛糙的邊角，你們已經(jīng)看到不少了，這些我們都會很快改進。但這就是我們的嘗試：在開放狀態(tài)下構建產(chǎn)品，和外部的人一起打磨。

Dan：我太喜歡這種方式了，能不能講講你們做的一些設計決策？

Felix：這是個很好的問題。我個人有一個判斷：不只是 Anthropic，而是整個 Agent 類應用的用戶界面，在接下來一兩年里都會發(fā)生非常大的變化。

現(xiàn)在我們看到的，是為不同任務設計的高度專用化輸入框，以及圍繞特定任務搭出來的一整套腳手架。但隨著模型能力不斷提升、整個行業(yè)對“泛化問題”的理解逐漸加深，我認為未來我們會用更少的界面，覆蓋更廣的使用場景。

但在當下，我們之所以把 Cowork 單獨拆出來，是因為我們想非常透明地告訴用戶：這是一個“施工中的區(qū)域”。某種意義上，我們是在邀請你走進我們的廚房。我們希望能和用戶一起工作，幾乎每天都上線新功能、修 bug、嘗試新想法。所以這個獨立的 Tab 本身就是實驗性的，可以說是在前沿、甚至是“流血邊緣”。它節(jié)奏更快、打磨得沒那么精致，這也是我們把它單獨拎出來的主要原因之一。

當然，也有一些技術層面的原因。比如現(xiàn)在這個 Cowork 是運行在你本地電腦上的，所以里面的對話是本地的，不會在多設備之間同步。同時，我們給了 Claude 更激進的一些 Agent 能力。綜合這些因素，才決定做成現(xiàn)在這個形態(tài)。

Dan：同一個應用里，一邊是云端的聊天，一邊卻是在自己電腦上跑的 Agent。怎么讓用戶真正理解“這兩者不一樣”？

Felix：是的，我心里有一個夢想，我相信很多人也有同樣的想法：最終這些其實都不重要，代碼到底跑在什么地方，應該只是一個技術實現(xiàn)細節(jié)。對用戶來說，它應該就跟你訪問紐約時報網(wǎng)站時會不會用 WebSocket 一樣，誰會在乎呢？

對我們來說，現(xiàn)階段這樣做的好處是，可以跑得更快、發(fā)布得更快，也能和真正使用這個產(chǎn)品的人更近距離地一起共創(chuàng)。我一直很堅定地認為，一個人關起門來是很難做出好產(chǎn)品的。那種“躲進山洞里干一年，最后拿出來”的方式，其實很難成功。

我也經(jīng)常提醒大家：就連第一代 iPhone，都缺了很多我們現(xiàn)在覺得是“理所當然”的功能。所以，這確實是一個不小的門檻，但我們暫時可以接受，因為我們希望現(xiàn)在選擇用這個產(chǎn)品的人，本身就是帶著明確意圖來的。

Dan：我覺得這是一個非常有意思的模式，先極快地把東西做出來，以一個“新入口”的形式放在應用里，讓相對更少的人點進來。這樣就能在真實世界里快速迭代，而不是一開始就追求完美。尤其是在你剛才說一周半就能做出一個版本，簡直瘋狂。

“現(xiàn)在的狀態(tài)是，先看看大家怎么用”

Kieran：但在你們腦海里，這個產(chǎn)品“真正的形態(tài)”是什么樣的？你們接下來想往哪里走？

Felix：我太喜歡這個問題了，因為說實話，我也想反過來問你們兩個同樣的問題：你們希望它變成什么？你們想用它做什么？我已經(jīng)聽你們提到過，比如想讓它能訪問整臺電腦，還有多選交互是不是可以更靈活一些之類的。

但我現(xiàn)在更多的狀態(tài)是，先看看大家怎么用，然后瘋狂嘗試各種可能性。里面肯定有很多是錯的，也會有一些是對的。對我來說，真正有意思的不是我個人的愿景，而是用戶真正想拿它干什么。

我過去做過的產(chǎn)品幾乎都是這樣：你心里以為用戶會這么用，結果他們找到了完全不同的用法，然后你順著那個方向繼續(xù)做下去。所以我特別希望我們能搞清楚：人們現(xiàn)在到底想要什么、喜歡什么、不喜歡什么。肯定也會有人明確說不喜歡某些地方，那我們就根據(jù)這些反饋不斷調整、迭代。

Kieran：這又回到一個老問題了。比如 Boris 就非常擅長把 Claude Code 做成一種讓用戶在使用過程中逐漸發(fā)現(xiàn)“自己到底想要什么”的工具。那你們在 Cowork 里有沒有類似的策略？比如給我們一些“積木式”的東西？能不能加自己的插件或 Skills？Claude Code 很酷的一個地方在于它特別好 hack、特別可塑，你們面向非程序員的 Cowork 是不是也有類似理念？

Felix：對，非常強調可組合性。你剛才提到 Boris 推動 Claude Code 早發(fā)布、快迭代、看用戶怎么用，其實特別巧，我們之所以能這么快上線，很大程度上也是 Boris 在推動我說，“你應該早點給大家看看，看他們會怎么用”。（注：Boris Cherny 是 Claude Code 核心創(chuàng)作者）

至于可組合這一點，過去幾周、甚至最近兩個月里，我自己感受最深的，是我越來越依賴 Skills。以前我可能會去寫 MCP 工具，或者為 Claude 專門做一套很定制化的東西，現(xiàn)在我更多是直接寫 Skills。

有時候我還是會寫一個二進制程序，但我隨后就會在一個 Skill 文件里用 Markdown 描述：Claude，如果你要做這件事，請遵循這些規(guī)則。

舉個例子，我最近在給自己做一個馬拉松訓練計劃。我寫了一個小程序，從不同平臺抓取我的運動數(shù)據(jù)；然后在一個 Skill 里寫清楚：如果你要幫我做訓練計劃，請按這些原則來。現(xiàn)在，只要你在 Claude AI 里裝過的 Skill，都會自動加載到 Cowork 里。而且我覺得這只會越來越重要，尤其是模型越來越聰明，比如 Opus 4.5 版本，對 Skills 的遵循能力真的非常強。

所以目前來說，Skills 大概是我們最主要、也最“可 hack”的入口。

統(tǒng)一的“泛化入口”趨勢

Dan：太棒了。你剛才提到未來會有更少的 UI 形態(tài)。這是不是也意味著，圍繞“聊天是不是 AI 的最終形態(tài)”這個爭論，你其實是在押注自然語言會長期存在？也就是說，我們最終不會有越來越多復雜的 UI，而是更少的界面，人只需要和一個 Agent，或者一個能調度其他 Agent 的 Agent 對話？你們現(xiàn)在推動的方向，某種程度上是不是就類似今天 Claude Code 所展現(xiàn)出來的那種形態(tài)？

Felix：是的，這個問題現(xiàn)在仍然存在很大的爭論空間，而且肯定不存在什么“Anthropic 官方立場”。老實說，就算是在我這個并不算大的團隊里，大家也未必能在整體上達成一致。每個人對于未來人類將如何與 AI、與模型交互，都有非常不同的想象。

如果只從我個人的角度來說，我大概堅信兩件事。第一是：聊天式輸入及其各種變體——不僅僅是模型意義上的聊天，而是更廣義的那種“我想要點什么”的輸入框——會比我們想象中存在得更久。

如果你把它抽象開來看，不管是 Google 首頁，還是 Chrome 的地址欄，本質上都是一個“我想要某樣東西”的輸入框，我認為這種形態(tài)會長期存在，我們會繼續(xù)擁有某種看起來很像搜索框的入口。

問題是，我們到底需要多少個這樣的輸入框？你會有一個專門寫代碼的框嗎？一個用于個人娛樂的、一個處理醫(yī)療相關問題的？我并不確定未來會存在這么多彼此割裂的輸入框。

我再拿 Google 做類比。過去你可能記得，Google 會為不同需求提供不同的搜索入口和子產(chǎn)品。但現(xiàn)在，越來越多時候，你只是直接在 Chrome 的地址欄里輸入你想要的東西。你不會真的先想清楚“我現(xiàn)在是在購物模式”，然后再專門去打開 Google Shopping。

所以，如果我們未來看不到一種更聰明的、能理解你想做什么的“泛化入口”，我會很意外。當然，后端可能仍然會分流，比如它理解你想要做的是 X，于是給你呈現(xiàn)一個適合 X 的界面，但入口本身很可能是統(tǒng)一的。

產(chǎn)品設計中的取舍

Dan：我覺得一個很有意思的反例是 Microsoft Excel。某種程度上，它和 AI 的工作方式其實也很像：這是一個通用型產(chǎn)品，上手極其簡單，但你可以在里面把事情做到無限復雜。而且，Excel 甚至某種程度上催生了后來的 B2B SaaS 浪潮，很多 SaaS 本質上就是把 Excel 里的復雜工作流“產(chǎn)品化”了。所以也有另一種可能：你先有一個極其通用的工具，然后人們在里面發(fā)現(xiàn)了高價值、高強度的工作流，最后這些工作流再被拆分成獨立產(chǎn)品。

Felix：我覺得 Excel 真的是一個極其漂亮的例子。對很多開發(fā)者來說，Excel 其實處在一個有點“邊緣化”的位置，但如果你比較一下 Excel 的日活用戶數(shù)量和全球開發(fā)者的數(shù)量，那是一個非常驚人的對比。

我在 Excel 身上看到的一個很有意思的點是：它的重度用戶，其實并不太在意那種“邊際效率提升”，或者 UI 上一點點的小優(yōu)化。他們更在意的是對這個產(chǎn)品的深度熟悉和肌肉記憶。

這里面是有教訓的。我在很多產(chǎn)品表面上都見過這種情況：作為開發(fā)者，你會覺得“如果我單獨給你做一個更貼合這個場景的小工具，你的工作流會更好”。但結果往往是，用戶并不會去用那個新工具，而是繼續(xù)在他們已經(jīng)非常熟悉的產(chǎn)品里，把事情做完。

舉個例子，這是我在 Slack 工作多年反復學到的一課：你可以做很多你自認為更適合某個使用場景的獨立服務，但用戶最后往往還是選擇就在聊天里完成這件事。

Dan：說到這里，雖然今天的主題更偏向非開發(fā)者，但我感覺現(xiàn)在有不少開發(fā)者在看。你正好是那種“真的把這個東西做出來了”的人，對 Agent native 應用的構建理解非常深。

我們一直在思考 Agent-native 應用的核心原則。比如其中一個原則是“對等性（parity）”：用戶通過 UI 能做的事情，agent 也應該能做。我在 Cowork 里已經(jīng)能看到這一點。另一個是“粒度（granularity）”：工具應該盡量處在比功能更底層的層級，而“功能”更多存在于 prompt 或 Skill 中，這樣你就能以開發(fā)者沒預料到的方式去組合工具。這會自然帶來第三個原則“可組合性（composability）”，而可組合性最終會產(chǎn)生第四個：涌現(xiàn)能力（emergent capability）。也就是用戶開始用它做你完全沒想到的事情，你看到了潛在需求，然后再圍繞它構建產(chǎn)品。

這在我看來，幾乎就是 Claude Code 的工作方式。我很好奇，這一套在你聽來是否成立？或者從你們在 Anthropic 大規(guī)模落地的經(jīng)驗來看，有沒有什么能讓大家把 Agent native 應用做得更好的建議？

Felix：這套說法對我來說非常有共鳴。而且我覺得，“涌現(xiàn)能力”里隱藏著一個非常重要的事實：無論是個人還是在孤立的小團隊里，我們幾乎不可能提前預測一個 Agent 最終會在哪些地方變得極其有用，尤其是當你只給了它一些相對原始的工具時。

把工具盡可能下沉、做成通用形態(tài)，是一件非常強大的事情。工具越可組合、越通用，你就越能從模型智能的持續(xù)提升中獲益。我和很多開發(fā)者聊過一個感受：模型智能提升、以及模型“正確調用工具”的能力，增長速度往往遠快于你新增工具、或者教育用戶理解這些工具的速度。

所以如果你退一步思考：“我能不能先做一個高度通用的工具？”那你構建出一個可以適應未來新場景的產(chǎn)品的概率，其實會大得多。這一點，我非常認同。

Dan：那在這些原則之下，你怎么看其中的取舍？比如工具設計本身的權衡問題。

Kieran：對，我覺得把東西放進 prompt 里、再配合工具，本身是很棒的。但問題在于，我們現(xiàn)在突然需要去創(chuàng)建一些“能讀取 Skills 的工具”，或者類似的東西。于是就出現(xiàn)了一個新的“元層”。Skills 本質上就像是一種即時的 prompt 注入，但你得先把這個體系搭出來。現(xiàn)在所有在做這些東西的人，如果不是直接用 Claude Code 或 Cloud SDK，那基本都得自己從頭構建一整套。

于是就出現(xiàn)了一種拉扯：你到底是把行為直接描述在一個 tool 里？還是再包一層 tool，讓它去調用別的東西？這中間是有摩擦成本的。當然，可組合性是很好的。比如一開始你可能會有五個 tool：搜索郵件、讀取郵件、做這個、做那個。但你也可以說：不，我只提供一個 execute tool，然后用 Skills、MCP，或者某種抽象層來完成這些事情。現(xiàn)在正處在這樣一個轉變期，而 Claude Code 和 Claude SDK 顯然是在推動這個方向。

但我確實能感受到這種摩擦。我猜你也一定感受到了。所以我很好奇：你有沒有什么最佳實踐，能給那些還停留在“傳統(tǒng) AI 應用思維”的人一些建議？

Felix：我不確定我能給出什么“來自山頂?shù)闹腔邸保瑫饶阋呀?jīng)擁有的經(jīng)驗更有價值。但你說的那點，確實非常戳中我。我覺得你必須做一個取舍：哪些輸出你愿意讓它是非確定性的、哪些地方你愿意依賴模型的智能。而且一旦你依賴模型智能，每當你換一個更便宜、或者“更笨”的模型，那些地方的質量就會下降。

所以我會把整個工作流拆成兩類：一類是非確定性的；一類是可重復、穩(wěn)定的。如果某個部分非常可重復，而且你可以非常確信它“永遠不會變”，而且就算模型變聰明了，你也得不到任何額外收益，那我會覺得，這正是寫一個工具的好地方。

其實我們已經(jīng)在這么做了。你完全可以給 Claude 一個極其通用的“匯編級”工具，比如：“直接調用 GCC，你想怎么編就怎么編。”但我們并沒有這么做，因為那樣就太瘋狂了。

Skills 與可組合性實踐

Dan：那已經(jīng)是粒度的極限了。

Kieran：不過我也想說一句：當我和很多開發(fā)者聊的時候，我發(fā)現(xiàn)即便這個“是否要給模型工具”的基本假設，也正在被挑戰(zhàn)。我不會把太多賭注壓在這個假設上。比如，我們到底是不是還需要給 Claude 工具？還是說，某一天它只需要靠記憶和權重，直接把 0 和 1 寫到世界里？這是一個非常有意思、也非常難判斷的問題，沒人真的知道答案。

但你們已經(jīng)在實踐中學到了一些東西。你們之所以創(chuàng)造了 Skills，就是因為僅靠 Slash command 或子 Agent 已經(jīng)不夠了，對吧？我們需要 Claude.md 更強，但現(xiàn)實是 Skills 正是為了解決這個問題而誕生的，而且顯然它們效果很好。我完全認同你說的，Skills 太棒了。我現(xiàn)在幾乎每天都在寫 Skills，而且真的很愛用。所以這里面一定有些什么。但問題是：什么時候應該用 Skill？什么時候又不該？

Felix：這真的是一場特別有意思的對話。有一個你以后真的應該跟 Barry 聊聊。在公司內部，至少在某種程度上，Skills 這個概念就是他提出來的。從根本上說，Skills 正是你剛才描述的那種張力的自然產(chǎn)物。

舉個例子，我們想讓公司內部的人能很容易地拿到各種儀表盤。我們用的是一家主流數(shù)據(jù)服務商，很多數(shù)據(jù)都在那兒。一開始我們在想：要不要做一堆非常具體的工具，專門去拉數(shù)據(jù)、壓縮成固定格式。最早那幾版儀表盤，其實效果并不理想（那還是 4.5 之前）。大概每三四個里面，就有一個看起來很拉胯。于是，我們開始想：要不要把參數(shù)卡死，直接做一個“固定模板”的儀表盤？Claude 只負責往里面填新數(shù)據(jù)。

但在這個過程中，我們突然發(fā)現(xiàn)了一件事：如果你只是告訴 Claude 如何正確地查詢這個數(shù)據(jù)源、可以使用 SQL、以及生成儀表盤時需要遵循哪些設計原則，突然間，它就能穩(wěn)定地產(chǎn)出質量很高的結果，而且是“幾乎每一次”都很好。

更重要的是，這就打開了“涌現(xiàn)能力”的大門。因為你還可以對 Claude 說：“我知道你在遵循這些儀表盤原則，但我想換一種圖表類型”，或者“我想把它和另一份數(shù)據(jù)結合起來。”就在這一刻，事情真正開始變得有趣了。

Dan：這真的很有意思。我覺得為什么要用 Skill，而不是只給它 GCC、讓一切都即興發(fā)生，其中一個關鍵原因在于：你需要把一些可重復的、可分享的知識，變成一個大家都能討論、都能復用的東西。并不是所有事情都應該是“即時生成”的。有些事情，你就是希望一個團隊能長期、反復地用同一種方式來做。而這，本質上就是 Skill。

Felix：而且這其實也很符合人類本身的工作方式，對吧？比如我剛加入一家公司時，總有人教我怎么訂機票、怎么訂會議室。從某種意義上說，我們每個人，都是靠著一堆 markdown 文件在工作。

我覺得差不多該下線了，但在走之前，我想讓你們兩個各自給我一個建議：你們最希望我們改的一件事是什么？

Dan：那我先來一個最簡單的：給我對整臺電腦的完全訪問權限。還有就是，讓我更清楚地知道它現(xiàn)在到底是在我本地電腦上運行，還是在云端以聊天的形式運行；以及，讓它在手機上用起來更順暢。

Kieran：我也支持移動端。但我最想要的是能讓我添加自己的插件。我有一個插件市場，我只想把它接進來直接用。現(xiàn)在我得在一個應用里加東西，再拷貝到這里，有點繞。可能也能湊合用，但如果能原生支持插件市場、直接添加插件，那真的會非常棒。

Felix：好，明白了。謝謝你們，這些反饋都非常有價值。我們會把這些帶回去，跟團隊一起討論。也歡迎大家把想法發(fā)給我們。我們真的很希望聽到大家的反饋，并據(jù)此調整路線圖。

測試總結：理念可以，做得一般

最后，我們總結了 Every 團隊的測評結果。

Claude Cowork 的核心定位是為非技術用戶提供 Claude Code 級別的 AI 協(xié)作能力，其最顯著的突破在于重構了 AI 使用邏輯，從傳統(tǒng)“發(fā)提示詞→等回復”的一問一答模式，升級為“異步協(xié)作”模式。

與普通 Claude 聊天相比，Claude Cowork 專為“長時間工作”設計，具備持續(xù)推進任務直至完成的能力。直播中展示的典型案例包括：審計過去一個月的日歷并分析與目標的匹配度、抓取 PostHog 數(shù)據(jù)統(tǒng)計按鈕點擊量、分析 Every 咨詢業(yè)務的競品、整理下載文件夾、校對 Google Docs 文案等。這些任務均需 AI 持續(xù)“瀏覽”、推理，部分任務耗時可達一小時左右，遠超普通 AI 聊天的響應速度。

產(chǎn)品的場景適配性極強，尤其適合需要深度研究和數(shù)據(jù)處理的崗位。用戶只需連接 Chrome 瀏覽器，AI 即可直接使用用戶已登錄的各類服務，無需重復認證，輕松完成 Twitter 時間線熱點分析、競品信息搜集等需多平臺聯(lián)動的任務。同時，它支持生成文檔、Excel、PPT、PDF 等多種產(chǎn)出物，可應用于簡歷優(yōu)化、會議發(fā)言起草等日常工作場景，大幅提升增長團隊、咨詢人員、寫作者等群體的工作效率。

在交互設計上，產(chǎn)品右側設置了待辦任務列表，清晰展示任務進度與當前階段，用戶可直觀掌握 AI 工作狀態(tài)。其“詢問用戶”功能還配備了可視化交互界面，支持多選項快速響應，進一步降低了操作門檻。

根據(jù)測評，Cowork 具備較強的可擴展性，支持加載用戶已安裝的 Claude Skills，這也是其最具“可玩度”和“可定制性”的核心入口。用戶可通過 Skills 封裝專業(yè)知識與操作邏輯，實現(xiàn)個性化需求。

測評團隊也指出了產(chǎn)品當前存在的爭議與不足。

最核心的爭議在于“單獨設置 Cowork 標簽頁”的設計：部分用戶認為應在同一標簽頁內根據(jù)任務自動切換模式，避免額外的選擇成本；但也有觀點認為，獨立標簽頁能明確提醒用戶切換使用心態(tài)：從“實時對話”轉向“異步托付”，尤其對非技術用戶而言，這種明確的區(qū)分有助于適應全新的協(xié)作范式。

另外在體驗細節(jié)上，產(chǎn)品仍有諸多優(yōu)化空間：一是 UI 打磨不足，任務列表僅按時間排序，缺乏視覺區(qū)分度，部分內容存在“懶加載”導致展示不及時；二是權限管理不夠直觀，普通用戶難以清晰判斷 AI 是在本地還是云端運行，文件夾訪問權限需手動配置易造成困惑；三是“詢問用戶”功能存在邏輯缺陷，可能在用戶未響應時自動跳過問題，且選項數(shù)量和字符數(shù)存在限制；四是對復雜應用（如 Google Docs）的適配尚不完善，相關操作容易失敗。

針對不同用戶，測評團隊給出了針對性使用建議：非技術用戶可將其視為“升級版聊天功能”，用日常任務直接嘗試，逐步適應異步協(xié)作模式；重度用戶可嘗試通過 Skills 定制個性化功能，探索組合使用的可能性。他們表示，所有用戶均需保持好奇心，忽略“三個月前 AI 做不到”的固有認知，在每一次產(chǎn)品更新后重新嘗試核心需求，畢竟 AI 能力每隔幾個月就會發(fā)生巨大迭代。

最終，測評團隊給出的評分結論為：“理念綠牌，當前執(zhí)行黃牌”。理念層面，產(chǎn)品開創(chuàng)性地將 Claude Code 級別的異步協(xié)作能力開放給非技術用戶，推動了 AI 協(xié)作范式的轉變，具備極高的探索價值；執(zhí)行層面，因 UI 粗糙、部分功能邏輯不完善等問題，當前體驗仍有較大優(yōu)化空間。

https://www.youtube.com/watch?v=_6C9nMvQsGU

https://www.youtube.com/watch?v=oPBN-QIfLaY

https://www.promptarmor.com/resources/claude-cowork-exfiltrates-files

會議推薦

InfoQ 2026 全年會議規(guī)劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產(chǎn)業(yè)落地，從技術前沿到行業(yè)應用，全面覆蓋 AI 與軟件開發(fā)核心賽道！集結全球技術先鋒，拆解真實生產(chǎn)案例、深挖技術與產(chǎn)業(yè)落地痛點，探索前沿領域、聚焦產(chǎn)業(yè)賦能，獲取實戰(zhàn)落地方案與前瞻產(chǎn)業(yè)洞察，高效實現(xiàn)技術價值轉化。把握行業(yè)變革關鍵節(jié)點，搶占 2026 智能升級發(fā)展先機！