[Cat Wu跳巢新聞給的啟發] 她真正稀缺的能力，是敢刪掉自己做的東西

做產品的人有一套用了幾十年的老劇本。立項時先把技術邊界摸清楚，寫進規格書，然後花六個月到一年把它做出來。這套劇本能成立，靠的是一個假設，專案開始的時候技術能做到什麼，結案的時候大概也差不了多少。

這個假設已經不成立了。

Cat Wu 在 Anthropic 官方部落格裡寫過一句很精準的描述。她說傳統的產品管理建立在「專案開始時技術上可能的事，大致等於結束時可能的事」這個前提上，而指數成長的模型把這個前提打穿了。你可能在專案做到一半時發現，當初費力繞開的那個限制已經不存在了。

她用的意象是「你蓋在一塊正在往上漲的地面上」。

這句話不只是修辭。它意味著做 AI 產品的人，每隔幾個月就要面對一次「我上次做的決定還算不算數」的盤點。多數團隊沒有這個習慣，因為人類的工作本能是往前推進，不是回頭拆自己蓋過的東西。

她在 2025 年 5 月寫下的那篇《Product management on the AI exponential》，核心是四句話。用短期衝刺取代長期路線圖；用演示和評估取代文件；每次模型更新就回頭精簡舊功能；只做簡單有效的事，不要為 AI 的局限打補丁。

這四句聽著像口號。但如果你把它們攤開來看，會發現每一句落到具體產品上，都是一連串「刪掉什麼」的動作。而刪東西，恰恰是產品工作裡最難學的那一半。

我把她這套方法論拆成五層，每一層配一個 Claude Code 或 Cowork 的實際案子。拆完之後，最後再說說這套東西為什麼學不走，以及我們能學走的是哪一部分。

她不相信「現在做不到」是定論

多數產品經理的規劃建立在「技術恆定」的假設上。立項時模型做不到的，交付時大概還做不到，所以繞路是必要的，補丁是必須的。

她的判斷正相反。她從 2024 年 10 月開始做一件事，一直做到現在。

那時候 Claude Sonnet 3.5 剛出，她養成一個習慣：每一個新模型出來，都拿同一道題去考它。題目是讓 Claude Code 幫一個開源白板工具 Excalidraw 加一個表格功能。

2024 年 10 月，失敗。模型走一段就卡住，加不出來。

2025 年 6 月，Opus 4 發布，偶爾能成功。她把這個過程錄成預錄影片，放在 Claude 4 發布會上播。

再過不到一年，Opus 4.6 出來，她可以在幾千個專業開發者面前現場跑通這道題。

這道題兩年沒換過。題目不變，答案一直在變。

這件事的意義不在測試模型。她是在給自己校準：腳下這塊地現在漲到多高了。如果她不知道邊界在哪裡，所有的產品決策都是憑感覺。

METR 測過，2024 年秋天 Sonnet 3.5 大約能完成人類耗時 21 分鐘的軟體任務。到了 Opus 4.6，在大約一半的情況下，它能完成人類耗時將近 12 小時的任務。16 個月，大約 34 倍。

這個數字有三個限定要講清楚，不然會被誤讀。第一是大約一半的情況，不是穩定完成。第二是人類耗時，指的是軟體任務。第三是 16 個月的跨度。還有一個口徑問題：METR 對 Opus 4.6 的初測是 14.5 小時，後來下修到 12 小時，兩種算法會得出不同的倍數，我這裡用的是下修後的數字。

另外，這是兩個具體版本之間的單點比較。如果看長期趨勢線，學界測出的斜率平緩得多，大約每半年到七個月翻一倍。兩個數字不矛盾，一個是「這兩個版本差多少」，一個是「這條線平均多久翻一次」，但拿錯的數字去比會得出完全不同的結論。

但即便打上這三個折扣，這個斜率也足夠說明問題。你按 21 分鐘的能力設計的功能，在 12 小時的能力面前，有一半是白做的。

所以她的做法是「持續測量現在」。這件事說起來簡單，做起來需要一種紀律：你得願意每隔幾個月就承認自己上一次的判斷過時了。

一個功能要被定價三次

這是她整套方法論裡我覺得最好用的一條，因為它給你一個可以立刻上手的判斷工具。

先看 todo 列表這個案子。Claude Code 剛推出 todo 列表功能時，模型有個毛病：它不會可靠地把做完的項目勾掉。它可以跟你說要改二十個呼叫點，結果只改了五個就結束了。

團隊的解法是加系統提示。每隔幾條訊息，系統就提醒它一次，去更新自己的待辦清單。能用。問題也解決了。

但她把這個東西叫做 hack，也就是拐杖。

下一代模型出來，這個行為變成模型自帶的。那些提醒全部刪掉。

故事到這裡還沒結束。再往後，todo 列表這個功能的身份又變了一次。它最早是為了讓模型可靠地完成任務而存在的，是模型能力的支柱；後來它變成給使用者看的進度板，讓人知道 AI 現在做到哪一步。

功能還在，程式碼沒動多少，但它的身份變了兩次。

這就引出她那條判斷標準。一個功能要問它現在背著哪一種身份：

補短板的那一種，會隨著模型升級慢慢失去存在理由。幫使用者建立信任、理解進度、掌握控制權的那一種，會留下來。

所以同一個功能，模型更新一次，你就要重新給它定價一次。這是一個很反常識的要求，因為多數團隊計算功能價值的方式是「它上線時解決了什麼問題」，而不是「它現在還在解決什麼問題」。

敢刪的人少，因為刪等於承認當初白幹

她有個說法我一直記得。任何巧妙的繞過，下一代模型來的時候都會變成技術債。

這句話在 Claude Code 的系統提示上有一組具體的數字。她說系統提示和工具描述過去被大量工程化，用來補償模型的局限，隨著每個新模型出來，這些工程化內容都在被削減，Opus 4.6 上削減了 20%。

注意這個措辭。被削掉的是系統提示和工具描述，不是整套提示砍掉兩成，範圍要說準。

20% 這個數字單看沒什麼感覺。但它意味著，團隊有一整塊工作是在定期審查「我們當初為了繞過某個限制而寫的東西，現在還需不需要」。這塊工作在多數公司不存在，因為它不產生新功能，只減少舊程式碼。

為什麼多數團隊做不到？她的觀察很直接。做新的東西有成就感，刪自己做的東西像是在承認當初白幹。

這一點我認為是整篇最難學的部分，比抓模型邊界還難。因為它對抗的不是技術問題，是人的心理。一個團隊如果沒有把「刪掉舊功能」寫進流程和考核裡，它就永遠只會往上堆。

堆到某一天，產品變成一個誰也不敢動的遺跡。

恰好正確程度的 AGI 信仰

這是她訪談裡最反直覺的一句判斷。她說，要當一個 AGI 信仰程度剛好的人，非常難。

難在哪裡？她拆得很清楚。

為終極形態做產品太容易了。你只要想像模型無所不能，然後做一個輸入框，剩下的交給模型。這個故事很性感，也幾乎不需要判斷力。

難的是搞清楚眼前這個模型的能力邊界在哪，然後在這條邊界內榨出最大的價值。

兩種失敗的方式她都很清楚。太相信 AGI 的人，會忽略眼前使用者真正的痛，因為他覺得明年這個問題就自動解決了。太保守的人，下一次模型升級就措手不及，因為他做的所有東西都是為了遷就今天的限制。

所以她那句「恰好正確程度」是個具體的工作要求。你要同時記住兩件事：模型今天能做到哪裡，以及它下一個版本大概會到哪裡。

她的做法很具體。她會專門騰出時間，故意把 Cowork 推到極限。她跟它對話，搞清楚它到底為什麼在某個任務上犯錯。

這不是測 bug。測 bug 是找實作錯誤，她做的是畫地圖。每一次失敗都是一個座標，累積起來就是「當前模型的能力邊界」。

這張地圖沒有任何文件寫得出來，因為它是活的，每一版模型都要重畫一次。她願意花時間做這件事，是因為沒有這張地圖，所有的設計都是猜的。

95% 的自動化不是自動化

這條是我認為她講得最實用、也最少被人引用的一條。

她的說法很直接。如果一條自動化流程不是 100% 可靠，那它就算不上自動化。標題裡那個 95% 是我對她意思的概括，不是她的原話，她講的是「不是 100%」。

聽起來很苛刻。但她的解釋完全站得住。很多人搭了能完成九成到九成五的流程，然後在最後那一小段放棄了。結果是什麼？這條所謂的「自動化」變成一份需要隨時盯著的副業。你沒有省下時間，你的心智負擔反而增加了，因為你多了監控它、糾正它、擔心它哪次亂來的工作。

剩下那 5% 會把人變成監工。

所以在她看來，真正重要的是整套讓使用者敢把工作交出去的設計：權限、審查、日誌、回滾、人在迴路裡的確認點，跟模型多聰明關係不大。

她自己也死磕過這件事。用 Cowork 做 Gmail 收件匣清零，教它分類，教它分辨垃圾邀請和重要郵件，一遍一遍改提示、改技能。這個過程極耗時，而且到訪談時都還沒完全做到她滿意的程度。

這個例子值得留意，因為它顯示她不是嘴上說說。她自己要的標準就是 100%，達不到就繼續磨。

這也解釋了她到 OpenAI 之後說的那句「讓使用者保持控制權」。那句話常被當成公關語言，但它其實是她整條方法論的自然出口。一個讓人不敢交出去的系統，無論模型多強，都不能算產品。

做一個讓人敢把工作交出去的系統，比做一個看起來很聰明的模型更難。這是她整套思路裡最不性感、也最值錢的一句。

她最值錢的可能是流水線

前面四層都在講怎麼做判斷。如果你問我，她對一家公司最難被取代的貢獻在哪裡，我會說是這一層：她改的是產品的生產線。

這裡要先把一個常見的誤解拆掉。很多人以為她的做法是「不要流程」。不是。她做的流程比多數公司更精密，只是形式不一樣。

看幾個具體的機制。

research preview（研究預覽）。幾乎所有新功能先以研究預覽的形式發布，介面上寫明這是早期實驗，可能不會永遠支援。這個設計很聰明，它把發布從「承諾」變成「觀察工具」，一兩週就能推到真實使用者手裡。內部共識是降低對承諾的門檻、提高對學習速度的要求。

evergreen launch room。工程師覺得一個功能夠好了，就發進這個內部頻道。管文件的、管產品行銷的、管開發者關係的會直接跳進來，第二天對外的文案和文件就位。她的定位很清楚：PM 的工作是設計這套低摩擦的協作系統。

有想法不要開會，下午自己搭個原型。她把這個叫做 side quest（支線任務），一個不寫在正式路線圖上的自主實驗。團隊被鼓勵花一個下午去試一個念頭，測試一個原以為做不到的能力。

這裡有個更有據的細節。她讓團隊把規格寫完之後，直接丟給 Claude Code 看它能不能做出來。哪怕只是一個粗糙的原型，對話的品質就完全不一樣了。她同事的做法是把插件規範發給 Claude Code，回來的原型已經接近可交付狀態。

todo 列表後來的樣子也是這樣長出來的。她發現早期使用者讓 Claude Code 做大規模重構，模型會說「我需要改這 20 個呼叫點」，然後只改 5 個就停了。團隊從人類的做法借了「待辦清單」這個概念，才讓模型有辦法自己追蹤進度。這個功能不是規劃出來的，是從一個具體的失敗長出來的。

用團隊原則取代大部分 PRD。她維護一份原則文件，寫清楚核心使用者是誰、為什麼是他們、願意做哪些取捨。目的是讓每個人能自己做決策，不必等 PM 拍板。真正模糊的功能她才寫一頁紙，寫清目標、理想場景、當前失敗模式。

這裡也要說準。PRD 沒有消失。需要大量基礎設施投入的長期專案，她還是會寫 PRD。她砍掉的是「每個功能都要先寫規格書」這個慣性。

這四個機制不是四個可以挑著用的做法，它們是一條流水線上的四段，缺一段就轉不動。

side quest 供給想法，讓東西在被規劃之前就先存在。研究預覽降低發布的心理門檻，因為它允許你說「這是實驗」而不是「這是承諾」。evergreen launch room 壓縮發布的協作成本，讓文件、行銷、開發者關係不必排隊等流程。團隊原則替代審批，讓每個人在沒有 PM 點頭的情況下也能判斷該不該做。

四段接起來，才是一個完整的循環：有人想到、可以很快做出來、可以很快承認這是實驗、發出去之後相關的人自動就位。少任何一段，「一週把想法變成現實」就不成立。只有 side quest 沒有預覽機制，那些原型永遠躺在工程師的電腦裡；只有預覽沒有 launch room，發布會卡在文案和文件的排隊上。

結果擺在這裡：2026 年前三個月，Claude Code 上了 45 個以上的新功能。內部大約 90% 的程式碼由 Claude Code 自己寫，工程師的產出比一年前高約兩倍。

快來自期望設定，不來自模型

有個問題 Lenny 直接問過她。你們是不是用了內部還沒發布的模型在加速？

她的回答很值得記下來。她說他們已經快了好幾個季度，新模型不是核心原因。更大的原因是流程和團隊的期望設定：每個人都覺得自己既有權力、也有責任，把一個想法在一週內變成現實。

這句話打掉了很多人對「快」的誤解。多數公司以為速度來自工具，其實速度來自授權。當一個組織裡每個人都得等 PM 排優先順序、等主管批預算、等法務看完文案，再好的模型也救不了它。

她的做法說到底，是把「誰有權決定」這件事往前線推。

但這裡我要放一段她自己的坦白，因為它讓這套東西可信。

她說快最大的代價是產品一致性。有時候會同時推出功能重疊的東西，因為內部兩個方案都不錯，乾脆讓外部使用者告訴他們哪個更好。代價是新使用者可能不知道完成某件事的最佳路徑是哪一條。

這段話很重要。它說明這套方法不是萬靈丹，它有明確的副作用。任何一個跟老闆推薦「我們也來搞 side quest」的人，都該先把這段話讀一遍。

速度快、一致差，慢速穩、反應鈍。這是一道選擇題，不是一道有標準答案的題。

為什麼這套東西學不走

把她的方法論抄成一張清單不難，難的是支撐這張清單的三層結構。

第一層是履歷。工程師、投資人、產品經理，三段她真的都做過。她對工程背景的價值講得很直白：如果一件事該有多難你判斷得出來，簡單的就別討論了，花一小時做掉；難的就提前知道成本，好排優先順序。這種判斷力不是讀書能讀來的。

第二層是她真的動手。她面試過幾百個想轉 AI 的產品經理，發現多數人還在用六到十二個月路線圖的思維找工作。而她自己是用 Claude Code 搭 Streamlit 應用分析使用者回饋、跑模型評估，幾百小時的活一行程式碼沒手寫。

第三層是她同時懂模型和懂人。她說過模型暫時還替代不了的是常識和情商。一次發布有一千個細碎環節，判斷誰是關鍵利益相關方、他們之間什麼關係、該在什麼場合溝通，這些仍是人的地盤。

三層疊起來，才是那個「稀有感」。任何一層單獨拿出來，市場上都不算少見。

還有一個組織事實值得參考。Anthropic 大約有 30 到 40 名產品經理，分在研究、開發者平台、Claude Code、企業、成長五個團隊。Claude Code 團隊裡幾乎每個 PM 都有工程背景或直接寫程式，設計師也做前端。她描述的兩條路是：要嘛大量招有產品品味的工程師，要嘛維持工程師數量、多招 PM 引導。Anthropic 選了前者。

這個選擇本身就說明了她對自己這份工作的定義。她不是要找更多人來寫需求文件，她要找能自己驗證想法的人。

我們能學走的是哪三件事

她那一整套學不走，但其中有三件事，任何一個團隊下週就能開始做。

選一個能代表你業務難點的小任務，固定下來，每次工具或模型升級就拿它跑一次。它的用途是校準，不是驗收。你會得到一個別人給不了的東西：你的團隊對「現在能做到什麼」的第一手判斷。

這件事成本極低，一個下午。但多數團隊沒有，所以他們的技術判斷全靠廠商的發布會。

最容易做錯的地方在選題。太簡單的題，第一次就過了，之後每次跑都是重複驗證，測不出邊界移動。太難的題，每次都在同一個地方失敗，你也看不出這半年到底長了多少。她要的那道題有個很明確的特徵：現在做不出來，但你判斷得出它差在哪裡。Excalidraw 加表格就是這種題，失敗的方式很具體，不會含糊。

盤點你手上那些為了繞過某個限制而做的設計。每一次系統升級、每一次換工具，就問一次：這個東西現在是在補短板，還是在幫使用者建立理解？補短板的，排進刪除清單。

我知道這一步最難。因為它意味著要有人承認「我們當初做的這個東西，現在可以不要了」。所以它必須變成流程的一部分，不能靠自覺。

實際會卡住的地方是責任。盤點出來的功能，沒人敢刪，因為刪了要向上解釋，而留著不用解釋。這是組織的誘因結構問題，不是判斷力問題。她那一套能跑通，靠的是把「刪掉舊東西」寫進團隊的原則裡，變成一個被鼓勵的動作，而不是一個要辯護的決定。

不要只問這個流程自動化了幾成。要問剩下那幾成，會不會讓使用者變成監工。如果不是 100%，就要配齊權限、審查、日誌、回滾這些東西。配不齊，就別急著上線，因為你交付的東西會變成一份新的精神負擔。

這裡有個很常見的假達標。很多團隊會說「我們有人工複核」，聽起來流程完整了。但如果那個複核的人每做一次就要重新判斷一次、沒有任何預設規則可依，那他就是在當監工，不是在複核。判斷方法很簡單：問那個複核的人，如果他請假三天，這條流程會不會停。會停，就說明這還不是自動化，只是把工作換了一個人做。

這三件事沒有一件需要你是頂尖工程師才能做。它們需要的是紀律。

一個她自己承認的缺口

寫到最後，我要放兩段話，讓這篇文章不至於變成吹捧。

第一段先說明來源。這是外部評論者的意見，不是她的原話。她說「產品品味」是最稀缺的能力，訪談裡也說幾乎會僱用任何能證明自己有品味的人。但整場訪談下來，這個詞始終停在抽象層面，她沒有給出可操作的定義，也沒有給出評估的方法。

這是一個真實的缺口。一個說不清楚的篩選標準，很容易變成不可證偽的門檻。你說這個人沒品味，他沒法反駁；你說這個人有品味，別人也沒法驗證。我認為這個批評站得住。

第二段是她自己的坦白。她說過，如果模型有一天強到只要一個輸入框就夠，那她現在做的這類產品工作就沒有必要了。她甚至說得更直接，為一個超級 AGI 設計產品其實很容易，難的是在當前能力下榨出最大價值。

一個產品負責人公開說自己的工作有保質期，這種坦率很少見。但它同時意味著另一件事：她這套方法論有窗口期。它成立的前提是模型能力還在快速上升，邊界每隔幾個月就變一次。等到哪一天邊界穩定下來，這套「每隔幾個月重新定價」的紀律就會失去對象。

所以這篇文章最誠實的結論可能是這樣。她真正稀缺的是在一個劇烈變動的環境裡保持校準的紀律：敢刪、敢交付、敢承認自己上一次判斷過時了。懂 AI 反而是次要的。

（系列第二篇。附件另有可掛進 Claude Code 的技能檔案。）