聊聊Cursor+VibeCoding

最近两个月一直在主力用Cursor+VibeCoding的方式来帮助完成的工作，感觉差不多有80~90%的代码都是Cursor帮忙完成的。算不上这方面的专家，但是可以聊一下VibeCoding的感受。目前客户端DEMO项目上的实现方案是RN，基本上就是偏前端的一套解决方案，选择这个方案主要的一个目的也是VibeCoding，因为模型生成前端界面比生成原生界面的效果更好，而且这个方案开发界面更快。我自己体验下来在写一个复杂DEMO上，确实RN的开发效率高，不光是VibeCoding效率高，而且调试速度极快，保存源码就能直接看效果，比原生编译快非常多，以及VibeCoding产出的界面还挺像模像样的。不过现在这个方案还没有完全在正式项目上完全铺开，所以不好说在完全还原设计稿上的表现如何。VibeCoding过程也遇到一些问题。1. RN在0.69前后有两套不同的桥接架构。我在用VibeCoding生成代码的时候，有的时候模型会把这两套架构弄混淆，对于一个没搞过RN的开发者来说肯定不知道这些背景信息，所以有的时候代码生半天也运行不了。最后还是看了文档才明白是怎么回事。2. 很多VibeCoding的网站比如bolt.new，并不擅长处理RN中版本依赖问题，Expo对应React哪个版本有的时候搞不明白，以及有的时候引入的三方库和Expo的版本不兼容也会导致这VibeCoding的网站卡半天。卡半天的后果就是花钱买大量的Token。所以我觉得这些网站的收费有的时候显的非常不合理，也是社区抱怨很多的问题。3. 想要在RN里面集成自己开发的后端服务是很麻烦的事情，如果只是纯纯Vibe不看代码实现，是很难集成的，我司的实习生差不多花了好几天都没有彻底搞定自定义后端集成的问题，像Lovable 整合了Supabase这些服务商的API还好一些，我估计是模型针对这块儿单独优化了。4. 所以还是需要懂开发的人员接入完成最后一公里的任务，大部分时候是我来做这部分工作，这项工作又名VibeCoding善后工程师，需要深入到内部去尝试解决问题。而不是像实习生一样，经常改了A，B出问题了。要尝试修改BUG，还是要定位到问题，把精准的上下文扔给模型去解决。这算是准确率和效率的折中，而且至少整个项目是可控的。5. AI 写代码不会主动重构代码，一个页面上不断加功能，这个页面很快就突破一两千行，看起来非常费劲，我专门问了下公司前端大佬，通常他们都会拆组件，让文件大小变可控，所以需要在觉得需要重构的时候，让AI主动去给重构代码。还有就是很多别的页面已经有的方法，在实现功能的时候不会把方法单独提取出来，自己实现一个一模一样的方法，还是需要在Prompt里显式的说明。6. 幻觉。很多时候AI会给一些库编造出来根本不存在的API，尤其是一些相对比较冷门的库。以及有的库如果变化很快的话，AI很多时候会用过时的API。这需要我们显式的在Prompt里把工程源码里类的整体定义贴进去，让AI看到最新的代码之后，这个问题能改善很多。7. 胡编实现方案糊弄开发者。在实现流式响应服务端数据的时候，AI 给客户端做的流式方案并不是真流式（SSE），而是它自己在里面加了一个延迟打字的逻辑... 过了好久我才发现原来是在糊弄我。8. 简单问题复杂化。同事在实现一个后端功能的时候，命名框架有现成的解决方案，但是AI不用，非要自己在哪造轮子，但其实使用框架的方案实现就很简单，但是AI用自己的轮子半天也写不对。这种时候通常需要给AI一个示例作参考，否则AI的实现就会跑的很偏。暂时能想到就这么多... 感觉想要完整靠谱的交付没有程序员的介入还是不够的，现在在网上看到很多非技术出身的人通过 VibeCoding 开发的带数据存储相关的应用，我还是不太敢用，万一哪天自己存了半天的数据被搞丢了，都没地方说理去。我们公司算是在VibeCoding中走的比较靠前了，主要还是老板感想敢干... 很多时候团队还是在尝试探索出一套更高效的工作流，老板的思路是想办法让更多非工程师出身的人来参与到VibeCoding中来提升整体的开发效率。但是过去两个月的感受是，做点简单的应用（主要数据存储、数据结构简单）还行，但是复杂度稍微高一点的应用就得有人介入，以及最后那个负责善后的工程师承担了所有... 我甚至感觉善后工程师有点像是技术支持的角色了。对于搞技术的人来说， VibeCoding 对于技术水平比较有限，像我VibeCoding了2个月的RN，对很多JS的语法还是很不熟悉（我也在想也许以后的变成时代压根不需要关注语法了？），不过有一点好处就是确实能从执行中抽离一些精力出来，去关注整体架构层面的问题。先就这么多吧。