值班交接：首字时钟未过线，流式输出暂不放行

本班交接意见：不要因为接口支持流式输出，就直接打开生产开关。流式输出改变的是用户接收结果的节奏，不保证模型更早完成，也不保证任务更快结束。桌上的首字时钟应当回答两个问题：用户何时看到有用内容，以及看见之后能否放心继续工作。

先把首字时钟的起止点写清楚

从用户提交请求开始计时，分别记录请求发出、响应头到达、首个文本片段出现、首段可读内容出现，以及回答完成。连接建立、心跳和空事件都不能算首字；内部推理或工具调用事件，也不能直接算用户已经获得答案。

客户端还要记录实际渲染时间。服务端已经发送文字，不代表浏览器已经显示；代理缓冲、分片解析和界面批量更新，都可能把优势吃掉。值班看板应保留完整链路，而不只展示接口侧的首片段时间。

这些条件满足后，才批准小流量试运行

• 任务确实能从逐步阅读中获益，例如解释、草稿和排障建议，而不是必须等待完整对象才能执行的结构化结果。
• 产品已经定义自己的首段可读内容目标，并在相同提示词、输出预算和并发条件下，分别测量流式与非流式请求。
• 测试覆盖短回答、长回答、长上下文和工具调用，并检查较慢请求的分布，而不只看平均值。
• 界面能明确区分正在生成、已经完成和生成失败，且不会把半句建议呈现成最终结论。
• 用户可以取消生成，应用也会尝试终止上游请求；团队已经验证取消是否生效，以及取消前后的用量如何记录。

例如，评估 Gemini 2.5 Flash 或 GPT-6.1 Sol 时，应先分别建立基线，不要把一次跨模型的速度差归功于流式传输。每次只改变一个关键变量，才能知道收益来自模型、路由、输出长度，还是传输方式。

出现这些情况，先暂停放行

• 首个片段虽然很早到达，但后面长时间停顿，用户看到的只是反复闪烁的光标。
• 代理、网关或客户端会缓冲响应，导致测试环境能逐字显示，生产环境却整段出现。
• 业务要求先完成内容审核、格式校验或权限判断，而当前设计会在检查完成前向用户泄露片段。
• 断流后系统会静默重试并直接续写旧内容，却没有处理重复文本、答案分叉和额外费用。
• 生成中的内容会触发付款、发布、写库等操作，而执行层尚未等待完整结果并进行独立校验。

这些暂停项不一定意味着永久关闭流式输出。需要整体验证的内容可以先缓冲，工具结果可以先显示进度，最终答案通过检查后再展示。关键是不要用“正在输出”掩盖“尚不可用”。

断流演练要比顺畅演示更早完成

至少演练连接超时、首段等待超时、片段间长时间无数据和中途断开。它们需要不同的提示与处理方式，不能都归为“请求失败”。连接仍然活着，也不代表答案正在推进，因此心跳和有效内容应分别监控。

已经显示部分回答后，重试应让用户知情，并把新结果与旧结果清楚分开；除非协议明确支持续传，否则不要假定新请求能从断点恢复。保留请求标识、关键时间点、结束原因和可获得的用量信息，同时避免日志无差别收集敏感正文。

中转接入也要进入同一张验收表

如果团队需要按量使用多个模型系列，Relay365 可以作为中转接入候选，便于在统一接入方式下开展验证。但接入方便不能代替验收：仍需逐条确认目标模型的流式事件、错误处理、结束信号，以及生产网络中的缓冲行为。

准备进行小流量试验时，可以创建一个 Relay365 账户，用自己的真实任务跑完上述清单。先确认功能可用，再判断延迟收益和费用是否适合业务，不要把中转服务本身视为更低延迟的承诺。

交班记录只写可验证的放行依据

最终放行依据应当是：可读内容确实更早出现，完成时间没有不可接受的退化，断流能解释和恢复，审核与执行边界没有被绕过。任何一项尚未验证，就继续保持小流量或关闭开关。首字时钟值得放在桌上，但它不能成为唯一一只表。