关于 Vibe coding 的一点想法

最近调 UI 逻辑时感受很明显。现在很多营销讲出来的 Vibe coding ，做出来的大多还是简单应用工种，就是页面、表单、展示这些，先把轮廓很快铺出来，看上去像是完成得很快。

但一但真的进到工业化细节，问题就会开始隐僻出来。比如交互状态怎么流转、异常怎么处理、相近逻辑怎么复用、模块之间会不会越来越散，这些都不是把页面画出来就算完。

如果是一些没那么重要的应用，用 90% 以下的 vibe coding ，我觉得的确没什么问题，够快，够省事，也够交差。但如果想把 vibe coding 拉到 90% 以上，那就不是一句“能不能生成”这么简单了。

假设一个功能要拆成 10 个关键节点，想让整体成功率达到 90%，那每个节点的平均准确率其实要去到 98.95% 左右，不是 90%，也不是 95%。因为 0.9895 的 10 次方，才勉强接近 0.9 。 

问题就在这里。LLM 生成出来的代码，很多问题是藏着的，不是马上能看到。你想把每个节点从“看起来差不多能用”，一路拉到接近 99% 的稳定度，后面就要花很大的力气去补测、去收口、去反复校正。省下来的开发量，很多时候最后又会从验证和修补上全部还回去。

还有一个很明显的点，LLM 比较容易做局部补全，不太会主动帮你做全局收敛。A 、B 两个模块有接近的方法，它很多时候就是各写一份，先让你跑起来，后面再把冗余和混乱留给人处理。

不过反过来看，如果工作本身就只是为了拿一份薪水，老板也只是以结果导向，只看你有没有按时把东西交出来，那上面这些批判很多时候其实也没什么意义。因为在这种语境下，代码是不是冗余，结构是不是发散，后面是不是难维护，都不是第一优先。先交付，先能跑，先把结果摆出来，反而才是最实际的。

就现有的环境来看，大概就是，工作嘛～

能跑就先算赢了，至于后面是不是一地鸡毛，那是下个版本的 福报 ！！

表面上效率很高，实际上只是把复杂度打包寄给未来。