Anthropic 設計主管的工作流:垃圾進去,寶貝出來
整理版優先睇
Anthropic設計主管Jenny Wen分享:用「垃圾進去,寶貝出來」工作流,同埋Cowork四版UI嘅減法哲學
Jenny Wen 係 Anthropic 嘅設計負責人,主力設計 Cowork。佢之前喺 Figma 做,而家日日對住五六個項目,同工程師一齊睇真正行緊嘅 prototype,Spec 得幾個 bullet points。佢形容自己嘅工作狀態係「loose」。
呢篇文章展示咗佢點樣用 Cowork 做「garbage in, treasure out」嘅工作流:由用戶研究、Slack 反饋、網上評論全部餵俾 Claude,自動提煉洞察,再分叉做功能建議同 presentation,最後每週一自動執行。呢個流程以前要一個小團隊做一星期,而家自動化咗。
文章仲講咗 Cowork 嘅真實誕生過程——唔係 10 日,而係一年探索加 10 日衝刺。UI 由 V1 嘅工作流導向,到 V4 嘅極簡共享待辦清單,一路做減法。Jenny 認為設計師必須習慣否定自己,擁抱速度,雖然唔會多咗空閒時間,但可以做更多有價值嘅事。
- 結論:從雜亂數據到產品決策嘅自動化工作流係可行嘅,關鍵係跨來源模式識別。
- 方法:先瘋狂加功能,再根據真實使用砍到核心,唔好怕否定自己幾個月嘅設計。
- 差異:內部用戶嘅細緻 feedback 比外部粗線條反饋更有價值,應該優先服務內部挑剔用戶。
- 啟發:設計師角色由 pixel 輸出變為體驗策展,North Star 從五年壓縮到三個月。
- 行動點:建立每週自動執行嘅反饋→洞察→建議循環,並用粗糙線框圖快速驗證方向。
「垃圾進去,寶貝出來」工作流
Jenny 每日要處理嘅信息來源又雜又亂:用戶訪談記錄、Slack 反饋、X 同 Reddit 評論、內部 dogfooding 結果。佢將呢啲嘢全部餵俾 Cowork,等 Claude 自動拆解同交叉分析。
- 1 將所有反饋來源一次過掛載,唔使整理,原始文件直接入。
- 2 Claude 自動拆出多個子 Agent 並行處理,提煉出 7 個洞察主題,每週都唔同。
- 3 分叉兩個任務:一個轉化為 P0/P1 功能建議,另一個做成週一 kickoff 演示文稿。
- 4 揀一個方向叫 Cowork 出粗糙線框圖,避免高保真令你覺得方案已定。
- 5 設成每週一早上 10 點自動執行,結果經 Slack MCP 推送團隊頻道。
粗糙線框圖係刻意為之,令你更容易否定方向,換一個再試。
佢仲話自己唔多用 Skills 功能,因為掛咗個個人筆記文件夾,Cowork 從中學到佢嘅偏好,等於佢自己維護嘅記憶。
一年探索+10日衝刺:Cowork 嘅真實誕生
媒體成日話 Cowork 10日做出嚟,但 Jenny 澄清:實際係佢一年前加入 Anthropic 開始,公司就一直想整一個畀知識工作者嘅 thinking partner,期間試咗好多輪原型,有啲效果唔好。
轉折點係 2025 年底假期,非技術人員開始用 Claude Code,顯示出早期 PMF 信號,於是決定衝刺 10 日推出。
- 1 V1:結構化輸入面板,Chat 次要。Jenny 話「都 2025 年仲要人手填?直接問 Claude 咪得。」
- 2 V2:Chat 做主位但引導選項太多,打開就覺得累。
- 3 V3:點擊流程引導,視覺元素互相競爭。
- 4 V4(而家):剝掉側邊欄,主頁係 Claude 嘅待辦列表,輕到不行。
核心矛盾係:究竟要話畀用戶幾多嘢,定係等佢哋自己探索?佢哋最終揀咗後者。如果一開始就做 V4,可能唔知邊啲可以砍,只有先做加法再做減法先有底氣。
規劃縮短,角色轉變
Anthropic 內部做月度規劃,一張 spreadsheet 最多 12 個 P0,每個有 DRI,每週 check on track 定 not on track。Spec 主要畀法務同安全睇,核心溝通係坐喺工程師側邊睇 prototype 討論行為。
North Star 願景最多三到六個月,因為未知太多。設計師嘅價值係將五個團隊重疊嘅嘢策劃成連貫體驗,唔係產出像素。
Jenny 對覺得「腳下嘅地在鬱」嘅設計師話:工程師已經適應咗以日為單位交付功能,設計師係第二波。佢都有被威脅嘅感覺,但見到同事適應得好,覺得自己都得。
你並唔會有更多空閒時間,實際上你會工作得更努力,因為可以做更多鍾意嘅事。

Jenny Wen,Anthropic 的設計負責人,Cowork 的設計主導者。她最近上了一期播客,完整展示了自己怎麼用 Cowork 幹活,還講了 Cowork 的真實誕生過程,以及產品界面經歷了多少次推翻重來。

Jenny 加入 Anthropic 之前,在 Figma 工作。那是一個把"設計工具"做到極致的地方,每個像素都有意義,每個交互都經過打磨。
一年後,她的日常變成了這樣:同時 consulting 五六個不同的項目,大量時間跟工程師坐在一起看 working prototype(不是設計稿,是真正在跑的內部構建版本),當場討論怎麼改。Spec 從幾十頁變成幾個 bullet points,Figma 還在用但不再是主要產出物。
她自己用了一個詞來形容這種新的工作狀態:"loose"。
如果你只看表面,會覺得這是一個設計師"降級"的故事。但 Jenny 最近做了一次 40 分鐘的深度分享,手把手展示自己怎麼用 Cowork 工作,翻出四版被斃掉的 UI 截圖一個個說"這版為什麼不行",順帶把 Cowork 的真實誕生過程講了出來。
你會發現,不管是她自己的工作方式,還是 Cowork 這個產品本身,走的都是同一條路:先拼命做加法,再一輪輪砍到只剩最核心的東西。
"垃圾進去,寶貝出來"
先看她現在怎麼幹活。
Jenny 給自己用 Cowork 的方式起了個名字:"garbage in, treasure out"。垃圾進去,寶貝出來。
她每天要處理的信息來源又雜又亂:用戶研究訪談記錄、內部 Slack 反饋頻道、X 和 Reddit 上用戶的評論、內部 dogfooding 的反饋。單獨看每一條都不算什麼,但堆在一起就是一團噪聲。Cowork 擅長的事情恰恰是從這團噪聲裏提煉出信號。
她在視頻裏做了一段完整的演示。這個鏈條值得仔細看,因為它展示的不是某個單一功能,而是一個從原始數據到產品決策的完整工作流。
第一步:把所有反饋來源一次性喂進去。 她把 UXR 團隊的用戶訪談文件夾直接掛載到 Cowork,不整理不標註,原始文件扔進去就行。同時在同一個對話裏讓 Claude 去 X 和 Reddit 上搜 Cowork 的用戶評價。一句話,兩件事:讀本地文件 + 搜網上評價。Claude 自動拆出多個子 Agent 並行處理。
第二步:提煉洞察。 跑完之後,Claude 把所有來源的信息交叉分析,提煉出 7 個洞察主題,存到她電腦上的一個文件夾裏。她說這些主題每週都不一樣,這正是她想要的。這一步的核心不是"AI 幫你搜信息",而是"AI 幫你做跨來源的模式識別"。用戶訪談說的痛點和 Reddit 上的吐槽可能是同一個問題的不同表達,人工整理很容易漏,AI 做這種交叉分析反而比人強。
第三步:分叉,並行跑兩條線。 她不是順序執行"先想功能,再做 PPT",而是同時開兩個任務。一個把洞察轉化為具體的產品功能建議,按 P0/P1 排優先級;另一個把洞察做成團隊週一 kickoff 用的演示文稿。兩個任務共享同一份輸入,輸出不同,沒有依賴關係,所以並行。
第四步:從功能建議到線框圖。 功能建議出來之後,她挑一個方向,讓 Cowork 直接出幾個交互原型,要求"粗糙線框圖風格"。高保真會讓你下意識覺得"方案已經定了",粗糙的線框圖讓你更容易說"這個方向不對,換一個"。看過之後選個方向,帶到 Figma 或 Claude Code 裏繼續迭代。
第五步:設成定期任務。 她把整套流程設成了每週一早上 10 點自動執行,還通過 Slack MCP 自動把結果推送到團隊頻道。
"I start every Monday morning at 10am with this presentation and with three different product ideas that I can use and kick off the week for."(我每週一早上 10 點就有一份演示文稿和三個可用的產品創意,直接啓動本週工作。)
也就是說,她每週一到公司時,一份基於最新用戶反饋的洞察報告、一組產品方向建議、和一個可以直接在 kickoff 上用的演示文稿已經在等她了。以前這套流程需要一個小團隊花一週,現在是一個自動化的周循環。

她連 Skills 都不用
Jenny 說她個人其實不太用 Cowork 的 Skills 功能。
原因挺特別的:她在 Cowork 裏掛載了一個文件夾,裏面是她平時積累的各種個人筆記,一對一會議記錄、隨手想法、工作中的觀察。Cowork 從這些筆記裏學到了關於她的足夠多的信息,以至於她覺得對 Memory 和 Skills 的需求都降低了。
她把這個比作一種"自己維護的記憶"。不是 AI 系統自動記住你說過什麼,而是你把自己的思考過程以筆記的形式餵給它,它就自然地瞭解了你的偏好、風格和上下文。
她還舉了一個很有意思的例子:準備這期播客之前,她把自己的個人筆記文件夾給 Cowork,讓它根據筆記內容幫她整理出適合在播客裏聊的話題和要點。不是讓 AI 替她說話,而是幫她從自己已有的思考中梳理出脈絡,解決"面對空白頁不知道從哪開始"的問題。
她也說了,這可能不是最佳實踐,但對她的使用場景確實有效。這又是一個減法的例子:複雜的 Skills 體系她不需要,一個筆記文件夾就夠了。
"10 天做出 Cowork"是個誤讀
你可能在各種報道里看到過這個說法。10 天,一個全新產品,從零到上線。聽起來非常硅谷,非常 AI 時代。
但 Jenny 自己說的原話是:
"The actual story is that the Cowork or this direction of Cowork has been something that the company has been thinking about or wanting to do for basically ever since I joined Anthropic about a year ago."(真實的故事是,Cowork 這個方向,從我一年前加入 Anthropic 開始,公司就一直在想、一直想做。)
一年前,Anthropic 內部就在琢磨一件事:怎麼給知識工作者做一個 thinking partner。他們已經有了 Claude Code,給程序員用的 Agent 工具跑得很好。但非技術人羣呢?
過去一年裏,不同團隊做了好幾輪原型。有的偏技術實驗,嘗試不同的 Agent 架構;有的偏產品探索,試各種交互形態。Jenny 說有些 "didn't pan out super well"(效果不太好)。
轉折發生在 2025 年底的假期。那段時間所有人終於有空了,開始認真試 Claude Code。關鍵是,不光工程師在用,非技術人員也開始用了。有人拿它解析播客轉寫稿,有人拿它做複雜的數據分析。Anthropic 觀察到 Claude Code 的 Agent 架構在非技術人羣中出現了早期的 PMF 信號。
"Even if we don't have the perfect product yet, we should get something out there because we think that our moment to capture this audience is right now."(哪怕產品還不完美,我們也該先推出去,因為抓住這批用戶的窗口就是現在。)
所以 10 天是從"我們決定現在發"到"上線"的衝刺時間。前面一年的探索、失敗、積累,媒體全給省略了。

四版 UI,一路做減法
Jenny 在視頻裏翻出了四版 UI 的截圖。看這個演變過程,比任何產品方法論課都實在。
第一版:工作流導向。 左邊是一個結構化的輸入面板,你要手動添加來源、設定輸出類型,Chat 反而是次要的。Jenny 和另一個設計師當時的想法是:用戶可能不理解這個新產品能幹什麼,所以要用 UI 引導他們。
兩個問題同時撞上來。一個是技術層面的,當時的 Claude 還跟不上覆雜工作流的要求。另一個更致命,是體驗層面的。Jenny 說出了那句讓我印象最深的話:
"Why do we have to do this in this day and age when we could just ask Claude to do something for us?"(都 2025 年了,為什麼還要我們手動填這些東西?直接問 Claude 不就好了?)
這句話否定的不是別人的設計,是她自己團隊花了好幾個月精心打造的產品。
第二版:引導式。 吸取了 V1 的教訓,Chat 提到了主位。但團隊還是放不下"引導"的執念。界面上鋪滿了引導選項:創建文檔、做分析、生成演示文稿……每個選項點進去還有參數可以調,文檔長度、類型、格式,一堆旋鈕等着你擰。Jenny 的評價:打開就覺得累。
第三版:嚮導式。 做了一個點擊流程,一步步引導用戶。同時在界面上展示了大量 UI 元素,想讓產品感覺跟普通聊天不一樣。結果是視覺元素互相競爭,用戶不知道該看哪裏。
第四版(現在的版本):極簡。 剝掉了所有重型側邊欄和引導流程,主頁變成了 Claude 的"待辦列表",你能看到所有活躍的任務、等待審批的任務、定時任務。
"A shared to-do list between you and Claude, as opposed to this chat box with a bunch of overwhelming suggestions."(一個你和 Claude 之間的共享待辦清單,而不是一個塞滿建議的聊天框。)


從"工作流編排器"到"引導式聊天框"到"嚮導流程"到"共享待辦清單",交互越來越輕,給用戶的指引越來越少。而且 Jenny 說了,第四版四五週前還跟現在長得完全不一樣,他們到現在還在不停改。
回頭看這四版,有一個容易忽略的邏輯鏈。V1 做了大量加法:結構化輸入、工作流模板、輸出類型選擇。這些設計不是因為團隊不懂產品,恰恰相反,是因為他們太懂了。他們預判了用戶可能的困惑,提前設計了所有引導路徑。然後 V1 被否定,V2 減了一些還是太多,V3 換了形式但本質還是在"教用戶",V4 幾乎全部砍掉。
如果 Anthropic 第一天就做了 V4 那個極簡界面,行不行?大概率不行。因為他們不知道哪些東西可以去掉。只有先把能想到的都做出來,在真實使用中發現"這個沒人用""那個反而礙事",才能做出有底氣的減法。
Jenny 總結的核心矛盾是:你到底要告訴用戶多少東西,還是讓他們自己探索。他們最終的答案偏向後者。
Anthropic 內部怎麼做規劃
Jenny 透露了一些 Anthropic 內部的產品規劃方式。
Cowork 團隊做月度規劃。一張 spreadsheet,最多 12 個條目,都是真正的 P0。每個條目一個 DRI(直接責任人),每週回來看一眼:on track 還是 not on track。就這麼簡單。
以前的產品 Spec 要做六個月到一年,里程碑、P0、P1 排得工工整整。現在呢?
"It's usually just like a few bullet points."(通常就幾個要點。)
Spec 還寫,但主要是給法務和安全團隊看的。核心溝通方式已經變了:大量時間是和工程師坐在一起看原型、討論行為,而不是做 Figma 高保真稿。
North Star 願景也縮短了。
"There's no such thing as a one-year vision, let alone a two- or five-year vision for us, because there's so much that's unknown out there."(對我們來說不存在一年期的願景,更不用說兩年或五年,因為未知太多了。)
她覺得願景不一定要是靜態的 deck,可以是一個 prototype。設計師在這裏的價值不是產出像素,而是把五個不同團隊在做的可能互相重疊的東西,策劃成一個連貫的體驗,幫大家看到一條把這些碎片拼在一起的路徑。最多看三到六個月。

內部用戶比外部用戶重要
這個判斷乍一聽反直覺。Jenny 說:
"We rely on internal feedback a lot, which might be counterintuitive."(我們非常依賴內部反饋,這可能違反直覺。)
她解釋了原因:內部用戶和外部用戶給的反饋是不同層次的。外部用戶的反饋偏粗粒度,通常是"能不能跑通我的場景"。內部用戶的反饋細緻得多,會深入到交互設計和打磨層面。因為內部的人願意誠實地挑毛病,也最願意把產品推到極限。
"People internally will really poke at that stuff, versus people externally tend to give you feedback about does it work for their user flow."(內部的人會真正挑刺,外部用戶更多是告訴你他的場景能不能跑通。)
Jenny 提到 Claude Code 的成功也是同樣的策略:先讓內部最挑剔的用戶滿意了,外部才好推。她說在 Figma 也是一樣的做法。

一個佐證這個策略有效的故事:Cowork 開始開發時,他們找了幾個內部銷售人員做輸入。這些人是"diehard Claude Code users"(Claude Code 的鐵粉),用命令行工具來生成銷售線索、寫電話腳本。Jenny 說她當時都不知道 Claude Code 還能這麼用。
後來 Cowork 一出來,這些人全部遷移過去了。不僅如此,他們的同事也開始用了。有 UI 更好用、更貼近日常工作流、不用開命令行。這說明 Cowork 不是 Claude Code 的簡化版,而是面向完全不同用戶羣的產品。兩個產品共享底層的 Agent 架構,但面對不同的人、不同的場景、不同的使用習慣。
"腳下的地確實在動"
播客最後,主持人問 Jenny 對那些覺得"腳下的地在動"的設計師有什麼建議。
"If you feel like the ground is shifting beneath your feet, it's because it is."(如果你覺得腳下的地面在動,那是因為它確實在動。)
她的觀察是:工程師已經先經歷了一輪衝擊,"creating entire features in days, not weeks"(以天為單位交付完整功能,而不是以周為單位),而且適應得很好。設計師現在是 "second-tier effect",周圍的角色已經變了,輪到設計師了。
然後她說了一段讓我印象最深的話。不是方法論,不是產品觀點,是一個人面對鉅變時很具體的心理過程:
"我有時候確實會覺得被威脅到了,我的工作變化太大了,人們不再用以前的方式看重我。但我想到我那些工程師同事,他們已經適應了工作方式的劇變,而且適應得非常體面,產出比以前更好更多。我看着他們,就覺得,如果這些我真心尊敬的人都能做到,我也可以。"
這段話有意思的地方在於,她沒有說"AI 解放了設計師去做更高級的事"這種漂亮話。她說的是焦慮,是看着同事先走過這條路之後獲得的信心,是一種很具體的"跟着走"的勇氣。
然後她補了一句帶苦笑的真相:
"You don't actually get more free time. You actually work harder."(你並不會有更多空閒時間。你實際上會工作得更努力。)
和我使用Claude Code的 體感一模一樣,你能做的事情更多了,你總想幹點不一樣的沒幹過的,想法從你的腦子裏一個一個蹦出來,你都想去嘗試。這放在之前你可能只是想想,而現在你可以真的能幹起來。
因為你不用做以前不喜歡做的事了,你會做更多你喜歡的事。結果就是你反而工作得更努力了。

最後
Cowork 的故事拆開來看,有三層可以帶走的東西。
第一層是節奏:先做加法再做減法。一年的原型探索不是浪費,是在積累"什麼不該做"的判斷力。10 天衝刺不是天才靈感,是一年的認知積累遇上了對的時機。下次你在一個產品方向上反覆折騰覺得沒進展的時候,想想 V1 和 V2 的意義。
第二層是勇氣:否定自己的能力。Jenny 看着自己團隊花幾個月做的 V1 說"都 2025 年了為什麼還要用戶手動填這些",這種自我否定不是虛無主義,是對用戶體驗的誠實。
第三層是速度:AI 時代的時間單位變了。工程師從周變天,規劃從年變季,North Star 從五年變三個月。設計師的 Spec 從精美文檔變成幾個 bullet points。不是因為大家變懶了,是因為 Claude 幫你幹了那些你不該花時間乾的事。
Jenny 說得好:不是你自由了,是你能做更多了。
本文內容來源:YouTube 視頻 "Claude Cowork Tutorial from Cowork's Design Lead (40 Min) | Jenny Wen",Peter Yang 播客
加入XiaoHu.ai 日報社羣 每天獲取最新的AI信息

____________
End.
感 謝 閲 讀
點贊,轉發,關注關注關注↓↓