Epic用Vibe Coding重写启动器，性能翻车引爆开发者群嘲

Epic Games 最近干了件挺有「节目效果」的事：他们发布了一个全新的游戏启动器，号称「史上最快」，但宣传语里却带着一句自嘲——「编程太难了，所以我们干脆用 vibe coding 重写了一个」。这句话本身就够离谱了，更离谱的是成品表现。

Vibe Coding 是什么，为什么会被群嘲

「Vibe coding」是近两年在开发者圈子里流行起来的说法，大意是不写严谨的逻辑、不调试，靠感觉和 AI 生成代码「凭直觉写程序」。它原本带着点玩梗性质，用来调侃那些快速拼凑原型的人。Epic 把它写进官方宣传语，等于主动承认这次重写没走常规工程流程。

问题在于，Epic 不是小作坊。它是做出 Fortnite、掌握虚幻引擎的公司，一个启动器列表页的渲染性能理应是基本功。所以当用户看到启动器滚动卡顿、界面残留上一屏内容时，嘲讽几乎是必然的——有视频创作者直接开喷：「你都做出 Fortnite 了，连个图片列表都显示不明白？」

「Vibe coding」这个概念由 AI 研究者 Andrej Karpathy 在 2025 年初提出，原意是描述一种极端的 AI 协作方式：开发者几乎不看 AI 生成的代码，只凭运行结果「感觉对不对」来决定是否接受，遇到报错就把错误信息原样丢回给模型，直到程序能跑为止。它和传统的「AI 辅助编程」有本质区别——后者仍要求人阅读、审查、理解生成的代码，而 vibe coding 主动放弃了代码审查这一环。这种做法在一次性脚本、周末原型、内部演示工具上确实能大幅提速，但代价是代码的可维护性、边界处理和性能特征完全不可控。Karpathy 本人也强调它适合「throwaway code」，不适合长期演进的生产系统。Epic 把这个圈内梗写进官方宣传语，等于公开承认产品走了非生产级的开发路径，这也是开发者群体反应激烈的原因之一。

实际体验：Linux 上「更光荣」，滚动就是灾难

根据演示视频的实测，这个启动器在 Linux 上的表现反而被形容为「works gloriously」，但原因很黑色幽默：一滚动就暴露性能问题，帧率掉得肉眼可见。

更让人无语的是一个被调侃为「个人最爱」的 bug：你刚看过的内容会永久残留在 UI 上，怎么都消不掉。对启动器这种高频交互界面来说，这属于基础状态管理没做干净。

启动器这类界面的性能瓶颈通常集中在列表虚拟化和渲染管线两处。数百上千个游戏条目如果全部实例化并常驻内存，滚动时每一帧都要重排布局、重绘纹理，帧率就会断崖式下跌；成熟做法是只渲染视口内可见的条目（虚拟滚动），并复用已创建的节点。UI 残留问题则多与状态管理和重绘时机有关：当列表项被回收复用时，若没有在数据绑定时清空旧状态，或没有正确触发失效重绘，上一屏的像素就会「粘」在界面上。这两类问题都不算高深技术，但需要明确的性能预算、真机测试和回归用例来保证。对一个每天被数百万玩家打开的启动器而言，它们恰恰是工程纪律的直接体现。

Steam 的对照：一天之内甩出性能补丁

真正把这件事推向高潮的是竞品反应。Steam 在消息传出后很快推送了客户端性能更新，让启动速度压缩到 5 秒级别。视频作者的评价很刻薄也很精准：Epic 靠 vibe coding，Steam 靠「天赋、技能和投入」。

这场对比之所以有传播力，不在于谁快了几秒，而在于它揭示了一个判断标准——当一个团队把「编程很难」当作卖点而不是要解决的问题时，用户会立刻用脚投票。启动器是玩家每天必开的入口，任何卡顿都会被放大成品牌印象。

这件事真正的启示

AI 辅助编程降低了写代码的门槛，但没降低交付质量的门槛。Vibe coding 适合做原型、做实验、做内部工具，一旦放到面向数百万玩家的正式产品上，缺少测试、性能预算和状态管理的代价会立刻显形。Epic 这次的翻车，本质不是「用了 AI」，而是把工程纪律让位给了营销话术。

对开发者来说，这个案例的价值在于划出一条线：AI 可以帮你写得更快，但性能、稳定性和边界条件仍然需要人来负责。启动器这种「简单」的界面，恰恰是最考验基本功的地方。