Claude Code與Cowork負責人：智能體時代，團隊怎么管、人怎么活

編輯｜Panda

Anthropic 工程師人均每個季度產出的代碼量，是 2025 年同期的 8 倍。這可不是某個孤立團隊的戰績，而是一整條從「穩定」直接拉升到「起飛」的曲線：過去幾年幾乎持平的產出量，在過去一年里近乎垂直上升。

圖源：《When AI Builds Itself》，Anthropic

寫代碼，正在從工程師工作中最耗時、最稀缺的環節，變成一項「理論上人人皆可擁有」的能力。

帶來這條曲線、也親身管理著這條曲線背后所有人的，是 Anthropic Claude Code 與 Cowork 團隊的負責人Fiona Fung

在 Lenny's Podcast 的一期訪談中，她講述了當「編碼不再是瓶頸」之后，一個工程組織真正需要面對的問題：野心的上限在哪里？質量怎么守住？管理者每天該做什么？團隊里那些不再寫代碼、只是「等 Agent 干活」的人，會不會覺得孤獨？

視頻地址：https://www.youtube.com/watch?v=Ybrl4FYM57c&t=3s

這篇文章梳理了這場訪談的核心內容。

Fiona Fung 簡介

Fiona Fung 在軟件行業已經工作超過 25 年。她的職業生涯始于 IBM，在 DB2 操作系統服務團隊做實習生，當時用的還是 Vim 和終端調試器。此后她加入微軟，在 Visual Studio 團隊一待就是 11 年，參與打造了 Visual Studio 和 TypeScript。她曾在 Visual Studio 編輯器組工作，用 VS 編輯器本身來構建 VS 編輯器，這也是她「dogfooding（嘗自己的狗糧）」情結的起點。

離開微軟后，她加入 Meta，從零到一帶出了 Facebook Marketplace 團隊，這項業務如今每年產生的商品交易總額（GMV）已超過 1000 億美元。在 Meta 期間，她還負責過公司第一款智能眼鏡產品，并參與打造了初代 AR 眼鏡項目 Orion。隨后她轉到 Instagram，統領基礎設施、增長、誠信與安全團隊，管理規模一度超過 500 人。

如今在 Anthropic，Fiona Fung 統領 Claude Code 與 Cowork 背后的整個工程與產品團隊，Boris Cherny（Claude Code 之父）與 Catherine Wu 都向她匯報。兩人此前都曾登上 Lenny's Podcast，且都是節目歷史上收聽量最高的幾期嘉賓之一。

從「刻錄 CD」到「編碼不再是瓶頸」

Fiona Fung 回憶，她在 Visual Studio 時期，軟件是要刻錄進 CD 再上架銷售的，這意味著團隊必須在一個「硬性死線」之前把所有事情做完。正因為工程時間是極其稀缺的資源，那個年代的工作方式高度依賴前期規劃。一旦定了范圍，幾乎沒有回旋余地。

這種稀缺性，正是今天被徹底打破的東西。她說：「以前工程時間是非常寶貴的資源，你還有這些非常硬性的死線……現在的轉變是，編碼不再是瓶頸了。」

這表明：不只是工程師，Claude Code 團隊里的設計師、產品經理，幾乎每個人都在提交代碼

參與提交代碼的人變多了，學科背景也更多元了，但吞吐量本身也高到前所未有。這就帶出了她反復強調的一個詞：驗證（verification）

當越來越多不同背景的人都能產出代碼，如何確保每個人對代碼質量都有足夠的信心，成了新的核心問題。

「現在是關于你能有多大野心」

Fiona Fung 提到一個細節：一位工程師原本不是移動端出身，團隊卻需要一個新功能覆蓋到移動端。過去他大概率會說「這個太難了、太復雜了」，但現在的反應變成「等等，這其實完全可行，我讓 Claude Code 去做就行了」。

這呼應了訪談中反復出現的一個判斷：編碼這件事本身不再是限制，限制變成了你敢不敢想。「一切理論上都變得可能了。現在的問題是你能有多大野心。」

Fiona Fung 將這種變化形容為「天花板被抬高了，任何人都能做到以前做不到的事」。這種轉變并非人人都能輕松適應。訪談一開始，Lenny 就提到一個被反復討論的現象：團隊和整個行業內部，正在出現一種「擁抱 AI、干得風生水起」與「抵觸 AI、感到挫敗甚至憤怒」兩類人之間的分裂。

對此，Fiona Fung 認為成長型思維是分水嶺所在：那些始終保持好奇、愿意持續學習的人，往往適應得更好；而挫敗感背后，很多時候藏著一種更本能的情緒——恐懼

她的建議是：與其被這種恐懼支配，不如主動去問自己「這件事里，哪些是我能控制的」，這個思路會在文章后半部分她講述自己成長經歷時再次出現。

這也是她對招聘畫像的重新定義。她現在尋找兩類人：

• 有產品感的創意 builder：他們是那種對某個產品有強烈熱情、會把想法從零構建出來、并持續根據反饋打磨迭代的「造夢者」；
• 深度系統專家：負責那些模型目前仍處理不好、必須靠人類專業知識兜底的硬核部分。

她說，這兩類人「信任但要驗證」的原則同樣適用：模型很強，但總有一些領域仍然需要真正的專業判斷

Claude 替她盯著整個團隊

Fiona Fung 描述了她作為管理者，工作方式的一次顛覆性轉變。

她現在會在團隊維護的所有代碼倉庫里常駐一個 Claude Code 遠程會話，這個實例同時能訪問團隊的 Slack 頻道和各類指標儀表盤。每個月，她會和團隊成員一起打開這個會話，共同回顧：這個月聚焦做了什么？上線了哪些產品？市場反饋如何？有沒有引發什么問題？

「以前我可能只會用這些會話生成 PR 和修復 bug，現在我用它們來和我支持的人展開對話。」

她提出了一個管理原則：「犯新的錯誤」。她說，允許犯錯是必要的，「只要每次犯的是新錯誤」，因為如果目標是零錯誤，往往意味著團隊推進得不夠快，或是過于謹慎。

而在過去一兩個月里，這套流程又被一次新功能「Routines（例行程序）」徹底改變了。

她過去每天早上喝咖啡時會人工瀏覽各個反饋渠道，判斷當天有沒有時間去修一些小問題；現在她設置了一個每天固定時間運行的 Routine，自動幫她掃描反饋渠道、提煉主題、甚至直接生成可供審核的 PR。她這樣形容這層變化：「以前我可能還會自己生成一些 prompt，但現在有了 Routines，幾乎是我在讓一個 Agent 幫我生成 prompt 和 PR。

Bad 與 Sad：8 倍產出下如何守住質量

代碼審查曾是團隊最大的瓶頸之一。Fiona Fung 坦言，去年 Claude Code 團隊甚至還沒有「Claude 做代碼審查」這件事。

如今，團隊仍然堅持對需要深度專業判斷的領域保留人工審查，但更多情況下，團隊會把「什么是好的標準」寫成一份規范（spec），直接檢入代碼倉庫，并保證規范隨代碼同步更新。她的經驗是：「只要你把『什么才算好』這件事寫清楚放進倉庫里，代碼審查就能去核對它是否仍然符合當初設定的目標。」

她還提到一個有意思的細節：團隊重新審視了測試驅動開發（TDD）這個由來已久的工程原則：先寫測試、確保測試失敗，再去實現功能。

她說自己過去一直不太擅長這套流程，「感覺像是必須先吃掉那盤西蘭花」，而她本人享受的是直接動手把產品做出來的那份快感。但她記得自己在 Claude Code 上修復的第一個 bug，正是先對 Claude 說「我想做測試驅動開發，幫我先把測試寫出來，確保它先失敗」，然后再去做真正的修復，看著測試由紅轉綠。

她認為，這說明了一件事：那些一直存在、原本正確卻因為「太麻煩」而被工程師繞開的好方法論，如今因為有模型分擔了大量執行工作，反而變得比以前更容易被堅持下來。

在質量管理上，團隊摸索出了一套簡單的分級框架：「Bad」指的是那種嚴重、不可恢復的錯誤，比如 CLI 崩潰、丟失工作進度；「Sad」則是可恢復但影響體驗的問題，比如界面閃爍。團隊把這套分類的具體定義權下放給各個小組，讓他們根據自己負責的界面或服務來定義「什么算 Bad、什么算 Sad」，因為不同產品面之間的儀表盤數字很難直接比較，而一個統一的高層框架能幫團隊更快看清全局體驗的走向。

團隊還專門做了一個略帶幽默感的儀表盤：追蹤反饋渠道里「臟話」出現的頻率，用來側面感知用戶的挫敗情緒。這個想法誕生于去年九月，Fiona Fung 笑稱這是團隊一次很有意思的頭腦風暴產物。

高 Agency，也意味著高 Accountability

Agency（自主行動力）」是 Fiona Fung 反復強調的團隊文化關鍵詞。談到經濟學家 Tyler Cowen 近期一場演講中提到「主動性（initiative）」是當下表現最好的人的共同特質時，她立刻表示這與團隊信奉的價值高度一致：「這就是我們在 Claude Code 和 Cowork 團隊特別看重的東西——遇到問題，團隊里每個人都會有自己的解法。所以我們非常強調高 Agency，但我們也說，高 Agency 意味著高 Accountability。

她解釋，這意味著團隊給予成員充分的自由去「大膽嘗試」，但同時也要求每個人對結果負責：你解決問題的假設是什么？做完之后效果如何？這種「自由與責任對等」的機制，她認為是團隊保持高產出同時不失控的關鍵平衡點。

用她的話說，團隊文化里那種「大家都在放手去做」的狀態，最終都要回到一個很樸素的追問：你到底解決了什么問題，又是怎么驗證自己確實解決了它。

別把「動作」當成「進步」

關于如何衡量 AI 時代的工程師生產力和投入產出比，Fiona Fung 的態度相當審慎。她回顧了團隊內部關于「代碼行數」這個指標的爭論：曾有工程師提交了巨量代碼行數，后來發現只是把一個現成的庫搬運了過來；也有相反的情況：團隊升級了底層框架后，同樣的產出反而生成了更少的代碼。

她的結論是：「不要把動作誤當成進步。如果你只是在衡量工具的使用量，你衡量的是『行動』，但這真的在推動你想要的結果嗎？」

她分享了一個來自 Facebook Marketplace 早期的例子：團隊按區域逐步上線產品時，最初盯著的核心指標是「賣家數量」。但在第一個上線的地區，賣家數量偏低，用戶卻依然能順利找到想要的商品；后來才發現，這個地區雖然賣家總數不多，卻聚集了不少「超級賣家」。

如果當時機械地按賣家數量這一個指標來決定是否擴張，可能會得出錯誤結論。這次經歷讓她此后始終提醒自己：任何指標，哪怕曾經很合理，都要不斷追問它是否仍然服務于最初想要達成的結果。

除了指標本身，她也強調「傾聽巡回」（listening tour）的價值，尤其是與資深工程師的一對一交流。這些對話往往比儀表盤更能激發出真正有價值的洞察，也更容易在全團隊范圍內擴散。

她表示，這套傾聽巡回的習慣，也正是她推行「管理者先做 IC」這項制度的直接來源之一：正是在與團隊成員的一輪輪交流里，她聽到了不少關于「審批層級太多」「希望有更清晰的優先級」的真實聲音，才決定從制度層面做出調整，而不是僅僅停留在口頭上的鼓勵自主性。

每個經理都要先做一段時間的 IC

Fiona Fung 在團隊里推行了一項頗為獨特的做法：每一位新晉管理者在正式承擔管理職責之前，都要先以個人貢獻者（IC）身份工作一段時間，此后也要持續保持部分 IC 工作。

這個想法來自她加入團隊后做的一輪內部傾聽。她注意到，如果一個管理者一上來就急著「打開管理工具箱、做管理該做的事」，反而容易造成過多的審批層級；而如果先花時間深入代碼庫和產品本身，往往能和團隊建立起真正的信任關系。

這項原則某種程度上也是她自己職業生涯的翻版：她提到，當年從微軟轉到 Meta 出任管理崗位時，第一個季度她堅持先以工程師身份工作，就是為了親身體驗「作為一名 Meta 工程師去交付產品」是什么感覺。

到了 Anthropic 后，她延續了這個習慣。加入 Claude Code 團隊的第一周，她原本準備走老套路，請每位工程師喝咖啡聊需求，后來卻改成向 Claude 提問了解代碼庫。

她表示，自那之后每天做 PR，對她而言重要的不是修復了什么具體問題，而是這件事本身能讓她始終保持「在場感」：「哪怕儀表盤和各種數據再完美，如果你作為一個領導者沒有每天真正地使用、體驗自己團隊所構建的產品，你就會漸漸失去那種『觸感』。」

她還提到一個細節，頗能說明這種「親手上陣」對她本人的意義。

她說自己在 Meta 最后一次提交生產環境代碼大約是在 2017 年，此后雖然一直堅持 dogfooding，卻很少再真正動手寫代碼上線。很大程度上是因為她害怕自己不小心捅出簍子，或者因為流程、工具鏈早已變了樣，反而浪費別人的時間去替她兜底。但加入 Claude Code 團隊的第一周，她原本按老習慣準備挨個約工程師喝咖啡、了解代碼庫，后來卻停下來想「不如直接問 Claude 吧」。

于是 Claude 成了她最好的「入職搭子」：她可以隨時就代碼庫提問，Claude 不僅幫她生成自動化測試，還在她想額外做一輪人工測試時，幫她梳理出一套能覆蓋各種邊界情況的手動測試方案。正是這種確定性，讓她重新找回了提交代碼的信心，也讓不少許久未寫代碼的朋友，如今紛紛告訴她「我又開始提交代碼了，多虧了 Claude」。

技能會退化嗎？

面對「工程師不再親手寫代碼，編碼能力會不會退化」的問題，Fiona Fung 的回答是：這是團隊內部真實討論過的話題。

她提到Boris Cherny 早期是親手寫代碼的，雖然現在已經不這樣做了，但正是那段經歷讓他對系統 architecture 有了深刻理解。

她認為，無論模型多強，「深入了解你所依賴的那一層」這件事本身依然重要，因為只有理解依賴關系，你才能真正意識到底層發生了變化，也才能更好地利用這些變化

「和 Agent 一起工作太孤獨了」

訪談中一個格外真實的細節，是團隊發現的一種新型「孤獨感」。過去的工程協作是「N 個人一起搭一套系統」，其中有人做后端、有人做前端、有人做 iOS，彼此之間自然產生大量互動；而現在，一個人可能同時運行著十個并行工作的 Claude 實例獨自推進項目，團隊成員之間反而互動變少了。

Fiona Fung 坦承：「過了一段時間之后，我們發現這開始變成一種孤獨的體驗，因為大家都在和自己的 Agent 工作太多了。」

為此，團隊最近開始組織「結對編程午餐」，也保留黑客馬拉松這樣的集體創作時段。

有意思的是，團隊發現即便都在用 Claude Code 和 Cowork，每個人的工作流程也千差萬別。真正坐下來看彼此如何工作時，大家反而能從中學到很多此前沒意識到的技巧。這被形容為一種類似孩子「平行游戲」的狀態：各自在做自己的項目，卻因為并肩工作而彼此受益。

同樣值得記錄的，是關于「Flow 心流」的懷念。Fiona Fung 自己也做過十年工程師，她坦言過去那種「獨自鉆研一個棘手問題、最后攻克它」的心流體驗和成就感，如今確實在變少。現在更多時候，人是在等待 Agent 把東西構建出來。她說，團隊里其他工程師也提到過類似感受：以前最艱難、也最讓人享受的那部分工作，正在被替代。她認為，大家從產品本身獲得的成就感正在填補這部分缺失，但這確實是一種真實存在的轉變，而非虛假的懷舊。

下一個被改變的角色：PM、設計與數據科學

除了工程師，Fiona Fung 認為 PM 是目前受 AI 沖擊第二大的角色。因為 PM 不再受限于工程帶寬，一旦有想法，很多時候可以自己動手實現。

她提到，Anthropic 的 PM 們已經開始「卷起袖子」，在工程師排期不上的時候自己動手把一些功能改動完成。她判斷，接下來設計和數據科學會是下一批被顯著改變的領域，團隊需要投入更多精力，把這些環節的工作流程也自動化起來。

Lenny 在訪談中提到一位從事數據科學工作的朋友的經歷頗具代表性：現在很多人會自己用 AI 做一版數據分析，再拿去給數據科學家「過目把關」，而這些分析往往一半時候是錯的。數據科學家的工作因而變成了不斷審核他人用 AI 生成的分析結果，而不是自己動手做分析。這與 Fiona Fung 所說的「驗證」正是同一個趨勢的不同側面。

對于普通工程管理者，Fiona Fung 總結了這個時代的新常態：絕大多數代碼提交都有 Claude 參與協助；工程師需要持續培養更強的產品感；角色邊界正在雙向模糊。

工程師變得越來越「產品導向」，而越來越多原本非工程背景的人也開始承擔類似工程師的工作。

把 AI 能力帶給身邊的小生意主

訪談中一個格外溫暖的段落，是 Fiona Fung 講述她如何萌生做「Claude for Small Business」的念頭。她出生在香港，幼年移民加拿大時不會說英語，是外婆放下一切陪她長大，但外婆同樣不會英語，在異國他鄉的生活頗為孤獨。

直到有一年夏天，她們偶然發現了一家由講粵語的老板娘開的毛線店，從此每周都去，那里成了外婆的「編織圈」，Fiona Fung 也是在那里學會了如今又重新流行起來的宏觀編織（macramé）。

這段童年記憶，成為她后來關注小微企業的情感起點。真正的契機，是她自己用 Cowork 處理差旅報銷。她一向不喜歡這類瑣事，卻發現 Cowork 處理得很流暢，由此想到：身邊那些起早貪黑、常常利潤微薄的小生意主朋友，如果能用上這樣的工具會怎樣？她隨后幫幾位朋友完成產品上手，過程中他們也幫團隊找出了不少真實存在的 bug，可謂「雙贏」。

她印象最深的一個例子，來自一位經營兩家餐廳的朋友。

這位朋友的文檔文件夾活像「廚房里那個什么都往里塞的抽屜」。她記得自己有菜單文件，卻怎么也找不到。Fiona Fung 授權 Cowork 訪問該文件夾后，很快幫她找到了菜單。更讓她意外的是，這位朋友隨后開始用一種她完全沒預料到的方式使用產品：讓 Cowork 分析同類菜系在當地的定價水平，以確保自己的價格「對本地人和游客都合理」，Cowork 給出的分析接近于一份市場調研報告。

「所以我每次都能學到新東西，而且他們也一直在給我很好的反饋。」

值得一提的是，這條產品線的誕生并非一次自上而下的戰略決策。Fiona Fung 特別強調，「Claude for Small Business」的想法并非她一個人的功勞。在她帶著幾位小生意主朋友做產品體驗的同時，團隊內部也有一支專門和中小商戶客戶做深入溝通的小組，同樣發現了類似的效率缺口，比如商戶們總在問「這個插件支持嗎」「那個插件支持嗎」。

兩條線索最終匯聚到了一起，才有了如今 Cowork 里那個專為小企業設計的功能開關。這些一線經驗后來直接推動了「Claude for Small Business」的誕生。對于如何把這種能力更廣泛地推廣出去，她的建議很樸素：從分享一個真正改變過自己生活的 AI 使用案例開始，把它當作和身邊人打開話題的方式，因為如果不這樣做，AI 能力上的鴻溝只會越拉越大。

「隱性需求」是新產品的起點

Fiona Fung 還分享了 Anthropic 屢屢先人一步發現新機會的方法論：留意「隱性需求（latent demand）」

她提到，團隊觀察到不少并非專業程序員的人也在使用 Claude Code，這促使團隊去思考如何為這類用戶改善體驗。這正是 Cowork 誕生的一條重要線索。

類似的觀察方式也催生了「Claude for Small Business」：團隊注意到用戶不斷追問「這個插件支持嗎、那個插件支持嗎」，于是干脆把這些能力打包整合進產品里，變成 Cowork 里的一個開關。

她將這套方法論總結為：「人們總會以你意料之外的方式使用你的產品，無論是好是壞。最好的應對方式，就是持續迭代、學習，并始終貼近反饋。」

下一步：更加異步化的工作方式

談及工程工作方式的下一個前沿，Fiona Fung 認為團隊正在朝更「異步（async）」的方向演進。

她把這和 Routines 聯系起來：過去她需要同步地寫一個 prompt、等它跑完，再決定下一步要不要異步地再起幾個任務；現在 Routines 能夠按她設定的節奏自動生成 prompt、派發給多個 Agent 去執行，等她第二天早上醒來時，成果已經以 PR 的形式擺在她面前，供她審閱、決定是否合入。

她把這種變化理解為管理者日常工作被系統性「模板化」的過程：過去她每天早上會思考「我該看哪些反饋渠道、該關注哪些人的進度」，現在這套判斷本身也被寫成了可以自動運行的流程。

用她的話說，這是「抽象層級又往上提了一級」。她也坦言，自己同樣很好奇這條路徑接下來會走向何方。她笑著對 Lenny 說：「要是能在一年后再回來聊一次這個問題就好了」，

恐懼、成長型思維，與「不被落下」

對于那些在這場變革中感到焦慮甚至被落下的人，Fiona Fung 給出的建議來自她自己的成長經歷。

她認為成長型思維是應對變化最重要的心態，即要始終保持學習、始終愿意質疑「過去讓你成功的方式，未必還能讓你繼續成功；而這個道理早在 AI 工具普及之前就已經被她驗證過，尤其是在從微軟轉到 Meta 的頭一年里體會最深。

她也談到「恐懼」本身。她認為恐懼是一種進化本能，本無可厚非，但面對它的方式很關鍵：與其把自己代入「一切都在發生在我身上、我無能為力」的敘事，不如去問「這件事在我能控制的范圍內，有哪些是我可以做的？

她分享了自己十幾歲時的一段往事：她當年并未選擇走計算機科學的路，而是一心想成為一名視覺藝術家。

她的第一臺能接觸到的電腦，是高中九年級時學校的打字課教室里的。為了補齊申請工程學院所需的理科課程，她拼命惡補，卻又一度陷入「負擔不起學費」的恐懼；直到高中里貼出一張國家銀行招聘暑期柜員的傳單，她抓住了這條「生命線」，靠著這份最低工資的兼職一路打工攢錢、支付學費，甚至在互聯網泡沫破裂、企業普遍凍結實習招聘的那兩年里，持續做了兩年銀行柜員。

她說，這是她當年在恐懼面前唯一能采取的、真正在自己掌控范圍內的行動。

她還提到自己很喜歡的一句話：「你不敢去的那個山洞里，藏著你正在尋找的寶藏」，并把它和「做一些讓自己感到害怕的事」聯系在一起：當一個人在某個領域已經足夠嫻熟、達到某種效率巔峰時，恰恰是靠著去做那些讓自己害怕的事情，才能繼續成長。

用產品本身校準自己：Dogfooding 的分量

貫穿整場訪談，Dogfooding（嘗自己的狗糧）幾乎是 Fiona Fung 被身邊同事提及最多的一個特質。

她解釋，這是她保持對產品「脈搏」敏感度的方式：任何產品的誕生，背后都承載著一個「讓某種體驗變得更好」的愿景，而只有持續使用產品本身，才能真正貼近這個愿景是否被兌現。

她舉了兩個頗為生動的例子。她早已離開 Facebook Marketplace 團隊多年后，有一次想賣掉自己的一臺 MacBook Air，結果商品剛一掛出，就有人試圖用一種她此前完全沒識別過的新型騙術對她下手。這次經歷讓她再次印證「用戶總會以意想不到的方式使用產品」這一規律。

另一個例子發生在她支持 VR 和 AR 團隊期間：不知為何，她自己設置 VR 設備的方式總能復現出一類奇怪的「地板高度」問題，這個「意外的復現環境」反倒幫團隊定位到了一個真實存在的 bug。

她的結論很樸素：不要把自己局限在指標儀表盤和演示文稿里。那些具體的、一個個「意外發現」的故事，往往比冷冰冰的數據更能告訴你產品到底出了什么問題、又該往哪里改進。

她也提到，這幾乎是她加入過的每一個團隊里都會被反饋的一個特質。無論是 VR、智能眼鏡，還是 Instagram，新同事總會跟她說，很欣慰看到一位領導者真的在用自己團隊做出來的東西，并且愿意給出真實的用戶反饋。對她而言，這不只是一種工作習慣，更是領導者親身體驗團隊所做工作的一種方式。

從 IBM 的 Vim 終端，到 Visual Studio 的第一次 IDE 體驗，再到如今在 Anthropic 管理著一支人均代碼產出 8 倍增長的團隊，Fiona Fung 二十五年的工程師生涯，恰好跨越了軟件行業幾次最重要的范式轉移。

但她在這場訪談里反復回到的，并不是工具本身有多強大，而是一系列更樸素的問題：當編碼不再稀缺，什么才是真正稀缺的東西？答案或許是清晰的判斷力、對產品真實的體感、愿意為結果負責的自主性，以及在快速變化面前持續學習的心態。這些恰恰是任何一次技術躍遷都不會替代掉的能力。

正如她所說，恐懼本身無可厚非，重要的是永遠記得去問自己：「在我能控制的范圍內，我可以做點什么？」