如果你看过本系列之前的内容，可能会觉得Vibe coding始终不值一提，也可能会惊叹于开发竟能如此简单？

但它实际上并不简单

我在分享过的工作流中（就是那个庞大的几十个节点的Refly画布），其实删除了很多无用的分支，其数量大约占到了剩余部分的1/2或2/3左右。

比如十几个问答回合之后你会发现AI完全跑偏了，比如你让它修改一个小问题发现它给你整了个巨大的调试功能，比如你纠结于它给你的每次结果都跑不通导致越描越黑……

但始终，它是我们目前仅有的选择。

AI的功能其实还有很大的提升空间，接下来的内容就让我补完这个过程中的痛苦经历，以及从这个痛苦经历中悟出的解决办法。同时我也会延续之前开发“喵卡”应用的后续过程，希望能对你起到哪怕一点点避坑的作用。

来来来，闲言碎语不要讲，且听我表一表~~武松武二郎~~AI这个~~Bitch~~让人又爱又恨的东西。

*（注：我在“喵卡”应用的开发中始终用的是Claude sonnet 4，以下提到“AI”其实主要是指这个模型）*

---

https://appstore.lazycat.cloud/#/shop/detail/iamxiaoe.lzcapp.refly

代码质量不稳定

其实从上次说到的优化喵卡界面开始，事情就开始变得不是那么简单顺畅了。

我发现了一个Claude（或者其他AI也有）的一个比较讨厌的事实：

那就是它没事就会私自优化和重构代码，优化过程中有时就出错，加上记忆偶尔混乱，导致整个文件的功能时好好坏不稳定。然后你如果让它部分修改，它只管加不管减，最后页面可能能用，但代码超极乱……

就……真的是在堆屎山。

加上与copilot模式有区别，在聊天式对话中，AI可能在“记忆”过程中有一些缓存空间专门存储这些代码，这些代码却又是不可见甚至会混乱的（矢量空间？），所以可能几次修改之后，你发现它给你的代码与之前有完全的不同，如果不检查就用，很可能会引起全局的混乱和没法调试的错误。

反过来说，如果你要一直追问或要求它追加修改，AI很可能犯得错更多。

比如对JS文件可能给你完全不一致且有错误的代码，或者忘记之前的某些方法又重写了新的代码；而css文件更糟糕，几乎每次有什么新的界面元素，它只会在文件末尾添加新代码，最终导致同一元素有多个重复且不同的样式块，旧的样式属性会被优先级覆盖但是始终藏在巨大的文件中。

写长文件却无法维持

比如下面这个情况：

我在Vibe开发“喵卡”时，到了开发的中段（经验不足的）我才发现一个问题，就是以我对于应用第一版上线的要求，尤其是在我前一步修改了部分计划删除了一些需求的时候，其实对于后端保存临时文件之类的功能都已经不需要了，第一版本质上说已经是一个静态应用了。

但是AI只管继续完成任务，不断把新的功能甚至调试功能都加在前端主应用JS中，甚至本来可以用模板的HTML代码都直接嵌进JS的变量去用！

自始至终，完全没有提到“某些文件不再需要”、“某段代码可以删除了”之类的提示，所以如果你不细看细想，它生产过的垃圾都会变成你代码中的垃圾。

严重的健忘症患者

而当一个文件写到近两千行左右（虽然让我写可能要长出五倍），AI可能开始忘记以前写好的一些方法，当修改时它会创建新的方法，经常是修改这个问题时改坏了另一个地方。

由于它不提示清理内容，于是我主动要求AI帮我判断和清理不再需要的文件：

我把现有的文件结果同步给你，请先判断一下这些文件中，根据之前的对话历史的变化，有哪些文件是不再用到可以删除的，有哪些是可以再利用的。

同时也要求拆分一些代码，以便更好维护：

是否可以拆分现有的js和css，使文件不要太长，且更易维护？但不要拆分太多，适当即可。

它的回复相当好，也相当专业，看上去也确实记得项目中的每一个文件（也可能因为我导入了文件结构）

但是在后续的开发中，它常常会忘记已经分拆了文件，在改一个功能的时候，它会把之前分拆出去的内容又重新写回到主文件中！

---

相爱-分手-复合

我发现这个过程很像是恋人间的关系，又爱又恨、时好时坏，在一次次的分分合合中互相磨合，最后互相理解得更多……

啊，不行，这太变态了。

难以同步

我有时会手动调整一些样式或功能之类的小地方，开始的时候每改一处都会小心翼翼地把信息同步给它，AI看上去听到了，也确认甚至提出了修改建议。这时通常我会认为它已经“知道”或“记住”了我的改动，然而往往并非如此。

在后续的修改中，它会常常“以它自己的方式”悄悄地把之前的代码写回去，导致我哭笑不得。如果不检查就使用，会发现之前改好的地方又坏了，这太糟了。

由于怕了这种情况，我也会尝试改为只让AI去修改的方式，哪怕一个样式的小修改也让它去做，还要描述好情况，指定位置，甚至解释原因。

但结果呢？几乎没有改善！

我甚至尝试了两次与它同步新的文件，但也并不理想。

AI开始变得像一个顽固而心不在焉的家伙，回答相当不靠谱，开发进入了一种僵局。

自己动手

之前我不知道是因为前后端融合还是对话太长导致了AI忆记过载之类，总之界面是越改问题越多，有时还有整体崩溃的情况。太累了。

要放弃吗？不可能的。

毕竟功能开发已经相当完整了，只是样式和简单JS其实我也行的，我需要的只是调整一下心态，从指挥者变成擦屎官就好了。

于是我开始了占用了整个开发时间一半的手动调试阶段，手动整理和调试了大半的样式表，又从头开始理解整个前端代码的运行逻辑。

好在AI写代码习惯还行，变量命名很规范，必要的注释也都有，除了文件巨长之外没啥大毛病。

于是在这种情况下，我手动修改了大部分的样式和小部分的代码功能。

结果就是我与AI“分手”了，随着改动的增加，“复合”看上去越来越没有可行方法。

聚焦具体问题

在漫长而痛苦的过程中，我一直在思考与AI“恢复关系”的方法，比如让它以方法函数为单位，每次只修改一小个代码块。

比如改动最大的主界面仍然由我手动控制，但某个新功能页面，就可以让它在新的模块中单独开发。

这样即使万一混乱代码积累更多，也只会堆成另一座屎山，用孙悟空的说法就是，担两座山比只担一座山舒服多了。

于是我先借由对于比较独立的设置页面提出修改，把问题先聚焦在在这个功能模块上：

下面请只针对设置页面进行一些修改，首先去掉settings-page的背景色，让其可以透出底色。然后整个settings-header都去掉，它没有实际意义。然后将每个功能的setting-card里的card-icon中的emoji小图标，移动到card-content.h4的标题文字之前，缩小一下，把card-icon容器去掉，以节省页面空间。在section-content的右上角加一个关闭按钮，关闭其实就是重新加载页面，以显示修改过的数据并刷新首页。

然后限制它只能在个文件内部修改：

好的，在我们同步所有文件之前，请先在现有的setting.js中修改，可以新建一个模块也可以修改setting.js，主要目标是完成导入和导出数据模块的功能。可能会需要有一个类似中间格式的json，希望它结构简单易懂易扩展，以后也方便把其他应用生成的内容转换过来。另外导入时要选择增量导入还是完全覆盖，导出则可以整个导出就可以了。

经过这种聚焦，代码质量开始回升，毕竟小段的代码无论对它还是对我，都是更好控制的。

非线性合作

（天才的我想出了这样的标题）

由于进行了任务分拆和聚焦，后面的修改开始变的顺利多了，与AI的“复合”似乎有了些眉目。我发现我还是爱它的，它应该也还爱我。

与此同时，因为虽然我对主JS的代码进行了一些修改，但大致的逻辑其实一直没有动过。所以对于主JS的修改，我会基本上沿用手动调整，即使不会改或需要与别的文件进行联控，我也会让AI只提供“需要修改的地方”的代码片断。

由于已经看过了完整的逻辑，所以修改和替换这些代码片断对我来说还算是能做到。

“喵卡”的项目，从分拆代码到最后基本都跑通，大约经历了十来个问答回合，但是对我来说，所用的时间却和之前只由AI开发相比之下长了更久更久。

不过后来我甚至渐渐习惯了这种片段式修改的方式，因为框架只要不做修改，片断对全局的影响比起AI把整个代码重写来说要小得多。况且对于它给我的片断，我都是在能够自己理解并检查修改后才实际部署的。

---

尝试复合

常言道破镜难重圆，我自己摸索出的“非线性合作”方式虽然可以短期解决眼前的问题，让项目进行下去，但是可以预见未来再全部交回给AI，重新做甩手掌柜的可能性越来越低。

所以还是得想办法与AI酱复合。

同样与恋爱关系相比的话，复合的前提是更多的相互理解，与重建相互间的信任。

好歹也用AI这么久了，该踩的坑都踩过了，该擦的屁股也擦过了，想继续在一起的话不让步是不行的。

避免健忘

完全避免AI健忘是不可能的，但AI作为预测工具，其预测的根本还是基于你提供的物料。那么有没有一种可能，正是你提供的过多物料，包括聊天线程太长，才导致了它思维混乱？

解决的办法也很简单，开始新的聊天线程最方便，但是我不太想用，毕竟之前的线程完整地表现了所有的开发逻辑，也体现了很多BUG及解决方式，如果重新开始，我没有把握它不会犯以前的问题，比如重新给我加入Service Workers。

那么剩下的就是减少物料了，我从对话中去掉了很多多余的参考。比如minidb的使用很简单，而且一直没有出什么错，于是我把相关的资料从参考中去掉了；再比如打包配置文件，其实它们一直存在在列表中，而且已经稳定，于是也减掉。

经过减少“垃圾食品”，AI的记忆力明显恢复，代码质量肉眼可见的回升了。

避免过度优化

由于对需求的理解经常跑偏，AI有时会提出很奇葩的解决方案。

比如一个事件绑定的小问题，在桌面端当窗口缩放，有一些渲染难以靠CSS解决，所以需要重绘整个页面；而在移动端，软键盘打开时实际上窗口会被缩放，于是就激活了页面重绘，导致软键盘又收了回去，无法在表单中添加新的内容，最终发现其实就是判断下设备加两行代码的问题。

但一开始，AI居然给我提供了一个洋洋洒洒上百行的方案，包括专门检查每个事件的方法。

这个问题的解决过程是，我在尝试它的方法不行后，想起来在分析错误的环节里AI提到过窗口缩放会导致软键盘异常，于是自行寻找每个改变窗口大小的方法，以及寻找window.resized的事件监听。找到怀疑的地方后提供给它，询问是否这个问题，果然在我提之后它才意识到，问题迎刃而解。

再比如导出和导入时，本来很稳定的数据结构导出后无法导入，或导入后找不到。原因是minidb的记录识别字段是_id，AI编程时却使用了id。这个本来只是搜场后改改的问题，AI却给我整出了导出前格式判断、导入前格式判断、各种动态检查，甚至把创建数据中用到的每个id都转换成_id。

最后还是我发现问题，是minidb不允许自己设置_id，并提义AI修改后才顺利解决。

利用传统工具

上述id问题的解决方法，是逐个修改和统一变量名，导致变动又多又杂。

AI能给我的方法，是在回复中包含每一个错误的变量名，然后指示我找到并修改。如果遵照它的方法，必然要多花费大量的时间。

其实后来我的方法是在代码编辑器中搜索错的变量名，手动改一下就好了……

再比如几次,同页上有多项内容要修改，可按AI的推荐修改后却不知哪里错了，无法运行下去。

于是我打开git中之前某次功能稳定的提交，与现有文件对比，就知道具体改了哪些地方，这样只要逐个判断修改过的代码块是否是产生问题的根本，然后把看上去没问题的代码保留，把怀疑有错的地方恢复，测试个几下后搞定。

---

最后需要声明一下：以上的绝大部分内容，都是我个人摸索的经验，不一定代表完全有效，每个人也有每个人习惯的方法，不能统一而论。但理论上，使用这些思路是有一定机率可以提高你的AI输出质量并提高效率的。

正如恋爱脑一发作人往往会变得盲目，使用AI也不要拘泥于凡事都靠AI，人类自己的敏锐与直觉是AI不具备的，很多传统的工具也往往比AI有用。打开思路，不执着、不纠结，或许才是玩转AI更好的方式。

《Vibe打金计划》可能会在下一篇后终结，也可能会延续，谁知道呢？