Vibe Coding 是什么：适用场景与边界
Vibe Coding 是 Andrej Karpathy（/ˈændrɛdʒ ˈkɑːrpəθi/）在 2025 年初提出的概念，描述一种 AI 辅助编程风格：用自然语言描述需求 → AI 生成代码 → 跑通就过，不通就再让 AI 改 → 不完全理解每一行生成的代码，靠「感觉」和测试结果判断对错。
Karpathy 原话大意：“I just vibe. I don’t even read the diff. I just accept all and if it works, it ships.”
本质上它是把 AI 当成一个你不太审查代码的 Junior 开发者来协作——高信任、低验证成本、以结果驱动。
一、适合的场景
| 场景 | 原因 |
|---|---|
| 原型 / MVP / Demo | 速度优先，验证想法。后面如果要工程化，再重写也不迟 |
| 一次性脚本 | 数据清洗、格式转换、跑完就扔。生命周期短，正确性可肉眼验证 |
| 个人小工具 / 内部工具 | 用户是自己或几个同事，炸了影响可控，出了问题随时改 |
| 学习新领域 | 让 AI 生成代码你逆向理解，比从零看文档快。但最终要读懂 |
| UI 草稿 | 快速出前端页面看感觉，后面再工程化 |
共同特征：代码生命周期短、失败成本低、可验证性强。
二、不适合的场景
| 场景 | 原因 |
|---|---|
| 生产核心链路 | 涉及钱、权限、数据完整性的代码，每一行都需要理解 |
| 安全敏感逻辑 | 认证、鉴权、加密——错了是漏洞，不是 bug |
| 长生命周期系统 | 需要维护、扩展、多人协作的模块。不理解就改不动，改不动就腐化 |
| 性能敏感底层代码 | 热点路径、内存管理、并发控制——差一行结果差很多 |
| 线上排障 | 你不理解代码，出问题连排查起点都找不到 |
共同特征：失败成本高、需要长期维护、正确性不可妥协。
三、判断标准
一条自检就够了：
「这段代码我没细看，但我愿意为它上线负责。」——如果答案是不行，就别 vibe。
更务实的梯度做法：
原型阶段 → Vibe 没问题，速度第一
准备上线 → 至少读懂核心路径和控制流
准备长期维护 → 重构为你真正理解的代码
四、争议
- 支持方：编程民主化，降低门槛，让人专注于「做什么」而非「怎么做」。大多数 CRUD 代码本来也不需要天才手写。
- 反对方：对生产代码不负责。不理解就上线 = 把技术债务从代码层面转移到认知层面，还更难追。
- 中间立场（更务实）：Vibe coding 是一把速度杠杆，不是免思考通行证。知道什么时候 vibe、什么时候回到逐行理解，才是成熟工程师的判断力。