报告模式:长输出分段计划防上下文爆炸

📅 发布时间:2026/8/27 23:10:32
报告模式:长输出分段计划防上下文爆炸 又是一次翻车复盘。季度行业分析我让 AI 一口气写八千字前两节像模像样第三节开始把第二节的观点换了个说法再讲一遍编号从三、“莫名其妙跳回3.1”到了结论部分它已经忘了开头定下的判断口径。重写一遍token 花了双份时间也搭进去了。后来我改用察元AI文档助手的报告模式同样规模的报告稳多了。这篇讲讲长输出为什么会塌以及报告模式怎么把塌方挡住。长输出塌方的三个原因一是上下文膨胀。AI 自己写出来的每一个字都会变成后续生成的上下文。写到五千字时它背着五千字的包袱在写第六千字越写越沉。二是注意力稀释。开头那句重点分析供需关系的指令在八千字的长度里权重被摊得越来越薄写着写着就飘了。三是没有中间验收点。一口气生成等于一次性交卷中间跑偏没人拉回来偏到最后只能整篇重来。这三条叠加就是后半段忘前半段的病根也是 token 开销失控的常见来源——在 Token 成本越来越被盯着的今天长输出乱写一遍再重写是最贵的浪费。报告模式一次生成拆三段报告模式的思路很直接把一次生成拆成计划段、执行段、汇总段。计划段先出大纲和写作计划只定写什么、什么顺序、每节给多少篇幅这一段便宜改起来也便宜——大纲不对改一句话就行。执行段按确认过的计划分段展开每段边界清楚写完即验收跑偏当场拉回。汇总段最后收口统一口径、对齐术语和编号、补上前后的呼应专治前后打架。妙处在于成本结构变了人的意见被前置到最便宜的计划段而不是最贵的成稿段。在大纲阶段调整一句话和全文重生成一遍差着一个数量级的开销。读长文档也是一个道理读写两侧的毛病是同一种一次性硬塞。察元在读这一侧同样有分块设计文档元信息会先给出字数、段数和是否建议分块的提示读全文超过约 80k 阈值会被拦下来要么明确强制要么改用分页分块的方式按块读。生成用报告模式、读取用分块一套思路的两面把长任务拆成有边界的短任务。什么时候该切报告模式我的经验阈值很简单成稿预期超过三千字或者结构超过两级标题就别让 AI 一口气写完。还有一个信号更直接——如果你在提示词里已经写出了然后“接着”最后再这类顺序词说明任务本身天然是多段的硬塞进一次生成等于让模型自己做分段计划而它做长程计划的能力恰恰是长输出里最先掉线的那一环。报告模式做的事情本质上是把这个分段计划从模型手里拿回来交给人拍板。操作建议三条第一生成前先定大纲再放权提示词可以直接抄先列出三级大纲和每节要点给我确认不要直接写正文我确认后再逐节展开最后单独写一段汇总统稿第二执行段每写完一节人扫一眼再放下节别攒到最后一起看——中间不点头攒到最后的往往是一起重写。第三汇总段重点查三样口径是否前后一致、编号是否连贯、术语是否统一这三样恰恰是分段生成最容易裂开的地方。统稿完我还会让校对先跑一遍 dryRun只出问题清单不落盘把编号、术语、数字的一致性问题一次捞完对着清单改比通读八千字省力得多。适用人群与边界报告模式适合所有要产出长文本的人季度分析、可研报告、标书技术方案、课程讲义。边界也要说明白分段计划防的是结构性塌方——重复、失忆、编号混乱它不担保内容真实。数据、引文、结论的对错仍然要人去核AI 分段写得再整齐事实错误一样会藏得很深。长输出的答案是别让 AI 一次逞英雄人也一样。