为什么“人能忍多少延迟”是第一块基石

2019 年我在一个云游戏项目里干过一件蠢事。我们花了两个月，把端到端延迟从 92ms 压到 58ms，测试报告漂亮得像奖状，折线图一路向下，谁看了都得鼓掌。然后我们请了 12 个玩家来试玩，问一句“跟手吗”。8 个人说“还行”，2 个人说“有点飘”，2 个人说“比我家主机差远了”。

我当场就懵了。58ms 啊，物理极限都快摸到了，你还想怎样？

后来我才想明白一件事：我一直在优化我的秒表，玩家一直在用他们的大脑。这俩根本不是同一套度量衡。

这个系列前面 28 篇，我们聊的都是管道：编解码、GPU 虚拟化、边缘节点、ABR、QUIC、私有协议。这些都是真功夫，但你得承认，它们全都服务于管道尽头的那个东西——一颗只有 1.4 公斤、功耗 20 瓦、还特别爱自作主张的人脑。管道修得再好，最后要过的是神经系统的闸门。这道闸门的通过标准，跟你的监控面板上的标准，经常对不上。

举个最日常的例子。你跟玩家说“我们 P50 延迟 45ms”，玩家听不懂，也不关心。他只会说三个词：跟手、飘、黏。这三个词背后其实是三件完全不同的事，对应三种完全不同的神经机制，也需要三套完全不同的工程解法。你把它们混成一锅“延迟优化”，钱就白花了。

所以这篇我想干的事很朴素：把“人觉得卡”这件事拆开，看看里面到底装了些什么。拆完你会发现，游戏策划和工程师天天吵的那些事——震动要不要做、音画能不能错开、预测帧敢不敢用、抖动和均值哪个更要命——其实在神经科学里都有现成的答案，只是没人把它翻译成人话。

顺便说一句，这篇可能是整个系列里最“不技术”的一篇，但它决定你前面 28 篇的技术投入，到底能不能变成玩家嘴里那句“哎，这个可以”。

第 1 层：大脑没有统一时钟，它有三套各走各的表

我们做工程的人有个根深蒂固的假设：时间是一条均匀的线，所有事情都发生在这条线上，只要对齐就行。大脑不这么干活。

视觉、听觉、触觉这三条通路，从刺激发生到进入意识，耗时完全不同。视觉信号要经过视网膜、外侧膝状体、初级视皮层，一路走下来慢；听觉通路的路径短得多，反应快；触觉走脊髓上行，速度也不慢，而且时间分辨率极高——你的指尖能分辨间隔几毫秒的两次触碰，眼睛根本做不到。

如果大脑老老实实按“谁先到谁先处理”，你看到的和听到的将永远对不上，世界会像一部配音烂掉的译制片。所以大脑干了一件很聪明的事：它不等齐，它“重新对齐”。它给慢的通道补时间，给快的通道压时间，最后合成一个“同时发生”的故事。这个过程叫多感官整合，它是自动的，你完全意识不到。

关键在于，这个对齐有宽容区间，而且三个模态的区间宽度完全不一样。业内流传最广的一组数字来自国际电信联盟和欧洲广播联盟的推荐标准，源头是 BBC 那批人做的实验，测的就是“人多大幅度才能察觉音画不同步”：

这张表最反直觉的一行是：音频可以比画面慢一截，但绝不能比画面快。为什么？因为大脑的默认假设是“光速比声速快”。远处打雷，你先看到闪电再听到声音，这是刻在进化里的常识。所以当音频稍微滞后，大脑会自动解释成“哦，这东西离我有点远”，毫无违和感。可一旦音频超前，大脑的解释系统就崩了——它找不到任何现实模型来套，只能报错。你听到的是一声闷响，感觉到的却是“这游戏打击感好假”。

我们踩过的坑就在这。当时为了压总延迟，我们给音频单独开了一条低延迟快车道，视频还在解码队列里排队，音频已经出去了。结果数据上“音画平均偏差 18ms”，漂亮；实际玩家社群反馈是“打怪像在打纸片”。后来把音频人为延迟 30ms 补齐，数据变“难看”了，反馈反而好了。这就是我说的：你的监控面板和玩家的脑子，用的不是一套 KPI。

再说视觉。视觉通路慢，但大脑不会干等着，它会做外推——根据前一帧的运动趋势，猜下一帧物体在哪。这就是为什么 24 帧的电影你看不出卡，因为运动模糊和外推帮你补了。可外推有前提：趋势得稳定。一旦延迟开始抖，画面里的运动轨迹变得不可预测，外推就失效，你会立刻感觉到“飘”。注意这个词——不是“慢”，是“飘”。慢是可以适应的，飘不行。

所以这一层给出的第一条设计结论是：云游戏要做的不是“绝对同步”，而是“稳定地不同步”。一条恒定的 40ms 音画偏差，玩家十分钟就忘了；一条在 0 到 80ms 之间反复横跳的偏差，玩家会一直觉得“这游戏有问题”。这一点跟第 9 篇聊的抖动问题是一条线：抖动杀死的不是带宽，是大脑的预测能力。

第 2 层：手眼之间跑的不是反馈，是预测

很多人对“反应”的想象是这样的：我看到敌人，脑子下命令，手按键，画面响应。一条单向的链路，延迟等于链路各段之和。这个模型是错的，而且错得很离谱。

真实情况是：大脑在发出动作指令的同时，会给感觉系统发一份“预期副本”，告诉它“我接下来要干这件事，你按这个预期去对账”。你抬手去拿杯子，大脑在手臂还没动的时候就已经预测了手会在哪，然后拿真实反馈来校验。这套机制让人类能以极低的感知延迟完成复杂动作——因为大部分时候，你感知到的不是“已经发生的事”，而是“我预测会发生的事，并且它没被证伪”。

这套机制有一个致命弱点：它对“预期的预期”极其敏感。如果反馈回来的结果和预测差一点点，大脑会做微调，你觉得顺；如果差得太多或者差值不稳定，大脑就得放弃预测，退回到“等反馈”的笨办法，那一刻你会突然觉得“怎么这么笨重”。

这就是为什么云游戏的延迟不是“线性叠加”那么简单。本地 16ms 的延迟，大脑早就把它吃进模型里了，你根本感觉不到。云端再多 40ms，理论上总延迟 56ms，但实际体感落差远大于 40ms——因为它把一套已经训练好的预测模型打乱了，大脑得重新建模。重建模的那几分钟，就是玩家说的“不适应期”。

不同品类对这套模型的依赖程度天差地别，这就是为什么“延迟容忍阈值”必须分品类谈，不能一刀切：

看最下面两行。VR 之所以卡在 20ms，是因为它触发了另一套机制：前庭系统。你的内耳在报告“头转了”，视觉在报告“没转”，两套信号打架，大脑的解法是判定你中毒了，于是启动呕吐程序。这不是矫情，是生理防御。所以做云 VR 的人从来不敢说“延迟差不多就行”，差一点人就躺下了。

音游那一行，值得单拎出来说。节奏游戏的判定窗口窄到什么程度？主流音游的“完美”判定通常只有正负十几毫秒的宽度，越难的谱面越窄。也就是说，云游戏额外带来的那 30ms，等于直接把玩家的“完美”判定吃掉，把“完美”降级成“良好”。玩家不会说“你的延迟高”，他会说“我今天状态不好”，然后第二天不来了。这是最阴险的一类流失——玩家自己都不知道为什么走。

格斗游戏这个案子我想多说两句，因为它特别能说明“引擎层预测”和“神经层预测”的关系。格斗圈过去十年最大的技术革命是回滚式网络同步——简单说，就是本地先按“对手大概率会这么动”把画面演下去，等真实输入到了，如果猜错了就把状态倒回去重算。玩家看到的绝大部分时间是“无缝”的。这套东西的本质是什么？就是把大脑本来要干的预测活，搬进引擎里干了。它之所以效果拔群，恰恰是因为它模仿了人脑的工作方式。

那么问题来了：当网络同步已经在引擎层做了 3 帧回滚，云游戏再在传输层叠 30ms，会怎样？答案是预测被套了两层，误差被放大。所以格斗游戏社区对云游戏的态度普遍是“能玩，但别比赛”。这不是偏见，这是他们真的能感觉到。

给策划的落地建议：如果你做的是格斗、音游、硬核射击，云端方案要么别碰，要么在玩法层做“延迟友好改造”——放宽判定窗口、加输入缓冲可视化、把“手感”的反馈做得更响。改玩法比改管道便宜一百倍，这是我血泪换来的经验。

第 3 层：震动不是锦上添花，是大脑认定“这是我干的”的证据

我见过太多团队把震动反馈当成“能砍就砍”的可选项。云游戏尤其容易砍——因为震动信号得从服务器传回客户端，占一条低延迟回程，工程师一看这玩意儿不影响画面，第一个就想动它。

这是一个非常昂贵的误解。

触觉在感知系统里的地位，比我们以为的高得多。它不只是“加个效果”，它是大脑判定因果归属的关键证据。你挥拳打中一个东西，视觉告诉你“打中了”，听觉告诉你“咚”，触觉告诉你“我的手被震了一下”。三条信息在几十毫秒内被绑成同一个事件，大脑才会得出一个结论：这一下是我打出去的。

这个绑定有窗口。研究里管它叫时间绑定窗口，通俗讲就是：只有几个感觉通道的信号在足够近的时间范围内到达，大脑才会把它们缝成同一件事。窗口宽度因任务而异，但普遍落在几十毫秒量级。一旦触觉被甩出这个窗口——比如震动比画面晚了 80ms 才来——大脑会把它缝到下一个事件上去。玩家体验到的不是“震动延迟了”，而是“这游戏的打击感很怪，说不上来哪里怪”。

说个真实的。Xbox 云游戏最早在浏览器上跑的时候，手柄震动是缺席的。社群里的反馈很少直接说“我要震动”，大部分是“感觉像在看别人玩”“少了点什么”。后来官方陆续把震动补上，包括扳机的那种细腻反馈，评价立刻不一样。你说这是玄学吗？不是，这是大脑终于拿回了因果归属的证据。

我们自己在项目里做过一次盲测，两组玩家玩同一段战斗，一组开震动一组关，其余完全一样。结果开了震动那组的主观“打击感”评分高出将近两成，而且他们描述的词汇明显更具体——“重”“实”“有回弹”；关掉那组用的词是“轻飘飘”“像切豆腐”。同一段动画，同一套音效，唯一的差别是几十毫秒的一次抖动。

但触觉也是云游戏里最难做对的一环，因为它的时间预算特别紧。算笔账：游戏逻辑判定命中 → 服务器发出震动指令 → 走网络到客户端 → 客户端下发到手柄 → 手柄马达物理起振。光是马达起振这一下，传统转子马达就要十几毫秒，好一点的线性马达也要几毫秒。加上网络回程，很容易就冲到 60-80ms，正好踩在绑定窗口的边缘上跳舞。

现在行业里大概有三条路：

第一条，客户端本地预测震动。服务器不发明文指令，只发“发生了什么类型的事件”，客户端根据本地已有的动画和状态自己算该不该震。这条路延迟最低，因为根本没走网络往返，但需要客户端和服务器的状态高度一致，一旦预测错了会震错，反而更出戏。

第二条，服务器直发，接受延迟。简单可靠，但基本注定错过绑定窗口，适合那些本来就不靠手感吃饭的品类。

第三条，砍掉。省事，但你要清楚代价是什么——你砍掉的不是特效，是玩家对“操作归属感”的确认。

我的倾向很明确：如果你的游戏是动作、射击、竞速这类吃手感的品类，震动优先级应该排在分辨率之上。真的。玩家能忍受画面糊一点，忍不了打出去像打在空气里。这一点在第 10 篇聊主观画质评估的时候也提过类似的逻辑：玩家对“锐利”的敏感度，远低于对“响应”的敏感度。

第 4 层：人会“适应延迟”，然后产生延迟幻觉

前面三层讲的都是即时的神经机制。这一层讲一个更慢、也更容易被厂商利用的东西：适应。

心理学里有个老概念叫适应水平理论，大意是人判断一个刺激是强是弱，靠的不是绝对值，而是跟自己的参照系比。手伸进 20 度的水里觉得凉，伸进 10 度的水里再回 20 度，就觉得温了。延迟感知完全遵循这个规律。

有实验做过这件事：让玩家在明显有延迟的环境下玩一段时间，再测他们的主观感受和实际表现。结果是——主观不适感在十几分钟内显著下降，操作表现也会部分恢复。玩家的手会自动提前，脑子会自动重编预测模型。这就是为什么很多人玩云游戏半小时后会跟你说“好像还行”。

但适应是有代价的，而且代价经常被忽略：

第一，适应会在抖动面前瞬间崩塌。你适应的是“稳定的 80ms”，不是“80ms 上下浮动 40ms”。后者根本没法建模，大脑会一直处在重新校准的状态，累。这也是为什么有些云游戏平台均值很漂亮，玩家还是骂——他们骂的是那条上下翻飞的曲线。

第二，适应会制造反向不适应。在云端泡了两小时，切回本地，你会有一小段时间觉得本地“太灵敏了”“怎么一碰就动”。这个现象挺有意思，它说明适应是双向的，你的基准线被挪走了。对厂商来说这是个坏消息：玩家一旦习惯了云端，再回本地的不适感，会被归因成“云游戏后遗症”，口碑就这么来的。

第三，也是最微妙的一点：适应会被期望操纵。这就是所谓的延迟幻觉。同样一段流，你告诉玩家“这是低延迟竞技模式”，和告诉他“这是省流模式”，他给出的主观评分能差出一截，尽管两者是同一个流。这不是玩家撒谎，是感知本身被期望调制了——大脑会根据“我预期它应该怎样”来调整实际感受的权重。

说到这，就不得不提那个绕不过去的案例：Stadia 的“负延迟”。

2019 年 Google 发布 Stadia 的时候，抛出了一个说法，大意是通过预测玩家的输入、提前渲染，可以让延迟“变成负数”——比本地还快。这话一出，整个行业炸了锅，社交媒体上嘲讽声一片，什么“物理学不存在了”之类的段子满天飞。

公允地说，这事不能全算吹牛。预测渲染这件事本身是成立的，而且到处都是。格斗游戏的回滚同步就是在预测对手输入，VR 的重投影就是在预测头部姿态，很多云游戏平台也在偷偷做输入预判。技术上，你确实可以在玩家按下按钮之前就把大概率会出现的画面渲染好，从而在统计意义上“抢回”一部分时间。

但它有几个硬边界，而发布会一个字没提：

边界一，预测只在可预测的场景有效。玩家沿着固定路线跑、做固定连段，预测命中率高；玩家突然急停、变向、开镜，预测就废了，废了就得回滚，回滚的瞬间玩家会感觉到一次“顿”。你以为你在消除延迟，其实你在把连续的延迟换成离散的卡顿。

边界二，它放大的是平均值，不是最差值。宣传里那个漂亮的数字是平均意义上的，玩家真正敏感的 P95、P99 那一段，反而可能因为回滚变差。这个逻辑跟第 6 篇聊 ABR 时是一个道理：平均值是给投资人看的，尾部是给玩家受的。

边界三，它没法骗过触觉和音频。画面可以预测，声音和震动很难——你总不能提前放一段还没发生的音效。所以负延迟一旦做过头，最先崩的是多感官的一致性，玩家会觉得“画面跟手了，但声音怪怪的”。

所以我的判断是：“负延迟”这个词是营销，但“用预测换体感”这件事是真技术。问题不在技术，在于把统计上的平均值包装成了物理上的因果，这是把玩家当傻子。而玩家可能说不出哪里不对，但他会用脚投票。

写到这我想跟做独立游戏的同行说句掏心窝子的话：你没有 Google 的服务器，但你有一个它没有的东西——你可以改玩法。与其死磕那 10ms，不如想想你的游戏有没有可能设计成“延迟不敏感”的样子。判定窗口宽一点，前摇给足一点，反馈做响一点，玩家根本不会去查你的延迟曲线。这是小团队最划算的一笔买卖。

参数化设计工具：把神经阈值翻译成可调参数

下面这两张表是我自己在项目里用的，不是标准答案，但至少能让你在评审会上有话说。第一张是延迟预算怎么分，第二张是那些“玄学参数”该定在哪个区间。

先说预算。很多人分配的思路是“各段都压一点”，这个思路是错的。正确的思路是：先按品类定出容忍上限，再倒推各段配额，并且给抖动留出比平均值更多的余量。

第二张表是那些“感官参数”，它们经常被当成美术或音频的事，其实应该写进策划文档：

强调一个我吃过亏的点：不要把音频偏移做成动态自适应。我们当初做过一版，算法会根据网络状况自动调整音画偏移，追求“永远对齐”。结果玩家疯了一半。因为大脑喜欢恒定，讨厌变化。一个固定的 25ms 偏差没人管，一个在 0 到 50ms 之间来回摆的偏差，所有人都觉得游戏坏了。在感知这件事上，“稳定的错”永远优于“不稳定的对”。这句话你要是只记一句，就记这句。

双路径：五步体感自测 + 进阶评测方法论

【初级路径】给你一个五分钟能跑完的体感体检，不用仪器。

第一步，看抖动不看均值。别问“延迟多少”，问“最差的时候有多差”。让测试的人玩二十分钟，中间故意制造一点网络波动（家里有人下电影那种），看他会不会突然骂一句。会骂，说明你的尾部不行。

第二步，测音画。放一段有明确同步点的内容——开枪、脚步声、UI 音效都行。让测试者闭眼听一次、睁眼看一次，然后问“刚才那声枪响，是画面先还是声音先”。他说不出来最好，说得出来你就得查。

第三步，测震动。把震动关掉再开，问他两次的手感差异。如果他说“没区别”，要么你的震动做得太弱，要么延迟大到已经脱绑了。

第四步，测适应后的手感。让他玩十五分钟，然后突然切回本地版本。看他第一反应——如果他愣一下说“怎么这么快”，说明云端延迟已经被适应了；如果他一脸轻松，说明你云端本来就没差多少。

第五步，也就是最容易被跳过的一步：问他在哪个具体动作上感觉不对。“有点卡”是废话，“我二段跳落地那一下总会慢半拍”是情报。会问问题的策划，比会调参数的工程师值钱。

【进阶路径】如果你要做正经的主观评测，有几条纪律。

第一，必须有适应期。人刚上手的前三分钟数据基本是废的，一定要留出十分钟以上的适应窗口再开始打分，否则你会系统性高估延迟带来的负面影响。反过来，如果你在做竞品对比，要保证两边的适应时间一样长，不然就是耍流氓。

第二，做双盲。别告诉玩家哪个是“低延迟模式”。前面说过，期望能直接改变感知评分。你不知道这件事的时候，测出来的数据最干净。

第三，均值 + 分位数 + 主观分三件套一起看。只看均值你会做出错误的取舍，只看主观分你会被个别敏感玩家带偏。三个对不上的时候，通常是你的测试设计有问题。

第四，按品类分组，别混着算。硬核射击玩家和休闲玩家的阈值能差出一倍，混在一起平均出一个“玩家普遍可接受 60ms”，这个结论没有意义。

第五，也是我最想说的：主观评测不是“验证工程指标”，它是独立的一等信息。当主观和客观打架的时候，别急着怀疑玩家，先怀疑你的指标定义。这个思路在第 10 篇讲画质评估时我提过一次，在延迟这件事上，它更成立。因为延迟的终点本来就是人的脑子，不是示波器。

五个我亲眼见过、或者亲自踩过的坑

FAQ

Q1：为什么我玩云游戏半小时后觉得不卡了，切回本地反而不适应？

这就是延迟适应，正常生理现象。你的大脑把云端延迟编进了预测模型，切回来时新模型还没建好，所以短暂地觉得本地“太灵”。一般几分钟就恢复。有意思的是，这个现象对厂商是个隐患：玩家的不适感会被归因成“云游戏有问题”，尽管问题出在切换本身。所以做产品的可以主动引导一句“切换后需要短暂适应”，能省掉一批差评。

Q2：“负延迟”到底是技术还是话术？

七分技术，三分话术。预测输入、提前渲染、VR 重投影、格斗回滚，都是同源的思路，真实存在且有效。但把它说成“比本地还快”，是偷换了统计平均和物理因果的概念。你可以用预测技术，但别信“能彻底消除延迟”这句话，说这话的人要么不懂，要么在卖东西。

Q3：云游戏的手柄震动为什么经常没有，或者慢半拍？

两个原因。一是很多平台为了省事干脆不做，尤其是浏览器端，手柄和网页之间的通信本身就有额外开销。二是做了也可能超时——震动指令要走一趟网络回程，加上马达起振，很容易超过人和画面绑定同一事件的窗口。省钱的做法是客户端根据本地已有的动画状态自己预判该不该震，服务器只负责校正。

Q4：音画不同步多少毫秒玩家才会察觉？为什么音频可以比画面慢？

量级上，音频滞后画面要到一百多毫秒才明显，音频超前画面四五十毫秒就不行了。原因很朴素：现实世界里光速比声速快，大脑默认“声音晚到”是正常的物理现象，会自动解释成距离；而“声音早到”找不到任何现实模型，只能报错。所以工程上宁可让音频慢一点，千万别让它抢跑。这条原则在老式影视制作里已经用了几十年，云游戏只是重新学了一遍。

Q5：做独立游戏，值不值得为云游戏专门做延迟友好设计？

值得，但方向要对。别去改管道，那不是你能控的。你能控的是玩法层的宽容度：判定窗口宽一点、前摇给得更明确、反馈做得更响、关键动作别设计成必须靠十几毫秒精度完成。这些东西做完了，延迟从 40 涨到 70，玩家可能根本察觉不到。反过来说，如果你的核心乐趣就建立在毫秒级精度上——比如硬核音游、竞技格斗——那就老老实实承认云不是最好的载体，别硬上。承认局限比强行适配更体面。