别再吹牛了，100% 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（唯一约束）。