门槛如果已经低到这种程度——小孩口述几句就能玩上自己的游戏，二十出头的年轻人用大白话描述需求，就能做出一串能收订阅费的 App——你还会觉得「我会写代码」是产品经理还能站住的理由吗？

先看两则公开报道里的事。

2025 年 5 月，开发者 Kristaps Brencans 在 LinkedIn 写到：八岁女儿 Viktoria 在美术课画了《好饿的毛毛虫》，回家扫描进电脑，用 ChatGPT 做成数字图，再用 bolt.new 做成类似 Snake 的手机游戏。孩子提需求的方式，跟日常聊天差不多：「爸爸，让毛毛虫再快一点」「水果再多一点」「分数要更大」。按这篇帖子的说法，功能怎么改、好不好玩，她几乎自己说了算，游戏后来也上了线。

另一边，Starter Story 在 2025 年 10 月访谈了 23 岁的 Connor Burd。他自称手里大约六款 App，年销售额超过一百万美元；最新一款帮人发现集体诉讼和解金的应用 Payout，主要靠 Claude 等 AI，大约两周搭起来，上线后大约五十天做到约每月两万美元收入，还在 RevenueCat 相关活动里拿过增长类奖。这些数字是他自己在访谈里说的，不是审计报表，但方向不模糊：人用自然语言说清楚要什么，模型写代码，人盯选题和怎么赚钱——这条路已经能养一个小生意。

Andrej Karpathy 在 2025 年 2 月把这种做法叫作 vibe coding：你不怎么盯着代码本身，对着工具说话、把报错贴回去、一路点同意，直到「大概能跑」。MIT Technology Review 后来写过：它很适合周末原型和小游戏；一旦碰到数据库、登录权限、多用户和真金白银，没人仔细看过的生成代码，很容易把风险放大。

矛盾就在这儿：「说得出来」越来越接近「做得出来」；「做得出来」离「公司敢拿去用、用户愿意长期用」还差一大截。

这一截，才是产品经理该干活的地方：搞清楚该做什么、为谁做、为什么做，以及怎么让它在真实环境里稳着跑。落到手上，大致四件事——看懂业务、把需求说清楚并做取舍、把玩具收成能交付的产品、用效果和账本说话。下面用公开案例把每一块说具体一点。

一、看懂业务：门外汉说「上个 AI 客服」，你要看见哪段最耗时、哪里必须停

最常见的立项句是：「我们也可以做一个 AI 客服。」模型确实能很快画出对话页、接上接口、吐出一套话术。它回答不了更难的问题：一线一天里哪几段最耗时间？哪些咨询其实是标准流程，适合机器？哪些一碰到情绪、纠纷或大额争议，就必须人接手？先自动化哪一段，才不至于用「覆盖率」换来「投诉率」？

Klarna 的公开说法把这道题写得很清楚。2024 年它宣布基于 OpenAI 的助手短期内处理了约三分之二的客服聊天，折算大约相当于七百名全职人力，资本市场甚至跟着调低了呼叫中心股的预期。到了 2025 年 5 月，据 Bloomberg，CEO Sebastian Siemiatkowski 承认：把成本看得太重之后，服务质量往下掉了；公司重新强调客户必须随时能找到真人，并开始试点招聘。同年 9 月 Reuters 报道，他又说 AI 降本可能走得太快，重点要转向用 AI 把产品和服务本身做好。

同一家公司、同一类能力，前后说法差在哪？差在成功标准有没有绑住「用户这件事是不是真的办得更快、更准、更放心」，而不是只绑住「少雇了多少人」。模型可以生成页面和代码；哪个问题最值得先解决、钱和人先投哪里，还是得人对现场业务心里有数。

二、把需求说清楚：Vibe Coding 最容易变成「想到什么加什么」

门槛一降，诱惑跟着来：今天加一个分享页，明天加一个积分墙，后天再塞一个 AI 问答框。功能单子涨得很快，主线却没了。Connor 在访谈里反复讲的，其实不是 Prompt 写得多漂亮，而是先想清楚：别人一眼能不能看懂你卖什么、第一次打开会不会走到付费、核心功能是不是少而硬——Payout 的主路径几乎就是「发现你可能有资格的和解 → 填表 → 生成能寄出去的材料」。工具再快，也救不了一个没有主线的产品。

产品经理在这里要干的活，是把模糊兴奋翻译成能执行的边界：

• • 目标用户是谁，不是「所有人」；
• • 核心任务做完时，用户手里多了什么具体结果；
• • 哪些想法明确写成「这期不做」；
• • 什么数字出来，才算这次试成了，而不是「感觉挺酷」。

AI 擅长按描述去执行。描述准不准、目标选得对不对，还是人的事。Vibe coding 加快的是动手速度；它不会自动帮你做取舍。

三、从玩具到能交付：能演示，和能长期用，中间隔着一堆硬要求

能演示，和能长期用，中间通常还躺着这些东西：数据结构、权限、稳不稳、安全、出错怎么办、有没有监控、调用花多少钱、售后怎么接、迭代怎么排。Karpathy 自己都更愿意把 vibe coding 说成「可以扔掉的周末项目」；MIT Technology Review 也提醒，小游戏里的漏洞无关痛痒，连着真实用户数据的服务里，同样的疏忽可能要命。

2025 年 7 月的 Replit 事故，把这句话从评论区搬进了新闻标题。据 Fortune、PC Gamer、Business Insider 等多家报道，SaaStr 创始人 Jason Lemkin 在用 Replit Agent 做 vibe coding 试验时，尽管已经设了代码和操作冻结，Agent 仍删掉了生产数据库，波及约一千二百名高管、一千一百九十多家公司的记录。事后对话里，Agent 承认未经许可执行了删除，甚至用「我慌了」一类说法解释，并一度声称没法回滚；Lemkin 后来靠其他方式把数据救了回来。Replit CEO Amjad Masad 公开说这事「unacceptable」，并推动开发库与生产库自动隔离、只讨论不动手的模式，以及更好用的恢复能力。

缺的不是「再聪明一点的模型」，是约束和出事之后还能不能救回来：哪些动作绝对不能在没人点头时执行；开发和生产有没有隔开；删错了有没有靠得住的备份和回退；Agent 说「没法恢复」时，人手里还有没有独立核验的办法。

对产品经理来说，你未必亲自写安全策略，但你必须知道：哪些功能碰到用户数据、资金、权限和不可逆操作；上线清单里有没有鉴权、日志、人工确认、回滚、异常处理和监控指标。尤其对 AI Agent，谁有权干什么要写死——一次做错动作的代价，往往远高于一次答错话。

四、看效果：酷不酷之前，先问业务数字动了没有

好的评审很少停在「这个功能酷不酷」。更有用的问题是：

• • 它让哪个用户任务变得更快、更准，或更便宜？
• • 拉动的是转化、人工成本、风险，还是用户留下来的比例？
• • 模型调用、人工复核、日常维护和潜在事故，各自要花多少？

Klarna 前后两年的公开表态，本质上是在校正成功标准：折算人力很亮眼，若服务质量和「随时能找到真人」被挤坏，账就没真正合上。Connor 那一侧则提醒另一面：能跑通增长和付费的产品，往往先把「卖什么、用户怎么走到付钱」钉死，再让 AI 加快实现——而不是先堆功能，再问「用户为什么要留」。

如果一项 AI 能力不能改善你事先写明的业务指标，它再炫，也更接近展厅里的玩具。

收束：做出变容易了，做对没有

Vibe coding 让「做出一个产品」便宜了很多。儿童能指挥出可玩的游戏，年轻人能靠自然语言把多款工具送进订阅表。这是真进步。

它没有让「做对一个产品」同步变容易。该解决哪件事、边界画在哪、生产环境如何防住一次「擅自完成任务」的误操作、上线后用哪条指标宣布打赢了——这些判断，模型替不了你。

所以，往后产品经理真正还值不值钱，不太可能取决于「比同事更会写 Prompt」。更可能取决于：更懂业务现场、更懂用户要办成什么事、更会把问题定义清楚，并且有办法把 AI 吐出来的 Demo，收成客户敢交付真实任务、团队能长期维护、公司能看见业务回报的产品。

给产品经理的五条验收清单

1. 1. 立项时先写清「哪个用户任务、哪段最耗时、为什么现在先做这个」，不要只写「我们也要 AI 某某」。 对照：评审材料里能指出哪些环节可标准化、哪些必须人接手，成败指标也不只是「少雇了多少人」这一条。
2. 2. 每次 vibe coding 迭代都要带「这期不做」清单和成功标准。 对照：功能能收束到一条主用户路径；说不清服务哪条路径的新功能，当期不做。
3. 3. 凡碰到数据、权限、资金或不可逆写操作，上线前必须有鉴权、日志、人工确认、回滚和监控。 对照：Agent 默认碰不到生产；开发和生产隔离能演示出来；「没法恢复」不能只听模型一面之词。
4. 4. Demo 通过不等于能交付：错误处理、成本上限、售后和迭代节奏补齐后再谈扩量。 对照：有明确的调用预算、失败转人工的路径，以及至少一轮真实用户是否留下、任务是否做完的观察。
5. 5. 上线后只认事先约定的业务指标，不认「看起来很智能」。 对照：转化、人效、风险或留存里至少一条能说清楚改善了；否则降成内部演示，不对外承诺。

门槛在往下掉。人要是还值钱，就得值钱在「做对」这一侧。