「模型會把你的 harness 當早餐吃掉」——Cat Wu 談 Anthropic 怎麼為下一代模型造產品

本文整理自《Lenny's Podcast》2026 年 4 月 23 日播出的單集，受訪者為 Anthropic 產品總監 Cat Wu，主管 Claude Code 與 Cowork 兩條產品線。本系列共三篇，這是第三篇談「為下一代模型造產品」的工程哲學，第一篇談 PM 角色重塑與產品品味，第二篇談使命作為決策仲裁機制。

{{< youtube PplmzlgE0kg >}}

{{< spotify "episode/7wTqD5zwl8ZitUeplapvBG" >}}

{{< apple-podcast "tw/podcast/how-anthropics-product-team-moves-faster-than-anyone/id1627920305?i=1000763270413" >}}

---

「模型會把你的 harness 當早餐吃掉」

Lenny Rachitsky 在訪談中講了一句後來在 X（Twitter）瘋傳的話：「模型會把你的 harness 當早餐吃掉。」這句聽起來像玩笑的話，其實道破了 Anthropic 內部過去兩年累積出來的核心產品哲學：當你為了補強模型某個弱點而蓋起來的鷹架（也就是 harness），下一代模型一上線就會直接把它吃掉。聰明的產品團隊不會等到那天才驚訝，而是會主動每隔一段時間就回去把鷹架拆掉。

Cat Wu 在訪談裡用一個非常具體的例子展示了這個過程。Claude Code 剛推出時，使用者常常請它做大型重構（refactor），它會說「好，我需要修改這 20 個呼叫點」，但實際上只改了 5 個就停下來。團隊裡的工程師 Sid 想出一個解法：模仿人類的工作方式，給模型一個「待辦清單」（to-do list）工具，讓它把每一個要修改的呼叫點列下來、一個一個完成。這個工具加上去之後，Claude 真的能把全部 20 個呼叫點修完。

但故事不只到這裡。Cat 接著說：「Opus 4 出來之後，我們發現完全不需要逼它使用這個待辦清單，它會自己自然地用。對於早期的模型，我們必須一直提醒它『你完成了清單上的所有項目嗎？沒做完就不能停』。但對於後來的模型，不需要任何 prompt，它就會自然地做完清單上的每一件事。」這個例子完美演示了「拐杖」如何從必要、變成可選、再變成多餘。而 Anthropic 的處理方式，是在每一次模型發布時主動去檢視。

「我們確實在每次推出新模型的時候都這樣做，」Cat 說，「我們會把整段 system prompt 從頭到尾讀一遍，反思每一個段落：這個提醒，模型現在還需要嗎？如果不需要，就拿掉。」這個動作聽起來像是維運瑣事，但它背後藏著一個更大的產品判斷：當模型能力不斷躍升，許多原本被視為功能的「行為強制」其實是在拖累更聰明的版本，必須及時清理才不會變成包袱。

Build before it works：把「還不能用」當成出貨策略

如果說「拆鷹架」是後手動作，那 Anthropic 的另一個產品哲學就是更主動的版本：在模型還不能讓某個產品穩定運作之前，就先把產品蓋起來。Cat 把這套邏輯講得非常清楚：「蓋出那些『還不能用』的產品其實很重要，這樣你才會知道，要讓這個產品真的能用，到底缺什麼？然後當最新的模型出來，你可以直接把它換進你已經做好的原型，看看新模型有沒有把那個缺口補上。」

這套思維最具體的例子，就是 Claude Code 的 slash code review 功能。Cat 解釋，Anthropic 早就「夢想 Claude 能成為一個可靠的程式碼審核者，可以讓我們有信心地相信它抓到了大多數的 bug」。他們試了好幾次，也曾經推出過比較簡單的版本，但效果都不夠好。直到 Opus 4.5、Opus 4.6、以及 Sonnet 4.6 這幾代模型，他們才終於覺得「OK，這個程式碼審核已經好到我們的工程團隊真的會把它當作合併 PR 的必要關卡」。她描述新模型解鎖的能力：可以同時跑多個程式碼審核代理，平行掃過整個 code base，並把真正需要工程師處理的問題綜合起來。

Lenny 順著這個思路給出了精準的歸納：「這是這個 podcast 上反覆出現的趨勢，做出一個未來六個月可能可以運作的東西，先卡在那個能用不能用的邊緣，然後等模型趕上，你就會領先所有人。」Cat 直接同意了這個說法，並且把它往前推：當你已經有原型，新模型一出來只要「換進去」，你就立刻擁有一個能用的產品；對手如果是現在才開始打造，至少落後你一個月以上的開發週期。

這套邏輯其實顛覆了傳統工程的紀律。過去軟體產品的金科玉律是「不要出貨還沒完成的東西」、「不要承諾還做不到的功能」；但 Cat 描述的 Anthropic 方法，反而是「先做不能用的東西，把『缺什麼』搞清楚」。這背後的隱含假設是模型能力的提升曲線足夠陡峭、足夠可預測，所以你今天蓋的「不能用的房子」，幾個月後會自動「能住人」。如果模型曲線變平、AI 進展變慢，這個哲學就會變成資源浪費；但只要曲線還在，這套打法就能持續放大領先優勢。

Claude 的「性格」是首要產品功能，不是品牌包裝

訪談裡有一段 Lenny 提到，他訪談 Anthropic 共同創辦人 Ben Mann 時，對方堅持 Claude 的性格與「憲法」（constitution）是 Claude 之所以好的核心，而不只是行銷話術。Lenny 自己當時沒完全理解，是事後才意識到使用者對 Claude 的依戀有相當部分來自於它的「氣質」。他在這集追問 Cat：「為什麼性格那麼關鍵？」

Cat 給的答案非常具體。她說當你回想自己合作過的人，總會有那種「我就是喜歡他的能量、喜歡他的氛圍」的感覺；而當人們談到 Claude 和 Claude Code 時，這也是被提起最多的事情之一。她接著拆解 Claude 性格的四個具體面向。第一個是「輕鬆有趣，但同時極度勝任你的任務」。第二個是「自我意識很低」，所以你跟它說「你做錯了」，它會真心地說「天啊，謝謝你告訴我，讓我修一下，我們一起做」。第三個是「非常正向」，當你覺得這個任務不可能完成、不知道從何下手，它會說「沒關係，我覺得我們可以分這幾步走，要我幫你先開始嗎？」。最後一個是「有行動偏好，能給你誠實的回饋，而不只是同意你說的每一句話」。

這四個面向被 Cat 視為產品功能，而不是品牌特性。「我們認為這就是讓一個好同事之所以好的東西：這種正向、行動偏好、能給誠實回饋而非一味附和的能力。所以我們刻意把這些灌輸進 Claude，因為我們覺得這讓它變得更愉快地一起工作。」她特別點名 Anthropic 內部負責塑造 Claude 性格的 Amanda，形容她的工作極度模糊：連寫程式都比較容易，因為至少可以驗證對錯，但塑造性格需要極強的信念與表達能力，知道 Claude「應該」是什麼樣子。

把性格視為產品功能而非行銷包裝，是一個容易被忽略的策略選擇。在大多數 AI 公司裡，模型的「個性」往往被丟給品牌團隊或對話設計師處理，視為「人感」的調味；但 Anthropic 把它放在跟模型能力同等的位置，並由具有強烈信念的人主導。Lenny 在訪談中提到，當 OpenClaw 被限制使用 Claude 訂閱時，社群難過的其中一個理由就是失去了透過 OpenClaw 用「他們熟悉的 Claude」的那種感覺。這個觀察暴露了一件事：當 AI 產品的能力差距越來越小，性格本身就會成為差異化的護城河。

從一個任務、到多個任務、到 50 個遠端代理

Cat 在訪談接近尾聲時被問到 Claude 與 Cowork 的長期願景。她沒有畫一張漂亮的願景圖，而是用「積木」的方式拆解未來的演進路徑。這個視角本身就是 Anthropic 產品哲學的具體展現：每一個積木都建立在前一個之上，每一個跳躍都對應到模型能力的某個關鍵閾值。

第一塊積木是「讓單一任務成功」。給模型一個清楚的描述，看它能不能穩定地產出可以合併、或者可以分享給同事與外部對象的成果。這聽起來基本，但其實是過去兩年所有產品工作的累積結果。Claude Code 從 2024 年一路走到現在，本質上就是把這塊積木磨到夠堅實。第二塊是「同時做多個任務」，Cat 用 multi-Claude-ing 這個詞描述 2025 年下半年興起的趨勢，當時使用者開始同時跑 6 個 Claude Code 工作階段，這個現象之後只增不減。

第三塊則是真正的躍進。Cat 直接把話講出來：「下一步可能是 50 個 Claude 同時跑，或上百個 Claude 同時跑。那需要什麼樣的基礎設施？到那個時候，你大概不會把所有東西都跑在本機了，因為記憶體不夠。」她接著拆解這個未來會帶來的三個產品設計挑戰。第一個挑戰是介面：當這些任務都在遠端執行，「介面要怎麼設計，才能讓你這個人類知道哪些任務需要去看？」第二個挑戰是信任：「我們要怎麼確保代理會充分驗證自己的工作，這樣當你看到任務說『完成了』，你可以很快確認、完全信任它真的按照你的規格做完？」第三個挑戰是學習：「這個過程要怎麼讓自己改進？當你看到一個任務沒有做到你想要的，你給它回饋，模型要在未來每一次執行時都記得這個回饋，這樣它就不會再犯同樣的錯誤。」

這三個挑戰實際上勾勒了下一代代理產品的競爭主軸：不再是「模型有多聰明」，而是「人類怎麼有效率地監督一群代理」。Cat 提到的 Slash code review 之所以是個關鍵案例，正因為它是這條進化路徑的早期驗證：一個原本不可能的功能，在 Opus 4.5/4.6 才終於跨過閾值，但 Anthropic 團隊已經因為早就蓋好原型，能在模型一上線就立刻拿出真正可用的產品。

95% 不是自動化：Cat 給聽眾的工作方法論

訪談接近尾聲，Lenny 拋出一個許多 PM、創辦人、跨職能工作者都在焦慮的問題：「在這個 AI 驅動的世界裡，怎麼樣才不只是『活下來』，而是『活得很好』？」Cat 給的建議很短，但每一條都帶著刀鋒一樣的鋒利度，而且都跟主流敘事擰著走。

第一個建議是把重複工作自動化，但要做到 100%，不要停在 95%。這是整集訪談裡最違反主流敘事的一條建議。Cat 直白地說：「如果一個自動化沒有 100% 運作，它就不算是自動化。最後那 5% 到 10% 確實要花更多時間。建造自動化往往比你自己做還慢。」她接著鼓勵聽眾投資時間，把某個自動化磨到真的 100% 可靠，「沒什麼價值在一個 95% 通的自動化裡」。Lenny 在那個當下坦承自己就是這個錯誤的受害者，他把垃圾郵件分類做到 95% 準確，結果偶爾會把重要信件誤判到垃圾資料夾，反而帶來新的焦慮。Cat 自己也承認，她正在訓練 Cowork 幫她做 Gmail 收件匣歸零，目前還沒成功。

第二個建議是建構你每天真正會用的應用，而不是炫技用的原型。Cat 觀察到很多人在玩 AI 時，會做出許多酷炫的原型 app，但建好之後再也不打開。「我會推大家去蓋那些你真的每天都在用的 app，因為只有透過真實使用，你才真的拿到了價值。如果你蓋的原型沒有幫你完成更多事，那 AI 對你這天就沒真的加值。」她也提醒了相反方向的陷阱：花太多時間客製化工具、加一堆 skill 與 MCP，最後反而沒做出原本要做的核心東西。Lenny 順著這個觀察戳了一下 X 上常見的「秀我的 setup」風潮，Cat 直白回應：「我覺得簡單的 setup 其實效果更好。」

第三個建議是「Just do things」，這是 Cat 自己最常掛在嘴邊的座右銘。她解釋這背後的邏輯：「我覺得工作這件事是假的。如果你理解了限制條件，你可以推導出能做什麼，然後就快快做、從錯誤裡學、做錯了就道歉或修正。」她把這歸結為「first principles thinking」加上「跨團隊邊界執行」的能力。在很多公司裡，「PM 該做什麼」、「設計師該做什麼」、「這塊 code base 我們不能碰」被定義得很死，「Just do things」就是讓人感覺被授權去跨這些界線、把事情完成。Cat 認為這是新創公司值得在生涯某個階段體驗一次的原因，因為 20 人新創的環境會逼著你練出這個技能。

我的觀察一：「為下個模型留空位」是最違反工程習慣的紀律

Cat 在這集訪談中描述的所有產品哲學，最震撼的其實不是「快」，而是「主動為了未來重做」這個紀律。每一次模型升級都回去刪掉 system prompt 裡的拐杖、每一次都先蓋好還不能用的產品等模型追上、明知今天的某個功能會被下一代模型吃掉還是先把它蓋起來，這些動作對傳統工程紀律來說都是反過來操作。傳統軟體開發的金科玉律是「不要重複造輪子」、「不要在不確定的情況下出貨」，但 Anthropic 的產品哲學恰好挑戰了這兩件事。

對臺灣的開發者與 PM 來說，這個轉變的意義非常具體。我們過去靠「把產品做穩」、「把技術債還清」建立的工程聲譽，正在被「保持原型彈性、隨時準備被新模型重洗」這種更動態的能力取代。如果你今天為了補強 GPT-4.5 或 Claude Sonnet 4.5 的某個弱點，蓋了一個複雜的 prompt 結構或工具系統，你應該預期它在六個月內會被某代模型直接吃掉。這其實不是壞事，反而是你產品設計的成功，因為它證明了你選對了問題。但你也必須有紀律地回去把這套鷹架拆掉，否則它會變成你下一個版本的技術債。

「Build before it works」這個哲學在資源有限的環境下尤其值得思考。臺灣的小型團隊或新創常常陷入「等模型成熟再做」的迴圈，結果模型成熟那一天，市場已經被別人佔了。Cat 的訊息很清楚：你應該現在就蓋、即使你知道現在的模型還做不到，因為等你的原型變成可用產品的那一刻，你已經比任何「現在才開始做」的對手領先一個發布週期。這個策略需要的不是更多的工程資源，而是不同的心理姿態：願意在不完美的產品上投入時間，並且相信那個投入會在某個未來時點兌現。

我的觀察二：80% 不算自動化——臺灣團隊把 AI 用到一半就停下來的代價

Cat 那句「95% 不是自動化」應該被每一個用 AI 工具的人貼在螢幕邊。我在臺灣的科技公司觀察到一個普遍的模式：團隊會花兩週把某個工作流的 80% 自動化，到那個甜蜜點就停下來慶祝、發週報、做內部分享，然後再也不回頭把剩下的 20% 啃掉。問題是那 20% 通常不是可以無視的小尾巴，而是真實工作的多數情境。一個 80% 通的客戶分類流程，意味著每一百個客戶裡有二十個被丟錯桶；一個 80% 準確的會議紀錄整理，意味著每五次會就有一次必須全部重看。這些誤差堆起來的監督成本，會把自動化原本要省下的時間紅利全部吃掉。

為什麼臺灣團隊特別容易停在 80%？我覺得是因為臺灣的工程文化普遍把「可以 demo」當成完成的指標，而不是「可以信任」。一個 demo 起來很順的工作流，用在週會展示、用在向上對齊，很容易被算成「成功案例」。但 Cat 描述的標準完全不同：必須做到 100% 可靠，因為剩下的那 5%-10% 才是「監督疲勞的核心成本」，你只要還在看，你就還沒拿回時間。她自己訓練 Cowork 做 Gmail 收件匣歸零還沒成功，就是這個道理。當這件事必須真的不用再看一眼才算數，你才會發現中間有多少邊緣狀況需要解決，也才會發現 80% 跟 100% 之間其實是質變，不是量變。

對臺灣的工程團隊來說，下一個季度該做的不是再多做幾個 80% 的自動化，而是挑一個現有的 80% 自動化，把它磨到真的 100%，看看那個分水嶺後的世界長什麼樣子。在一個鼓勵秀 setup、秀 prompt 工程、秀技巧的時代，這個建議反而是最珍貴的逆風建議：與其每週貢獻一個新 demo，不如花一個月把一個舊 demo 修到能完全信任。前者是社群分數，後者才是真實的時間自由。