前阵子我让 AI 帮我写个 React 待办清单，结果给我整懵了。
输入框里敲了一句 "帮我写个 React 待办页面，支持新增删除"，回车一发，十几秒就给我吐出来一百多行代码。我粘到项目里，哎居然能跑，当时还觉得 AI 真好用。结果想加个样式，点开代码一看人傻了：字段一会儿叫
title一会儿叫text，不知道什么时候偷偷塞了本地存储逻辑，还顺带做了个筛选功能。代码全揉在一个组件里，缩进乱得像麻花，想改个按钮颜色都得找半天。
说实话，那时候我觉得 AI 写代码也就这样 ------ 看起来像模像样，一跑也能跑，真要维护起来比屎山还难下手。直到后来我翻到 Vibe Coding 的思路，才反应过来：不是 AI 不行，是我从根上就用错了。
原来我从第一步就用错了：规划才是一切
我之前总觉得，用 AI 写代码不就是把需求说清楚，等它输出就行？直到我看到个比方：你不会让刚入职的新员工第一天就直接写核心业务，总得先给人看一遍技术规范、捋一遍业务流程吧？对 AI 也是一个道理。
你上来就扔一句 "帮我写个 XX 功能"，它只能靠猜，猜你的技术栈、猜你的代码风格、猜你要不要加额外功能，猜来猜去可不就幻觉满天飞了。
所以 Vibe Coding 的第一步，也是最核心的一步：先做规划，绝对不许 AI 一上来就写代码。
我当时就拿那个待办清单试了试，给 AI 发了这么一段：
plaintext
遵守胶水编程思维：优先使用成熟方案，避免凭空造逻辑
第一个阶段：只做规划，禁止输出任何代码
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 正确姿势
还是拿拖拽排序举例子，两种写法的差距真的天差地别。
错误姿势（从零造零件，高幻觉风险）：
plaintext
帮我写 React 待办清单的拖拽排序功能正确姿势（胶水思维，只用成熟组件）：
plaintext
给待办列表增加拖拽排序
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 协作写代码都有啥好用的小技巧？或者踩过什么离谱的幻觉坑？评论区唠唠，我也学点新东西。