Vibe Coding 知多少？

   Hello folks，我是 Luga，今天我们来聊一下人工智能应用场景 - 构建大模型应用架构写代码协作模式：Vibe Coding。

   前段时间，特斯拉前 AI 总监 Andrej Karpathy 发了一条推文，大意是说他现在的编程状态就是“Vibe Coding”（氛围感编程）。

   为何钟情于 Vibe Coding ？简单说，就是你不再死磕每一行语法，不再纠结某个库的 API 到底传三个参数还是两个参数。你把大把的时间花在写 Prompt（提示词）上，把代码生成交给 LLM（大语言模型），然后你只负责 Run 一下。

   跑通了？Great，Vibe（氛围）对了，继续下一个功能。 报错了？复制报错信息丢给 AI，修好为止。

    乍一听，这不就是“脚本小子”或者“面向 StackOverflow 编程”的终极进化版吗？很多老派工程师对此嗤之以鼻，觉得这是技术堕落。但作为一名长期关注研发效能和系统架构的从业者，我必须得说：别急着嘲笑，Vibe Coding 本质上是一场软件工程领域的“架构降维打击”。

   今天，我们不谈虚的，就从系统架构和研发工作流的视角，来扒一扒 Vibe Coding 到底改变了什么，以及我们该如何在一个“氛围感”拉满的时代，守住工程质量的底线。

—01—

Vibe Coding 的解构：一种新的人机协作架构

   在传统的软件工程架构中，人是绝对的计算中心。我们需要在大脑里构建 AST（抽象语法树），需要记忆几千个 API，需要在大脑缓存里维护整个模块的上下文。IDE（集成开发环境）只是你的打字机和纠错本。

  而在 Vibe Coding 的架构中，我们则退居到了“编排层”，那么，意味着：

  1、交互架构的变迁：从 I/O 到 Context/Intent

  以前我们写代码，输入是字符，输出是二进制。现在，Vibe Coding 的核心输入是 Context（上下文） 和 Intent（意图）。

  意图（Intent）： “我要一个带鉴权的登录窗口，用 React 写，样式抄 Airbnb。”

  上下文（Context）： “这是我的 auth.ts 文件，这是我的 tailwind.config.js，别给我引入新的 UI 库。”

   在这个架构里，IDE（如 Cursor, Windsurf）不再是编辑器，而变成了一个RAG（检索增强生成）系统。当你敲下 Cmd+K 的时候，背后发生了一次复杂的架构级操作：系统抓取你的当前文件、引用文件、甚至整个 Git 仓库的索引，打包成向量，去匹配最相关的代码片段，塞进 LLM 的上下文窗口。

   2、容错机制的下沉

  传统编程要求“零错误”。写错一个分号，编译器就教你做人。而 Vibe Coding 引入了一种概率性的容错架构。我们允许代码第一遍是“脏”的。因为修复成本极低（Highlight 代码 -> "Fix this"），所以我们不再追求一次性写对，而是追求更快的迭代反馈循环。

   这种模式下，编译器和解释器的角色变了。它们从“看门大爷”变成了“质量检测探针”。我们利用运行时的报错信息作为 Feedback Loop（反馈环）的一部分，驱动 LLM 进行自我修正。

—02—

架构师视角的冷思考：Vibe Coding 对系统设计的冲击

   大家都在爽用 AI 写代码，但随之而来的架构问题，可能比代码本身更棘手。如果一个团队全面转向 Vibe Coding，我们的系统架构会变成什么样？

   1、样板代码的“通货膨胀”与微服务碎片的泛滥

   以前我们提倡 DRY（Don't Repeat Yourself），提倡高度抽象，是因为写代码累，维护代码更累。我们通过复杂的泛型、继承、设计模式来复用逻辑。但在 Vibe Coding 时代，生成样板代码（Boilerplate）的成本趋近于零。

    这会导致一个有趣的架构现象：“去抽象化”。与其写一个极其复杂、适配十种情况的通用组件，不如让 AI 给我生成十个简单、独立、互不干扰的组件。

优点： 解耦。A 模块挂了不影响 B 模块，逻辑直白，没有复杂的继承链。

缺点： 代码体积爆炸。如果系统里有 50 个长得差不多的函数，当你需要统一修改一个逻辑（比如改一下时间戳格式）时，原本改基类就完事，现在你可能需要 AI 帮你把 50 个文件都扫一遍。

 这要求我们在架构设计时，重新审视“代码复用”的价值。也许在未来，从某种意义上而言，“逻辑复用”比“代码复用”更重要。

   2、"AI Slop"（AI 垃圾堆）与可维护性危机

   Vibe Coding 最可怕的地方在于：代码生成的速度，远超过人类阅读理解的速度。一个初级工程师可以在一小时内用 AI 生成两千行代码，跑通了一个复杂的报表功能。功能是好的，Vibe 是对的，但代码内部可能是“屎山”，例如：

奇怪的变量命名（AI 幻觉）。

冗余的逻辑判断。

引入了三个功能重复的第三方库。

极其低效的循环嵌套。

   这种代码我称之为“AI Slop”。它能跑，但它是黑盒。一旦业务逻辑变更，或者出现了性能瓶颈，接手维护的人（或者未来的你自己）会极其痛苦。

   因此，从架构角度看，这引入了巨大的技术债务。我们在享受 Vibe 的同时，正在透支未来的可维护性。

   3、测试即架构

  在 Vibe Coding 时代，单元测试和集成测试的地位将上升到前所未有的高度。以前，测试是为了防人类手滑。 现在，测试是系统的骨架。因为代码是概率生成的，不可信。唯一能从逻辑上约束 AI 不乱来的，只有测试用例。

   在 Vibe Coding 的工作流中，TDD（测试驱动开发） 可能会迎来真正的春天，甚至变种为 PDD（Prompt Driven Development）：

架构师/高阶开发者编写测试用例和接口定义（.d.ts）。

Vibe Coder 疯狂生成代码，直到跑通测试。

   因此，测试代码成为了系统真正的“规格说明书”，而实现代码只是可替换的填充物。

—03—

支撑 Vibe Coding 的基础设施

   在实际的项目开发过程中，要真正玩转 Vibe Coding，光靠 ChatGPT 的网页版是不够的。我们需要一套全新的架构级基础设施。从宏观角度而言，主要涉及如下：

   1、Context Manager 驱动

  现在的主流 Cursor、Windsurf 只是第一步。未来的 IDE 架构核心是 Context Management（上下文管理）。一个资深的 Vibe Coder 知道，AI 变笨不是因为它模型差，而是因为你喂给它的 Context 不对。

 例如，我们可能会遇到这种架构挑战： 如何在有限的 Token 窗口（即使是 200k/1M）里，塞入最精准的代码片段？

  通常而言，针对上述问题，可能 IDE 需要内置一个高性能的向量数据库，并结合知识图谱。比如我改动了 A 函数，IDE 应该顺着调用链找到 B 和 C，自动把它们加入 Context。

   2、MCP（Model Context Protocol）的支撑

   最近 Anthropic 推出的 MCP 协议非常值得关注。从架构视角看，它解决了数据孤岛问题。

   以前 AI 只能看你的本地代码。有了 MCP，IDE 可以连接你的 MySQL 数据库、连接你的 Linear 任务看板、连接你的 Sentry 报错日志。

   这才是 Vibe Coding 的完全体： 你对 IDE 说：“嘿，看看 Sentry 上那个最新的报错，结合数据库里的用户表结构，帮我写个修复补丁。” 这背后，是数据层、监控层与代码生产层的打通。这是一种全新的 DevOps 架构。

—01—

那么，究竟如何理解 Vibe Coding ？

   基于前面所述，Vibe Coding 本质上是一种“意图优于实现”的编程范式。传统开发中，开发者的主要心智负担在于“如何用代码实现意图”——需要掌握语法规则、API调用、数据结构选择、边界情况处理等细节。而 Vibe Coding 将这个负担转移给 AI，开发者通过自然语言描述期望的结果或“氛围”，由大型语言模型（LLM）生成应用程序的源代码。

   从工作流角度看，Vibe Coding 形成了一个全新的开发闭环：语音/文本意图输入 AI代码生成 运行测试 反馈优化 迭代改进。这个流程的关键是让AI成为“编码执行层”，开发者升级为“意图表达层”和“质量控制层”。

   从架构层面来讲，Vibe Coding 的实现依赖如下两大技术突破：

   1、大型语言模型的代码生成能力

  现代 LLM（如GPT-4、Claude 3.5、DeepSeek）的代码生成能力已达到生产可用水平，其核心是基于大规模代码语料训练的 Transformer 架构。这些模型不仅学会了语法规则，还掌握了常见的编程模式、框架 API 用法和问题解决路径。这些模型是基于概率生成的，而非确定性逻辑推理——这是 Vibe Coding 所有问题的根源。

   就目前而言，AI 编程工具通常采用两种技术路线：

行内补全模式

  基于上下文预测下一段代码，类似 IDE 的自动补全但更智能。优势是响应快、不打断思路，但只能生成片段级代码。

对话生成模式

通过自然语言指令生成完整功能模块，甚至整个项目脚手架。能够理解复杂意图，但对提示词（Prompt）质量敏感。

  2、代码库级上下文理解

现代 AI 编程工具的另一个突破是对整个代码库的理解能力。它们会：

索引项目结构

分析文件关系、依赖链、函数调用图等，建立代码语义索引。

检索相关上下文

根据当前编辑位置，自动检索相关的代码片段作为提示上下文。

增量学习项目风格

通过分析现有代码，适应项目的命名风格、架构模式等。

  这种上下文理解对生产环境至关重要。以 Cursor 为例，它的 Composer 功能能够在整个代码库范围内理解需求，生成的代码会自动继承项目的 TypeScript 类型定义、React组件结构和状态管理模式。

   综上所述，Vibe Coding 很爽，让我们找回了那种“想到就能做到”的创造力快感，降低了编程的门槛，让想法到产品的距离无限缩短。但作为架构师，我要泼一盆冷水：Vibe 是感性的，但工程是理性的。

   你可以用 Vibe Coding 快速出原型，快速验证 MVP（最小可行性产品）。但当你要把这个系统推向生产环境，要面对千万级流量，要处理用户的真金白银时，请收起你的 Vibe。

   这时候，我们需要的是严谨的 Code Review，是 100% 覆盖的测试，是灰度发布，是容灾演练。

   Vibe Coding 不是一种无需大脑的偷懒方式，是以人类的判断力为核心，以 AI 算力为杠杆的架构跃迁。因此，只有当你深刻理解了底层的处理逻辑，业务场景，你才能自信地坐在屏幕前，看着代码如流水般生成，然后轻描淡写地说一句："The vibe is good. Deploy it."

   Happy Coding ~

Reference ：

[1] https://www.newscientist.com/article/2473993-what-is-vibe-coding-should-you-be-doing-it-and-does-it-matter/

[2]     https://tribeacademy.sg/blog/vibe-coding/

  Adiós !

··································

对云原生网关 Traefik 感兴趣的朋友们，可以了解一下我的新书，感谢支持！

Hello folks，我是 Luga，AI 创业者，Traefik Ambassador，Jakarta EE Ambassador， 一个 15 年+ 技术老司机，从 IT 屌丝折腾到码畜，最后到“酱油“架构师。如果你喜欢技术，不喜欢呻吟，那么恭喜你，来对地方了，关注我，共同学习、进步、超越～