AI产品经理的战场正在从会议室转向代码编辑器！当团队为‘用户打断AI语音’的交互细节吵到深夜时，有人用Cursor半小时做出可运行demo——这就是硅谷爆火的Vibe Coding革命。它不仅改变了PRD撰写方式，更让产品经理能亲手验证模型行为、快速迭代方案，甚至自建工具军团。本文将揭秘这种‘描述需求即生成代码’的新范式，如何重塑AI时代的产品开发逻辑与PM核心竞争力。

周五晚上，那场没有赢家的会

先讲一个我上个月真实经历的场景。

周五晚上，会议室里只剩下我、前端、算法三个。我们在为一个 AI 对话产品里”用户中途打断模型”的交互细节，已经吵了一个半小时。

我说：用户开口的瞬间就该把模型的语音停掉。 老李说：那 token 计费会有问题，模型还在生成。 前端说：前端拿不到那么实时的事件，得后端推过来。 我说：那别的产品都能做到啊，我用过 ChatGPT 的语音模式。 算法说：他们怎么实现的我也不知道，咱们这个架构跟人家不一样。

然后我们就这么僵在那里。我心里清楚，再吵下去也不会有结果——因为我说不出”具体应该怎么做”，他们说不出”为什么做不了”，我们三个都在用各自的语言系统互相发射雾炮弹。

那天晚上回家路上，我打开 Cursor，把那个交互需求用自然语言描述给它听，半小时后我手里多了一个粗糙但能跑起来的 demo——它不完美，但它清晰地告诉了我：这件事在前端可以怎么实现，需要后端给什么事件，token 计费的问题在哪一行代码里发生。

第二天早上的会，三十分钟结束。

这就是我想跟你聊的事——Vibe Coding，正在变成 AI 产品经理之间的新分水岭。

不是因为它让产品经理变成了工程师，而是因为它让产品经理变成了一个”能自己把脑子里的东西跑出来”的产品经理。这两件事的差距，比你想象的大得多。

一、先把”Vibe Coding”这个词说清楚，别让它变成又一个被滥用的概念

2025 年 2 月 2 日，前特斯拉 AI 总监、OpenAI 创始团队成员 Andrej Karpathy 发了一条推特，原话大致是：

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

（我把这种新的写代码方式叫”vibe coding”——你完全跟着感觉走，拥抱指数级，并且忘掉代码本身的存在。）

这条推文一夜之间在硅谷传爆了。各种媒体、播客、播客开始用这个词。一个新词流行起来当然有大半是热度炒作，但 vibe coding 之所以能站住脚，是因为它真的描述了一种新的工作方式：

你不再写代码。你描述你想要什么。AI 写代码。你看效果，再描述要改的地方。AI 改代码。直到它跑起来。

这听起来像不像产品经理在干的事？

是的，vibe coding 在本质上更像产品行为，而不是工程行为。它要求你能清楚地描述需求、能识别”对不对”、能在一堆候选方案里做选择——这些都是产品经理的看家本领。

让我把它跟容易混淆的几个东西区分开：

它不是“产品经理学点 Python 写脚本”。那是 2015 年的事。 它不是“用 ChatGPT 帮你写几行 SQL”。那是 2023 年的事。 它也不是“低代码平台拖拽搭一个表单”。那是企业 IT 的事。

它是：你坐下来，用一个像 Cursor、Claude Code、codex这样的 AI 编辑器，对它说”我要一个能让用户上传简历、然后用大模型抽取教育背景和工作经历，最后生成一个雷达图的页面”，然后它真的给你写出来一个能跑的东西。

跑起来之后你说”颜色太丑了，雷达图换成时间轴”，它继续改。 你说”这里加一个倒出 PDF 的按钮”，它继续改。 你说”我想接公司内部的人才库 API”，它问你要文档，你扔给它，它接上。

整个过程你可能没看一行代码，但你做出了一个能用的东西。

目前主流的 vibe coding 工具大致分两类：

第一类是”AI 编辑器”，更适合本地开发，偏给懂一点点技术的人——Cursor（最早爆火）、Claude Code（Anthropic 自家的 CLI）、Windsurf（被 Cognition 收购前是 Codeium 出的）、Cline 等。

第二类是”网页版生成器”，浏览器里就能用，给完全不懂代码的人也能上手——v0（Vercel 出的，专门给前端组件）、Bolt.new（StackBlitz 出的，能跑全栈）、Lovable（瑞典团队，主打从需求到 demo 极速）、Replit Agent。

这两类工具的体验都还在剧烈变化，但它们指向的方向是一致的：让”想清楚 + 描述清楚”这件事，直接产出能跑的产品。

二、为什么偏偏是 AI 产品经理，比所有其他 PM 都更需要这个能力

你可能会问：会写代码的产品经理一直都有，搜索、电商、社交领域那些大佬级 PM 不少都会写。为什么单独把 AI PM 拎出来说？

因为 AI 产品有三个跟传统产品根本性不同的特性，让”自己能跑出来一个东西”这件事，从加分项变成了必备项。

第一个特性：模型行为不可预测，PRD 写不清楚。

你做一个表单页，需求是确定的：用户输入什么、点哪个按钮、跳到哪一页。你画完原型图，工程师照着实现就完了。

但你做一个”AI 帮用户改简历”的功能呢？你写”模型应该让简历更专业”，怎么算专业？你写”输出不超过 500 字”，模型有 30% 概率输出 600 字怎么办？你写”语气友好但不肉麻”，”肉麻”的边界在哪儿？

这些问题，坐在工位上写文档的产品经理永远写不清楚，因为它们的答案藏在”模型实际跑一遍之后看到的东西里”。你不动手跑一遍，你的 PRD 就是猜出来的。

第二个特性：试错成本高，但试错次数得多。

AI 功能的效果好坏，常常取决于一些非常细的东西：prompt 怎么写、context 给多少、用哪个模型、温度调到多少、加不加思维链。这些东西你不在真实数据上跑，光靠想是想不明白的。

如果你每次试错都要排一个工程师的 sprint，一周才能拿到一个版本的结果，你这个产品三个月也迭代不出来。

如果你自己能跑，你今天下午想一个新 prompt，晚上就能在 50 条真实用户数据上看到结果，明天上午带着结论去找工程师讨论上线。你的迭代速度直接快一个数量级。

第三个特性：竞争窗口期短，慢半步就晚一年。

AI 这个赛道现在的节奏，2024 年初你看到一个机会，半年内必须有产品上线，否则就被别人占了位置。你想想那些去年到今年涌出来的 AI 工具——做翻译的、做配音的、做 PPT 的、做面试模拟的——哪个团队不是先跑出 demo 拿融资、再快速迭代上线的？

你的竞争对手可能是一个三个人的小团队，里面那个 PM 自己会用 Cursor 写前端，老板兼工程师晚上回家用 Claude Code 写后端，他们一周能上线一个新功能。你们公司 PRD 还在评审环节，他们都把第二轮用户反馈消化完了。

这三个特性叠加起来，意味着 AI PM 这个岗位，从底层逻辑上就不再是”动嘴的人”了。它要求你既能想清楚，又能跑出来。光想，跟不上节奏；光跑，跑出来的是错的东西。两个能力都得有。

三、会 Vibe Coding 的 AI PM，到底比不会的多了什么

下面这六个优势，是我自己在用 Cursor 和 Claude Code 这一年时间里，真切体会到的差别。我尽量不说虚的，每一条都给你具体场景。

优势一：写 PRD 之前能先”跑”一遍，文档质量直接换一个段位

过去我写一个 AI 功能的 PRD，大概要纠结这些事：

• 模型这个意图识别准不准？我写”识别用户的咨询意图”，但 80% 的准确率和 95% 的准确率，对应完全不同的产品形态。
• 这个交互到底顺不顺？我画的流程图里”用户输入 → 模型回复 → 用户追问”，但真跑一遍可能发现追问的时候上下文丢了。
• 这个边界情况怎么处理？用户上传一个 50MB 的 PDF，模型超时了，我们前端怎么显示？

过去这些问题我只能写”待评审”或者”开发后再定”，然后开发同学拿到 PRD 就开始骂街——因为我把所有不确定的事情都甩给了他们。

会 vibe coding 之后，我写 PRD 之前先花两小时跑一个粗糙原型。这两小时换来的东西是：

• 我亲眼看到模型在 30 条真实用例上的准确率大概是个什么水平，PRD 里直接写”目标准确率 90%，当前基线 73%，需要在 prompt 工程或 fine-tune 上投入”。
• 我亲手把交互走了一遍，发现追问场景下需要把前一轮的输入也带上，PRD 里直接画清楚 context 怎么拼。
• 我跑出来 50MB PDF 的报错，PRD 里直接写”文件大小限制 20MB，超出时提示文案是 XXX”。

PRD 从一份”提问清单”，变成了一份”答案清单”。评审从两小时变成四十分钟。

优势二：跟工程师讨论的时候，你有底气，他们也省心

我以前最怕跟资深工程师讨论方案。不是怕他们刁难我，是怕他们随口一句”这个做不了”或者”这个要做半个月”，我没办法判断对错。

不会写代码的 PM 在这种场合通常有两种应对：一种是”那我去问问别人”——把球踢给上级或者另一个工程师，但你的专业感就掉了。另一种是”那好吧”——直接接受工程师的判断，但万一他是错的，整个产品节奏就被拖了。

会 vibe coding 之后，你有了第三种选择：自己回去跑一遍，看到底是不是真的做不了。

我前阵子提了一个需求：”让模型在生成长文档的时候，能流式输出，并且支持用户中途打断重新生成。”我们的工程师说这个要重构整个流式管道，至少两周。

我没当场反驳，回去用 Claude Code 在一个 demo 仓库里把这个功能糙糙地写了出来——不是产品级，但跑起来了。第二天我把那个仓库甩给工程师，说”这个是我跑通的版本，你看看跟我们现有的代码合并起来需要改哪些地方”。

工程师看完之后改口说”五天能做”。

这件事不是为了证明工程师在偷懒——他没偷懒，他只是在他熟悉的复杂架构里看到了风险。但当你能给他一个”已经在简化场景里跑通的参考”，他对工作量的估计会立刻变得准确，因为他看到的不是一个抽象需求，而是一个具体实现。

这种沟通效率的提升，是双向的。工程师也喜欢跟会跑代码的 PM 合作，因为他不用每次都从”什么是 token”开始解释。

优势三：做完用户访谈，当场给一个原型，用户惊掉下巴

这一条是我最喜欢的。

传统的用户调研流程是：访谈→写报告→开内部会→改 PRD→排开发→等 demo→再约用户验证。一个循环下来三周起步。

会 vibe coding 的 PM 可以这么干：上午跟 5 个目标用户访谈，下午用 Bolt 或者 Lovable 把核心交互糙糙地搭一个前端原型出来——不需要后端，前端用 mock 数据先跑通。第二天下午再约其中两个用户，把原型给他们试。

你不需要等 sprint，不需要排开发。你的”假设→验证”周期从三周缩到两天。

更重要的是，用户面对一个能点击的东西的时候，给出的反馈跟看一张图的时候完全不一样。你画 Figma 原型他说”挺好的看着挺顺的”，你给他一个能跑的 demo 他立刻说”这个按钮怎么藏这么深啊我找了半天”。

这种反馈是金子。你在 PRD 进入开发之前就拿到，意味着你减少了 80% 的返工。

优势四：自己搭内部工具，不再求人也不再等

AI 产品经理日常工作里，有一大半时间是在跟”数据”打交道：标注数据、看 case、做评测、查 bad case、统计分布……

每一项工作如果你都得求工程师或者数据团队帮你搭工具，你就永远是个二等公民。会 vibe coding 的 PM 自己搭。

我现在自己搭过的内部工具至少有这些：

• 一个 case 标注页面：把线上 bad case 拉出来，团队成员可以打标签、写评论、按维度筛选。
• 一个 prompt 对比测试器：左边输入 prompt A，右边输入 prompt B，跑同一批数据看输出差异。
• 一个用户反馈聚合面板：把 App Store、客服工单、问卷里的反馈喂给模型，自动按主题归类。
• 一个竞品监控小机器人：每天爬几个竞品的更新日志和社交媒体，模型生成摘要发到我自己的飞书群。

这些工具如果走正规开发流程，每个都得排两周以上，而且工程团队凭什么优先你的”个人工具需求”？

我自己搭，每个工具最多一两个晚上。糙是糙了点，但够用。够用就够了，因为它们的目标用户只有我自己和团队里几个人，不需要做得像 ToB 产品那么扎实。

这件事的复利效应特别夸张。一年下来你比同事多了十几个工具，你工作效率上的差距已经不是 vibe coding 本身，而是你有一支自己的”小型工具军团”。

优势五：评估第三方技术方案，不再被”听起来很厉害”忽悠

AI 这个领域，每个月都有新模型、新框架、新 API、新 agent 平台。供应商们排着队来 BD，每一家都说自己”准确率 95%”、”业内领先”、”独家技术”。

不会动手的 PM，只能听他们演示，看他们提供的 cherry-picked demo，然后凭感觉做选型。

会 vibe coding 的 PM 直接打开他们的 API 文档，半小时写一个测试脚本，把自己业务的 100 条真实样本喂进去，跑出真实准确率。再花半小时把第二家的 API 也接上，对比。

这个动作能帮你避免的坑，多到你不敢相信。我经历过一次：某家供应商演示的时候模型表现非常好，签合同前我自己跑了一遍发现在我们的中文金融场景里准确率只有 60%。这个差距足够我们换掉一家供应商，省下几十万的年费。

当你能”动手验证”的时候，你不再是被推销的那个人，你是来做评测的。

优势六：招聘和管人的判断力升级，知道工程师在干什么

最后一条不那么直接，但越往高层走越重要。

AI 产品经理做到一定阶段，要带团队。你要面试工程师，要给绩效，要决定谁负责哪个项目，要判断技术方案的优劣。

不会动手的 PM 在这个层面会越来越虚——你听工程师说他这周做了”模型量化加速”，你不知道这是 30 分钟的工作量还是 3 周的工作量。你听候选人说他熟悉”RAG”，你不知道他是真的搭过还是只读过文章。

会 vibe coding 的 PM 不一定要懂得跟工程师一样深，但你能做到不被忽悠。你自己跑过简单的 RAG，你就知道哪些点是真的难、哪些点是公开教程能照抄的。你自己接过 LLM API，你就知道一个迭代任务大概多久能完成。

这种判断力是当 leader 必须的。它跟你能不能写产品级代码没关系，跟你有没有亲手摸过这些东西有关系。

四、泼一盆冷水：Vibe Coding 不是万能药，这几个坑你必须知道

我前面把 vibe coding 夸得很厉害，但我对它的局限也得说清楚。否则你看完这篇文章冲出去信心爆棚，反而会摔得很惨。

第一坑：能跑通的 demo 不等于能上线的产品。

vibe coding 出来的代码，质量普遍是不达标的。安全漏洞、性能瓶颈、边界情况处理、并发、数据持久化、监控告警……这些东西没有专业工程师把关，会出大事。

我自己有过一次，搭的内部工具被同事用得多了，有人意外把生产数据库连进去了，差点出事故。这种事情专业工程师在 code review 里第一时间就会拦下，但 vibe coding 不会。

所以你的产出物有它的位置：原型、demo、内部工具、PoC、评测脚本、个人小工具——这些是 vibe coding 的主战场。面向真实用户的产品级代码，依然要交给工程团队，他们会推翻重写，这是合理的。

第二坑：你会有一种”我无所不能”的错觉。

刚开始用 Cursor 那段时间，我经常觉得自己能搞定一切——你让我做一个推荐系统？我能做。你让我做一个支付网关？我能做。

直到有一次我真的去搭了一个简化版支付流程，跑通了之后兴致勃勃拿给一个支付团队的朋友看，他扫了五分钟告诉我里面有 7 个安全漏洞，其中两个能直接被 SQL 注入掏空数据库。

vibe coding 让”看起来能跑”变得很容易，但”看起来能跑”和”真的能跑”中间隔着工程素养、安全意识、对业务边界的理解。这些东西它给不了你。

第三坑：你会忘记跟工程师好好沟通。

会跑代码之后，我有一阵子甚至开始绕过工程师——”反正我自己能搞，我先把东西做出来再说。”

这是错的。**你的角色不是替代工程师，而是更好地跟工程师协作。**你写的代码再好，也是个原型，最终能进生产环境的还是工程团队写的代码。如果你跟他们关系搞僵了，你做再多 demo 也没用。

正确的姿势是：你自己跑通了，把它当作沟通的素材，而不是”我已经做完了你们抄一下就行”的成品。

第四坑：你以为你懂技术了。

你不懂。你只是会用一个非常聪明的 AI 帮你写代码而已。

真正的技术理解需要你能自己 debug、能从一个 stack trace 看出问题在哪、能在不同的架构方案之间做权衡、能预判系统在什么负载下会崩。这些 vibe coding 给不了你，需要你长期一行一行写代码、一次一次踩坑才能积累出来。

所以请保持谦卑。你只是多了一项能力，不是变成了另一个职业。

五、方法论：30 天，从零到能在工作里真用上 Vibe Coding

讲了这么多，最后给一套能直接照着做的方法。

起步阶段：Day 1 ~ Day 7，把工具跑通

Day 1：选一个工具，注册，跑通第一个例子。

如果你完全不会写代码，建议从 Lovable 或 Bolt.new 开始，浏览器里直接用，没有任何环境配置成本。 如果你会一点点（比如装过 Python、用过 git），上 Cursor 或 Claude Code，能力上限更高，更适合长期。

第一天的目标只有一个：让任意一个工具跑出一个 Hello World 级别的网页。一个能显示”你好”的页面就够了。重点是把账号、订阅、环境配置这些破事一次性解决掉。

Day 2 ~ Day 3：跑通一个”真实但简化”的小项目。

不要从你公司的产品入手。选一个你个人感兴趣的小东西。比如：

• 一个能查你所在城市未来三天天气的页面（练 API 调用）
• 一个把你扔进去的英文文章总结成中文的小工具（练 LLM 调用）
• 一个把你列的待办清单按优先级排序的页面（练前端交互）

每个项目两到三个晚上能跑通。这一步是建立信心，让你相信”我也能做出能跑的东西”。

Day 4 ~ Day 7：刻意练习”如何描述需求”。

vibe coding 玩得好不好，70% 取决于你描述需求的能力。同一个工具，A 用的人三句话说清楚，B 用的人五十句话还说不清楚——结果天差地别。

这一周每天花一小时，练习把一个需求拆成 AI 能听懂的话。心法是：

• 先说整体：”我要做一个 X，给 Y 用”
• 再说输入和输出：”用户输入 A，得到 B”
• 然后说关键约束：”必须支持 Z，不要包含 W”
• 最后说长什么样：”风格类似 Notion，颜色用浅色”

写得好的需求描述本身就是好 PRD。这个能力是 vibe coding 给你的副产品，也是最值钱的副产品之一。

进阶阶段：Day 8 ~ Day 21，开始用在工作上

Day 8 ~ Day 14：用 Vibe Coding 重做你最近的一个 PRD。

挑一个你最近写过的、已经评审过或者已经开发完的功能。不要挑没做过的，因为你需要一个对照。

把这个功能用 vibe coding 重新做一遍只跑通核心交互的版本。比如你之前写过一个”AI 简历优化”的 PRD，那就做一个能让用户上传简历、调用模型、输出优化建议的最小版本。

做完之后做两件事：

第一，对照你之前的 PRD，看哪些地方”如果当时跑过这个 demo，我会写得不一样”。把这些点列下来。这就是 vibe coding 给你的直接红利。

第二，把这个 demo 给当时一起做这个功能的工程师看一眼，问他：”如果当时我给你这个，我们会节省多少时间？”

听他的回答。这个回答会决定你接下来用不用得动力继续投入。

Day 15 ~ Day 21：搭一个内部工具给团队用。

挑一个你团队里大家都觉得”很烦但没人有空做”的小事。比如：

• 每周拉一遍线上 bad case 然后分类
• 把客服反馈分主题汇总
• 跟踪几个竞品的更新

用 vibe coding 把这件事自动化或工具化，发给团队。不要追求完美，糙一点没关系，有用就行。

这一步的目的是让你建立”我自己搭的工具能解决真实问题”的实感，并且让团队看到你这个能力。这两个心理收益都非常重要。

实战阶段：Day 22 ~ Day 30，在真实项目里用一次

挑一个你下个 sprint 要主导的功能，从头到尾用上 vibe coding：

• PRD 之前：跑一个粗糙原型，验证可行性，再决定 PRD 怎么写。
• PRD 评审：在评审会上用你的原型 demo 来说明关键交互。
• 开发期间：自己接着原型迭代，用来跟工程师同步细节。
• 测试阶段：用 vibe coding 写一些自动化测试脚本或者 case 评估工具。
• 上线之后：搭一个监控看板看核心指标。

跑完一个完整 sprint 之后，你已经把这个能力嵌进自己的工作流了。它不再是”额外学的东西”，而是”我做产品的一部分”。

长期心法：三句话，记住就行

走到这里你已经入门了，剩下的是长期心法。我自己总结的三句话：

第一句：能描述清楚的人，才能驾驭 AI。

不管工具怎么进化，”清楚地说出我要什么”这件事永远是你的核心竞争力。每写一段 prompt 都是在练这个肌肉。

第二句：跑通是起点，不是终点。

跑通一个 demo 只是入场券。真正的产品能力体现在你跑通之后，能不能判断它好不好、能不能想清楚怎么改、能不能跟工程师讲明白怎么做生产级的版本。

第三句：不要假装自己是工程师。

你是产品经理。你的舞台在更靠前的位置——理解用户、定义价值、推动落地。vibe coding 是你的新工具，不是你的新身份。

结尾：时代变了，护城河也变了

我是 2014 年开始做产品经理的。十二年里，”什么样的 PM 值钱”这个标准变过好几次。

最早是会写 PRD 的，因为那时候大部分人写得稀烂。后来是懂数据的，会跑 SQL 拉数据的 PM 比纯靠拍脑袋的吃香。再后来是有商业思维的，能把功能跟收入挂上钩的人晋升更快。

现在轮到了 vibe coding。

我不是说不会 vibe coding 的 PM 会立刻被淘汰——大部分公司里大部分项目，传统 PM 的工作方式还能用上几年。但你看那些发展最快的 AI 公司、那些三个月就能从 0 到 100 万用户的产品，里面的产品经理几乎清一色都已经在自己跑代码了。

这就是”护城河”四个字真正的意思。它不是说你不会某个能力你就活不下去，而是当下一波机会到来的时候，你抓不抓得住，取决于你今天有没有在准备。

vibe coding 这个能力，门槛不高，但需要你今天就开始练。明天的你，会感谢今晚下载 Cursor 的你。

晚安，加油，去跑你的第一个 demo 吧。

作者注：文中提到的 Andrej Karpathy 关于 vibe coding 的推文发于 2025 年 2 月 2 日，原文链接读者可在他的推特账号 @karpathy 历史推文中查询；提到的 Cursor、Claude Code、Windsurf、v0、Bolt.new、Lovable、Replit Agent 均为公开可访问的产品。文中”周五晚上的会”等具体场景为作者本人经历改编，不代表特定公司或团队。