Responses API 输入计数：长文拆分前估算

先建立待提交资料清单

计数前不要直接拼接所有文本。先为每份材料记录名称、类型、版本、是否每次都需要，以及将要进入哪一个任务。稳定规则与本次动态资料应分开保存：前者如语气、格式和禁用项，后者如章节目标、事实卡和本轮修改意见。

用 SDK 的输入计数资源预检

OpenAI Python SDK 的 Responses 资源提供了 input_tokens 子资源，可用于在正式生成前进行输入计数。计数时应使用与正式请求相同的模型标识和输入结构；若正式请求还会带入规则、工具或会话内容，也要确认这些内容是否已纳入本次预检范围。

1. 从资料清单取出一个待执行任务的稳定规则和动态资料。
2. 按正式请求将使用的顺序组装输入对象，不要在计数后再临时追加大段材料。
3. 调用 input_tokens 的计数能力，保存返回的计数结果、模型标识、资料版本和计数时间。
4. 为每个章节重复计数，避免只记录全部资料的一次总数。

计数结果用于比较和拆分，不应替代正式提交后的响应记录。连续改稿需要缩短既有会话时，可结合对话压缩后的长文改稿续写流程保存新的续写边界。

记录结果并决定拆分位置

建立一张估算记录表。除了数量，还要写明该数字对应哪一批资料；否则同一篇文章更新资料后，旧数字容易被误当成当前结论。

拆分优先按可独立验收的边界进行：章节、资料类型、事实主题或改稿轮次。每个子任务应有自己的目标、输入版本和输出文件，不要让后一个任务隐含依赖未记录的上下文。

一个长文改稿示例

例如，团队要修改四章文章，手中有统一写作规则、四份章节资料和三轮历史意见。先把统一规则列为固定项；然后为每章建立“章节资料加本章历史意见”的输入包并分别计数。若第四章还引用一份较长的访谈记录，则将访谈拆成事实卡与原文定位信息，只把本章需要的事实卡放入本次任务。生成完成后，再由汇总任务核对四章之间的术语和结论是否一致。

常见故障与修正动作

• 故障：计数结果很小，正式请求却失败或内容不完整。原因：计数对象与正式请求不一致，后续追加了规则、历史消息或资料。修正：保存计数时的输入快照，并在提交前比较模型、输入项和版本。
• 故障：同一章节每次数字变化很大。原因：资料清单没有固定，编辑在不同位置粘贴了重复内容。修正：给每份资料分配版本号，计数前去除已被固定规则覆盖的重复段落。
• 故障：拆分后章节互相矛盾。原因：全局事实与章节局部材料没有分层。修正：维护一份只含已确认事实的共享卡，并在每个子任务中引用同一版本。
• 故障：只留下数字，无法复现当时判断。原因：没有记录模型、任务范围和资料版本。修正：将计数结果与任务编号、输入摘要、版本号和拆分决定一起归档。

提交前检查清单

• 本次输入资料已按稳定规则、动态资料和历史内容分类。
• 计数对象与计划提交的模型和输入结构一致。
• 每个计数结果都关联任务编号、资料版本和记录时间。
• 超出团队可接受范围的任务已按章节、主题或资料类型拆分。
• 每个子任务都写明了目标、事实来源和预期交付物。
• 共享事实卡与各章节资料的版本关联已复核。
• 正式提交前已删除无关历史内容和重复材料。