把整篇长文档交给 Muse Wonder 之后，回答只覆盖后半段、前文信息凭空消失，通常不是模型“没读懂”，而是输入已经越过它当前实际能稳定利用的上下文范围，截断点恰好落在前面的段落上。要分清是长度限制、分块方式还是提问写法造成的，先固定一份可复现的输入基线，再逐段追加提问找出首次遗漏的段落号，最后用同一问题对比一次性投喂和分段投喂的输出覆盖范围。

适用场景：单次输入远超常用上下文长度、回答只覆盖文档后半段的长文档问答。操作动作：给每段编号并记录字数与首尾句，逐段追加提问，标出首次遗漏的段落号。验证方式：让模型复述当前输入范围内指定段落的标题或首句，与输入范围对照。风险边界：不同模型、不同版本、不同调用参数的可用窗口并不一致，任何一次测出的边界只能说明当前这套配置，换模型或改参数都需要重新标定。

给测试长文标上段落序号与长度量级

先把输入固定下来。每次换一篇新文档就重新测，结论之间没有可比性；建议用同一篇长文反复试，改动只发生在输入范围上。段落编号可以采用 P001、P002 这种定长前缀，直接写在每一段开头，这样模型复述时你能一眼看出它引用的是哪一段，也方便在日志里检索。标题行和正文段都编，不要只编正文，否则标题被截断时容易误判。

长度量级不需要精确到字节，够用就行：中文按字符数估算，英文按词数估算。Linux 下可以先按空行切段，再统计每段长度：

# 按空行切成段落，输出每段编号和字符数
awk 'BEGIN{RS="";n=0} {n++; gsub(/\n/," "); printf "P%03d\t%d\t%s\n", n, length($0), substr($0,1,30)}' doc.txt

如果文档本身没有空行分隔，先手工按语义把小标题切成块，再跑上面的统计。记录表建议保留四列，段号用于定位，字数用于估算总输入量，首尾句用于事后核对模型到底读到了哪一段：

这张表就是后面所有判断的基线。哪一轮开始对不上，直接回到表里查段号。

逐段追加提问，记录从第几段开始丢前文

接下来做追加测试：第一轮只投 P001，第二轮投 P001+P002，第三轮 P001+P002+P003，依次累加。每一轮都问同一个问题，并额外要求模型复述当前输入里覆盖到的所有段号，例如“请列出你这次输入中包含的段号，并各用一句话概括”。把每轮的输入范围、模型复述的段号、首次没有出现的段号记在同一张对照表里。

输入范围：P001 ~ P00N
提问：请列出你本次输入中能看到的所有段号，并对每段给出一句话概括。
期望：复述段号应覆盖 P001 ~ P00N
首次遗漏段号：P00X（注释：从这一轮开始 P00X 及其之前的内容不再被复述）

首次遗漏的段号就是当前配置下判断截断位置的主要依据。出现两种典型形态：一种是前面整段整段地丢，说明总量已经超出窗口；另一种是中间某段开始丢、后面又恢复，这更像切分或拼接方式的问题，而不是单纯的窗口不够。需要说明的是，模型复述不出来不等于内部一定没读到，可能是注意力分配偏后，所以这一步只用来定位“可用覆盖范围”，不要当成严格的窗口大小测量。

对比一次性全文投喂与分段投喂的回答差异

确认了遗漏段号之后，再判断问题到底出在长度还是切分。方法是用同一个问题跑两次：一次把全文一次性投喂，一次按前面测出的安全范围分段投喂（例如每 3 段一组），把两次回答并列放在一起看覆盖范围。

如果两次回答覆盖范围差异明显、分段投喂能覆盖到前文，说明主要矛盾是长度而不是切分；如果分段后仍然丢中间段落，就要回头检查分块边界是不是切在了句子中间，或者在拼接时丢了分隔符。这一步不追求谁更好，只求把归因分清楚，因为长度问题和切分问题的处理方式不一样。

把有效提问长度和分块节奏写成模板

把上面测出来的结论固化成固定写法：分块大小取“首次遗漏段号”之前的段数并留一点余量，例如实测在 P007 开始丢，就按每 3 到 4 段一组；每块提问句保持句式一致，只替换块编号和问题；每块都要重复携带同一份背景摘要，不要让模型靠记忆接上下文。可以用下面这个模板：

【背景摘要】
文档主题：<一句话主题>
已确认前提：<1-3 条已从上文得到的事实>

【本块内容】
段号范围：P004 ~ P007
正文：<粘贴对应段落，保留段号前缀>

【问题】
基于以上内容回答：<同一个问题>
如果本块内容不足以回答，请明确说明缺少哪一段的信息。

模板里“已确认前提”是必须重复携带的部分，它替代了被截断掉的前文，通常控制在几行以内，太长又会挤占本块的输入空间。分块大小、背景摘要长度这两项需要结合自己使用的模型和调用参数确认，换环境后建议重新跑一遍逐段追加测试，再调整模板里的段数。