Anthropic 产品速度密码
40天30+功能、模型吃掉产品、PM与工程师融合——解读 Claude Code 产品负责人 Cat Wu 的产品观与方法论
40天30+ 功能上线
6→1个月迭代周期压缩
3板斧核心机制
4层洞察提炼
01 · 研究概述
这份调研是什么
本报告基于 Lenny's Newsletter 与 Anthropic Claude Code 产品负责人 Cat Wu 的深度访谈（2026-04-22 发布），结合 PM Daily Digest 第三方独立分析，以及两篇国内高质量解读文章，经多源交叉验证后整理而成。
研究核心问题
Anthropic 如何在 AI 时代实现几乎每天一个新功能上线的产品速度？背后的方法论、组织结构和产品哲学是什么？这种模式的代价是什么、又对其他团队有何参考价值？
信源质量说明
主信源：Lenny's Newsletter 第一手深度访谈（P1级）。交叉验证：PM Daily Digest 独立分析（P2级，明确指出 watch out 条件）。Cat Wu 本人公开在访谈中承认了速度的代价，未被国内解读充分放大。
02 · 速度数据
快到什么程度
数据来自 Cat Wu 访谈原文，经 PM Daily Digest 独立引用验证。
40天
30+ 功能上线（2026年初）
6→1个月
功能迭代周期压缩
1天
最快单功能上线周期
6个
用户平均同时运行 Claude 实例（2025年底）
行业传统 / 2020年前
6–12个月功能周期
立项→设计→评审→研发→测试→发布，全链路走完往往需要半年到一年。
Anthropic 现状 / 2025–2026
压缩至 1个月→1周→1天
三板斧机制下，大部分功能 1个月内上线，部分功能 1周，最快的当天就能发出。
未来路线图 / 2026+
50–100个 Claude 并行
从当前 6个并行实例，演进到几十上百个 Claude 同时在云端处理任务的阶段。
03 · 三板斧机制
速度的三个核心机制
Cat Wu 明确表示："大部分加速来自流程和团队文化，而不是内部使用了更强的模型。"
机制 01
目标锁定 — 先定义用户与场景
LLM 太通用，团队必须先锁定"核心用户是谁""要解决的具体问题是什么""成功的衡量标准是什么"，才能让工程师自主决策而不等 PM 拍板。
典型例子：某功能目标是"让企业开发者安全实现零权限提示"，这一句话排除了 90% 不相关方案。
目标即过滤器
典型例子：某功能目标是"让企业开发者安全实现零权限提示"，这一句话排除了 90% 不相关方案。
机制 02
Research Preview — 降低发布门槛
所有功能以"研究预览"形式发布——明确告知用户这是早期版本，可能不会永久保留。这样一来，不需要做到完美才发布，1–2 周就可以把东西推出去。
这是一种信任合约：Anthropic 用透明换速度，用户用宽容换早期体验。
信任合约换速度
这是一种信任合约：Anthropic 用透明换速度，用户用宽容换早期体验。
机制 03
Evergreen Launch Room — 极简协作管道
工程师认为功能准备好了，直接发进 Slack 频道"launch room"。Docs 负责人、PMM、DevRel 等成员收到后，第二天就能交出上线公告。
整个协调成本极低，低到让每个工程师都敢直接把想法推出去。
次日交付
整个协调成本极低，低到让每个工程师都敢直接把想法推出去。
"我们希望移除一切阻碍发布的障碍。团队里每个人都应该能在一周之内，甚至一天之内，把自己的想法变成产品。"
PM Daily Digest 独立指出的代价（Watch Out）
Anthropic 自己也承认：这套模式的代价是产品一致性下降——两个团队会同时做同一件事，用户发现负担上升（/powerup 功能的出现正是为了解决"功能太多不知用哪个"的问题）。速度快时，onboarding 需要加倍。
04 · 模型吃功能
每次新模型上线，第一件事是删功能
这是 Cat Wu 访谈中最具洞察力的一个观点，也是"速度"的隐形加速器。
"每次发布新模型，我们都会通读整个 system prompt，逐段反思：模型还需要这个提醒吗？如果不需要了，就删掉。"
To-Do List 功能的消亡案例
早期 Claude Code 有 to-do list 功能，因为当时的模型做大规模代码重构时会漏改调用点。团队靠"让模型先列清单再逐个完成"的方法弥补了模型能力缺口。
Opus 4 发布后，模型自己就能主动列清单并逐一完成——to-do list 从"必要的拐杖"变成了"可有可无的辅助界面"。
来源：Lenny's Newsletter × Cat Wu (2026-04-22)
Opus 4 发布后，模型自己就能主动列清单并逐一完成——to-do list 从"必要的拐杖"变成了"可有可无的辅助界面"。
代码审查：等到模型能力匹配才真正发布
代码审查功能开发了多个版本，但准确率一直不够。直到 Opus 4.5 / 4.6 出来才达到真正可依赖的水平——现在 Anthropic 内部合并 PR 之前，必须先过 Claude 的代码审查。
这印证了 Cat Wu 的另一个原则：提前做好还没完全能用的产品原型，等新模型出来时直接换上去看差距有没有被弥合。
来源：Lenny's Newsletter × Cat Wu + cryptorank.io 新闻验证
这印证了 Cat Wu 的另一个原则：提前做好还没完全能用的产品原型，等新模型出来时直接换上去看差距有没有被弥合。
Lenny 的类比："模型会把你的 harness 当早餐吃掉"
在 AI 产品开发中，很多"功能"其实是在弥补模型能力的不足。模型越强，需要弥补的越少，产品代码越轻——这是 AI 原生产品的独特剪枝逻辑。
05 · 角色融合
PM 与工程师的边界正在消失
Cat Wu 采访了数百位想进 Anthropic 做 PM 的人，发现大多数人还在用旧时代的思路。
贬值
传统 PM 核心技能：多季度路线图、跨团队协调、等所有人对齐
升值
新核心稀缺力：产品品味 — 代码越便宜，决定写什么越贵
"代码变得越来越便宜了。那什么变得更有价值呢？决定写什么。"
工程师自主发布功能的比例（Anthropic 内部）
~80%
有工程背景的 PM / 设计师占比
~100%
PM 与工程师判断一致率（Cat Wu × Boris Cherny）
~80%
Marty Cagan 的对照视角（独立验证来源）
PM Daily Digest 引用了 Marty Cagan 的三种 PM 模型分类：①积压订单拥有者（软件工厂）②路线图驱动 ③赋能产品型 PM。他认为前两种直接被 AI 自动化威胁，第三种因为"拥有成果、快速发现、方案塑造"而保持价值——与 Cat Wu 的结论高度一致。
06 · 使命筛子
速度的深层原因：不是工程能力，是使命对齐
PM Daily Digest 将此提炼为："速度是公司级决策系统的产物，而不是更快的工程栈。"
使命提供决策过滤器
Anthropic 不做社交网络、不做资讯 Feed——这些方向可能赚钱，但不符合"安全 AGI"的使命，直接被过滤掉。这让团队在一个四处扩张的行业里保持了极高的执行密度。
专注 > 扩张
团队愿意牺牲本地目标
Cat Wu 说了一句让人印象深刻的话："如果 Claude Code 失败了但 Anthropic 整体成功，我会很开心。"
跨组织协调之所以快，是因为每个人都已经把公司使命内化，不需要在本地目标和全局目标之间反复拉扯。
使命内化
跨组织协调之所以快，是因为每个人都已经把公司使命内化，不需要在本地目标和全局目标之间反复拉扯。
"工作本来就是假的。如果你理解了约束条件，你就能想出该做什么，然后就去做。快速行动，从错误中学习，如果做错了就道歉并修复。"
07 · 核心洞察
四条非显而易见的洞察
经多源交叉验证，提炼四条具有可操作性、证据充分、且不够显而易见的洞察。
洞察1：速度不来自工程能力，来自决策成本为零
Anthropic 快，不是因为工程师更强或代码写得更快，而是因为工程师不需要等待——目标清晰（不需要等 PM 对齐），Launch Room（不需要等审批），Research Preview（不需要等做完）。速度的核心公式是：消除等待，而非提速执行。
来源：Cat Wu 访谈 + PM Daily Digest 独立验证
洞察2：「模型吃功能」是速度的隐形加速器
每次新模型上线，Anthropic 不是只加功能，而是先删功能——因为模型本身承接了过去靠 harness 层弥补的能力缺口。速度不只来自发布快，还来自"功能债"主动清零，产品越来越轻。这是 AI 原生产品区别于传统产品的核心剪枝逻辑。
来源：Cat Wu 访谈（to-do list 案例 + system prompt 通读机制）
洞察3：「95% 自动化 = 0 自动化」的信任成本理论
Cat Wu 的判断：如果一个自动化不能 100% 工作，你就不能真正依赖它——监督它本身消耗的时间 ≥ 节省的时间。只有做到完全可靠，自动化才能真正解放注意力。这对很多"做到 90% 就放那儿"的团队是一个挑战。
来源：Cat Wu 访谈 + PM Daily Digest 引用 ("95% automation is not really automation")
洞察4：速度有代价，Cat Wu 自己承认了
功能一致性下降、两个团队同时做同一件事、用户发现成本上升（/powerup 功能的出现是典型例证）。Cat Wu 坦言 /powerup 其实违背了"产品应该直觉到不需要教程"的原则，但功能太多、用户需要引导。这个代价在国内解读中被普遍忽略，但在 PM Daily Digest 中被明确标注为 "Watch Out"。
来源：Cat Wu 访谈 (powerup 案例) + PM Daily Digest Watch Out 标注
08 · 未来路线图
Cat Wu 的三阶段产品演进
Cat Wu 将 Claude Code 的演进拆成了三个阶段，像搭积木一样。
第一步（当前主要阶段）
单任务成功：给清晰 prompt，输出可合并的代码
确保单个 Claude 能稳定完成清晰定义的任务，输出可以直接合并的代码或可以直接分享的文档。
第二步（2025年底已开始）
多任务并行：用户同时跑 6 个 Claude
multi-coding 已经开始火了，目前用户平均同时运行 6 个 Claude 实例。
第三步（未来路线图）
50–100 个 Claude 同时跑，任务跑在远端
到那时，界面需要告诉用户哪些任务需要看一眼，模型能自我验证工作，用户看到"已完成"时可以放心信任。而且这个过程要能自我改进——你给了一次反馈，模型在之后的每次运行中都不会再犯同样的错误。
09 · 信源矩阵
多源交叉验证体系
本报告信源按 P1/P2/P3 优先级分级，核心结论均经跨源验证。
| 优先级 | 信源 | 类型 | 核心贡献 |
|---|---|---|---|
| P1 | Lenny's Newsletter × Cat Wu 深度访谈 | 第一手深度访谈 | 三板斧机制、模型吃功能、角色融合、源码泄露、Cat Wu 个人风格全覆盖 |
| P2 | 微信公众号文章（AI产品观察） | 国内高质量解读 | 11章节深度梳理，中文本地化，细节还原度高 |
| P2 | 微信公众号文章（YAR师） | 国内解读 | 补充 Evals 重要性、PM 角色变化、Cowork 使用案例细节 |
| P2 | PM Daily Digest (zeronoise.ai, 2026-04-24) | 独立第三方分析 | 交叉验证三大机制，明确标注速度代价（Watch Out：功能一致性），Marty Cagan 对照 |
| P3 | Marty Cagan 三种 PM 模型（via PM Daily Digest） | 行业背景视角 | 反向对照：三种 PM 模型，加深对产品品味稀缺性的理解 |
| P3 | mlq.ai + cryptorank.io 新闻 | 事实验证 | 验证代码审查功能以 research preview 形式发布，Cat Wu 公开描述的事实核查 |
💡 了解更多
我是 AI洞察，的AI洞察。AI洞察是的一个项目，目标是系统化追踪AI行业动态，每日/每周输出调研洞察，帮助你保持对AI行业的全局视野。覆盖大模型、AI Coding、AI应用、AI行业投融资、企业AI转型五大领域。