Claude產品經理Lenny播客全文精譯

開場
我認為，要找到“恰到好處的 AGI 信仰”非常難。給一個超級強、接近 AGI 的模型做產品，其實很容易；真正困難的是，在當前模型能力下，如何把它的最大潛力真正激發出來。
我從來沒見過你們在 Anthropic 這樣的發布速度。
我們想把發布路上的每一個障礙都拿掉。很多產品功能的周期，已經從 6 個月縮短到 1 個月，有時甚至只要 1 天。你們采訪了幾百位 PM，我總覺得很多人對這個角色的理解方式還是不對。
PM 這個崗位正在快速變化。對 AI 原生產品來說，最重要的是極快地迭代，想辦法讓功能真的做到每周都能上線。
那么你覺得，PM 現在最需要培養的新能力是什么？
這還是回到“產品品味”上。隨著寫代碼變得越來越便宜，真正更有價值的，是決定寫什么。
今天的嘉賓是 Cat Woo，Anthropic 里 Claude Code 和 co-work 的產品負責人。Cat 站在 AI、產品和構建方式變化的中心位置，她和團隊正在打造一種最能改變我們構建產品方式的產品。她有很多洞見、經驗和判斷。你絕對不能錯過這期節目。

你在 Anthropic 的角色
Lenny： 我有太多問題了，非常高興你來做客。先從你的角色說起，尤其是你和 Boris 的分工。大家都知道 Boris。他那期節目是這檔播客里最受歡迎的一期。沒壓力哈。他創造了 Claude Code，帶隊工作，還能從手機上每天發出成堆的 PR。我現在都不知道具體數字了。
我覺得很多人低估了你對 Claude Code、co-work，以及你們正在做的所有東西的貢獻。你幫大家理解一下：你在團隊里到底做什么？你怎么和 Boris 協作？你們怎么分工？Claude Code 團隊里的 PM 角色到底長什么樣？
Cat： 我覺得自己很幸運能和 Boris 一起工作。他是非常棒的思考伙伴，也是我們的技術負責人。他很強的一點，是能非常清楚地描繪出產品在 3 個月、6 個月后應該是什么樣子，也就是這個產品未來的“AGI 版”應該長什么樣。
我的很多工作，就是去想：從今天的位置出發，怎么走到那個 3 到 6 個月后的愿景。與此同時，我花更多時間在跨團隊協同上，確保市場、銷售、財務、算力等團隊都真正認同這個計劃，大家朝同一個方向劃船，并且在功能準備好時，沒有任何阻礙上線的因素。
我覺得這套分工之所以有效，是因為我們在很多問題上幾乎“心靈合一”，但邊界其實又相當模糊。大概 80% 的事情我們是共同決定的，剩下 20% 的事情里，有些我更在意，我就會去推進；另一些他更在意，他就會直接負責。

為什么 AI 時代的 PM 角色變了
Lenny： 你之前跟我說過，你經常面試成百上千位 PM。如果我每次聽到有人讓我介紹 Anthropic 的人、想去 Anthropic 做 PM，我都能拿到一筆“分成”，那我大概已經有 300 億 ARR 了。
Anthropic 現在就是大家最想去工作的地方。所以我完全能想象你面試了多少 PM。你說你經?？吹接腥税堰@件事理解錯了，理解成了他們以為做一個成功的 AI 產品 PM 需要的方式。你能說說你看到了什么，以及現在想要成功到底需要理解什么嗎？
Cat： 在 AI 出現之前，技術變化慢得多，所以你可以按 6 到 12 個月的時間尺度來規劃。因為功能發布速度比較慢，所以大家更強調和其他協作團隊配合，確保他們先把能解鎖你功能的部分做出來。那時候代碼很貴，制造能力也慢。
現在有了 AI，再加上工程速度被極大加速，模型能力也在快速進步，很多產品功能的周期從 6 個月縮短到 1 個月，有時甚至一周，甚至一天。也就是說，產品真的必須非?？斓匕l布。
這意味著，作為 PM，應該少把重點放在讓多季度路線圖和合作團隊對齊上，而應該更多思考：怎么最快把東西推到線上？怎么做一個產品角落，讓工程師或 PM 有了想法后，到了周末前就能把東西交到用戶手里？
我覺得，在 AI 原生產品上表現最好的 PM，都是那些能把“從想法到用戶手里”的時間盡量壓縮的人，并且他們能定義清楚，這個產品最重要的、必須開箱即用的任務是什么。
Lenny： 我喜歡你這一點。你的意思就是，很多人還沒真正意識到自己需要多快移動，以及這份工作的很大一部分，其實就是推動團隊加速。那到底是什么在幫助這件事發生？你們 PM 團隊是怎么讓大家跑這么快的？當然，前提是能用到最先進的模型。
Cat： 第一件事，是設定清晰、明確的目標。因為 LLM 太通用了，反而會讓“我們在為誰做、我們要解決什么問題、最重要的使用場景是什么”變得很模糊。
所以一個優秀的 PM 能說清楚：我們的關鍵用戶是專業開發者；這個功能要解決的核心問題，可能是權限提示太多，讓人產生疲勞；我們希望讓企業里的專業開發者在安全前提下，把權限提示降到零。這樣一來，就能把很多可能的方案排除掉，讓團隊更聚焦地往一個明確方向做，幫助用戶只用一次提示就完成更多工作。
第二件非常重要的事，是建立一個可重復的發布流程。比如在 Claude Code 里，我們幾乎所有功能都會先以 research preview 的形式發布。我們會明確標注，這還是早期產品，只是一個想法，只是想收集反饋并持續迭代，它不一定會永久支持。
這樣做能降低我們發布功能時的承諾壓力。我們可以在一兩周內先把東西發出去。
第三件事，是 PM 要幫團隊建立一套工作框架，讓大家知道什么時候該拉上跨職能伙伴，以及這些伙伴的預期是什么。比如我們工程、市場和文檔之間的流程就非常緊密。工程師覺得某個功能準備好了，而且我們內部已經自己用過之后，就會把它發到我們的 evergreen launch room。然后負責文檔的 Sarah、負責 PMM 的 Alex，以及 Devril 里的 Tar 和 Lydia，會立刻跟進，第二天就能把營銷公告轉出來。
因為有了這套非常緊密的流程，工程師發布東西的阻力就小很多，而 PM 的職責就是把這種機制搭起來。

PRD 現在還重要嗎
Lenny： 那 PRD 在這里扮演什么角色？你剛才說“目標”很重要，關鍵是對成功標準達成一致——這東西是給誰用的？不是給誰用的？你還在寫 PRD 嗎？還是只寫幾條要點？在 AI 時代，這種東西怎么演化？
Cat： 我們主要做兩件事。
第一，我們有非常嚴格的指標體系，每周都會和整個團隊一起做 metrics readout。目的是讓每個人都真正理解業務的各個方面：我們的關鍵目標是什么，趨勢如何，驅動因素是什么。
第二，我們會維護一份團隊原則清單。這份清單包括我們的核心用戶是誰，以及為什么他們是核心用戶。我們把這些寫清楚，是希望團隊里的每個人都理解業務是怎么運作的，理解什么對我們重要，也理解我們愿意做哪些取舍。
這樣大家就可以自己做判斷，而不必總卡在 PM 或其他利益相關方那里。
Lenny： 我很喜歡這一點，因為這說明“未來還是需要 PM”。外界總有人在說：為什么還需要 PM？我們直接 ship、直接 build 就好了，我們只需要工程師。
Cat： 其實我們會在某些情況下寫 PRD。對于特別模糊的功能，寫一頁紙還是很有幫助的，寫清楚目標是什么、哪些是令人愉快的使用場景、當前有哪些失敗模式需要修復。
而且有些項目，尤其是需要重基礎設施的項目，確實會持續很多個月。那種情況下，我們還是會寫 PRD。

為什么 Anthropic 能這么快
Lenny： 我想再深入一點，了解你們為什么能這么快。我從來沒見過 Anthropic 這樣的發布速度。有人做了一個 Anthropic 發布日歷，結果幾乎每天都有一個重大功能或產品上線。
所以有個大家在網上問的問題是：你們剛剛發布的那個非常強的模型 Mythos 還處于 preview，因為太強了，大家有點擔心它的能力。你們內部是不是在用它？這是不是你們能這么快推進的原因之一？
Cat： 我們其實已經連續好幾個季度都很快了，所以這不完全是 Mythos 的功勞。Mythos 確實是一個極強的模型。我們內部也會使用這些模型，這確實讓我們的發布速度更快了一點，但我不認為這能解釋增長的大頭。
我覺得很大一部分原因在于流程和團隊預期。我們的流程很輕。我們希望移除一切會阻礙發布的東西。我們希望讓團隊里每個人都能感到自己有權把一個想法，從純想法變成真實出現在世界里的東西，少則一周，多則一天。
Lenny： 哇，這真是太厲害了。既有最好的模型，又在做產品本身。太酷了。
Cat： 我們非常幸運，能和最前沿的模型一起工作。
Lenny： 這優勢真的太大了。就是造一個東西，然后自己馬上用起來，再進一步加速。

關于 Claude Code 源碼泄露
Lenny： 還有幾個我想單獨聊的話題。Anthropic 這邊最近事情很多，我真的很想聽聽你的看法。一個是，大概一周前，Claude Code 的完整源代碼泄露了。有人把它放到了網上。我覺得那是某個人犯了錯誤。你能說說發生了什么、哪里出了問題、大家應該知道什么嗎？
Cat： 我們一看到這件事就立刻去查了。結果發現，這是人為錯誤造成的。是有一位同事在用 Claude 寫 PR，這其實只是一次包發布方式的更新，而且這件事還經過了兩層人工審核。
所以這次確實是人為失誤。我們已經加固了流程，確保以后不會再發生。
Lenny： 那個人現在還在 Anthropic 嗎？他們現在還做得好嗎？
Cat： 是的，是的。這是一個流程失敗，最重要的是從中學習，并增加更多防護措施，避免再次發生。我們現在的重點就是這個，而且大部分改進都已經上線了。

關于 Open Claude / Open Claude 訂閱限制
Lenny： 另一個問題是 Open Claude。最近有個動作，是不再允許大家把 Claude 訂閱拿去給自己的 open clause 用。很多人很不開心，不明白為什么這么做。他們覺得這對開源社區造成了傷害。大家應該怎么理解這個決定？
Cat： 我們看到 Claude 的需求非常大，所以一直在努力擴展基礎設施，同時讓我們的 harness 更加 token efficient，這樣用戶能獲得更多使用量。
不過，第三方產品和我們一方產品的使用模式不一樣，并不是為第三方產品設計的。我們花了很多時間去想，怎么才能給出最順滑的過渡方案。
所以我很高興最后能說，所有訂閱用戶都會額外拿到一些 credits。但與此同時，我們也必須做一個艱難決定：優先照顧第一方產品和我們的 API。這個決定就是由此產生的。
Lenny： 對我來說，這其實非常合理。你們相當于以每月 200 美元的價格補貼這類用量，差不多就是無限使用。我覺得很多人不理解，做生意是要賺錢的。我們得追求盈利，不能因為需求太旺就把算力隨便送出去。所以我能理解。

Anthropic 的 PM 團隊如何組織
Lenny： 回到 PM 團隊，Anthropic 的 PM 團隊是什么樣的？大概有多少 PM？組織方式是怎樣的？
Cat： 我們有好幾個 PM 團隊?，F在大概有 30 到 40 位 PM 左右。
有一個研究 PM 團隊，由 Diane 負責，主要任務是理解客戶對模型的所有反饋，然后把這些反饋傳給最合適的研究團隊去處理，同時也負責推進模型發布。
還有 Claude Developer Platform 團隊，維護 Claude Code 所依賴的 API，也會發布像 managed agents 這樣的功能，讓你可以構建自己的 agent，由我們代為托管。
還有負責 Claude Code 和 co-work 核心產品的團隊。
還有企業團隊，幫助 Claude Code 和 co-work 更容易被企業客戶采用，包括成本控制、RBAC、安全控制，以及確保企業在使用我們的工具時感到足夠放心和舒適。
另外我們還有增長團隊，負責推動整個產品矩陣的增長。我們和他們在 Claude Code、co-work 的增長上合作很多，我知道他們也會和其他團隊一起做 CDP 增長，也就是 Claude API 用戶的增長。

PM 會減少還是增加
Lenny： 說到增長，Amol 剛上過節目。他有一個很有意思的觀點，是很多人以前沒怎么講過的。大家總覺得未來需要更少 PM，理由是“為什么還需要 PM？工程師自己就能 ship”。
但他的看法是，因為工程師太快了，PM 和設計師反而被擠壓了。你很難跟上，因為每天都在發功能。他的結論是：他反而需要更多 PM，因為根本跟不上。
你怎么看？你覺得未來 PM 的招聘會增加嗎？你覺得這個職業長期會怎么變化？
Cat： 我覺得所有角色都在融合。PM 在做一些工程工作，工程師在做一些 PM 的工作，設計師也在做 PM，并且也在落代碼。
你可以選擇招更多有很強產品品味的工程師，也可以保持工程師招聘規模不變，但招更多 PM 來幫他們的工作定方向。
我們團隊更偏向于招有很強產品品味的工程師。這樣可以減少發布產品時的額外開銷。我們團隊里有很多工程師，能完全獨立地從 Twitter 上看到用戶反饋，一路做到一周末把產品發出來，幾乎不需要產品介入。
我覺得這其實是最高效的交付方式。工程和 PM 的邊界正在重疊，而且你在任何一邊多一點人手，都會有很大收益。產品品味仍然是非常稀缺的技能，只要我們覺得某個人強烈體現出了這種能力，我們基本都會招。
Lenny： 你的背景是工程師，對嗎？
Cat： 對，我做了很多年工程師。后來我還短暫做過 VC，然后才加入 Anthropic。其實我們團隊里幾乎所有 PM，要么以前就是工程師，要么在 Claude Code 這邊寫過代碼。這也是為什么我們團隊彼此信任很強、推進很快。我們的設計師以前也都當過前端工程師。
Lenny： 這正是大家最關心的問題：這種邊界融合正在發生。很多人真正想知道的是——如果你出身于工程、產品或者設計，這三種核心能力里，哪一種以后最值錢？
在 Anthropic、在 Claude Code 場景里，工程能力當然很重要。但在別的公司，如果你有設計背景，做 PM 可能更有價值，或者做 PM 本身就是最有價值的方向。
Cat： 我還是覺得，核心還是產品品味。隨著代碼寫起來越來越便宜，真正更值錢的是決定寫什么。這個功能的正確 UX 是什么？用戶體驗它的最佳方式是什么？
我們每天都會收到成千上萬條 GitHub issue，要求各種各樣的東西。要判斷哪些值得做、應該怎么做，這需要大量的判斷力和品味。我認為這種能力可以來自任何背景，但這是最重要的。
不過至少在接下來的幾個月里，工程背景特別有用的原因是：如果你有工程背景，你會更清楚一件事情到底應該有多難。這個判斷常常會影響你做什么選擇。如果某件事特別容易做，可能你與其爭論，不如花一個小時直接把它做掉；但如果它很難，而且你提前知道這點，那你就知道這會給團隊帶來更高的交付成本。
所以它對優先級排序會有幫助。
Lenny： 你說“接下來的幾個月”是因為模型可能在未來幾個月里變得特別好，以至于你不一定還需要這些判斷嗎？
Cat： 我覺得有價值的技能組合變化得非常快，所以很難預測幾個月之后會怎樣。我的意思不是我在預測某種具體的能力轉變，而是說，大規模變化會發生，而且會很快。
Lenny： 你不是在說 Mythos 會出來，一切都變了，然后我們就不需要懂工程了。
Cat： 不是。我只是說，每隔幾個月，編碼能力都會大幅提升一次，然后角色的價值也會隨之變化。最重要的是，你得有第一性原理思維：看清技術環境在怎么變，團隊到底需要你做什么，然后直接跳進去把那個缺口補上。
因為工作正在變得更模糊，這就意味著一個優秀的 PM 要能看清所有缺口，判斷出最重要的缺口，然后想辦法學會那個技能，或者把自己已有的技能遷移到這個新挑戰上。
所以現在的環境更看重那種什么都能上、能快速切換角色、而且對自己做什么沒有太多 ego 的人——只要這樣能讓團隊更快。

人類大腦未來還會在哪里有用
Lenny： 我一直在問像你這樣站在 AI 前沿、用最新工具構建產品的人一個問題：在人類還沒走到超級智能之前，人腦到底還會在哪些方面持續有用、持續必要？
我從你這里聽到的基本意思是：選擇該做什么、知道市場會往哪走、知道該優先做什么；再就是判斷你做出來的東西是不是對的，然后至少先把早期版本推出來。這樣理解對嗎？還有沒有別的地方，人類大腦在未來幾個月里仍然會很有用？
Cat： 我覺得人類仍然能提供模型沒有的常識。任何一次產品發布都有上千個在動的東西，其中很多都很小，但永遠有很多地方可能出錯。
模型未必總能很好地理解：誰是所有利益相關方、他們彼此之間什么關系、他們各自偏好是什么、跟他們溝通用什么渠道最合適，才能讓他們繼續站在你這邊。
我覺得很多更偏“戰術性常識”、EQ 相關的知識，現在仍然非常有價值。當然，我們也希望模型在這方面越來越強，我相信它們會越來越強，但現在還存在缺口。

怎么在變化中保持冷靜
Lenny： 作為人，面對這么持續的變化，你怎么應對？就像一直待在龍卷風中心，也許里面很平靜，但你怎么一直跟上發生的事？怎么在這種瘋狂變化里保持正常？
Cat： 我們團隊里的人基本都比較愿意擁抱混亂。我們會盡量用微笑面對每一個挑戰，因為總有很多事情在發生，總有很多風險和棘手情況。如果你對每件事都太緊張，很容易就會 burnout。
所以我們會尋找這樣的人：他們看到挑戰時會說“這會很難，但我很想去做”，然后盡自己最大努力去做。他們知道自己不可能完美，但只要知道自己盡力了，就能安心睡覺。
Lenny： 這個回答很有意思，也在呼應你前面說的，未來什么技能會重要。有人說過，這可能是世界上最“正?！钡臅r刻了。
Cat： 這確實會變得更難。我感覺很多周，周日晚上還只是一個 P0，等到周一已經變成另一個 P0，周一下午又變成 P0000，你會想：天啊，我怎么會那么擔心周日那個 P0。
但你得承認，你能做的只有這么多；你得睡好覺，第二天才能做出好決策；你還得非常殘酷地優先排序，把時間花在最重要的事情上。要接受有些事情可以先放掉。
我們確實會發一些沒有我理想中那么精致的產品。但我們的首要目標是幫助專業開發者更有力量。如果某個產品不算成功，只要它沒有擋住核心使用場景，那就沒關系，因為我們會收到反饋，并在下一次發布里修掉。
如果發布的功能有 bug，過去我會整晚睡不著；但現在我已經可以接受了，因為我知道我們會很快收到反饋，也會在下一次更新中修掉它。
Lenny： 我腦海里浮現的是《加勒比海盜》里那個表情包：一個人走下船上的樓梯，而整艘船都在他身后被拆掉了，但他還是非常淡定地往前走。很有意思的是，我認識的所有 Anthropic 人都特別冷靜，也特別樂觀。
Cat： 我覺得這點非常重要——有這種平靜和樂觀，而不是“天啊，一切都亂套了”。如果沒有這種心態，很容易 burn out。我們也傾向于招聘那些已經在行業里待了一段時間、經歷過很多起伏、知道什么能給自己能量、如何長期維持能量的人，這對我們幫助很大。

角色融合會失去什么
Lenny： 我很想問一個問題：既然工程師變成 PM，大家的邊界都在融合，我們會失去什么嗎？會不會失去職業階梯和清晰的晉升路徑？會不會失去設計一致性、代碼質量？總會有一些代價吧。你覺得我們在為更大的好處犧牲什么？
Cat： 我們確實在犧牲產品一致性。
過去，當代碼很貴時，你會非常仔細地規劃整個產品矩陣：每個產品彼此是什么關系、每一個產品的使用場景是什么、怎么集成，然后通常會針對每個場景做一個產品。
但現在 AI 變化太快了，而且要測試的想法太多，所以我們有時會做出相互重疊的功能。很多時候，是因為內部有兩種形態我們都喜歡，希望外部用戶來告訴我們到底哪種更好。
但對于新用戶來說，這意味著他們可能不知道完成某個目標 X 的最佳路徑是什么。我們就需要做更多教育，幫助他們理解核心功能是什么、最佳實踐是什么。我覺得這就是大量功能同時上線的代價。
用戶也會覺得很難跟上最新變化。傳統 PM 場景下，功能一個月或一個季度才發一次，所以用戶很容易理解：我每個月看一次就好，半年不看也沒事，不會覺得錯過了什么。
但在這些 agentic 工具里，不只是 Claude Code 和 co-work，而是整個生態里，大家會覺得自己必須每天刷 Twitter，看看最新的東西是什么。
我覺得我們還有很多可以做的，去讓用戶沒那么像在一臺越來越快的跑步機上。我希望用戶能覺得：我只要打開這些工具，它們就會教育我、告訴我我需要知道什么，讓我自然跟上。
Lenny： 我前幾天看到你們發了一個很有意思的新功能，我記得叫 /powerup，基本上會帶著你看一遍 Claude Code 的各種好用方式和最佳實踐。是不是就是你說的這個方向？
Cat： 對，完全是。以前我們不太想做這種功能，因為我們覺得產品應該足夠直觀，用戶不需要任何教程。
但后來我們意識到，功能實在太多了，用戶也真的很需要內置 onboarding。我們稍微偏離了最初的原則——“不要 onboarding 流程”——加了這個功能，因為很多用戶都在問：有 100 個功能，我到底必須用哪 10 個？所以我們就把這個東西做出來了。

Anthropic 為什么能逆襲
Lenny： Anthropic 在企業 B2B 這條路上非常成功，而傳統企業軟件通常不會天天發新東西，往往是季度更新。你們完全相反：幾乎每天都有新東西。Anthropic 的這波增長太不可思議了。Anthropic 創業時其實落后很多，大家都說它是資金最少的公司之一，也沒什么分發優勢，不是第一個跑出來的。OpenAI 當時明顯領先。很多人都覺得 Anthropic 長期沒法真正競爭。
可現在你們干得非常好，甚至在一段時間里就把一些大公司的團隊甩在后面，增長極快。站在內部看，Anthropic 能這么成功、能從落后打到今天，最關鍵的因素是什么？
Cat： 我覺得最重要的兩個因素是：第一，一個統一的使命，這一點的重要性怎么強調都不過分。我們招的人，最看重的是把安全的 AGI 帶給全人類。這一點會頻繁出現在我們做決策時，影響我們整個產品線到底應該聚焦什么。
因為我們把這個使命放在任何單個產品線之上，所以我們可以做出跨整個組織的快速決定，并且以統一的方式執行。我覺得這是我在這么大規模的公司里從沒見過的東西。
Lenny： 所以更明確一點，你的意思是，第一要務是安全對齊，確保 AI 對世界是好的。你是說，有了這個清晰的使命，做決定就會容易很多。
Cat： 如果有兩個相互競爭的優先級，我們會討論哪一個更符合 Anthropic 的使命。這樣就更容易決定二者中先做哪一個，最后大家都會支持那個決定。
有時候這意味著：我們本來想在 Claude Code 上發某個功能，但另一個事情更重要，所以我們就會把這個功能往后排，等以后再發。
Lenny： 這點很有意思。它也解釋了為什么和另一家名字很像的公司相比，你們不會去做社交網絡，也不會去做資訊流，因為這些并不符合使命。這讓 Anthropic 保持了專注，而這看起來正是成功的核心要素。
Cat： 對我來說，使命意味著把 Anthropic 的目標放在任何個人、任何單個產品之上。所以我覺得第二個我們很擅長的東西，就是專注。使命和專注不完全是一回事。
使命意味著團隊愿意為了 Anthropic 的目標、Anthropic 的 KR，犧牲自己個人目標甚至自己的 KR。大家非常愿意做這種取舍。
極端一點說，如果 Claude Code 失敗了，但 Anthropic 成功了，我會非常開心。我們整個團隊都非常愿意按這種思路做決定。
Lenny： 我不確定你能不能深入講這個，但你覺得 Open Claude 的決定是不是也屬于這種邏輯：它并沒有推進 Anthropic 的使命，所以你們必須停掉，因為它不是你們希望它發揮作用的方式？
Cat： 對 Anthropic 來說，最重要的事情之一，就是盡可能讓更多用戶接觸到我們。我們實現這件事的一個方式，就是通過我們第一方產品的 Claude 訂閱。所以我們非常希望把重心放在這上面，但這有時候確實會犧牲第三方產品。

Claude Code、Claude Desktop、co-work 怎么選
Lenny： 我們一直在聊 Claude、co-work 這些東西。我想確保大家真正理解你們是怎么用這些工具的?，F在有 Claude Code、Claude Desktop、co-work。最好的理解方式是什么？什么時候用哪一個？你自己分別在什么時候用？
Cat： 我通常會在終端里用 Claude Code，尤其是我在啟動一個一次性的編碼任務、并且想要用到最新功能的時候。CLI 是我們的起始產品形態，也是很多功能最先落地的地方，所以它也是所有工具里最強的那個。我通常會在一口氣想啟動一兩個任務，或者少量任務時，用它。
如果你要做前端工作，Claude Desktop 就特別好用。我很喜歡用我們的預覽功能。比如我在做一個 web app 時，經常會同時打開 Claude Code 和 Desktop，把右側的預覽面板打開，這樣我在和 Claude 聊天時，就能實時看到自己在做的網頁應用。
對于想要更圖形化體驗的人來說，Desktop 也很棒。終端對非技術用戶來說可能非常陌生。你的機器上會彈出一堆嚇人的提示，而你又沒法像在其他大多數產品里那樣點擊和操作，這會讓很多人覺得不舒服。
如果你不習慣終端，我非常建議試試 Claude Desktop。Desktop 還有一個優勢，就是能一眼看到所有在發生的事情。你可以看到自己的 CLI 終端會話，也能看到其他 Desktop 會話，還能看到在 web 和 mobile 上啟動的會話。它相當于一個一站式控制臺，讓你看到所有任務。
web 和 mobile 的價值，在于它們特別適合“路上發起任務”。CLI 和 Desktop 都要求你在本地筆記本上操作。但現實是，你有時候人在外面，可能在散步、出門，不一定帶著筆記本，也不一定會打開電腦。我見過無數人把電腦連在手機上，站在外面辦公。那說明我們缺一個能滿足這個需求的產品。
對我來說，移動端的意義，就是讓你可以在外面直接啟動任務，不必把筆記本到處帶著，也不必確保自己無論去哪兒筆記本都開著。
Lenny： 我太懂了。我在飛機上也見過這種場景，已經成了一個梗：我得把這個 agent 等完，不能關掉，我得要 Wi?Fi。
Cat： 對。
Lenny： 而 co-work 呢？
Cat： co-work 負責的是另一類工作：輸出不是代碼的那些工作。比如把 Slack 清零、收件箱清零，或者為即將到來的客戶會議做一個幻燈片，或者寫一份關于某個功能目標的簡短文檔，或者寫一個發布計劃。這些任務的輸出不是代碼，而 co-work 最適合做這些。
所以我心里會這樣區分：如果我要做的東西輸出是代碼，我會用 Claude Code、Desktop，或者 mobile 上的 Claude Code；如果輸出不是代碼，我就會用 co-work。
Lenny： 很多人其實低估了 co-work 的成功。它增長特別快，但很多人還是不太明白它到底是干什么的。你能舉幾個你工作中的使用案例嗎？有沒有什么特別有意思、甚至有點意外的用法，能幫你省時間、提高效率？
Cat： 如果你剛開始用 co-work，最重要的第一步，就是把和你角色相關的所有數據源連上。因為只有它能拿到所有上下文，才能真正幫你把輸出整理好。
對我來說，我會連 Google Calendar、Slack、Gmail 和 Google Drive。這樣它就能根據需要找到相關上下文、發問、拉線程進來，結果質量會明顯提升。
我經常用它做的事情，比如昨晚我們在準備 Code with Cloud 大會，我要在那里做幾場分享，其中一場是講 Claude Code 從“助手”走向“完整 agent”的轉變。為了這場演講，我想展示我們最近發的所有能推動這個轉變的產品，也想找出內部有哪些成功案例可以拿來做 demo。
所以我把 Google Drive、Slack 都接上了。我們的產品營銷 Alex 先整理出一版他覺得應該覆蓋的要點。我就把這些都喂給 co-work，告訴它我想講的敘事線。它真的自己干了一個小時：它去 Twitter 看了我們發了什么，查了 evergreen launch room，查了我們的 Claude Code announce channel，也就是團隊在這里發 demo、分享自己如何從 Claude Code 中獲得最大價值的地方。
它把這些全部綜合起來，做出了一份 20 頁的演示稿。我今天早上醒來就讀了這份稿子，整體上已經相當不錯了，只需要一些微調。我確實又給了一輪反饋，因為我喜歡幻燈片上的字非常少，而它寫得有點太多了，但這仍然比我自己做快太多了。
而且因為 co-work 能訪問我們的整個設計系統，它做出來的東西看起來真的就像 Anthropic 的設計師做的一樣。你一眼看上去就會覺得“這非常精致”。這類事情真的快得多。做這份 slide deck 本來要花我好幾個小時，但現在它先給我一個已經很不錯的草稿，我就可以把精力放在把 demo 做到最好上。
Lenny： 這簡直是 PM 的夢想，做 deck 太煩了，太慢了。
Cat： 是啊。

一個 co-work 提示詞示例
Lenny： 而且等你之后展示這個 deck 的時候，大家都能看到。當然不會是你第一次一鍵生成的版本，但你會在這個基礎上繼續迭代。為了幫大家自己試試，你剛才說的第一步是連接什么？Slack，還有什么？
Cat： Slack、Google Calendar、Gmail、Google Drive。
你應該把自己的溝通工具，以及存放團隊關鍵信息、自己關心的信息和正在做的事情的“源數據”都接上。
Lenny： 好的。那你大概給它的提示詞是什么，才生成了這份 deck？
Cat： 我大概就是寫：幫我做一份 Code with Cloud 大會的幻燈片。我的 PMM 建議它應該覆蓋這些內容。
這是我當前手工做的一版，我不喜歡。我把它鏈接給你了。你能不能先給我一個包含細節的建議大綱？另外，別和 keynote 的內容重疊太多，因為 keynote 更重要。
然后 Claude 就讀了我發給它的很多鏈接，生成了一個建議大綱。我讀完它給出的結構和不同想法之后，自己決定最終演講稿應該包含什么。
這其實很能體現 PM 現在的角色：co-work 很適合做頭腦風暴，能非常快地綜合大量信息，把所有可能性擺到你面前。但最后，PM 還是要做最終決定：最終產品里到底該放什么。
這次我最后決定，演講要覆蓋的是：從讓本地任務成功，到讓每個 PR 都變綠，再到幫助工程師提交更多 PR；以及每個階段最有說服力的 demo 分別是什么。做完這個大綱決定之后，co-work 就自己跑了好幾個小時，把整份幻燈片做了出來。
Lenny： 這太棒了。終于有個不用再親手做的部分了。感覺你其實是在跟一個“會做內容理解的 deck 設計師”對話，而且它真的懂你做過什么，能把內容做成你想要的樣子，而不只是讓它看起來漂亮。設計系統這塊你是怎么做的？它怎么知道 Anthropic 的設計系統？
Cat： 我這次其實用的是我們已經有的一套標準化演示模板，平時做對外活動都會用。然后我只是把這個模板給了 Claude。它能看到我們用什么顏色、什么字體、有哪些不同的幻燈片格式。里面大概有 20 張示例頁。
Lenny： 明白了，所以就是把模板傳進去，讓它照著這個工作。
Cat： 對。你也可以連接你的 Figma MCP，如果你的幻燈片格式本來就在那兒存著，它也可以直接拉過來。

PM 的工具棧
Lenny： 順著這個說，我一直很好奇，作為 PM，你的工具棧里通常有哪些工具？Anthropic 當然是 Claude Code 和 co-work，還有你們自己的工具。還有什么別的嗎？你剛剛提到 Slack，還有沒有別的？
Cat： 我的工具?；旧暇褪?Claude Code 和 co-work。Anthropic 的日常運行很大程度上依賴 Slack，我覺得它就是我們公司的核心 OS。坦白說，我大概有 30% 的時間，是在推動 co-work 能力的邊界，這樣我才能非常清楚它哪里還不夠好。
我也會花很多時間和模型對話，理解它為什么會犯這些錯誤。我們內部其實做了很多自己的工具。
我覺得 Claude Code 給整個公司帶來的一個巨大變化，是它大幅降低了開發任何你想要的自定義應用的門檻。所以我們看到一種非常明顯的趨勢：越來越多人在做個性化工作軟件，專門針對自己特定的場景，而不是繼續用那些并不完全適配的通用工具。
Lenny： 你得多講講。能舉些例子嗎？你或者別人做了哪些特別流行、特別有用的東西？
Cat： 比如我們 Claude Code 的一位銷售同事，他發現自己在重復做一套又一套 deck。于是他自己做了一個 web app，里面有我們知道最有效的一些 Claude Code deck 樣板，比如 101、201、mastering Claude Code 這類。他還做了一個輸入客戶上下文的方式，這些上下文會從 Salesforce、Gong 和其他筆記里拉取，這樣我們就能針對不同客戶定制 deck。
它會幫你識別出很多關鍵信息，比如這個客戶在用 Bedrock 或 Claude for Enterprise、或者 Console，這會影響他們能用哪些功能；它會識別出客戶特別關心 SLC 的 code review 階段，然后我們就在 deck 里加一頁介紹代碼審查能力；它還會識別客戶是不是需要符合 HIPAA，或者需要某些安全控制，于是我們會在 deck 里加一兩頁相關內容。
如果這個客戶在 Vertex 或 Bedrock 上，而且不想用 Claude for Enterprise，我們就會把那些只屬于 Claude for Enterprise 的頁面刪掉。
這些事通常都很手工，可能要花 20 到 30 分鐘，所以很多人要么自己花時間做，要么干脆懶得做，直接用通用版 deck。而現在，這些只要幾秒鐘，就能得到一份定制版。

Slack 的地位
Lenny： 有意思的地方在于，Slack 就像是沒人想自己做的那個工具。沒有人真的想造一個“替代 Slack”的產品。你剛才的描述里，它像是很多公司的 OS。
這很有意思。大家會說 Salesforce 只是 SaaS，我們不需要 SaaS 軟件了，我們自己會造。可 Slack 似乎是一種很耐久的工具，沒人真的想和它競爭，去做一個更好的版本。
Cat： 我覺得它是非常重要的通信基礎設施，而且它在幫助所有人獲取實時更新這件事上做得非常好。
Lenny： 是啊。很多人吐槽 Slack，但它在自己要做的事情上真的做得很好，而且最前沿的團隊都離不開它。
Cat： 對。而且我特別喜歡它的可定制性，他們把定制做得特別容易。所以我們很喜歡做 Slack bot，這種可折騰性讓我們能按自己想要的方式把 Slack 接進來，我非常感謝 Slack 在這方面的工作。

哪些團隊最會用 Claude Code 和 co-work
Lenny： 你剛才講了很多不同團隊如何用 Claude Code 和 co-work 來推進工作。除了工程團隊之外，你覺得哪個團隊最會用這些工具？我猜工程肯定是 token 消耗最大的團隊，但如果不是，那會很有意思?，F在第二大 token 消耗部門是誰？
Cat： Applied AI 很擅長把 Claude Code 和 co-work 的邊界推得很遠。他們很多時間都在幫客戶采用我們的 API。有時，他們會代表客戶做原型，而 Claude Code 讓這個過程比以前快太多了。
他們還有一個雙重目標：一方面要處理大量客戶溝通，另一方面要處理大量客戶來信和歷史上下文、電話記錄，所以他們既重度依賴 co-work，也重度依賴 Claude Code。
Lenny： 我理解一下 Applied AI，這是不是有點像“前臺工程師”那種角色？大多數人會怎么描述他們在做什么？
Cat： 他們的工作，是幫助客戶在公司內部采用最新的 API 和模型能力，不管是給客戶自己的產品供能，還是用于內部提速。
Lenny： 明白了。所以它有點像很技術化的 go-to-market，或者 deploy engineering 一類的角色。
Cat： 對，完全可以這么說。
Lenny： 那它很可能就是第二大 token 消耗組織了？
Cat： 對。而且我們也看到他們在不斷推動 co-work 的邊界。比如這些人通常同時負責很多客戶，一天里高峰時可能有 5 到 10 個客戶會議。
他們常用 co-work 的方式是：前一天晚上，讓它總結第二天要見的所有客戶會議、這位客戶都提過什么需求、當前最關注什么、上次會議留下了哪些 action items。co-work 會自動整理出一份簡報，讓他們在下一次會議前就知道要關注什么。
co-work 還可以幫忙研究答案。比如客戶問“功能 X 什么時候上線？”它可以去 Slack 里幫這位 PM 或 PI 人員查最新 ETA，再把它加到 notes 里。這樣在客戶電話里，這個人就能拿到最準確的最新信息。
這些都是人們自己搭出來、再分享給團隊的工作流。

token 花費是否已經超過工資
Lenny： 最近還有一個很常見的話題：token 花費會不會超過人的工資，也就是大家用 AI 的成本會不會比自己賺得還多。Anthropic 這邊有沒有一些數字在流傳，比如工程師每月、每天、PM 等等會花多少 tokens？
Cat： 我們很清楚，隨著模型變強，大家會把更多任務交給它們，也會花更多時間待在 Claude Code 和 co-work 里。所以，每次模型跳躍或者產品有重大改進時，我們都會看到每位工程師、甚至每位知識工作者的 token 成本上升。
不過，這個成本仍然遠低于普通工程師的工資，但它占工資的比例在持續上升。
Lenny： 真有意思。我們剛才也聊到，作為在 Anthropic 工作的優勢之一，就是你們能接觸到最前沿的模型。我一直聽說你們基本上可以用無限 token，想用多少就用多少。是這樣嗎？
Cat： 我們可以用很多 token。有些人確實會碰到限制。
Lenny： 好吧，還是有限制的。Boris，別停啊。真有意思，擁有最先進的模型，會帶來這么多優勢。
Cat： 這確實會形成一個很有意思的飛輪。我們也很相信要賦能內部團隊，讓他們盡可能快地做事。同時我們也信任每個人都知道，真正提供這些模型的算力成本有多高，所以我們相信團隊會負責任地使用這些 token。
浪費 token 是很不受歡迎的，但我們信任個人自己做判斷。

PM 現在最該培養的能力
Lenny： 回到 PM 角色。我們剛才已經提到過一點，但我覺得大家會很想聽你更系統地講一下。你認為現在 PM 最需要培養的、AI 公司最看重的新技能是什么？
Cat： 最難的能力，是能定義一個月后產品應該長什么樣。我覺得在這個時間尺度上，模型能做什么、用戶行為會怎么變，都會有很多不確定性。
但最好的 PM 能從用戶如何“濫用”現有產品的邊界中，看出一些模式；他們能感知方向，穩定地朝那個方向執行；如果模型能力比他們最初預期的強得多或者弱得多，他們也能調整路線。
我覺得，要在 AGI 這件事上保持“剛剛好”的信念非常難。因為每個人都能看到一個未來：模型極其聰明，幾乎什么都能做。在那種情況下，其實你根本不需要多復雜的產品。你甚至可以重新回到一個文本框：你告訴模型你想要什么，它就能自己加任何工具、接任何集成，去把事情做完。它知道自己什么時候不確定，也可以主動提澄清問題。
給超級 AGI、超級強模型做產品很容易。真正難的是，在當前模型能力下，怎么把最大能力激發出來；怎么幫用戶走上最佳路徑；怎么引導用戶利用模型的長處，同時補上它的短板。
這項技能其實很稀缺。
Lenny： 那這項能力怎么培養？是不是就是不斷使用每個模型，理解它能做什么、擅長什么、不擅長什么，以及它在變化？你剛才說過“品味”，我理解成：你要對模型的能力有品味，知道它哪里強、哪里弱、哪里最近發生了變化。
Cat： 我覺得就是花大量時間和模型對話、使用模型。我特別喜歡讓模型自己反思自己的行為。
比如，當我注意到模型做出一些意外行為時——比如它做了前端修改，也跑了測試，但沒有真正去看 UI——這時候讓模型回頭解釋“為什么你會這么做”，其實很有幫助。
有時它會說，系統提示里某個地方有歧義，或者它沒意識到前端驗證也是這項任務的一部分，或者它把驗證交給了某個子 agent，而那個子 agent 沒做測試，它自己也沒檢查。這種時候，只要你對它為什么這么決定保持好奇，就能看出是什么誤導了它，這樣就可以修 harness，把這個缺口補上。
另一個有幫助的點，是找到那些你最信任、能給你準確反饋的用戶。通常只有少數幾個人，比其他人更擅長準確表達某個模型，或者某個模型 + harness 組合到底哪里好、哪里不好。很多人都會給反饋，但不是每個人的反饋都同樣有資格。找到那 5 個你真正信任的人，非常關鍵，這樣你能很快拿到高質量反饋。
第三件事也很有用，不過并不是每個人都愛做，那就是做 eval。你不需要做幾百個 eval 才有用，做 10 個很好的 eval 就足夠重要。它能幫助團隊量化目標是什么、進展到哪一步、還缺什么。
我認為 eval 是個長期被低估的事情，更多 PM 和工程師都應該參與進來。
Lenny： 我們已經聊了很多 eval。現在有種趨勢，大家都覺得產品管理的未來就是寫 eval，因為它本質上就是定義成功是什么。好，具體一點地定義出來，然后我們就知道了。你自己有多少時間會花在寫 eval 上？
Cat： 我覺得 eval 的重要性會隨著你做的功能不同而變化，也和你要解決的問題類型有關。我們團隊里有很多人會花大量時間做 eval。我們還有一小組成員，會和研究團隊非常緊密地合作，更精確地理解 Claude Code 的行為，以及最大的改進空間，并盡量把這些量化得很具體。
我個人通常會在某個功能需要更明確的產品定義時介入 eval。通常最后的產出會是：我做了 5 個 eval，告訴大家怎么跑，哪些會成功、哪些不會，以及我用過什么 prompt 來提升成功率。
不過這真的很看具體功能，不是每個功能都需要；但像 memory 這類功能，就特別受益于 eval。
Lenny： 你提到“有些人特別擅長評估模型”，這一點很有意思。其實這就像人類 eval：他們知道哪里表現好、哪里有短板。有沒有你特別想點名表揚的人？
Cat： 我覺得有兩類人特別厲害。
第一位是 Amanda，她負責塑造 Claude 的性格。這是個非常難的角色，因為任務太模糊了。哪怕是寫代碼都更容易，因為你可以驗證成功與否；而塑造人格，需要你對“Claude 應該是誰”有很強的確信。
我覺得她不僅能塑造這個角色，還特別擅長說清楚目標是什么、什么算成功、什么不算成功。
我真正信任的另一群人，就是 Claude Code 團隊。我們經常一起吃團隊午餐。每次有新模型在測，最快的反饋方式之一，就是午餐時挨個問每個人：“你對這個模型的直覺是什么？”
很多時候，大家會給出這樣的反饋：這個模型沒有把自己的思考解釋清楚，顯得太 abrupt；或者它特別愛寫很多 memories，但我們還不確定這些 memories 的質量高不高；或者有人會注意到這個模型很愛自己測試自己，這很好；也有人會覺得它測試得還不夠。
這些反饋會幫助我們決定接下來應該看哪些數據，去驗證這是不是一個更大的模式。我們有大量數據，但從中提煉洞見非常難，所以這群人的反饋能幫助我們形成假設，再去用數據驗證。

Claude 的性格為什么重要
Lenny： 你剛才說到 Claude 的性格。我之前請過聯合創始人 Ben Mann 上節目，他說 Claude 的性格、人格、constitution，是 Claude 非常重要的一部分。后來我才意識到，很多人之所以喜歡 open claw（或類似討論），原因之一就是 Claude 的性格太好了、太有趣、太吸引人了。按他的說法，性格正是 Claude 在這么多任務上都表現好的原因。
聽起來這像是個很不起眼的邊緣因素：讓它有趣、好玩、說話風格活潑，但其實它對 Claude 的成功非常關鍵。你怎么看？還有什么是大家沒理解到的？為什么這個“性格”和“人格”這么重要？
Cat： 當你回顧自己合作過的人，你會發現有些人就是能讓你覺得：我真的很喜歡他們的能量，我真的很喜歡他們的 vibe。
人們談到 Claude 和 Claude Code 時，經常提到的一點，就是他們真的很喜歡 Claude 的輕松和有趣。但與此同時，它對你的任務也非常勝任。大家尤其喜歡 Claude 的低 ego。比如你告訴它：“你這里做錯了?！彼鼤嬲\地道歉，像在說：“哎呀，謝謝你告訴我，我來修，我們一起把它做好。”
它也非常積極。如果你覺得“這任務太難了，我都不知道從哪兒開始”，Claude 會說：“沒關系，這里是我覺得我們該走的步驟。要不要我先幫你啟動？”
我認為，一個很棒的 co-worker，必須有這種積極性、偏向行動的傾向，以及能給你真誠反饋的能力，而不是對你說的每一句話都一味附和。我們希望把這些特質灌進 Claude，因為我們覺得這會讓一起工作變得更愉快。

新模型到來后，產品為什么會變
Lenny： 有件事我想回到前面提過的：每次有新模型出來，你們常常得重新審視以前做過的東西。這很有意思，也可能很煩——就像“天啊，我們剛 ship 出去，現在又要重新想一遍”。聊聊你們要多頻繁地回來重做幾個月前發過的產品。
Cat： 隨著新模型上線，我們很多變化其實是把不再需要的功能刪掉。因為以前我們會給產品加一些“輔助輪”，幫助模型完成它本來做不到的事情。
典型例子就是 todo list。Claude Code 剛發布時，用戶讓它做大型重構，它會說：“好，我要改 20 個調用點。”然后它真的去改，但只改了 5 個就停了。于是我們就想：怎么讓它記住要把這 20 個都改完？
我們團隊的 Sid 就想：如果換成人類會怎么做？人類會先把自己需要改的所有東西列成清單。就像你在 VS Code 里查出所有調用點后，左邊會有一個列表，你會逐個替換。那我們怎么給 Claude 也配一個類似的工具？于是他加了一個 todo list。結果我們發現，有了 todo list，Claude 就能把這 20 個調用點全部改完。
但到了 Opus 4 以及之后的模型，我們發現其實不需要強迫它用 todo list 了，它自己就會自然地用。對于早期模型，我們還得不斷提醒它：“你都把 todo list 做完了嗎？只有全部做完才能結束?！倍髞淼哪Ｐ?，不用提示也會自然想到去完成 todo list。
現在，todo list 作為用戶功能還是挺好的，因為你能更清楚地看到 Claude 在做什么。但說實話，它現在已經不是那么核心了。模型可能會用，可能不會用；要把事情做徹底，它已經不再必須依賴這個東西。
Lenny： 我記得有人在節目里說過一句話：“模型會把你的 harness 當早餐吃掉。”按你剛才的說法，就是你們會隨著模型變強，慢慢去掉那些之前加在模型上方、為了彌補它表現不足而做的東西。模型越聰明，事情就會變得越簡單，因為它自己就能更自然地做出你想要的事。
Cat： 對。每次模型變聰明，我們就能移除很多 prompt 干預。我們每次發布新模型都會做這件事：把整個 system prompt 讀一遍，反思其中每一段提醒，模型現在真的還需要嗎？如果不需要，就刪掉。
不過，新模型真正最令人興奮的地方，還是能解鎖全新的功能。很多功能我們以前都試過，但因為準確率不夠高，所以一直沒敢正式發布。
比如 code review。我們之前嘗試做過幾次 code review 產品，也發過更簡單的版本，比如過去的 /code review 命令。但直到最近這些模型，我們才覺得這套 code review 好到足以讓工程團隊真的依賴它，在合并 PR 前先過一遍 review。我們一直夢想 Claude 能成為一個可靠的 code reviewer，真正能抓住大多數 bug。只有到了 Opus 4.5、4.6 和 Sonnet 4.6，我們才覺得：可以同時跑多個 code review agent，覆蓋整個代碼庫，綜合出工程師在 merge 前必須處理的真實問題。這就是新模型解鎖的新能力。
Lenny： 這也是我節目里很常見的一個主題：先做一個“未來六個月可能才會真正可行”的東西，站在當前能力的邊緣上，然后等模型趕上來，你的產品就會突然變成一個很棒的產品，而且會領先所有人。
Cat： 對，完全沒錯。做一些“現在還不完全工作，但未來很可能會工作”的產品，非常重要。這樣你才能真正看清，產品要工作還缺什么；等最新模型一出來，你就能把它直接替換進你已經做好的原型里，看它是否真的補上了那個缺口。

Claude 和 co-work 的長期愿景
Lenny： 你能說多少關于 Claude 和 co-work 未來會往哪走？我猜你不會想透露太多，但我感覺你們一直在不斷往上加新功能：手機端派發任務、各種移動能力等等。怎樣能更好地理解這些東西的長期愿景？
Cat： 我們會把這件事理解成“搭積木”。對于 Claude Code 和 co-work 來說，最核心的積木，是讓單個任務成功。
你想產出某個結果，就給它一個清晰的 prompt 和描述，然后看它能不能持續輸出你可以合并、或者可以分享給同事和外部受眾的可接受結果。任務成功率，就是最核心的積木。
隨著模型變聰明，單任務成功率會高很多。然后我們看到用戶開始同時做多個任務。多任務并行，在 2025 年底已經變成一件大事，而且之后只會越來越普遍。
所以我們會這樣看：好，一個任務現在能穩定工作了，接下來你就可以一次做 6 個任務。再往后，如果模型更聰明，我們的推演是，也許你會一次運行 50 個 Claude，甚至幾百個 Claude。那我們就需要什么樣的基礎設施，才能支持這個規模？
到了那個時候，你大概率不會再把所有東西都本地跑在機器上，因為內存根本不夠。所以我們會思考：怎么讓你更容易管理這些任務？它們很可能會遠程運行。
我們要怎么設計界面，讓你這個人類知道哪些任務需要關注？怎么保證 agent 會徹底驗證工作，這樣當它告訴你“完成了”的時候，你能非?？斓仳炞C并完全信任它確實按規格完成了？又怎么讓這個過程自我改進：當你發現某個任務沒有達到你的要求時，可以直接給反饋，而模型在未來的所有運行中都能吸收這條反饋，再也不犯同樣的錯？
這就是我們帶用戶一起走過的演進路徑。

給從業者的建議
Lenny： 很多聽眾是 PM、創始人，或者其他跨職能角色。大家都會擔心自己的職業未來。你會給什么建議？不僅是“怎么活下來”，而是怎么在這種 AI 驅動的世界里真正做得很好、甚至蓬勃發展？大家需要聽到什么、需要做什么？
Cat： 我覺得 AI 給每個人帶來了比以前大得多的杠桿。所以只要你發現自己在重復做某個手工任務，就應該想一想，能不能用 Claude Code、co-work 或其他 AI 工具把它自動化。
大多數人的工作里都有很喜歡的創造性部分，也有非常討厭的瑣碎部分。我覺得 AI 最美妙的地方，就是它可以替你做那些瑣碎工作，它可以從你每次做手工任務中學習，然后泛化成自動執行，這樣你就能把精力放回到創造性部分。
這意味著你能做的事情會比以前多很多。所以我對大家最直接的建議是：找出那些重復性工作，把它們交給 Claude。不斷迭代這些自動化，直到成功率非常高，然后再思考：我還能為團隊、產品、公司做些什么，是以前因為沒有帶寬而沒能做的？或者，有沒有哪個你一直覺得公司應該做、但總沒時間做的小項目？如果 AI 能處理掉那些體力活，你就會多出大約 20% 的時間。
所以我的建議是：擁抱這些工具，把你不想做的工作交出去，想辦法讓它們加速你。這樣你就能做更多事。
Lenny： 你剛才說的核心觀點，我完全同意：找到能用 AI 解決的問題。很多工具的潛力大家都看得到，但對很多人來說，最難的部分其實是“我到底該做什么”。你這套說法其實就是：多留意你一直在做、而且可以自動化的事情，多留意那些你一直想做但沒時間做的點子。也就是說，給自己解決一個問題，基本就是核心建議。
Cat： 對。我也會鼓勵大家，重點不是“這只是個很酷的概念”，而是把自動化真正做到 100% 可用。我看到有人會嘗試自動化某件事，把準確率做到 90%、95% 就放棄了。但如果一個自動化不是 100% 穩定，那它其實就還不算真正的自動化。最后那 5% 到 10% 往往最費時間。
而且，構建自動化常常比自己做還慢。所以我鼓勵大家花時間把你真的想要的自動化打磨到 100%。下功夫教好它，讓它理解你的偏好，持續給它反饋，幫助它提升技能，直到它真的能穩定到 100%。這樣你才真的能依賴它。95% 的自動化，價值其實不大。
Lenny： 我超級有這個毛病。這對我很有幫助。
Cat： 我也有同樣的問題。我最近一直在教 co-work 幫我把 Gmail 變成 inbox zero，但這個過程非常耗時，而且你可能已經發現了，它目前還不夠好。
Lenny： 哈哈，有意思的是，我腦子里想的正是這個。我有個工作流，每封郵件進來都會檢查是不是垃圾郵件，就是那些“嘿，我能上你的播客嗎？”或者“這個你怎么看？”之類的請求。我根本沒時間處理這些，所以我給它設了一個叫 spammy 的文件夾。它大概 95% 的時候都做得很好，但偶爾也會漏掉真正重要的郵件。你這番話正好提醒我，我應該把它做到完美。
Cat： 對。我們現在也在努力把自定義這些命令的流程變得容易一些，因為目前你得知道太多概念：你得知道怎么定義 skill，還得知道怎么用這個 skill 并給它反饋，還得知道怎么讓 co-work 根據所有反饋去更新 skill，還得知道去哪兒讀 skill，確認反饋是不是按你想要的方式被吸收了。我們的工作之一，就是讓這個流程盡可能無痛。

最后一段補充
Lenny： Cat，還有什么你想分享的？有沒有什么想留給聽眾的話？有沒有什么你想再強調一下、但我們還沒聊到的？在進入很精彩的閃電問答前，你還有什么想說的？
Cat： 我看到很多人都在玩 AI，做一些原型應用，或者折騰工作流。我真的很想推動大家去構建那些你自己每天都真的在用的應用，因為只有在真實使用中，你才能真正獲得價值。
如果你做了一個原型應用，但它并沒有幫你做更多事情，那 AI 其實并沒有真正給你的日常帶來價值。
你從“只是一鍵生成了個東西，好酷”里能學到的也有限，尤其是之后你再也不回頭用它的時候。那樣你學到的不多，也沒有真正獲得杠桿。
Lenny： 這點說得太好了。
Cat： 我還覺得，有些人會花很多時間自定義自己的工作流。光譜一端，是那些從來不做自定義、也不做自動化的人；另一端，是那些過度沉迷于自定義工具的人，他們會瘋狂加 skill、加 MCP、加各種 workflow 改進。我覺得有時候，這甚至會分散你對核心目標的注意力——比如發布一個產品、做出一個功能。
定制確實很好玩，我們也希望自己的產品很可折騰，這樣你可以把它調成最適合自己的樣子。但這件事也有上限。有些人可能會花太多時間在定制上，結果沒睡覺，也沒去做原本真正想做的核心工作。
Lenny： 我在 Twitter 上經?？吹竭@種東西：大家曬自己的“工作流配置”，說自己已經優化到失控了。然后問題就是：那你到底做了什么？
Cat： 對啊，配置很酷，但你到底造了什么？我反而覺得，簡單的配置通常更好。
Lenny： PowerUp 這類東西，就是把等級稍微提升一點。
Cat： 對。
Lenny： 昨天我看到一條 Karpathy 的推文，他說了一個很有意思的分化：一部分人早年試過 ChatGPT、Claude 之類的工具后，覺得“也就那樣”，于是放棄了，變得很犬儒，認為 AI 沒什么大不了；另一部分人則把它真正用來寫代碼，因此看到了它強大的全部力量。兩邊的人都不太理解對方，也不理解對方為什么會這樣看世界。你這邊的建議非常對：真的拿它去做現實任務，看看它究竟已經變得多強。
Cat： 我覺得最大的變化是，2024 這一代產品還是“聊天式”的，而 Claude Code 這一代產品已經是“行動式”的。
人們真正“啊哈”的時刻，是當 Claude 可以代表你直接做事。知道 agent 不只是告訴你該做什么，而是真的能替你把事做了，這種感覺太棒了。當人們體驗到這一點時，那就是最震撼的時刻。
Lenny： 順便給那個 Chrome 擴展點個贊。Claude Code 的 Chrome 擴展很有意思，你可以直接看著它幫你干活。比如你說：“幫我填個表單”，它就會說：“好，我來了。”
Cat： 對。

閃電問答
Lenny： 好，在進入我們非常激動人心的閃電問答前，還有別的嗎？
Cat： 沒有，來吧。
Lenny： 好的，Cat，我有 5 個問題。歡迎來到閃電問答。那個動畫環節我得確保說出來。準備好了嗎？
Cat： 準備好了。
1. 你最常推薦給別人的兩三本書是什么？
Cat： 我很喜歡《亞洲如何運作》（How Asia Works）。它講的是經濟發展，以及哪些政策和政府能造就長期成功的經濟體。
我還很喜歡《科技陷阱》（The Technology Trap）。這本書講的是過去幾輪技術革命——工業革命、計算機革命——以及它們如何影響勞動者。我喜歡這本書，是因為我覺得歷史里有很多東西可以學，能幫助我們確保這次轉型順利。
還有一本比較輕松的，是《紙神》（Paper Menagerie）。這是一本短篇小說集，講的是成長、AI 和自我發現。
2. 你最近最喜歡的一部電影或電視劇是什么？
Cat： 我很喜歡《Drive to Survive》。沒有什么更深的含義，就是看人們對一個單一工程目標如此癡迷，會讓人很滿足，會感受到他們追求純粹性的感覺。
我也特別喜歡《Free Solo》，講的是 Alex Honnold 不帶安全繩攀登酋長巖。類似地，這也是一種非常純粹的成就：去完成一條極其困難、極其危險的路線，而且你必須保持絕對專注，因為一旦犯錯就會死。
Lenny： 那部片子真的離譜。很有意思的是，這跟你做的工作居然也有某種關聯。
Cat： 我其實就是個攀巖愛好者。我第一次看《Free Solo》是在我開始攀巖之前，所以當時只是覺得“很厲害”，但我根本不明白它到底有多離譜。
這種電影很少見，知道得越多，越會被震住。像他在墻上做的那些動作，我這輩子哪怕放在健身房里、離地一英尺、還系著繩子，可能都做不到。
Lenny： 你看過那部關于另一個年輕人的紀錄片嗎？就是去冰山上的那個？
Cat： 看過，那部很悲傷。
3. 你最近發現、并且非常喜歡的產品是什么？
Cat： 除了 Claude 相關產品之外，最改變我生活的產品，大概就是 Waymo 了。我是 Waymo 的鐵桿用戶，每天上下班都會坐兩次。
我喜歡它的兩個原因是：第一，Waymo 不會讓我有負擔感。如果它在等我，我不會覺得必須立刻跑到路邊等它，所以壓力會小很多。
第二，我覺得它讓我更高效了。和另一個人類在車里時，我通常不太會開工作電話。我會覺得一直在筆記本上工作有點不禮貌。但 Waymo 不一樣，我可以在車里接工作電話，不用擔心別人聽見，不用擔心“這會不會不禮貌”，也不用擔心“我是不是太大聲了”或者“是不是得讓別人換音樂”。這相當于每天給我省回了 30 分鐘。
Lenny： 這些技術的二階效應真的很有意思。
Cat： 對。我以前一直以為 Waymo 要比 Uber、Lyft 便宜才會成功，但其實我很愿意為它付 2 倍價錢。
Lenny： 我也很喜歡 Waymo。它就是那種“你一旦見過，就會覺得太瘋狂了”的東西。然后你會習慣它。你一坐進去會想：“這太不可思議了?！比缓筮^一會兒你又忘了它有多神奇。
Cat： 對，而且它還改變了我們的說法。Anthropic 很多人都很喜歡 Waymo。以前你會說“叫個打車軟件”，現在大家都會直接說“Waymo 到了嗎？”
4. 你最喜歡的人生格言是什么？
Cat： 就是“做事”。
Lenny： 沒錯。
Cat： 我覺得第一性原理思維很有價值。如果你知道自己在優化什么，而且你的第一性原理很扎實，那么你通常能推導出正確的行動路線，并且能把它清楚地講給所有利益相關方聽。然后你就應該直接去做。
我覺得很多職位其實是“假的”。如果你理解了約束條件，你就能知道自己能做什么，然后快速去做，快速從錯誤里學習，做錯了就道歉或修正。
Lenny： 你說得太對了，誰說的這句真好。
Cat： 我覺得把這句話告訴別人，其實很解放人。在很多公司里，角色定義得特別死：好，這些是 PM 做的事，這些是設計師做的事，這些是工程師做的事。連團隊邊界都畫得非常 rigid：這塊代碼我們能碰，那塊不能碰。
而“做事”這件事能讓人真正感到被授權，可以跨團隊邊界做決策，只為了把事情推進下去。
Lenny： 這聽起來像是一項非常重要的技能。人們會把它叫作 agency，或者偏行動、主動推進。這些說法本質上都在講同一件事：別等許可，先去做。
Cat： 對。我覺得，人生中最值得去體驗 startup 的原因之一，就是你會學到這個。對我來說，一個真正改變人生的經歷，是當公司只有 20 個人的時候，我第一次在這種規模下工作。那時候根本沒流程，問題又巨大，需要我們去解決。
我非常感謝 Alex 和整個團隊，他們讓我和其他人都能不受“銷售應該做什么、運營應該做什么、工程應該做什么”這些邊界限制，直接去想辦法。你手里有所有工具，面前又有一個很大很難的問題，你可以用任何辦法去找到好的解決方案。
你幾乎必須經歷過這種環境，才能培養出這種能力，才能真的在行動上感到自在。很多人上學、讀大學時，學到的是“照我們說的做，你就會得高分”。你得學會把這種思維卸下來，變成“我要做真正需要做的事情，哪怕別人覺得這很蠢，我也認為這是對的”。
Lenny： 對，就是這樣。
5. Claude 思考時，你最喜歡的那個“思考詞”是什么？
Cat： 我很喜歡 “manifesting”。而且這也是我最喜歡的一張貼紙。
Lenny： 很明顯的冠軍。
最后一個問題：如果 AGI 在我們有生之年到來，而你不需要工作了，你會做什么？
Cat： 我覺得 AGI 真正滲透到整個社會，還會花很長時間。所以眼前最重要的事，其實是幫助世界一起跟上。
如果認真講未來，我大概率會做很多攀巖。我可能會搬去 Fountainbleau，住在一萬塊巨石中間，爬一陣子。
我還有好多書想讀。我的目標是每周讀一兩本書，但現在大概只有 0.5 本。
未讀清單太長了。我覺得歷史里有太多東西值得學習，我也有太多地方還遠遠不懂，比如物理、機器人、硬件、航空航天之類的，太多有趣的話題了。所以哪怕 AI 早就知道這些，我還是會很興奮地繼續學。

收尾
Lenny： Cat，這期太精彩了。你太棒了。
再問兩個追問：如果大家想在線上找到你、關注你在做什么，應該去哪里？以及聽眾怎樣才能對你更有幫助？
Cat： 最好的方式是去 Twitter 找我，我的賬號是 @Catwoo。歡迎在 Twitter 上提到我，也歡迎私信我。我會看所有私信，不一定每一條都回復，但我都會看。
而最有幫助的事情，是告訴我們 Claude Code 和 co-work 哪里不好用。我們非常感激正面反饋，但真正讓我們成長的是邊界情況、錯誤，以及那些我們能復現的具體任務——也就是 Claude Code 或 co-work 失敗的地方。
如果你能把這些反饋給我們，而且我們能復現，那我們就能在下一代模型和下一代 harness 里真正把它改好。
Lenny： Twitter 上的人從來不吝嗇反饋，所以請繼續發。
Cat： 對，請繼續把你遇到的問題發給我們。
Lenny： 真的很酷，看到你和團隊這么活躍地在 Twitter 上回應大家，說明這些反饋你們真的會看到、真的會處理。
Cat： 是的，我們非常感謝大家這么積極參與。這給團隊帶來很多能量。我們有一個叫“user love”的頻道，只要大家分享成功案例，我們就會發進去；如果大家分享產品問題，我們就放到反饋頻道，方便更廣泛的團隊去處理。
Lenny： 能知道這個真的太好了。謝謝你分享。
Cat，非常感謝你來做客。
Cat： 謝謝邀請。
Lenny： 拜拜，大家。

我是鄧小閑koki，微信 m61502202，推特@kokisanai，加好友請說明來意。

我的個人故事：

AI系列