AI Native 產品節奏

資料來源#

• 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)

摘要#

Cat Wu 說明了 Anthropic 如何以令外界驚訝的速度進行發佈。每個產品功能的週期時間從 6 個月 → 1 個月 → 有時縮短至 1 天。其運作機制主要是減少流程，而非增加流程：透過 research-preview 品牌定位來降低內部承諾、以使命作為裁決準則來消除跨團隊協商、透過 evergreen launch room（常青發佈室）實現當天完成文件與行銷作業、對模糊的功能不撰寫 PRD，並以具備產品品味的工程師作為交付單位（參見 Engineer PM Convergence）。

What "fast" actually looks like#

• 團隊成員在週一提出想法 → 週五前 research preview 上線。
• 來源：Lenny：「有人製作了 Anthropic 全公司的發佈日程表，真的幾乎每天都有重大功能或產品發佈。」
• 個別功能「有時」能在 1 天內完成，這並非普遍現象——但大部分功能的週期是 1 個月，而業界常態則是一季。

What does not explain it#

Cat 被直接問到內部使用 Mythos 是否能解釋這樣的速度：

「這不完全是因為 Mythos。我們確實在內部使用這些模型，我認為這稍微提高了我們的發佈速度，但我認為這無法解釋大部分的提升。我認為很大程度上是流程以及團隊的預期。」

值得深思的是：模型並非瓶頸；流程才是。

Six practices that compose the cadence#

1. Research-preview branding#

大多數發佈都是以帶有明確標籤的 "research preview" 形式推出。這有助於：

• 設定使用者預期，讓他們知道該功能還處於早期階段且可能會改變
• 降低內部承諾——團隊不需要承諾永久支援該功能
• 容許在功能尚未完全開發完備時就進行發佈——在一個星期內將想法呈現給使用者，並根據回饋進行迭代

2. 以使命作為裁決準則#

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

這消除了最昂貴的協調成本：團隊之間的優先順序爭論。使命（「為人類帶來安全的 AGI」）高於任何單一產品。當團隊發生衝突時，由使命來做決定——而且「一旦決定，每個人都會全力支持該決定。」

這是透過共享價值觀來減少流程，而不是透過會議來增加流程。

3. Evergreen launch room#

「工程師會將 [開發完成的功能] 發佈在我們的 evergreen launch room。負責文件的 Sarah、負責 PMM 的 Alex，以及 Devril 的 Tar 和 Lydia 會立刻加入，並在隔天就完成行銷公告。」

這是一個常設頻道，已完成的功能可在當天獲得文件和行銷支援。這消除了耗費大多數團隊數週時間的線性交接流程（工程 → PM → 行銷 → 文件 → 發佈）。

4. 僅在需要時撰寫 PRD#

• 模糊不清的功能 → 單頁企劃書（1-pager）：目標、令人愉悅的使用場景、目前的失敗模式
• 重度依賴基礎設施的功能 → 完整的 PRD
• 大多數功能 → 不撰寫 PRD；透過指標讀出（metrics readouts）與團隊原則來完成對齊工作

Cat 的團隊原則列出了「誰是我們的關鍵使用者，為什麼他們是我們的關鍵使用者……這樣團隊中的每個人都能理解我們的業務是如何運作的，以及我們願意做出哪些妥協。」

5. 每週指標讀出#

整個團隊每週都會審查業務指標。這能將上下文資訊推播給所有人，因此個別決策不需要 PM 批准——團隊中的每個人對哪些做法有效都擁有相同的視角。

6. 以具備產品品味的工程師作為交付單位#

「我們團隊中的許多工程師完全有能力 end-to-end 地獨立完成工作，從在 Twitter 上看到使用者回饋，到在週末發佈產品，幾乎不需要產品團隊的參與。」

當工程師具備產品品味時，交接環節就消失了。PM 的角色變成了乘數效應的推動者（跨部門阻礙排除、制定團隊原則、做出更艱難的策略決定），而不是線性流程中的關卡。

關於跨學科的版本，請參見 Engineer PM Convergence。

What gets sacrificed#

Cat 指出了明確的權衡：

「我們正在犧牲產品的一致性。在過去，撰寫程式碼的成本很高，你會仔細規劃產品套件中的所有內容，以及每個產品之間的關係。現在隨著 AI 發展如此迅速，我們有時確實會出現功能重疊的情況。」

具體徵兆包括：

• 新使用者不知道哪個功能可以解決他們的問題（有多個功能可以解決，但方式略有不同）
• 使用者覺得「自己彷彿踩在一個速度越來越快的跑步機上」
• 對內建引導（onboarding）的需求（Claude Code 中的 /powerup 指令發佈較晚，這違反了最初『產品應該直覺易用』的原則，因為功能的數量增長超出了直覺所能理解的範疇）

Cat 將其形容為：「發佈大量功能的代價。」這是一個真實存在的代價，而不是一個無關緊要的問題。

What gets harder#

• 程式碼審查（Code review）。 當 agent 發佈更多程式碼時，人類需要審查的內容也會隨之增加。Matt Pocock 的坦白非常貼切：「老實說，我還不知道答案是什麼。」
• 品質門檻。 某些發佈的功能之 Bug 數量超出了 Cat 的預期。這是可以接受的，因為「只要不影響核心使用場景就沒關係，因為我們會聽到回饋，並在下一個版本中修復。」
• 職涯階梯 / 角色定位清晰度。 這是 Engineer PM Convergence 帶來的隱性代價。

Cultural substrate: face challenges with a smile#

「我們的團隊充滿了樂於擁抱混亂的人。我們試著微笑面對每一個挑戰，因為總是有太多事情在同時發生。總是有太多的風險和棘手的情況，如果你對任何事情都感到過度緊張，你很快就會筋疲力竭。」

招募知道如何在長期衝刺中保持精力的業界資深人士；偏好低自我（low-ego）的人，他們會將混亂視為令人興奮的事，而不是令人不知所措的負擔。Lenny 的觀察是：他遇到的每一位 Anthropic 員工都「既冷靜又樂觀」。

"Just do things"#

Cat 的人生座右銘。這捕捉了讓這種發佈節奏成為可能的底層基質：人們不等待授權，職責並非「虛設」，但角色邊界非常靈活，行動是預設選項。當這種特質與使命對齊相碰撞時，就產生了 Anthropic 的高速度。如果缺乏使命對齊，"just do things" 就會產生 drift。

獨立佐證：Anthropic Labs#

Dan Carey 在 2026 年 5 月關於在 Anthropic Labs 內部構建 Claude Design 的記述，獨立地重現了本頁面上的幾乎所有實踐——這是在一年後由另一個不同的團隊所進行的。Labs 在十週內運行了相同的循環「50 到 100 次」；大多數工作以 research preview 形式發佈；不撰寫 PRD、不撰寫願景文件、不召開 OKR 會議（參見 Prototype Over PRD）；每日發佈（「我們的目標是每隔一兩天就向使用者發佈一次」）；並將構建循環本身作為優化對象（參見 Compounding Loop Optimization）。速度的具體證明：**在週五推出和接下來的週一之間，共發佈了 62 項改進。**在 Cat Wu 讓 PRD 變得更輕量的地方，Carey 則完全去除了它們——將這種節奏推向了極限。

相關連結#

• 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 — 內部測試套件的精簡本身就是將此節奏應用於內部工具的範例
• 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 讓它們變得更輕量（單頁企劃書、指標讀出），Thariq Shihipar 則讓它們變得更豐富（互動式 HTML）——兩者都旨在保持人類對齊而不減慢速度
• Seven Powers Applied to AI — 構建 AI-native 是一種營運優勢（此發佈節奏），而不僅僅是策略優勢；護城河分析解釋了為什麼現有企業難以複製它
• Zero-Friction Scope Creep — Anthropic 的內部發佈節奏是「具備強大判斷力」的版本；缺乏這種判斷力基礎的初創創始人會面臨範圍蔓延的風險，而單靠節奏本身是無法解決的
• Evals as Product Spec — 使 6 個月→1 天的發佈節奏得以永續進行的迴歸防護欄；如果沒有「每個功能十個優秀 eval」作為安全網，每週/每月的發佈風險將會太大

待解決的問題#

• 這種發佈節奏能推廣到 100 人以上的規模嗎？Anthropic 本身規模更大（僅 PMs 就有約 30 到 40 人），但顯著推動這種節奏的 Claude Code 團隊規模很小。
• 對於預期穩定的 B2B 企業級發佈，與 research-preview 品牌定位等同的做法是什麼？Cat 並沒有對此進行解答。
• 這種發佈節奏有多少是結構性的（流程選擇），有多少是文化性的（人才密度）？可能兩者皆有，比例尚不明確。

衍生內容#

• Learning to Co-Work with AI: A Software Engineer's Field Guide — 品味校準循環和午餐時的氛圍檢查（vibe-checks）被採納為個人實踐
• AI-Native Product Org Bottlenecks — 將發佈節奏塑造成對負責品味的壓力測試：dogfooding 訓練它，evals 編碼它，問責制擁有它
• The PRD-Replacement Spectrum at AI-Native Speed — 較輕量化的 PRD 是光譜中經過校準的中間地帶；在此處劃分了更輕量化 vs 更豐富的產出物（artifact）之軸線

資料來源#

• 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