当AI让代码成本趋近于零，产品经理的核心价值正经历前所未有的重构。Anthropic产品负责人Cat Wu和OpenAI前联合创始人Andrej Karpathy不约而同指出：在Software 3.0时代，产品审美与架构判断力正取代传统的PRD写作能力，成为PM最稀缺的竞争力。本文将深度解析AI时代产品管理的三大范式转移——从路线图管理到价值判断，从功能交付到边界定义，从文档优先到Demo优先的工作方式革命。
Cat Wu 是 Anthropic Claude Code 和 Co-work 的产品负责人。最近她上了 Lenny’s Podcast，聊 Anthropic 的速度文化、PM 角色的变化，以及她面试几百个候选人之后的一个判断：大多数人对 AI 产品管理的理解，方向是错的
她用一句话说清楚了这件事：
“当代码变得越来越便宜，真正变得更有价值的是决定写什么。”
（”As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write.”）
这句话指向一个很多 PM 还没真正理解的概念——product taste，产品审美
过去技术变化慢，写代码贵。PM 的主要工作是协调路线图，让大家的功能互相解锁。做 6-12 个月规划，花两周写 PRD，开评审会，排进路线图，等工程师开发。一套流程走下来，两三个月没了
现在不一样。Cat Wu 的团队把功能交付从半年压到了一天。模型在变强，AI 让工程效率上了一个台阶。很多功能从 6 个月变成 1 个月，有时候是一周，偶尔就是一天
这个节奏下，”怎么把东西做出来”已经不是瓶颈，真正的瓶颈是”什么东西值得被做出来”
她面试了几百个 PM 候选人，发现大多数人还在用 6-12 个月路线图的思维找工作。他们会写 PRD、会排优先级、会跨团队对齐——这些技能正在被工程效率吃掉
剩下的，是她说的 product taste
当工程执行的成本被 AI 大幅压低，PM 每天面对的决策密度反而上去了。以前一个功能要不要做，可以慢慢讨论，因为做错的代价是几周到几个月的工程时间；现在做错的代价可能只是一个下午，但要做的事情也多出十倍。这时候真正稀缺的，就是在每件事上快速判断”它值多少”的直觉，这种判断力体现在三个层面
工程背景带来的成本直觉
Cat Wu 团队几乎所有 PM 都有工程背景或者直接写代码，设计师以前是前端工程师。她自己是工程师出身，后来做 VC，加入 Anthropic 之前就在用 Claude Code 搭 Streamlit 应用分析用户反馈、跑模型评估——几百小时的活，一行代码都没手写
为什么工程背景在当下特别有用？她解释：
“如果你有工程背景，你能判断一件事应该有多难。如果很简单，别讨论了，花一小时做掉；如果很难，你提前知道成本，就能更准确地排优先级。”
（”If you have an engineering background, you can tell how hard something should be. If it’s easy, don’t discuss it, just spend an hour and do it. If it’s hard, you know the cost upfront, so you can prioritize more accurately.”）
这已经从加分项变成基础项。一个 PM 必须读得懂 AI 时代的新价格表：一个功能到底应该开会讨论，还是当天做一个 research preview？一个问题是 prompt 层能接住，还是要 harness、eval、产品交互一起上？
区分临时补强和长期价值
AI 产品里的功能经常背着两种身份。一种是补模型能力的短板，另一种是帮用户理解和信任模型
Cat 举了 Claude Code 的 to-do list 做例子。早期 Claude Code 做大型重构，经常说要改 20 个调用点，改到 5 个就停下来。团队给它加了一个 to-do list，让它像人一样列清单、一项一项完成。后来的模型自己学会了这个行为，to-do list 对模型完成任务的帮助变小了，但对用户观察 Claude 在做什么仍然有用
模型进步以后，前一种身份会淡掉，后一种可能一直留着。PM 必须不断重新判断同一个功能现在在产品里到底在干什么。传统软件里，功能上线之后就进入维护期；AI 原生产品里，功能可能在模型更新一次之后就要重新定价
这里有个让人不太舒服的现实：你今天辛苦设计的 workflow、prompt、辅助功能，三个月后可能被新模型内建的能力取代。你以为你在做产品护城河，结果它只是某一代模型能力不足时的临时鹰架
“恰好正确程度的 AGI 信仰”
这是整场访谈里我觉得最有意思的回答。Cat 认为 AI 公司 PM 最难练的能力，是定义一个月后产品应该是什么样子
“做到恰好正确程度的 AGI 信仰非常难。”（*”It is very hard to be the right amount of AGI pilled.”*）
每个人都能看到那个终极未来：模型极其聪明，什么都能做，你只要一个输入框告诉它你想要什么，它自己就能接入工具完成任务。为那个终极版本做产品太容易了
难的是搞清楚当前模型的能力边界在哪，怎么在这个边界内榨出最大价值。
太 AGI pilled 会让你忽略眼前用户的痛点，太保守会在下一次模型升级时措手不及。最好的 PM 能看到一种信号——用户怎么突破现有产品的极限。从这些信号里判断方向，稳步推进，同时在模型能力超出或低于预期时灵活调整
Cat 自己的做法是把 30% 的时间花在故意把产品推到极限上：和模型对话，搞清楚它为什么在某些任务上犯错
Cat Wu 的判断不是孤例。前 OpenAI 联合创始人、前特斯拉 AI 总监 Andrej Karpathy 从另一个角度给出了几乎一样的结论
2025 年 6 月，Karpathy 在 YC AI Startup School 演讲，正式提出 Software 3.0 的概念。Software 1.0 是传统代码，人类用 Python、C++ 写明确指令；Software 2.0 是神经网络，代码就是模型权重，人类通过数据集和优化器让机器自己”写”代码；Software 3.0 是大语言模型，提示词就是程序，编程语言变成了自然语言。他的判断是：
“Software 3.0 正在吞噬 1.0 和 2.0，大量软件将被重写。”（*”Software 3.0 is eating 1.0 and 2.
0. A huge amount of software is going to be rewritten.”*）
到了 2025 年底，Karpathy 自己也被这场变革卷了进去。12 月 27 日他在 X 上发了一条长帖，第一句话就是：
“作为一名程序员，我从未感到如此落后。”（*”I’ve never felt this much behind as a programmer.”*）
他说如果能正确串联起过去一年涌现的工具，自己本可以变得强大 10 倍，但还没做到。他列了一长串新概念——agents、sub-agents、prompts、contexts、memory、modes、permissions、tools、plugins、skills、hooks、MCP、LSP、slash commands、workflows、IDE integrations——并把这场变革形容为”对软件工程行业的 9 级地震”，像”一个强大的外星工具被发到大家手里，但没有说明书”。这条推文当时转发过万，浏览量 360 万。一个站在最前沿的人都坦言落后了，普通 PM 和工程师就更没有”等一等”的余地
Vibe Coding：人人都是程序员
2025 年 2 月，Karpathy 随手发了一条推文，定义了 Vibe Coding——氛围编程。你不再真正”写”代码，而是用自然语言描述你想要什么，让 AI 来生成。你只需要”感受氛围”，看看结果对不对
这个词火了，进了维基百科。YC 的数据显示四分之一初创公司 95% 的代码由 AI 生成。编程的门槛被拆掉了
当人人都能”写代码”，代码本身就不值钱了。值钱的是你用代码做什么——也就是产品判断
钢铁侠战衣，不是钢铁侠机器人
Karpathy 提了一个产品设计原则：不要追求完全自主的 AI Agent，要做”部分自主”（Partial Autonomy）的产品。他用的比喻是：
“我们应该造’钢铁侠战衣’（增强人类能力的工具），而不是’钢铁侠机器人’（完全自主的 AI）。”（*”We should be building Iron Man suits, not Iron Man robots.”*）
他给的设计框架里有几个有用的概念。一个是自主滑块（Autonomy Slider），让用户控制 AI 的介入程度，比如 Cursor 的 Tab 补全 → Cmd+K → Agent 模式，Perplexity 的搜索 → 深度研究。一个是生成-验证循环（Generation-Verification Loop），AI 生成、人类验证，循环越快越好；好的产品要让验证变得容易，同时把 AI 控制在短链条任务上。还有 Demo-Product Gap，他有一句话：
“Demo 只需要成功一次，产品需要每次都成功。”（*”Demo is works.any(), product is works.all().”*）
这个差距，就是产品品味发挥作用的地方
人类价值剩下的三件事
在一篇被广泛讨论的对话里，Karpathy 的观点被总结成：当 Vibe Coding 的蜜月期过去，人的核心价值会坍缩为三个不可替代的维度——审美与品味（Taste），判断”什么是好”；架构判断（Architecture Judgment），判断”系统怎么拆”；验证与纠错（Verification），判断”哪里出了问题”
审美排在第一位
这跟 Cat Wu 的判断是一致的：Karpathy 从技术范式角度论证”代码变便宜”，Cat Wu 从产品管理角度论证”判断变贵”。两个人从不同位置看到了同一件事
2025 年底，Karpathy 在年终盘点里又提了一遍：RLVR 训练范式的突破、Cursor 重构 LLM 应用生态、Claude Code 带来的本地 Agent 革命、Vibe Coding 让编程民主化。他特别提到，LLM 是优秀的”应届生”，但 Cursor、Claude Code 这样的工具才是把”应届生”变成”职场老手”的地方。中间那层编排、判断和引导，就是产品品味的具象化
工程执行不再是瓶颈，PM 的关注点跟着变了
简单说，就是从”怎么把东西做出来”转到”什么东西值得被做出来”，从”提高一次性判断的正确率”转到”提高整个循环的学习速度”
具体落到日常工作上，几件事变得更重要
一是目标定义能力。把模糊的用户期待变成清晰的目标：核心用户是谁、解决什么问题、核心场景是什么、什么可以放弃。Cat 举的例子是 Claude Code 的某个功能：核心用户是企业里的专业开发者，要解决权限提示太多导致的疲劳感，目标是让企业开发者安全地做到零权限提示。目标一旦清楚，就排除掉了大量不相关的方案
二是模型能力边界判断。知道当前模型在哪些地方可靠、哪些地方要靠 harness 补、哪些地方能用产品设计把用户引到黄金路径上。还要看出来哪些短板下一代模型大概率会自己学会，不要为这些即将消失的短板搭太重的产品
三是信任机制和权限控管。Cat 提到一个观念我觉得挺重要：如果一个 AI 工具只做到 95%，很多时候它其实还没到真正的自动化。剩下的 5% 会让人变成监工——你还是要一直检查它有没有错、确认它有没有漏、担心它哪一次突然乱做。所以重要的不只是模型能力，还有整套 workflow、permission、review、log、rollback、human-in-the-loop。做一个让人敢把工作交出去的系统，比做一个”看起来很聪明”的模型更难
四是用户行为信号捕捉。Claude Code 的 Chrome 集成功能就是这么来的：团队发现用户在 Claude Code 里做 web 应用之后会手动切到浏览器测试，来回复制粘贴指令。流程很麻烦，但用户真的在这么做，于是团队直接把它做成了产品功能
Evals：怎么定义“AI 做得好”
Evals（评估）是 AI 产品 PM 的新能力。它解决的问题听起来简单，做起来一点都不简单：你怎么定义”AI 做得好”？
一句”回答要准确”远远不够。准确是什么？在什么情境下算准确？可以漏掉什么？绝对不能错什么？它不确定的时候应该问人还是自己查资料？答错了，错到什么程度算严重？
Cat Wu 说：
“不需要一开始做几百个 eval，有时候 10 个好的 eval 就很有价值。”
（”You don’t need to start with hundreds of evals. Sometimes 10 good evals are very valuable.”）
拿客服 AI 举例，光说”要能回答停车问题”是不够的，得定义：遇到退款问题时，什么情况可以自动回答？什么情况一定要转真人？如果用户情绪很差，要怎么判断？如果订单资料不完整，要不要继续回答？如果答案没有足够把握，要怎么保守处理？这些都是产品判断，也是 eval 的来源
Claude Code 的 Agent teams 功能（让多个 Claude 协同工作）也是这么做的——团队成员专门做了一套测试，什么场景下有效、什么时候会出问题、该怎么改进。数据支撑下，抽象的功能描述变得具体可衡量
还有一点：每次新模型发布后，都值得把已有功能重新审视一遍。你上个月发布的功能，这个月新模型可能让它突然变强了
未来好的 PM，未必是最会写 PRD 的人，更可能是最能把模糊的人类期待，转成 AI 可以被测试、被改善、被部署的标准的人
从文档优先到 Demo 优先
Cat Wu 团队的工作方式跟传统 PM 流程已经不太一样了
Research preview 机制。Claude Code 几乎所有功能都先以研究预览的形式发布，明确告诉用户：这是早期产品、只是一个想法、我们在收集反馈、这个功能可能不会永远支持。这降低了发布承诺，一两周就能把东西推出去。release 从一个阶段的终点，变成了观察工具——把东西推到真实用户面前，一方面是交付价值，一方面是用最快的速度拿到下一轮信号
Evergreen launch room。工程师觉得功能准备好了，就把它发到这个频道。负责文档、市场营销、开发者关系的同事直接跳进来，第二天就能完成对外宣传。搭这套发布流水线，就是 PM 该干的事
Side quest 文化。团队鼓励所有人随时做”支线任务”——有想法别开会，下午自己去试试。Anthropic 几个挺火的功能，桌面版 Claude Code、AskUserQuestion 工具、todo lists，都是这么”玩”出来的，没有谁专门规划过
Team principles 替代 PRD。团队维护一份原则文档：核心用户是谁、为什么是他们、愿意做什么取舍。每个工程师看到一条用户反馈，能自己判断它属于哪类用户；设计师做交互取舍的时候，知道哪些体验可以牺牲。PM 没办法站在每条路径上一个一个审批，只能把判断标准提前铺在地上，让团队在很短的循环里自己跑
PM 在变成什么
Cat Wu 的核心观点是：PM 这个角色正在从”需求管理者”变成”AI 工作系统的设计者”
AI 能自己执行了，PM 的价值在定方向、给上下文、设计反馈、判断产出质量。模型能力一直在变，PM 的价值在不停地重估——这里应该补模型、约束模型，还是放手让模型自己来
这件事并不遥远。Cat Wu 讲的不是科幻，是很多产品团队接下来一两年就会遇到的现实。Anthropic 大约有 30-40 名 PM，分布在研究、开发者平台、Claude Code、企业和增长五个团队。即使在 Anthropic 这样一个”大量招有产品品味的工程师”的组织里，PM 仍然不可替代——因为执行不再稀缺以后，真正稀缺的问题是：该把什么东西放进循环里，以及怎么判断循环有没有真正学到东西
Cat Wu 面试了几百个 PM，product taste 仍然是一种很稀缺的技能。她说：
“任何能强有力地展示这种能力的人，我们基本都会录用。”
（”Product taste is still a very rare skill to have, and we’ll pretty much hire anyone who we feel has demonstrated this strongly.”）
最后用她的另一句话作结尾：
“Just do things. 如果你知道自己要优化什么，而且有清晰的第一性原理，那么通常就能推断出正确的行动方案，并清楚地向所有利害关系人解释清楚，然后就应该去做。”
（”Just do things. If you know what you’re optimizing for, and you have clear first principles, you can usually figure out the right course of action, explain it clearly to all stakeholders, and just go do it.”）
参考资料：
Lenny’s Podcast × Cat Wu：https://www.youtube.com/watch?v=PplmzlgE0kg
Karpathy YC AI Startup School 演讲：https://www.youtube.com/watch?v=LCEmiRjPEtQ
Karpathy “I’ve never felt this much behind as a programmer” 推文报道（机器之心 / 36 氪）：https://eu.36kr.com/zh/p/3613263277868036
本文由 @秋孝隱 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。