跟 AI 写代码越写越乱？我靠这套「Vibe Coding」思路彻底治好了幻觉屎山

说句实话，AI 刚火那阵子，我其实对它写代码这回事儿挺不屑的。看起来像模像样，一跑也确实能跑，真到要维护的时候，那代码比屎山还难啃。直到后来，等你真正摸到 Vibe Coding 的思路，才反应过来：不是 AI 不行，是自己从根上就用错了。

原来第一步我就用错了：规划才是一切

你如果还抱着“跟 AI 说需求就行”的念头，那大概率会踩坑。你想想，你不会让刚入职的新员工第一天就直接上手核心业务，总得先给人看一遍技术规范、捋一遍业务流程吧？对 AI 也是一个道理。

你上来就扔一句“帮我写个 XX 功能”，它只能靠猜——猜你的技术栈、猜你的代码风格、猜你要不要加额外功能，猜来猜去，可不就幻觉满天飞了。

所以 Vibe Coding 的第一步，也是最核心的一步：先做规划，绝对不许 AI 一上来就写代码。

我当时就拿那个待办清单试了试，给 AI 发了这么一段：

遵守胶水编程思维：优先使用成熟方案，避免凭空造逻辑
第一个阶段：只做规划，禁止输出任何代码
1. 确认技术栈：React 19 + Tailwindcss + useState
2. 梳理功能边界：新增待办、删除待办、切换完成状态；不做本地持久化、筛选、拖拽功能
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 协作写代码都有啥好用的小技巧？或者踩过什么离谱的幻觉坑？评论区唠唠，也学点新东西。