Vibe Coding翻车：Epic新启动器速度竟输给Steam

最近，Hacker News 上一则帖子引发了不少技术圈的讨论：Epic Games 新推出的启动器被指速度慢于早已被吐槽多年的 Steam 客户端。更微妙的是，这款启动器据称是用当下流行的"Vibe Coding"方式开发的——也就是重度依赖 AI 生成代码、靠感觉迭代的开发模式。当"AI 提效"撞上"启动器启动要等半天"的用户体验，问题就变得有意思了。

事件回顾：一个反直觉的对比

Steam 客户端长期是 PC 玩家口中的"性能梗"——启动慢、界面重、后台常驻占用高。Valve 这些年虽然持续用 CEF（Chromium Embedded Framework）重构界面，但"Steam 又卡了"几乎是玩家社区的固定节目。

正因如此，当有开发者指出 Epic 的新启动器在冷启动、页面切换、商店加载等环节比 Steam 还慢时，这个话题才具备了对比价值。它打破了一个默认假设：大家都在骂 Steam 慢，所以新做的启动器只要"正常做"就该比 Steam 快。现实却相反。

**CEF（Chromium Embedded Framework）**是多篇文章中提到的关键技术背景。它本质上是一个开源框架，允许开发者把完整的 Chromium 浏览器内核嵌入到原生应用中，用 HTML、CSS 和 JavaScript 来构建桌面端界面。Valve 正是用 CEF 重构了 Steam 客户端的界面层，让商店、社区等大量页面可以用 Web 技术快速迭代。这样做的好处是开发效率高、跨平台一致性好，代价则是引入了一个完整的浏览器运行时：内存占用高、进程模型复杂（多进程渲染），冷启动时需要加载整个 Chromium 内核，自然显得“重”和“慢”。理解这一点很重要，因为 Epic 新启动器同样大量使用 Web 技术栈，两者在架构上并非“原生轻量”对阵“Web 臃肿”，而是两种 Web 技术路线在启动性能上的直接比较。这也解释了为什么“新的一定更快”这个直觉未必成立——决定速度的往往不是技术新旧，而是运行时的实际开销。

Vibe Coding 的诱惑与代价

Vibe Coding 的核心逻辑是：开发者用自然语言描述需求，让 AI 生成代码，自己主要做方向把控和快速验证，而不是逐行推敲。这对原型验证、Demo 演示、小工具开发确实非常高效。

但启动器这类产品有几个特殊属性：

• 冷启动路径长：从进程创建、资源加载、网络请求到 UI 渲染，任一环节的低效都会放大成"感觉很慢"。
• 运行时环境复杂：用户机器配置千差万别，AI 生成的代码往往针对"理想环境"，缺少对边界情况的打磨。
• 性能优化需要具体测量：哪一段慢了、慢多少、为什么慢，这些问题靠"感觉"和 AI 猜测很难定位，必须依赖 profiling 工具和真实数据。

换句话说，Vibe Coding 擅长"从 0 到 1"地跑起来，但不擅长"从 1 到 0.8 秒"的性能压榨。

**冷启动（Cold Start）**是评价启动器类产品最核心的指标之一。它指的是从用户双击图标、操作系统创建进程开始，到界面真正可交互为止的完整耗时，通常包括：进程创建与初始化、本地配置和缓存的读取、动态链接库加载、网络请求（如登录校验、内容分发）、以及 UI 渲染和首帧绘制。之所以叫“冷”，是因为此时没有预热好的缓存和常驻进程，所有开销都要实打实地走一遍，因此最能反映真实体验。与之相对的是“热启动”，即在已有进程或缓存下的再次唤起，耗时通常低得多。这也是为什么单看某些场景“感觉还行”不足以说明问题——用户每天第一次打开启动器时经历的正是最慢的冷启动路径。要把冷启动优化好，必须对上述每个环节分别埋点计时，定位瓶颈，再针对性削减，而不能停留在整体“感觉慢”的层面。

为什么 AI 生成代码容易在性能上吃亏

这不是要否定 AI 编程，而是说清楚它在哪类任务上会暴露短板。

其一，AI 默认选择"能跑通"的实现。 当你要求"写一个启动器界面"，模型很可能给你一个功能齐全但层级冗余的组件树、重复的网络请求、或者没做懒加载的资源引用。功能测试全绿，性能测试没写。

其二，性能问题往往藏在依赖和架构里。 AI 生成的代码倾向于引入现成的库来完成任务，依赖体积、初始化开销、线程模型这些隐性成本，不会被"功能是否正确"的检查捕捉到。

其三，缺乏持续的性能回归意识。 传统客户端团队会有启动耗时埋点、版本对比、性能预算。Vibe Coding 的迭代节奏快，容易跳过这些"不产出新功能"的环节。

**Profiling（性能剖析）**是定位性能问题的标准工程手段，也是本文反复强调“无法被 AI 替代”的能力。它通过采样或插桩的方式，记录程序运行期间各函数、各线程、各系统调用消耗的时间和资源，从而生成火焰图、调用栈耗时排名等可视化结果，帮助开发者回答“到底哪一段慢、慢多少、为什么慢”这三个关键问题。常见的工具有各语言自带的 profiler、操作系统的性能分析器（如 Windows 的 ETW、Linux 的 perf）以及浏览器内核的 DevTools 性能面板。对于启动器这类产品，profiling 能精确揭示是网络请求串行、依赖初始化阻塞主线程，还是资源解压耗时。与之配套的还有“性能预算”和“回归测试”：把启动耗时设成量化目标，每次代码变更后自动比对，防止性能在快速迭代中悄悄劣化。AI 可以生成功能代码，但设定指标、采集数据、解读剖析结果并做出取舍，仍然依赖工程师的判断。

对开发者的实际启示

这起对比事件不该被简单解读为"AI 编程不行"。更准确的结论是：AI 编程的收益和风险，取决于你把性能放在流程的哪个位置。

如果你在做客户端或启动器类产品，可以考虑这几点：

1. 把冷启动耗时当成一等指标，从第一天就埋点，而不是等用户抱怨。
2. 对 AI 生成的代码做性能审查，重点看依赖引入、初始化顺序、网络请求合并。
3. 区分"功能原型"和"发布版本"，前者的标准是能演示，后者的标准是用户等待时间可接受。
4. 用数据而不是感觉做优化决策，profiling 工具的价值在这个场景下依然无法被 AI 替代。

结语

"Epic 新启动器比 Steam 还慢"这个话题的传播力，恰恰来自它的反差感：一个被认为过时的老客户端，跑赢了一个用最新 AI 工作流做出来的新产品。这不是说 Vibe Coding 没有价值，而是提醒我们——当性能成为用户体验的核心组成部分时，AI 提效不能替代工程打磨。

对正在拥抱 AI 编程的团队来说，真正的挑战不是"能不能用 AI 写出来"，而是"用 AI 写完之后，你还有没有能力把它调快"。