vibe coding时我都在想什么

前段时间接了个做 APP 的活，由于时间紧任务重，设计稿一大堆，手写怕是来不及交付，正好 vibe coding 的风在吹，那就试试吧。于是从架构项目开始，一边和 AI 聊功能，一边喂设计稿，抛开电脑有点旧、风扇有点响，用vibe coding 的形式做项目是真的爽，出代码的速度是不用怀疑的，人的精力也可以分散出来做一些其它的事情。

本来以为整个项目都能 vibe coding 一把梭，但后来光是看对设计稿的还原就有点亿言难尽，更是在有些情况下，AI 似乎是“理解”了设计稿之后，全部重新按照自己的想法给我写了页面样式...

最后没办法，还是得在 AI 写的代码的基础上再修修改改，部分实在实现得离谱的，还得是自己重写。

不仅样式实现得不太行，整体的代码质量也有待提高，如果不明确提示，几乎不会做太多的优化，连很基础的公共组件也不会自动提取出来，回过头看这其实和对设计稿的还原不到位又相关了。

当然，这些问题大多出在我给的提示词不够细致，很多时候我直接设计稿一丢，然后加一句根据设计稿实现对应功能，页面入口在 xxx，就结束了。

所以所谓的一句话让 AI 给实现一个产品能不能实现？答案是能，但是也就限于玩具软件或项目初期仅有 MVP 路径的产品原型，然后让营销号们制造一下焦虑、让卖课党多割几根韭菜、让不懂行的 hr 拿着几个名词开始压榨程序猿/媛；不会真的有人相信可以一句话实现一个微信吧...

后来我在一边等 AI 出代码的时候，顺便发了会呆，我想既然 AI 写代码这么快，虽然质量有待提高，但这总归是时间问题了，那前端程序猿/媛们该怎么办？以后我们的核心竞争力到底是啥？还有必要好好写代码吗？

对于简单问题，我们的处理效率肯定是不如 AI 的，特别是在没有设计稿的场景下 vibe coding，AI 还是可以给出质量不错的输出，毕竟互联网上那么多公开的内容，AI 学到一些好的设计是很容易的，所以我们能看到那么多人在一句话实现一个简单的产品；但是短期之内，AI 的创造性和对复杂问题的处理（例如屎山代码）能力还不太够，真要 AI 去重构屎山代码还保持原有的功能和交互不变，至少现在我得打个问号。在 AI 无法准确理解历史代码上下文，同时难以胜任抽象设计的现在，我还没这么干过，也没敢去干。

所以从这个角度来说，我们不应该再去死磕那些框架原理、算法实现；并不是说他们不重要，而是 AI 在处理这些问题上效率太高了；有空的话可以去了解，但不要一门心思地去钻研，除非是希望写框架、做 core contributor，不然不建议过度花费时间在这些内容上。我们的精力应该花在需求分析、顶层设计、代码抽象能力提升等方面，通过更了解业务需求，更懂项目设计，从而驱动 AI 在人的指导下输出高质量的代码。

面对 AI，我们要做的是改变自己的核心竞争力以避其锋芒。以前的核心竞争力是编码能力、性能优化、项目工程化等，而在 AI 面前，创造力和复杂问题的处理能力才是更能保证自己不被替代的理由。当代程序猿/媛不能妄想在自动化重复性高的流程上打赢 AI，以后的发展必然是程序猿/媛 + AI 协同的模式，真正不可取代的是人类的判断力与创造力，尤其是在产品定义与复杂架构决策中。

至于是否有必要好好写代码，我由始至终都认为这是必须的。我们可以不写代码，但一定要知道怎么写才是好代码。虽然屎山代码一时半会没人敢动，但如果有一个机会能重写，我们能写好吗？能做好抽象设计吗？能保证不会再变成另一个屎山吗？我相信这些事情还是需要人来做，在正经项目中我还是不太敢让 AI 放手一搏，这搏一搏，大概率变不了摩托。

之前刷推特的时候，看到前端明星尤雨溪对现在用 vibe coding 写的项目的吐槽

不过并不是说 vibe coding 不靠谱，而是很多人其实并没有用好 vibe coding，特别是没有技术基础的人，连自己的想法都描述不清楚，更别提用 vibe coding 实现可落地的产品了。

vibe coding 是个有用好用的东西，但就像一把刀，在普通人手里能做到做饭不切手就很好了，但在星级厨师手里却可以用豆腐雕出金缕佛衣。