Responses API 对话压缩后的长文改稿续写

先建立压缩任务表

压缩前不要只记录“文章已改到第几轮”。为每个任务建立一行记录，至少包含文章标识、当前草稿版本、最后一条响应标识、待改范围、负责人和压缩时间。另存一份当前草稿快照，避免把压缩操作当成正文归档。

划定必须保留的信息

将历史内容分为三类：必须保留、可概括和可丢弃。必须保留的是已核验事实、编辑已确认的结论、文章结构约束与尚未完成的修改要求；可概括的是已被新版本覆盖的讨论过程；可丢弃的是重复指令、被否决的措辞和无关闲聊。不要把未经核验的候选说法写入保留区。

• 把事实材料写成可核对的短句，并保留原始来源位置。
• 把规则写成明确条件，例如段落范围、受众和禁止新增事实。
• 把待办写成可执行动作，例如“仅重写第三节开头”。

记录当前响应并发起压缩

在调用前确认当前链路使用的是响应关联方式，而不是同时混用不兼容的会话参数。SDK 中提供了 compact 方法，可传入模型与 previous_response_id 来压缩已有对话。请求完成后，保存压缩结果对象的标识，并把它与压缩前的响应标识、草稿版本一起写入任务表。

1. 冻结本轮草稿并保存版本快照。
2. 确认最后一条可继续的响应标识。
3. 调用压缩接口，使用同一任务需要的模型配置。
4. 保存压缩结果标识、调用时间和操作人。
5. 不要删除原始版本记录，直到续写复核通过。

用压缩结果继续改稿

续写时只提交本次修改目标和必要的事实补充，并关联压缩后得到的结果。使用 previous_response_id 继续时，先前请求的 instructions 不会自动带入，因此需要在新请求中重新提供当前有效的写作规则。规则应以任务表中的已确认版本为准，避免把旧规则和新规则同时发送。

例如，团队已完成一篇产品说明的四轮改稿，现在只需调整结尾。续写输入可明确为“保留已确认事实和现有标题层级，仅重写结尾两段，不新增数据或承诺”。生成后将新响应标识回写到草稿版本记录中。

常见故障怎么修正

以下排查按常见故障、原因和修正动作处理，先停止发布，再恢复到可确认的版本。

• 故障：续写后语气或格式变了。原因：续写请求没有重新提交当前有效规则。修正动作：从任务表取回固定规则，作为本次 instructions 重新发送，再生成对照版本。
• 故障：正文出现旧版本已删除的说法。原因：压缩前未标记淘汰内容，或继续关联了错误的响应标识。修正动作：核对链路记录，回退到正确版本，并在新请求中明确排除该说法。
• 故障：压缩调用失败或无法继续关联。原因：响应标识为空、模型配置不匹配，或请求参数组合不符合接口约束。修正动作：检查保存的标识和请求日志，按当前 SDK 文档核验参数后重试，不覆盖原始记录。

发布前逐项验收

压缩成功不代表改稿可发布。发布前检查项应由内容运营与开发侧共同确认：

• 当前草稿版本能对应压缩前后两个响应标识。
• 固定写作规则已在续写请求中重新提供。
• 文中的数字、日期、名称和结论均能回到已确认材料。
• 没有把讨论中的猜测、废弃方案或未确认待办写成事实。
• 标题层级、段落范围和本次修改目标均符合任务单。
• 原始草稿快照、压缩记录和最终响应标识已归档。