大模型API回答不完整怎么办？输出上限、结束原因与续写处理指南

大模型API回答不完整时，先不要直接提高输出Token上限。相同的“少了一段”现象，可能由模型达到输出限制、网络连接中断、安全策略拒答、请求超时，或前端只显示了部分内容造成。正确做法是按照响应日志、传输链路和显示层逐层定位。

一、先确认是不是真正的输出截断

第一步查看服务端保存的原始响应，而不是只看网页或聊天窗口。如果原始响应已经缺少结尾，再检查HTTP状态、请求耗时、错误字段、响应体是否完整，以及接口返回的结束原因和用量信息。不同厂商的字段名称、结束标记和统计口径并不统一，应以实际接口文档为准，不能把某一家接口的参数名直接套用到另一家。

• 达到输出上限：结束原因通常会提示长度或输出限制相关信息，同时输出用量接近请求设置的上限。具体判断仍需以接口文档和响应字段为准。
• 网络或传输中断：服务端可能已经生成了一部分内容，但客户端连接断开、流式读取异常或代理超时，导致本地只收到前半段。
• 安全拒绝或提前停止：响应可能包含拒绝说明、过滤结果或特殊结束状态，不应简单当作普通文本被截断。
• 前端显示不全：数据库、日志或浏览器开发者工具中的原始内容完整，但界面因渲染、分页、长度限制或Markdown处理异常而隐藏了部分内容。

二、区分上下文容量与最大输出长度

上下文容量和最大输出长度不是同一个指标。上下文容量通常涉及输入内容、历史消息以及本次输出所占用的总空间；最大输出长度则限制本次生成的结果。输入很长时，即使把输出上限设置得较高，也可能没有足够空间继续生成。反过来，输入较短也不代表模型一定会输出很长内容。

排查时记录实际发送的消息、历史对话、模型或部署配置、输出限制参数、输入与输出用量，以及接口返回的结束原因。不要只根据客户端展示的字数估算Token，也不要假定所有平台都接受相同的参数名称。对参数是否生效、上限是多少，应查阅所用接口的当前文档。

三、按链路定位网络中断

对于流式响应，客户端需要持续读取事件或数据块，并在结束信号到达后再拼接结果。可以同时保留原始分块、最后一次收到数据的时间、HTTP状态和连接错误。若服务端日志显示生成已结束，而客户端没有收到完整响应，应检查反向代理、网关、超时设置、连接复用和流式读取代码。

非流式请求则应确认响应体是否完整写入，避免在读取尚未完成时就把结果交给解析器。重试时要注意幂等性和费用控制；对于已经生成部分文本的请求，不能仅凭重试结果就认定它会从原位置无缝接上。

四、长任务优先拆分，而不是盲目续写

长报告、技术文档或代码生成更适合拆成章节和结构化子任务。例如先生成目录，再逐章生成，每章明确目标、长度、输入资料和输出格式，最后由程序合并，并检查章节是否缺失、标题是否重复、引用是否对应。这样比一次请求完整生成大文档更容易定位失败位置。

如果需要续写，应向模型提供原任务要求、已完成内容的结尾、当前章节标题、尚未完成的要点和输出格式。仅发送“继续”并不能保证恢复原输出，也可能从新的位置重复上一段、改变术语或遗漏原本的约束。合并前可以对续写开头做重复检测，并人工或程序复核段落顺序。

五、JSON截断的处理方法

例如接口返回的JSON缺少闭合括号，直接解析会失败。此时不要用简单字符串拼接盲目补上括号，因为字符串内部可能还缺少字段、转义不完整，或结构本身已经损坏。先保存原始响应，确认是输出上限还是传输中断；若结构化结果必须完整，通常应重新生成，并要求模型只返回符合约束的JSON。

对于较大的结构化结果，可以按数组、记录区间或业务分块分别生成，再由程序合并，并在每块完成后进行语法解析、字段校验和重复检查。若接口支持结构化输出或响应格式约束，也应按照该接口文档配置，但不能据此保证任何异常情况下都不会截断。

六、建议保留的诊断信息

• 请求标识、时间、模型或部署标识和接口版本信息。
• HTTP状态、错误字段、流式分块记录及连接异常。
• 输入、输出和总用量，以及实际使用的输出限制参数。
• 接口返回的结束原因、原始响应和前端最终展示内容。
• 合并后的文本或JSON是否通过长度、结构和业务字段校验。

通过这些信息，可以判断问题发生在生成、传输、解析还是展示阶段。只有确认确实因输出限制结束后，才适合调整限制或进一步拆分任务；如果是网络中断、拒答或前端截断，提高上限通常无法解决根因。