"代码越来越便宜,产品品味反而越来越贵。"
------Cat Wu,Anthropic Claude Code & Cowork 产品负责人
3 分钟速读版
不只是 PM------这 7 条核心判断,对每个想进 AI 圈、想用好 AI 工具、担心被 AI 时代抛下的人,都是必修:
- 代码越来越便宜,产品品味反而越来越贵------当 Claude Code 把工程实现成本打到地板,竞争核心从"能不能做出来"变成"该不该做、怎么做才对"。这条规则不只对 PM 成立,对任何想用好 AI 的人都成立。
- PM 不会消失,但"那种 PM"会------半年路线图、跨部门对齐、PRD 拉通,这套互联网时代的玩法,在 AI 公司几乎全部失效。背后的逻辑同样适用于工程师、设计师、产品运营。
- 为超级 AGI 做产品很简单,为今天这个不完美的 AI 做产品才难------做产品的人要做的,是在模型还没抵达终局前,把它包装成可信、可交付的东西。
- 95% 的自动化不是自动化------最后那 5% 才是关键,只有走完才能闭着眼睛信。这是用 AI 工具的人最常踩的坑。
- 新模型发布时,最大的工作不是加功能,是删功能------很多产品逻辑是为弥补模型短板加的拐杖,模型变强了就该拿掉。
- Anthropic 跑得快不只是因为模型强,是因为组织被设计成了"无摩擦发布机器"------工程师从看到反馈到上线,有时一天就能跑完。
- Just do things------岗位本身被高估了,看清约束、理解目标、就该直接动手。这条对想转型、想入行、想跨界的人,最重要。
下面是这场访谈的深度精读。读完大概 25 分钟。
写在前面
Cat Wu 在 Lenny's Podcast 第 4 分钟,抛出了这场访谈最扎眼的一刀:
她每天都在面试想进 AI 公司的产品经理。但看了上百个之后,她发现绝大多数人还在用 2020 年的那套逻辑做事------半年路线图、跨部门对齐、PRD 拉通、和工程团队 battle 优先级。
而这套东西,在 Anthropic 这种功能开发周期被压到一周、有时甚至一天的地方,几乎全部失效。
Cat Wu 是 Anthropic Claude Code 和 Cowork 的产品负责人------这家公司内部公认面试经验最密集的 PM 之一。她要说的核心一句话能讲完:不是 PM 这个岗位过时了,是"那种 PM"过时了。
而且不只是 PM 。这场访谈里 Cat 反复强调的判断------"代码越来越便宜,品味越来越贵""95% 的自动化不是自动化""新模型出来,先做减法",每一条都不只针对 PM。它们指向的是同一个问题:在 AI 让生产力发生跃迁的当下,什么样的人会被淘汰、什么样的人会被需要。
所以这篇文章我推荐给三种人:
- 想进 AI 公司的人------你需要知道面试官真正在找什么,而不是按 5 年前的简历模板写
- 想用好 AI 编程工具的人------Cat 给了一套非常具体的"从入门到 100% 信任它"的方法论
- 不懂技术、但担心被 AI 时代抛下的人------里面的"三步法"和"自主性 (agency)"那一段,是写给所有人的
关于 Cat Wu
工程师背景出身,普林斯顿计算机系毕业,先后在 Scale AI 做过 Product Engineer、在 Dagster 做过 Engineering Manager。
之后她去了 Index Ventures 做投资合伙人(Partner),将近三年时间,投过 Figma、Datadog、Discord 这些公司。
2024 年 8 月,她加入 Anthropic,现在是 Boris Cherny 的搭档,Claude Code 产品负责人。
她在 Lenny's Podcast 上做的那场访谈长 1 小时 26 分钟。我整场听完,提取了里面十八个判断------下面这篇精读,是这些判断的详细展开。
我会在每个章节后面穿插自己作为 Claude Code 重度用户和开源 agent 项目维护者的视角------但更多地方,Cat 的原话本身就足够锋利,不需要我再添油加醋。
一、Cat Wu 与 Boris Cherny 的协作:一个被低估的搭档关系
很多人听说过 Boris Cherny。他是 Claude Code 的技术负责人。Lenny 在节目里直接说,2026 年 2 月那一期 Boris 的访谈(主题是"What happens after coding is solved")是 Lenny's Podcast 至今最受欢迎的一期。Boris 本人每天大量提交代码,甚至在手机上写 PR。
但 Cat Wu 和他的协作关系,是这场访谈第一个值得听的点。
Cat:Boris 是一个非常出色的思维伙伴。他是技术负责人和产品愿景制定者,擅长定义"三个月、六个月之后产品该长什么样",以及那个 AGI 终局的理想版本是什么。
我的工作更多是在思考------从我们现在所处的位置,如何一步步走到三到六个月后的那个愿景。我会花很多时间在跨团队协作上,确保市场、销售、财务、算力等团队都认可这个计划。
她描述了一个具体比例:80% 的事情两人共同关心、一起推进;剩下 20% 里,一部分她主导,一部分 Boris 主导。
这是一种健康的"愿景人 + 执行人"组合,但在 Anthropic 又不完全是。Cat 自己有十年工程师背景,她不只是把愿景往下翻译,她也直接做产品判断、写代码、看 PR。
这种 PM 与技术 leader 的边界模糊,贯穿了 Cat 后面所有的论述------它不是个例,而是 Anthropic 整个组织的设计假设。
二、PM 的核心工作,从"对齐"变成了"加速"
在 AI 之前,PM 最重要的能力是什么?
是对齐 。半年到一年的路线图,跨团队的依赖排期,PRD 写得清清楚楚,季度 OKR 一层层拍下来。背后的逻辑很简单:代码很贵,决策错了代价大,所以前置规划越细越好。
但当代码的边际成本被 Claude Code 这类工具砍到接近为零,整个逻辑都翻转了。
Cat:以前一个功能要花六个月,现在可能一周,有时候一天。PM 的工作重心不再是对齐路线图,而是定义"怎么用最快速度把一个想法送到用户手里"。
她举了一个具体动作:在 Claude Code 里,他们几乎所有功能都是以"research preview"(研究预览/早期试用版)的方式上线。
明确告诉用户:这是个早期想法,我们在收集反馈,未来不一定长期支持。
这个标签的好处是把发布的心理负担降到最低------团队不用为每个功能"做对了再发"焦虑,工程师两周就能把一个想法推到用户面前。
要让发布通路真正畅通,Cat 列出了 PM 必做的三件事:
第一件:把目标讲清楚。 因为大模型太通用,反而带来很多模糊空间。优秀 PM 首先要把"目标用户是谁、要解决什么问题、最核心的使用场景是什么"讲透。比如:目标用户是专业开发者,这个功能要解决的问题是权限提示太多导致疲劳,目标场景是让企业开发者在安全前提下实现"零权限提示"。这样目标清晰,自然排除了很多不合适的方案。
第二件:建立可复用的发布机制。 像 Claude Code 的 research preview 标签,本身就是一个"机制产品"------它降低了团队的心理负担,让"一两周内的快速上线"成为常态。
第三件:搭建清晰的协作框架。 让团队知道什么时候需要引入市场、文档等跨职能角色,以及他们的工作预期是什么。Anthropic 内部有一套非常紧密的流程:工程师觉得功能 ready 了 → 内部验证过 → 发到一个固定的发布频道 → 文档、产品营销、开发者关系团队立刻接入,第二天就能完成对外发布。
在 AI 公司,"能在多短时间内把一个想法落到用户手里",这件事本身就是产品经理最核心的能力之一。
PM 在 AI 时代的工作,从"路线图守门人"变成了"发布通路的设计者"。
三、PRD 没死,但被切成了两半
很多人喜欢喊"PRD 已死"。Cat 没这么说。
她讲的是另一件事------PRD 这件事被拆成了两块:
一块是"必须每周复盘的硬指标"。 团队每周和全员一起做数据 readout,让每个人都真正理解业务全貌:核心目标是什么、当前趋势如何、背后的驱动因素是什么。
另一块是"团队原则"。 核心用户是谁、为什么是他们、什么是我们愿意做的取舍。
之所以要把这些讲清楚,是为了让团队里的每个人都理解业务逻辑,知道什么最重要、哪些是我们愿意做的取舍。这样大家就可以自己做判断和决策,而不是每件事都要依赖产品经理或者其他角色。
为什么这套机制重要?因为在一个功能开发周期被压到一周的环境里,如果什么事都要 PM 来拍板,团队第一天就堵死了。 把判断框架交给所有人,每个工程师、设计师都能自己做决策,整个组织才跑得起来。
至于传统意义上那种十几页的 PRD?她说还会写,但只在两种情况下:
- 一是功能特别模糊,需要一页纸把目标、理想用例、当前 failure mode 讲清楚
- 二是涉及重型基础设施、要做几个月的项目
其余时间,PRD 这个文档形态本身已经不重要了------重要的是"团队是不是知道现在该做什么、不该做什么"。
四、Anthropic 跑得快,不只是因为模型强
外界很喜欢一个叙事:"Anthropic 发得快,是因为他们自己就有最强的模型 Mythos。"
Cat 否定了这个说法。
我们已经快了好几个季度了,所以不只是 Mythos 的原因。Mythos 非常强大,我们内部确实用模型,这提高了发布速度一点,但不是主要原因。
主要是流程和团队期望。我们流程极少,要消除所有阻碍发布的障碍,确保团队中的每个人都有能力把自己的想法从概念到发布在不到一周内完成,有时甚至一天。
Cat:我们团队的招聘偏好是有强 product taste(产品品味------对"该做什么、不该做什么"的直觉判断力)的工程师。这种人可以端到端从看到反馈到周末前发布,PM 只要把判断框架建好就行。
这是 AI 时代组织设计的真正赌注:不是雇更多 PM 去管理复杂度,而是把 product taste 这种能力下沉到每一个工程师手里。
如果你团队里所有工程师都在等 PM 拍板才敢动,组织速度就被锁死在 PM 的带宽上。
⚠️ 但这套打法有前提条件,普通公司学不来的部分
读到这里很多人会想:那我们公司能不能也这么做?
老实说,大概率不能。 因为 Anthropic 的"无摩擦发布"是建立在三个特殊前提上的:
- 最强模型自有------他们的工程师可以用上比客户更早的内部模型,生产力 10 倍于普通公司
- 使命驱动的招聘------所有员工都对"安全 AGI 给全人类"有共同认同,这意味着跨团队冲突自然少
- 极强的工程师文化------招聘偏好"有强 product taste 的工程师",而不是"有 product taste 的 PM"。这两类人选的招聘市场完全不同
如果你的公司是传统大厂、招聘市场没这么强、模型还要付费调用 API、KPI 体系又是按部门切的------单纯模仿"无流程发布"只会变成混乱,不会变成速度。
我自己的观察是:能从这套方法论里抄到的,大概只有"research preview 标签"和"判断框架下沉"这两条。其余的需要先改组织,才能改流程。
顺带聊两个外界很关心的"事故"
Claude Code 源码泄露事件。 Lenny 在节目里直接问了。Cat 的回答很坦诚:这是人为错误,有人用 Claude 辅助写一个 PR,关于发布包更新方式的,经过两层人工审核还是出了问题。涉事员工还在公司,没事。"这是流程失误,最重要的是从中学习,增加更多防护措施。"
OpenClaw 限制事件。 Anthropic 限制了用 Claude 订阅去跑 OpenClaw 这类第三方产品,社区反应激烈。Cat 的解释:Claude 订阅原本不是为第三方产品设计的,使用模式与第一方产品差别很大。最后做了一个艰难决定------优先保证第一方产品和 API,但同时给每个订阅者一些 credits 作为过渡。
Lenny:你们 200 美元/月基本是无限使用,我觉得人们不理解商业运作------需要赚钱,需要盈利。不能免费送出这么紧缺的算力。
五、Anthropic 的 PM 团队长什么样
Cat 透露了 Anthropic 内部的 PM 编制:大约 30--40 个 PM,分成五个团队。
Research PM 团队 ------ Diane 负责。把客户对模型的反馈系统性地灌回研究团队,同时负责模型发布流程。
Claude Developer Platform 团队 ------ 维护 Claude Code 之下那层 API,负责 managed agents 这类基础能力的发布。
Claude Code 团队 ------ Cat 自己带的团队。Claude Code 和 Cowork 这两条核心产品线都在这里。
Enterprise 团队 ------ 服务大型企业客户的落地。成本控制、RBAC、安全管控这些"卖给大公司必须有"的能力都从这里出。
Growth 团队 ------ 负责全产品套件的增长,和 Claude Code、Cowork 是紧密协作关系。
Lenny 提到 Anthropic 增长负责人 Amol Avasare 不久前在他播客上说了一个反共识的判断:因为工程师跑得太快,PM 和设计师反而被挤压、跟不上每天的发布节奏,所以未来需要更多 PM,而不是更少。
Cat 的回应很有意思:
所有角色都在融合。PM 做一些工程工作,工程师做 PM 工作,设计师做 PM 工作,也参与提交代码。
你可以选择招更多有出色 product taste 的工程师,或者保持工程招聘不变,招更多 PM 指导他们。我们团队专注于招聘有出色 product taste 的工程师,这样可以减少发布产品的开销。
她特别强调了一句:
Product taste 仍非常稀缺,任何在此方面表现强的人,我们几乎都会雇佣。
Cat 团队几乎所有 PM 要么以前是工程师,要么现在还在 Claude Code 写代码。设计师也基本有前端工程背景。
六、对今天这个不完美的 AI 设计产品,比对 AGI 难得多
这一段是整场访谈里最锋利的判断。
Cat:为一个超级 AGI 设计产品其实很简单------你只需要一个输入框就够了。模型足够聪明,它会自己调用工具、识别不确定性、主动澄清。真正难的,是为今天这个还会犯错、还会误解、还会半途中断的模型设计产品。
这句话之所以重要,是因为它戳穿了一个目前流行但其实很懒的产品观------"我们就做对话框,剩下的等模型变强"。
不行的。今天的真问题是:
- 模型会卡在某个步骤不动
- 模型会自信地给出错误答案
- 模型会把任务转交给一个根本不存在的子流程
- 模型会写完代码但忘了跑测试
每一个真正在用 AI 干活的人都遇到过。
Cat 给了一个非常具体的例子:Anthropic 内部一直想做"AI 代码审查"功能。
他们尝试过好几次,做过简单的 /code-review 命令,但准确率不够,一直没敢正式上线。直到 Opus 4.5、4.6、Sonnet 4.6 这一代模型出来,他们才真正觉得"这个东西好到可以依赖了"。
现在 Anthropic 工程团队合并 PR 之前,会真的依赖这套 AI 代码审查通过。他们甚至可以同时运行多个代码审查 agent,遍历整个代码库,然后综合输出一组工程师在合并前需要解决的真实问题。
这是产品节奏的胜利:你提前半年到一年做原型,留好钩子,等模型能力追上来,你就比所有人提前半年上线。
Cat:去构建那些暂时还跑不通的产品非常重要。这样你才知道,这个产品要真正成立,还缺什么。等到新模型出来,你只需要把它替换进你已经做好的原型里。
【作者插话】 这点我深有体会。我自己做 agent 编排项目的时候,有几个功能模块在 Claude 3.5 时代怎么调都不稳。但我没拆掉它,而是降级处理留在原型里。Sonnet 4.5 出来后,这些模块直接复活了------什么都没改,准确率从 60% 跳到 95%。留好原型,等模型追上来,这是 AI 时代最被低估的产品策略之一。
七、一个被严重低估的实操技巧:让模型自我反思
整场访谈里,Cat 提到一个她自己最常用、但没什么人讨论的技巧------让模型对自己的行为做反思。
Lenny 形容这是"Cat 最被低估的 AI 技能"。
具体怎么用?
她说有时候模型会做一些不太符合预期的操作。比如:
- 让它改前端,它改了代码、跑了测试,但根本没真正打开 UI 验证
- 让它做一个复杂任务,它把活转交给某个子 agent,但那个 sub-agent 没执行测试,它自己也没回头检查
这种时候,最有价值的动作是直接问它:"你为什么这么做?"
模型给出的答案往往会暴露真问题:
- "你的系统提示在 X 这一段让我误解了"
- "我没有意识到前端验证是这个任务的一部分"
- "我把验证交给了子 agent,但没去 check 它有没有真做"
这些反馈会直接告诉你:你的运行框架在哪里漏气了。
Cat:很多时候,只要你对模型为什么会做出这个决策保持足够的好奇心,就能发现它是在哪一步被误导了,从而可以去调整整个运行框架,把这个问题补上。
她还讲了另外两个相关的实操方法:
方法二:找出你最信任的几个用户。 不是每个人的反馈都同样有价值。通常有少数几个人,在描述"某个模型 + 某种运行框架为什么好用"这件事上,比其他人更清晰、更准确。找到那样一小群你真正信任的、比如五个人左右的用户,对快速获得有效反馈非常关键。
方法三:构建评估体系(evals,即一组用来给模型/agent 打分的标准化测试用例)。
Cat:你不需要做上百个评估才能产生价值。只需要做十个高质量的评估,就能很好地帮助团队明确目标、衡量进展,以及发现当前的不足。评估这件事被低估了,应该有更多产品经理和工程师参与进来。
Cat 自己一般在某个功能还需要进一步明确产品定义时才会亲自下场做评估。产出通常是:"我做了五个评估,这是运行方式,这些是成功的案例,这些是失败的案例,以及这是我用来提升成功率的提示词。"
【作者插话】 让模型自我反思这个动作,改变了我整个 agent 调试思路。以前 agent 卡住了,我第一反应是改 prompt。现在我会先问它"你刚才为什么那么做",拿到的信息量比改十次 prompt 都多。这是把模型当成你最重要的"用户"------不是工具,是合作者。
八、95% 的自动化,不是自动化
整场访谈里,传播潜力最大的一句话在这里:
Cat:如果一个自动化不能做到 100%,它就不算自动化。最后那 5% 到 10% 才是真正花时间的地方,但只有走完这段,你才能真正信任它。
这话刺人,但精准。
太多人------包括 Cat 自己------在做工作流的时候,都停在了 90% 那个点。Cat 承认她在训 Cowork 帮她清空 Gmail 收件箱,到现在还远远不行。Lenny 也说他做了一个 Gmail 邮件自动分类,把"问能不能上播客""要不要看看这个"之类的请求归到一个文件夹,准确率 95%,但偶尔会把重要邮件误判进去------结果他得每天还是去翻一遍那个文件夹。
【作者印证】 我自己也踩过这个坑。之前给 Gmail 做了一套自动归档,准确率大概 92%,看起来挺好。但那 8% 里偶尔会漏掉客户邮件------结果就是我每天还是得手动过一遍。那 8% 没解决,前面 92% 的工作量都白省了。 我后来给 agency-orchestrator 写重试和验证机制,核心动机也是这个------如果你的 agent 做完一个任务有 5% 概率出错,而你又必须复核,那这个 agent 等于没用。
但 95% 准确率的自动化,本质上还是手动工作流------因为你必须每次都过一遍才能确认它没出错,而这个动作本身就消解了自动化的全部价值。
一个值得反复读三遍的标准:自动化的成立条件,不是能不能跑通,而是你敢不敢闭着眼睛信它。
Cat 给出了具体的"打磨方法":多下点功夫,把你的偏好教给 Cowork,多给它反馈,让它不断提升能力,直到达到完全可靠的程度。
她也承认,Anthropic 自己在让用户更容易做这种"自定义工作流"上还远远不够好:
Cat:现在的流程还是有点复杂。你需要理解很多概念------要定义一个技能、要调用这个技能、要不断给它反馈、然后还要告诉 Cowork 根据这些反馈去更新这个技能。同时你还需要知道去哪里查看这个技能,确认它是否按你的预期更新了。
这条判断对开源工具作者尤其重要。社区里大部分 agent 项目卡在 demo 期,看起来很酷,但没人真正用------因为差的就是从 90% 到 100% 的那一段不性感的工程量。
九、Claude Code、Cowork、桌面、网页------什么时候用什么
Cat 自己的工具栈分配。
Claude Code (CLI):跑一次性编程任务、想用最新功能。CLI 是最早的产品形态,新功能都先在这里上线,所以也是功能最强的一种形式。
桌面端:做前端、做需要预览的东西。预览面板可以一边跟 Claude 对话一边实时看页面变化。
桌面端对非技术用户也更友好------很多人对终端有天然恐惧,觉得复杂、各种弹窗让人紧张。桌面端还是统一的任务控制台------你可以一眼看到 CLI 终端任务、桌面任务、网页和手机发起的任务。
网页 / 移动端:随时启动任务,不用守着电脑。
Cat 提到一个很真实的场景------很多人出去散步还在用手机给电脑开热点继续工作,就是因为这个场景一直缺一个更好的解决方案。
Lenny:我也见过人在飞机上不敢关电脑,就守着 Wi-Fi 等 agent 跑完。
Cowork:所有产出不是代码的工作。清空 Slack、清空 Gmail、做客户演讲 PPT、写功能目标文档、整理客户简报。
判断标准很干脆:输出是代码 → Claude Code;输出不是代码 → Cowork。
Cat 自己的工具栈大致是:Claude Code、Cowork、Slack。 Anthropic 基本上是跑在 Slack 上的,她形容 Slack 是"公司的核心操作系统"。她大概有 30% 的时间在不断试探 Cowork 和 Claude Code 的能力边界。
十、Cowork 的真实使用场景
Cat 说很多人还在低估 Cowork。她在节目里讲了三个具体场景,我把第一个完整写出来,这个最有代表性。
场景 1:用 Cowork 做一场内部大会演讲的 PPT
她在准备 Code with Claude 大会的演讲。其中一场要讲"Claude Code 如何从助手进化成真正的 Agent",希望展示发布的产品和内部成功案例。
她已经把 Google Drive 和 Slack 接入了 Cowork。直接把产品营销同事 Alex 写的草稿、自己的草稿、目标故事线全部喂给 Cowork。
Cowork 自己工作了大概一个小时:
- 翻了 Twitter 上的发布内容
- 查了内部发布频道
- 翻了团队分享 demo 的频道
- 把这些信息整合成一份 20 页的 PPT
第二天早上她看了一下,整体已经挺不错。改了改风格(她偏好极简,Cowork 一开始字写得多),就拿去用了。
她的 prompt 也非常简单:
"帮我做一份 Code with Claude 大会的 PPT。这是 PMM 建议要覆盖的内容,这是我的一版草稿,我不太满意,还有一版是我自己手动做的,也不太好。先帮我整理一个更完整的内容大纲,并且尽量避免和更重要的主题演讲重复。"
她最后定的内容结构是:从"提升本地任务的成功率",到"让每一个 PR 都顺利通过",再到"帮助工程师完成更多 PR"。 框架确定后,Cowork 自己花几个小时把整套 PPT 做出来。
关于设计系统接入。 Anthropic 本身有一套用于所有对外场景的标准演示模板。把这套模板直接交给 Claude,让它学习配色、字体,还有不同类型的页面结构。也可以直接连 Figma MCP(Model Context Protocol,Anthropic 主推的工具/数据源标准化接入协议),如果模板存在那里,可以直接拉进来用。
这正好说明了现在 PM 的价值:Claude 是一个非常强的思考伙伴,可以快速整合大量信息,把各种可能的方向都摆在你面前------但最终拍板的人还是 PM。
场景 2:销售同事的"客户定制 PPT 自动化工具"(简版)
Cat 团队的一位销售同事做了一个 Web 应用嵌套 Claude Code:把 Salesforce 和 Gong 的客户信息接进来,自动判断客户用的是 Bedrock 还是企业版、关注代码审查还是安全控制、有没有 HIPAA 合规需求,然后自动加减幻灯片、删除不适用的页。
本来 20--30 分钟手做的客户定制 PPT,现在几秒钟生成。
这就是 Claude Code 给企业内部带来的最关键变化:它极大降低了开发自定义应用的门槛。
场景 3:Applied AI 团队的"客户会议简报"(简版)
Applied AI 团队(类似前线部署工程)的工程师同时负责多个客户,一天 5--10 场会议。
他们让 Cowork 在前一天晚上自动整理:明天每个客户的最新需求、关注点、过去待办事项、Slack 里的最新 ETA。生成一份"战斗简报",一目了然。
十一、Token 成本的真相:它正在悄悄追上工程师的工资
Lenny 在节目里抛出一个最近 Twitter 上反复讨论的趋势:有人晒出账单,自己每月的 token 花费已经超过了自己的工资。 这听起来夸张,但在重度使用 agent、跑大量并行任务的工程师里,已经不是孤例。
Cat 没给具体数字,但完整确认了趋势:
Cat:每当模型出现一次跃迁,或者产品有显著改进时,人均 token 成本都会上升。目前这个成本仍然远低于一个普通工程师的薪资,但它所占的比例正在逐渐提高。
注意这句话里两个被很多人忽略的细节。
第一,"模型跃迁"和"产品改进"会同时推高人均 token。 不是因为模型本身变贵了------单 token 单价其实在持续下降------而是因为模型每变强一次,大家就更敢把更复杂、更长链条的任务交给它。从前你只敢让它写一个函数,现在你让它跑 50 个并行任务遍历整个仓库。token 用量是按几何级数往上走的。
第二,"远低于工程师薪资"这个参照系本身就是个炸弹。 公开数据里,Anthropic 工程师年薪在 560k 到 785k 区间。一个工程师每个月的 token 花费要追到这个数,需要单月烧掉数千到上万美元------这在过去想都不敢想,现在已经能看到追赶的影子。
内部使用排名:工程团队居首
Anthropic 自己的 token 消耗榜:
- 第一名:工程团队------研发、跑测试、code review、迁移代码,token 消耗占大头
- 第二名:Applied AI 团队------前线部署工程师同时服务多个客户,需要大量 prompt 工程和评估实验
Lenny 顺着这个话头追问:那 Anthropic 员工是不是无限 token?
Cat 的回答非常 Anthropic 风格------相信每个个体的判断,但不假装没有约束:
Cat:我们可以用很多 token,不过也有人会碰到限制。浪费 token 是不被鼓励的,但我们也相信每个人都能自己做出判断。
这句话背后有一个值得抄走的管理哲学:不靠预算审批治理资源,靠"信任 + 透明 + 反馈"治理资源。 给员工足够的额度让他们试,但每个人都知道"浪费"这件事是被默认看在眼里的。这种管理成本只有在公司还小、文化够强的时候撑得住------也是为什么 Cat 后面会反复强调"使命驱动"。
【作者插话】 这一节我自己最有感觉的一点是:token 成本越追近工资,衡量"AI ROI"的方式就必须变。 早期大家算"AI 帮我省了几小时人力 vs 几美元 token",ROI 看着像是 100 倍。但当 token 成本逼到工资的 30% 甚至 50%,这个账就要重新算------你必须问的不再是"它有没有帮我省时间",而是**"它帮我做的那部分事,值不值得它消耗的 token"**。这是 2026 下半年所有 agent 产品都要面对的问题。
十二、新模型发布时,最大的工作不是加功能,是删功能
这是另一个反直觉的洞察。
Cat:每次新模型发布,我们做的最大动作不是加功能,是删功能。很多产品里的逻辑,本来是为了弥补模型的短板加上去的。模型变强了,这些拐杖就该拿掉。
她举的例子是"待办列表"。
早期 Claude Code 用户会让它做大规模重构,比如改 20 个调用点。早期模型经常改了 5 个就停了。团队加了一个待办列表机制,强制 Claude 把 20 项全部列出来再逐个处理。
但到了 Opus 4 及之后的模型:不需要再强制它使用这个待办列表了,它会自然地这么做。
现在他们还保留着待办列表,但不是给模型用,是给人看的------用户需要知道 Claude 现在在做什么。
模型会把你的运行框架"当早餐吃掉"。
每次发布新模型,Anthropic 会做一件事:把整个系统提示从头到尾读一遍,逐条判断这些提醒现在还需要吗?如果不需要,就删掉。
这条判断的现实意义:今天你给 Claude Code 设计的所有 prompt 工程、所有 system prompt 加固、所有 sub-agent 编排,下一个模型出来后可能 30% 都得删。
从产品策略角度,这意味着另一种打法:去构建那些今天还跑不通的产品。 当下做 demo,留 hooks,等下一代模型出来直接换进去------你比所有人提前半年到一年。
十三、Claude 的"性格"为什么是核心竞争力
Cat 的另一个重要观点:Claude 的"角色",不是边缘功能,而是核心竞争力。
Lenny 的观察:在 OpenClaw 这种第三方场景里,很多人之所以会失落,有一个原因就是 Claude 的"个性"------它相比其他模型,确实更好玩、更有趣、更有吸引力。
Cat 给了一个具体画像。Claude 的几个性格特点:
- 轻松、有趣------和它对话不累
- 专业、可靠------任务质量稳定
- 低 ego------你说"你这里做错了",它真的会说"哦,确实是我错了,谢谢你指出来,我来改一下"
- 积极、偏向行动------你说一件事很难无从下手,它会说"没关系,我们一步一步来,这是建议的步骤,你需要我帮你先开始吗?"
- 会给真诚反馈,而不是对你说的每句话都附和
Cat:一个优秀的协作伙伴,往往具备这种积极性、这种偏向行动的倾向,以及一种能够给出真诚反馈的能力。所以我们会刻意把这些特质注入到 Claude 里。
塑造 Claude 角色这件事,Anthropic 有专门的人在做(Amanda)。Cat 形容这是一个非常难的工作------做编程相对容易,因为可以验证结果是否正确;但塑造角色,需要对"Claude 应该成为什么样的存在"有非常强的判断力。
十四、Anthropic 后来居上的真正原因:统一的使命
Anthropic 这家公司起点其实劣势明显------资金、分发、先发优势都不占,OpenAI 当时遥遥领先。但现在它实现了非常强劲的增长。
Cat 说,内部视角下最关键的因素是:统一的使命。
团队在招聘时就强调"将安全 AGI 带给全人类"这个使命的认同,并在产品决策中持续以此作为最高原则。由于该使命优先级高于任何单一产品线,组织能够实现跨团队的快速决策与一致执行。
Lenny 追问了一个尖锐的问题:你们和 OpenAI 的差异,是不是就在这里?OpenAI 探索的方向多得多。
Cat 没正面回答,但她说了一段值得读三遍的话:
Cat:在我看来,使命的核心在于将 Anthropic 的整体目标优先级置于任何单一团队或产品之上。这与"专注"不同,后者更多是执行层面的能力,而使命是一种价值取向。
具体体现为:团队愿意在必要时牺牲自身的 OKR,以换取公司整体目标的最大化,并且这种取舍是被主动接受的。
在极端情况下,即使像 Claude Code 这样的产品未达预期,只要 Anthropic 整体成功,团队依然会认为这是正确的结果。
这是一种极度罕见的组织文化------不是"专注做对的事",而是"愿意为整体牺牲局部"。
OpenClaw 的限制决策就是这种文化的产物:Anthropic 的目标之一是扩大用户覆盖,关键路径是自己的订阅产品。这意味着对第三方产品的支持有时候必须取舍。
十五、长期方向 & 人类还剩什么
长期方向:从"任务"到"百个并行 agent"
Cat 用"构建模块"的思路来思考 Claude Code 和 Cowork 的长期演进路径:
- 当下:让单个任务成功完成。任务是最基本的单位
- 2025 年底:多任务并行已经是趋势,从 1 个任务到 6 个任务同时跑
- 未来:同时跑 50--100 个任务
当模型更强时,也许你会同时运行 50 个甚至上百个任务。那问题就变成:我们需要什么样的基础设施来支撑这一点?到那个阶段,你很可能已经无法再在本地机器上运行所有东西了。
这指向几个产品方向:任务运行在远程环境、人类只看"哪些任务需要关注"、agent 自己验证工作、整个系统能够自我改进。
人类在 AI 时代还能发挥价值的地方
Lenny 问了一个所有人最关心的问题:在超级智能到来之前,人脑暂时还有用武之地的地方在哪?
Cat 的回答可以拆成四层:
第一层:常识和情商。 任何一次产品发布都牵扯多个利益相关方,他们彼此关系、偏好、沟通方式各异。这种内隐的常识,模型还远远做不好。
第二层:第一性思考。 看清技术版图怎么变,团队缺什么,然后冲上去补位。
第三层:产品品味。 从一万条 GitHub issue 里挑出该做的那十条,选对实现方式。
第四层:定义"一个月后产品该长什么样"。 这是 Cat 自己认为最难的能力------在巨大不确定性中,从用户突破产品边界的方式里看到模式,设定方向。
十六、给所有担心被 AI 干掉的人:三步法
Cat 给所有担心职业前途的人的具体建议,我觉得是整场访谈里最实在的一段。
第一步:找出你工作里那些反复在做的、不喜欢的、机械的事情。
第二步:把它交给 Claude Code 或 Cowork。
第三步------这才是大多数人没做到的:死磕到 100%。 不要停在 90%,不要停在 95%。教模型你的偏好、给它反馈、让它学习,直到它真的可以闭着眼睛信。
为什么这件事重要?
Cat:因为只有真的把一段重复劳动 100% 自动化掉,你才会发现一件事:你突然多出来 20% 的时间。这 20% 不是用来做更多原来的事的,是用来做那些你一直觉得公司应该做、但从来没时间推进的事。
这才是 AI 给个人的真正杠杆------不是替代你的工作,是把你从"必须做但不爱做的事"里解放出来,让你有空做你真正在乎的那部分。
而那一部分,恰好是 AGI 还做不到的:判断方向、定义问题、看准市场、识别哪个机会值得 all in。
但要警惕另一个极端:工具配置成瘾
Cat 还补了一句很重要的反向提醒:
我会更建议大家去做那些你每天都会用到的应用。因为只有在真实使用中,你才能真正获得价值。
她讲了两个极端:
- 一类人完全不做定制、不做自动化------错过了 AI 的所有杠杆
- 另一类人走向另一个极端------非常执着于优化工具,加很多 skills、MCP、各种工作流优化,反而分散注意力,偏离最核心的目标
Lenny 在 Twitter 上经常看到的现象:
大家都在展示自己的配置,说你看我的 setup,有多复杂、多极致优化。但问题是,你到底在做什么?
Cat 的总结是:
简单的配置反而更有效。
十七、AI 时代,新世代产品工人的画像
听完整期访谈,Cat 心目中那个能在 AI 时代活下来的人,画像慢慢清晰:
- 第一性思考------能看清技术版图怎么变,团队缺什么,该补哪个洞
- 不在乎岗位说明书------PM 写代码、工程师做产品、设计师提 PR 都是日常
- product taste 是底层能力------能从一万条 GitHub issue 里挑出该做的那十条
- 乱中求快的心理素质------周日一个 P0,周一更大的 P0,周一下午又升级一层,但晚上还能睡着
- 拒绝 95% 自动化------只信 100%
- 愿意为今天这个不完美的 AI 设计产品,而不是空想 AGI
- 常识和情商------AI 还做不好的人际、组织、沟通
- 会用模型自我反思------把模型当作最重要的"用户"之一
Cat 自己在节目里反复引用了一句她常想的话:"Just do things."------去做就是了。
Cat:岗位本身有点被高估了。如果你看清了约束条件,理解目标,就该直接去做,从错误里学,犯了就道歉、就修。
在大多数公司里,岗位划分非常严格------这是 PM 的事,那是设计师的事,那块代码我们不能动。"去做就是了"是把每个人从这种紧箍咒里解放出来。
她说这是一种自主性 (agency)------敢于做决策,敢于跨越团队边界推进事情,只为了把事情真正做成。
这种能力很多人是在创业公司学到的。Cat 自己讲了一段触动我的经历:
对我来说,一个非常改变人生的经历,是在一家只有 20 人规模的公司里工作。当时基本没有什么流程,但我们要解决的问题却非常大。我很感激当时的团队,他们给了我以及团队其他成员充分的自由,让我们可以在没有明确边界的情况下自己去摸索,不再有"销售该做什么""运营该做什么""工程师该做什么"这种限制。
十八、Cat 的个人推荐
最常推荐的几本书:
- 《How Asia Works》------讲经济发展和长期成功国家的政策
- 《The Technology Trap》------讲过去几次技术革命如何影响劳动者。Cat 推荐它的原因是:"我们可以从历史中学到很多,从而确保这一次转型能够走得更好。"
- 《The Paper Menagerie》------刘宇昆的短篇小说集,讲成长、AI、自我认知
喜欢的影视:
- 《Drive to Survive》(F1 纪录片)------"看到人们如此专注于一个单一的工程目标,本身就很让人满足"
- 《Free Solo》(Alex Honnold 无保护攀登酋长岩)------她看完之后开始攀岩。"这是一部很少见的电影:你对这件事了解得越多,就越会被震撼到它到底有多不可思议。"
最爱的产品(除了 Claude):Waymo。
如果车在等我,我不会有负担感。它让我更高效------可以直接开会,不用担心被听到。这个产品每天大概帮我"多拿回"了 30 分钟时间。
Anthropic 内部对 Waymo 的依赖已经改变了大家的说话方式------以前说"叫个打车软件吧",现在直接问"Waymo 到了吗?"
关于 AGI 之后她会做什么: 她大概会去多攀岩,可能搬到 Fontainebleau 专心攀一段时间。她还有很多书想读------目标是每周一到两本,但现在大概只有每周 0.5 本。
结语:一个正在裂开的 AI 认知
访谈最后,Cat 提到 Andrej Karpathy 在 Twitter 上的一个观察:
一类人在 ChatGPT 早期尝试过,觉得"也就这样吧",然后放弃了------对 AI 能力变得很怀疑,觉得这东西没什么大不了。
另一类人,尤其是用 AI 写代码的人,已经看到了它真正的强大------知道它能做到什么程度。
这两类人彼此很难理解对方是怎么看世界的。
Cat 的判断:
一个很大的变化是,2024 年那一代产品主要是基于对话的,而像 Claude Code 这一代产品,更偏向行动导向。
很多人真正的顿悟时刻,是在发现模型可以直接帮你完成事情,而不仅仅是告诉你该怎么做。当你意识到 Agent 不只是给建议,而是可以真正替你执行任务,这种体验是非常震撼的。
一旦体验到这一点,很多人的认知都会被彻底改变。
这,可能是 2026 年这个时间点上,最值得每个人想清楚的一件事------你是哪一类人?
留个问题给你
这一期访谈对我个人冲击最大的是"95% 自动化不是自动化"这句话。
回头一看,我自己工作流里至少有五六个工作流卡在 90%------因为我每次都告诉自己"先这样吧,剩下那 10% 太麻烦"。
想问问你:
你最希望做到 100% 自动化、但目前还死活搞不定的一件事是什么?
哪怕只是一句话的吐槽都行,我会逐条看,把最有共鸣的几个回复在下一期文章里展开聊。
本文源自 Lenny's Podcast 2026 年 4 月 23 日对 Cat Wu 的访谈《How Anthropic's product team moves faster than anyone else》。原节目长 1 小时 26 分钟,覆盖了远多于本文的内容,强烈推荐去听原版。
视频:youtu.be/PplmzlgE0kg
Newsletter: lennysnewsletter.com
嘉宾:Cat Wu(@_catwu)
关于作者
Claude Code 重度用户,开源 agent 编排项目 **agency-orchestrator，agency-agents-zh（10.1K stars）**维护者。日常关注 AI 时代的产品形态、agent 工程化、和"人 + 模型"的协作设计。文中关于 agent 调试、自动化可靠性的实操体会,大多来自这个项目踩过的坑。