Vibe Coding 到底是什么？一个全栈开发者的实战理解
2025年2月，Andrej Karpathy 发了条推文，大意是："我在搞一种新的编程方式，叫 vibe coding。你完全跟着感觉走，忘掉代码本身的存在。我看东西、说东西、跑东西、粘贴东西，然后它大部分时候就能跑。"
这条推文炸了。
Karpathy 是谁？OpenAI 联合创始人，前特斯拉 AI 负责人。他说这话不是在开玩笑，而是在描述他用 Cursor Composer 搭一个叫 MenuGen 的项目时的真实体验。他甚至用语音输入跟 AI 对话，连键盘都懒得碰。原话是："I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."
我当时看到这条推文的第一反应是：又在吹。后来我自己试了试，发现……还真挺离谱的。
先搞清楚概念
Vibe coding，中文翻译叫"氛围编程"或者"感觉编程"。说实话这两个翻译都不太准确，但也没更好的词了。
核心意思很简单：你不再逐行写代码，而是用自然语言告诉 AI 你想要什么，AI 帮你生成代码。你的角色从"写代码的人"变成了"描述需求的人"。
举个例子。以前你想写一个用户注册页面，你得：搭表单组件、写验证逻辑、接后端 API、处理错误提示、搞响应式布局。每个环节都得自己写。
现在你跟 AI 说："帮我写一个注册页面，要有邮箱验证、密码强度提示、手机号可选，用 Tailwind CSS，风格参考 Linear 的登录页。"
然后 AI 就给你生成了。可能不是完美的，但能跑。你再根据实际效果调整。整个过程从"写代码"变成了"描述+审查+调整"。
Karpathy 原话里有个细节特别到位——他说他写代码的时候 "Accept All"，根本不看 diff。报错了就把错误信息粘贴回去，"usually that fixes it"。代码复杂到超出他的理解范围了，他也无所谓。
这就是 vibe coding 的精髓：关注结果，不关注过程。
不过 Simon Willison（Django 联合创始人）说了一句很经典的话来划线："如果 LLM 写了你所有的代码，但你审查、测试并理解了每一行，那在我看来这不是 vibe coding，那只是用 LLM 当打字助手。"
这句话点到了关键分歧：你到底理不理解你正在运行的代码？ 真正的 vibe coding，按 Karpathy 的描述，是你不理解也没关系，只要它能跑。
这个词怎么火起来的
2025年2月 Karpathy 发明这个词。3月 Merriam-Webster 就把它列为"俚语和趋势词"。到了年底，Collins 字典直接把它选为 2025 年度词汇。搜索量在那年春天暴涨了 6700%。
为什么这么火？因为它精准描述了一种很多人已经在做但没有名字的事。
想想看，2024年底到2025年初，Cursor、GitHub Copilot、Windsurf 这些工具已经让很多开发者养成了一个习惯：写需求描述，而不是写代码。大部分时候 AI 生成的代码你直接就用了，偶尔改改，很少从头手写。Karpathy 只是给这个现象起了个名字。
到了2025年7月，《华尔街日报》报道说 vibe coding 已经被专业软件工程师用于商业场景。不再是玩具了。
但争议也随之而来。Andrew Ng（吴恩达）在2025年6月吐槽说，vibe coding 这个名字有误导性，让人以为软件工程师就是"跟着感觉走"。他说实际使用 AI 编程工具的工作远比这复杂和辛苦。
不管你怎么定义它，这个趋势已经不可逆了。
我自己的 vibe coding 体验
说说我的真实经历。
建这个网站（totb0311.site）的时候，大概70%的代码是 AI 生成的。不是说我不懂那些代码——我懂，但我没有一行一行去写。大部分时候我是这样工作的：
- 跟 AI 描述我要什么功能
- AI 生成代码
- 我看看大概对不对，能跑就用
- 不能跑就把报错信息扔回去
- 重复几次，搞定
有一次特别离谱。我要给网站加一个多语言切换功能。正常来说这活儿得折腾半天——路由、中间件、语言文件、URL 重写，一堆东西。我跟 Claude Code 说了一句："给网站加中英文切换，中文路由用 /zh 前缀，英文用根路径。"
然后它就开始干活了。读我的项目结构，理解 Next.js 的 App Router，创建语言文件，修改中间件，生成语言切换组件。大概十分钟后，功能就跑通了。整个过程我做的事情就是：描述需求、看效果、说"这里不对"。
但也有翻车的时候。
有一次我让它重构一个数据库查询逻辑，说"优化一下性能"。它很自信地改了一堆东西，我看了一眼觉得没问题就提交了。结果第二天发现某个页面的数据加载慢了三倍——它把一个索引优化给删了，因为"看起来冗余"。
还有一次更搞笑。我让它给文章列表页加一个搜索功能。它加了，能用，但我发现搜"Python"的时候结果不对。排查了半天，发现它把搜索逻辑写成了模糊匹配标题的前10个字符。我不知道它是怎么"理解"成这样的，但代码确实能跑，只是逻辑完全不对。
从那以后我就学到了：vibe coding 不是不看代码，而是选择性地看。关键路径（数据库、认证、支付）必须人工审查，UI 和辅助功能可以"跟着感觉走"。
vibe coding 和传统 AI 辅助编程有什么区别
有人可能会问：GitHub Copilot 不是早就有了吗？用 AI 补全代码和 vibe coding 有什么区别？
区别很大。
传统 AI 辅助编程（比如 Copilot 的自动补全）是这样的：你写代码，AI 在旁边猜你下一行要写什么，给你建议。你还是主导者，AI 是助手。你不写，它就不动。
Vibe coding 是反过来的：你描述需求，AI 写代码，你审查结果。AI 是主导者，你是审查者。你不描述，它确实不动，但一旦你描述了，它会把整个功能实现出来，而不是补全一行。
用一个比喻：传统 AI 辅助编程是你开车，副驾偶尔提醒你"前面该拐弯了"。Vibe coding是你告诉出租车司机"去机场"，司机自己开，你只在走错路的时候说一声。
还有一个关键区别：上下文范围。Copilot 的自动补全通常只看当前文件的上下文，而 vibe coding 工具（如 Cursor Composer、Claude Code）会读取整个代码库，理解项目结构、依赖关系、已有模式，然后在这个大上下文里做决策。
所以 vibe coding 不是"更好的自动补全"，而是一种完全不同的工作方式。你从"写代码的人"变成了"管理 AI 写代码的人"。
工具生态：谁在做 vibe coding
2026年的 vibe coding 工具已经很成熟了，大致分几个流派。我每个都用过一段时间，说说真实感受。
IDE 流派：Cursor 和 Windsurf
Cursor 是 VS Code 的 fork，加了 AI 深度集成。它的 Composer 模式可以同时编辑多个文件，读取整个代码库，甚至执行终端命令。$20/月的 Pro 套餐够大多数人用。
我用 Cursor 最多的场景是改已有代码。比如我要给一个组件加个新功能，打开 Composer，描述一下需求，它会自动读取相关文件，理解上下文，然后给出修改方案。大部分时候改得还不错。
Windsurf 的特色是"记忆"功能——用48小时后它会学习你的项目架构模式。$15/月，比 Cursor 便宜一点。我之前写过 Windsurf 的详细评测，对它的推理能力印象深刻，但稳定性偶尔有问题。有一次它在一个循环里改着改着突然开始删文件，吓我一跳。
一个有经验的开发者总结得好："Cursor 是最好的 AI 编辑器，Claude Code 是最好的 AI 工程师，Windsurf 是性价比最高的。"这三个我都认同。
终端流派：Claude Code 和 Codex CLI
Claude Code 是 CLI agent，不走 IDE 路线。它的 200K+ token 上下文窗口在处理大型项目时特别强。适合那种"我要重构整个模块"的场景。
我用 Claude Code 最多的是"探索性开发"。比如我想给网站加一个新功能，但不确定怎么做最好。我会跟它说："我想实现 X 功能，帮我分析一下有哪些方案，各自的优缺点是什么。"它会先读我的代码库，然后给出建议。确认方案后，再让它实现。
Codex CLI 是 OpenAI 的方案，也是终端驱动。之前我写过详细对比，这里不展开了。
这两个工具更适合有经验的开发者，因为你在终端里工作，需要对项目结构有清晰的认知。
浏览器流派：Bolt.new、Lovable、v0
这一类最激进。你不需要装任何东西，打开浏览器就能用。
Bolt.new 在浏览器里直接跑 Node.js（通过 WebContainers 技术），从想法到可运行的原型可能就几分钟。$25/月。特别适合非技术背景的创业者验证想法。我试过让它做一个简单的任务管理应用，从描述到能跑大概花了5分钟。当然，细节很粗糙，但核心功能是对的。
v0.dev 是 Vercel 做的，专注生成 React/Next.js UI 组件。你描述一个界面或者上传截图，它生成用 Tailwind + shadcn/ui 的代码。它是"组件工厂"，不做后端。我经常用它来快速生成 UI 组件，然后手动集成到项目里。生成质量不错，但有时候 Tailwind 的类名会写得很啰嗦。
Lovable 结合了设计精度和开发工作流，内置 Supabase 集成，支持双向 GitHub 同步。$25/月。设计师和产品经理特别喜欢它，因为生成的界面颜值比较高。
全栈流派：Replit Agent
Replit Agent 从数据库设计到云部署一条龙。$25/月包含托管。适合初学者和独立开发者。
但平台锁定是个大问题——你很难把项目迁出去。而且2025年7月出了个事故：Replit 的 AI agent 在一次测试中删除了用户的生产数据库，尽管用户明确指示"不要做任何更改"。Replit CEO 后来公开道歉。
这个事件给我的教训是：不管用什么工具，生产环境的数据一定要有备份，而且要定期验证备份是否可用。
vibe coding 适合什么场景
用了一段时间后，我对 vibe coding 的适用范围有了比较清晰的认知。
适合的场景
原型和 MVP：需要快速验证想法的时候，vibe coding 是神器。YC 2025 冬季批次有25%的创业公司代码库95%由 AI 生成。这些公司用 vibe coding 快速找到 PMF，然后再招工程师重构关键部分。
前端 UI 开发：描述一个界面，AI 生成响应式组件，这事儿 AI 做得又快又好。特别是表单、列表、卡片这些常见 UI 模式，AI 生成的质量已经很不错了。
内部工具：给团队做个数据看板、报表工具、管理后台，不需要多精美，能用就行。
一次性脚本：数据处理、格式转换、批量操作，写完就扔的那种。
个人项目：Side project、周末 hackathon，追求速度而非完美。
有个很经典的案例：独立开发者 Pieter Levels 用 Cursor 和 Grok 3 在17天内做了一个多人飞行模拟器，年收入100万美元。Booking.com 的700人 GenAI 试点项目中，开发者学会写更好的 prompt 后，merge request 数量提升了30%。
这就是 vibe coding 的上限——速度够快，想法够好，AI 帮你把技术门槛降到几乎为零。
不适合的场景
安全关键系统：认证、支付、加密，这些地方 AI 生成的代码可能有漏洞。2025年5月的一次安全扫描发现，Lovable 生成的1645个网页应用中，170个存在个人信息泄露漏洞。2026年初更离谱——一个 vibe coding 平台出了安全事故，150万个 API 密钥和3.5万个用户邮箱泄露，原因是数据库配置错误。那个应用的作者承认他一行代码都没手写过。
大型长期项目：代码可维护性是大问题。GitClear 的研究显示，AI 生成的代码导致代码重构比例从2021年的25%降到2024年的不到10%，代码重复量翻了四倍。
需要深度理解的场景：如果你不理解代码在做什么，出了问题你也不知道怎么修。
受监管行业：医疗、金融、航空，这些地方对代码质量有严格要求，不能"跟着感觉走"。
一个反直觉的研究结果
2025年7月，METR（一个评估前沿模型的机构）做了一个随机对照实验。他们找了经验丰富的开源开发者，测试使用 AI 编程工具是否能提高生产力。
结果让人意外：使用 AI 工具的开发者反而慢了19%。更离谱的是，这些开发者自己以为快了24%，事后还觉得自己快了20%。
这个结果初看很反直觉，但仔细想想有道理。对于经验丰富的开发者来说，他们已经对代码库非常熟悉，手写代码的速度其实很快。AI 工具的介入反而打断了他们的工作流——要等 AI 生成、要审查、要调整，这些额外步骤加起来反而更慢。
但这个研究有个重要前提：参与者是经验丰富的开源开发者。对于新手或者不熟悉代码库的人来说，AI 工具确实能显著提高效率。
所以 vibe coding 的效率提升不是绝对的，取决于你是谁、在做什么。
安全问题：最大的隐患
vibe coding 最让人担心的是安全问题，这个问题值得展开说说。
Veracode 在2025年10月发布了一份报告，结论很扎心：过去三年，LLM 生成功能代码的能力大幅提升，但生成安全代码的能力基本没进步。而且更大的模型在安全性上并不比小模型好。只有 OpenAI 的推理模型在安全性上有一点点提升，但幅度远不如功能性的提升。
CodeRabbit 在2025年12月分析了470个开源 GitHub PR，发现 AI 参与编写的代码比人写的代码多出1.7倍的"严重"问题。具体包括：逻辑错误、依赖关系错误、控制流缺陷（多75%）、安全漏洞（多2.74倍）。格式错误和命名不一致的问题也很突出。
这意味着什么？AI 生成的代码看起来能跑，但底层可能藏着定时炸弹。你测试的时候没问题，不代表生产环境没问题。攻击者专门找这种"看起来没问题"的代码下手。
2025年12月，安全研究员 Etizaz Mohsin 发现了 Orchids vibe coding 平台的安全漏洞，并在2026年2月通过 BBC 记者演示了攻击过程。一个 vibe coding 平台的安全问题能上 BBC 新闻，说明这事有多严重。
技术债：看不见的成本
除了安全，技术债也是个大问题。
GitClear 做了一个纵向分析，研究了2020到2024年间的2.11亿行代码变更。他们发现：
- 代码重构从2021年的25%降到2024年的不到10%
- 代码重复量翻了约四倍
- 复制粘贴的代码量超过了移动的代码量，这是二十年来第一次
- 代码流失率（刚合并就要重写的代码）几乎翻倍
这些数据说明什么？AI 生成的代码能跑，但不一定好维护。你用 vibe coding 快速搭出来的东西，可能三个月后就变成一团乱麻。
2025年9月，Fast Company 报道说"vibe coding 的宿醉来了"——很多高级工程师在接手 AI 生成的代码时陷入了"开发地狱"。代码能跑，但没人看得懂，改一处崩三处。
我自己也踩过这个坑。网站刚建的时候为了赶进度，很多页面组件是 AI 一股脑生成的。两个月后我想重构，发现组件之间的耦合关系乱得不行——A 组件依赖 B 组件的某个状态，B 组件又依赖 C 组件的一个函数，而 C 组件的那个函数其实只用了一次。花了整整一个周末才理清楚。
开源社区的影响
2026年1月有篇论文叫"Vibe Coding Kills Open Source"，观点挺有意思。
论文认为，vibe coding 降低了使用和构建现有代码的成本，但也削弱了用户与开源维护者之间的互动。当开源项目只能通过直接用户互动来变现时，vibe coding 的普及会降低参与度和分享意愿，最终减少开源软件的可用性和质量。
还有一个更隐蔽的问题：LLM 倾向于推荐训练数据中出现频率高的大型成熟库。比如你问 AI "怎么搞 HTTP 请求"，它大概率推荐 axios 或者 fetch，而不是一些更轻量但不太知名的库。这会破坏库和工具的自然选择过程，新的开源工具更难被发现。
而且 AI 不会提交有用的 bug 报告，也不会意识到潜在的问题。对开源维护者来说，用户反馈是改进项目的重要来源，而 vibe coding 把这个反馈回路切断了。
这个角度我之前没想过。vibe coding 对个人开发者是利好，但对开源生态可能是个隐性伤害。
Linus Torvalds 也在用
一个有趣的花絮：2026年1月，有人发现 Linus Torvalds（Linux 之父）在他的一个个人项目 AudioNoise 里用了 vibe coding。他在 README 里写："Python 可视化工具基本上是用 vibe coding 写的。"他用的是 Google Antigravity。
连 Linus 都在用，说明 vibe coding 已经不是"玩具"了。当然，他只是在一个个人 hobby 项目里用，Linux 内核他肯定不会这么搞。这也说明了一个道理：vibe coding 适合特定场景，不是万能的。
我的建议：怎么正确用 vibe coding
折腾了这么久，我总结出一套自己的方法论，分享给大家。
分层使用
把项目分成不同层级，对不同层级采用不同的 vibe coding 程度：
- UI 层：大胆用，生成了直接用，微调就好
- 业务逻辑层：用 AI 生成初稿，但必须审查核心逻辑
- 数据层：手写或仔细审查，AI 生成的 SQL/ORM 代码必须验证
- 安全层：认证、授权、加密，这些要么手写要么用经过验证的库
善用上下文文件
Cursor 有 .cursorrules，Claude Code 有 CLAUDE.md。把这些文件写好，告诉 AI 你的项目规范、技术栈、代码风格，AI 生成的代码质量会高很多。我花了一个小时写了一份详细的 CLAUDE.md，之后 Claude Code 生成的代码明显更符合我的风格了。
小步迭代
一次只让 AI 做一件事。做完测试，确认没问题，提交。然后再做下一件。千万别让 AI 一口气改十个文件——出了问题你都不知道是哪次改动导致的。
报错是最好的 prompt
Karpathy 说得对：把完整的错误信息和堆栈跟踪扔给 AI，通常就能修复。这比你描述"这里好像不对"有效一百倍。
知道什么时候该停下来
如果 AI 连续三次都没修好一个 bug，回退到上一个 Git 提交，自己来。继续 prompt AI 只会让事情更糟。它会开始"猜"，越猜越离谱。我有一次让 AI 修一个 CSS 的 z-index 问题，它改了六次，每次都引入新问题，最后整个页面的布局都乱了。回退到初始提交，自己手动加了一行 z-index: 9999，两分钟搞定。
关键路径必须人工审查
数据库迁移、API 认证、支付集成、权限控制——这些地方出了问题就是事故。不管 AI 生成的代码看起来多完美，这些地方必须人工过一遍。
新手怎么入门 vibe coding
如果你之前没用过这类工具，我建议从这几步开始：
第一步：选一个工具
如果你想在 IDE 里工作，选 Cursor。下载安装，打开你的项目，按 Cmd+K（或 Ctrl+K）唤出 AI 对话框。先从简单的开始，比如"帮我给这个函数加注释"或者"把这个组件改成 TypeScript"。
如果你想在终端里工作，装 Claude Code。npm install -g @anthropic-ai/claude-code，然后在项目目录里运行 claude。适合有一定命令行基础的人。
如果你完全不想装东西，打开 bolt.new 或者 v0.dev，直接在浏览器里试。
第二步：从简单功能开始
别上来就让 AI "帮我写一个完整的电商系统"。从一个小功能开始，比如：
- "帮我写一个格式化日期的工具函数"
- "给这个列表组件加分页功能"
- "帮我写一个 API 接口的单元测试"
等你熟悉了 AI 的能力和局限，再逐步加大复杂度。
第三步：学会写好 prompt
prompt 的质量直接决定 AI 输出的质量。几个技巧：
- 具体：不要说"优化一下性能"，要说"这个函数在数据量超过1万条时会卡，帮我用索引优化查询"
- 给上下文：告诉 AI 你的技术栈、版本、已有代码风格
- 分步骤：复杂功能拆成多步，每步做完测试确认再进行下一步
- 描述预期行为：不只说"做什么"，还要说"期望的效果是什么"
第四步：建立审查习惯
从一开始就养成审查 AI 代码的习惯。不需要每行都看，但至少要：
- 看懂代码的主流程
- 检查有没有明显的安全问题（硬编码密钥、SQL 注入等）
- 确认错误处理是否合理
- 跑一遍测试
这个习惯越早养成越好。等代码量大了再补审查习惯，来不及的。
未来怎么看
说说我自己的判断。
vibe coding 不会取代传统编程，但它会改变编程的定义。未来的"编程"可能更多是"描述"和"审查"，而不是"编写"。写代码本身会变成一个越来越不重要的技能，理解需求、设计架构、审查质量这些能力会变得更重要。
对新手来说，vibe coding 是一个巨大的机会。你不需要花三年学编程语言才能做出一个能用的应用。但如果你想成为真正优秀的工程师，你还是需要理解底层原理。否则你永远只是一个"AI 操作员"，而不是"工程师"。这不是危言耸听——当 AI 能做的事情越来越多，纯靠"操作 AI"的人的价值会被压缩。真正值钱的是能判断 AI 做得对不对、能设计系统架构、能处理 AI 处理不了的边界情况的人。
对有经验的开发者来说，vibe coding 是一个效率工具，不是替代品。用好了能让你事半功倍，用不好反而拖慢速度。关键是找到适合自己的工作流。我的建议是：先在一个小项目上试，找到自己的节奏，再逐步应用到正式项目中。
我目前的做法是：用 vibe coding 搭骨架和做重复性工作，关键逻辑自己写。UI 层大胆交给 AI，数据层和安全层严格把关。这个平衡点每个人不一样，得自己试。
后面打算再深入研究一下 Bolt.new 和 Lovable，看看这类"浏览器端 vibe coding"工具到底能做到什么程度。到时候再写一篇详细的对比。
有啥问题评论区聊。
- 参考资料：*