1
00:00:00,100 --> 00:00:06,432
本内容改编自小山学堂《学 AI 产品，从入门到精通》，为二次演绎配音版。

2
00:00:06,382 --> 00:00:10,360
这一集要解决的，是一个特别委屈的问题。

3
00:00:10,360 --> 00:00:21,093
你的监控面板上，接口响应四秒多，P99 也压在及格线以内，工程团队该做的优化都做了，可用户还是在评论区骂慢，续费还是掉。

4
00:00:21,093 --> 00:00:23,004
问题到底出在哪。

5
00:00:23,004 --> 00:00:26,887
答案是，你和用户在看两块不同的秒表。

6
00:00:26,887 --> 00:00:33,822
服务器那块表记的是物理事实，从请求发出到完整答案落地，五秒就是五秒。

7
00:00:33,822 --> 00:00:44,314
用户那块表记的是心理事件，从按下发送开始走，看见第一个字就停，中间没有刻度、没有解释、没有东西看，于是它被估长了。

8
00:00:44,314 --> 00:00:48,750
打分、续费、卸载，全都发生在用户那块表上。

9
00:00:48,750 --> 00:00:51,490
为什么产品经理要关心这件事。

10
00:00:51,490 --> 00:00:56,574
因为 AI 产品有三个天生毛病，慢、会错、不透明。

11
00:00:56,574 --> 00:01:01,021
推理要时间，幻觉压不净，用户看不见它在干嘛。

12
00:01:01,021 --> 00:01:08,257
工程手段短期内只能缓解这三样，但用户的评价由感知产生，而感知是可以设计的。

13
00:01:08,257 --> 00:01:17,884
你在前面学到的流式输出、模型路由、语义缓存、进度汇报，每一个除了是工程手段，还有一重心理学开关的身份。

14
00:01:17,884 --> 00:01:28,185
这一集要给你的，就是把用户那块表的走时规律摸清楚，然后告诉你哪些改动不用动模型、不用加机器、账单便宜一个量级。

15
00:01:28,320 --> 00:01:30,373
先做个思想实验。

16
00:01:30,323 --> 00:01:38,159
同一个问题，同样五秒出完整答案，只改这五秒里给用户看什么，四种呈现并排跑。

17
00:01:38,159 --> 00:01:40,984
第一种空白冻结，什么都不给。

18
00:01:40,984 --> 00:01:44,397
第二种转圈等待，告诉你它还活着。

19
00:01:44,397 --> 00:01:47,402
第三种流式输出，先给一部分。

20
00:01:47,402 --> 00:01:51,020
第四种步骤外显，让你看见它在干嘛。

21
00:01:51,020 --> 00:01:54,037
物理时长一模一样，都是五秒。

22
00:01:54,037 --> 00:02:01,116
跑完之后你会发现，多数人最难受的是第一种，最舒服的是第四种，体感差出两三倍。

23
00:02:01,116 --> 00:02:06,645
空白除了难受，还有一笔隐藏的账，它会放大你对时长的估计。

24
00:02:06,645 --> 00:02:17,534
感知时间研究里有个说法叫前瞻计时，你一边等一边盯着时间走，注意力押得越多，主观时长就膨胀得越厉害，紧张情绪再往上拉一截。

25
00:02:17,534 --> 00:02:23,280
Zakay 与 Block 提出的注意闸门模型，是这条规律最常被引用的解释。

26
00:02:23,280 --> 00:02:32,871
他们从一九九零年代起做了一系列实验，无反馈与高唤起状态下的时长高估，在前瞻计时实验里被反复复现。

27
00:02:32,871 --> 00:02:37,042
把这条规律记牢，你会重新理解一类用户反馈。

28
00:02:37,042 --> 00:02:45,816
客服工单里那些说卡了半天、半天没反应的描述，多数时候后台日志显示请求早就正常返回了。

29
00:02:45,816 --> 00:02:50,191
不是用户在撒谎，是用户那块表确实走了更久。

30
00:02:50,191 --> 00:02:53,784
你拿日志去对质，只会让矛盾升级。

31
00:02:53,784 --> 00:03:02,486
还有个更狠的验证，让你凭体感掐八秒，掐的过程里不给进度、不给转圈、不给文案，尽量别在心里数拍子。

32
00:03:02,486 --> 00:03:06,837
多数人按下停止的时候，实际才过了六秒出头。

33
00:03:06,837 --> 00:03:11,801
落地到数据上就是这句，服务器记五秒，用户记六秒半。

34
00:03:11,801 --> 00:03:16,248
无反馈等待的高估误差，实验里两三成很常见。

35
00:03:16,248 --> 00:03:25,611
所以你产品的体感延迟，比监控面板上的 P99 更糟，而这段差距不是后端造成的，是界面造成的。

36
00:03:25,750 --> 00:03:31,589
既然秒表开在用户心里，工程预算就要花在他真的在计时的那段时间里。

37
00:03:31,539 --> 00:03:33,775
于是有了这第二个实验。

38
00:03:33,775 --> 00:03:42,969
一台聊天机器人，总时长锁死五秒，只让你动一个参数，首字时间，也就是从发送到看见第一个字的那一段。

39
00:03:42,969 --> 00:03:46,323
拖滑块，重放，看体感分怎么变。

40
00:03:46,323 --> 00:03:48,162
结果很反直觉。

41
00:03:48,162 --> 00:03:54,556
把首字从五秒压到零点五秒，总时长一秒没省，体感分翻了两三倍。

42
00:03:54,556 --> 00:04:00,301
反过来，首字不动，总时长从五秒压到四秒，这根表几乎不动。

43
00:04:00,301 --> 00:04:02,645
原因就在第一块表身上。

44
00:04:02,645 --> 00:04:07,236
用户的开表点是按下发送，收表点是看见第一个字。

45
00:04:07,236 --> 00:04:14,255
首字之后，他的注意力就交给了阅读，边读边到的内容，几乎不被记进等待的账本。

46
00:04:14,255 --> 00:04:22,500
所以工程团队盯着总时长的 P99 优化，用户只记首字，两块表对不上，差评就从缝里钻出来了。

47
00:04:22,500 --> 00:04:27,368
实验里那根首字杠杆的长度，就是这条怪癖给的。

48
00:04:27,368 --> 00:04:30,265
这条规律直接改排期优先级。

49
00:04:30,265 --> 00:04:37,008
接流式、先出提纲、分段返回，这三件事的性价比全部排在升级机器前面。

50
00:04:37,008 --> 00:04:40,505
还有一条更隐蔽的，错误要当场兜住。

51
00:04:40,505 --> 00:04:46,094
时间记忆是事后重建的，情绪越糟，重建出来的等待就越长。

52
00:04:46,094 --> 00:04:55,325
同样一次五秒等待，结局是答得挺到位，回忆里的时长约四秒；结局是答非所问，回忆里的时长会被拉长。

53
00:04:55,325 --> 00:05:00,938
所以延迟和幻觉在差评里常常挤进同一句话，又慢又蠢。

54
00:05:00,938 --> 00:05:07,825
答案质量的问题会连坐到速度头上，反过来，好答案也能替你把慢遮掉一截。

55
00:05:07,990 --> 00:05:12,831
排队心理研究里有三条定律，对 AI 产品最要命。

56
00:05:12,781 --> 00:05:15,546
第一条，不确定的等待更长。

57
00:05:15,546 --> 00:05:22,228
同一个界面，左边写生成中请稍候，右边写预计二十秒、已完成百分之四十。

58
00:05:22,228 --> 00:05:28,394
你盯十秒试试，左边那块大概到第十秒，你就开始怀疑它是不是挂了。

59
00:05:28,394 --> 00:05:29,957
原因不复杂。

60
00:05:29,957 --> 00:05:34,296
没有刻度的时候，大脑只能按最坏情况焦虑。

61
00:05:34,296 --> 00:05:40,762
有刻度，大脑就能安排自己，还剩多少、要不要先去干点别的，心里有数。

62
00:05:40,762 --> 00:05:43,130
迪士尼把这个用到了极致。

63
00:05:43,130 --> 00:05:50,149
排队入口的牌子上写着从此处起四十分钟，而实际多数时候三十分钟就排到。

64
00:05:50,149 --> 00:05:53,490
游客非但不恼，反而觉得赚了十分钟。

65
00:05:53,490 --> 00:05:56,748
这里有个硬原则，预估宁高勿低。

66
00:05:56,748 --> 00:06:01,435
报四十分钟实际三十分钟是惊喜，反过来就是背叛。

67
00:06:01,435 --> 00:06:04,680
第二条，没解释的等待更长。

68
00:06:04,680 --> 00:06:08,238
裸转圈只回答了一个问题，它还活着吗。

69
00:06:08,238 --> 00:06:11,243
它回答不了第二个问题，它在干嘛。

70
00:06:11,243 --> 00:06:22,577
而大脑有个坏习惯，凡是得不到解释的沉默，它会自动脑补最坏的剧本，是不是卡死了，是不是把我的请求丢了，是不是在偷偷跑什么不该跑的东西。

71
00:06:22,577 --> 00:06:24,728
换成另一句话试试。

72
00:06:24,728 --> 00:06:29,608
正在检索十二篇文档，已读完七篇，正在交叉比对。

73
00:06:29,608 --> 00:06:33,779
秒数一秒没变，焦虑值肉眼可见地往下掉。

74
00:06:33,779 --> 00:06:37,060
沉默变成直播，等待就有了叙事。

75
00:06:37,060 --> 00:06:41,147
对 AI 产品来说，这根杠杆几乎不要钱。

76
00:06:41,147 --> 00:06:49,308
Agent 的工具调用日志、检索进度、阶段切换，本来就是调试信息，搬上台面就是体验资产。

77
00:06:49,460 --> 00:06:52,691
第三条定律，空手的等待更长。

78
00:06:52,641 --> 00:06:55,814
白屏三秒，体感能顶别人十秒。

79
00:06:55,814 --> 00:06:59,239
眼睛没有落点，秒表就走得格外慢。

80
00:06:59,239 --> 00:07:07,941
反过来，提纲先出来，结论、依据、风险，用户边读边确认重点，手里不空，秒表基本就停了。

81
00:07:07,941 --> 00:07:11,823
把三条定律叠起来用，效果是这个样子的。

82
00:07:11,823 --> 00:07:16,860
用户让 Agent 审一份五十页的采购合同，全程约二十五秒。

83
00:07:16,860 --> 00:07:22,196
原始界面只有一个干巴巴的分析中，用户焦虑值拉到九十二。

84
00:07:22,196 --> 00:07:24,167
现在加四个动作。

85
00:07:24,167 --> 00:07:27,641
第一个动作，给预估时长且报偏高。

86
00:07:27,641 --> 00:07:36,655
按历史耗时的偏高值报预计三十秒左右，二十五秒完成是白赚的惊喜，等待从无底洞变成倒计时。

87
00:07:36,655 --> 00:07:39,648
第二个动作，阶段性汇报进展。

88
00:07:39,648 --> 00:07:47,340
读取合同十二页、提取付款与违约条款、交叉核对双方义务，每换一个阶段说一句在干嘛。

89
00:07:47,340 --> 00:07:50,021
第三个动作，先流式出提纲。

90
00:07:50,021 --> 00:08:00,165
五秒先给分析框架，付款条款账期九十天偏长、违约金上限缺失、知识产权归属含糊，用户边读边确认。

91
00:08:00,165 --> 00:08:04,528
第四个动作，给一个转后台加完成通知的出口。

92
00:08:04,528 --> 00:08:09,985
这四个动作还有个被忽略的副作用，中间态本身就在给能力背书。

93
00:08:09,985 --> 00:08:20,429
用户看到读取合同十二页、交叉核对双方义务，他会推断这个系统真的在读、真的在比，而不只是在等一个大模型吐字。

94
00:08:20,429 --> 00:08:27,244
过程展示的第二重价值就在这里，它同时是焦虑的解药，也是能力的证据。

95
00:08:27,244 --> 00:08:34,516
任务一毫秒没变快，二十五秒还是二十五秒，但用户从干等变成了盯着它干活。

96
00:08:34,516 --> 00:08:41,222
他知道要等多久，知道它在干嘛，手里有东西读，还握着一个随时能走的出口。

97
00:08:41,222 --> 00:08:46,835
多数人未必点那个出口，但知道能走，等待就有了退路。

98
00:08:46,990 --> 00:08:50,714
讲完三条定律，再看怎么给任务定档。

99
00:08:50,664 --> 00:08:59,930
人机交互研究里有组用了几十年的阈值，出自 Nielsen 一九九三年的可用性工程，上溯到 Miller 一九六八年的工作。

100
00:08:59,930 --> 00:09:02,707
零点一秒内，感觉是瞬间。

101
00:09:02,707 --> 00:09:05,495
一秒内，思路不会被打断。

102
00:09:05,495 --> 00:09:08,488
十秒，是专注等待的极限。

103
00:09:08,488 --> 00:09:11,048
三道线切出三档策略。

104
00:09:11,048 --> 00:09:18,127
一秒以内，直接出结果，不要加任何过渡动画，动画本身就是在浪费用户的时间。

105
00:09:18,127 --> 00:09:27,563
一到十秒，必须流式，配上进度或者阶段说明，这是绝大多数 AI 功能待的区间，也是这一集所有技巧的主战场。

106
00:09:27,563 --> 00:09:31,301
超过十秒，别修文案了，换形态。

107
00:09:31,301 --> 00:09:38,632
超过十秒还让用户同步干等，注意力必然流失，这不叫体验瑕疵，叫设计事故。

108
00:09:38,632 --> 00:09:43,813
正确做法是把同步等待改成后台任务，配完成通知。

109
00:09:43,813 --> 00:09:53,945
你可以这样想象，用户发起一个深度研究任务，界面上写着预计三分钟，要跑四十多次检索和交叉比对，同步等着可太煎熬了。

110
00:09:53,945 --> 00:10:02,082
任务卡收进右上角的通知中心，窗口还给用户，他接着问下一个问题，或者干脆去倒杯水，都行。

111
00:10:02,082 --> 00:10:05,171
三分钟后完成通知把他拉回来。

112
00:10:05,171 --> 00:10:13,091
深度研究类产品跑十几分钟没人抱怨，因为它开场就把话说清了，这需要一段时间，好了叫你。

113
00:10:13,091 --> 00:10:15,988
预期立对了，慢就名正言顺。

114
00:10:15,988 --> 00:10:21,721
反过来，一个聊天框让人干瞪眼十五秒，用户就会觉得产品坏了。

115
00:10:21,721 --> 00:10:26,493
同样的耗时，形态选对是深度，选错是事故。

116
00:10:26,640 --> 00:10:30,003
休斯顿机场的故事值得单独讲一遍。

117
00:10:29,953 --> 00:10:36,972
乘客抱怨取行李等太久，机场加人提效，把平均等待压到八分钟，投诉照旧。

118
00:10:36,972 --> 00:10:44,328
细看数据才发现问题所在，乘客下机走到转盘只要一分钟，剩下七分钟全程干站着。

119
00:10:44,328 --> 00:10:47,104
后来的方案一秒都没再提速。

120
00:10:47,104 --> 00:10:54,833
把到达口改远，行李分到最远的转盘，乘客要多走六倍的路，走到转盘时行李刚好出来。

121
00:10:54,833 --> 00:10:57,922
总时长没变，投诉几乎清零。

122
00:10:57,922 --> 00:11:05,542
这个案例二零一二年经纽约时报的报道被广为传播，标题就叫为什么要等待是一种折磨。

123
00:11:05,542 --> 00:11:11,275
道理就一句，走路的人觉得自己在推进，干站的人才觉得自己在等。

124
00:11:11,275 --> 00:11:21,576
迪士尼的蛇形折返是同一套逻辑，队伍被设计过，每隔几十秒就能往前挪一步，沿途的布景和预演短片让手里有东西看。

125
00:11:21,576 --> 00:11:26,996
同样的物理时长，被拆成了一直在前进、一直有事干的体验。

126
00:11:26,996 --> 00:11:29,460
这里有个容易搞反的顺序。

127
00:11:29,460 --> 00:11:37,165
很多团队的手是，先花两个季度把延迟从八秒压到五秒，再回头发现差评一条没少。

128
00:11:37,165 --> 00:11:45,410
正确的顺序是反过来的，先把呈现修好，让五秒的等待变得可交代，再去谈要不要为那三秒花钱。

129
00:11:45,410 --> 00:11:51,624
因为呈现改动几乎不花成本，而压延迟的每一秒都要你拿真金白银去换。

130
00:11:51,624 --> 00:11:58,691
两个案例指向同一句话，难受的从来不是时长本身，是不确定、没解释、空着手。

131
00:11:58,691 --> 00:12:02,429
修好这三样，秒数没变，差评先没了。

132
00:12:02,429 --> 00:12:15,133
这也回答了那个成本问题，这一集出现过的四个等待设计动作，给预估时长、阶段汇报、先出提纲、转后台通知，哪个非得把模型换快才做得到。

133
00:12:15,133 --> 00:12:17,429
答案是一个都用不着。

134
00:12:17,429 --> 00:12:21,900
先修呈现再修延迟，账单能便宜一个量级。

135
00:12:22,060 --> 00:12:26,324
最后一课更反直觉，有些等待根本没必要消灭。

136
00:12:26,274 --> 00:12:35,589
同一个问题发给两个客服机器人，答案一字不差，A 零点三秒秒回，B 花三秒半把工作日志逐条亮出来再作答。

137
00:12:35,589 --> 00:12:38,318
投票的时候，多数人信 B。

138
00:12:38,318 --> 00:12:40,193
这就是劳动错觉。

139
00:12:40,193 --> 00:12:49,556
出处是哈佛商学院 Buell 和 Norton 二零一一年的实验，论文题目叫劳动错觉，运营透明度如何提升感知价值。

140
00:12:49,556 --> 00:13:01,887
被试在模拟的机票搜索网站上查航班，一组秒出结果，另一组要等三十到六十秒，但屏幕上滚动着正在检查某家航空公司、正在检查另一家。

141
00:13:01,887 --> 00:13:10,337
结果是展示劳动的那组满意度反超，部分条件下被试宁愿选等六十秒但看得见工作的网站。

142
00:13:10,337 --> 00:13:15,325
机制一句话，人用看得见的努力，推断看不见的质量。

143
00:13:15,325 --> 00:13:22,921
搜索到底查得细还是查得糙，用户没法直接看见，于是拿屏幕上的工作量当质量的代理指标。

144
00:13:22,921 --> 00:13:29,616
咨询师当场给方案显得不值钱，说容我回去分析三天反而显得专业，同一回事。

145
00:13:29,616 --> 00:13:45,930
工程上你有三根现成的杠杆，推理模型的思考过程、检索来源、工具调用日志，全开之后是三层收益，看得见的努力制造了错觉，来源和日志给了可核验的抓手，用户顺带看懂了系统的工作方式。

146
00:13:45,930 --> 00:13:48,634
但它有三条不能越过的红线。

147
00:13:48,634 --> 00:13:58,694
第一，高频任务收着演，翻译按钮用户每天点几十次，第一次展示过程建立信任，之后就直奔结果，别拿用户的耐心铺排面。

148
00:13:58,694 --> 00:14:06,591
第二，展示时长锁在真实耗时之内，呈现节奏可以放慢，超出真实劳动的时长就是造假。

149
00:14:06,591 --> 00:14:14,391
第三，绝不能故意拖慢，后端零点四秒算完了还硬加三秒努力动画，这是造假不是设计。

150
00:14:14,391 --> 00:14:26,110
被拆穿一次的代价是，用户会把这套把戏泛化到你产品的每个角落，之后真实的检索日志、真实的思考过程，都会先被当成表演审视一遍。

151
00:14:26,110 --> 00:14:37,949
还有一条常被漏读的前提，劳动错觉只在结果合格时生效，答案砸了，用户看过的努力只会变成新槽点，查了十二篇文档还答成这样。

152
00:14:38,090 --> 00:14:42,114
第一，考核指标里给首字时间单开一行。

153
00:14:42,064 --> 00:14:49,997
用户那块表从发送走到首字，你只盯总时长的 P99，就等于没在考核用户真正在意的东西。

154
00:14:49,997 --> 00:14:56,872
把首字时间写进报表，写进告警，写进验收标准，让它和总时长平起平坐。

155
00:14:56,872 --> 00:15:00,117
第二，先修呈现，再修延迟。

156
00:15:00,117 --> 00:15:06,018
大部分太慢的差评，模型一行代码都不用动，账单便宜一个量级。

157
00:15:06,018 --> 00:15:12,809
排期上先做流式、预估时长、阶段汇报、先出提纲，做完了再考虑升级机器。

158
00:15:12,809 --> 00:15:18,062
别让界面空白，超过一秒就给反馈，超过三秒就给进展。

159
00:15:18,062 --> 00:15:22,148
第三，给任务定档，超过十秒就换形态。

160
00:15:22,148 --> 00:15:29,444
一秒内直接出，一到十秒必须流式加进度，超十秒转后台任务加完成通知。

161
00:15:29,444 --> 00:15:35,718
不要用更精致的加载动画去掩盖一个本该异步的任务，那是拿装饰盖事故。

162
00:15:35,718 --> 00:15:39,576
第四，预估宁高勿低，进度不许造假。

163
00:15:39,576 --> 00:15:44,660
按历史耗时的偏高值报，实际提前完成是白赚的惊喜。

164
00:15:44,660 --> 00:15:53,014
假进度、硬加延迟是信任炸弹，一旦被拆穿，真的也跟着贬值，再多真实的日志都救不回来。

165
00:15:53,014 --> 00:16:00,129
第五，高频任务收着演，只在关键的、用户自己难验证的场景把过程亮出来。

166
00:16:00,129 --> 00:16:06,090
劳动错觉的红利建立在两个前提上，劳动真实发生，并且结果合格。

167
00:16:06,090 --> 00:16:09,720
两个前提缺一个，都别开这个开关。