值班记录：把流式首字计时器放上桌面，按六步排查等待

桌面上的计时器，要盯住用户看见文字的时刻

值班时收到“模型一直没反应”的反馈，先别急着换模型。请求可能仍在处理，也可能已经返回内容，却被中间层攒住了。流式响应的价值，是让用户边接收边阅读；它不承诺更快生成全部答案。先把等待拆开，才能知道该查哪里。

先记三个时刻，再谈首字快不快

• 第一步，选一个固定问题，记录请求发出、首段有效文字显示、回答结束三个时刻。前两者的间隔，是用户实际感受到的首字等待；首尾间隔，则是完整回答耗时。严格的首个生成单元延迟需要更细的服务端观测，不能仅凭界面上的第一个字推算。
• 第二步，用同一问题分别测试普通响应和流式响应，并保持模型、上下文与输出上限一致。普通响应往往等内容准备完成后再交付，流式响应则逐步交付。观察重点不是哪个动画先出现，而是哪次更早给出了可读内容。

从接入地址到界面刷新，逐段确认没有攒包

• 第三步，确认客户端真正启用了流式接收，并逐段读取响应。如果使用兼容开放式接口的软件开发工具包接入 Relay365，基础地址应填写 https://api.api365relay.com/v1。不要在读取完整响应后才更新界面，否则上游即使持续发送，用户仍会看到一段空白等待。
• 第四步，检查反向代理、服务端响应和前端渲染是否存在缓冲。分别记录第一段网络数据到达和第一段文字显示的时刻；两者差距明显时，优先检查应用链路。连接建立通知、心跳和空内容片段都不应算作首字，界面也不必为了每个微小片段立即重绘。

固定输入重复测，把失败请求也写进交班本

• 第五步，使用固定输入重复测试，例如先用 Gemini 2.5 Flash 跑通链路，再用 Claude Haiku 4.5 检查同一接收逻辑。记录测试时间、输入长度、输出长度、并发情况和错误信息。不同模型的结果只能解释当次条件，少量样本不足以证明长期快慢，也不要把失败或超时的请求从记录里悄悄删掉。
• 第六步，为等待、中断和重试设计明确状态。尚未收到文字时显示正在处理，收到文字后逐步呈现；中途断开则保留已显示内容，并说明回答未完成。重试可能再次产生调用费用，不能把重新请求伪装成原回答的无缝续传。敏感请求内容也不应为了排查而完整写入日志。

交班时交出时间线，而不是一句“已经变快”

一条有用的交班记录应包含：何时发出请求、何时收到有效文字、何时显示、何时结束，以及是否重试。流式体验改善，首先意味着等待变得可见、可解释，不等于总耗时必然下降。如果首字很快但后续停顿明显，还要检查片段间隔，避免只优化开头的数字。

需要在一个接入点试用多个模型家族时，Relay365 的按量付费中转服务适合用来搭建这张测试桌，但仍应实测具体模型与调用链路。可以创建一个 Relay365 账户，从短问题、低并发开始，确认首字计时、错误提示和费用记录都能正常交班，再逐步接入真实业务。