把一整份文档丢给 Space Bunny,回答却漏掉中间章节、或者抓住某个次要段落反复展开,通常不是模型能力的问题,而是输入长度和任务类型没对上。短问答和草稿润色可以直接用;长文档更适合先切块、逐段确认、再合并。下面按这个思路给出可照着做的判断表和切法。
判断标准是输入长度和问题类型是否匹配:一屏内能看完的短问答、语气润色,可以直接整段提交;上千字以上、需要通读才能回答的长文档,建议按章节或论点切块,每块套同一个问题模板单独提问,逐段核对结论是否冲突、有没有整段被跳过、引用能否对回原文,再合并成最终结果。切块会带来额外的核对成本,如果只是改一句话或查一个词,不必走这套流程。
先判断这个任务该不该整篇贴
先把文档长度和问题类型分开看。长度决定信息能否被完整覆盖,问题类型决定要不要读全文。下面这张对照表可以作为第一次分流用。
| 文档长度 | 问题类型 | 建议输入方式 | 怎么验证 |
| 一屏内,几百字 | 找某个说法、改语气、改错字 | 整段直接贴,问题写在后面 | 看回答有没有引用原文原句 |
| 几屏,章节可见 | 整合摘要、跨段对比 | 先整篇试一次,出现明显漏段再切 | 对照原文小节标题,看是否每节都有落点 |
| 几十页 | 整体摘要、通篇判断 | 按章节切块,每块先出小结,再合并 | 块编号与原文章节号一一对上 |
| 几十页 | 找具体条款、找某个数字或定义 | 只贴可能含该条款的章节 | 把回答里的句子拿回原文检索 |
| 几十页 | 改语气、润色某段 | 只贴要改的段落,不要整篇 | 通读一遍,看是否夹带了没提过的信息 |
容易踩坑的是“整体摘要”这一类问题。它看起来只要一段话,其实要求覆盖全文,输入越长越容易被中间部分吞掉。判断症状很简单:如果回答里出现“文中没有提到”“似乎”“大致”这类模糊措辞,而原文其实写得很明确,就说明该切块了;如果回答整体顺畅、每节都有对应,就可以继续整篇用。
长文档按结构切块的具体切法
切块的目的是让每一块都能被独立提问、独立回答,而不是把长文硬切成等份。下面三种切法按文档结构选一种即可,也可以混用。
按章节标题切
适合有明确标题层级的文档:制度、说明书、技术手册、报告。切点就落在标题处,每块带上自己的章节标题一起提交,方便后面回指。适用的问题是整体摘要、目录级判断、章节之间是否矛盾。缺点是章节长短悬殊时,短章节可能信息不足,可以和相邻章节合成一块再问。
按论点段落切
适合结构松散、小标题不规整的文档:会议记录、评审意见、邮件往来。以空行或一个完整论点为界,一块只放一个论点,提问时把论点原句一起带上。适用的问题是找具体条款、找某条论据、判断某段说法有没有被后文推翻。这种切法块数偏多,核对时按论点清单逐个对,不容易漏。
按固定长度加重叠切
适合没有小标题、连续叙述的文本:长访谈、逐字稿。按固定长度切开,块与块之间保留一小段重叠。重叠不是为了提高速度,而是避免某个结论刚好落在切口上,被两块各说一半。代价是重叠部分会被重复处理,核对时要注意同一句话不要被算成两条结论。
每块提问都套同一个问题模板
切好之后,每块都用同一套问法,不要一块问“这段讲了啥”、下一块问“帮我找重点”。问法一变,输出口径就变了,合并时根本分不清差异是内容差异还是提问方式差异。可以直接用下面这个模板。
我在处理一份长文档,已切成多块,现在只给你其中一块。
请严格按下面三项回答,不要展开其他内容:
1. 这段在说什么:用一句话概括,不展开。
2. 与问题相关的句子:逐条摘录原文,并标出所在段落或小节位置。
3. 缺了哪部分上下文:这段无法回答的部分,直接写出来,不要猜测。
我的问题:<填写你的问题>
本块内容:<粘贴这一块>
三项里最容易被省掉的是第 3 项,但它恰恰是防跑偏的关键。让模型明确说出“这段没有涉及 XX,需要看其他章节”,比让它硬凑一段完整答案可靠得多。第 2 项要求摘录原句而不是复述,是为了后面能拿回原文检索。模板固定下来以后,每块的输出结构一致,逐块对照就能直接做,不用每块重新理解一遍回答格式。
逐段核对后再合并结果
合并之前先做核对。三件事按顺序过一遍:块与块的结论是否互相冲突;有没有哪一块整段被跳过、没有输出;回答里摘录的句子能不能对回原文。这些都能通过人工比对完成,不需要额外工具。
- 查冲突:同一事实在两块里说法不一致,通常说明切口切断了上下文,回到边界附近读一遍原文再判断以哪块为准。
- 查漏块:把块编号和原文章节号列成清单,逐条打勾,任何一块没有对应输出,就单独重问一次。
- 查引用:把回答里的原句复制出来,在原文里搜索一次;搜不到的句子说明是复述或补写,标出来重新确认。
- 合并:按原文章节顺序排列各块结论,冲突项单独列出并注明以哪处原文为准,标注“缺上下文”的块补上相邻块后重问。
- 整体过一遍:合并完再提交一次,只给原始问题和你整理好的块结论,看是否还有漏项。
核对这一步是有成本的,块越多成本越高,所以切块粒度不必太细。通常按章节切、块数控制在能逐个看一遍的范围内就够了。
短任务为什么可以直接用
短问答和草稿润色落在边界的另一侧:输入短、问题指向单点、结果可以当场读完,所以不需要切块,也不需要套模板。
- 输入长度:一屏内能看完,或者只需要看其中一个段落,通常几百字以内。
- 提问方式:原文和问题放在同一个请求里就行,比如“把下面这段改成更口语的语气”“这段里说的截止时间是哪天”。
- 是否需要核对:改语气、换措辞、调结构这类任务,读一遍就能判断好坏;涉及事实、数字、条款的短问答,仍然建议把答案里的原句回原文核一次。
- 分界:一旦需要通读全文才能回答,或者回答里出现“中间部分没有提到”“整体来看”这类措辞,就说明已经越过边界,该切块了。
实际的用法往往是混着的:一封两三百字的邮件直接润色,一份几十页的规范先按章节切块、逐段确认后再合并。两者之间没有硬性字数线,判断依据是回答能不能覆盖你关心的位置,以及你愿不愿意为核对多花时间。