在AI编程工具从Vibe演变成Wish那会儿，产品经理的角色正处在被重新定义的状况之中。蚂蚁集团灵光App所提出来的新概念，能让PM仅仅凭借自然语言的描述，便生成可以运行的应用。这一方面释放了大量受到开发资源限制的产品创意，另一方面也引发了关于PM核心价值的深度思考。本文会剖析Wish的革命性突破以及现存的局限，并且揭示在这个“人人都是开发者”的时代里，产品经理最为不可替代的三大判断力。

我运用写代码这一行为已然近似半年之久了。提及“写代码”此表述实则并不全然精准——相较而言更像是“指挥代码”。我于特定范围里键入些许语句用以阐述我内心所求之物，人工智能便迅速接连不断地生成众多文件，我运行一番以查看实际呈现的效果，若发现存在偏差便再度表述些许内容，它随之进行修改。如此反复历经几个回合，一个尚算说得过去的原型便得以诞生了。

身为一名产品经理，这般体验致使我既有颇感兴奋之情，同时又隐隐怀有不安之感，兴奋所在之处在于，往昔撰写 PRD 后抛给开发并等待两周之事，现今于下午我便能自行去搞出一个 demo 来佐证心目中的想法，不安之处则在于——倘若人人皆能够如此行事，那么 PM 所存在的意义究竟是什么呢？

一直到昨天，看到了蚂蚁集团灵光 App 所提出的“Wish”这样一个概念，如此这般的不安，就变成了一个更为具体的问题。

先把概念捋清楚

在过去一年当中大概率你已然听腻了Vibe ，这个词于2025年初被创造出来，实际上就是，你运用自然语言对AI表述你所期望的功能 ，随后AI助力你写好代码 ，你甚至无需理解哪些代码 ，只要能运行加以使用便可以了。

词典将其选为2025年度词汇，超过一半的提交代码已然是AI生成的，在2025年冬季批次里，四分之一的创业公司代码库中95%是由AI写出的，这些具体数据已不再是新鲜事物了。

昨天，让我真正坐直的，是灵光App升级后，所提出的那个新词：Wish。

它和 Vibe 的区别在哪里？我试着用一句话讲清楚：

促使 Vibe 加速的乃是“编码”呀 ，你依旧得与代码进行交互呢 ，也就是要安装 IDE ，配置环境 ，管理依赖关系 ，最后实现上线部署。Wish 期望跳过的恰恰是“代码”这件事情本身呀 ，你仅仅只需说出你所期望得到的东西 ，系统便会从生成直至部署 ，全程一站式的为你交付一个能够正常使用的应用。

用我们 PM 所熟知的话语来讲，Vibe 让开发效率提升至十倍之多，然而其使用门槛仅仅降低了些许。Wish 所要达成的，乃是直接将门槛予以拆除。

为什么 PM 应该认真对待这件事

你或许会认为，这难道不就是那低代码或者无代码的陈旧事例，只是换了个全新的包装而已吗？我在最开始的时候，也是这样去想的。然而，当我认真仔细地审视了灵光的产品逻辑之后，我便改变了原本的看法。

常规的那种低代码平台，诸如简道云、明道云这类，实际上是在进行“模块拼装”操作，也就是给你一系列预先制造好的组件，让你通过拖拽来进行组合，它的上限极为有限，一旦遇到稍微复杂些许的需求便无法处理。

Wish有所不同，它在底层运行的依旧是大模型代码生成，从理论上来说，其能够做到的事情与程序员亲手编写代码大致相同，只是它将诸如IDE、终端、部署这些，只有程序员才明白的内容全部进行了封装处理，用户所看到的仅仅是一个对话框，在讲完需求之后，等待片刻，便能获取到一个可以使用的应用。

这究竟意味着什么呢 ，意味着 ，以往 ，卡在 ， “有想法但没有开发资源” ，这个瓶颈之上的 ，大量需求 ，突然间 ，有了 ，释放的出口。

有过做 PM 这种经历的人，都清楚，这个瓶颈是何等的真实。你要是有 20 个想要去验证的想法，然而开发团队在一个迭代之中，仅仅能够安排进去 3 个而已。那么剩下的 17 个，要么就一直待在需求池里，慢慢发霉，要么就得等你积攒够了政治资本，才能够把其中一个推上去。

倘若这十七个想法之中的半数能够借助Wish直接制作成demo，甚至是MVP呢？

我自己踩过的坑

提及此处，就不得不去讲述一下我自身的经历，原因在于它确切地表明了 Vibe 与 Wish 之间的那一道鸿沟。

之前，我运用 + Code 为自身打造了一个信息聚合工具的原型，从功能层面审视，完成度尚可，能够对多个信息来源予以抓取，施行基本的分类及筛选举措，而且前端看上去好歹也还凑合，整个构建进程大约耗费了两个周末的时间。

但中间有多少时间花在了”功能之外”的事情上呢？

在安装Node.js环境之际，版本出现了冲突状况，为此折腾耗费了一个小时。对于数据库选型，纠结了多时，最终是出于图省事的缘由。在前端框架方面，于React和Vue之间徘徊不定。将其部署至服务器时，又遭遇了一堆nginx配置的难题。其间还碰到过一次，所生成的代码致使我本地文件目录结构变得混乱不堪，花费了两个小时才得以恢复。

这些事情，其中每一件，都与我真心想要去验证的产品假设，不存在任何关联，然而，它们却耗费了我最少40%的时间。

当时要是存在一个工具，能使我越过这所有的一切，仅仅将注意力集中于“这个功能应当呈现出怎样的样子，交互逻辑究竟是什么”，——如此这般才是 PM 切实应当耗费时间的所在之处。

让我觉得 Wish 值得认真看待的原因就在于此。它所解决的并非是“怎么写代码更快”的状况，而是“PM 到底能不能完全不触碰与代码相关的任何事物，直接去验证产品想法”的情形。

冷静一下：Wish 的三个硬伤

固然没错了，兴奋是兴奋着，然而从事产品制作的人，绝不能够仅仅看重愿景，却忽视约束条件。Wish在当前阶段，起码存在三个显著的问题，倘若讲不清楚，那就是没有尽到责任。

第一，复杂度的天花板。

没问题，AI生成一个待办清单应用能行，SaaS产品有登录、有支付、还有实时协同，现阶段不行。一篇Red Hat的分析这么说：不懂技术的人写的需求规格书不是蓝图，是许愿清单。AI能帮你许愿，建筑质量取决于图纸精度。

这表明，Wish，更适宜于验证阶段，而非交付阶段。PM，利用它迅速开展demo，并无问题，然而，别期望它直接产出能够上线运营的系统。

第二，安全性是定时炸弹。

研究指出，大模型在过去三年之际于生成功能性代码方面具备的能力呈现突飞猛进态势，然而代码安全性这块的进展近乎没有。在2026年初的时候codejock 17，便产生了一个vibe coded的应用出现数据泄露状况，致使150万个API密钥以及3.5万用户邮箱被暴露出来。究其原因在于，开发者（其实际上属于未曾编写过哪怕一行代码的一位普通用户）根本就不晓得数据库是需要进行权限配置的。

对产品经理而言codejock 17，这当属一个颇具实操性的提示，即借助Wish来开展内部工具的构建，进行原型演示呈现，实施概念验证操作均无不可，然而一旦牵涉到与用户数据以及金钱交易相关的功能之处，那就务必规规矩矩地交付予专业工程师来处理。

第三，调试是噩梦。

如下那句话总结得极为恰当：二十分钟能够生成两万行代码，然而却需要两年的时间用以展开调试，且生成了之后你难以解读，出现了故障你也不清楚该从哪里着手去处理。麻省理工学院的研究也表明，人工智能所生成的代码看似很””，但实则反倒致使错误变得更加难以被察觉。

这表明，Wish所产生的事物，其生命周期必定是短暂的。你能够将它视作一次性原型来加以运用，然而不要期望它能够持续不断地迭代演化。

PM 的真正机会在哪

聊完风险，说说我认为 PM 应该怎么看待这波变化。

并不是 Wish 在取代产品经理，而在于它正采取行动，重新去界定 PM 的核心竞争能力。

在过去的那些年份当中，好多项目管理者日常从事具体工作实际上是在开展“翻译”行为，也就是将业务端的要求转化成开发人员能够明白的表述方式，撰写产品需求文档、绘制原型图、对接接口这一系列事宜全都要做。这些工作并非毫无重要性可言，然而它们所具备的价值正处于迅速缩减的态势。究其原因在于，人工智能在理解自然语言形式表述的需求方面能力日益增强，处于中间位置的翻译层次变得愈发单薄了。

那什么东西是 AI 替代不了的？

判断力。

具体来说是三种判断力：

能够进行怎样的判断力。在这样一个“做应用”成本渐渐趋向于零的世界当中，稀缺的并非产能，而是方向感。究竟应该为用户解决哪一个问题。这个问题是否值得去解决。市场之上有没有人已然解决了。这些判断是需要对于用户的深入理解，对于市场的持续观察，对于商业逻辑的穿透力。这些存在的事物并非是几句话语就能够去替代的。

具有不做某些事情的那种判断力。而当所有的人全都能够在一瞬间就做出一个 app 的情形下，克制相较于执行是更为稀缺少见的。你清楚在那一堆看起来都还不错的功能里面，哪些是要砍掉的、哪些是要留存下来的，还清楚什么时候应当去做减法，而这本身就是一番专业能力。

明确界定标准的判断力，AI所生成的事物具备可用性，然而，“具备可用性”与“具备良好使用体验性”之间存在着极大差距，交互方面的细微环节该如何精心雕琢，异常状况下的流程要怎样妥善处理，边界情形是否已周全考量，这些均属于PM的专业范畴，亦是产品质量的真正关键区分界限。

一个实操建议

到最后来讲讲实际相关的。要是你身为PM，我有个建议，你此刻就着手做一件事情，将Wish类工具归进你的日常工作流程里，不过仅仅是用于验证的阶段。

下一回你碰到一个得跟老板或者利益相关方交流的产品想法时，别再耗费三天去撰写PRD了。不管是凭借灵光，还是借助别的什么方式，拿出半天时间做出一个能够运行的demo来。运用真实的可交互原型去实现沟通，而非使用PPT以及Axure线框图。

这般去做存在两个益处，其一，验证的速率加快了一个数量等级，众多不太靠谱的想法，于demo阶段便能够被摒弃掉，得以避免白白耗费开发资源；其二，在团队范围之内构建起一种全新的认知，即这个PM并非仅仅只会绘制原型、撰写文档，他能够直接将想法转化为能够付诸操作的事物。

然而要记住这样的底线，Wish所产生出来的事物是用以对想法进行验证的，并非是用于上线的。在验证通过以后，该去撰写技术方案的依旧得去撰写，该开展code相关操作的依旧得去开展。以许愿的形式作为开头，以工程的形式作为收尾。

这大致说不定会是，2026年时，一个身为产品经理的与AI编程工具之间那种最为健康的关系。

作者表明：此篇文章的观点，源自于我历经半年的使用，以及对于 Code 的真切体验，还有就是针对蚂蚁灵光等新一代 AI 编程产品所做的产品分析。要是存有不一样的看法，欢迎留言予以交流。

如有侵权请联系删除！