一条请求该直接送进 Ling-3.1-flash 一次返回，还是先切分再送，取决于这条输入本身有多长、以及你需要它在什么时间点交出结果。实时问答要求的是尽快拿到一个能接上话的答复，长文改写要求的是整篇结构别散，这两件事对单次返回长度的容忍度不一样，混用一条链路最容易出现的情况是：对话等太久，或者文章后半段被默默砍掉。

先把手里请求按单次输入长度分档，短档直接走实时问答，长档直接进切分改写链路，中间档先试一次完整返回、再用会话记录里的结束位置确认有没有被截断。两条链路的输入输出约定要分开写，提示词、长度上限和拼接规则都不共用。是否分流合理，用同一批问题各跑一次，记录结束位置、耗时和人工可接受度来比对，别凭感觉判断。

把现有对话按单次输入长度分成三档

分档口径建议按自己业务里的输入形态来定，可以同时看两个指标：段落数和字符量。段落数决定结构复杂度，字符量决定单次返回压力。下面这张表给的是分档思路和对应动作，具体阈值需要结合你实际使用的上下文长度、超时设置和延迟容忍度确认，不建议照搬别人的数字。

操作上可以先写一个小脚本，把待处理文本按段落切出来、统计段落数和字符数，落到一张表里再看分布。这样分档依据是可复核的，改阈值时也能回看是哪一档出了问题。

在会话记录里找出返回被截断或中途停下的位置

判断一条请求是不是“一次返回不了”，看响应记录里的结束位置就能确认。不同接入方式字段名不一样，常见的结束原因字段类似 finish_reason、stop_reason 这类命名，需要结合自己使用的 SDK 或网关确认具体键名。重点看三处：结束原因是不是正常收尾；返回文本的最后一句有没有说完；响应里是否带有可用的输出长度计数（usage 一类的字段）。

标记被截断的那一段的做法：把该次返回的末尾几段原文复制出来，单独存到一个标注文件里，打上请求 ID 和“结束位置可疑”的标签，并记录它是在第几段停下的。后续做切分时，这个位置就是天然的切分参考点。如果结束原因显示为长度上限触发，而不是内容自然收尾，就把这条请求移出短档。

给长文改写加切分与结果拼接步骤

切分位置的选择原则按优先级排：优先在小标题（一级、二级标题）之前切；其次在段落分隔符处切；再次在句末标点处切。不要从代码块、表格、有序列表的中间切开，否则拼接后会破坏原文结构，重新改一遍比重跑一次更费事。

拼接时保留标题层级和段落顺序：切分时给每一段带上序号和它原本的标题路径，改写完成后按序号回填，标题本身不重复生成，只保留一份。最后把拼接结果和原文的标题序列做一次对照，确认没有丢段、没有换序。

# 切分骨架（伪代码，按自己环境替换读写函数）
chunks = split_by_heading(text)          # 优先在标题前切
for i, c in enumerate(chunks):
    c.id = i
    c.heading_path = track_heading(c)    # 记录所属标题层级
    c.out = call_ling(c.text)            # 单段改写调用
merged = join_in_order(chunks)           # 按 id 顺序回填，标题去重
assert heading_sequence(merged) == heading_sequence(text)

每一段调用都应记录返回是否完整，如果某一段同样出现结束位置异常，说明切分粒度还是偏粗，可以再往下切一级。

给实时问答设单次返回的收敛条件

实时问答链路要的是“这一轮够不够用”，可以固定看几个观察点：回复是否以完整句子收尾；是否直接回答了被问的那件事，而不是复述问题；是否明显超出对话场景需要的长度；返回时间是否超出你能接受的一次等待。这几个观察点都能从响应记录和页面行为里看到，不需要额外推测。

不满足时的重发策略建议按代价从低到高走：先收紧提示词，把“只回答问到的点”写清楚；再把上下文缩减到本轮相关的那几段；还不行就把一个问题拆成两个更小的问题分别发；最后才考虑调整单次返回长度上限。重发不建议无限次，通常一轮里控制在有限的几次即可，避免把等待时间叠起来。

用同一批问题分别跑两条链路做对照

分流是否合理，用自己手上的一批问题验证最快。准备一组覆盖短档、中档、长档的输入，每条都分别走实时问答链路和长文切分链路，记录下面的字段，然后逐行比对。

比对时先看结束位置这一列：如果中档请求在实时问答链路里频繁出现结束位置异常，就把这一档整体挪到长文切分链路；如果长档请求在切分链路里人工可接受度明显更高，就保持不动。等待表现按你实际观察记录即可，比如“首段出现前需要等待”“整篇返回后才有内容”，不做量化推断。跑完一轮后，把结论写回分档表，分流规则才算有依据。