当 AI 能自己编写代码开发产品的时候，产品经理还剩下什么？

随着大模型和辅助编程工具的普及，开发软件原型的门槛被大幅拉低。工程师可以用自然语言快速生成可运行的界面与逻辑，不少人因此产生疑问：如果代码生成已经如此低廉，传统意义上的产品经理（PM）是否正在失去存在的必要？

a16z 的 Josh Elman 对此给出了截然相反的判断。他的核心观察非常明确：代码的构建成本确实在大幅下降，但做出正确产品判断的成本，一分钱都没有降低。

这不是抽象判断。Josh 早年在 RealNetworks 负责 RealPlayer 的产品与工程团队时，商业团队曾建议每次播放器启动都展示广告，并拿出 Excel 表格说明能赚多少钱。他知道这会伤害产品，却说不清该如何用产品判断反驳财务预测。

后来，Reid Hoffman 在 LinkedIn 的面试中问他：「产品经理产出的制品（artifact）究竟是什么？」Josh 当时回答是规格说明书（spec）。加入 LinkedIn 后，他还为「社交网络里的招聘平台」写过一份 120 页的规格，详细定义体验与需求。

但规格只能描述系统要做什么、完成时要勾掉哪些检查项。多年后 Josh 意识到，PM 真正的 artifact 是一个「故事（story）」：谁在使用产品，它为什么会影响这些人的生活。这个故事不是营销文案，而是一幅团队共同理解的图景；任何人都应当立刻听懂，并能在 PM 不在场时准确复述。它还要回答用户为什么来、每一步有什么感受、哪里应该令人惊喜、哪里可以有意保持平淡。

这也引出了作者对产品经理的核心定义：帮助团队（和公司）把正确的产品交给用户。PM 不是凌驾于团队之上的领导者，而是要理解自己的团队及其在公司整体目标中的位置，协助团队真正把产品交付（ship）出去，并持续判断究竟什么对用户才是「正确（right）」的。

当把东西做出来变得极其容易时，团队面临的最大危险不再是做不出功能，而是以极快的速度制造出大量没人需要、逻辑断裂、用户用完即走的平庸功能。探讨 AI 时代的产品工作，核心在于理解开发循环发生的翻转，以及如何建立真正以用户价值为核心的判断框架。

开发循环的翻转：从漫长推演到原型先行

在传统的软件研发体系中，工程时间非常昂贵。为了避免昂贵的工程资源投入到错误方向，团队在真正编写代码之前，必须先投入大量精力撰写功能规格（spec）、做成本估算（costing）、界定范围（scoping）并完成设计（design）。在这种严谨的前期推演下，团队一年大约只能跑六到八轮完整的开发循环。

引入 AI 编程工具后，这种开发循环发生了根本性翻转：从原先的纸面推演，变成了提出想法（idea）→ 先用 AI 构建（build）→ 上手把玩走查（play with it）→ 再做视觉/UX 与工程设计（visual/UX & engineering design）→ 交付（ship）→ 学习反馈（learn）。