跟 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字段，模块拆分也合理，确认没问题了才让它开始写代码。

规划究竟要避免哪些问题？

不要认为这一步多余。后来复盘时我发现，短短几百字的规划已经直接挡住了三个最常见的问题：

• 明确限定功能边界，避免 AI 擅自扩充内容，把简单 demo 变成臃肿的半成品
• 预先划分模块，要求 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 随着你的习惯持续迭代。

刚开始时，我每次写代码都要重申规范，比如“用函数组件”“用 Tailwind”“注释不要写太多”，重复多了也很烦。后来我专门保存了一个 md 文件，记录技术栈偏好、代码规范和踩过的坑；每次新建项目，先将这份规范交给 AI，相当于进行一次岗前培训。

之后我又增加了一个环节：每次 AI 完成代码后，都让它自行复盘哪些地方不符合规范、哪些地方可以改进，再把结论写回那份规范文件。这相当于让 AI 自己提出要求，使下一次输出更符合我的习惯。

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

我遇到过的几个坑，你们不要再踩

经过这段时间的使用，我也遇到不少问题，下面选几个最容易踩中的来讲。

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

第二个坑是总想让 AI 一次写完全部代码。若把完整页面都交给 AI，结果很可能是一团混杂的代码。更合适的方式是逐个组件编写，每完成一个便核对一个，不符合规划就立即修改，全部积累到最后再处理便来不及了。

第三个坑是迷信 AI 能处理复杂的底层逻辑。虚拟列表、复杂动画、自定义拖拽等任务有数不清的边界 case，AI 手写十个往往有八个存在 bug。遇到这种情况不要硬撑，应使用成熟开源库，让 AI 只完成胶水衔接。

最后再谈两点

经历这么久的实践后我才明白，Vibe Coding 的本质不是让 AI 编写更多代码，而是学会如何与 AI 协作，把它安排在适合的位置。

归根结底，最关键的是三件事：不要开口就索要代码，先讲明规划与规则；减少让 AI 从零造轮子，多安排胶水拼接工作；沉淀自己的规范，让工具变得越来越顺手。

当然，这套方法并非万能。面对完全创新且没有现成方案的核心业务逻辑，该亲自编写时仍要亲自完成，AI 最多只能辅助。但在日常业务开发、编写 demo、搭建页面等场景中，它确实能让人避开许多幻觉问题。

大家平时与 AI 协作写代码时，有哪些实用技巧？又遇到过什么离谱的幻觉问题？欢迎在评论区交流，也让我学些新经验。