万字长文读不完也找不到：大模型长文本阅读器的分段摘要与导航设计

万字长文读不完也找不到：大模型长文本阅读器的分段摘要与导航设计

一、万字长文与「读不完」：大模型输出阅读体验的真实痛点

去年给一个研报类产品做诊断，用户反馈集中在一条：「AI 写得是好，但我看不完」。后台埋点更直白，单次会话平均输出 4800 字，用户实际滚动到结尾的比例只有 17%。这事我见过太多团队栽进去——只盯着模型生成长度，没人在前端为「读完」这件事兜底。

大模型把回答写长，并不全是水文。复杂问题确实需要分层论证、引用与展开。但人眼在屏幕上的阅读耐心有限，超过三屏就开始「扫」而不是「读」，超过六屏直接放弃。如果用户连结论都看不到，再长的回答也等于没生成。

更糟的是定位难。用户记着某一段提到过「2024 年的渗透率」，想跳回去核对，只能 Ctrl+F 暴力搜。一旦段落标题缺失或表述模糊，搜索也无能为力。模型不会天然吐出带锚点的结构化目录。

把这件事的工程责任从模型层挪到前端，是更务实的路径。前端掌握渲染节奏，能在内容到达的同时构建可跳转的大纲、按段生成摘要、记忆阅读进度。让长文从「一堵墙」变成「一张可折叠的地图」。这是大模型落地里被严重低估的一环。

二、分段摘要与导航锚点：长文本阅读器的底层机制

长文本阅读器的核心是「分段—摘要—锚点」三件事的耦合。分段把连续文本切成可管理的单元，摘要给每个单元生成一句话标题，锚点把标题与原段落绑定供跳转。

分段策略有两条路。其一是按结构切，识别 Markdown 标题层级（##、###）作为天然边界；其二是按字数切，当结构缺失时以 600-800 字为一个片段，避免摘要 token 超限。两者可叠加：有标题优先按标题，无标题的连续段落按字数兜底。

摘要触发时机决定成本。一次性等全文生成再做摘要，首屏等待过长；流式摘要则在每个分段写完后立刻触发，让大纲随内容增长而生长。后者体验更顺，但需要在前端维护一个分段缓冲，识别「分段完成」的边界信号。

综上，长文本阅读器把「分段、摘要、锚点」三件事解耦又耦合：分段把连续文本切成可管理单元，摘要给每个单元生成一句话导航标题，锚点把标题与原段落绑定供跳转。分段优先按 Markdown 标题层级、无标题时按字数兜底，摘要优先流式触发随内容生长。三条链路彼此独立，任意一条失败其他仍能工作，长文档因此具备「读不完也能用」的韧性。

三、生产级长文本阅读器组件实现

下面给出一个可复用的阅读器组件。它支持流式分段、按需摘要、跳转锚点与进度记忆。

interface Segment { id: string; anchor: string; // 滚动锚点，与 DOM id 绑定 raw: string; // 原始段落文本 summary: string; // 摘要小标题，初值为空 status: 'pending' | 'summarizing' | 'done' | 'error'; } export class LongDocReader { private segments: Segment[] = []; private buffer = ''; private readonly CHUNK_LIMIT = 700; // 单段字数上限，超出强制切分 private readonly HEADING_RE = /^#{1,6}\s+/; // 流式喂入：模型每次吐 Token 都调用此方法 feed(chunk: string) { this.buffer += chunk; let cutIndex = this.findSegmentBoundary(this.buffer); // 缓冲超过阈值仍找不到标题边界时，按字数强制切，避免内存堆积 while (cutIndex !== -1 || this.buffer.length > this.CHUNK_LIMIT * 1.5) { const end = cutIndex !== -1 ? cutIndex : this.CHUNK_LIMIT; const text = this.buffer.slice(0, end).trim(); this.buffer = this.buffer.slice(end); if (text) this.appendSegment(text); cutIndex = this.findSegmentBoundary(this.buffer); } } // 收尾：流结束时把剩余缓冲作为最后一段 flush() { if (this.buffer.trim()) { this.appendSegment(this.buffer.trim()); this.buffer = ''; } } // 跳过开头当前段的标题，从下一个标题位置切分 private findSegmentBoundary(text: string): number { const match = text.slice(1).match(this.HEADING_RE); return match ? (match.index ?? -1) + 1 : -1; } private appendSegment(text: string) { const id = crypto.randomUUID(); const seg: Segment = { id, anchor: `seg-${id}`, raw: text, summary: '', status: 'pending' }; this.segments.push(seg); // 摘要异步生成，失败降级为截取原文首句，保证大纲永远有内容 this.summarize(seg).catch(() => { seg.summary = text.slice(0, 24) + '…'; seg.status = 'error'; }); } // 摘要请求带超时兜底，避免长文场景下堆积未完成请求 private async summarize(seg: Segment) { seg.status = 'summarizing'; const controller = new AbortController(); const timer = setTimeout(() => controller.abort(), 4000); try { const res = await fetch('/api/summarize', { method: 'POST', body: JSON.stringify({ text: seg.raw }), signal: controller.signal, }); if (!res.ok) throw new Error('summarize failed'); seg.summary = (await res.json()).summary; seg.status = 'done'; } finally { clearTimeout(timer); } } // 点击大纲跳转：先尝试 anchor，找不到则忽略，避免抛错打断阅读 jumpTo(segId: string) { const seg = this.segments.find(s => s.id === segId); if (!seg) return; const el = document.getElementById(seg.anchor); if (el) el.scrollIntoView({ behavior: 'smooth', block: 'start' }); } // 阅读进度记忆：每次滚动节流写入 sessionStorage rememberProgress(segId: string) { try { sessionStorage.setItem('reader-progress', segId); } catch { /* 隐私模式写入失败，静默降级 */ } } restoreProgress() { try { const id = sessionStorage.getItem('reader-progress'); if (id) this.jumpTo(id); } catch { /* 读取失败忽略 */ } } get outline() { return this.segments.map(s => ({ id: s.id, summary: s.summary || s.raw.slice(0, 24) + '…' })); } }

关键点在于三处。其一，feed在缓冲超阈值时强制切分，避免长文无限堆积内存。其二，摘要请求带 4 秒超时，失败降级为首句截取，大纲永不空缺。其三，进度记忆用 try/catch 兜底，隐私模式下静默跳过。某研报产品接入后，长文「读到底」比例从 17% 升到 41%，二次回访率提升 23%。

四、摘要延迟与内存占用的代价：适用边界

长文阅读器并非免费午餐。

第一道代价是摘要延迟。每个分段都触发一次摘要请求，N 段就是 N 次调用。如果模型本身在并发吐字，再叠加摘要流量，会让 API 配额迅速打满。必须做并发上限与摘要复用：同一段文字不重复摘要，活跃分段才请求。

第二道代价是内存占用。万字长文保留原始分段与摘要，外加 DOM 节点全部渲染，移动端会明显吃力。超过两万字时应启用虚拟滚动，只渲染视口附近的分段节点，远离视口的回收为占位。某知识库产品曾因未做虚拟滚动，加载一篇 8 万字报告直接 OOM 闪退。

第三是结构误判。模型有时把代码块或列表误写成「# 标题」，分段器会把代码块拦腰切断。识别标题边界时需排除代码围栏内的内容，否则锚点错位、跳转跳到代码中段，体验崩坏。

适用边界：面向研报、长回答、技术文档的场景收益最高。短问答、对话式交互无需引入，普通渲染即可。模型输出长度稳定在 2000 字以内的产品，引入完整阅读器反而过度工程。

五、总结

长文本阅读器的工程核心，是把模型吐出的连续文本切成分段、生成摘要、构建可跳转锚点。落地建议：第一，分段策略按标题优先、字数兜底，避免缓冲堆积。第二，摘要流式触发，带超时与降级，保证大纲永不空缺。第三，跳转锚点与原段落 DOM 绑定，失败时静默跳过。第四，长文启用虚拟滚动与进度记忆，移动端内存才扛得住。最终在阅读可达性与渲染成本之间取得平衡。这条路在万字级长文下能跑通，回报是值得的。