为什么你用 AI 做的应用感觉很慢（以及该怎么办）

你用 AI 做的应用能用。按钮都在该在的地方，屏幕对得齐整，数据存得下来。但就是有哪里不对劲。页面加载要多卡一拍。一个五十项的列表会顿上一秒。点了”保存”，让你等一下，然后再等那么一会儿，然后开始琢磨是不是该再点一次。什么都没坏 —— 它就是感觉慢。

如果你是一个用 AI 应用构建器做东西的非技术型创始人，这是最常见的那种”我不知道哪里出了问题”的时刻之一。好消息是，80% 慢的 AI 应用，慢的原因就那么寥寥几个。它们没有一个要求你去搞懂数据库是怎么运作的。它们全都有你能用大白话让你的 AI 构建器去做的修法。

这篇文章就是那张速查表。

为什么”慢”通常就是四件事

当用户说一个应用感觉慢时，他们几乎从来都不是指”服务器性能不够”。他们指的是这四件事之一：

1. 首次出画很慢 —— 他们点了一个链接，然后盯着一个空白屏幕看上两秒，才有任何东西出现。
2. 一个长列表很卡 —— 滚动、筛选、或者加载”我所有的项目”，比刷 Instagram 还要花时间。
3. 一个操作拖太久、却不告诉他们正在发生什么 —— 他们点了”保存”或”发送”，没有任何看得见的反应。
4. 数据库被问了太多问题 —— 那些要展示来自多处数据的页面，把每一块都单独去取，再把等待时间一层层叠起来。

就这些。几乎每一个我看过的慢的 AI 应用，都是因为这四个原因之一而慢的。下面讲讲怎么认出每一个，以及该让你的构建器去做点什么。

慢的原因 #1：首次出画

它看起来是这样：你点了一个指向你应用的链接，地址栏读条转完了，但页面还会白上一两秒，才有任何东西出现。

通常的成因：应用在给你看任何东西之前，先把它可能用得上的每一段 JavaScript 都加载了。AI 应用构建器倾向于打包打得很大方 —— 宁可多带上也别漏掉 —— 而你加的功能越多，那个包就越大。

该让你的 AI 构建器做什么：*“首次页面加载感觉很慢。能不能按路由把 JavaScript 包拆开，好让首页不用去下载整个管理后台那部分？“或者更简单地：“给首页之外的路由加上懒加载。“*大多数现代框架用一两行配置就能支持这个。AI 知道怎么做 —— 你只需要开口要。

顺手再问一句：*“落地页上有没有什么大图是我们可以优化的？“*一张 4 MB 的主视觉照片，比任何代码问题都更会拖垮体感速度。

慢的原因 #2：长列表

它看起来是这样：你有一个列表 —— 项目、联系人、帖子，什么都行 —— 一旦它超过四五十项，滚动就开始磕磕绊绊，或者筛选要明显顿上一拍。

通常的成因：应用把每一个条目都一次性渲染到了页面上，连你看不见的那些也渲染了。十个条目时这没问题。五百个时，浏览器就卡死了。

该让你的 AI 构建器做什么：*“项目列表在条目很多时会变慢。我们能加上分页吗，或者把列表虚拟化，让只有可见的那几行被渲染出来？“*分页（“每页显示 20 个，配上下一页/上一页按钮”）是最容易的修法。虚拟化（“只渲染随着用户滚动而出现在屏幕上的内容”）感觉更顺滑，但稍微多费点工夫。哪个都行。

如果这个列表还带搜索或筛选：*“搜索筛选能不能放到服务器上做，而不是在浏览器里做？“*服务端筛选意味着浏览器任何时候都只攥着匹配的那些行，而不是整个数据集。

慢的原因 #3：无声的等待

它看起来是这样：你点了”保存”或”发送”或”生成”。看不出有任何事发生。两秒后，屏幕更新了，你才意识到它这整段时间一直在干活。

通常的成因：应用在做实打实的活儿 —— 往数据库里存、调一个 API —— 但 AI 构建器没加上一个加载状态。所以从你的视角看，这一点根本没干任何事。

这其实不是一个性能问题。它是一个体感性能问题，而这类问题往往比真问题更让人难受。一个没有任何反馈的 200 毫秒操作，感觉比一个带着转圈图标的 2 秒操作还要慢，因为用户的大脑处在一片漆黑里。

该让你的 AI 构建器做什么：*“给每一个触发操作的按钮加上加载状态。在它干活时显示一个转圈图标或’保存中…’的文字，并把按钮禁用，好让用户没法连点两下。“*这是任何应用里性价比最高的那个性能修法，而且它几乎不花什么成本。

顺手再问一句：*“对于那些我们已经知道结果会是什么的操作，我们能不能乐观地更新界面 —— 立刻把变化显示出来，如果服务器拒绝了就回滚？“*乐观更新正是社交应用上那个”点赞”按钮即便你手机信号糟透了也感觉瞬时响应的原因。

慢的原因 #4：话痨数据库

它看起来是这样：一个展示条目列表、每条还带着额外信息的页面 —— 比如一个项目列表、每个项目还显示里面任务的数量 —— 比一个普通列表的加载要慢得多。

通常的成因：页面先用一个查询把那些项目加载出来，然后又用一个单独的查询去加载每个项目的任务数。十个项目？十一个查询。一百个项目？一百零一个。这叫做”N+1 查询”，也是 AI 做的应用里最常见的数据库性能 bug，因为 AI 优化的是读起来清晰的代码，而不是跑起来高效的代码。

该让你的 AI 构建器做什么：*“这个页面每个条目都在发一个查询。我们能不能用一个查询就把所有相关数据取回来 —— 一个 join 或者一个聚合？“*这两个词是什么意思你不用懂。AI 懂。把那个慢的页面给它看，说一句”我觉得这里有个 N+1 问题”，通常就够了。

你不靠任何工具也能发现 N+1 问题：打开那个页面，数一数它要花多久，然后往底层那个列表里加进十倍多的条目。如果页面现在慢了十倍，你就碰上了一个 N+1。如果它只慢了一丁点，那就没有。

关于过早优化的一句话

新手创客会掉进一个陷阱：在还没有任何人用这个应用之前，就想把每一个页面都做快。别。

性能优化是有真实成本的。给一个永远只会有二十行的列表加分页，是白费工夫。优化一个一天只加载两次的页面，是白费工夫。给一个只有三个用户的内部工具拆包，是白费工夫。修一个慢页面的正确时机，是当你能说得出是哪个页面、哪个操作、以及哪个被它惹烦了的人的时候。

所以先正常地把它做出来。交付上线。看它是怎么被用的。当某样东西让一个真实的人 —— 包括你自己 —— 感觉慢时，把症状对应到上面那四个类别之一，再去要那个具体的修法。你会得到一个更快的应用，而不必为你的用户永远不会留意到的基础设施搭上一个礼拜。

怎么跟你的 AI 构建器谈速度

一个管用的套路：描述症状，而不是解决方案。AI 在挑出正确修法上比你以为的要强得多，只要它知道究竟哪里不对。

可以照抄的好指令：

• “我打开设置页面时，要过一秒才有任何东西出现。我们能弄清楚是什么在挡着首次渲染吗？”
• “仪表盘比首页加载得还慢，尽管它显示的数据更少。我们能看看它是怎么取数据的吗？”
• “我在资料页上点’保存更改’时，有两秒钟什么都没发生。加上一个加载状态，并确保按钮没法被连点两下。”
• “用 500 个假条目测试这个列表，告诉我慢在哪里。”

最后这一条被低估了。让 AI 自己生成测试数据、再亲自去试那个页面，是你能做的最有用的事情之一。它常常会在你的用户之前就找到那些慢点 —— 并在同一条回复里把修法也提出来。

AI 做的应用里的速度，无关魔法。它无非是搞清楚你的问题落进了那四个桶中的哪一个，再用清晰的话去要那个对的修法。做到这一点，“感觉很慢”就会靠着寥寥几个小而有的放矢的改动变成”感觉还行” —— 而不是一次重写。