AI Native Product Cadence

資料來源#

• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next
• Designing with Claude: From prompt to production
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
• Inside AI-pilled engineering teams: Five lessons for scaling without losing the plot

摘要#

Cat Wu 說明 Anthropic 如何以令旁觀者驚訝的速度推出產品。每項產品功能的週期時間從 6 個月 → 1 個月 → 有時只要 1 天。背後的做法主要是移除流程，而非增加流程：以研究預覽品牌降低承諾、以使命作為決勝依據來消除跨團隊協商、設置常設發布室讓文件與行銷能在同一天完成、不確定的功能不寫 PRD，以及以具備產品品味的工程師作為交付單位（參見 Engineer PM Convergence）。

「快」實際上是什麼樣子#

• 團隊成員週一提出的點子 → 週末前以研究預覽形式上線。
• 來源：Lenny：「有人整理了一份 Anthropic 的發布日曆，裡面真的每天都有一項重大功能或產品推出。」
• 個別功能「有時」只花 1 天，不代表大多數都如此——不過大多數只需一個月，而業界常態是一季。

什麼因素並不能解釋這件事#

有人直接問 Cat，內部能使用 Mythos 是否解釋了這種速度：

「這不完全是 Mythos 的功勞。我們確實在內部使用這些模型，我認為這讓我們的發布速度稍微提升，但我不認為它能解釋大部分的增幅。我認為很大一部分來自流程，以及團隊對自己的期待。」

請認真看待這一點：瓶頸不是模型，而是流程。

共同構成這種節奏的六項做法#

1. 研究預覽品牌#

多數發布都明確標示為「研究預覽」。這麼做可以：

• 讓使用者知道功能仍在早期階段，之後可能變動
• 降低內部承諾——團隊不會因此被綁定，必須永遠維護該功能
• 允許功能尚未完整就先推出——一週內讓使用者試用點子，再依據回饋反覆改進

2. 以使命作為決勝依據#

「如果有兩個互相競爭的優先事項，我們會討論哪一個對 Anthropic 的使命更重要。」

這消除了成本最高的協調工作：團隊之間的優先順序爭辯。使命（「為人類打造安全的 AGI」）高於任何單一產品。團隊發生衝突時，由使命決定——而且「大家都會支持我們最後做出的決定」。

這是透過共同價值觀移除流程，而非藉由開會增加流程。

3. 常設發布室#

「工程師會把[完成的功能]貼到我們常設的發布室。負責文件的 Sarah、負責 PMM 的 Alex，還有 Devril 的 Tar 和 Lydia 都會直接加入，隔天就能完成行銷公告。」

這是一個常設管道，完成的功能能在同一天配上文件與行銷內容。它省掉了大多數團隊要花上好幾週的順序交接（工程 → PM → 行銷 → 文件 → 發布）。

4. 只在必要時撰寫 PRD#

• 不明確的功能 → 一頁文件：目標、令人驚喜的使用情境、目前的失敗模式
• 重度基礎設施功能 → 完整 PRD
• 大多數功能 → 不寫 PRD；由指標檢視與團隊原則來協助取得共識

Cat 的團隊原則列出「我們的關鍵使用者是誰、為什麼這些人是關鍵使用者……讓團隊裡每個人都能理解業務如何運作，以及我們願意在哪些地方取捨」。

5. 每週檢視指標#

整個團隊每週檢視業務指標。這會把背景資訊提供給大家，讓個別決策不必經過 PM 核准——團隊裡每個人都能用同一個角度了解哪些做法有效。

6. 由具備產品品味的工程師負責交付#

「我們團隊裡很多工程師都能全程端到端地完成工作，從在 Twitter 上看到使用者回饋，到週末前推出產品，幾乎不需要產品團隊介入。」

工程師具備產品品味，交接就會消失。PM 的角色成為倍增器（跨職能排除阻礙、建立團隊原則、處理更艱難的策略決策），而非一道順序關卡。

跨領域版本請參見 Engineer PM Convergence。

必須付出的代價#

Cat 清楚說明了取捨：

「我們犧牲了產品一致性。過去寫程式碼成本很高時，你會仔細規劃整個產品組合，以及每項產品之間的關係。現在 AI 發展得這麼快，我們有時確實會推出彼此重疊的功能。」

具體表現：

• 新使用者不知道該用哪項功能解決問題（有好幾項都能解決，只是方式略有不同）
• 使用者覺得「自己正處於一台愈轉愈快的跑步機上」
• 需要內建引導流程（Claude Code 的 /powerup 指令推出得較晚，違背了最初「產品應該直覺易用」的原則，因為功能數量成長得比直覺體驗更快）

Cat 將其稱為「大量推出功能的代價」。這是真實的代價，不是無關緊要的小事。

變得更困難的事#

• 程式碼審查。 代理程式交付更多程式碼，人類就得審查更多。Matt Pocock 的坦白也適用於此：「老實說，我還不知道答案是什麼。」
• 品質門檻。 有些已發布的功能比 Cat 希望的更容易出錯。之所以能接受，是因為「只要沒妨礙核心使用情境，就沒關係，因為我們會收到回饋，並在下一次發布時修好。」
• 職涯階梯／角色清晰度。 這是 Engineer PM Convergence 隱含的代價。

文化基礎：帶著微笑面對挑戰#

「我們團隊裡的人都會迎向混亂。我們努力帶著微笑面對每項挑戰，因為事情總是很多。風險和棘手狀況總是層出不窮，如果每件事都讓你壓力過大，就會精疲力竭。」

聘用有資歷的業界人士，因為他們知道如何在漫長的成長期維持活力；偏好自我意識較低的人，把混亂視為令人興奮，而不是難以招架。Lenny 的觀察是，他遇過的每位 Anthropic 員工都「沉著而樂觀」。

「就去做」#

這是 Cat 的人生座右銘。它概括了讓這種節奏得以實現的基礎：人們不會等待許可，工作不是「假的」，但角色界線很有彈性，行動才是預設選項。當這種做法與使命一致，就能帶來 Anthropic 的速度。若沒有使命一致性，「就去做」只會造成偏離方向。

獨立佐證：Anthropic Labs#

Dan Carey 在 2026 年 5 月談到他如何在 Anthropic Labs 內打造 Claude Design，獨立重現了本頁幾乎每一項做法——團隊不同，時間晚了一年。Labs 在十週內執行同一個循環「50 到 100 次」，大多數工作以研究預覽形式推出；沒有寫 PRD、願景文件，也沒有 OKR 會議（參見 Prototype Over PRD）；每天發布（「我們的目標是每天或每兩天讓使用者用到新版本」）；並把打造產品的循環本身當作優化目標（參見 Compounding Loop Optimization）。具體的速度證明：從週五發布到接下來的週一，推出了 62 項改進。 Cat Wu 讓 PRD 變得更精簡，Carey 則完全移除 PRD——把這種節奏推向極限。

結構性做法：將交付與發布分開#

Ramp（Geoff Charles，CPO；case-study，2026 年 6 月）以一項結構調整，解決了本頁六項做法從文化面處理的相同速度與品質問題。其起始條件正是上述每項做法背後的前提：團隊「每天都會交付重大新功能」，這「讓領導層幾乎不可能完全掌握最新進度」。

兩個層級，關卡從交付決策移開。 團隊準備好時就能隨時發布給早期使用者層級——不需核准。大約10% 的 Ramp 客戶選擇加入，形成一個由 5,000 多家企業組成的固定測試群體。只有從早期使用者層級升級至全面供應才需要通過關卡，而且要憑證據審核一份七項制式清單：打造了什麼、為什麼打造；一段不超過 3 分鐘的 Loom 示範；早期使用期間觀察到的 KPI；客戶回饋；新使用者首次使用流程；銷售與支援準備情況；以及包含發布層級、定價和溝通內容的推出計畫。許多資料組裝工作由接上 Ramp 系統的 AI 自動完成，審核則採用預設 48 小時後自動發布的 SLA——主管若未在兩天內審查，功能就會推出。

有三點讓這個做法與上述方式不同，而非只是換句話重述：

• 這和研究預覽品牌（#1）是同一個洞見，只是從命名慣例轉變為客戶分群。 研究預覽降低了發布帶來的預期；早期使用者層級降低了曝險範圍。前者是對使用者的承諾，後者是一群實際使用者——只有後者能產生升級關卡所需的 KPI 證據。
• 證據循環能夠閉合。 清單要求「早期使用期間的 KPI」，只有早期層級存在時，這項要求才有辦法達成。這具體呈現了 Nathan 在下文提出的循環完成度指標：功能若發布到早期使用層級後始終沒有蒐集證據，就永遠不會升級，因此循環未完成的情況天生就看得見，不必依靠紀律去發現。
• 預設方向反轉了。 48 小時審核期限一到就預設發布，會把關卡拖延的代價轉嫁給把關者。比較 Prototype Over PRD 與做法 #4——核心想法相同（移除讓領導層成為瓶頸的文件），只是從核准流程延伸到規格撰寫。

來源沒有提供的一項資訊是：這種雙層關卡是否保住了品質的任何測量結果。文中提到 5,000 家企業的測試群體與 48 小時 SLA，但沒有提供瑕疵、回復或升級資料；而 Ramp 是出版者的投資組合公司。

節奏帶來的測量問題：忙碌與進展#

上述所有做法都在最佳化產出量。Akshay Nathan（OpenAI，生產力工程）指出了這種最佳化可能招致的失敗模式，也是本頁最尖銳的反面觀點（Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI，practitioner-opinion）：

「或許陷阱就在於把忙碌和進展混為一談。我認為，現在因為有這些工具，製造忙碌比以前容易多了。但要取得進展，你必須非常明確而審慎地說清楚想達成什麼。」

有人直接問他，團隊「加了很多 LLM，也替這個那個做了儀表板，但實際上沒什麼改變」是否陷入陷阱，他只用一個詞回答：「沒錯，那就是陷阱。」

代理指標失效了。 Nathan 說明原因：團隊一直想衡量的是「是否達成目標」，但因為目標無法直接測量，所以改用代理指標——提交次數、程式碼行數、故事點數。在代理程式出現後，代理指標與目標脫鉤：「你用了多少 token 或建立了多少個 pull request，不再和你的團隊能否達成目標高度相關。」這也適用於上文做法 #5（每週檢視指標）：如果有人沒有另外定義進展的意思，只用已發布的功能數量衡量節奏，那衡量的就是忙碌。一般性的測量工具問題可參見 Telemetry vs. Survey Measurement；也要留意，OpenAI 在使用者端面臨相同的缺口——Nathan 直言，衡量產品是否提升了使用者的生產力仍未解決（「我們還沒弄清楚……每個人的目標都不同」），而讚或倒讚也無法解讀，因為你無從分辨使用者評價的是內容、感受，還是結果。

他的替代方案是衡量每次嘗試的品質，而非次數。「我們這個團隊是不是正在培養一種能力，不只增加嘗試次數，也提升每次嘗試的品質？我們能不能一路完成從產生點子、打造出來、取得回饋、根據回饋調整，到驗證或推翻假設，再繼續下一個點子的整個過程？」這是循環完成度指標，而非產出指標——它計算完整的點子→打造→回饋→判斷循環，因此一個速度很快、卻從未完成循環的團隊，得分就是零。他明確把團隊文化也納入其中（「願意謙遜地……反覆經歷這個流程，並保持動力」），因此照他目前的說法無法測量；應把它視為一種思考框架，而非測量工具。

延伸閱讀#

• Cat Wu — 主要闡述者
• Dan Carey — Anthropic Labs 的獨立佐證（Claude Design 開發）
• Prototype Over PRD — 本頁精簡 PRD 做法推到不寫 PRD 的極限
• Compounding Loop Optimization — 推動這種節奏的逐循環最佳化方法
• Anthropic Labs — 在團隊層級執行這種節奏的賭注工廠
• Boris Cherny — 趨同的觀察（「我們只規劃未來一週」）
• Engineer PM Convergence — 讓這種節奏得以運作的角色架構
• Harness Shrinkage as Models Improve — 內部 harness 的精簡，本身就是將這種節奏應用於內部工具的例子
• Claude Character as Product — 角色設計以相同節奏推進；Amanda 的迭代循環是一個緊湊的例子
• Claude Code Best Practices — 以此節奏運作的團隊所公開的實作成果
• Human-AI Accountability Redesign — 內部節奏重設在跨職能與工作者層面的對照；HBR 的建議將 Anthropic 的做法推廣開來
• AI Employee Framing — 反駁「擬人化能加速採用」；依 HBR 所言，真正能加速採用的是管理者以身作則，這與 Cat 的「人人都寫程式」做法一致
• HTML as the New Markdown — 對高速撰寫 PRD 的相反選擇：Cat 讓 PRD 更精簡（一頁文件、指標檢視），Thariq Shihipar 則讓它們更豐富（互動式 HTML）——兩者都旨在讓人保持共識，同時不拖慢速度
• Seven Powers Applied to AI — 打造 AI 原生產品帶來的是營運優勢（這種節奏），不只是策略優勢；護城河分析說明了為何既有業者難以輕易複製
• Zero-Friction Scope Creep — Anthropic 的內部發布節奏，是搭配強判斷力的版本；缺乏這種判斷力基礎的初次創業者，會面臨單靠節奏無法解決的範疇蔓延風險
• Evals as Product Spec — 讓 6mo→1day 節奏能持續下去的回歸防護；若沒有每項功能十個優秀 eval 作為安全網，每週或每月發布都會太冒險
• Telemetry vs. Survey Measurement — 「忙碌與進展」背後的測量工具問題：容易蒐集的檢視數據，往往正是那些已與結果脫鉤的指標
• Organizational Complements to AI — AI 原生組織一開始就具備這種節奏所依賴的工作流程、審查與工具配套，而非事後補上；流程實驗成本低，正是代理式 AI 配套可能比電氣化更快普及的原因

尚待解答的問題#

• 這種節奏能否擴大到約 100 人以上？Anthropic 本身規模更大（單是 PM 就約有 30 到 40 人），但明顯帶動節奏的 Claude Code 團隊規模很小。
• 在客戶期待穩定性的 B2B 企業發布中，研究預覽品牌有什麼對應做法？Cat 沒有談到。
• 這種節奏有多少來自結構（流程選擇），又有多少來自文化（人才密度）？兩者可能都有，比例不明。

衍生文章#

• Learning to Co-Work with AI: A Software Engineer's Field Guide — 將品味校準循環和午餐時的氛圍檢視轉化為個人實踐
• AI-Native Product Org Bottlenecks — 將節奏視為負責任產品品味的壓力測試：實際使用能培養品味，eval 能將其編碼，責任制度則由人承擔
• The PRD-Replacement Spectrum at AI-Native Speed — 精簡 PRD 是光譜上經過校準的中間地帶；本文則劃分出文件精簡與豐富程度的軸線

資料來源#

• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next
• Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI — Latent Space，2026-07-28（practitioner-opinion）：Akshay Nathan 談忙碌與進展正是那個陷阱、提交／LOC／PR／token 代理指標如何崩解，以及以每次嘗試的品質作為替代思考框架
• Inside AI-pilled engineering teams: Five lessons for scaling without losing the plot — Bessemer Atlas，2026-06-10（case-study）：§1，Ramp 的雙層發布關卡——早期使用約涵蓋 10% 的客戶（5,000 多家企業），升級至 GA 需通過七項證據清單，以及預設 48 小時後發布的審查。Geoff Charles 是 Bessemer 投資組合公司的 CPO；流程說明未附帶品質數據