什么是 Vibe Coding，先说清楚
这个词是 Andrej Karpathy 去年提出来的，原话大概是：你不是在写代码，你是在"感受"代码的形成。你用自然语言描述你想要的东西，AI 把它变成代码，你只负责看对不对，不对就继续跟它说。
听起来很玄乎，实际上就是把 AI 编程助手从"辅助角色"变成"主角"。你是导演，AI 是演员，你说台词要这样，AI 演出来，你觉得差点意思再改。
几个月前这个概念还停留在推特和 YouTube 的讨论层面，但现在已经有大量人在真正用这种方式构建东西了。GitHub 的数据说 AI 生成的代码占比已经超过了 40%，某些领域更高。
不信你去看看 X 上 #vibecoding 这个 tag，每天都有新鲜的展示和争议。
我的三个月实验
第一个项目：内部数据监控工具
三月初，我们团队需要一个简单的内部工具——定时拉几个 API 数据，做成图表，邮件推送。没什么复杂的业务逻辑，就是胶水代码。
以前这种需求我会花一周搞定，还需要反复对齐需求、写文档、review。
这次我换了个方式：Claude Code + 几段自然语言描述。大概是这样的：
"做一个 Python 服务，每天凌晨 2 点拉取三个 API 数据，数据结构是这个格式...，用 matplotlib 生成日环比和周趋势图，最后用 SMTP 发邮件给固定地址列表。"
三个小时后，主体功能跑通了。
说实话，第一次看到生成出来的代码，我有一秒钟的不适感——因为代码真的不是我写的，我甚至不知道某几个函数的具体实现，只知道它跑起来了。这种感觉很微妙，有点像让别人替你考了一道题，答对了但你自己不确定为什么。
但功能是好的。后来跑了三个星期，没出什么问题。
第二个项目：一个小型 API 服务
这是第二个项目，麻烦就在这里开始了。
需求比第一个复杂一些：一个接收 Webhook、做数据清洗、写入数据库、触发下游通知的 API 服务。有并发需求，还涉及第三方认证。
Vibe Coding 的方式开始跑得很顺。一天时间，骨架出来了，本地联调也通。
然后我就推了 staging。
第一个问题出现了：高并发下会出现数据库连接耗尽。代码里没有连接池配置，AI 生成的代码默认用了同步 IO，在几十个并发请求下直接趴了。
第二个问题：Webhook 验签逻辑是有的，但有一个边界条件没处理——如果第三方在 Header 里发了一个非标准格式的时间戳，验签代码会抛一个未捕获的异常，整个服务崩。
第三个问题：API Key 在代码里没有经过任何加密，直接明文存在环境变量读取逻辑的注释旁边……虽然没有硬编码进去，但注释里写着"这里替换成你的 key"，审计扫了一眼就标红了。
三个问题，不算特别致命，但每一个放在生产环境里都是实实在在的风险。
我花了两天时间把这些问题修掉。
问题出在哪里，我想清楚了
这三个月下来，我觉得 Vibe Coding 本身没什么问题，问题在于一个概念偷换：
它把"能跑起来"和"可以上线"划了等号。
这两件事根本不是一回事。
开发阶段的"能跑起来"，是在一个干净的本地环境里，只有你一个用户，数据是你准备好的，网络是稳定的，没有恶意请求，没有并发压力，没有磁盘满了的情况，没有 Token 过期的边界。
生产环境是另一个宇宙。
我整理了一下这三个月遇到的问题，以及 X 上其他人分享的案例，发现有几个坑几乎是 Vibe Coding 项目的标配：
mindmap
root((Vibe Coding 常见坑))
安全问题
硬编码密钥
未加固的认证逻辑
缺少输入校验
稳定性问题
无连接池
缺少重试机制
未捕获异常
可维护性问题
无测试覆盖
意图不可追溯
修一处破三处
性能问题
缺少数据库索引
同步 IO 用在高并发场景
无缓存设计
这些问题有一个共同特点：AI 生成代码的时候是在为"演示"优化，不是为"生产"优化。
就像一个厨师给你做了一道菜，摆盘漂亮、颜色好看，你拍了照片发朋友圈。但你没发现盐放少了，因为你当时嘴里有别的味道盖住了。上了餐厅菜单，每天五十桌客人，这点问题就会被放大。
但我不想全盘否定它
说了这么多问题，但我没有变成 Vibe Coding 的反对者。
原因很简单：这东西真的能解放生产力，前提是你知道它能干什么、不能干什么。
用一张图说清楚：
quadrantChart
title Vibe Coding 适用区间
x-axis 需求清晰度低 --> 需求清晰度高
y-axis 系统复杂度低 --> 系统复杂度高
quadrant-1 慎用（需要深度工程化）
quadrant-2 不推荐（复杂且模糊）
quadrant-3 非常适合（脚本/原型/工具）
quadrant-4 适合（成熟需求的快速交付）
内部小工具: [0.3, 0.2]
原型验证: [0.4, 0.15]
数据分析脚本: [0.55, 0.25]
小型 API: [0.65, 0.45]
核心业务服务: [0.7, 0.8]
金融交易系统: [0.8, 0.9]
认证系统: [0.75, 0.85]
左下角那一块——需求清晰、复杂度低——这是 Vibe Coding 的甜蜜区。脚本、内部工具、原型验证、数据处理，这类东西用 Vibe Coding 做，效率是传统方式的好几倍，而且出问题的代价很小。
右上角——复杂度高、涉及安全和并发——这里就要非常小心了。不是说不能用 AI，而是你不能"全程放手"，你需要审查、测试、加固。
我现在的工作流
根据这几个月的经验，我现在的工作方式大概是这样的：
flowchart TD
A[有新需求] --> B{评估复杂度}
B -- 简单工具/脚本 --> C[直接 Vibe Coding]
B -- 中等复杂度 --> D[写 Spec 文档]
B -- 高复杂度 --> E[架构设计先行]
C --> F[功能验证]
D --> G[基于 Spec 用 AI 生成]
E --> H[分模块用 AI 辅助]
F --> I{是否要上生产?}
G --> I
H --> I
I -- 是 --> J[安全审计]
I -- 否 --> K[直接用]
J --> L[错误处理补全]
L --> M[关键路径测试]
M --> N[Staging 验证]
N --> O[上线]
这套流程的核心是：Vibe Coding 负责速度，工程思维负责质量。
两者不是对立的，是互补的。
关于"不会写代码的人能用 Vibe Coding 做产品"这件事
X 上有一个持续几个月的争论：Vibe Coding 是否会让"不懂编程的人"也能做软件产品？
坦白说，这个问题我的答案是：能，但只能到一定程度。
我认识一个做设计的朋友，去年底开始用 Cursor + Claude，确实上线了一个小工具，也有真实用户在用。但他告诉我，现在最大的痛苦不是功能做不出来，而是出了问题不知道为什么。
有一次用户反馈某个功能突然不好用了，他用 AI 改了三遍，改了这里那里又好了，又坏了。他不知道根因是什么，只能靠反复"感觉"去调整。这个过程极其消耗精力，而且容易陷入"按下葫芦起了瓢"的循环。
CodeRabbit 去年底做过一个分析，对比了 470 个开源 PR，AI 生成代码的逻辑错误比人工代码多 75%，安全漏洞多 174%，性能问题多近 8 倍。
这不是说 AI 不行。这是说，如果你不具备识别这些问题的能力，你就没有办法知道什么时候该停下来、什么时候该深挖。
所以我觉得，Vibe Coding 降低了入门的门槛，但没有降低把产品做好的门槛。这是两件不同的事。
2026 年的真实局面
现在是 2026 年 4 月，我觉得这个行业正在进入一个有趣的节点。
一边是工具越来越强——Google 的 Gemma 4 单卡能跑复杂推理，Claude Code 几乎能跑完整个开发流程，各种本地部署方案越来越成熟。
另一边是问题越来越明显——Georgia Tech 追踪了 2026 年 3 月的数据，单月因 AI 生成代码引发的 CVE 达到 35 个，研究者估计实际数字是公开披露的 5 到 10 倍。亚马逊在推行 AI 开发 mandate 之后，三个月内经历了至少四次 Sev-1 级事故，其中一次六小时宕机估算损失了 630 万个订单。
工具强大和工程质量之间的矛盾，在 2026 年没有消失，反而变得更尖锐了。
graph LR
A["📅 2023<br/>Copilot 普及<br/>代码补全为主"]
B["📅 2024<br/>Chat-based 编程<br/>LLM 能生成完整函数"]
C["📅 2025<br/>Agent 出现<br/>能做多步任务<br/>Vibe Coding 概念兴起"]
D["📅 2026<br/>AI 写 40%+ 代码<br/>生产事故开始暴露<br/>Spec-Driven 模式兴起"]
A --> B --> C --> D
style A fill:#e8f4f8,stroke:#4a9eca,color:#000
style B fill:#d4edda,stroke:#28a745,color:#000
style C fill:#fff3cd,stroke:#ffc107,color:#000
style D fill:#f8d7da,stroke:#dc3545,color:#000
我觉得接下来会发生什么
不做预测家，就说我的观察。
第一，Spec-Driven Development 会成为主流。
就是在用 AI 生成代码之前，先写一份明确的规格文档——不是 PRD，不是需求文档，而是一份技术意图说明，约定接口、约定边界、约定行为。AI 基于 Spec 生成代码，而不是基于"感觉"。
这不是什么新概念，但在 Vibe Coding 带来的混乱之后，它会重新被重视。Amazon Kiro 这类工具已经在做这个方向了。
第二，"会 Prompt 的工程师"和"会工程的 Prompt 工程师"，市场价值会拉开差距。
前者只会说话，后者能在说话的同时判断对不对、风险在哪、该怎么兜底。后者才是真正的竞争力所在。
第三，AI 会继续强大，但不会让工程思维变得不重要。
这是我最核心的判断。模型的上下文窗口越来越长，推理能力越来越强，但一个没有架构设计、没有测试覆盖、没有错误处理的系统，无论是人写的还是 AI 写的，在生产环境里都是定时炸弹。
最后说一句
Vibe Coding 是真实的工具，不是噱头，也不是银弹。
它最大的价值不是"让不会写代码的人写出代码"，而是让会写代码的人把时间花在更重要的事情上。
如果你把它当成替代工程能力的东西，迟早会被它坑。
如果你把它当成放大工程能力的工具，它能让你快很多。
区别在于，你有没有留住那个"我知道这里可能有问题"的直觉。
那个直觉，是工程经验，不是 Prompt 技巧。
