我终于找到了 AI 写代码的正确姿势：从“屎山”到“胶水”，一个 ToDo List 教会我的事
🎯 读完这篇，你也能让 AI 写出清晰、可维护、不瞎编的代码。全程干货，附完整实战复盘。
你有没有经历过这样的时刻——
信心满满地对 AI 说：“帮我写一个 React 待办清单。”十秒后，一大段代码吐了出来，组件、样式、事件处理一应俱全。可你定睛一看：title 和 content 混着用，本地存储和远程 API 全塞在一起，还“贴心地”顺便给你写了套拖拽排序——用 onMouseDown 和 getBoundingClientRect 手撸的那种。跑一下，不是报错，就是交互诡异。你想加个筛选功能，却发现代码已经拧成一根麻花，根本无从下手。
这就是典型的 “幻觉代码 + 屎山代码” 双重暴击。
我曾经也是这么干的，直到遇见 Vibe Coding CN 这份指南。它没有教我一门新语言，却教会了我一套与 AI 协作写出靠谱代码的方法论。严格来说，这不是“如何写代码”，而是“如何指挥 AI 像靠谱的同事一样干活”。
我用这套方法，从一个 ToDo List 小项目开始，彻底重塑了自己用 AI 编程的体验。今天就把这套融进我实战的心法，掰开揉碎讲给你。
一、别把 AI 当代码生成器，它是你第一天入职的同事
很多教程都在说“自然语言编程时代来了”，这话没错，但最容易掉进去的坑是：你把它当成了言出法随的魔法棒。
想象一下：你开了一家新公司，招了个第一天入职的程序员。你既不给他看公司代码规范，也不告诉他要用什么技术栈，张嘴就是“给我写个完整的后台管理系统”。他必定挠头，然后凭自己上一家公司的记忆硬写——最终交付一堆和你想象完全不同的东西。
AI 就是这个新同事。你用得越随意，它写得越随意。
指南里提出一个重要的操作理念：把 Claude Code、Cursor 这类工具当成你的结对编程同事，而不是代码生成器。 既然是同事，你需要：
- 给它看“员工手册”（技术栈、规范、边界）
- 分配明确的任务（乐高式的模块）
- 规定统一的术语（字段名不能它自己发挥）
更关键的是——你得让这些信息在每次对话中都生效。 很多工具支持 /init 或记忆模块，你可以把项目规划作为系统提示词固定下来。这样一来，后续的每一次 prompt 都自动带上全局约束，AI 再也不会跑偏。
这，就是后面三步法里第一块基石。
二、三步法：从此告别幻觉与屎山
整个 Vibe Coding 的协作流程，被我提炼成三个环环相扣的步骤。我把它们完整地用在了 ToDo List 项目里，每一步都有血有肉。
第一步：规划就是一切——先逼 AI 写“入职手册”
不要一上来就让 AI 写代码。你要强制它进入**“只规划，不写代码”**的状态，先把需要做什么、怎么做、不能做什么定得清清楚楚。
这就是我给 Claude Code 的第一个 prompt（注意它的结构）：
帮我写一个 React 待办清单页面，支持新增、删除任务。
先规划，再编码。
第一个阶段：只做规划，禁止输出任何代码
1、确认技术栈：React 19 + TailwindCSS + useState
2、梳理功能边界
- 新增待办、删除待办、切换完成状态
- 不做本地持久化、筛选、拖拽功能
3、拆分模块（乐高组件）
输入框组件、待办条目组件、列表容器组件
4、定义数据流
useState 存储 task 数组，数据结构：
{ id, text, completed }
5、输出这份完整规划，等待我确认无误后，再分段实现代码
你可以把这个 prompt 理解成一份“入职手册”的提纲。它背后藏着四个反幻觉设计：
- 划定边界：明确“不做持久化、不筛选、不拖拽”，AI 就不会擅自赠送功能，防止代码无限膨胀。
- 强制模块拆分：输入框、条目、列表容器三个组件，各司其职。以后读代码、加功能都像翻书，而不是拆盲盒。
- 预先规定数据结构：字段必须叫
id、text、completed，不能是 AI 自己臆想的title或content。从根源上杜绝字段级幻觉。 - 生成-审核-更新闭环：这份规划不是一次性的。每次需求变动，你都要先更新规划，再让 AI 执行。它就是你整个项目生命周期的宪法。
当 AI 把规划输出给你时，你得像产品经理审核 PRD 一样仔细过：边界是否清晰？模块是否合理？字段是否准确？一切确认后，再让它一段段写代码。新手最爱跳过这步直接看代码，但恰恰是这一步，决定了你的项目最终是乐高城堡，还是危房。
第二步：胶水编程——能抄不写，能连不造
当基础功能跑通后，我想增加拖拽排序。如果我还是像以前那样喊：“帮我加个拖拽排序”，AI 极有可能从零手写一套坐标监听、排序算法。代码量爆炸不说，各种边界 case 的 bug 会让你调到怀疑人生。
指南里给了一个极其形象的词：胶水编程。
🧴 胶水本身不创造零件，只负责把现成的零件粘合在一起。你只写衔接、调用、流转的粘合代码，把各个模块联通。轮子别人造好，你只做胶水。
落实到操作上，就是一句话：绝不从零自研底层逻辑，优先选择社区长期验证的成熟开源组件。
我给 AI 的指令变成了这样：
遵守胶水编程原则：绝不从零自研底层逻辑，优先选择社区长期验证的成熟开源组件。
当前需求：给待办列表组件增加拖拽排序
1. 先调研：React 生态成熟的拖拽库，优先选用 react-beautiful-dnd（业内广泛使用）
2. 不要自己手写拖拽底层代码，只做粘合工作
3. 输出内容顺序：
安装依赖命令，把现有 TodoList 组件和 react-beautiful-dnd 进行衔接，只写模块之间适配、数据流转的粘合代码
你猜怎么着？AI 忠实地去“调研”了这个库的用法，然后只生成了寥寥二三十行代码：用 DragDropContext 包裹列表，用 Droppable 和 Draggable 改造每个条目，再在 onDragEnd 里写一个数组重新排序的函数。
全部是胶水，没有一行多余的坐标计算。拖拽顺滑上线，而且代码极简，两周后回去改也一眼就懂。
“胶水”思维远不止拖拽。任何功能——表单校验、状态管理、路由、请求——都优先想想：“有没有一个成熟的库可以胶水一下？” 你指挥 AI 去找那些被验证过千万次的“乐高零件”，然后写最少量的代码把它们拼起来，幻觉和屎山的概率自然成倍下降。
第三步：元反论——让 AI 帮你打磨提示词
到这里，你已经能写出干净的项目了。但还有一层更高级的玩法：让 AI 自我进化，持续优化你们的协作方式。
指南里引入了“元反论”的概念，有点学术，说人话就是：
- α 提示词（Alpha）：你写的、告诉 AI 怎么干活的规范。
- Ω 提示词（Omega）：AI 根据生成结果，对 α 提示词进行评价、打分，提出改进建议，形成自我进化的闭环。
具体怎么用？每次 AI 完成一个功能后，你可以追加一句：
“请复盘我上面的指令，分析哪些表述可能产生歧义，哪些边界没有讲清楚，给出一个优化后的 prompt 版本。”
AI 就会化身为你的私人助教，帮你发现自己都没察觉的模糊点。比如，它可能会说：“你上次没有明确数组的初始值，这次建议加上 初始为空数组。” 或者 “你要求‘切换完成状态’但没有指定 UI 表现，下次可以描述为‘点击文本时添加删除线并改变透明度’。”
你按它建议改进后的 α 提示词，再喂给它自己，产出的质量就会螺旋上升。这就像你身边多了一个专门帮你提高沟通效率的教练，你的每一次 “prompt 工程” 都在迭代进化。
你甚至可以更进一步，把这些复盘总结成一份“协作备忘录”，粘在项目的规划文档里，成为你们团队（你和 AI）的知识库。
三、ToDo List 实战全流程复盘：一个项目走通三步法
理论说了那么多，来看看我是怎么在一个真实项目里一镜到底的。
阶段一：制定规划
我把前面的“只规划，不写代码” prompt 扔给 Claude Code。它吐出一份清晰的 Markdown 规划：React 19 + TailwindCSS，三个组件，{ id, text, completed } 数据结构，无持久化、无拖拽。我逐条审核，确认“不做筛选”这个边界是合理的，字段名没有用 title。
阶段二：分段施工，审核每一块砖
我说：“按照规划，先写 TodoInput 组件。” AI 生成后，我检查它确实是受控组件，onSubmit 时把 text 塞进数组，ID 用 Date.now()。没问题，接着写 TodoItem 和 TodoList。每一步都小步快跑，不让错误堆积。
阶段三：胶水时刻，加入拖拽
基础功能跑通后，我给出了“胶水原则”的 prompt。AI 输出 pnpm install react-beautiful-dnd，然后改写 TodoList：用 DragDropContext 包裹，原来的 map 变成 droppable 里的 draggable，onDragEnd 里写了两行 splice + setTasks。全程没有出现任何 clientX、clientY。拖拽体验丝滑，代码依然清爽。
阶段四：复盘优化——让 AI 自己给自己“找茬
所有功能都落定后，我多做了一步，这步看起来不起眼，但实际效果惊人。
我对 AI 说：“你回头看看我刚才给你的所有指令，挑挑毛病——哪里说得不清楚？哪里容易让你跑偏？给我一个改好的版本。”
这就是所谓的“元反论”，说人话就是：让 AI 复盘你的话，帮你改 prompt。
AI 很快给了我反馈：“你规划里定义了 id 字段，但没说生成规则。如果后续要做编辑功能，ID 不稳定会出 bug。建议补充：ID 用 nanoid 生成。”
就这么一句话，我瞬间反应过来：对，我之前用的是 Date.now()，短时间内连续添加可能会重复。换成 nanoid 就稳了。我立刻把它加进规划文档里，以后这个项目再怎么迭代，ID 这块都不会踩坑。
你体会一下这个过程：
- 我写指令 → AI 执行
- AI 回头看我的指令 → 挑出模糊点 → 我改进指令
- 下次再用改进后的指令 → 生成质量更高
这就像你带一个新同事，他干完活后，跟你说：“老板，你刚才说的第三步其实我没太懂，我猜着做的。下次你可以这样讲，我就不会跑偏了。”你一听有道理，下次就换个说法。几次迭代下来，你们的配合越来越默契，甚至不用多说，他就知道你要什么。
这就是“元反论”的核心——不是你在单方面调教 AI，而是 AI 反过来帮你成为更好的 prompt 作者。 你们的协作会形成一个正向循环，越用越顺手。
整个项目跑下来，代码没有一个多余的 state，没有一个自创的排序算法。即使过一个月再打开，我也能立刻理清脉络，心里不慌。
四、这套方法为什么能根治“AI 代码恐惧症”？
到这里你会发现，过去我们总被 AI 的幻觉和屎山折磨，不是因为 AI 不够强，而是因为我们与它的协作方式太粗放。
把这三步放到一起看：
- 规划 解决了“不知道该做什么”的模糊，用硬边界挡开功能膨胀。
- 胶水 解决了“怎么做才靠谱”的技术选型，用成熟零件替换掉手撸的脆弱。
- 元反论 让你和 AI 的沟通语言不断精进，形成正向飞轮。
更本质地说，这是从 “程序员 + 代码生成器” 模式，切换到了 “架构师 + 协作伙伴” 模式。你不是在写 prompt，你是在给 AI 写一份活页入职手册，然后带着它一起复盘、迭代。
这套方法不挑技术栈。React、Vue、Python FastAPI、Flutter……任何场景你都可以先圈定边界，再找成熟轮子，最后用复盘打磨指令。
写在最后
现在我每次打开 Claude Code，都感觉不像在敲命令，而是在跟一个非常熟悉我项目架构的同事对话。他会提醒我边界，会推荐最好的零件，会用最少量的胶水帮我拼出想要的东西。
如果你也受够了 AI 的胡编乱造和天书代码，强烈建议你去精读 Vibe Coding CN 的原文。我的全部实践都源于那里。
记住这几句话，把它贴在工位上：
- 先写宪法，再开工。
- 只做胶水，不造轮子。
- 让 AI 复盘，越用越强。
现在，你是不是也想去给 AI 写一份包含“测试任务”的入职手册了？ 🚀
如果这篇实战笔记帮你少踩了几个坑，不妨点个赞、收个藏，转发给同样在和 AI “斗智斗勇”的伙伴。你们的每一次“一键三连”，都是我继续深挖最佳实践、记录更多真实踩坑复盘的最大动力。我们下篇文章见！
