Vibe Coding 一年之后:当“随口一说“真的能上生产环境

📅 2026/7/12 11:26:14
Vibe Coding 一年之后:当“随口一说“真的能上生产环境
2025 年初Andrej Karpathy 在一条推文里随手造了个词——Vibe Coding大意是“别看代码了跟着感觉走让 AI 全写能跑就行”。一年半过去这个词从段子变成了工作流。有人用它三天上线了一个 SaaS MVP也有人用它写的支付回调被薅走了六位数。这篇文章不谈信仰只聊事实哪些场景它真的能打哪些地方它会让你半夜接到报警电话。目录一、Vibe Coding 到底是什么不是什么二、一年来的技术栈演进从“能跑”到“能用”三、成功案例MVP 与内部工具的甜蜜区四、翻车现场鉴权、支付与数据安全五、安全边界清单哪些活能交哪些不能六、2026 年的务实路线混合开发模式七、写在最后一、Vibe Coding 到底是什么不是什么Vibe Coding 的核心操作很简单你用自然语言描述需求AI 生成代码你运行一下能用就下一个不能用就再描述一遍。整个过程中开发者更像产品经理而不是工程师——你关心的是“做什么”而不是“怎么做”。但这里有个常见误解Vibe Coding 不等于“完全不看代码”。Karpathy 自己也说了他的原始语境是个人项目和原型验证。问题是这个概念传播开之后边界被无限放大了。有些团队真的把它当银弹拿来写生产系统的核心链路这就出事了。准确地说Vibe Coding 是一种开发模式的光谱。一端是纯对话式开发完全不看生成的代码另一端是 AI 辅助开发AI 写初稿人逐行审查。大多数落地实践处于中间位置。二、一年来的技术栈演进从“能跑”到“能用”2025 年初玩 Vibe Coding工具链还很粗糙——基本就是 ChatGPT 加复制粘贴。一年过去整个生态已经完全不同了。2026 年中的今天主流工具链大概长这样编码代理Claude Code、OpenAI Codex CLI、Google Jules 都支持在终端里直接对话式开发能读写文件、运行测试、提交 Git。IDE 集成Cursor 和 GitHub Copilot 已经从“补全工具”进化成了“对话式协作者”支持多文件编辑和项目级重构。模型能力Claude Opus 4 系列和 GPT-5 的上下文窗口和推理深度让 AI 真正能理解一个中等规模项目的整体结构而不只是看一个函数。部署管道Vercel v0、Replit Agent 这类平台把“从描述到部署”压缩到了分钟级别。关键变化不是某个工具变强了而是整条链路打通了。以前你要在聊天窗口和编辑器之间来回切换现在 AI 直接在你的项目目录里干活写完跑测试测试过了自己提 commit。三、成功案例MVP 与内部工具的甜蜜区先说结论Vibe Coding 目前最能打的两个场景是MVP 快速验证和内部工具开发。案例一三天上线的客户反馈看板一个朋友在做 B 端 SaaS产品经理想要一个内部用的客户反馈看板——能接 Intercom webhook按主题分类生成周报。传统排期至少两周他用 Claude Code 对话式开发三天搞定。技术栈是 Next.js Supabase Tailwind全程没手写超过 50 行代码。因为是内部工具不需要处理鉴权走的公司 SSO、不涉及支付、数据丢了也不致命——完美落在 Vibe Coding 的舒适区里。案例二周末做的独立开发产品推特上一个独立开发者周五晚上有了个想法——做一个 AI 生成旅行攻略的小工具。周日晚上就部署上线了第一周来了 2000 个用户。核心代码大概 1500 行他说自己“认真看了”的不超过 300 行。这个项目后来确实遇到了性能问题AI 调用没做队列并发一高就挂但在验证 PMF 这个目标上它完成了使命。这两个案例有共同特点试错成本低迭代速度重要性远大于代码质量。四、翻车现场鉴权、支付与数据安全接下来是不那么愉快的部分。事故一Stripe webhook 验签被跳过2025 年下半年一个小型 SaaS 产品被曝出支付漏洞。开发者用 AI 生成了 Stripe 集成代码代码看着挺完整——创建 checkout session、处理 webhook、更新订阅状态都有。但 AI 生成的 webhook 处理函数里stripe.webhooks.constructEvent()那行被写成了 try-catchcatch 块里直接console.log了一下就继续处理了。等于 webhook 签名验证形同虚设任何人都可以伪造 webhook 事件给自己“充值”。发现的时候已经损失了大几万。事故二JWT 密钥硬编码另一个案例更经典。开发者让 AI “帮我加一个 JWT 登录”AI 很听话地写了一套完整的 auth 模块。密钥呢直接写死在代码里const SECRET super-secret-key-change-me。开发者没看Vibe Coding 嘛直接部署了。这个 secret 跟着代码推到了公开的 GitHub 仓库。后面的事情你能猜到。事故三SQL 注入——是的2026 年了还有一个用 AI 生成的 Python Flask 后端查询用户信息的接口直接把 URL 参数拼进了 SQL 字符串。ORM 都没用。开发者说“我以为 AI 肯定知道要用参数化查询”。AI 确实知道但那次生成碰巧没用——因为 prompt 里写的是“写一个简单的查询接口”“简单”这个词可能触发了 AI 生成最朴素的实现。这三个事故都有一个共同模式AI 生成的代码在功能层面是对的在安全层面是裸奔的。Vibe Coding 的“不看代码”哲学恰好把最需要人类判断的安全细节给跳过了。五、安全边界清单哪些活能交哪些不能基于过去一年社区踩过的坑我整理了一份实用的分类。不是理论推导是真实事故倒推出来的。简单粗暴的口诀“碰钱碰密碰隐私一行不能不审”。剩下的看场景自行判断。六、2026 年的务实路线混合开发模式经过一年的集体踩坑社区基本达成了一个共识纯 Vibe Coding 和完全不用 AI 都不现实。实际可行的是混合模式。第一层AI 生成人定骨架项目结构、数据库 schema、API 契约——这些由人来定。用 CLAUDE.md 或者 cursor rules 之类的项目配置文件把架构约束写清楚AI 在这个框架内生成具体实现。这比让 AI 从零开始设计一个系统靠谱得多。第二层关键路径设门禁在 CI/CD 流水线里对安全敏感文件设置强制 review 规则。比如任何改动auth/、payment/、middleware/目录下文件的 PR必须至少两个人类 reviewer approve。GitHub 的 CODEOWNERS 就能做到。第三层自动化兜底2026 年的工具链已经能做到不少自动化安全检查SAST 扫描Semgrep、CodeQL跑在每个 PR 上专门检测 AI 常犯的错误模式——硬编码密钥、SQL 拼接、未验证的 webhookAI Code Review用 Claude Code 的/code-review或者类似工具让另一个 AI 审查第一个 AI 写的代码是的很套娃但确实有效依赖审计AI 特别喜欢引入不必要的 npm 包npm audit和socket.dev这类工具是标配第四层渐进式放权新项目的前两周所有 AI 生成的代码都过 review。跑稳之后非关键路径逐步放开只保留核心模块的强制审查。这比一开始就全放开要安全得多。七、写在最后回头看Vibe Coding 这一年走过的路跟任何新技术的采用曲线差不多先是狂热“AI 能写所有代码”然后是幻灭“又出安全事故了”最后慢慢找到务实的位置。我个人的判断是Vibe Coding 正在从一种“编码方式”变成开发流程的默认起点。就像没人会从零手写一个 HTTP server 一样未来大部分代码的初稿都会是 AI 生成的。区别在于成熟的团队知道哪些初稿可以直接用哪些必须人工精修。不要把 Vibe Coding 当成取代工程能力的东西。恰恰相反——你得先知道什么是好代码才能判断 AI 写的代码好不好。一个不懂 JWT 原理的人根本发现不了 AI 把密钥硬编码了。工具会越来越强但工程判断力这件事目前还没法外包。