OpenAI Responses API 写作输出被截断后怎么续写

截断状态判断

先不要根据最后一句是否有句号来判断完成。保存本次响应的原始对象、响应 ID、模型、输入、instructions、max_output_tokens、stream 设置和生成正文。Responses API 的创建接口支持 max_output_tokens、previous_response_id、store 和 stream 等参数；这些字段应与正文一起进入任务记录。

应用侧可优先读取响应对象中的状态和不完整详情，并保留未知状态，而不是把所有非完整结果都直接标记为失败。流式场景则要区分已经收到的正文增量、结束事件和错误事件。页面上文字停止滚动，只能说明客户端暂时没有新内容。

• 正文是否停在一个未完成的小节、列表项或代码块中。
• 响应 ID 是否已经写入数据库或任务日志。
• 请求是否把输出上限设置得过小，尤其要注意推理模型的输出预算也会占用上限。
• 流式连接是否中断，还是模型正常返回了不完整结果。

续写上下文

续写的核心不是把已有正文无差别复制回输入，而是建立一份明确的续写上下文。至少保存以下内容：

1. 原始任务目标、文章提纲和资料版本。
2. 已生成正文的完整副本，以及最后一个完整段落或小节标题。
3. 原始 response_id、请求参数和当前任务状态。
4. 下一节的名称、必须覆盖的要点和不应重复的内容。
5. 本次续写的幂等键，例如文章 ID、响应 ID 和续写序号的组合。

如果团队需要长期复查，可参考OpenAI Responses API 写作结果怎么保存和复用响应记录，将输入、参数、响应 ID、状态和最终正文分开保存。

响应关联续写

Responses API 的创建方法支持 previous_response_id，可用于把新请求关联到上一条响应。续写请求仍要明确说明“只生成缺失部分”，并给出准确的衔接位置。注意：资料包中的 SDK 说明指出，使用 previous_response_id 时，上一轮的 instructions 不会自动带到下一轮，因此续写请求必须重新提供必要的规则。

from openai import OpenAI

client = OpenAI()

first = client.responses.create(
    model="your-model-id",
    instructions="你是长文写作助手。按给定提纲生成文章，并保持标题层级稳定。",
    input="主题：如何搭建 AI 写作流水线\n请先完成前两节。",
    max_output_tokens=3000,
    store=True,
)

# 应用侧先保存 first.id、first.output_text 和完整请求记录
continuation = client.responses.create(
    model="your-model-id",
    instructions=(
        "继续完成上一响应未完成的文章。"
        "只输出缺失内容，不重复已经生成的段落。"
        "从最后一个完整小节之后开始，保持原有标题层级和语气。"
    ),
    input=(
        "续写位置：上一响应最后停在‘任务状态保存’小节中段。"
        "请先补完该小节，再继续完成后续提纲。"
    ),
    previous_response_id=first.id,
    max_output_tokens=3000,
    store=True,
)

print(continuation.id)
print(continuation.output_text)

示例中的模型 ID 只是占位符，实际值应使用项目已确认可用的模型。每次续写都要保存新的响应 ID，不要覆盖上一条记录。合并正文时，以应用侧已经落盘的正文为准，只把通过边界检查的新内容追加进去。

流式中断恢复

如果使用 stream=true，应用应在每次收到正文增量时写入草稿缓冲区，并记录最后已处理的事件序号或增量位置。连接中断后，先保留已收到内容，不要清空草稿。

资料包显示，Responses API SDK 支持通过 retrieve 获取指定响应，也支持在流式读取已有响应时使用 starting_after，从指定事件序号之后继续接收。这个方式适合处理已经创建、但客户端没有完整消费事件的响应。若使用 WebSocket，还可以通过 response.steer 发送续写输入；该机制会返回 accepted、pending 或 failed 等相关事件，应用应等待后续 response.created 或失败事件确认结果，而不是把 accepted 当成正文已经生成。

常见故障与修正

• 续写内容重复。原因是新请求没有提供明确的结束边界，或应用把上一段全文再次作为普通输入发送。修正时保存最后一个完整标题和段落，只要求从该边界之后生成，并在追加前做段首去重。
• 续写突然换了语气或格式。原因是 previous_response_id 不会自动携带上一轮 instructions。修正时在新请求中重新写入文章格式、语气、标题层级和事实边界。
• 续写请求报上下文超限。原因可能是多轮响应关联后输入越来越长。source 中说明 truncation 为 auto 时，输入超过模型上下文窗口会从会话开头丢弃项目；disabled 则可能因输入超限返回 400。修正前先缩短不必要的历史，或使用项目已验证的上下文压缩方案，并记录实际策略。
• 流式页面显示不全，但服务端已有结果。原因是客户端断开或没有消费完事件。修正动作是使用已保存的 response_id retrieve 响应；流式恢复时从已记录的 starting_after 位置开始，避免从头追加。
• WebSocket 续写后没有立即看到正文。原因是 steer 的 accepted 只表示服务端接管了排队输入，并不表示输入已经应用。修正时继续监听 successor 的 response.created、response.incomplete 或 response.steer.failed 等事件，并处理 pending 状态。

发布前验收清单

1. 确认正文没有停在未闭合的句子、代码块、表格或列表项中。
2. 确认续写内容从正确的小节边界开始，没有重复上一段或跳过提纲节点。
3. 确认 response_id、续写序号、请求参数和最终正文均已保存。
4. 确认每次追加操作可重试，重复执行不会产生两份相同正文。
5. 确认文章标题层级、段落顺序、链接路径和输出格式符合发布规则。
6. 确认关键事实仍能回到原始资料，续写没有补入未确认的信息。
7. 确认流式任务已收到完成结果，或非流式响应的状态已通过应用侧规则验收。
8. 确认只有验收通过的合并稿进入发布状态，截断草稿仍保留为可追溯版本。