跟 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 协作写代码时，有哪些实用技巧，或者遇到过什么离谱的幻觉问题？欢迎在评论区交流，我也想从中学些新东西。
