当 AI 应用构建器跑偏了：不推倒重来，让你的构建重回正轨

人们用 AI 应用构建器折腾几个小时后，常常会描述一种特定的感觉。第一个小时很棒。你勾画出一个想法，看着那东西在你眼前自己拼装起来，在你那个做了一半的应用里点来点去，咧嘴直笑。然后到了第三个小时左右，事情开始往下滑。AI 修好了你报告的那个 bug，可它上面那个页面现在看起来不一样了。你让它撤销，它却改了别的东西。到第五个小时，你已经搞不清什么存下来了、什么没存，开始琢磨是不是干脆重新开始算了。

别。AI 应用构建器没坏，它只是跑偏了。这是一个非常可修复的状态，而你根本不用把项目炸掉才能脱身。

“跑偏”到底是什么意思

当一个 AI 应用构建器产出好结果时，那是因为两件事对齐了：它对你想要什么有一幅清晰的画面，它对应用当前长什么样也有一幅清晰的画面。大多数糟糕的构建螺旋，都来自这两者之一变模糊了。

这有点像让一个朋友隔着电话帮你重新布置一个房间。如果他看得见这个房间、又明白目标，那他很在行。可如果他记的是你两小时前发的一张照片里的房间，而目标从那以后已经变了三回，那他就会开始把东西往一些已经不存在的角落里挪。AI 的处境一模一样。它是照着一张快照在干活，而你的快照已经过期了。

你通常会通过三个信号之一，注意到这一点。

信号一：AI 在反复重写同一个东西

你让 AI 修一下登录按钮。它把登录按钮重写了一遍。你又让它修同一个登录按钮 —— 同样的措辞、同样的提示词 —— 它又重写了一遍，跟上次略有不同。再来两轮，这个按钮现在成了第三种颜色，还跑到了页面另一个地方去了。

这是记忆漂移的信号。AI 已经不再把它先前的成果当作地基，而是每一轮都从你的描述重新开始。新版本不一定更糟，它只是不一样 —— 而如果你已经开始喜欢上旧的那个，那不一样就等同于更糟。

遇到这种情况，诀窍是给它打个锚。别再用抽象的话去描述改动（“把登录按钮做得清爽点”），而是用 AI 能跟屏幕上实际存在的东西对得上的话去描述（“按钮现在写着 ‘Sign in’，居中，是蓝色的 —— 这三点都保留，只把边角改圆”）。你是在给 AI 递一张新鲜的快照。能稳定地把非开发者从这个循环里拉出来的，是一句这样的话：“它现在做的是 X —— 只改 Y。“

信号二：每修一个就坏一个

你报告注册表单坏了。AI 修好了表单。你重新加载页面，发现仪表盘的布局变了。你让它把仪表盘改回去。注册表单又坏了。

这就是把人们吓到去重新开始的那个螺旋，也是构建在做到 80% 时被放弃的最常见原因。底下发生的事情是：AI 正在动那些影响范围超出你所要求区域的文件或组件。我最近看一位创始人让 AI”修一下首页的颜色”，结果到处的导航栏都变了 —— 因为驱动这两者的样式存在同一个地方，AI 一下子把两个都改了。它以为自己在修一个东西，实际上是在改两个。

修法是机械式的。用大白话让 AI只改你在意的那个文件、页面或组件，别的一律别碰。大多数 AI 应用构建器在你设下这个约束时都会遵守。“只编辑注册页面。别碰仪表盘布局，别加新文件，别重组任何东西。“如果 bug 出在共享代码里 —— 比如同时驱动表单和仪表盘的那段样式 —— AI 会告诉你。这是有用的信息，而且这是一个比瞎猜好得多的起点。

这里还有一件管用的事：别再累积修复了。如果构建处于一个半坏的状态，先取一个小胜利、把它存下来，然后往前走。AI 应用构建器会很快地把问题叠加起来，因为每一个提示词都把上一个半坏的状态当成了输入。一个干净的存档点，能切断这条链。

信号三：AI 在反复问你同样的问题

三轮之前它问你想要哪个数据库。你说了 Postgres。现在它又问了，只是换了个说法 —— “这些数据需要跨会话保留吗？” —— 你这才意识到，它正在往回漂、漂回同一个决定上。

这通常意味着 AI 丢了项目层面的上下文。它在用最近的几条消息干活，而不是你早先做出的那些架构选择。你也真不好怪它；人在漫长的会议里也会犯同样的毛病。但结果就是：你会一边想盖二楼，一边不停地把地基重新争论一遍。

出路是写一份简短、大白话的项目简介，等 AI 开始漂的时候就把它粘回去。两三句话就够了：“这是一个预约吉他课的网页应用。老师管理自己的可约时间。学生预约一个时段、付款、收到一封确认邮件。用 Postgres 做存储，用 Stripe 做支付。“那一段话，就是 AI 最需要留在手边的东西，也是它最常忘掉的东西。把它当成贴在冰箱上的便条。

一套脱困的小小行动手册

当你撞上那三个信号之一时，下面这套通常管用，按顺序来。你不必全做一遍；第一个能消除症状的步骤通常就够了。

把能用的存下来。在你做别的任何事之前，确保你应用里那些还能用的部分，已经存成了一个版本或一个检查点。大多数构建器都内置了这个；如果你的没有，那就截图、把可见的行为复制到一个笔记里。你会需要一个基准线。

用一句话说出目标。出声地说、写下来、放在某个地方。“我要做的是让注册表单接受一个邮箱和一个密码，并发一封欢迎邮件。“如果你没法用一句话说清楚，那这本身就是 AI 漂移的部分原因 —— 它是在把你自己的含糊，原样照回给你。

隔离出坏掉的那块。告诉 AI 它被允许动哪个页面、组件或功能。要具体。“只编辑注册表单。别改别的任何东西。“如果你没法精确说出什么坏了，那就让 AI 总结一下它上一次改了什么；这往往能把真正在动的那块东西揪出来。

把改动锚定到当前的样子上。描述当前状态和目标状态。“它现在在密码字段下面显示一条红色的报错信息。我想让这条报错信息在用户重新开始输入时消失。“具体的”改动前后”胜过抽象的意图。

拿了胜利就停。这整份清单里最难的一条。当构建回到一个能用的状态时，存档、然后离开几分钟。别立刻就去修下一个。一连叠加四五个修复的构建，往往会进入又一个螺旋。修一个、存档、暂停的构建，往往不会。

什么时候真的该重新开始

有时候，正确的选择确实是从头来过，而认得这些信号是值得的。如果你的项目一直在大幅转向 —— 最初的想法已经不是现在真正的想法了，而应用里反映着三四个不同版本的”这到底是什么” —— 那用一个新提示词干净地重来，比把这团乱麻解开要快。如果你已经迭代得太久，久到自己都不知道项目里到底有什么了，那也一样。沉没成本会让你想接着干下去。明天的你会感谢你做了这个重置。

但那是例外。“这个构建在往歪里走”的日常版本，只要你知道该找什么，五分钟就能修好。AI 没有忘记怎么做应用。它只是忘了你在做的是哪一个。

如果你经历过这样一个螺旋 —— 那些循环、那些连锁的修复、那些反复的同样问题 —— 试着把你那句一句话的项目目标写在一个你能粘回去的地方。这是个小习惯，能让下一个卡壳的时刻短一些。