考察点
这是 2026 年 AI 编程面试的常见观点题，Karpathy 提出 vibe coding 这个词之后几乎场场被问。面试官想看的是你能否辩证区分场景，而不是无脑吹或无脑黑；更深层是考察你对「代码正确性由谁保证」这个根本问题的理解。追问常往「你敢把 vibe coding 的代码上生产吗」「怎么发现 AI 埋的雷」走。
参考答案
先定义清楚
Vibe coding 是 Andrej Karpathy 在 2025 年初造的词，核心是：人完全用自然语言描述需求，AI 生成全部代码，人不读代码，只看运行结果——能跑、看着对，就继续提下一个需求；报错了就把报错贴回去让 AI 自己修。整个过程中「代码」这个中间产物对人是透明的，人面对的是一个会进化的程序，而不是一份代码资产。
它真实的价值
公平地说，vibe coding 在特定场景是巨大提效：一次性脚本、demo 原型、个人小工具、探索性实验。这类代码的共同点是生命周期短、出错代价低、没有维护者。以前写一个爬数据的小脚本要一下午，现在二十分钟，而这些脚本你本来就不打算读第二遍。它还把编程门槛拉低到非工程师群体——产品经理可以自己搓个内部工具原型再来谈需求，这是真实的生产力释放。
风险在哪
问题出在人把这套方式搬进生产代码。我归成四类风险：
| 风险 | 具体表现 |
|---|---|
| 安全漏洞 | AI 生成代码在 SQL 注入、鉴权绕过、密钥硬编码上犯错是常态，不 review 就是带着漏洞上线 |
| 隐性 bug | 代码「能跑」只覆盖了 happy path，并发、边界、异常路径的缺陷在特定条件下才爆 |
| 架构腐烂 | 每轮对话 AI 只看到局部，反复叠加后重复代码、矛盾抽象堆积，几个月后没人（包括 AI）改得动 |
| 能力空心化 | 团队没人真正理解系统行为，出线上事故时连排查入口都找不到 |
最致命的是这些风险有延迟性：vibe coding 的项目头两周进展神速，第三个月开始为每一次改动付出越来越高昂的调试成本，此时沉没成本已经大到没法回头。
责任问题绕不开
工程上有个原则不会因为工具改变：谁合并代码，谁为它的行为负责。AI 没有责任能力，出了资损事故不能说「这是 AI 写的」。而负责的前提是理解——你没读过的代码你负不了责。所以 vibe coding 和生产环境之间天然矛盾：要么你读了代码（那就不是 vibe coding 了），要么你放弃了责任（那你不该有生产权限）。
我的使用边界
可丢弃代码随便 vibe；要进主干的代码，AI 可以写，但 diff 必须逐行过、测试必须绿、核心逻辑必须能复述。实际操作里有个简单判断标准：这段代码出 bug 的最坏结果是什么？答案是「删了重来」就 vibe，答案是「半夜被叫起来」就走完整流程。
可能的追问
- vibe coding 会取代程序员吗？——它取代的是「把需求翻译成代码」这一层体力活，反而抬高了理解系统、判断质量的价值；会被淘汰的是只会翻译不会判断的人。
- 团队里有人 vibe coding 提交了代码怎么办？——制度上堵住：PR 必须本人能讲清每处改动、CI 测试覆盖率卡点、review 时作者先讲设计意图，让「看不懂自己代码」无法通过流程。
- 怎么快速发现 AI 代码里的雷？——优先查三类地方：输入校验和鉴权逻辑、错误处理分支、它「自作主张」引入的依赖和抽象，这些是 AI 犯错密度最高的区域。