别再吹牛了，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（唯一约束）。 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 的逻辑死结出现了： 不纠正：线上系统埋雷，后期必出性能问题 要纠正：必须写一段比代码还长、比编程还复杂的自然语言提示词： 请使用 Drizzle ORM 定义 users 表，email 字段添加 unique 约束，但禁止在回调函数中手动创建 idx_email 索引，因为 unique 约束会自动生成索引，重复索引会造成性能浪费与存储冗余 这已经不是「描述需求」，而是用自然语言写代码。 案例 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 一定要有懂代码和业务逻辑的资深成员在，保持足够的约束和及时对 Vibe Coding 后的代码审查。 落地建议：如何安全使用 AI 编程 目前阶段，AI 不是全自动开发工具，而是高级辅助工具。想要保证代码质量，必须遵守两条铁律： 1. 测试用例必须全覆盖 AI 写测试用例的速度还是挺快的，而且准确性很高，所以可以借助单元测试、集成测试、接口测试来完成对 AI 功能的初次校验。 2. 必须有资深开发者逐次审查 没有人能跳过「理解代码」这一步。例如对代码： 审查逻辑合理性 审查架构规范 审查性能隐患 ... 100% Vibe Coding = 技术裸奔 真正高效的模式是：Human Intention + AI Execution + Human Review 最后我想说，写代码变便宜了，但为错误买单的成本，从来没有降低过。感谢关注，点赞也欢迎关注我的公众号：ai超级个人，不定时分享高级特效源码哦