在 Cat Wu 看來，AI 時代的產品經理（PM）最核心的能力是縮短從創意到交付給使用者的時間和定義「開箱即用」的核心任務。以前 PM 習慣做 6 到 12 個月的路線圖，但當下在 Anthropic 內部，一個功能從點子到上線，最快只要一天！
很多人都好奇 Anthropic 為什麼能後來者居上，Cat Wu 給出的答案是：團隊成員的使命一致。他們招聘時會只招「那些最關心為全人類帶來安全 AGI 的人。」她甚至說，如果為了公司整體的 AI 安全使命，哪怕犧牲掉她自己負責的產品線（比如 Claude Code）也完全沒問題！
這場 Podcast 中還包含了很多精彩觀點，訪談原文如下：
Boris Cherny 擅長設定目標，Cat Wu 負責跨部門協作實現
Lenny： Cat，歡迎來到 Podcast。
Cat Wu： 謝謝邀請。
Lenny： 我有太多的問題想問了，非常激動能邀請你來。我想先讓大家了解一下你和 Boris 的分工。大家都認識 Boris，他那一集是本 Podcast 最受歡迎的一集，別有壓力。他創造了 Claude Code，領導著團隊，每天甚至能從手機上提交無數個 PR（拉取請求），我都不知道那個數字現在是多少了。我覺得人們在 Claude Code、Cowork 以及你們正在構建的一切成就上，給你留的功勞還不夠。幫我們理解一下你在團隊中的角色，你如何與 Boris 合作，你們如何分配職責？在 Claude Code 團隊中，PM 角色具體是什麼樣的？
Cat Wu： 我覺得能和 Boris 共事非常幸運，他一直是一個很棒的思考夥伴。他是我們的技術負責人，在很大程度上也是產品的願景領袖，他非常擅長設定目標，比如「三個月、六個月後產品應該是什麼樣子」，也就是產品的「AGI 終極形態」（AGI pill version）。而我的職責很大一部分是弄清楚：我們如何從現狀走到那個 3 到 6 個月後的願景。我把更多的時間花在跨部門協作上，確保我們的市場、銷售、財務、算力資源等團隊都認可這個計劃，確保大家心往一處想，勁往一處使，並且一旦功能準備就緒，發布過程就不會有任何阻礙。我覺得在很多方面我們合作得很好，因為我們某種程度上達到了「思想融合」，但界限其實非常模糊。我想我們大約 80% 的想法是同步的，剩下的 20% 裡，有些事情我比他更在意，就由我主導；另外 20% 他比我更在意，就由他去推動。
Anthropic 招聘 PM 的標準：能縮短時間和定義核心功能
Lenny： 在錄音前你提到，你一直在面試數百名 PM。如果每次有人求我介紹他們去 Anthropic 當 PM 我都能拿五分錢，我現在大概有 300 億的年經常性收入（ARR）了。那裡就是大家最想去工作的地方。所以我能想像你面試了多少人。你告訴我，你發現很多人都做錯了，他們對於「如何成為一名成功的 AI PM」的理解不對。聊聊你所看到的現象，以及大家需要理解當下的成功祕訣是什麼？
Cat Wu： 我認為在 AI 出現之前，技術更迭要慢得多。所以你可以規劃 6 到 12 個月的時間跨度。因為發布功能的速度較慢，所以你會更多地強調與其他合作夥伴團隊的協調，確保他們發布的功能能為你鋪路，因為那個時代的程式碼編寫成本非常高。我認為現在有了 AI，隨著工程效率的加速和模型能力的提升，我們許多產品功能的開發週期已經從 6 個月縮短到了 1 個月，有時甚至是一週或一天。隨之而來的是，我們需要確保產品能非常迅速地發布。這意味著作為 PM，不應再把重點放在確保你的多季度路線圖與合作夥伴團隊保持對齊，而應更多地關注：如何找出最快的方法把東西推向市場？我們如何為產品系列打造一個「概念角落」，讓工程師或 PM 有了想法後，到週末就能送到使用者手中？我認為在 AI 原生產業上表現最出色的 PM，是那些能夠縮短從「產生創意」到「交付給使用者」的時間，並能定義出產品中最核心、最需要開箱即用的任務的人。
讓團隊快速行動的 PM 職責：明確目標，建立可重複發布流程，搭建產品開發流程體系
Lenny： 我很喜歡你說的這一點，大家還沒意識到需要跑得有多快，以及現在的職責很大程度上就是「幫助團隊跑得快」。那具體怎麼做呢？除了擁有最先進的模型外，你和你的 PM 團隊還做了什麼來幫助大家移動得這麼快？
Cat Wu： 我認為第一點是設定明確的目標。由於大語言模型（LLM）太通用了，這實際上在「為誰構建」、「解決什麼問題」以及「核心用例是什麼」上製造了很多歧義。因此，優秀的 PM 能夠說：「好，我們的核心使用者是專業開發者；這個功能我們要解決的主要問題是權限提示太多，讓人感到疲勞；我們的目標是讓企業的專業開發者能安全地實現『零權限提示』。」這設定了一個非常明確的目標，因為它排除掉了許多減少提示音的潛在方案，讓人們能通過一次提示完成更多工作。
第二點非常重要，就是建立一套可重複的發布流程。對於 Claude Code，我們幾乎所有的功能都是以「研究預覽」（Research Preview）的形式發布的。我們在發布時會明確貼上這個標籤，讓使用者知道這是一個早期產品，只是一個創意，我們只是想獲取回饋並進行迭代，而且它可能不會被永久支援。這樣做降低了我們的發布壓力，我們可以在一兩週內就把東西做出來。
第三點是 PM 應該為團隊創建框架，讓他們知道何時引入跨職能合作夥伴，以及這些夥伴的預期是什麼。例如，我們在工程、市場和文件團隊之間有一套非常緊密的流程。當工程師覺得某個功能已經準備好並經過內部測試（dogfooding）後，他們會發在我們的「常青發布室」頻道。負責文件的 Sarah、負責產品市場（PMM）的 Alex，以及 Tar、Lydia 等開發者關係（DevRel）成員會立即加入，隔天就能轉出市場宣傳公告。因為流程非常緊密，降低了任何工程師發布產品的摩擦，而 PM 就是那個應該搭建這套體系的人。
Anthropic 的內部對齊：嚴格指標和「團隊原則」清單，
幾個月的專案才會寫 PRD
Lenny： PRD（產品需求文件）在這個過程中扮演什麼角色？你提到目標很重要，要對「成功是什麼樣子」、「為誰服務」達成一致。你會寫 PRD 嗎？還是只是幾個要點？在 PM 的世界裡，它是如何演變的？
Cat Wu： 我們做兩件事。一是我們有非常嚴格的指標，每週都會和整個團隊進行指標解讀。目標是確保每個人都深度理解業務的方方面面、核心目標是什麼、趨勢如何、驅動因素是什麼。第二是我們有一份「團隊原則」清單，包括誰是核心使用者、為什麼要選他們。我們闡明這些，是為了讓團隊裡的每個人都覺得自己理解業務邏輯，明白什麼對我們重要，以及我們願意權衡掉什麼。這讓人們能夠自主做決定，而不會覺得被 PM 或其他利益相關者卡住。
Lenny： 我喜歡這種感覺，未來我們仍然需要 PM。現在有很多言論說「為什麼需要 PM？直接構建發布就行了，我們需要工程師」。
Cat Wu： 我覺得對於那些特別模糊的功能，寫一個一頁紙的文件（one-pager）確實有幫助，寫清楚目標是什麼、令人愉悅的用例是什麼、目前需要修復的失效模式有哪些。偶爾也會有一些專案，特別是需要重度基礎設施的專案，確實需要幾個月時間，在這種情況下，我們還是會寫 PRD。
產品發布快速不只是 Mythos 的功勞
Lenny： 我想再深入挖掘一下你們是如何跑得這麼快的。我從未見過像 Anthropic 這種節奏，有人做了你們發布日程的行事曆，幾乎每天都有重大功能或產品。網路上有人問：你們不僅發布了，還構建了這個不可思議的 Mythos 模型（目前在預覽階段），因為它太強大了，人們甚至有點害怕它的能力。你們一直在用它嗎？這是你們能跑這麼快的原因嗎？
Cat Wu： 實際上我們已經保持這種高速度好幾個季度了。所以，我不認為這全是 Mythos 的功勞。Mythos 是個極其強大的模型，我們確實在內部使用這些模型，這確實提升了一點發布速度，但我認為這解釋不了大部分的提速。我認為更多在於流程和團隊預期。我們的流程非常精簡，我們想要移除任何阻礙發布的障礙。我們希望團隊中的每一個人都感到被賦能，能夠把一個想法從雛形變成現實，並在不到一週、甚至一天內推向世界。
Claude Code 源碼洩露事件：是流程上的失敗
Lenny： 擁有最好的模型同時還在構建產品，這優勢太大了。我想聊聊幾個插曲，關於 Anthropic 有太多事情發生了。大約一週前，Claude Code 的完整原始碼洩露了，有人把它傳到了網路上，我想那是某人的失誤。關於這件事你有什麼想說的嗎？到底發生了什麼？哪裡出了錯？
Cat Wu： 我們看到後立即進行了調查。我們意識到這是人為失誤的結果。當時有一名員工在使用 Claude 編寫 PR，那只是一個關於我們如何發布軟體包的更新，它實際上經過了兩層人工審核。所以這是人為失誤的結果，我們已經強化了流程，確保未來不會再發生。
Lenny： 那個人還在 Anthropic 嗎？
Cat Wu： 在的。這是流程上的失敗，最重要的事情是從中吸取教訓，增加更多的防護欄。這就是我們一直關注的，大部分防護措施已經上線了。
OpenClaw 中不能用 Claude：訂閱方案不是為第三方產品設計的
Lenny： 另一個問題是關於 OpenClaw（註：指使用者通過第三方工具使用 Claude 訂閱）。最近有一些舉措阻止人們在第三方工具中使用 Claude 訂閱，大家很生氣，也很困惑。感覺這像是對開源社群造成了傷害。人們需要了解這個決定背後的考量是什麼？
Cat Wu： 我們看到了對 Claude 的巨大需求，我們一直在努力擴展基礎設施，並讓我們的框架在 Token 使用上更高效。訂閱方案最初並不是為第三方產品設計的，它們的用法模式與我們的自營產品不同。我們花了很多時間思考什麼是我們能提供的最平滑的過渡方式。所以我很高興能宣布，每個人在訂閱的同時都會獲得一些額度。但是，我們確實必須做出艱難的決定，即我們需要優先考慮我們的自營產品和 API。這就是這個決定的初衷。
Lenny： 這對我來說完全說得通。你們每個月以 20 美元的價格補貼這種用法，而這幾乎是無限使用的。我想人們不理解企業也是要賺錢的，我們得實現盈利，在算力需求如此巨大的時候，不能白送。
Anthropic 有 5 個 PM 團隊，所有角色都在融合
Lenny： 回到 PM 團隊，Anthropic 的 PM 團隊是什麼樣的？有多少人？是怎麼組織的？
Cat Wu： 我們有幾個 PM 團隊，目前大概有 30 到 40 名 PM。Diane 領導研究 PM 團隊，負責收集客戶對模型的回饋並傳達給研究團隊，同時也負責模型發布。還有 Claude 開發者平台團隊，維護著 Claude Code 所基於的 API，並發布像「託管智能體」（Managed Agents）之類的產品。然後是 Claude Code 團隊。還有企業團隊，負責讓企業客戶更容易採用這些工具，包括成本控制、RBAC、安全控制等。最後我們還有增長團隊，負責整個產品線的增長。
Lenny： 提到增長，Amole 之前上 Podcast 時提到了一個很有趣的觀點：大家總覺得未來需要的 PM 會變少，工程師直接幹就行；但他認為因為工程師跑得太快了，PM 和設計師反而被擠壓了，沒時間跟上所有的變化。所以他認為他需要更多的 PM，因為太難跟上了。你怎麼看？你覺得 PM 的招聘會增加嗎？長期來看這個職業會發生什麼？
Cat Wu： 我認為所有的角色都在融合。PM 在做工程工作，工程師在做 PM 的活，設計師在做產品管理並提交程式碼。你要麼招聘更多具有優秀產品品味的工程師，要麼保持工程師招聘人數不變，多招 PM 來指導工作。在我們的團隊中，我們非常專注於招聘具有優秀產品品味的工程師，這樣可以減少發布產品的溝通成本。我們團隊很多工程師完全有能力端到端地處理：從 Twitter 上看到使用者回饋，到週末就把產品發出來，幾乎不需要產品經理介入。我認為這是最有效率的方式。所以工程師和 PM 的界限在重疊。
我認為產品品味仍然是一種非常稀缺的技能，只要我們覺得某人展現出了這種能力，我們幾乎都會錄用。
Lenny： 你的背景是工程對吧？
Cat Wu： 是的，我做了很多年工程師，在加入 Anthropic 之前短暫做過 VC。實際上我們團隊幾乎所有的 PM 之前都是工程師，或者會在 Claude Code 提交程式碼。這有助於建立團隊信任，讓我們跑得更快。甚至我們的設計師之前也是前端工程師。
最有價值的核心技能：產品品味
Lenny： 這是一個大問題。既然界限在融合，如果你來自工程、產品或設計背景，哪種核心技能最值錢？
Cat Wu： 我仍然認為歸根結柢是產品品味。隨著程式碼編寫成本降低，更有價值的是決定「寫什麼」。什麼是正確的設計（UX）？使用者體驗最愉悅的方式是什麼？我們收到成千上萬個 GitHub Issue 要求各種功能，需要極大的耐心和品味去弄清楚：哪一個值得做？正確的做法是什麼？這種技能可以來自任何背景。
之所以工程背景在接下來的幾個月裡特別有用，是因為如果你懂工程，你能更好地感覺到某件事的難度。這通常是決定構建什麼的重要因素。如果某件事非常容易做，那麼與其爭論，不如直接花一個小時把它做出來。
但如果某些東西構建起來更難，你提前知道這一點，你就會明白，好，對於我們的團隊來說，把這個功能推向市場將耗費更多的成本。所以這在優先級排序上會有一些幫助。
Lenny： 你說「在接下來的幾個月裡」，是因為模型在未來幾個月可能會變得非常出色，以至於你甚至不需要了解那麼多工程知識嗎？
Cat Wu： 我認為有價值的技能集變化確實非常頻繁，所以很難預測幾個月後的情況。所以這與其說是對我認為將發生何種轉變的評論，不如說是對我認為將發生重大轉變的評論。
Lenny： 所以你並不是說那是 Mythos 發布的時候，它會改變一切，讓我們不需要了解任何工程知識？
Cat Wu： 不，我只是說每隔幾個月，編碼能力似乎就會大幅提升，這隨後會改變其他角色的價值。
Cat Wu： 我認為最重要的事情是能夠擁有這種「第一性原理」思考，你能弄清楚技術格局是如何變化的，團隊真正需要你做什麼，並投入進去填補那個空缺。因為我認為工作正變得越來越模糊，這意味著一個優秀的產品經理（PM）能夠理解所有的差距在哪裡，弄清楚哪些是最高優先級的，然後想辦法學習那個技能，或者思考我擁有的哪些技能可以應用到這個挑戰中。所以我認為當前的環境看重那些能夠承擔多種職責、能夠靈活切換角色、並且對於為了幫助團隊跑得更快而去做任何工作都保持低姿態的人。
人類仍具有模型不具備的常識
Lenny： 我很喜歡這個答案。我一直在問那些處於你這種位置的人，即處於 AI 能力最前沿、使用最新工具構建產品的人，一個問題：在通往超級智能的過程中，人類大腦在哪些方面會持續發揮作用且不可或缺？我在這裡聽到的是，本質上是選擇要開發的東西，了解市場的走向，並弄清楚優先級。然後是判斷你構建的東西是否優秀和正確，並至少以某種早期版本將其推向市場。聽起來對嗎？在至少接下來的幾個月裡，人類大腦還有哪些地方是有用的？
Cat Wu： 我認為人類仍然具有一種模型所不具備的常識水準。任何產品的發布都有上千個移動的環節，其中一些很小，但總是有很多潛在的出錯可能。我認為模型並不總是能很好地感知誰是所有的利益相關者，他們彼此之間的關係如何，他們的偏好是什麼，以及與他們溝通並保持一致的正確場所有哪些。我認為很多這種更隱性的常識，比如情商（EQ）之類的知識，仍然非常有價值。當然，我們希望模型在這方面變得更好，我認為它們會變得更好，但現在我認為仍有差距。
Anthropic 團隊的共同特質：淡定且樂觀
Lenny： 作為人類，身處這場持續不斷的變革龍捲風中心，你如何應對？也許那裡很平靜，但你如何掌握正在發生的事情？在這場瘋狂的進程中，你如何保持清醒？
Cat Wu： 我認為我們的團隊充滿了樂於擁抱混沌的人。所以，我們嘗試微笑著面對每一個挑戰，因為總是有太多的事情在發生。總是有那麼多的風險和棘手的情況，你知道如果你對任何事情過於緊張，你就會精疲力竭。所以我們尋找那些能夠直面挑戰並心想「這會很難，但我很興奮去解決它，我會盡我所能，我知道我不會做到完美，但我能安然入眠，因為我知道我盡力了」的人。
Lenny： 這是一個關於未來哪些技能重要的有趣回答。我忘了是誰說的，也許是 Ben Evans，他說這是這個世界有史以來最正常的時刻了。
Cat Wu： 是的，它肯定會變得越來越難。我覺得有好多個星期，可能週日晚上有一個 P0 級任務，到週一又有另一個 P0，到週一下午又冒出一個 P0000 級任務，你會感嘆：哇，真不敢相信我之前竟然那麼擔心週日那個 P0。但你必須承認，你所能做的只有這麼多，你需要睡個好覺，這樣隔天才能做出好的決定，並且對你的時間分配進行極其嚴苛的優先級排序。什麼才是最重要且必須做對的事情？並且要接受放手。比如我們發布的一些產品並沒有我希望的那麼考究，但你知道，我們的最高目標是賦予專業開發者力量。如果一個產品不那麼成功，只要它沒有阻塞核心用例，那就沒關係，因為我們會聽到回饋並在下一個版本中修復它。發布一個有 Bug 的功能曾經是那種會讓我徹夜難眠的事情，但現在我已經能夠接受它了，因為我知道我們會得到快速的回饋，並在下個版本中修復。
Lenny： 我腦海中的畫面是那個 GIF，大概是《神鬼奇航》裡的，一個男人走下船的樓梯，整艘船在他周圍崩塌，而他非常淡定，只是漫步走下樓梯，即使一切都在瓦解。這很有趣，因為我遇到的每個來自 Anthropic 的人都非常淡定且樂觀。
Cat Wu： 是的，我認為這是一個非常有趣的洞察，即保持這種冷靜和樂觀，而不是心想「天哪，一切都瘋了」。如果你不具備這一點，你會很快精疲力竭。我認為我們也傾向於雇傭那些已經在業界待了一段時間、經歷過很多起伏、並且很清楚什麼能給他們帶來能量以及如何長期維持能量的人，我認為這幫了我們很多。
使用者很難跟上 AI 產品的最新進展，需要工具引導
Lenny： 很有趣。我想問的是關於角色模糊的問題。工程師變成 PM，貓變成狗，每個人都變成了其他人。在這個世界裡我們失去了什麼？我們是否失去了職業階梯和清晰的職業路徑？我們是否失去了設計的一致性或者程式碼品質？你知道，可能有一些弊端。你發現哪些東西是為了更大的利益而犧牲掉的？
Cat Wu： 我們正在犧牲產品的一致性。在過去，當編寫程式碼的成本很高時，你會仔細規劃產品套件中的每一件事，每個產品如何關聯，每一個產品的用例是什麼，它們如何整合，而且每個用例基本上只有一個產品。現在隨著 AI 發展如此迅速，有這麼多想法需要測試，我們有時確實會有功能重疊。很多時候是因為內部有兩種我們都喜歡的表現形式，我們想讓外部使用者告訴我們哪一種更好。但對於新使用者來說，這意味著他可能不知道完成某項任務的最佳路徑是什麼。我們需要做更多的教育工作，幫助人們理解核心功能是什麼，以及使用它們的最佳實務是什麼。我認為這是發布大量功能的代價。使用者也會覺得很難跟上最新的進展。通常在傳統的 PM 模式下，你每個月或每季發布一個功能，使用者很容易理解「我只需要每月查看一次，學習一些新東西，即使我忽略它六個月也沒關係，不會覺得錯過了什麼」。我認為對於這些智能體工具，不僅是 Claude Code 和 Cowork，而是整個生態系統，人們覺得需要每天刷 Twitter 看看最新的東西是什麼。
Cat Wu： 沒錯。我們也看到他們在不斷突破 Cowork 的能力天花板。舉例來說，這些人通常要同時對接好幾個客戶，忙起來一天可能有 5 到 10 場客戶會議。他們常常在前一天晚上用 Cowork 整理摘要：明天有哪些會議？客戶提出了哪些需求？目前最迫切需要解決的是什麼？過去會議的待辦事項有哪些？Cowork 會直接彙整成一份卷宗，讓他們在下一場會議前能快速掌握的簡報。Cowork 甚至能主動查找答案，比如客戶問「X 功能什麼時候上線」，Cowork 會翻遍 Slack 找出最新的預計上線時間（ETA）並加進筆記裡。這些都是同仁為自己打造、後來分享給整個團隊的自動化工作流程。
Anthropic 同仁的 Token 用量其實也是有上限的
Lenny： 酷。最近有個很常被討論的話題：Token 花費竟然超過員工薪水，也就是大家用起 AI 的成本比自己的薪水還高。Anthropic 內部有沒有關於工程師或 PM 每天、每月消耗多少 Token 的數據？
Cat Wu： 很明顯，隨著模型越做越好，人們會把更多任務交給它，在工具上花的時間也更長。所以每次遇到模型跨代或產品有重大進展時，單一知識工作者的 Token 成本確實會攀升。我認為目前這個成本還遠低於工程師的平均薪資，但這個比例正隨著時間逐步增加。
Lenny： 在 Anthropic 工作的好處之一，就是你們有幾乎用不完的 Token 額度，可以盡情揮霍，對吧？
Cat Wu： 我們確實可以用到很多 Token，但有些人還是會碰到用量上限。
Lenny： 竟然有上限！好吧，Boris（Anthropic 共同創辦人），把它關掉啦！
Cat Wu： 因為掌握最先進模型所帶來的「飛輪效應」真的很有趣。我們非常相信要賦予內部團隊用最快速度打造產品的能力。我們也相信每個人都理解提供這些模型服務的真實成本，我們信任團隊會負責任地使用 Token。浪費 Token 是會被鄙視的，但我們信任每個人能做出自己的判斷。
AI 時代 PM 最難的技能：定義下一代產品
Lenny： 回到 PM 的角色。你認為在當今的 AI 公司招聘 PM 時，哪些是正在浮現、PM 需要刻意培養的技能？或者你最看重什麼？
Cat Wu： 我認為最難的技能是能夠定義「一個月後產品應該長什麼樣」。在目前的時間軸下，模型能做到什麼、用戶行為會發生什麼變化，都存在極大的模糊性。但最頂尖的 PM 能夠透過觀察用戶如何挑戰現有產品的極限，從而感知到某種模式。他們能設定方向並穩健地執行，如果模型能力的提升超乎預期或不如預期，他們也能隨時調整路徑。
我認為，要成為一個「恰到好處」的 AGI 信徒（AGI pilled）其實很難。每個人都能預見到那個模型極其聰明、無所不能的未來，到那時候你甚至不需要太複雜的產品，只要一個對話框告訴模型你想要什麼就行了。它聰明到可以自己添加任何工具或整合來完成任務，知道什麼時候該感到不確定，什麼時候該提問。
為那種「超級強大的 AGI」打造產品其實很容易。難的是如何針對「當前的模型」，搞清楚如何激發它的最大潛能？如何幫助用戶走上那條「黃金路徑」？如何引導用戶善用模型的優勢並修補它的弱點？這種技能目前非常稀有。
技能培養方法：與模型大量對話、找出「有品味」的用戶、建立「評估集」
Lenny： 那麼該如何培養這種技能呢？是單純透過大量使用模型，理解每個模型的極限，培養對模型能力的「品味」嗎？
Cat Wu： 我認為關鍵就是投入大量、大量時間與模型對話並使用它。
我非常喜歡做的一件事就是讓模型反思自己的行為。有時候當我注意到模型做了意想不到的事，比如在某些情況下，模型改了前端程式碼並跑了測試，但實際上根本沒用到使用者介面（UI），這時候去問模型為什麼這麼做其實非常有用。
有時候它們會回答說：「嘿，系統提示詞（system prompt）裡有些讓人困惑的內容」，或者「我沒意識到前端驗證是這項任務的一環」，或者「嘿，我把驗證委派給這個子代理，但子代理沒做測試，我也沒檢查它的工作」。很多時候，只要你對模型做決策的原因保持好奇心，它就會向你展示是什麼誤導了它，讓你能夠修復 Harness 來彌補這個缺陷。
另一件有幫助的事是找出誰是那種「有品味」的用戶，也就是你最信任、能給你最精準模型回饋的人。通常總有那麼幾個人比其他人更會表達，是什麼讓特定的模型、或是「模型與Harness的組合」變得優秀。
很多人都會給你回饋，但並非每個人的回饋都具備同等的參考價值。因此，找到一個你信任的「五人核心小組」是獲得快速回饋的關鍵。我認為第三件有用，但並非每個人都喜歡做的事就是建立「評估集（evals）」。
你並不需要建構成百上千個評估集才能看到效果。哪怕只建立 10 個優秀的評估集，對於協助團隊量化目標、掌握進度，以及發現缺失點都非常重要。所以，我覺得評估集是一件被低估的事情，更多產品經理（PM）和工程師應該投入其中。
Lenny： 我們已經聊過很多次評估集了。現在有一種趨勢，認為產品管理的未來就是撰寫評估集，因為它本質上就是在定義「成功長什麼樣子」。好，這太酷了，讓我具體定義成功，然後我們就心裡有譜了。你大概把多少時間花在編寫評估集上？
Cat Wu： 我認為評估集的重要性取決於你正在開發的功能，或者你試圖解決的問題。我們團隊中確實有很多人把大量時間花在評估集上。我們有一個小小組，與研究部門緊密合作，目標是更精準地理解 Claude Code 的行為，找出最大的進步空間，並嘗試進行具體的衡量。
當某個功能我認為需要更多產品定義時，我會親自參與評估。通常產出會像這樣：「好，這是我做的五個評估集，這是運行它們的方法，這些是成功的，這些是失敗的，這是我用來提高成功率的提示詞。」這要看具體的功能，不是每個功能都需要，但我認為像「記憶」這類功能會從中獲益良多。
擅長評估模型的人：Claude 性格塑造者和 Claude Code 團隊
Lenny： 你提到有些人非常擅長評估模型，這很有意思。這幾乎像是一種「人為評估」，他們能理解哪裡正在大幅成長，哪裡可能資源匱乏。有誰是你特別想點出來、而且非常擅長這件事的嗎？
Cat Wu： 我認為有兩個人在這方面簡直不可思議。一位是 Amanda，她塑造了 Claude 的性格。這實在是個非常艱難的職位，因為任務極度模糊。甚至寫程式都相對容易，因為你可以驗證成功與否，而塑造性格需要對自己堅信 Claude 應該成為什麼樣子抱有極強的信念。
我認為她不僅擁有塑造性格的驚人能耐，還非常擅長表達目標是什麼、性格是什麼、什麼算成功、什麼不算。另一組我非常信賴的人就是 Claude Code 團隊。我們常有團隊午餐，每次測試新模型時，獲得回饋最快的方法之一，就是在午餐會上走向每一個人，問他們：「嘿，你對這個模型的『氛圍感（vibe）』有什麼看法？」
通常我們會聽到這樣的回饋：「好吧，這個模型太突兀了，沒有充分解釋它的思考過程」；或者「嘿，這個模型很愛寫一大堆記憶，但我們不確定這些記憶的品質高不高」；也有些人會注意到，「好吧，這個模型喜歡自己測試，這很棒」；或者「這個模型自己測試得不夠」。這些回饋告訴我們該查看哪些數據，來驗證這是不是一個更廣泛的模式。我們擁有海量數據，但從中提取見解非常困難，所以這組人的回饋幫我們確定了想要測試的假設，然後我們就能提取數據進行驗證。
Claude 的性格讓合作變得更愉快
Lenny： 你剛剛提到關於 Claude 性格的那點，我之前邀請過共同創辦人 Ben Mann 上節目，他也聊過這個。Claude 的性格、它的「憲章（constitution）」是 Claude 如此重要的組成部分。我算是後知後覺才意識到，比如 OpenClaw（開源版本），人們會感到難過的原因之一，正是 Claude 的性格太棒了，既有趣又引人入勝，不像其他模型。就像他說的，性格是讓 Claude 在這麼多事情上表現出色的核心。聽起來可能像個微不足道的小事：「喔，它很有趣，說話方式很好玩」；但它確實是 Claude 成功的關鍵。對於人們可能不理解為何性格和個性如此關鍵，你有什麼想法嗎？
Cat Wu： 回顧你合作過的每一個人，總有些人會讓你覺得：「我真的好喜歡他們的能量，好喜歡他們的氛圍」。當人們想到 Claude 和 Claude Code 時，這是他們最常提到的一點，他們真的很喜歡 Claude 那種輕鬆愉快又風趣的特質。但同時，它在處理你的任務時又極其稱職。
人們也很欣賞 Claude 的「低自尊（low ego）」。如果你告訴它：「嘿，你這部分做錯了。」它會真誠道歉說：「噢，天啊，謝謝你告訴我。讓我來把它修好。我們一起合作吧。」它也非常積極。如果你覺得：「噢，這根本是個不可能的任務，我不知道該怎麼起步。」Claude 會說：「好，沒關係。我認為我們該採取這些步驟。你要我幫你起個頭嗎？」我認為一個優秀同事的部份魅力，就在於這種積極性、這種行動導向，以及給予你坦率回饋的能力，而不僅僅是附和。我們試著將這些特質注入到 Claude 身上，因為這讓合作過程愉快許多。
新模型迫使產品變革：移除不再需要的功能
Lenny： 我想回頭來聊聊。你提到新模型發佈時，你經常得重新審視已經建好的東西。這點太有意思了，但也可能讓人有點挫折，像是「可惡，我們才剛發佈這個，現在又得重新思考它」。談談你帶著新模型回頭檢視的頻率。
Cat Wu： 我們因應新模型所做的許多改變，其實是移除不再需要的功能。很多時候，我們在產品中加入功能，是作為模型的「枴杖」，因為它本來沒辦法自然地完成任務。最經典的例子就是「待辦事項清單（to-do list）」。
我們剛發佈 Claude Code 的時候，人們會叫它進行大規模重構，Claude Code 會說：「好，酷。我需要更改這 20 個呼叫點」，然後它改了 5 個就停下來了。我們就想：「好，我們該怎麼強迫它記住要把這 20 個全部改完？」
我們團隊的 Sid 說：「好，如果我們想想人類會怎麼做呢？人類會列一張清單。就像在 VS Code 裡面，你會搜尋所有呼叫點，它們會顯示在左側，然後你一個一個去取代。」所以他加了待辦事項清單的功能，我們發現有了它，Claude 確實能把所有 20 個呼叫點都修完。
但到了 Opus 4 及之後的模型，我們發現不再需要強迫它用這張清單了。它會很自然地使用清單。對早期的模型，我們必須不斷提醒它：「嘿，你的待辦事項清單完成了沒？沒做完不能結束喔。」但對後來的模型，根本不需要提示，它就會很自然地想到要把所有事情完成。如今，待辦事項清單對使用者來說還是不錯的，因為你可以看清 Claude 正在忙什麼，但老實說，它現在已經是個被弱化的功能了。
Lenny： 我忘了誰在節目上說過，「模型會把你的 Harness 當早餐吃掉」。我聽到的意思是，隨著模型變聰明，你會把那些因為模型表現不佳而不得不加進去的東西移除掉，一切變得越來越簡單。
Cat Wu： 是的。每當模型變得更聰明，我們就能移除大量的提示詞干預。每次發佈模型時，我們都會完整讀過整個系統提示詞，並反思：以模型現在的能力，這些部分真的還需要這些提醒嗎？如果不需要，我們就移除掉。不過，新模型解鎖的最令人興奮的事，是帶來全新的功能。
有很多功能，我們明明在先前的模型上測試過了，但準確率就是不夠高。比如程式碼審查（code review）。我們試過幾次，過去也發佈過簡單的 /codereview 指令，但直到最近的模型，我們才覺得這個功能已經好到，讓我們的工程團隊在合併 PR 之前都依賴它來通過審查。直到 Opus 4.5 和 4.6，我們才有信心能同時運行好幾個程式碼審查 Agent，讓它們遍歷整個程式碼庫，並綜合出工程師需要解決的真實問題。
Lenny： 這是本節目另一個常見的趨勢：去打造一些在未來六個月內可能成真的事物，就處於「快要可行」的邊緣，然後模型追趕上來，它就會變成一個超棒的產品。
Cat Wu： 沒錯，正是如此。打造一些現在不一定跑得動的產品非常重要，這樣你才能知道還欠缺什麼，然後當最新的模型一出來，你就可以直接把新模型放進原型中替換掉。
Claude Code 和 Cowork 的願景：為大量平行任務打造基礎設施
Lenny： 關於 Claude 和 Cowork 的長期願景，你能透露多少？
Cat Wu： 我們是從「建構組件（building blocks）」的角度來思考的。核心組件是讓單一任務成功：你給它一段描述，它能不能持續地產出可被接受的成果？隨著模型變聰明，任務成功率會隨之提高。然後我們看到人們開始同時處理多個任務。「多重編碼（multi-coding）」在 2025 年底成為趨勢，而且一直在成長。
我們的推演是這樣的：好，現在你可以一次處理 6 個任務。當模型變得更加聰明，也許你會一次運行 50 個，甚至成百上千個 Claude。那麼我們需要建構什麼樣的基礎設施？到那時候，你可能就不會在本地機器上運作了，記憶體根本不夠用。所以我們正在思考，如何讓你更容易管理這些遠端執行的任務。我們該如何建構介面，讓你知道哪些需要介入？要如何確保 Agent 充分驗證了工作成果，以至於當你看到「已完成」狀態時，你可以完全信賴它？
找出重複性工作交給 AI，100% 有效才是真正的自動化
Lenny： 對於那些擔心自己未來職涯的產品經理、創辦人或其他跨職能角色，你有什麼建議，讓他們不僅能度過這個轉型期，還能大放異彩？
Cat Wu： 我認為 AI 給了每個人比以往更多的槓桿。我的建議是：每當你發現自己又在重複做手動任務時，就想辦法用 AI 工具幫你自動化。工作中總有你熱愛的創意部分，以及你討厭的繁瑣部分。AI 美妙的地方就在於，它能為你處理那些雜務，它能學習、總結並自動執行，讓你專注在創意上。
我最直接的建議是：找出那些可以交給 Claude 的重複性工作。在這些自動化流程上不斷迭代，直到成功率變得非常高，然後專注在：你還可以為團隊或公司做些什麼，是之前沒心力去碰的事？
Lenny： 核心建議其實就是「為自己解決一個問題」。
Cat Wu： 沒錯。我也會促使聽眾，將自動化從「很酷的概念」提升到「100% 成功」。有時候我看到用戶把準確率做到 90-95% 就放棄了。但假如一個自動化不是 100% 有效，它就不是真正的自動化。最後那 5-10% 的提升確實需要投入更多時間，打造它可能比你自己手動做還慢。但我鼓勵你投入心力，教會 Claude 你的偏好，讓它達到 100%，然後你才能真正依賴它。95% 的自動化其實沒什麼價值。
Lenny： 我對這點深感慚愧。
Cat Wu： 我也有同感。我一直試著教 Cowork 幫我清理 Gmail 的收件匣。這非常耗時，而且它顯然還沒達到我理想中的樣子。
Lenny： 有意思，我也設定了一個自動分類垃圾郵件的工作流程，95% 的時候都超棒，但接著：「噢，哇，我漏了一封信，因為它被歸錯地方了。」這對我來說是個動力：我會把它做到完美。
Cat Wu： 我們也正致力於讓自訂流程變得更無縫，這樣就不會覺得做起來很痛苦。
用 AI 打造那些你每天都用的應用程式
Lenny： Cat，在進入閃電問答環節之前，還有什麼想分享的嗎？
Cat Wu： 我看到很多人在玩 AI，打造一些原型應用。我極力推動大家，要去打造你每天都在用的應用程式。如果只是「哦，我一鍵搞定了某個東西，太酷了」，然後就再也沒碰它，你其實學不到什麼，也沒獲得多少實際的槓桿效果。
Lenny： 說得沒錯。我也覺得有些人花了太多時間在自訂工作流程上，光譜的兩端分別是：從不自訂的人，和像強迫症一樣沉迷於優化設定、加了一大堆技能，但其實沒在打造核心產品的人。
我發現越簡單的設定效果其實越好。Karpathy 昨天發了條推文談到這個鴻溝：有些人早先試了 AI 覺得不行就放棄了；而另一群用它來寫程式的人，看到了它極致的強大。兩邊的人都無法理解彼此。你的建議非常好：把它用在真實的事情上。
Cat Wu： 那個巨大的轉變在於，2024 年那一代的產品是對話式的，而 Claude Code 這一代是基於行動的（action-based）。那個「啊哈！原來如此」的時刻，是發生在 Agent 真的能代你執行動作的時候。那是一種很奇妙的感覺。
Lenny： 一定要給 Claude Code 的 Chrome 擴充功能一個好評，你可以看著它自動填寫表單，整個過程超療癒的。
眼下最迫切的是幫助世界跟上 AI 的腳步
Lenny： 在工作或生活中，有沒有哪句座右銘是你常常想起來的？
Cat Wu： 「做就對了（Just do things）」。我認為「第一性原理」思考很有價值。如果你很清楚自己在優化什麼，你就能推導出正確的行動方針，然後你就該去做。我認為「工作崗位（jobs）」是虛構的。只要你能理解限制條件，你就能搞清楚自己能做什麼，然後盡快動手，從錯誤中學習。
Lenny： 告訴人們這點真的讓人感到解脫。在很多公司，角色被定義得非常死。「做就對了」這種心態讓人感覺充滿力量。
Cat Wu： 這也是我大力推薦去新創公司工作的頭號理由。在 Scale AI 還只有 20 個人的時候加入，那段經歷對我來說是改變人生的。當時根本沒什麼流程，Alex（創辦人）賦予我們自己去搞定事情的力量，不管是要做銷售還是做工程，總之就是動用一切手段去解決問題。
Lenny： 好，最後一個問題。我也問過 Boris：隨著通用人工智慧（AGI）可能在我們有生之年到來，當你可能不再需要工作時，你會做些什麼？你會如何打發所有的空閒時間？
Cat：我覺得 AGI 要滲透到整個社會，還需要很長一段時間。所以，眼下最迫切的事情，其實是幫助世界跟上腳步。至於之後要做什麼的非正式答案嘛，我大概會去瘋狂攀岩。我應該會搬到法國楓丹白露（Fontainebleau）之類的地方，住在上萬顆巨石之間，在那邊爬上好一陣子。
還有好多書想讀，我給自己訂的目標是每週讀一到兩本，但現在大概只能讀個 0.5 本。待讀書單積壓得相當可觀。我覺得歷史中有太多值得我們學習的東西，也有太多我渴望了解卻還不夠明白的事。舉例來說，我對物理、機器人、硬體、航太這些領域完全一竅不通，有趣的領域實在太多了。所以，即使知道 AI 已經掌握了這些知識，我還是會很興奮地去學習它。
Lenny： Cat，非常感謝你今天來和我們聊這麼多。
Cat： 謝謝邀請我。大家再見。
參考連結：