跟 AI 写代码越写越乱？这套「Vibe Coding」方法帮我治好幻觉屎山

说实话，我那时觉得 AI 写代码不过如此：表面像模像样，运行起来也没问题，可一到维护就比屎山更难处理。后来接触 Vibe Coding 的思路，我才意识到问题不在 AI，而在于自己从根本上用错了方法。

问题从第一步就开始了：规划决定一切

以前我总以为，用 AI 写代码只要把需求交代清楚，再等它输出即可。直到看见一个比方，我才醒悟：新员工刚入职时，你不会让他第一天就写核心业务，而会先让他了解技术规范、梳理业务流程；对待 AI 也是同样的道理。

技术栈、代码风格以及是否添加额外功能，它全都不知道。你上来只说一句 “帮我写个 XX 功能”，它便不得不逐项猜测；一路猜下去，幻觉自然满天飞。

因此，Vibe Coding 最先要做、也是最关键的事情，就是提前完成规划，绝不能让 AI 上来便开始写代码。

当时我就用那个待办清单做了尝试，并向 AI 发出这样一段内容：

遵守胶水编程思维：优先使用成熟方案，避免凭空造逻辑第一个阶段：只做规划，禁止输出任何代码1. 确认技术栈：React 19 + TailWindcss + useState2. 梳理功能边界- 新增待办、删除待办、切换完成状态- 不做本地持久化、筛选、拖拽功能3. 拆分模块输入框组件、待办条目组件、列表容器组件4. 定义数据流useState 存储 task 数组 数据结构：{id, text, completed}5. 输出这份完整规划，等待我确认无误后，再分段实现代码

发过去之后 AI 老老实实列了完整的规划文档，半行代码都没敢写。我扫了一眼，技术栈对得上，功能边界写死了 “不做什么”，数据结构也定死了text字段，模块拆分也合理，确认没问题了才让它开始写代码。

规划究竟要防范什么？

这一步并非多此一举。后来复盘时我发现，仅仅几百字的规划，就直接封住了三个最常见的坑：

• 别让简单 demo 被 AI 擅自加戏后膨胀为臃肿的半成品，功能边界必须事先锁死
• 预先完成模块拆分，让 AI 依照组件输出代码，避免生成揉成一团的面条代码
• 把数据结构彻底确定，从源头消除字段幻觉 —— 不再出现一会儿title一会儿content了

我自己的小习惯 规划阶段我会反复强调 “禁止输出代码”，多花三五分钟改规划，比后面花半小时在屎山里找 bug 划算太多。

完成这样一个简单操作后，最终生成的代码结构十分清楚，各组件职责分明；想调整样式时，直接找到对应组件即可，整体结构与自己编写的相差无几。

「胶水编程」：尽可能降低 AI 的幻觉风险

规划讲完以后，再谈另一个我认为最实用的思路 —— 胶水编程。这个认识确实是我踩过坑后才获得的。

之前我想为待办清单添加拖拽排序，没多考虑便告诉 AI“帮我写个拖拽排序功能”。AI 随即手写了一整套拖拽逻辑，包括监听鼠标事件、计算元素坐标和手写排序算法，看上去格外厉害。可粘贴运行后，快速拖动会乱序，松手位置会跳动，边缘元素甚至能被拖出容器，各种 bug 让我修得头大。

当时我还埋怨 AI 写出的逻辑不可靠，后来才弄明白：并不是 AI 不可靠，而是我让它承担了不擅长的任务。

「胶水代码」究竟是什么

在我的理解中，胶水编程就像拼乐高：成熟的开源组件相当于厂家生产的乐高零件，经过千万人验证，尺寸准确且不易损坏；我们和 AI 无须在家烧塑料制造零件，只需编写少量“胶水代码”，把现成零件连接起来，使数据能够在组件之间流转。

这种方式为什么可以减少幻觉？原因很简单：AI 编写的代码越少，发生错误的概率越低。核心逻辑由经过社区验证的开源库承担，AI 只需写十几行用于衔接和适配的代码，即使发生问题也能一眼定位。

错误做法 vs 正确做法

仍以拖拽排序为例，两种实现方式之间的差别确实天差地别。

错误做法（从零制造零件，幻觉风险高）：

帮我写 React 待办清单的拖拽排序功能

正确做法（采用胶水思维，仅使用成熟组件）：

给待办列表增加拖拽排序1. 选用 react-beautiful-dnd 实现2. 不要手写拖拽底层逻辑，只做组件衔接和数据流转3. 先给出安装命令，再基于现有 TodoList 组件做适配

当时换成第二种写法后，AI 输出的代码量直接减少三分之二，核心逻辑全部交由库处理，我只需完成数据对接。粘贴运行后，拖拽十分丝滑，边界情况也没有问题，调试时间甚至没超过两分钟。

说实话，想明白这一点后，我写代码轻松了许多。过去总觉得让 AI 包办所有内容才厉害，现在反倒认为：可以不用 AI 编写的逻辑就不用，能依靠开源项目就直接采用，把 AI 的工作量降到最低，最终代码才更可靠。

越用越顺畅：让 AI 逐步自我进化

让 AI 按照你的习惯不断迭代，关键在于沉淀每一次经验。这个小技巧说来并不复杂，却能在规划和胶水思维之外，让 AI 变得越来越好用。

后来，我把技术栈偏好、踩过的坑和代码规范集中记录在一个 md 文件中。每当新项目启动，先把它交给 AI，等于完成一次岗前培训。这样一来，“用函数组件”“用 Tailwind”“注释不要写太多”等规范就不用像最开始那样，每次写代码都重新说一遍，免去了反复说明的烦恼。

再后来，我还增加了一个步骤：AI 每次写完代码后，都要自行复盘哪些地方不符合规范、哪些地方可以优化，再把结论补充到那份规范文件中。这相当于让 AI 主动为自己设定要求，使下一次输出更符合我的习惯。

就像很多人说的 α 提示词和 Ω 提示词：一份告诉 AI 该怎么干活，另一份负责打分复盘、优化规则。不用什么复杂的工具，一个普通的 markdown 文件就能搞定，用的次数越多，AI 就越懂你的风格，到后面基本改都不用怎么改。

我遇到的几个坑，希望你们别再踩

这段时间实际使用下来，我遇到的坑并不少，下面挑几个最容易中招的来讲。

第一个坑，是规划过于模糊。不要只写“做一个简单的待办页面”，因为你理解的“简单”与 AI 理解的“简单”完全不同。必须明确写出“做什么、不做什么”，将边界划分清楚，AI 才不会随意添加功能。

第二个坑，是忍不住让 AI 一次写完全部代码。把整个页面都交给 AI，得到的内容大概率会揉成一团。更合适的方式是逐个拆分组件，完成一个就核对一个；发现不符合规划便立刻修改，积累到最后再处理就来不及了。

第三个坑，是迷信 AI 能够编写复杂底层逻辑。虚拟列表、复杂动画、自定义拖拽等场景存在数不清的边界 case，AI 手写十个往往有八个带着 bug。遇到这种情况不要硬撑，应当寻找成熟开源库，只让 AI 负责胶水衔接。

最后再谈两句

折腾这么长时间后，我终于明白，Vibe Coding 的本质并非教人如何让 AI 写出更多代码，而是教人怎样与 AI 协作，把它安排在合适的位置。

归根结底，最关键的是三件事：不要一开始就索要代码，先讲清规则和规划；减少让 AI 从零造轮子，多安排胶水拼接工作；持续积累自己的规范，让工具越用越顺手。

当然，这套方法并非万能。面对完全创新且没有现成方案的核心业务逻辑，仍然需要自己编写，AI 最多只能辅助。不过在日常业务开发、编写 demo 和搭建页面等场景中，它确实能帮助我们避开许多幻觉带来的坑。

平时与 AI 协作写代码时，你们有哪些实用技巧，又遇到过哪些离谱的幻觉问题？欢迎在评论区聊聊，也让我学习一些新东西。