「垃圾進，珍寶出」：Anthropic 首席設計師談 Cowork 的產品哲學與 10 天上線的真相

整理 & 編譯：深潮TechFlow

嘉賓：Jenny Wen，Cowork 設計負責人

主持人：Peter Yang

播客來源：Peter Yang

原標題：Claude Cowork Tutorial from Cowork s Design Lead (40 Min) | Jenny Wen

播出日期：2026年3月29日

重點總結

Jenny 是 Cowork 的設計負責人。 她帶我深入了解了 Anthropic 的內部運作，包括她如何使用 Cowork 設計和開發產品，以及 Cowork 誕生背後的真實故事。 Anthropic 幾乎每天都在推出新功能，看到他們的工作方式讓我感到非常震撼。

精彩觀點摘要

• 我花時間做的大部分事情，就是把產品推出去。 不過我覺得這可能和一兩年前看起來不太一樣了，其中很大一部分，其實就是和工程師、產品人員之類的以一種不太正式的方式一起 jam （即興協作）。 通常是大家一起看一個原型，然後指出並思考它可以如何演進。

• 我覺得 Cowork 最讓我感到驚豔的一點，就是它在信息整理上的能力。 我喜歡稱它為「垃圾進、珍寶出」。 它能夠從各種不同的來源中收集信息，然後快速找到其中的關鍵點，提煉出有價值的內容，並將其轉化為具有實際生產力的成果。

• 除了非常細緻的生產代碼工作 (production code) 之外，我現在幾乎所有的事情都用 Cowork 來完成。 如果是需要專注於某些程式碼細節的場景，我還是會用 Claude Code。 但對於日常的溝通和協作，我現在完全依賴 Cowork。

• 那句「他們 10 天就做出來了」的說法，其實是從某次訪談或媒體報道中被截取出來的。 但真實的情況是，關於 Cowork 這個方向，我們其實從我一年前加入 Anthropic 時就已經開始構思了，我們一直在思考如何打造一種能夠幫助所有通用知識工作者的「思維夥伴」 (thinking partner)。
• 雖然 Claude Code 已經能夠很好地處理程式碼相關的任務，但我們的目標是涵蓋所有知識工作場景。 我覺得真正的挑戰在於：我們該如何執行這個想法？ 什麼樣的架構才是最適合的？ 什麼樣的使用者體驗 (UX) 才是正確的？

• 我還是會做 Figma。 但我們現在不常做規格文件了，而且通常也沒那麼詳細。 我們仍然會做優先排序，它還是作為一個文件存在，但通常只是幾個 bullet points，不是那種過度設計的漂亮表格。

• 我們所處的技術領域變化極快，新的模型不斷湧現，更新速度也越來越快。 因此，對我們來說，制定一年的願景都不太現實，更不用說兩到五年的願景了，因為有太多未知因素。

• 如果你覺得腳下的地面在移動，那是因為它確實在變化。 我們必須承認這一點，並學會適應，同時也要以開放的心態重新審視我們現有的工作方式。
• 每當我覺得自己的職業受到挑戰時，但這種時候，我會想到我的工程師同事們。 他們的工作早就經歷了巨大的變革，但他們不僅適應了這些變化，還以極大的勇氣和謙遜迎接挑戰，最終實現了更有效率、更出色的工作成果。 他們是我的靈感來源──我會告訴自己，如果這些我非常尊敬的同事可以做到，我也一定可以。 他們是我適應改變的榜樣。

開場

我不知道是不是有典型的典型一天，但我花時間做的大部分事情，就是把產品推出去。 不過我覺得這可能和一兩年前看起來不太一樣了，其中很大一部分，其實就是和工程師、產品人員之類的以一種不太正式的方式一起 jam （即興協作）。 通常是大家一起看一個原型，然後指出並思考它可以如何演進。 有時候只是討論功能的表現，有時候是我自己去實現一些東西。 我覺得仍然有很大一部分時間是我自己在設計、做原型之類的，但現在設計工作的方式感覺很鬆散。

其實它們往往甚至不是原型，而是已經在我們內部建構和 Claude 或 Cowork 實例中運行的工作原型。 我通常會花時間使用這個功能、推動這個功能、看看它的能力、形成意見，而下一步迭代通常就是我坐下來和工程師說： 嘿，我是這麼想的。 這些是我覺得應該改的地方。 我覺得還是有時間讓我覺得在設計工具裡迭代、打磨和精煉仍然非常非常重要。 所以那部分並沒有消失。 只是因為我同時在處理更多項目，所以感覺更有效的方式就是非常隨意、非常非正式地去做。

我還是會做 Figma。 但我們現在不常做規格文件了，而且通常也沒那麼詳細。 是的。 我們依然會做優先排序，它還是作為一個文檔存在。 其實這對我們交給安全或法務團隊很有幫助，這樣他們能了解發佈內容是什麼，但通常就只是幾個 bullet points。 不是那種過度設計的漂亮表格。 我覺得我們的 Figma 檔案也是一樣。

Cowork 實操示範

當然可以。 我來講講我是如何使用 Cowork 的。 其實我有一個小秘密，除了非常細緻的生產代碼工作 (production code) 之外，我現在幾乎所有的事情都用 Cowork 來完成。 如果是需要專注於某些程式碼細節的場景，我還是會用 Claude Code。 但對於日常的溝通和協作，我現在完全依賴 Cowork。

我覺得 Cowork 最讓我感到驚豔的一點，就是它在資訊整理上的能力。 我喜歡稱它為「垃圾進、珍寶出」。 它能夠從各種不同的來源中收集信息，然後快速找到其中的關鍵點，提煉出有價值的內容，並將其轉化為具有實際生產力的成果。

舉個例子，現在我連接了一個資料夾，裡面存放著一些使用者訪談記錄。 我們 Cowork 團隊非常注重與使用者的緊密聯繫，這也是我們一定成功的關鍵之一。 我們透過傳統的使用者體驗研究 (UXR)，直接與使用者對話，同時也透過內部自用的方式，例如我們有一個專門用來收集回饋的 Slack 頻道。 此外，我們也會關注社群媒體上的討論，並傾聽那些熱情用戶的意見。 正是因為我們始終保持與使用者的緊密聯繫，並且能夠快速迭代產品，我們才能不斷改進並取得今天的成果。

所以我現在要做的就是，我會告訴 Claude：嘿，我有這個訪談資料夾，但我也會讓 Claude 去社群媒體、Reddit 和其他 Cowork 的顧客評價裡看看，告訴我最大的洞見是什麼。 它可能需要一點時間，因為它真的要處理這麼多數據並進行加工。 但它會做一些事情，例如有時會派生出子代理並行處理，還會花時間在網路上搜尋。

其實我們現在就可以透過 Cowork 直接做出來，我覺得我們的研究人員有一個會發出來的，我們還有一個會在 Slack 裡 ping 我們的版本。 我們也會直接聽內部 Slack 頻道，我們非常依賴內部和最強大的用戶來給我們提供那種前沿反饋，因為內部人員真的願意對你誠實，他們往往會把功能推到最遠，而且最容易跟進。

我覺得這也是 Claude Code 成功的重要部分──就是傾聽第一線使用者。 而且這也是我們在 Figma 時大量做的事情，大量內部 dogfooding。 因為特別是涉及互動設計和打磨這些方面時，內部人員真的會去戳那些細節，而外部用戶往往給的反饋更多是 它是否適合他們的用戶流程 ，所以它能提供一種完全不同層級的反饋。

Cowork vs Claude Code 的使用者邊界

我們注意到，Cowork 的整體應用範圍正在逐步擴大，並且開始被用於一些類似於先前 Claude Code 的前沿用戶所嘗試的場景中。 還記得我們剛開始開發 Cowork 的時候，內部銷售團隊是我們主要的資訊來源。 他們當中有幾位是 Claude Code 的深度用戶，利用它來產生潛在客戶名單、編寫電話腳本等。 當我第一次看到這些用例時，我感到非常吃驚，因為當時我什至沒有想到 Claude Code 能夠被用來完成這些任務。 而現在，這些使用者幾乎已經全面轉向了 Cowork，甚至連他們的同事也開始頻繁地使用 Cowork 了。

就是因為現在有一個好看的 UI，所以我認為這就是它真正需要的。 而且還有一部分原因是，它和他們正在做的其他工作離得非常近——他們本來就在用聊天功能，而且從這個桌面應用裡也能繼續用 Claude Code，所以我覺得它比打開命令列更貼合他們現有的工作流程。

從洞裡見到可執行 Artifact 的完整流程

這裡有七個不同的主題，而且每個星期都不一樣，我基本上可以直接告訴它： 幫我創建這個文檔 X ，而且已經自動存在我電腦上的一個文件夾裡。 我還可以同時啟動兩個並行任務。 例如我可以說：這些洞見很棒，但根據這些我應該實際建立哪些產品功能？ 然後我還可以並行做另一件事——根據你剛才幫我做的洞見文檔，把這些內容轉成一份我這週 kickoff 時可以跟團隊分享的演示文稿。

但最終我從這裡就可以開始設計流程了——它會給我各種功能選項。 從那裡我甚至可以讓 Claude 幫我為這些功能創建一些 wireframe。 它可能會給我一大堆不同的選項，我可以把它們帶到 Figma 裡真正去細化，或者帶到 Claude Code 裡，用我們真正的設計系統組件把它們做成真實的東西，然後從那裡開始。

另外我還能做的是，把這兩個都變成定時任務。 所以我大概會讓它幫我把這個任務安排成每個週一早上 10 點自動執行。 這樣我每週一早上 10 點就會帶著這份簡報、帶著三、四個不同的產品想法開始工作，用來 kick off 這一週。 它把從回饋到做出 tangible 東西或團隊能看的 idea 這個迭代周期壓縮得非常緊，幫助我們快速迭代產品，並且快速把它做得更好。

是的。 所以如果你真的想讓我從零開始把這些洞見整理成某種功能優先級，它現在花的時間會比以前長很多。

我也是這麼操作的。 例如你發給我的這個播客筆記，我有一個個人筆記資料夾，裡面有 1:1 會議的內容、隨機的想法之類的，然後我就直接說： 讀一下我的個人筆記，幫我想一下這個播客的發言要點，並幫我想想在這裡我想說什麼。 我當然不會一字不差地照著念，但它真的幫我打開了思路，幫助我進化了我的思考，而不是卡在那裡。

Skills 與個人知識庫

我們內部有幾個 skill 專門用來做文件和幻燈片，因為它能幫助我們保持品牌一致性。 我其實沒有個人 skill 函式庫，大部分時候都是藉用內部已有的 skill，然後用在不同用途。

但其實我發現，現在用 Cowork 的資料夾——我裡面放了所有個人筆記之類的——它透過這些資料夾了解我的方式，但對我來說已經非常有用了。 我反而覺得越來越不需要 memory 和 skills 了，因為它已經有一個關於我的知識庫了。 當然我還是認為 skills 有它的適用場景，但就我目前的用例來說，我個人感覺需求沒那麼大了。

是的，它基本上就是我自己維護的一個 memory，因為我一直在裡面記筆記。

團隊協作節點

我的意思是，像真正的 UXR 訪談這些東西，其實是我不會自己做的——要么是產品經理，要么是團隊裡的研究員，或者團隊裡的其他人會去做。 然後透過這個，你就直接分享 artifact，把他們拉進來，然後這個實際上就能成為團隊運作的依據。

我們團隊至少是相當 bottom-up 而且很民主的，所以我們的運作方式就是，我們把洞見和目標給大家，然後每個人就去做出原型、嘗試東西，想法來自四面八方。 它不是作為設計師我來想出所有方案，而是 “嘿，這裡有洞見。這是我們這個月要努力達成的目標，我們大家怎麼一起達到？ ”

以及我們去管理和決定真正要建構和做什麼的能力。

至於設計，Claude 的一個功能是，它能夠產生類似線框圖 (wireframe) 的草圖，並給出多種設計選項。 身為設計師，我非常喜歡這種方式。 即使這些草圖的精細度不是很高，但它們能讓我直觀地看到不同的可能性，而不必完全依賴自己的想像。 這種方式能幫助我更快決定接下來的設計方向。

所以，我認為讓 Claude 來直接產生這些初步的選項，可以省去我手動製作草圖的時間和精力。 從這些選項中，我會選擇一個方向，開始進行小範圍的迭代。 接下來，我可能會用程式碼將這個方向製作成一個初步的原型，然後在這個基礎上繼續優化和完善設計。

Cowork 誕生的真實故事

那句「他們 10 天就做出來了」的說法，其實是從某次訪談或媒體報道中被截取出來的，大家就一直圍繞這個點討論。 但真實的情況是，關於 Cowork 這個方向，我們其實從我一年前加入 Anthropic 時就已經開始構思了，雖然 Claude Code 已經能夠很好地處理程式碼相關的任務，但我們的目標是涵蓋所有知識工作場景。 我覺得真正的挑戰在於：

在過去一年裡，我們嘗試了許多不同的原型設計，其中有些想法甚至比現在的目標更宏大。 我們也進行了許多技術實驗，測試了各種 AI 智能體框架，但其中一些嘗試並沒有成功。 最終，我們才逐步確定了現在的方向。 我們不僅參考了實驗室團隊開發的原型，也研究了我們產品團隊自己建構的原型。 最終，時機和執行力成為了關鍵，就像閃電正好擊中了目標一樣。

當我們決定要發布這個產品時，整個過程非常迅速——從“我們該發布了”到“產品已經上線”，只用了 10 天。 這主要是因為我們在 Claude Code 假期期間看到了它的潛力。 在假期裡，很多人終於有時間去試用 Claude Code，甚至一些非技術用戶也開始使用它，例如用它解析播客的轉錄稿，或者進行複雜的數據分析等。 我們發現 Claude Code 的智能體框架 在非技術用戶中也開始展現出早期的產品市場契合度。 其實當時我們內部已經有一個可以工作的原型，原本計劃稍晚一些再發布，但這些反饋讓我們意識到「現在就是最佳時機」。 於是，我們決定把握這個機會，最終有了那瘋狂的 10 天。

沒錯，大致就是這樣的，我們本來計劃再過幾週才上線，但當時我們感到「現在就是最佳時機」。 這也促使我們在時間緊迫的情況下，將產品的範圍縮小到一個更現實可行的程度，並投入了全部的精力和資源，最終成功完成了發布。

早期設計迭代：從 workflow 工具到極簡 Chat

當然可以。 我特地整理了一些早期的螢幕截圖，可以展示我們當時的設計想法和迭代過程。

今年早些時候，我們有了一個早期原型，這是我和另一位設計師合作完成的。 當時，我們嘗試讓這個工具更偏向任務導向 (task-oriented) 或工作流程導向 (workflow-oriented)。 因為我們很擔心使用者是否能夠理解，使用 Cowork 這樣的產品，他們是否能夠完成某些具體的任務，或實現一些明確的成果 (outcome)，例如創建一個儀表板 (dashboard)，或整合來自不同來源的資料。 所以，當時我們把使用者介面設計得非常結構化，幾乎像一個工作流程工具——例如「添加這些內容，這是輸入 (inputs)，這是輸出 (outputs)」。 而聊天功能被放到了次要的位置。

這是我們早期的一個設計方向，但後來我們決定改變思路，讓它更簡單，。 我們嘗試透過這種方式引導使用者實現更具體的目標，例如分析或文件生成。 我們也設計了一個功能性的原型－使用者點擊後，可以看到各種選項，每個選項都有按鈕可以調整，例如文件的長度，或選擇文件類型，例如備忘錄或簡報，但這個設計最終讓使用者感覺過於複雜和壓迫。

所以在多次探索和嘗試中，我們一直在努力尋找一個平衡點：我們到底是應該更明確地定義使用場景，還是保持像聊天框一樣的自由形式。

最終，我們幾週前發布的版本就是現在的樣子。 我們曾經嘗試過一種幾乎像是「嚮導模式」 (wizard-like) 的使用者體驗，使用者點擊後會看到提示，例如「建立一個文檔，長度為三到五頁」等等。

當時我們還在介面中加入了許多元素，希望讓它看起來與普通的聊天框有所不同。 但後來發現，這種設計讓介面顯得過於複雜，視覺元素之間的競爭太激烈。 於是，我們決定簡化設計，去掉了大部分不必要的元素。

現在你看到的使用者介面，已經大幅簡化了。 我們移除了繁重的側邊欄 (sidebars)，讓它更接近傳統的聊天框，但在首頁做了一些改動，使它看起來更像是一個由我和 Claude 共同分享的「待辦事項清單」 (to-do list)，而不是一個充滿複雜建議和指導的聊天工具。

也許未來它可以支援多個智能體 (agent)，可以在上面拖曳任務來管理工作流程。

也許未來會有這樣的可能性。 但我想強調的是，UI 設計在大約四、五週前還完全不同，我們一直在不斷學習，探索什麼樣的設計最有效，什麼樣的設計不太奏效，同時努力尋找最好的方式將這項技術呈現給用戶。

Cowork 與 Claude Code 的差異定位

是的。 Cowork 中依然支援使用斜線指令 (slash commands)，但它們並不是主要的互動方式。 我個人覺得，Cowork 至少是個專業人士的工具。 我們觀察到，許多使用者已經以非常高階使用者的方式在使用它，而且社群中已經湧現出一些高階使用者。 這些使用者通常願意花時間學習更複雜的功能，例如自己創建技能 (skills)、與團隊共享，或使用簡寫命令 (shorthand commands)。

不過，我們的目標是讓這些功能成為次要的互動方式，而不是強制性的學習內容。 也就是說

規劃流程與願景

我們的規劃方式每次都有不同。 在我所在的團隊，我們進行的是月度計畫。 我們有一個電子表格，至少在 Cowork 部分，最多列出大約 12 個任務，這些都是我們的最高優先事項 (P0)。 每個任務都有一個直接負責的人 (DRI)，我們每週都會檢查：我們是否仍在正確的軌道上？ 我們也會進行一些季度或半年規劃，通常由一位負責人指出：「我認為我們應該朝這個方向發展，這些是我們需要關注的事項。」但這些規劃並不嚴格到必須執行特定專案。 更多的是為團隊提供一個整體的方向，所以相對比較靈活。

我確實做過，去年我做過一個 North Star 願景 deck。 我認為願景確實有其價值，它們為團隊指明方向，並幫助我們在即將開展的工作中保持清晰。 不過，由於我們所處的技術領域變化極快，新的模型不斷湧現，更新速度也越來越快。 因此，對我們來說，制定一年的願景都不太現實，更不用說兩到五年的願景了，因為有太多未知因素。

所以我現在認為願景的時間跨度最多是三到六個月，並且可以以文件的形式呈現。 我覺得當願景是視覺化的時候，它更有影響力。 這也是設計的巨大價值所在——能夠將各種元素整合在一起，在特定時間內講述一個連貫的故事。 當然，願景也可以是一個原型，而不僅僅是一個靜態的 deck。 它可以幫助我們協調團隊之間的工作，尤其是當我們有五個團隊在處理非常相似或可能衝突的專案時。 設計可以透過策展來幫助這些想法達成一致，並為我們展示一條通往理想使用者體驗的路徑，而不是分散的體驗。

我們確實有評審，但不像我以前在一些公司那樣，每個功能都需要評審，我們的評審主要針對那些較大且優先級較高的項目。 評審的目的不是為了耗費大量時間準備，而是為了提高專案的可見度並獲得回饋。

給設計師的建議：如何在 AI 時代找到位置

如果你覺得腳下的地面在移動，那是因為它確實在變化。 我們必須承認這一點，並學會適應，同時也要以開放的心態重新審視我們現有的工作方式。 我覺得現在的變化對設計師的影響特別大，尤其是因為我們正處於這波浪潮的第二波。 其他一些職業角色已經經歷了類似的轉型，而如今輪到我們了。 同時，我們的設計工具也在不斷進化。

每當我感到自己的職業受到挑戰時，我會感到一絲不安，例如「天哪，我的工作正在發生巨大的變化，人們可能不再像以前那樣看重我的工作了。」但這種時候，我會想到我的工程師同事們。 他們的工作早就經歷了巨大的變革，但他們不僅適應了這些變化，還以極大的勇氣和謙遜迎接挑戰，最終實現了更有效率、更出色的工作成果。 他們是我的靈感來源──我會告訴自己，如果這些我非常尊敬的同事可以做到，我也一定可以。 他們是我適應改變的榜樣。

沒錯，或者說這些變化讓我們能夠完成更多的工作。 例如，當我看到我的工程師同事們現在能夠在短短幾天內完成一個完整的功能，而以前可能需要幾週時間時，我真的覺得非常震撼。 所以，是的，這種改變也帶來了更多的可能性。