2026 年 9 月 1 日，埃隆·马斯克在 G20 创新部长级会议上作出了一个相当激进的预测：到 2027 年底，AI 可能完成几乎所有纯数字领域的工作；软件开发能力可能在未来一年左右达到他所说的“Stockfish 级”，让人类难以直接与 AI 竞争。设计、开发、测试和试错的门槛正在持续下降。过去需要产品、设计和工程多轮协作才能验证的想法，现在一个人借助 AI，可能几小时内就能做出一个可演示的版本。
这很容易带来一个结论：既然这么容易就能做产品，产品经理会不会变得人人都能当？
我的观点恰好相反。
AI 降低了“造出一个功能”的门槛，却没有降低“做出一个好产品”的门槛。当功能、方案和代码都更容易生成时，产品最稀缺的部分——理解市场、定义问题、创造体验、作出取舍并对商业结果负责——反而被推到了更前面。这就是所谓的“产品力”。
AI 让更多人能够动手做产品，但不会让更多人自然就成为产品经理。
当数字化执行越来越容易
前面提到的马斯克的判断，时间点未必准确，“所有数字化工作”也显然是一个需要谨慎理解的范围。但它指出的方向值得认真对待：代码、页面、原型、分析和其他标准的数字化执行工作正在快速变得更便宜。
这并不意味着技术从此没有价值。复杂架构、可靠性、安全、专有数据和深度工程仍可能构成壁垒。但“我们会开发软件”本身，将越来越难成为长期护城河。一个团队可以很快地做出很多东西，也可能更快地做错更多东西。
当执行能力大量涌现，真正稀缺的就变成了另外一些东西：应该为谁解决什么问题，什么体验值得创造，哪些可能性应该放弃，以及企业愿意为哪一种结果持续投入。
这些仍然是人的工作。
产品不只是一套软件
产品 = 用户 + 解决的痛点 + 交付载体 + 价值交换
也就是说，产品是一种客户愿意选择、使用并付费的服务或体验。软件可以是载体，AI 可以是能力，最终被市场检验的却是：它是否解决了值得解决的问题，是否创造了足够好的体验，又能否形成可持续的商业结果。
在这个意义上，本文所说的产品经理，并不只是 Scrum 里的一个岗位名称，也不只是负责维护 Backlog 的 PO。他更接近一项产品业务的经营者：知道客户是谁，价值主张是什么，收入和成本怎样形成，并愿意对采用、留存和 P&L 结果承担责任。
不是每一位产品经理今天都拥有完整的 P&L 权限，但 AI 时代的产品岗位需要逐渐建立这种经营意识和责任。只负责功能是否按时上线，却不关心客户是否愿意使用、付费和继续留下，已经很难算完整的产品责任。
产品负责人不是需求的搬运工
AI 可以帮助整理访谈、归纳反馈、生成竞品分析、画原型，甚至直接写出第一版代码。它擅长提供可能性，却不能替产品负责人决定哪一种可能性值得投入。
用户和业务部门会提出各种要求。产品负责人不能只是把这些要求转成需求文档，而要继续追问：问题是否真实、是否足够重要，用户为什么仍然对现有方案不满意，以及什么改变会让他愿意换一种做法。
沃尔玛的生成式搜索是一个直观的例子。它的关键并不只是把搜索变成一种对话体验，而是允许用户围绕一次聚会或者迎接新生儿这样的生活任务表达需求，再帮助用户完成跨品类选择。技术是生成式搜索，产品上的关键却是把“找商品”重新理解为“完成一项生活任务”。
模型可以生成推荐，但不能替产品负责人决定：用户真正卡在哪个决策上，怎样建立信任，哪些步骤应该省略，哪些控制权必须留给用户。
产品负责人正在成为经营单元
如果借用 OPC（One-Person Company）的概念，AI 时代的产品负责人越来越像公司内部的一个微型经营单元。他不必独自完成所有工作，但要能够调动 AI 和专业团队，把市场判断、产品设计和技术实现组织起来，并对结果负责。
AI 时代的产品经理，往往需要横跨三个工作面。
第一是产品业务。
产品负责人要理解市场、客户分层、价值主张、定价、单位经济和增长路径。目标不只是“完成一个产品”，而是经营一项有人愿意持续选择的业务。
第二是数字化产品与体验设计。
一项体验往往横跨界面、数据、规则、流程和线下服务。尤其在 To B 场景里，所谓用户通常不止一个人：使用部门、业务负责人、采购、IT、信息安全和法务，都可能决定产品能否被采用。比如，Microsoft Copilot 以用户原有权限作为数据访问边界，用户不能借助 Copilot 读取自己本来无权访问的内容。这说明企业产品的设计对象不只是回答界面，还包括身份、权限、合规与治理。
第三是AI Agent 编排。
这不只是会写 Prompt，也不要求每位产品经理都成为底层模型工程师。但产品负责人至少需要理解怎样把任务拆给模型、工具、确定性程序和人：上下文从哪里来，什么结果需要评测，哪些动作必须审批，失败时怎样转交，延迟和成本是否还能支撑商业模式。
生成式 AI 的输出具有概率性。功能上线不代表结果稳定，一次演示成功也不代表用户会在真实工作中持续采用。产品负责人需要把 Eval、人工边界、反馈和迭代机制当成产品本身，而不是上线后的技术补丁。
这三个工作面不是三份并列的工作清单。真正困难的，是在商业目标、用户体验和技术现实发生冲突时作出取舍，并把取舍变成一项能够持续经营的产品结果。
“古典工种”都可以走向产品经理，但难度各异
对已经在做产品经理的人来说，这并不是一场从零开始的职业竞赛。他们本来就在业务、用户和技术之间周旋，已经拥有成为多面手的起点。接下来就需要向两端各走一步。向业务端，是从负责功能和版本，走向理解商业模式、配置投入并承担经营结果。向技术端，则是从“把需求交给开发”，走向能够亲自编排 AI、快速验证产品假设，对数据、权限、安全、评测、成本和运行边界作出判断，并把这些边界纳入产品设计。
传统业务人员的优势，是了解客户、流程、行业规则和钱从哪里来。他们通常不缺问题，也不缺想法，缺的更多是上面提到的产品力，即把经验变成产品的能力：哪些需求值得标准化，哪些只是个别例外，最小版本应该验证什么，又怎样把一次做法变成别人也能使用的服务。要走向产品负责人，他们需要学会定义产品、设计体验，在短期验证与长期产品方向之间作出取舍。他们还要能够理解技术方案，借助 AI 做出第一版原型，再用真实采用和付费意愿检验自己的判断。
而开发人员和工程师恰好站在另一边。他们能够把需求变成系统，也更容易理解模型、数据和架构，却可能把“技术上能不能做”当成主要问题。要走向产品负责人，他们需要主动走出需求单和技术方案，去看客户为什么不用、业务怎样赚钱、一个问题是否值得解决，以及什么样的体验才能让人愿意改变原来的习惯。工程的严谨当然重要，知道什么必须一次做对、什么可以先用小规模验证，同样重要。
这不意味着一个人要包办所有专业工作。真正有竞争力的产品负责人，不是样样都比专家做得更深，而是能够横跨产品业务、数字化产品与体验设计，以及 AI Agent 编排，把专业团队组织起来，持续作出取舍，并对最终的商业结果负责。
AI 会继续让“做出来”变得越来越容易。
真正难、也真正有价值的，是始终知道为什么做、为谁而做，什么值得被做成产品，以及怎样让客户愿意为它买单并持续使用。
当“施工”变得便宜的时候，决定什么值得保留，并对它的成败负责，反而会变得更贵。
如果这篇文章对您有所启发，欢迎点赞、关注并转发给更多朋友。更多内容，敬请访问 FFDE.ai ( www.ffde.com.cn )。