Vibe Coding逻辑漏洞深度解析：真相与自洽性争议

注：本文是亲身经历企业级的 Vibe coding 项目后的经验总结。有趣的是，写这篇文章的过程中，查到一个很有意思的资料：Vibe Coding 这个词的发明者 Andrej Karpathy（OpenAI 联合创始人、前 Tesla AI 负责人），后来自己也放弃了 Vibe coding，转向了一个叫 Agentic Engineering 的新方向。

好了，正文开始！

前言

现在各大技术平台上，鼓吹“100% Vibe Coding 碘伏编程”的机构、贩卖焦虑的博主层出不穷。仿佛只要靠 AI，一个毫无编程基础的人就能实现任何应用。

但说实话，在企业真实场景中，完整落地了一套企业级 Vibe Coding 项目后，得出的结论相当扎心：

100% Vibe Coding 不是好不好用的问题，而是它在逻辑上根本无法自洽、无法成立。

这篇文章会结合实战翻车案例和计算机科学经典理论，彻底拆解 100% Vibe Coding 的致命漏洞。

业务背景与 Vibe Coding 范式

先明确一下这次实战的基础信息，避免概念混淆。

1. 实战任务

为团队搭建一套可复用、可维护、企业级标准的 Node.js 通用脚手架，技术栈：

Hono.js + Drizzle ORM + PostgreSQL

必须包含：统一错误处理、结构化日志、完整用户模块、RBAC 权限控制模块等通用能力。

2. 使用工具

Claude Cli

3. 开发范式

严格遵循目前最火的 SDD（Spec-Driven Development，规格驱动开发）范式来开发，这也是 Vibe Coding 最推崇的标准化流程。

接着理清一下 Vibe Coding 和 SDD 范式的概念，有基础的同学可以跳过这部分阅读。

4. Vibe Coding 是什么？

这个词由前 OpenAI 首席科学家 Andrej Karpathy 带火。它的核心逻辑不是“AI 辅助”，而是“意图接管”：

一句话描述就是：不看代码、不理解实现，只用自然语言驱动 AI 生成代码，并以“能跑”为唯一标准的开发方式。

你可能会问，那报错怎么办？简单，把报错丢给 AI，直到没有错误为止。

5. SDD 规范是什么？

为了让大家秒懂什么是 SDD，简单拆解一下它的三部曲。

想象你要开发一个新项目，老板要开新业务，产品经理先出个产品文档。在 SDD 规范里，这叫 spec.md。它只聚焦用户价值和业务意图，不聊技术，只聊“我们要干什么”。

有了产品文档，研发得定框架、写技术文档。在 SDD 规范中，这叫 plan.md。

有了技术文档，接下来就是搬砖了。以前是我们人来写代码，现在交给 AI，得先让它把要做的事写成任务列表，这在 SDD 规范中叫 tasks.md。

最后确认 tasks.md 没有问题，就要开始开发了。但开发过程中，一般技术人都有自己的团队规范，比如变量命名规范是什么，代码接口规范是什么等等。

这种全局性的“游戏规则”，在 SDD 规范中叫 constitution.md。

其实本质就是不断拆解你的需求，最后对齐 AI 到底要帮我们做哪些任务。

企业级实战：两个真实翻车案例

吐槽一句，维护 SDD 这个范式的文档本身就非常费劲了。

严格按照 SDD 流程执行，甚至放弃「一次性生成任务」（task.md），尝试改进 SDD 的用法，采用小步生成 + 逐次核查，结果依然频繁翻车。

翻车的场景特别多，这里举两个案例。

案例 1：数据库表设计 —— 冗余索引致命隐患

第一个小案例关于建表。这个 task 中已经清晰展示了表结构。如下：

CREATE TABLE users (id UUID PRIMARY KEY DEFAULT gen_random_uuid(),email VARCHAR(255) UNIQUE NOT NULL,-- ... 其他字段);

重点：email 明确标注了 UNIQUE（唯一约束）。

AI 生成的 Drizzle 代码：

export const users = pgTable("users", {id: uuid("id").primaryKey().defaultRandom(),email: text("email").notNull().unique(), // ... 其他字段(table) => [index("idx_email").on(table.email), // 致命的“画蛇添足”]});

问题在哪里？

在 PostgreSQL/MySQL 中：

UNIQUE 约束 = 自动创建唯一索引

AI 额外手动添加了一行索引，如下：

export const users = pgTable("users", {// ... (table) => [index("idx_email").on(table.email), // 致命的“画蛇添足”]});

导致的结果：

• ✅ 代码不报错
• ✅ 功能能跑通
• ❌ 冗余索引 → 占用额外存储
• ❌ 写入性能大幅下降
• ❌ 长期埋下数据库性能隐患

然后，Vibe Coding 的逻辑死结出现了：

• 不纠正：线上系统埋雷，后期必出性能问题
• 要纠正：必须写一段比代码还长、比编程还复杂的自然语言提示词

这已经不是“描述需求”了，而是用自然语言写代码。

案例 2：依赖管理 —— 隐蔽的工程规范错误

文档中明确写明了环境规则：

• 本地开发：使用 dotenv 加载环境变量
• 生产环境：通过 docker-compose 注入变量，不需要 dotenv

结果 AI 直接把 dotenv 安装到了：

"dependencies": {"dotenv": "^17.1.13"}

正确做法应该是：

"devDependencies": {"dotenv": "^17.1.13"}

显然，"dotenv" 这个库已经明确说明线上环境不会用，但 AI 依然给安装到了 "dependencies" 中。

结果呢？代码不报错，项目能启动，但生产环境打包体积增大，不符合企业级工程规范。

以上案例都有一个共同特点：代码不报错，但问题确实比较明显。

问题到底在哪？

所有翻车案例，最终都指向三个底层逻辑死结。

自然语言的天生模糊

计算机科学祖师爷 Edsger Dijkstra 在 1978 年论文《论“自然语言编程”的愚蠢》（EWD667）中早已断言：

当你追求 100% Vibe Coding 准确落地时，必须用“模糊”的语言去约束一个“极其确定”的结果。当你的约束严谨到足以让 AI 不犯错时，你的 Prompt 其实已经变成了一套极其臃肿、低效的“新编程语言”。

复杂度“转移”了，而非“消失”

Vibe Coding 最大的谎言：降低开发难度 = 消除系统复杂度。

真相是：AI 把「开发成本」转移成了「维护成本」。

• 项目从 0→1：速度极快，新手也能生成可用代码
• 项目从 1→100：维护地狱，没人能读懂、修复、扩展 AI 生成的混乱代码

短期利好，MVP 验证、原型 demo、一次性脚本（项目扔了也不可惜），但长期来看确实是灾难，因为企业级系统 80% 的成本在维护与迭代。

两极分化：强者更强，弱者永远学不会

Vibe Coding 不是普惠工具，而是放大器：

• 对资深工程师：AI 是“增程器”，能快速实现思路、排查漏洞
• 对纯新手：AI 是“陷阱”，让你永远不理解底层逻辑，永远只会“让代码跑通”

更危险的是：大型项目中，你根本不知道 AI 代码埋了多少雷。一次线上故障，你用 AI 修复一个问题，可能埋下三个更深的隐患，而且你完全无法识别。

Vibe Coding 的正确使用边界

它不是魔鬼，也不是银弹，只适合特定场景。

适用场景（低风险 / 短生命周期）：原型、MVP 验证、一次性脚本、简单场景 CRUD 等等，确实是不错的选择。

但当项目是大型生产项目、跟金融相关的或者是长期维护的项目，使用 Vibe Coding 时，一定要有懂代码和业务逻辑的资深成员在，保持足够的约束和及时的代码审查。

落地建议：如何安全使用 AI 编程

目前阶段，AI 不是全自动开发工具，而是高级辅助工具。想要保证代码质量，必须遵守两条铁律。

1. 测试用例必须全覆盖

AI 写测试用例的速度还是挺快的，而且准确性很高。可以借助单元测试、集成测试、接口测试来完成对 AI 功能的初次校验。

2. 必须有资深开发者逐次审查

没有人能跳过「理解代码」这一步。审查内容包括：

• 逻辑合理性
• 架构规范
• 性能隐患
• 等等

100% Vibe Coding = 技术裸奔。

真正高效的模式是：Human Intention + AI Execution + Human Review。

最后想说，写代码变便宜了，但为错误买单的成本，从来没有降低过。