“垃圾進，珍寶出”：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 點就會帶著這份演示文稿、帶著三四個不同的產品想法開始工作，用來 kick off 這一週。它把從反饋到做出 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：

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