长文档能不能整段交给 Grok 4.6，通常取决于三个变量：输入长度、切分方式、任务类型。与其凭感觉判断它是不是「记不住」，不如固定一个问题、一份文档，逐档加长输入，看回答从哪一档开始漏要点、哪一档开始报超时。边界之内，整段输入往往最省事；边界之外，按章节切分更稳；而必须跨段比对的问题，切分反而会丢信息，这时要改成先分段摘要再汇总提问。

建议先用同一份文档、同一个问题做长度递增测试，找到回答开始遗漏或超时的输入区间，再决定整段输入还是按章节切分。整段输入适合要点集中、跨段依赖弱的任务；切分适合定位明确、可独立作答的问题；必须跨段的问题用先分段摘要再汇总提问。判断以你自己记录的回答完整度和错误日志为准，模型版本或上下文配置变化后需要重测。

测量不同文档长度下的完整回答率

先写一份要点清单：把这份文档里你期望被答到的内容拆成 5 到 8 条，作为打分依据。然后把同一个问题分别喂给 1/4 篇幅、1/2 篇幅、全文三种输入，逐档记录，而不是一次跑完就下结论。

1. 固定问题措辞，不改动，例如「请列出文档中提到的所有交付节点及对应负责人」。
2. 按篇幅档位逐次提交，每次只改输入长度这一个变量。
3. 对照要点清单数命中条数，并记录是否中途截断、是否返回长度或超时类错误。
4. 把每次结果追加到同一份记录里，方便横向比较。

提问时可以要求模型分条回答并标注依据段落，这样遗漏更容易看出来：

请只根据下面的文档回答，按要点分条输出，每条后面标注依据的段落标题。
若文档中没有对应信息，直接写「文档未提及」。
问题：……
文档：……

记录建议用一行一条的表格或日志文件，字段保持固定：

doc_id, doc_chars, input_mode, question_id, expected_points, hit_points, truncated, error, note
d1, 12000, whole, q1, 6, 5, no, none, 第4点缺失
d1, 12000, by_chapter, q1, 6, 6, no, none, 需手动合并两段回答

关注点是区间，不是单点：回答开始变薄的输入长度附近，往往就是该考虑切分的位置。这个位置会随文档结构松散程度和上下文配置变化，需要结合环境确认。

对比整段输入与按章节切分的回答差异

拿到边界区间后，挑一份踩线的文档做对照。同一份文档、同一个问题，只切换输入组织方式，其余保持不变。

1. 整段输入跑一次，保存完整回答和错误信息。
2. 按文档自身的标题层级或分隔符切成若干段，逐段提交同一个问题，要求每段回答里注明段落标题。
3. 把分段回答按原顺序拼接，去除重复句，人工或规则化统计要点命中情况。
4. 两次结果都对照同一份要点清单，并单独标注哪些要点只能靠跨段信息才能答出。

观察点建议固定为四项：要点命中条数、回答是否自相矛盾、是否需要人工合并、是否出现「只答开头」的现象。切分通常能改善后段内容的遗漏，代价是跨段推理变弱、合并成本上升；如果要点清单里有明显需要前后对照的条目，切分后大概率答不出来，这属于预期内的损失，不是切分方法本身出错。

对必须跨段的问题改用先摘要后提问

当问题本身要求前后比对，比如「哪些结论在不同章节之间不一致」，逐段单独提问是答不出来的。这时把流程拆成两段：先降维，再提问。

1. 按标题或分隔符把文档切成段，给每段编一个编号，编号后面提问时还要用。
2. 对每段单独跑一次摘要，要求保留人名、数字、时间、结论，并限制条数，避免摘要本身又变长。
3. 把各段摘要按编号拼成一份汇总稿，控制在能整段送进模型的范围内。
4. 把原问题提交给摘要汇总稿，并要求答案标出依据的段落编号。
5. 若某条结论需要原文细节，再用段落编号回到原文对应片段核对，而不是重新整篇提交。

第1步（每段各跑一次）：
把下面这段文字压缩成不超过5条要点，保留人名、数字、时间、结论，
并在开头标出段落编号。

第2步（汇总后跑一次）：
下面是各段要点汇总，请回答：……
每条答案后面标注依据的段落编号；
如果汇总信息不足以回答，明确说明缺哪一段。

这做法的代价是多了一次摘要误差传递，摘要丢掉的信息，后面很难找回来，所以第一步的保留字段要写清楚。适合的是结构清晰、以文字论述为主的文档；表格密集型文档先转成文字再摘要，效果通常更稳定。

记录触发截断或超时的输入特征

只记「文档多少字」不足以复用，因为同样字数下，结构不同结果会差很多。每条失败记录至少写清这几类特征，攒到十几条后就能看出规律。

• 长度：字符数，有条件的话再记粗略 token 数，两者不要混用。
• 结构：纯段落、包含大表格、包含代码块、嵌套列表深度、是否有大量重复格式行。
• 提问方式：单问还是多问并列、是否要求引用原文、是否要求长输出、是否限制分条数量。
• 会话状态：是首轮提问还是多轮追问，前面已经占用了多少上下文。
• 错误表现：报长度错误、报超时、还是正常返回但内容中途截断。

区分「接口报错」和「内容变薄」很重要：前者看返回的错误信息，后者只能靠要点清单对照。两类问题的处理方式不同，前者要减输入，后者可以先调提问方式。

给出不同任务下的输入组织建议

落到具体任务上，取舍会清晰一些。以下都是可以先试的默认做法，具体档位按你自己测出来的边界调整。

• 问答：定位型问题，比如「第三章提到的验收标准是什么」，按章节切分加段落范围提问，命中率通常更稳；全局型问题，比如「整篇文档的核心主张」，整段输入或先摘要后提问更合适。提问时把范围写进提示词，比如「只看第 3 节」。
• 摘要：优先分段摘要再合并，而不是整篇一次性压缩。整段摘要容易出现中后段内容变薄、只有开头详尽的倾向；分段摘要虽然多跑几次，但每段都有输出，便于逐段核对。
• 抽取：先把字段和规则固定下来，再按章节逐段抽取，最后合并去重。抽取任务对格式一致性要求高，逐段跑比整段跑更容易定位漏抽的字段，也便于用同一套规则重跑。

三类任务共用的验证方式是同一份要点清单或字段表：跑完对照一次命中情况，再决定是调整输入长度、切换切分方式，还是改提问措辞。边界一旦改变（换模型版本、改上下文配置、文档结构变化），建议重跑一次长度递增测试，不要直接沿用旧结论。