VibeCoding 浪潮下，产品经理最值钱的能力变了

guozi

VibeCoding 让产品经理第一次能直接把需求变成可运行的产品，但大多数人的产出是"能用但粗糙"——注册没有验证、数据没有权限、流程没有闭环。差距不在工具，在于需求描述的精度。产品经理多年修炼的 PRD 能力、用户视角和边界思维，在 AI 开发时代反而成了最稀缺的竞争力。



上周，一个做产品经理的朋友给我发了一个链接。

点开，是一个能跑的 SaaS 工具——用户注册、数据看板、导出报表，全都有。他兴奋地说，这是他用 AI 花了两个小时做出来的，一行代码没写。

我看了一圈，跟他说：能跑，但你这个东西上线会出事。

注册页面没有输入校验，用户输错邮箱也能注册成功，后续收不到验证邮件；用户密码没有加密存储，存在数据泄露风险；数据看板没有权限控制，任何人拼个 URL 就能看别人的数据；导出功能没有限制频率，一个脚本就能把系统跑崩，所有用户都用不了。

他愣住了。他说，我就是跟 AI 说”帮我做一个用户注册功能”和”做一个数据看板”，它就帮我做出来了啊。

问题就出在这里。
一、AI 不会替你思考边界
很多产品经理对 VibeCoding 的理解是：我告诉 AI 我想做什么，它帮我写代码，搞定。

这个理解不能说错，但少了最关键的一环。

你告诉 AI”做一个用户注册功能”，它确实会做。但它做的只是”能注册”——输入邮箱密码，点按钮，存进数据库。至于邮箱格式不对怎么办、密码太短怎么办、邮箱重复注册怎么办、网络断了怎么办——如果你不说，AI 不会自己想。

因为它不知道。

AI 没有用过你的产品，不知道你的用户是谁，不知道什么场景会让你的客服电话被打爆。它只知道你给了它一句话，它按最常见的方式实现。

这就像你跟一个刚入职的开发说”帮我做一个注册功能”，然后就走了。他做出来的东西，大概率跟你脑子里想的不一样。不是他能力不行，是你没说清楚。

区别在于：跟人协作，对方可能会追问；跟 AI 协作，你不问，它就不说。

PM 视角：这个问题产品经理太熟悉了。我们每天在做的事，就是把”我想要一个 XX”翻译成”在什么场景下，给谁用，成功是什么样，失败是什么样，边界在哪里”。PRD 写得好不好，直接决定了开发做出来的东西对不对。VibeCoding 时代，这个逻辑没变，只是接收方从开发变成了 AI。而 AI 比开发更需要精确的描述——因为它不会主动问你问题。产品经理多年写 PRD 练就的边界思维，在 AI 协作中直接变成了生产力。
二、需求描述的精度，决定了 AI 产出的质量


我来举一个具体的对比。

低精度的描述：

“帮我写一个用户注册功能。”

AI 产出：一个最基础的注册表单，邮箱+密码，点提交就存库。没有校验，没有验证邮件，没有错误提示，没有防重复注册。

高精度的描述：

“用户通过手机号注册，输入手机号后发送验证码，验证码 5 分钟有效。注册成功后进入引导流程，引导用户完善资料、选择兴趣标签。手机号已注册时提示’该手机号已注册，请直接登录’。注册页面底部显示用户协议和隐私政策链接。”

AI 产出：完整的注册流程，带验证码校验、引导流程、错误处理，而且有合规的用户协议。

同样是”做一个注册功能”，两种描述出来的东西天差地别。

差别在哪里？四个维度：

维度

低精度

高精度

用户是谁

“用户”

“新注册的用户”

场景是什么

“点击注册”

“在注册页面输入手机号，点击获取验证码”

成功是什么

“能注册就行”

“注册成功后进入引导流程，5 步完成资料填写”

失败是什么

（没写）

“手机号格式错误提示’请输入正确手机号’，验证码过期提示’验证码已过期，请重新获取'”

这四个维度，产品经理闭着眼睛都能背出来——这不就是我们写 PRD 时反复强调的”用户故事”和”验收标准”吗？

PM 视角：多年写 PRD 的经验，在 VibeCoding 时代直接变成了生产力。你花 10 分钟写清楚的需求描述，AI 用 5 分钟产出完整功能。别人花 1 分钟说一句模糊的话，AI 用 5 分钟产出一个需要反复修改的半成品。10 分钟对 1 分钟的投入，换来的是 5 分钟对 5 小时的返工。
三、上下文工程：给 AI 写 Brief，跟给老板写 Brief 是一回事
最近有一个概念在 AI 开发圈很火，叫”上下文工程”（Context Engineering）。

听起来很高深，其实就是一件事：让 AI 在每次工作之前，先完整了解你的项目背景。

我用产品经理能理解的话来说——你在带一个新来的实习生。你不会每次交代任务都从头讲一遍”我们公司是做什么的、这个产品的目标用户是谁、这个功能的业务背景是什么”。你会给他一份项目 Brief，让他先看，看完再来接活。

上下文工程就是给 AI 写 Brief。

具体来说，产品经理需要维护三份文档：

第一份：产品背景文档。 一句话说清这是什么产品，给谁用，解决什么问题。核心业务流程是什么，有哪些关键角色，哪些事情绝对不能做。就像你给新同事发的项目背景邮件。

第二份：产品需求文档。 每个功能的详细描述——用户怎么操作，成功什么表现，失败什么提示，边界条件是什么。这就是 PRD，只不过以前写给开发看，现在写给 AI 看。

第三份：产品边界文档。 哪些功能做、哪些不做、优先级是什么。这就是产品经理最熟悉的功能范围定义，帮 AI 理解”什么该动、什么不该动”。



这三份文档写好之后，每次你跟 AI 开始新的对话，它先读这三份文档，然后对你的项目有了完整理解。这时候你再说”帮我做一个注册功能”，它就知道你的业务背景、你的用户画像、你的错误处理风格，出来的东西质量完全不一样。

有人可能会说，这也太麻烦了，我就想快速做个原型。

但你想想，你给老板提案之前，要不要先写个 Brief？你带团队做项目之前，要不要先把需求文档写清楚？这些事你本来就要做。只不过以前写完交给开发团队，现在写完交给 AI。

区别只有一个：给 AI 的文档必须更精确。因为开发同事看不懂会来问你，AI 不会。

PM 视角：上下文工程本质上就是产品经理的”项目管理能力”。你对项目理解越深、文档越清晰，AI 的产出质量就越高。这不是新技能，这是 PM 多年修炼的老技能——只是换了一个交付对象。
四、工程师做 VibeCoding vs PM 做 VibeCoding
这里有一个很有意思的对比。

我认识两个朋友，都在用 VibeCoding 做自己的副业产品。一个是后端工程师，做了十年技术；一个是产品经理，没写过代码。

工程师朋友跟 AI 的对话很高效，每次都说”帮我用某某技术方案实现数据隔离”或者”这个组件用服务端渲染，不要用客户端渲染”。AI 出来的东西技术上没问题。

但产品做出来之后，问题来了。

注册流程很顺畅，但他没想过用户注册之后应该看到什么——直接扔了一个空白仪表板，用户不知道该干什么。数据导出功能有，但他没想过导出的文件名应该包含日期和用户名——用户下载了十个文件，全是”export.csv”，根本分不清哪个是哪个。设置页面能改密码，但他没想过用户改完密码之后应该怎么处理——改完密码页面还是显示”已修改成功”，但用户不知道自己已经被登出了。

PM 朋友呢，技术细节一窍不通，但她的需求描述是这样的：

“用户注册成功后，第一次进入仪表板，应该看到一个欢迎引导，告诉用户接下来可以做什么。引导分三步：创建第一个项目、邀请一个成员、查看数据看板。每一步完成后打勾，三步全完成后引导消失。”

AI 出来的东西，功能完整，流程闭环，用户体验有始有终。

差别在哪里？工程师关注”这个功能怎么实现”，PM 关注”用户怎么用这个功能”。

AI 不缺实现能力，它缺的是”想清楚”。而”想清楚要做什么”，恰恰是产品经理每天在做的事。

PM 视角：VibeCoding 时代，”想清楚做什么”比”知道怎么做”更值钱。工程师的优势是能跟 AI 说清楚技术方案，PM 的优势是能跟 AI 说清楚产品方案。当 AI 的技术能力越来越强，”技术方案”这个环节会被 AI 自己搞定，而”产品方案”——也就是需求本身——会成为唯一的瓶颈。
五、五个阶段，产品经理闭着眼睛都能走


VibeCoding 的完整流程分五个阶段。我用产品经理的语言翻译一下：

第一阶段：定义。 你脑子里有一个模糊的想法——”我想做一个 XX”。这个阶段的任务是把模糊想法变成清晰的需求文档。你需要跟 AI 反复对话，让它追问你，直到把用户是谁、核心功能是什么、不做什么、边界在哪里全部确认清楚。这就是需求访谈，PM 天天在干——就像你做用户调研时，不断追问”为什么”直到挖到真实需求。

第二阶段：架构。 确定产品方案、搭建功能骨架、定义数据流转。听起来很技术，但本质就是信息架构设计——这个产品有哪些模块，数据怎么流转，哪些功能在前台、哪些在后台。PM 做竞品分析和功能拆解时，用的是同一套思维——就像你画产品结构图时，先确定有哪些模块，再确定模块之间的关系。

第三阶段：开发。 逐个功能实现。关键原则是：一次只做一个功能，做完验证再做下一个。如果一个任务 AI 花了超过 15 分钟还没完成，说明你给的需求太大了，需要拆。这就是敏捷迭代，PM 最熟悉的工作节奏——就像你做版本规划时，把大需求拆成小需求，一个迭代做一批。

第四阶段：调试。 产品出了问题，需要定位原因。关键不是让 AI 猜，而是给它完整的上下文——完整的报错信息、你做了什么操作、期望是什么、已经试过什么。这就是用户反馈分析，PM 每天都在处理——就像你处理客诉时，先问清楚”用户做了什么操作，期望什么结果，实际发生了什么”。

第五阶段：交付。 上线前的最终检查——安全检查、功能验收、发布流程。这就是发布清单，PM 每次发版都要过一遍——就像你做验收测试时，逐项检查功能是否符合 PRD 要求。

你发现了吗？这五个阶段，产品经理闭着眼睛都能走。区别只是以前你把需求交给开发团队，现在你把需求交给 AI。

PM 视角：VibeCoding 没有发明新流程。它只是把产品经理已经熟悉的开发流程，换了一个执行者。这意味着 PM 上手 VibeCoding 的学习成本极低——你已经有方法论了，只需要学会怎么跟 AI 对话。
六、一个被忽视的问题：AI 生成的东西安全吗？
这一点很多用 VibeCoding 的人完全没想过。

有一组数据：研究发现，AI 生成的代码中约 45% 存在安全漏洞。（来源：How Vibe Coding Works, VibeCoding.app, 2026）

这不是 AI 的错。AI 的目标是”让代码能跑”，不是”让代码安全”。你不说，它就不做。

最常见的问题是什么？用户数据泄露。

我那个用 AI 做 SaaS 的朋友，用户密码没有加密存储，直接存在数据库里。数据库一旦被攻破，所有用户的密码都暴露了。他完全不知道。

PM 不需要会写安全代码。但你需要知道什么时候该问一个问题：”这个安全吗？”

你不需要知道密码应该怎么加密存储，但你需要在需求里写一句”用户密码必须加密存储，禁止明文”。你不需要知道接口应该怎么鉴权，但你需要在需求里写一句”所有接口必须验证用户身份，未登录不能访问”。你不需要知道数据应该怎么隔离，但你需要知道”用户只能看到自己的数据，不能看到别人的数据”。

这些安全边界，写进需求文档里，AI 就会遵守。不写，AI 就不管。

PM 视角：不懂安全的 PM，上线后出了安全事故，背锅的是自己。你不需要成为安全专家，但你需要有一份”安全检查清单”，每次做需求的时候过一遍。清单包括：用户数据是否加密存储？接口是否有权限校验？敏感操作是否有二次确认？异常情况是否有兜底方案？这是 PM 的自我保护。
七、AI 是放大器，不是替代品


对产品经理而言，VibeCoding 这波浪潮表面上看是降低了做产品的门槛。

以前你不会写代码，就做不了产品。现在你不会写代码，用自然语言告诉 AI，它帮你做。门槛确实低了。

但门槛低了不意味着人人都能做出好东西。

AI 是一个放大器。你给它精确的需求，它放大你的效率——以前需要开发团队做两周的功能，你一个人用一下午搞定。你给它模糊的需求，它放大你的混乱——出来的东西到处是漏洞，改一个地方崩三个地方，最后推倒重来比从头做还慢。

差距不在工具。差距在于你给 AI 的输入质量。

而输入质量，取决于你能不能想清楚：这个产品给谁用、核心场景是什么、成功长什么样、失败怎么处理、边界在哪里。

这些能力，产品经理修炼了这么多年。

用户洞察，帮你定义”给谁用”。需求拆解，帮你定义”做什么”。边界思维，帮你定义”不做什么”。验收标准，帮你定义”做完长什么样”。

这些不是新技能。这些是 PM 的基本功。

但在 VibeCoding 时代，这些基本功第一次直接转化成了生产力——以前你写完 PRD 交给开发，中间还有一层沟通损耗；现在你写完需求描述交给 AI，5 分钟后就能看到可运行的产品。

PRD 的质量，直接决定了产出的质量。

所以我说，VibeCoding 浪潮下，产品经理最值钱的能力变了——不是会写代码，不是会用 AI 工具，而是你已经具备多年的能力：把模糊的想法变成精确的需求。

这个能力以前叫”写 PRD”。现在叫”跟 AI 对话”。本质是一样的。

AI 是乐器。需求描述能力是乐感。

有乐感的人拿到好乐器，能奏出好曲子。没有乐感的人拿到再好的乐器，也只是在弹一排音符。

产品经理这批人，乐感磨了这么多年。AI 把乐器变好了。对你们来说，这是好事。

本文由 @浩子 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自作者提供

--------------------------------------------------
本文转载自：https://www.woshipm.com/pmd/6387711.html