Vibe Coding 是什么:AI PM 该不该自己写代码
一句话解释
💤
Vibe Coding(氛围编程)
用自然语言向 AI 编程 Agent 描述你想要什么,让它生成、运行、修改代码,你全程不必读懂每一行,只需要判断"效果对不对"。
它把"写代码"从一门需要多年训练的手艺,变成了一种更接近"和一个懂技术的同事对话"的体验——这也是为什么 2025-2026 年,越来越多不会编程的产品经理开始亲手做出可运行的 Demo。
概念溯源:从一条推文说起
"Vibe Coding" 不是学术术语,也不是哪家公司的产品名,它出自 OpenAI 创始成员、特斯拉前 AI 总监 Andrej Karpathy 在 2025 年 2 月 2 日发的一条推文。原话是:
"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:你完全沉浸在氛围里,拥抱指数级进步,甚至忘记代码本身的存在。"
他在同一条推文里描述得更具体:看到报错就把错误信息直接粘贴给 AI,AI 改完基本不看 diff(代码差异)就接受,遇到问题也懒得深究原理,"我基本上就是看看东西、说说话、跑一跑、复制粘贴,大多数时候就是能用"。这是一种相当极端、近乎"完全放手"的工作方式,前提是像 Cursor Composer 配 Claude Sonnet 这类工具已经好到能撑起这种信任。
这条推文本人形容是"一时兴起随手发的",没想到精准踩中了当时很多人的共同体验,迅速破圈:Merriam-Webster 词典 2025 年 3 月就将其收录为"俚语与热词",Collins 英语词典更是把它评为 2025 年度词汇。
定义的分化:不是所有"用 AI 写代码"都叫 Vibe Coding
术语火了之后,用法很快就比 Karpathy 原意宽泛得多。开发者 Simon Willison 在 2025 年 3 月专门写文章做出区分:如果 AI 帮你写了每一行代码,但你审查过、测试过、真正理解了这些代码,那就不是 Vibe Coding,而是普通的"AI 辅助编程"——Vibe Coding 的核心特征恰恰是"不审查、不完全理解,只看结果"。吴恩达(Andrew Ng)也在 2025 年 6 月提出批评,认为这个词容易误导人,让大家以为专业工程师用 AI 工具时也是"跟着感觉走",但实际上专业场景里的 AI 辅助开发仍然包含大量审查和把控。
到 2025 年 7 月,《华尔街日报》报道称专业工程师也开始把 Vibe Coding 用于商业项目——这时词义已经从"周末个人小项目的一时兴起",扩展到覆盖企业级的 AI 辅助开发实践,原本"完全不看代码"的严格定义,在日常使用中被大大稀释了。
2026 年的演化:Karpathy 自己也换了说法
到 2026 年年初,Karpathy 本人认为随着模型能力跃升,"Vibe Coding"这个词已经不够用了,提出了新说法 "Agentic Engineering"(智能体化工程)。他的解释是:"agentic"是因为现在的默认模式不再是你亲自写代码,而是你在编排(orchestrate)多个 Agent 去写,自己负责监督;"engineering"则是强调这里面有章法、有专业性,不是纯粹跟着感觉走。他给出一句被广泛引用的总结:"Vibe Coding 抬高了下限,Agentic Engineering 保住了上限。" 换句话说,Vibe Coding 让完全不会编程的人也能做出东西(抬高下限),但要做出经得起推敲、能长期维护的系统,还是需要专业性和方法论(守住上限)。
对 AI PM 来说,这个演化路径本身就是重要信息:不要把 Vibe Coding 神化成"从此不需要理解技术",它的价值一直是"让你能更快地把想法变成看得见摸得着的东西",而不是替代工程判断力。
和其他三种"做 Demo"方式的区别
AI PM 想把一个想法变成可演示的东西,大致有四条路。它们不是互相排斥的关系,而是"投入门槛"和"最终掌控力"两个维度上的权衡:
#NNSppyagLoUN text { white-space: pre; }#NNSppyagLoUN .fb0 { stroke: var(--N900-FG, 0.15); }#NNSppyagLoUN .fb0 {stroke: rgba(31,35,41, 0.15)}#NNSppyagLoUN .fx0 { stroke-miterlimit: 10; }#NNSppyagLoUN .fx0 {stroke-miterlimit: 10}#NNSppyagLoUN .fa1 { fill: rgb(187, 191, 196); }#NNSppyagLoUN .fa1 {fill: rgb(187, 191, 196)}#NNSppyagLoUN .fx1 { font: 400 12px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#NNSppyagLoUN .fx1 {font-style: normal}#NNSppyagLoUN .fx2 { text-anchor: middle; }#NNSppyagLoUN .fx2 {text-anchor: middle}#NNSppyagLoUN .fx3 { dominant-baseline: central; }#NNSppyagLoUN .fx3 {dominant-baseline: central}#NNSppyagLoUN .fx4 { stroke: none; }#NNSppyagLoUN .fx4 {stroke: none}#NNSppyagLoUN .fc0 { fill: var(--text-caption); }#NNSppyagLoUN .fc0 {fill: #646a73}#NNSppyagLoUN .fa2 { fill: var(--text-link-disabled); }#NNSppyagLoUN .fa2 {fill: rgb(187, 191, 196)}#NNSppyagLoUN .fx5 { font: 400 16px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#NNSppyagLoUN .fx5 {font-style: normal}#NNSppyagLoUN .fx6 { text-anchor: start; }#NNSppyagLoUN .fx6 {text-anchor: start}#NNSppyagLoUN .fx7 { dominant-baseline: alphabetic; }#NNSppyagLoUN .fx7 {dominant-baseline: alphabetic}#NNSppyagLoUN .fc1 { fill: rgb(31, 35, 40); }#NNSppyagLoUN .fc1 {fill: rgb(31, 35, 40)}#NNSppyagLoUN .fb1 { fill: var(--N900-FG, 0.15); }#NNSppyagLoUN .fb1 {fill: rgba(31,35,41, 0.15)}#NNSppyagLoUN .fb2 { fill: rgb(209, 217, 224); }#NNSppyagLoUN .fb2 {fill: rgb(209, 217, 224)}#NNSppyagLoUN .fa3 { fill: var(--bg-body); }#NNSppyagLoUN .fa3 {fill: #fff}ABCDEF12345方式传统写代码低代码/无代码平台(如飞书低码、Bubble)找工程师做 DemoVibe Coding怎么做自己动手写、调试、部署拖拽组件、配置逻辑,平台内置模板把需求讲清楚,等排期,工程师实现用自然语言向 AI 编程 Agent 描述需求,AI 生成并运行代码,你验证效果、继续对话调整门槛高,需系统学习编程低,但受平台能力边界限制对 PM 本人门槛低低,但需要一点"看懂报错、判断对不对"的耐心产出物的可控性最高,想改哪里改哪里中等,超出平台预设能力就做不了取决于沟通质量和排期优先级较高,本质是真代码,能力上限取决于 AI 能力和你能读懂多少迭代速度慢,受个人熟练度限制快,但复杂逻辑会卡住慢,受协作成本和排期制约很快,当天甚至几十分钟出一版典型场景专业工程师做生产级系统内部工具、标准化流程表单需要严谨评审、正式立项后的开发PM 自己验证想法、做原型、面试作品集
Vibe Coding 相对于低代码平台的关键区别在于:低代码平台是"在别人画好的框里拼积木",逻辑边界被平台预设死了;Vibe Coding 生成的是真实代码,理论上没有平台能力上限,只是你未必看得懂全部细节。相对于"找工程师做 Demo",最大的区别是去掉了沟通成本和排期等待——你不需要先把想法讲清楚再等别人实现,而是自己先做出一版粗糙但可运行的东西,再拿着它去和工程师讨论,讨论效率完全不同。
对 AI PM 的价值:为什么这正在变成核心竞争力
验证想法的速度快了一个数量级
传统流程里,一个想法从"我觉得这个可行"到"有个东西可以点开看看",中间要经过写 PRD、评审、排期、开发、联调,少则几天多则几周。Vibe Coding 把这个链条压缩到几十分钟到几小时——你可以在提出想法的当天就做出一个能点、能交互的原型,哪怕只是前端界面加假数据。这不是要替代正式开发流程,而是在正式立项之前,用最低成本证伪或证实想法,把"拍脑袋讨论"变成"看着实际效果讨论"。
和工程师沟通的效率显著提高
当你自己动手搭过哪怕一个简陋的 Demo,你对"这个功能大概要改哪些模块""这个交互在技术上大概是什么代价"会有更具体的直觉,提需求时能少说很多空话,也更容易听懂工程师说"这个改动比看起来复杂"背后的原因。这不需要你达到工程师的水平,只需要你亲手踩过一次"从想法到能跑起来"中间的坑。
面试作品集的说服力完全不同
转型指南 里提到一个反复被验证的观察:"一个亲手做过的 RAG 小 demo、一份认真写过的评测集,远比罗列课程证书更有说服力。" 这个判断放在 Vibe Coding 上同样成立,甚至更适用——因为它的门槛比"手写 RAG 代码"更低,几乎任何一个愿意花时间的 PM 都能做出一个可以现场打开演示的东西。面试官见过太多"我熟悉 Prompt 工程""我了解 RAG 原理"这样的自我介绍,但一个能当场点开、能现场改一个参数演示效果变化的作品,分量完全不一样。
边界:Vibe Coding 不是让 PM 替代工程师
这是最容易被误解、也最需要讲清楚的一点。Vibe Coding 抬高的是"从 0 到能跑起来"的下限,不是让产品经理从此不需要工程师。以下这些工作,仍然清晰地属于专业工程师的范畴,PM 不应该、也没有能力越界:
#xqyDzTDTyNUd text { white-space: pre; }#xqyDzTDTyNUd .fb0 { stroke: var(--N900-FG, 0.15); }#xqyDzTDTyNUd .fb0 {stroke: rgba(31,35,41, 0.15)}#xqyDzTDTyNUd .fx0 { stroke-miterlimit: 10; }#xqyDzTDTyNUd .fx0 {stroke-miterlimit: 10}#xqyDzTDTyNUd .fa1 { fill: rgb(187, 191, 196); }#xqyDzTDTyNUd .fa1 {fill: rgb(187, 191, 196)}#xqyDzTDTyNUd .fx1 { font: 400 12px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#xqyDzTDTyNUd .fx1 {font-style: normal}#xqyDzTDTyNUd .fx2 { text-anchor: middle; }#xqyDzTDTyNUd .fx2 {text-anchor: middle}#xqyDzTDTyNUd .fx3 { dominant-baseline: central; }#xqyDzTDTyNUd .fx3 {dominant-baseline: central}#xqyDzTDTyNUd .fx4 { stroke: none; }#xqyDzTDTyNUd .fx4 {stroke: none}#xqyDzTDTyNUd .fc0 { fill: var(--text-caption); }#xqyDzTDTyNUd .fc0 {fill: #646a73}#xqyDzTDTyNUd .fa2 { fill: var(--text-link-disabled); }#xqyDzTDTyNUd .fa2 {fill: rgb(187, 191, 196)}#xqyDzTDTyNUd .fx5 { font: 400 16px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#xqyDzTDTyNUd .fx5 {font-style: normal}#xqyDzTDTyNUd .fx6 { text-anchor: start; }#xqyDzTDTyNUd .fx6 {text-anchor: start}#xqyDzTDTyNUd .fx7 { dominant-baseline: alphabetic; }#xqyDzTDTyNUd .fx7 {dominant-baseline: alphabetic}#xqyDzTDTyNUd .fc1 { fill: rgb(31, 35, 40); }#xqyDzTDTyNUd .fc1 {fill: rgb(31, 35, 40)}#xqyDzTDTyNUd .fb1 { fill: var(--N900-FG, 0.15); }#xqyDzTDTyNUd .fb1 {fill: rgba(31,35,41, 0.15)}#xqyDzTDTyNUd .fb2 { fill: rgb(209, 217, 224); }#xqyDzTDTyNUd .fb2 {fill: rgb(209, 217, 224)}#xqyDzTDTyNUd .fa3 { fill: var(--bg-body); }#xqyDzTDTyNUd .fa3 {fill: #fff}AB123456能做(PM 亲自上手合理)验证交互流程是否顺畅的原型用假数据/小数据集跑通一个核心逻辑面试作品集、内部提案的 Demo探索性质的技术方案可行性验证给工程师提供一个"具体一点的参考"而非最终方案不该做(仍需专业工程师)面向真实用户、需要承担流量的生产环境代码涉及真实用户数据的安全审查与合规处理需要长期维护、多人协作的代码库架构设计高并发、高可用场景下的系统设计与容灾未经审查就把 AI 生成代码直接合并到主干、上线给真实用户
一句话概括这条边界:Vibe Coding 出来的东西默认是"验证用的一次性原型",不是"可以直接上生产的工程资产"。就像 Karpathy 自己在原始定义里承认的,这种工作方式"基本不看 diff、不深究原理",这在探索阶段没问题,但恰恰是生产代码最忌讳的态度——安全漏洞、性能陷阱、技术债往往就藏在"没人仔细看过的那部分代码"里。AI PM 用 Vibe Coding 的目的,是让自己在"想法"和"工程实现"之间多一个可以亲手验证的中间地带,而不是把自己的角色变成半吊子工程师。
决策框架:我该不该自己动手写(氛围)代码?
面对一个新想法,可以按下面几个问题依次自查:
这个东西的目的是验证想法,还是要长期运行给真实用户用? 如果是前者,适合自己上手做;如果是后者,应该走正式开发流程,哪怕你已经做出了一版 Demo,也只能作为参考,不能直接当成交付物。
我需要多快看到结果? 如果答案是"今天下午的评审会就要用",找工程师排期基本来不及,这正是 Vibe Coding 最适合出场的场景。
这个想法有没有可能被现有工具(低代码平台、模板)十分钟解决? 如果有现成的低代码方案能满足,没必要额外学习编程式的工具——用最省力的方式达到目的。
我愿不愿意花时间去看懂报错信息、判断 AI 给出的方案是否合理? Vibe Coding 不要求你会写代码,但要求你有基本的耐心去判断"这个结果对不对""哪里看起来不对劲"。完全不愿意参与判断、只想当甩手掌柜,风险会明显升高。
做完之后,这个东西会不会被误当成"可以直接用的产品"? 如果团队里有人可能把你的原型代码直接部署上线,一定要提前说清楚这只是验证用的、未经审查的代码,避免安全和稳定性风险被忽视。
如果 5 个问题里,你的答案指向"验证性质、时间紧、没有现成工具、我愿意参与判断、团队清楚这只是原型",那就大胆动手;如果指向"要长期维护、涉及真实用户数据、没人愿意做后续代码审查",这时候该做的是把想法讲清楚,交给专业工程师来做,而不是勉强自己啃一个 Vibe Coding 搞不定的复杂系统。