轻松上手 Vibe Coding：别让 AI 写屎山代码，先学会怎么指挥它

很多人第一次用 AI 写代码，体验会很割裂。

一开始很爽：

帮我写一个 React 待办清单页面。

AI 很快就吐出一大段代码，看起来组件也有了，按钮也有了，样式也有了。

但一跑，问题来了：

有些代码像真的，但根本跑不起来
有些功能能跑，但逻辑乱成一团
想改一个字段，发现全项目到处都叫不一样
想加一个小功能，结果 AI 又凭空造了一套复杂实现

这时候你会感觉：AI 不是帮你提效，而是在帮你制造新的屎山。

问题不一定是 AI 不行，而是你把它用错了。

Vibe Coding 不是"把需求丢给 AI，然后等它变魔法"。真正靠谱的方式是：

把 AI 当成一个新同事，而不是许愿池。

新同事刚入职，你不会让他第一天就直接改核心业务代码。你会先给他项目背景、技术栈、代码规范、业务边界、模块拆分、数据结构。

AI 也一样。

这篇文章讲的不是"怎么写代码"，而是：

怎么和 AI 协作，写出更靠谱、更可维护的代码。

一、先别急着写代码

新手用 AI 写代码，最容易犯的错误是：

一上来就让 AI 直接实现功能。

比如：

text 复制代码

帮我写一个 React 待办清单页面，支持新增、删除任务。

这个 prompt 看起来没问题，但它其实给 AI 留了太多自由发挥空间。

AI 会开始猜：

要不要本地存储？
要不要接 API？
要不要筛选任务？
要不要拖拽排序？
要不要优先级？
要不要编辑任务？
用什么数据结构？
组件拆成几个？

你没说清楚的地方，AI 就会自己补。

补得好，是惊喜。

补得不好，就是幻觉代码和屎山代码。

所以 Vibe Coding 的第一条原则是：

不要先写代码，先写规划。

二、规划就是一切

写代码之前，先让 AI 读懂项目。

这一步很像公司新人入职。

你不会让一个刚入职的同事直接上生产环境改代码。你会先告诉他：

我们用什么技术栈
项目目录怎么组织
哪些功能要做
哪些功能不要做
数据结构是什么
组件怎么拆
代码风格是什么

AI 也是一样。

如果你用的是 Codex、Claude Code 这类工具，可以先让它生成或阅读项目规划文件，比如：

text 复制代码

/init

或者手动让它创建一个 PLAN.md、CLOUDE.md、TASKS.md。

这些规划文件的作用是：

给每一次后续 prompt 自动提供上下文和约束。

它不是摆设。

它会让 AI 每次动手之前都知道：这个项目的边界在哪里，哪些事情不能擅自扩展。

三、正确示范：先规划，再编码

假设我们要做一个任务清单页面：

用 React + Tailwind CSS 实现一个待办清单页面。

新手可能会直接说：

text 复制代码

帮我写一个 React 待办清单页面，支持新增、删除任务。

更稳的写法应该是：

text 复制代码

遵守胶水编程思维：优先使用成熟方案，避免凭空造逻辑。

第一个阶段：只做规划，禁止输出任何代码。

1. 确认技术栈：
   React 19 + Tailwind CSS + useState

2. 梳理功能边界：
   - 支持新增待办
   - 支持删除待办
   - 支持切换完成状态
   - 不做本地持久化
   - 不做远程 API
   - 不做筛选
   - 不做拖拽排序

3. 拆分模块：
   - TodoInput：输入框组件
   - TodoItem：待办条目组件
   - TodoList：列表容器组件
   - App：状态管理和整体组装

4. 定义数据流：
   使用 useState 存储 tasks 数组。

   数据结构固定为：
   { id, text, completed }

5. 输出完整规划，等待我确认无误后，再分段实现代码。

注意这段 prompt 的关键点：

第一阶段只做规划，禁止输出代码。

这句话很重要。

因为你要先审核 AI 的理解，而不是等它写完 500 行代码再去救火。

四、为什么规划能减少幻觉？

AI 生成烂代码，很多时候不是因为它不会写，而是因为它不知道边界。

比如待办任务的数据结构，如果你不提前规定，AI 可能一会儿写：

js 复制代码

{ id, title, done }

一会儿又写：

js 复制代码

{ id, text, completed }

再过一会儿又变成：

js 复制代码

{ taskId, content, isFinished }

字段一乱，组件之间就开始互相对不上。

所以你要提前规定：

js 复制代码

{ id, text, completed }

这不是细节。

这是项目的"接口契约"。

规划的价值就在这里：

先划定边界，防止 AI 擅自加功能
先拆分模块，防止一坨代码塞进一个文件
先定义数据结构，减少字段幻觉
先审核方案，避免错误方向越写越远
让规划文件贯穿整个开发周期

一句话：

规划不是浪费时间，规划是在给 AI 装护栏。

五、第二步：胶水编程思维

规划解决的是"别乱写"。

胶水编程解决的是"别乱造"。

所谓胶水编程，就是：

能用成熟方案，就不要从零自研底层逻辑；能组装，就不要硬造轮子。

胶水不生产零件。

胶水只负责把零件粘起来。

在 AI 编程里，这个思想非常重要。

因为 AI 最危险的地方之一，就是它很擅长"看起来会写"。

比如你让它写拖拽排序。

它可能真的手写一套：

鼠标监听
坐标计算
元素碰撞
排序算法
拖拽过程样式
边界处理

看起来很厉害。

但拖拽这种东西，边界 case 特别多：

鼠标拖动
触摸屏拖动
键盘可访问性
滚动容器
拖拽过程中列表变化
移动端兼容
动画和焦点管理

如果让 AI 从零手写底层逻辑，很容易出现幻觉 bug。

更稳的方式是：

让 AI 调研成熟库，然后只写粘合代码。

六、错误示范：让 AI 从零造拖拽

比如你这样说：

text 复制代码

帮我给 React 待办清单写一个拖拽排序功能。

这个指令太开放了。

AI 可能会自己实现一整套拖拽系统。

问题是：

底层逻辑复杂
边界情况多
代码量膨胀
后续维护困难
出 bug 你很难判断哪里错了

这就是"从零造零件"的风险。

你不是在用 AI 提效，你是在让 AI 替你挖坑。

七、正确示范：让 AI 先调研，再胶水

更好的 prompt 是：

text 复制代码

遵守胶水编程原则：
绝不从零自研拖拽底层逻辑，优先选择社区长期验证、仍在维护的成熟方案。

当前需求：
给待办列表增加拖拽排序功能。

请先做方案调研，不要写业务代码。

输出内容：
1. React 生态中适合列表拖拽排序的方案对比
2. 每个方案的维护状态、学习成本、适用场景
3. 推荐一个最适合当前 TodoList 的方案
4. 说明为什么不建议手写拖拽底层逻辑
5. 等我确认后，再只写"粘合代码"

这里最关键的是：

先调研，不要写业务代码。

你要让 AI 先证明它选的方案靠谱。

以前很多文章会推荐 react-beautiful-dnd，它确实曾经很流行。但现在要注意：这个库已经被 deprecated，并且 GitHub 仓库已经 archived。

所以更稳的表达不是"永远选某个库"，而是：

先查维护状态，再选成熟方案。

比如现在做 React 拖拽排序，可以考虑 @dnd-kit 这类仍然活跃、文档清楚、生态使用广的方案。

这才是真正的胶水编程：

不是盲目找库。

而是把成熟库、业务组件、数据流，用少量可控代码连接起来。

八、胶水代码到底写什么？

很多人会误解胶水编程，以为就是"不写代码"。

不是。

胶水编程不是不写代码，而是少写底层代码。

你仍然要写：

数据结构适配
组件参数传递
事件回调
状态更新
样式衔接
错误处理

比如拖拽排序里，你不应该让 AI 手写拖拽引擎。

你应该让它做这些事：

text 复制代码

1. 安装成熟拖拽库
2. 用拖拽容器包裹 TodoList
3. 把每个 TodoItem 声明成可排序项
4. 在拖拽结束时拿到 oldIndex 和 newIndex
5. 更新 tasks 数组顺序
6. 保持原有 { id, text, completed } 数据结构不变

这就叫粘合。

轮子别人造好，你负责把它接进你的业务。

九、第三步：让 AI 自我进化

规划和胶水解决的是"当下这一次怎么写得稳"。

但如果你想长期用 AI 写代码，还需要第三步：

让 AI 根据结果不断改进规则。

现在很多 AI 编程工具都有记忆、规则文件、项目规范、harness 流程。

你可以把一次次踩坑沉淀成规则。

比如你发现 AI 经常犯这些错误：

不经确认就加功能
字段名随手改
用已经废弃的库
一次性输出太多代码
没有先读项目结构
不跑测试就说完成

那你就可以让 AI 总结成规则：

text 复制代码

请根据这次开发过程，总结 5 条以后必须遵守的项目规则。
要求：
1. 能直接写入 PROJECT_RULES.md
2. 每条规则都要可执行
3. 避免空话
4. 以后每次改代码前都要先检查这些规则

这就是一种"元方法论"。

你不是只让 AI 解决一个问题，而是在让它优化下一次解决问题的方式。

可以粗略理解成两类 prompt：

Alpha Prompt：告诉 AI 这次怎么干活
Omega Prompt：根据这次结果复盘，优化以后怎么干活

前者负责执行。

后者负责进化。

十、一个完整的 Vibe Coding 工作流

把前面的内容串起来，一个比较稳的 Vibe Coding 流程应该是：

text 复制代码

1. 初始化项目上下文
   让 AI 阅读项目结构、技术栈、已有代码、README。

2. 生成规划文件
   明确功能边界、模块拆分、数据结构、非目标。

3. 人类审核规划
   先确认方向，再允许写代码。

4. 分阶段实现
   每次只做一个小模块，避免一次性生成大坨代码。

5. 遵守胶水编程
   底层复杂能力优先调研成熟方案，不让 AI 凭空自研。

6. 运行验证
   构建、测试、lint、浏览器预览，能跑才算完成。

7. 复盘沉淀规则
   把踩坑点写进项目规则，下一轮继续复用。

这套流程的核心不是"让 AI 更听话"。

而是让 AI 更有上下文、更有边界、更有反馈。

十一、可以直接复制的 Prompt 模板

最后给一套可以直接用的模板。

1. 规划阶段

text 复制代码

你现在是我的项目协作伙伴。

第一阶段只做规划，禁止输出任何代码。

请先阅读当前项目结构和已有文件，然后输出：
1. 当前技术栈判断
2. 需求边界
3. 明确不做什么
4. 模块拆分
5. 数据结构
6. 实现步骤
7. 风险点

等我确认规划后，再进入编码阶段。

2. 编码阶段

text 复制代码

根据已经确认的规划，只实现当前这一个模块。

要求：
1. 不擅自增加规划外功能
2. 不修改已确认的数据结构
3. 保持组件职责单一
4. 输出改动说明
5. 如果发现规划有问题，先停下来说明，不要直接改方向

3. 胶水编程阶段

text 复制代码

遵守胶水编程原则：
优先使用成熟、仍在维护、文档清楚的社区方案。

当前需求是：XXX。

请先调研方案，不要直接写代码。

输出：
1. 可选方案对比
2. 维护状态
3. 适用场景
4. 推荐方案
5. 接入成本
6. 只需要我们自己写的粘合代码有哪些

4. 复盘阶段

text 复制代码

请复盘这次开发过程。

输出：
1. 哪些 prompt 有效
2. 哪些地方 AI 容易跑偏
3. 哪些规则应该写入项目规范
4. 下次遇到类似需求应该如何提示

要求规则具体、可执行，不要空话。

总结

Vibe Coding 不是随便和 AI 聊两句，然后等它自动生成完美代码。

真正靠谱的 Vibe Coding，是一种协作方法：

方法	解决什么问题
先规划	防止 AI 擅自扩展需求
定边界	防止功能膨胀
定数据结构	防止字段幻觉
模块拆分	防止代码变成一坨
胶水编程	防止 AI 从零乱造复杂逻辑
运行验证	防止"看起来完成"
复盘沉淀	让下一次协作更稳

AI 写代码最怕的不是它不会写。

最怕的是它太会写了。

你不给边界，它就会自己补边界。

你不给结构，它就会自己造结构。

你不给规则，它就会每次换一种写法。

所以，不要把 AI 当许愿池。

把它当同事。

先给上下文，再定规则，再拆任务，再写代码，再验证结果。

这才是 Vibe Coding 真正能落地的方式。