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

關於 Cowork 與 Claude Code 的差別

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

關於 Cowork 的誕生故事

那句「他們 10 天就做出來了」的說法，其實是從某次訪談或媒體報導中被截取出來的。但真實的情況是，關於 Cowork 這個方向，我們其實從我一年前加入 Anthropic 時就已經開始構思了。我們一直在思考如何打造一種能夠幫助所有通用知識工作者的「思維夥伴」（thinking partner）。

雖然 Claude Code 已經能夠很好地處理程式碼相關的任務，但我們的目標是涵蓋所有知識工作情境。我覺得真正的挑戰在於：我們該如何執行這個想法？什麼樣的架構是最合適的？什麼樣的使用者體驗（UX）才是正確的？

關於設計流程的演變

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

關於規劃與願景

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

關於設計師的未來

如果你覺得腳下的地面在移動，那是因為它確實在改變。我們必須承認這一點，並學會適應，同時也要以開放的心態重新審視我們現有的工作方式。

每當我覺得自己的職業受到挑戰時，但在這種時候，我會想到我的工程師同事們。他們的工作早就經歷了巨大的變革，但他們不僅適應了這些變化，還以極大的勇氣和謙遜迎接挑戰，最終實現了更有效率、更出色的工作成果。他們是我的靈感來源——我會告訴自己：如果這些我非常尊重的同事可以做到，我也一定可以。他們是我適應變化的榜樣。

開場

Peter Yang：大家好，今天我非常興奮地歡迎 Anthropic 的設計負責人 Jenny。Jenny 將向我們展示她如何使用 Claude Cowork 和 Claude Code 來設計和發布產品，同時也會與我們分享 Cowork 的內部故事，或許還會聊聊她產品的下一步發展。

Jenny，你工作中典型的一天是什麼樣的？哪些任務會佔用你大部分時間？

Jenny：

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

Peter Yang：基本上你會透過 Claude 之類的工具生成一堆原型，然後就和工程師一起 jam，給一些回饋，然後用提示詞讓 AI 去改進它，對嗎？

Jenny：

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

Peter Yang：我覺得那一直是我身為產品經理或設計師最享受的部分，就是把設計師和工程師拉到一起，看著產品一起迭代。所以你們現在不太做那種規格文件、Figma 文件之類的規劃文件了嗎？還是直接在程式碼裡迭代原型？

Jenny：

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

Cowork 實作示範

Peter Yang：你能不能給我們展示一下你如何使用這些產品，或者每個產品你分別用來做什麼？

Jenny：

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

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

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

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

Peter Yang：在你的實際工作中，你們有那種每週洞見報告之類的嗎？就是自動彙總所有內容然後寄給你和團隊的？

Jenny：

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

Peter Yang：我覺得這才是應該發生的，而且我感覺大多數公司裡團隊之間都太割裂了，但 Anthropic 感覺完全不是這樣。

Jenny：

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

Cowork vs Claude Code 的使用情境邊界

Peter Yang：我知道 Anthropic 的行銷、產品經理現在基本上都在用 Claude Code 做事，尤其是在 Cowork 內部可用之後。你怎麼看待不同類型的使用情境？或者大家是怎麼用 Cowork 和 Claude Code 的？

Jenny：

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

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

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

Jenny：

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

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

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

Peter Yang：一切都是關於迭代，一切都是關於迭代。我現在也變懶了，我總是讓 AI 先做第一版，然後我再去反應。

Jenny：

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

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

Skills 與個人知識庫

Peter Yang：你會用哪些 skills？或者你有沒有個人專用的 skills 來做這些文件和簡報？

Jenny：

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

Peter Yang：比如我有一個 writing skill，它會告訴 AI 不要用那些 AI slop 的詞彙。

Jenny：

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

Peter Yang：是因為它每天會根據你的對話自動更新記憶嗎？

Jenny：

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

團隊協作節點

Peter Yang：所以你在整個流程中什麼時候把團隊拉進來？或者說你和 AI 迭代，然後再跟團隊迭代來回切換，還是怎麼做的？

Jenny：

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

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

我覺得有了這些之後，我們還是不會直接把所有東西都交給 Claude 去做。我們仍然依賴我們自己來做很多判斷，以及我們去管理和決定真正要建構和做什麼的能力。

Peter Yang：人們在網路上談論品味和判斷力時，我覺得這些能力的培養方法，其實就是透過從內部和外部持續獲取大量的產品回饋。在這個過程中，你會逐漸形成一種直覺，能夠察覺哪些地方出了問題、需要修復。因為你每天都在傾聽和處理這些回饋，久而久之，你就會對問題有一種敏銳的判斷力。

Jenny：

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

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

Cowork 誕生的真實故事

Peter Yang：我們來聊聊 Cowork 是怎麼誕生的吧。外面有很多關於它 10 天就做出來的故事，但其實在那之前已經有很多迭代了吧？

Jenny：

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

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

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

Peter Yang：如果我沒有理解錯的話，過去一年你們在內部的 Slack 裡分享了很多原型，收集了大量回饋，最後確定了一個可行的原型。然後因為看到市場對它的需求，你們就快速完成了一次衝刺，把產品推了出來。

Jenny：

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

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

Peter Yang：你能分享一些關於早期迭代的經驗，或者展示一些正在開發中的內容嗎？

Jenny：

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

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

但是感覺要做很多步驟才能完成，在 2025 年這個時代，為什麼我們還要這麼複雜？直接讓 Claude 來處理這不就行了嗎？

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

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

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

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

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

Peter Yang：也許未來它可以支援多個智能體（agent），可以在上面拖動任務來管理工作流。

Jenny：：

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

Cowork 與 Claude Code 的差異定位

Peter Yang：在使用 Claude Code 的過程中，我經常在推特上分享一些回饋。它內建了很多斜線命令（slash commands），需要使用者一點點去學習。這種體驗有點像去 Costco 購物時的「尋寶」（treasure hunt）：你永遠不知道會發現什麼新的功能。

但對新手來說，這種方式並不算友善。它更像是一款遊戲，隨著使用時間增加，你會逐漸熟悉並掌握它。我感覺 Cowork 可能是在嘗試探索普通聊天工具和 Claude Code 之間的中間地帶。它不會把所有功能都隱藏起來，同時又能透過某種方式引導使用者更好地使用它。

Jenny：

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

不過，我們的目標是讓這些功能成為次要的互動方式，而不是強制性的學習內容。也就是說，即使使用者不了解所有命令，仍然可以輕鬆使用 Cowork。我們希望使用者與 Claude 的互動是自然且直觀的，而不是必須透過記住一系列命令才能完成操作。

規劃流程與願景

Peter Yang：Anthropic 的規劃流程是怎樣的？你們會進行年度規劃和目標設定嗎？還是更多依賴原型開發和不斷嘗試？

Jenny：

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

Peter Yang：相對靈活，對吧？有趣的是，我發現最具創新的公司往往較少進行年度規劃，而是更多地透過不斷迭代、並從使用者中學習。你在職涯中是否做過類似 North Star 願景 deck 的東西？你覺得這些有用嗎？

Jenny：

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

然而，願景真正的作用在於引導大家朝著同一方向前進，特別是在每個人都可以自由建構各種專案的環境中。所以我現在認為願景的時間跨度最多是三到六個月，並且可以用文件的形式呈現。我覺得當願景是可視化的時候，它更具影響力。這也是設計的巨大價值所在——能夠把各種元素整合在一起，在特定時間段內講述一個連貫的故事。當然，願景也可以是一個原型，而不只是一本靜態的 deck。它可以幫助我們協調團隊之間的工作，特別是在我們有五個團隊處理非常相似或可能衝突的專案時。設計可以透過策展來幫助這些想法達成一致，並為我們展示一條通向理想使用者體驗的路徑，而不是分散的體驗。

Peter Yang：那麼，你們會有產品經理的審查，或者針對相關人員的審查嗎？這些審查是正式的嗎，還是他們也參與到原型設計中？

Jenny：

我們確實有審查，但不像我以前在一些公司那樣，每個功能都需要審查。我們的審查主要針對那些較大且優先級較高的專案。審查的目的不是為了耗費大量時間準備，而是為了提高專案的可見性並獲得回饋。如果有跨團隊的、影響公司的重要專案，我們就會進行這些審查。

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

Peter Yang：那麼，對於那些覺得自己的職業環境正在快速變化的設計師們，你有什麼建議嗎？他們是否應該開始學習提交程式碼（PR）？還是說設計師應該採取其他方式來適應？

Jenny：

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

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

Peter Yang：從某種程度上來說，這些變化讓設計師擺脫了很多繁瑣的重複勞動，比如不再需要花時間在調整各種方框上，對吧？這樣你就能把更多精力投入到更高層次的思考和創造性工作中。

Jenny：

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