模型回复很快，视频怎么还没导出

开车出发前，把没来得及读的 PDF 转给 Agent，让它念出来，接着听内容。第七期记录的这次使用，没有计时数据，但有一个很清楚的结果：人已经能听文档了，不用再操心文件如何转换。

同一期里，给录屏做包装却要等十五到二十分钟。封面、片尾、转场、目录都要做，着急发布时，自己加字幕可能还快一些。两次体验放在一起，正好说明模型响应速度解释不了整个任务的耗时。

先看用户什么时候能开始用

DeepSeek App 在关闭搜索时响应很快，是节目中的个人感受。要判断这种提速对产品有多大帮助，还得看输出拿来做什么。

Anthropic 的延迟文档把请求发出到首个 Token 返回的时间称为 TTFT。流式输出能让人提前读到开头，适合解释、问答等边读边用的内容。若任务是生成一个文件，开头几行代码出现了，用户通常还无事可做。

朗读 PDF 则有另一种安排：第一段语音准备好就开始播放，后面的内容继续处理。这是一种设计选择，节目没有说明当时的工具是否采用了这样的流水线。它值得考虑，是因为听众的使用顺序本来就是从前往后。

同样，视频导出前可以先给一段预览。预览如果足以确认字幕位置或转场样式，就能提前发现问题；只显示制作中的几行日志，对准备发视频的人帮助不大。

用一个假设算例看得更清楚：任务共二十分钟，其中模型处理两分钟，素材传输与导出十八分钟。把模型部分缩短到十二秒，总耗时仍然是十八分十二秒。

实际排查时，需要分别记录下载、生成、渲染和上传用了多久。如果长时间停在渲染，就查输出规格、效果和执行设备；如果主要在返工，就查第一次预览为什么出现得那么晚。

包装本身也有取舍。一条临时说明功能的录屏，可能只需要裁掉空白、加上字幕。把所有动效都做齐，增加的等待未必值得。让用户选择快速版与完整包装版，往往比继续强调模型每秒输出多少 Token 更能解决眼前的问题。

短任务马上就能结束，直接给结果即可。长任务则要让用户分辨自己该不该介入。正在导出时可以离开；源文件缺失时应当补文件；一项已经超时的外部请求，需要给出重试或取消的入口。

这类状态可以很简短，也不需要公开模型的思考过程。完成通知最好附上能直接打开的文件，避免用户回来后再问一次结果在哪。

对于 PDF 朗读，值得检查的是声音多久开始、途中会不会停、离开当前页面后还能否继续听。对于视频，检查的是预览何时可看、最终文件何时可下载。这些时间才直接关系到用户的安排。