Vibe Coding工程之道-前言

前言

我不是因为 AI Coding 太好用，才写了这本书

如果你问我，是什么让我决定写一本关于 Vibe Coding 的书，我可能不会回答：因为 AI Coding 太强了。

恰恰相反。

是因为我被它折腾过太多次。

这些年，我几乎一直在和各种 AI Coding 工具打交道。Cursor、MGX、VS Code、Trae、Codex、OpenClaw、Hermes、Zcode……工具换了一批又一批，模型也一代比一代强。

刚开始接触 AI Coding 的时候，那种感觉确实让人兴奋。以前需要查文档、搜资料、翻 Stack Overflow、研究半天才能写出来的东西，现在只需要描述一句：“帮我实现这个功能。”几秒钟之后，代码就出来了。再说一句：“继续。”它甚至可以帮你创建文件、修改接口、调整数据库、修复报错、补充功能。

而且，我确实用这些工具做出了很多真正的项目。不是 Hello World，也不只是 Demo。

我做过基于 Dify 的企业知识库；做过基于 Odoo 的 ERP 二次开发，也做过 Odoo 电商模块的二次开发；还基于 Odoo 开发过可视化工作流引擎。

我用 FastAPI 开发过 API 接口，完整交付过 ASICRM 系统，也做过民族文化相关的家谱系统。

我基于 Enjoy 开源平台交付过智慧泵房项目，也使用 Xcode 开发过苹果 App。甚至在 PLC、ESP32 这些物联网场景里，我也大量使用 Cursor、Codex 等 AI Coding 工具参与开发。

从企业软件，到 Web 系统；从 ERP，到 CRM；从知识库，到工作流；从 API，到 App；再到 PLC、ESP32 和物联网设备。AI 确实帮我把很多过去门槛很高的事情做成了。

那些让我想摔电脑的时刻

我经历过很多 AI Coding 最让人崩溃的时刻。

有时候，一个功能明明昨天还能运行，今天让 AI 改了另外一个地方，它突然就坏了。你告诉 AI：“这里有个 Bug，帮我修一下。”它非常自信：“问题已经修复。”运行。报错。

你把错误继续发给它。它又非常自信：“我已经定位到根本原因。”再改。又报错。修着修着，你突然发现：最开始那个 Bug 可能还没解决，现在已经多出了三个新的 Bug。

有时候情况更加糟糕。一个项目刚开始的时候非常顺利。几十个文件，一两百个接口，功能一个接一个完成。你甚至会觉得：“照这个速度，再过几天整个系统就做完了。”

但随着需求不断增加，事情开始慢慢失控。数据库字段越来越多，接口返回格式开始不一致，同一段业务逻辑在不同文件里出现了三四遍，配置散落在代码各处，一个功能明明只需要改一个地方，最后 AI 改了十几个文件。

我经历过气得想摔电脑的时候。也经历过一个功能反反复复修改，最后发现还不如全部推倒重写的时候。经历过代码写了很多，却不知道问题到底藏在哪里，只能一个文件一个文件、一段代码一段代码地人工检查。

甚至有时候，面对几万行 AI 生成的代码，你会产生一种非常无力的感觉：这些代码明明都是“我让 AI 写的”，但我自己已经不知道它们为什么会变成现在这个样子。

这种痛苦，我相信很多真正做过 Vibe Coding 项目的人都经历过。

问题也许从来不只是 AI

有一段时间，我把这些问题归结为 AI 还不够聪明。我会想：是不是 Cursor 还不够强？是不是换一个模型会好一点？是不是 Codex 会处理得更好？是不是应该再找一个更强的 Agent？是不是上下文窗口再大一点，AI 就能理解整个项目？

于是不断换工具、换模型、换 Prompt、换工作方式。

模型确实越来越强。AI Coding 工具也确实越来越强。很多非常低级的错误已经明显减少。它们能够理解越来越大的代码库，能够跨文件修改代码，能够运行命令、分析日志、生成测试，甚至可以自主完成越来越复杂的开发任务。

也正因为工具越来越强，我现在使用 AI Coding 的方式，已经和最初发生了很大变化。我不再只是把需求交给 Coding 工具，让它把功能“做出来”，而是会继续让它回过头审视自己写下的代码：做安全检测，检查潜在风险；分析代码的健壮性和可扩展性；寻找重复实现、无效逻辑和已经失去价值的垃圾代码；检查模块之间是否存在不必要的耦合，以及当前设计能不能承受下一轮需求变化。

一个模块开发完成，也不意味着工作就结束了。我还会让 Coding 工具继续做功能测试和性能测试，主动寻找边界条件、异常路径和性能瓶颈，再根据测试结果持续迭代和优化。这个过程让我越来越确信：AI Coding 真正有价值的地方，不只是“生成代码”，而是让 AI 参与需求、实现、检查、测试、修复和优化的完整工程循环。

很多人仍然在重复经历同样的问题：需求越改越乱，代码越写越多，Bug 越修越多；AI 不断修改自己刚刚写过的代码；本地明明可以运行，一部署就出问题；开发环境正常，生产环境崩溃；一个功能上线之后，才发现数据库结构根本支撑不了后面的需求。

更可怕的是：很多时候，项目明明已经开始失控，我们却不知道它为什么失控。

直到后来，我才慢慢意识到：也许问题从来就不只是 AI。

我们跳过的，其实是“学会做软件”的过程

我们这一代 Vibe Coder 有一个非常特殊的地方。过去，一个人想开发软件，必须先学很多东西。编程语言、数据库、网络、架构、Git、测试、部署……学习门槛很高。所以很多人在真正做项目之前，已经被迫接触了一部分软件工程知识。

AI Coding 出现之后，这个顺序被彻底改变了。今天，一个完全没有软件开发经验的人，可以在还不知道什么是数据库主键、API、环境变量、版本控制、测试用例的时候，就开始开发一个真正的软件。

于是最常见的 Vibe Coding 工作流变成了：有一个想法，告诉 AI，让 AI 写；发现不对，继续告诉 AI；AI 继续改；再发现问题，再改。直到有一天，项目复杂度超过了我们能够理解和控制的范围。

这时候，我们通常会说：“AI 又把项目写烂了。”

但做过越来越多项目之后，我开始重新思考这句话。很多时候，AI 其实只是非常忠实地执行了我们的要求。真正的问题是：我们有没有告诉它需求边界在哪里？有没有先把业务拆清楚？有没有确定数据模型？有没有设计模块之间的关系？有没有定义接口规范？有没有告诉它哪些代码绝对不能随便修改？有没有测试异常路径？有没有版本、备份和回滚机制？有没有在项目越来越复杂的时候控制技术债务？

为什么写这本书

这也是我最终决定写这本书的原因。

我不想再写一本“如何使用 Cursor”的书，也不想写一本“100 个万能 Prompt”之类的书。因为工具一定会变。Cursor 会升级，Codex 会升级，新的 Agent 会不断出现，今天最强的模型，几年以后也可能只是一个历史版本。

但有些东西不会那么快改变。需求为什么必须先澄清，系统为什么必须拆模块，数据库为什么不能让 AI 随便建，接口为什么需要约定，代码为什么需要边界，测试为什么不能只是“我点了一遍没问题”，部署为什么不是把代码上传服务器那么简单，版本为什么必须可以回退，一个已经失控的项目为什么不能继续靠“再让 AI 修一下”来抢救。

这些问题，本质上都不是某一个 AI Coding 工具的问题。它们属于一个已经存在了几十年的领域：软件工程。只不过到了 AI Coding 时代，我们需要重新学习它。

不是按照传统计算机教材的方式，从理论开始学习几年之后再写项目。而是反过来：让 AI 负责越来越多的代码实现，而我们掌握那些真正决定项目是否失控的工程边界。

这也是我在这本书里真正想讨论的东西。

写给后来者

如果你已经在使用 AI Coding，也许你会在后面的很多章节里看到曾经的自己。

你可能也经历过一个 Bug 修五遍；经历过 AI 今天写的代码，明天自己推翻；经历过一个项目从“进展神速”突然变成“谁也不敢改”；经历过几十次“这次一定修好了”，然后运行，还是报错。

如果是这样，我希望你读完这本书之后，至少能够少走一些我走过的弯路。少重写几次项目，少熬几个没有意义的夜，少经历几次盯着几万行 AI 生成代码，却不知道问题究竟在哪里的无力感。

更重要的是，我希望你慢慢建立一种新的能力：不是比 AI 更会写代码，而是知道什么时候应该让 AI 写，应该让它写什么，哪些东西必须先设计，哪些边界绝对不能让它突破，以及怎样判断它写出来的东西到底能不能交付。

因为 AI Coding 真正改变的，从来不只是写代码的速度。它正在重新定义一个普通人能够创造什么。

而当代码越来越容易获得之后，真正稀缺的能力，也许恰恰不再是“写出代码”。而是驾驭复杂度，控制工程边界，把一个想法真正变成一个可以运行、可以维护、可以迭代、可以交付的软件。

这就是我写《Vibe Coding 工程之道》的原因。

AI 可以替我们写越来越多的代码。

但软件工程这件事，最终还是需要我们自己负责。