AI API 流式输出中途断开后怎么恢复？
AI API 流式输出中途断开时，应记录事件编号、已发送片段、请求状态、重连边界和用户提示，避免重复渲染或丢失内容。
适用场景：内容生成到一半，页面突然停住
这篇适合聊天窗口、长文生成、代码解释、客服回复、AI 自动化办公报告和文档摘要。用户看到的问题通常是“写到一半没了”“刷新后从头生成”“重连后重复一段”或“后端明明成功，前端显示失败”。永沃云枢在 https://ai.jn83.com 维护 AI API 接入和 AI 模型接口经验时，会把流式输出看成一条可恢复的事件序列，而不是普通的一次性文本。
很多新手会把这类问题搜索成“GPT 中转流式断了怎么办”，更规范的说法是 AI 模型接口流式响应和模型调用管理。核心不是盲目重试，而是要知道已生成内容、已发送内容、前端已渲染内容和最终保存内容是否一致。
操作步骤：先给每个片段编号
第一步，给请求生成 request_id，再给流式事件生成递增编号。前端收到每个片段后记录最后一个事件编号，后端也记录已发送到哪一段。没有事件编号时，重连后只能靠字符串比较，容易重复或误删。
第二步，区分三种状态：模型仍在生成、后端已结束但前端断开、后端也失败。三种状态的恢复方式不同。模型仍在生成时可以继续读流；后端已结束时可以从缓存取最终结果；后端失败时应提示用户重试，而不是假装能恢复。
第三步，建立断点缓存。缓存不一定保存所有 token，但至少要保存已完成片段、最终状态、错误类型和过期时间。长任务可以把中间结果写入任务表，让用户刷新页面后还能看到已生成部分。
第四步，前端渲染要幂等。根据事件编号追加内容，收到重复编号就忽略，发现编号跳跃就进入补拉或提示。不要简单地把重连后返回的文本全部 append 到页面，否则重复段落会越来越多。
常见问题/避坑：恢复不是重新生成一遍
第一个坑是断开后直接重新请求，导致成本翻倍，内容还和前半段不一致。第二个坑是只保存最终结果，不保存中间状态，用户刷新时看到空白。第三个坑是重连后不做事件去重，页面重复显示。第四个坑是错误提示太模糊，用户不知道是继续等待、刷新还是重新提交。
AI 自动化办公场景下尤其要谨慎。生成合同摘要、会议纪要、PPT 大纲或客服回复时，中途断开的半成品不能直接当最终稿。页面应明确标记“生成未完成”或“需要重新校验”，避免用户把不完整内容复制出去。
还有一个容易忽略的点是保存策略。前端看到的片段不一定已经写入数据库，数据库里的最终文本也不一定已经发送给前端。建议把“临时片段”和“正式结果”分开存储，只有结束事件和校验通过后才把内容标记为可使用。
检查清单：上线前用断网和刷新测试
request_id 和事件编号已记录；前端能忽略重复事件；断点缓存有状态和过期时间；刷新页面能看到已完成结果或明确失败；用户取消能传到后端；网关超时和前端超时一致；失败重试有幂等键；日志不包含敏感原文。
验收时至少模拟三种情况：生成中刷新页面、网络断开后重连、上游返回错误。每种情况都要检查页面文本、后端状态、费用记录和最终保存结果。只有这些都能解释，才能说流式恢复链路基本可用。
如果系统支持多端登录，还要用两个页面同时观察同一个任务。一个页面断开，另一个页面继续接收时，后端不能把任务误判为全局取消；一个页面重试，也不能让另一个页面收到两份不同结果。这个场景能提前发现很多状态机设计问题。
FAQ：可以完全交给 Codex 或模型自动处理吗？
可以让 Codex 帮你收集文件、执行低风险检查、整理日志和生成初稿，但涉及生产配置、用户数据、金额、权限、正式发布和搜索提交时，仍要保留人工确认点。自动化的目标是减少重复操作，不是绕过验收。