「Claude 自己在養自己」：Anthropic 用 Claude 自動化成長的 CASH 計畫、PRD 之死、與兩週規則

本文整理自《Lenny's Podcast》2026 年 4 月 5 日播出的單集，受訪者為 Anthropic 成長負責人 Amol Avasare。本系列共三篇，這是第二篇談 AI 自動化工作流，第一篇談商業故事與營運哲學，第三篇談 notebook channels 與職涯哲學。

{{< youtube k-H4nsOTuxU >}}

{{< spotify "episode/08QWCmKgDbMfpojknVW5Fa" >}}

{{< apple-podcast "tw/podcast/head-of-growth-anthropic-claude-is-growing-itself-at/id1627920305?i=1000759379580" >}}

---

CASH：Anthropic 把成長外包給 Claude

這集訪談的標題其實藏著最重的訊息，叫做「Claude is growing itself at this point」（Claude 現在已經在養大自己）。Lenny 不是隨口取這個名字。Anthropic 內部有一個正在跑的計畫叫做 CASH，全稱是 Claude Accelerates Sustainable Hyper-growth（Claude 加速可持續超級成長），由前 Reforge 成長工程講師 Alexei Komisaruk 親自帶進公司主導。它的目標說起來像科幻小說：讓 Claude 自己跑成長實驗，從找出機會、寫出程式碼、上線測試、到事後分析，整條鏈路都不靠 PM 親自操刀。

Amol 把 CASH 的工作流拆成四個階段，逐一檢驗 Claude 在每個階段的能力。第一階段是「機會發掘」（opportunity ID）：模型要看完上週的數據、抓出值得測試的假設，例如「我們的新使用者在第三步流失最嚴重，可以試試新的 onboarding quiz」。第二階段是「實作」（building）：模型直接動手寫文案、改 UI 程式碼、串資料管線。第三階段是「測試」（testing）：把實驗推到生產環境、控制流量、跑完統計。第四階段是「上線後分析」（post-ship analysis）：模型會回頭整理結果、判斷該不該全量上線、把學到的東西寫進團隊知識庫。

Amol 給 CASH 目前能力的評語非常具體：在文案改寫和小型 UI 實驗上，Claude 已經能達到「資深三年 PM 的勝率」。這個基準不是泛泛的客氣話。Anthropic 內部會把 Claude 跑出來的實驗結果跟同題目給人類 PM 跑出來的結果做對比，計算贏率（win rate）。Amol 說自從 Opus 4.5 與 4.6 系列上線之後，這個贏率有一次明顯的躍升，直接跨進可信任的範圍。換句話說，過去要花一個 PM 兩三天的小實驗，現在 Claude 自己就能完成。

但 CASH 也有它的天花板。Amol 老實承認，整個流程裡有一個階段 Claude 完全做不來，那就是跨職能的協調與對齊。「直到我們有了 AGI，要把六個人關在同一間會議室達成共識，仍然會是不可能的事。」Amol 引用 Anthropic 設計負責人 Joel 的這句話，幾乎是這集訪談裡最鋒利的一句金句。它的意思是說，CASH 可以幫你寫程式、跑數字、做分析，但它沒辦法跟法務談紅線、跟銷售談配合節奏、跟客服談知識庫更新；這些「拉人對齊」的工作至少在可見的未來仍然是人類 PM 不可被取代的核心。

Amol 的個人 Claude 外骨骼：每天 25 張圖、每週掃 Slack 找對齊問題

CASH 是組織級的自動化，但 Amol 自己在訪談裡花了同樣多的時間講他個人版本的 AI 工作流。他用 exoskeleton（外骨骼）這個詞描述 Claude 對他個人的角色：不是替他工作，而是讓他這個人能扛起本來扛不動的工作量。整套外骨骼有四層，每一層都是任何一家用 Claude 的公司今天就能照搬的做法。

第一層是每天早上的圖表 triage。Amol 設定了一個 Claude 的排程任務（scheduled coworker task），每天早上自動連到 Hex（Anthropic 內部的數據儀表板平台）打開 20 到 25 張關鍵圖表，配合 Chrome 擴充功能擷取圖像、判讀趨勢、把任何需要他注意的異常整理成一份簡報。「我以前每天早上要花 45 分鐘看圖表，現在 Claude 5 分鐘就把該注意的東西挑出來給我。」Amol 說，這 40 分鐘讓他可以多開一個一對一會議、或者把更多腦袋放在大方向決策上。

第二層是每週的對齊掃描。Amol 透過 Slack 的 MCP（Model Context Protocol）把 Claude 接到他追的所有專案頻道，每週一次跑一個 prompt：「掃過去七天我追的所有頻道，告訴我哪裡有跨團隊的對齊不一致、哪些決策被不同人講成兩個版本、哪些 blocker 還沒被處理。」他描述模型的表現「會在『你怎麼會把這個拿出來講』跟『天啊好險我有抓到這個』之間擺盪」，但訊號的命中率正在快速上升，已經比他自己用人腦掃描還可靠。

第三層是模仿主管的 coaching。Amol 的主管是 Anthropic 現任產品長 Ami Vora，她過去在 WhatsApp、Meta 都帶過大型產品團隊，並且公開寫過很多關於產品管理的文章。Amol 把她所有的公開文字加上他們之間的 Slack 對話，餵給 Claude 當 context，然後固定問 Claude 一個問題：「以你對 Ami 的了解，她對我這週的這個決策會給什麼回饋？」結果是，他得到一個能模擬主管視角的「鏡像 coach」，可以隨時 sanity check 自己的判斷。第四層是收件匣與報帳的全自動處理，這部分聽起來最瑣碎，但 Amol 說它每週為他省回兩到三小時。

PRD 之死：60-80% 出貨沒有規格文件

Lenny 在訪談中問 Amol 一個許多 PM 會關心的問題：在 Anthropic 你們還寫 PRD（Product Requirements Document，產品需求文件）嗎？Amol 的回答非常直接：「我對 PRD 有強烈的偏見，我覺得我就是討厭文件。我都是『go go go，砍掉所有 blocker』的那種人。我們出貨的東西裡，60% 到 80% 是沒有 PRD 的。」這個比例放在傳統矽谷大公司會被當成異端，但在 Anthropic 已經是預設模式。

要理解為什麼可以這樣運作，先要看 Amol 怎麼分類專案。最小的事情，例如「把某個 CTA 從藍色改成綠色」、「在 onboarding 第二步加一個 tooltip」，完全在 Slack 上談完就直接做。中型的事情，例如「重新設計付費方案」、「上一個新通路」，會開一個 30 分鐘的 kickoff 會議，把法務、安全、客服、設計、跨職能 BD 全部拉進來，一次把所有的紅線、限制、依賴對齊清楚。這個 30 分鐘的會議取代了傳統 PM 寫一份 20 頁 PRD、然後跑一輪一輪 review 的流程。

那真正需要 PRD 的場景是什麼？Amol 說他自己會留 PRD 給「策略性大型專案，例如新的產品線、跨季規劃」這類需要一個可以長期被引用的文件的場景。他甚至寫了一個 Claude skill 來幫他寫 PRD：把過去寫過的 PRD 全部放進 Claude 專案當作 reference，需要寫新的 PRD 時就讓 Claude 先產生草稿，他再修。換句話說，連那少數還需要寫 PRD 的場景，PM 也不再是那個從零打字的人。

更耐人尋味的是 Amol 描述的另一個趨勢：「prototype is increasingly the spec」（原型越來越是規格本身）。當你可以用 Claude Code 在一個下午做出一個能跑的原型，你還需要寫一份描述「這個東西未來應該長什麼樣」的文件嗎？原型本身就是最精準的 spec，比任何描述都更不容易被誤解。Amol 預測這個趨勢會繼續吃掉 PRD 的剩餘領地，未來真正需要文件的場景會越來越少，PM 的價值也會從「寫清楚」轉移到「決定做什麼」。

兩週規則：少於兩週的專案，工程師就是迷你 PM

如果 PRD 死了，那 PM 的工作流還剩下什麼？Amol 給出的答案是 Anthropic 內部叫做 the two-week rule 的明確規則。任何工程時間少於兩週的專案，PM 不再參與，整個責任完全交給負責的工程師當「迷你 PM」：他要自己跟法務確認紅線、自己把安全議題喬完、自己拉跨職能的對齊、自己決定要不要做 A/B 測試。PM 只在這條線之外的長期專案才繼續扛責任。

這條規則的存在前提是「product-minded engineer」（有產品意識的工程師）這個物種已經越來越普遍。Amol 觀察到，現在 Claude Code 讓工程師的產出量提升 2 到 3 倍，工程容量已經明顯超過 PM 與設計能消化的速度。如果不重新分配責任，PM 會變成「擋住工程師出貨的 bottleneck」，這跟成長 PM 應該扮演的加速器角色完全相反。兩週規則就是把這個 bottleneck 在制度上拆掉。

對 PM 角色的影響非常深。Amol 在訪談裡老實說，現在 Anthropic 內部，工程師從 AI 工具拿到的槓桿明顯比 PM 與設計師多。這意味著兩件事：第一，PM 的單位產出價值要往上拉，否則就會被組織擠壓；第二，傳統那種「PM 負責出第 21 個小功能」的工作方式必須結束，因為這種工作工程師自己就能完成。PM 的新定位是「把組織能力拉高一級」：制定策略、把跨季的方向講清楚、做關鍵的取捨判斷，而不是再去寫第 22 個 user story。

那設計呢？Amol 沒有迴避這個問題。他說設計師現在的處境跟 PM 類似，也被工程的高槓桿擠壓著。Anthropic 的應對方式是兩條路一起走：一條是繼續招更多 PM 與設計，但只招那些能跨界的「獨角獸」，例如「能寫程式的 PM」、「會做產品的工程師」、「在金融服務有十年經驗的 PM」；另一條是讓現有的 PM 與設計往上拉，從執行者變成方向制定者。前者解決短期容量，後者解決長期定位。

我的觀察一：臺灣公司還在補 AI 工程師，已經錯過 PM 角色重組的時間窗

我看臺灣公司過去半年大量在徵 AI 工程師、招 prompt engineer、買 GitHub Copilot 的訂閱，這些都是必要的動作，但都還停留在「給工程師更好的工具」這個層次。Amol 描述的故事是更深一階的事情：當你的工程師已經有 AI 工具，他的產出速度會擠壓 PM 與設計的傳統定位，這時候你要重新設計責任分配，否則組織會自我堵塞。臺灣多數公司還沒走到這一步，但這個時間窗會非常短。

最直接可以借鏡的是「兩週規則」。臺灣很多 SaaS 公司或軟體團隊習慣 PM 一路盯著每個小功能到上線，這個習慣在 Claude Code 還沒普及前是合理的；但當你的工程師已經能用 AI 把兩週的工作壓到三天，這種盯法會直接變成阻礙。建議任何已經有 PM 體系的團隊，這一兩個月就該找一個「短專案」試試 Amol 的兩週規則：明確告訴工程師「這個專案 PM 不參與，你自己拉法務、安全、客服對齊」，看看會發生什麼。多數情況下你會發現，工程師其實做得到，只是過去 PM 不放手而已。

第二件值得做的是個人版的 Claude 外骨骼。Amol 描述的四層工作流（圖表 triage、Slack 對齊掃描、主管 coach、收件匣自動化）都是用今天就能買到的工具就能組起來的，臺灣的 PM、營運主管、甚至中小企業老闆都應該嘗試。我自己最近開始用 Claude 看 GA 報表的關鍵圖表，光是省下那 30 分鐘的「每天早上掃儀表板」就足以改變一整週的時間結構。這套外骨骼的核心不是技術，而是「把哪些自己做的事情交給模型、哪些事情留給自己」這個判斷。

我的觀察二：CASH 不是噱頭，是 PM 角色的終局預演

CASH 計畫聽起來很科幻，但它真正的訊息不是「Claude 能寫文案了」，而是「公司開始有勇氣把成長 KPI 直接掛到模型身上」。這是一個質變。過去十年所有的成長 PM 都在學 A/B 測試、學 Bayesian 統計、學如何寫實驗設計文件；CASH 的存在意味著這些技能正在被自動化，未來成長 PM 的價值會集中在兩件事：一是定義要測什麼問題（model 還做不到的判斷力），二是處理需要說服多人的跨職能對齊（model 永遠搬不動的人類問題）。

對臺灣的 PM 來說，這是一個職涯轉折的訊號。如果你的工作八成是寫實驗設計、看 A/B 結果、整理週報，這些事情未來兩三年內會大量被自動化。你必須提前累積另外兩種能力：一是策略判斷，能看出哪些測試該做、哪些不該做，這需要對業務、對市場、對使用者的深度理解；二是組織導航，能在公司裡讓對的人在對的時候達成對的決定，這需要長期累積的人脈與信任。這兩件事 CASH 完全做不到，也是 PM 在 AI 時代真正的護城河。

最後一個值得思考的點是 Amol 那句「直到我們有了 AGI，要把六個人關在同一間會議室達成共識，仍然會是不可能的事」。這不只是金句，它精準地指出了人類在組織裡仍然不可被取代的角色：協調、信任、共識。如果你正在規劃自己未來五年的能力路徑，把時間投資在這條軸線上的回報，遠比再學一個新框架、再考一張證照來得實際。