AI 应用怎样区分用户取消和模型完成

AI 应用里最容易误判的一件事，是把“流没有继续返回数据”直接记成“模型完成”。用户点击停止时，浏览器通常只是中止了读取；代理断开、服务端异常、模型正常发出完成事件，表面上都可能表现为连接结束。可靠做法是把用户意图、传输结果和模型生命周期分开记录。

官方文档：https://developers.openai.com/api/docs/guides/streaming-responses

只有收到协议明确的完成事件，才能把一次流式生成记为 completed；AbortSignal 触发的是 cancelled，其他没有完成事件的断开应保留为 failed 或 interrupted。

一次“取消后显示成功”的故障现场

故障发生在一个带逐字输出的问答页：用户点击“停止生成”，界面立即停止追加文本，但历史记录随后显示“已完成”。排查日志时发现，前端只监听了 reader.read() 返回的 done=true，服务端也只在连接关闭时写入成功状态。于是三种情况被压扁成同一个结果：

• 用户主动取消：应记为 cancelled；
• 模型发出完成事件后自然收尾：应记为 completed；
• 网关超时、网络断开或服务端异常：应记为 failed 或 interrupted。

OpenAI 的流式文档把增量文本和生命周期事件分开描述，常见事件包括 response.output_text.delta、response.completed 和 error。这正好说明：收到最后一段文本，不等于收到完成确认。

先把结束信号拆成三层

第一层是用户控制层。点击停止、离开页面或切换会话，应该设置 cancel_requested=true，并让同一个 AbortController 终止读取。第二层是传输层，reader.read() 的 done=true 只说明当前响应流结束，不说明为什么结束。第三层才是模型层：只有解析到供应商定义的完成事件，才能设置 model_completed=true。

建议最终落库的最小字段如下：

用 AbortSignal 和完成事件写状态

前端不要在 done=true 分支里直接报告成功，而应等待流内事件更新 modelCompleted。下面的示例用简化的 SSE 解析函数表示事件分发，重点是状态优先级和异常处理：

const controller = new AbortController();
let modelCompleted = false;
let cancelRequested = false;

async function startAnswer(prompt) {
  try {
    // signal 让用户取消动作能中止 fetch 和响应体读取。
    const response = await fetch('/api/ai/stream', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ prompt }),
      signal: controller.signal
    });
    if (!response.ok || !response.body) {
      throw new Error(`stream unavailable: ${response.status}`);
    }

    const reader = response.body.getReader();
    while (true) {
      const { value, done } = await reader.read();
      // done 只代表传输流结束，不能单独证明模型完成。
      if (done) break;
      for (const event of parseSse(value)) {
        if (event.type === 'response.output_text.delta') appendText(event.delta);
        if (event.type === 'response.completed') modelCompleted = true;
        if (event.type === 'error') throw new Error(event.message);
      }
    }

    reportResult(modelCompleted ? 'completed' : 'interrupted');
  } catch (error) {
    // AbortError 是用户取消；其他错误保留为失败，便于复盘。
    if (error.name === 'AbortError' && cancelRequested) {
      reportResult('cancelled');
    } else {
      reportResult('failed');
    }
  }
}

function cancelAnswer() {
  // 先记录意图，再终止读取，避免把取消误判成普通断流。
  cancelRequested = true;
  controller.abort();
}

生产代码还要为重复点击做幂等保护，并把请求 ID、最后一个事件类型、已生成字符数和终止原因一起写入日志。若采用支持后台任务的 API，则应额外保存响应 ID；显式取消接口的适用范围以供应商文档为准，不能把它当成所有同步流的通用操作。

复盘后的日志和边界

修复后，状态转换应满足一个简单原则：completed 只能由明确完成事件写入，cancelled 只能由已记录的用户取消意图和 AbortError 共同确认。若先收到取消意图、随后又收到完成事件，通常以用户操作时间和服务端最终确认策略为准，但必须在日志保留两者，不要静默覆盖。

还要特别处理三类边界：页面卸载可能来不及发送状态上报；代理截断可能没有任何错误事件；服务端已经完成而客户端尚未读到最后一个事件。它们都不应靠猜测补成成功，可以使用心跳、服务端事件账本或最终查询接口补齐。

这次故障的根因不是 SSE 本身，而是把“连接状态”和“业务状态”混为一谈。把取消意图、模型完成和异常断开拆成独立证据后，界面文案、计费、重试和审计日志才能得到一致结果。

常见疑问

读到最后一段文本就能判定完成吗？

不能。最后一段文本只是增量数据，必须等待协议定义的完成事件；否则网关截断也会被误记为成功。

用户点击停止后还收到完成事件怎么办？

保留事件顺序和时间戳，按产品约定决定展示状态；通常用户主动停止优先显示 cancelled，但服务端是否已经完成应作为独立字段保存。