企业官网建设流程全解析

一本七部、累计上百万词的系列小说，能不能用六句话讲完，并且让这六句话不只交代剧情，还能解释它凭什么风靡全球？这不是文学鉴赏题，而是一个相当典型的工程题：长文本分块、递归摘要、结构化约束输出、归因式提示词设计、批量任务调度、接口服务封装。把这套流程跑通，你收获的不只是六句话，而是一条可以复用到研报压缩、会议纪要、论文综述、课程讲义整理上的长文本处理流水线。

这次我们把“六句话读完《哈利波特》”当成一个具体的内容压缩任务来做，重点不在复述剧情，而在于把“为什么能传播”拆成可被模型识别和输出的维度：世界观设定、成长叙事、情感锚点、语言门槛、跨媒介扩散。前四个靠文本分析，最后一个靠外部信息补充，边界要划清楚，否则模型很容易把营销结论和文本证据混着说。

硬件门槛并不高。真正吃资源的是两件事：一是原文长度，几十万词一次性塞进上下文不现实，必须分块；二是输出约束，六句话意味着每句话都要承载信息密度，模型一旦放飞就会写成读后感。所以本文的重点会放在分块策略、摘要层数、提示词结构和结果校验上，而不是堆参数。

本文会带你完成：环境自检与推理服务启动、长文本切分与递归摘要的实现、六句话摘要的提示词与结构化输出、传播力归因的第二轮分析、接口 API 与批量任务封装、显存与吞吐的观察方法，以及最常见的那几个坑怎么排。适合做 RAG、文档摘要、内容分析、多语言处理的开发者，也适合想把一本书、一份长报告快速压成可读结论的内容工作者。

1. 核心能力速览

先把这条流水线的能力边界摆清楚。它不是“一键读书”，而是“可控压缩 + 可控归因”。

几个需要提前说清楚的点：

第一，六句话是输出端的硬约束，不是模型的原生能力。模型不会自动知道“六句话”该怎么分配信息量，你得用提示词规定每句话负责哪个维度，否则它很可能用三句话讲剧情、一句话讲作者、两句话抒情。

第二，递归摘要会损失细节，而且损失是不可逆的。第一次分块摘要丢掉的信息，后面再多次总结也找不回来。所以分块粒度和每层摘要的保留策略，比模型选型更影响最终质量。

第三，“为什么风靡全球”这类问题属于归因，不是抽取。归因必须给模型明确的候选维度，否则它会输出一堆正确但空洞的形容词。这一点在第 5 章会具体演示。

从材料看，这个任务本身没有指定技术栈，所以下面的部署和调用都按通用实践给模板，路径、端口、模型名、接口地址都需要你按自己实际部署的服务替换。

2. 适用场景与使用边界

先说适合谁。第一类是做长文本处理的开发者：你手上有大量超过上下文窗口的文档，需要先压缩再检索，这条流水线就是 RAG 的前置环节。第二类是内容分析和研究场景：想从一部长篇作品里提取稳定的叙事结构、主题分布、情感走向，用模型做初筛比人工通读快得多。第三类是教育和技术写作：把一本厚书压成可讲解的提纲，六句话正好是一个课时的引入材料。

再说边界，这部分比功能更重要。

版权边界。原文文本的获取和使用要合法。自己购买的电子书用于个人阅读分析，和把全书文本上传到第三方服务、或把大段原文重新分发，是完全不同的性质。做摘要实验时，建议只保留章节级切片做本地处理，输出结果以摘要和要点为主，不要附带大段原文摘录。公开展示的示例，尽量用简介、目录、公开章节做替代素材。

事实边界。模型生成的摘要可能出现人物关系错位、情节顺序颠倒、把不同部的设定混在一起。六句话压缩天然会放大这种错误，因为每句话都在承担超额信息。所以摘要结果必须回查原文，尤其是人名、关键事件、结局走向这类硬事实。

归因边界。“为什么风靡全球”是一个包含市场、出版、翻译、影视改编、读者社群等多重因素的复合问题，纯文本模型只能给出文本内部的解释，比如成长叙事、代入感、世界观规则清晰。外部因素必须由你补进去，或者明确标注为模型推测。不要把一个语言模型的归因输出当成研究结论直接发布。

合规边界。涉及真实人物、真实事件、未成年人相关内容的摘要与传播，需要额外谨慎。生成内容如果用于公开发布，建议保留人工复核环节，并在必要时标注“AI 辅助整理”。

还有一条容易被忽略：这类摘要工具最大的风险不是算错，而是让人误以为读过了。作为工程实践它很香，作为阅读替代品它不合格。这个定位要在团队内部说清楚，否则后面所有质量讨论都会跑偏。

3. 环境准备与前置条件

环境这块按通用清单来，具体版本号以你实际安装的框架文档为准，不要照抄别人的版本组合。

操作系统层面，Linux 在长文本批处理和显存管理上更省心，Windows 也能跑，但要注意路径分隔符、编码和长文件名问题。如果做容器化部署，镜像里要预置好 CUDA 运行时和 Python 依赖，避免每次启动重新装包。

语言与依赖层面，建议用独立的虚拟环境隔离，Python 版本跟随所选推理框架的要求。核心依赖通常包括推理框架本体、分词器、HTTP 客户端、以及文本处理的辅助库。安装顺序建议是：先确认显卡驱动和 CUDA 可用，再装框架，最后装业务依赖，这样出问题时定位范围小。

硬件层面，重点看三件事：显存、内存、磁盘。显存决定单次能处理多长的上下文和多大规模的模型；内存决定分块与拼接过程中会不会被大字符串撑爆，几十万词的文本在内存里反复拼接很容易吃掉好几个 G；磁盘决定你能不能放下模型权重和多层中间结果。

端口层面，本地服务默认端口容易和已有服务冲突，启动前先查一遍占用情况。

下面是一段通用的环境自检脚本，命令本身是标准的，具体输出需要你按本机情况判断：

# 环境自检通用示例，请按本机实际情况调整 python --version pip --version # 查看显卡与驱动状态（NVIDIA 环境） nvidia-smi # 查看框架是否装好、是否识别到 GPU python -c "import torch; print(torch.__version__, torch.cuda.is_available())" # 查看端口占用，把 8000 换成你准备使用的端口 # Linux / macOS lsof -i :8000 # Windows PowerShell netstat -ano | findstr :8000

判断标准很直接：torch.cuda.is_available()返回True说明框架和驱动对上了；nvidia-smi能看到显卡型号和显存总量；端口查询没有输出说明可以安全使用。

如果 CUDA 不可用，先别急着重装框架，按这个顺序排查：驱动版本是否支持当前 CUDA 运行时、框架安装的是 CPU 版还是 GPU 版、虚拟环境里是否存在多个版本的运行时互相覆盖。这三条能解决大部分“明明有显卡却用不了”的问题。

另外准备一份最小素材。不要一上来就丢整本书，先用一章、一节、或者一篇三千字左右的长文跑通全流程，确认切分、摘要、拼接、输出四步都正常，再放大到全书。这个习惯能帮你省下大量等待时间。

4. 安装部署与启动方式

部署路线有两条，选哪条取决于你的隐私要求和调用频率。

路线一是本地推理服务。优点是数据不出本机，适合处理有版权或隐私要求的文本；缺点是要自己扛显存和启动维护。常见做法是用主流的本地推理框架加载模型权重，暴露一个兼容 OpenAI 风格接口的 HTTP 服务。

路线二是调用云端模型接口。优点是免部署、上下文窗口通常更大；缺点是要传文本出去，版权和隐私敏感的材料不适合。

下面给的是本地服务的通用启动模板，脚本名、模型标识、端口都要按你实际使用的框架替换：

# 通用启动模板：请把 <框架入口>、<模型标识>、<端口> 换成实际值 # 示例仅展示参数组织方式，不代表任何具体项目的固定命令 python -m <框架入口> serve \ --model <模型标识或权重目录> \ --host 127.0.0.1 \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85

几个参数的含义值得说清楚。--host用127.0.0.1表示只允许本机访问，如果你需要局域网内其他机器调用，才改成0.0.0.0，但那样务必配合防火墙和访问控制，不要把一个无鉴权的推理服务直接暴露在公网。--max-model-len决定单次请求的最大上下文长度，它同时影响显存占用和能一次吃下多少文本，调大之前先确认显存够用。--gpu-memory-utilization是显存占用比例，留一点余量给系统和其他进程，别顶到 1.0。

如果用容器方式，思路是一样的，把模型目录挂载进去，端口映射出来，注意容器内的 CUDA 版本要和宿主机驱动匹配。这里不给具体镜像名，因为不同框架的镜像命名差异很大，按官方文档来更稳妥。

启动之后，第一件事不是马上跑业务，而是做一次健康检查：

# 健康检查：确认服务已就绪，地址与路径按实际部署调整 curl http://127.0.0.1:8000/health # 查看模型列表（如果框架提供该接口） curl http://127.0.0.1:8000/v1/models

服务返回正常后，再看一眼显存占用，记下空载基线。这个基线很重要，后面你判断“是我的请求太长”还是“服务本身泄漏”时，就靠这个对照。

WebUI 方式适合先手动试提示词。很多本地框架自带对话界面，你在界面上反复调六句话摘要的提示词，找到稳定版本后再固化进脚本。这个顺序比反过来高效得多：先用界面找感觉，再用代码做批量。

5. 功能测试与效果验证

这一章按功能分小节，每节都给测试目的、输入、步骤、预期、判断标准和常见失败原因。所有测试都建议先用小素材跑，再放大。

5.1 基础六句话摘要测试

测试目的：验证模型在明确约束下，能否稳定输出固定句数、且信息不重复的摘要。

输入素材：选一个有完整起承转合的章节或短篇，两三千字为宜。

操作步骤：先构造一个带维度约束的提示词，不要只说“用六句话总结”。给维度，模型才知道每句话该干什么：

你是长文本摘要助手。请阅读下面的文本，输出恰好 6 句话的中文摘要。 六句话分别承担以下职责，顺序固定： 第 1 句：核心设定与世界规则（故事发生在什么环境、遵循什么规则） 第 2 句：主角的初始状态与核心诉求 第 3 句：推动情节的关键冲突 第 4 句：主角在冲突中的关键选择与代价 第 5 句：结局走向与主题落点 第 6 句：这段文本为什么能吸引读者（只基于文本内部证据，不要引入外部信息） 输出要求： - 恰好 6 句，每句不超过 60 字 - 不出现"总之""可以看出""本文"等套话 - 不引用原文超过 10 个连续字 - 如果某一句缺乏文本依据，写"文本未提供充分依据" 文本如下： <在此粘贴文本>

预期结果：六句话结构清晰，第 6 句能给出具体原因而不是空泛形容词。

判断成功的标准：句数准确、维度对得上、人名和事件没有明显错位、第 6 句有可回查的文本依据。

常见失败原因：模型把六句话写成三段（每句话塞两个分句）；第 6 句变成“因为很精彩”这种无效归因；输出带了“以下是摘要”的前缀。前两个问题靠提示词加约束和示例解决，第三个靠输出后处理剥离。

5.2 长文本分块与递归摘要测试

测试目的：验证超过上下文窗口的文本能否被完整覆盖，不丢章节。

输入素材：整本书或一份几万字的长报告，按章节切成多个文件。

操作步骤：两级摘要。第一级对每个块单独摘要，第二级把所有块的摘要合并后再摘要。下面给一个通用骨架，接口地址和模型名需要替换：

# 递归分块摘要通用骨架，请按实际服务地址与接口调整 import os import requests API_URL = "http://127.0.0.1:8000/v1/chat/completions" # 按实际部署替换 MODEL = "<模型标识>" HEADERS = {"Content-Type": "application/json"} CHUNK_PROMPT = """请把下面这段文本压缩为 5 条要点，保留：人物、关键事件、因果关系、结果。 不要评价，不要抒情，不要引用超过 10 个连续字。 文本： {text} """ MERGE_PROMPT = """下面是同一部作品的各章节要点。请据此输出恰好 6 句话的整体摘要， 六句话依次覆盖：设定、主角起点、核心冲突、关键选择、结局主题、吸引力来源。 要点如下： {points} """ def call_model(prompt: str, max_tokens: int = 1024) -> str: payload = { "model": MODEL, "messages": [{"role": "user", "content": prompt}], "temperature": 0.2, "max_tokens": max_tokens, } resp = requests.post(API_URL, headers=HEADERS, json=payload, timeout=300) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] def chunk_by_paragraph(text: str, max_chars: int = 3000): """按段落累积切块，避免把一句话从中间切断""" chunks, buf = [], "" for para in text.split("\n"): if len(buf) + len(para) + 1 > max_chars and buf: chunks.append(buf) buf = para else: buf += "\n" + para if buf else para if buf: chunks.append(buf) return chunks def summarize_file(path: str) -> str: with open(path, "r", encoding="utf-8") as f: text = f.read() chunks = chunk_by_paragraph(text) points = [] for i, c in enumerate(chunks, 1): out = call_model(CHUNK_PROMPT.format(text=c)) points.append(f"[块{i}] {out}") print(f"完成 {i}/{len(chunks)}") merged = call_model(MERGE_PROMPT.format(points="\n".join(points)), max_tokens=1200) return merged if __name__ == "__main__": result = summarize_file("./inputs/chapter01.txt") os.makedirs("./outputs", exist_ok=True) with open("./outputs/summary.txt", "w", encoding="utf-8") as f: f.write(result) print(result)

预期结果：每个块都有要点产出，合并后的六句话能覆盖全篇而不是只覆盖开头。

判断成功的标准：块数统计完整、没有空块、合并摘要里能追溯到大结局相关的内容。

常见失败原因：切块把一句话切断导致要点残缺；块太大超出上下文；中间层要点丢掉了伏笔类信息，导致结局那句没有依据。切块时按段落而不是按字符硬切，能解决第一个问题。

5.3 结构化输出测试

测试目的：验证模型能否按要求输出 JSON，方便后续程序消费。

提示词里明确要求返回 JSON，并给出字段定义和示例。同时把温度调到较低值，减少格式抖动。

{ "title": "作品名", "six_sentences": { "setting": "第 1 句", "protagonist_start": "第 2 句", "core_conflict": "第 3 句", "key_choice": "第 4 句", "ending_theme": "第 5 句", "appeal_reason": "第 6 句" }, "evidence": { "appeal_reason": ["可回查的文本依据 1", "依据 2"] }, "uncertainty": ["文本未提供充分依据的维度"] }

判断成功的标准：能直接json.loads解析、字段齐全、evidence里有可以回查的内容而不是空数组。

常见失败原因：模型在 JSON 外面包了 ```json 代码围栏或者加了解释性文字。处理方式是在提示词里明确“只输出 JSON，不要任何额外字符”，同时在代码侧做一次容错提取，从第一个{到最后一个}之间截取再解析。

5.4 传播力归因测试

测试目的：验证模型在归因任务上，是否能给出有依据的解释而不是空话。

关键在提示词：不要让模型自由发挥，先给它候选维度，让它逐条判断文本是否有支撑。

下面是一个故事的摘要。请判断以下五个维度中，哪些能在文本中找到明确依据， 哪些属于推测，哪些没有依据。逐条给出判断和依据，不要给整体评价。 维度： A. 世界观规则清晰、读者容易理解 B. 主角起点低，成长路径明确，读者容易代入 C. 存在稳定的情感锚点（友情、亲情、归属感） D. 冲突分层，既有眼前的危机也有长期的目标 E. 语言门槛低，阅读节奏快 输出格式：每个维度一行，格式为"维度代号 | 有依据/推测/无依据 | 具体依据或说明"

这个结构的好处是把“为什么风靡全球”拆成了可验证的小问题。模型如果某条没依据，会明确说没依据，而不是硬凑。

判断成功的标准：每条判断能对应到摘要里的具体内容，至少有一两条是“推测”或“无依据”，如果全是“有依据”，说明模型在迎合提问，需要调整提示词或在温度上再压低。

5.5 批量任务测试

测试目的：验证多文件连续处理时的稳定性和资源表现。

准备一个输入目录，放五到十个文件，跑一轮全量，重点观察三件事：是否有个别文件失败、显存是否持续增长、总耗时是否随文件数线性上升。这三点在下一章展开。

# 批量处理通用脚本，路径与命令按实际项目替换 mkdir -p ./outputs for f in ./inputs/*.txt; do name=$(basename "$f" .txt) echo "处理: $name" python summarize.py --input "$f" --output "./outputs/${name}.json" if [ $? -ne 0 ]; then echo "失败: $name" >> ./outputs/failed.log fi done

批量跑的时候一定要记录失败清单，不要用“跑完了”当成功标准。批量任务里最常见的不是整体挂掉，而是中间某几个文件悄悄失败，你事后才发现结果少了几份。

6. 接口 API 与批量任务

上一章的脚本其实已经用到了接口，这一章单独说清楚调用方式和批量设计。

主流本地推理服务普遍提供兼容 OpenAI 风格的对话接口，路径通常是/v1/chat/completions，但具体路径、字段名、返回结构需要以你实际部署的框架文档为准。下面是通用调用示例：

# 通用 curl 调用示例，地址、模型名、路径均需按实际部署替换 curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "<模型标识>", "messages": [ {"role": "system", "content": "你是严谨的长文本摘要助手，只输出六句话。"}, {"role": "user", "content": "请用六句话总结以下文本：<在此粘贴文本>"} ], "temperature": 0.2, "max_tokens": 800 }'

Python 侧的调用前面已经给过，这里补充几个工程细节。

第一，超时时间要给足。长文本请求的响应时间可能是几十秒到几分钟，不要用默认的几秒超时，否则你会以为是模型出错，其实是客户端先断了。

第二，失败重试要有退避。直接循环重试容易把服务压垮，建议每次重试间隔递增，并且限制最大重试次数。

# 带退避的调用封装，仅示意重试逻辑 import time import requests def call_with_retry(url, payload, retries=3, base_delay=2): last_err = None for attempt in range(retries): try: resp = requests.post(url, json=payload, timeout=300) resp.raise_for_status() return resp.json() except Exception as e: last_err = e wait = base_delay * (2 ** attempt) print(f"第 {attempt + 1} 次失败，{wait}s 后重试：{e}") time.sleep(wait) raise RuntimeError(f"重试耗尽：{last_err}")

第三，批量任务要控制并发。本地单卡服务的并发能力有限，同时发太多请求只会让每个请求都变慢，还容易触发显存峰值。稳妥的做法是从并发 1 开始，逐步加，观察响应时间和显存曲线，找到你这台机器的拐点。

第四，任务要可断点续跑。批量处理几十个文件时，中途挂了不该从头再来。简单做法是输出目录里已经有同名结果就跳过：

# 断点续跑逻辑示意 import os def should_skip(output_path: str) -> bool: return os.path.exists(output_path) and os.path.getsize(output_path) > 0

第五，批量任务的配置文件建议外置，把输入目录、输出目录、句数、并发数、模型标识都写进去，不要硬编码在脚本里。这样换素材、换模型时只改配置：

{ "input_dir": "./inputs", "output_dir": "./outputs", "model": "<模型标识>", "api_url": "http://127.0.0.1:8000/v1/chat/completions", "sentence_count": 6, "chunk_max_chars": 3000, "max_concurrency": 1, "request_timeout": 300, "retry": { "times": 3, "base_delay": 2 } }

关于“批量”还有一个容易被忽略的点：中间结果要落盘。分块摘要的每块要点都存一份，这样合并阶段出问题时不用重新跑一遍第一级，直接调提示词重跑合并即可。长文本处理里，节省下来的时间主要来自这里。

7. 资源占用与性能观察

这一章讲怎么观察，不讲具体数字。原因很简单：显存占用和吞吐量跟模型规模、量化方式、上下文长度、批处理大小都强相关，任何脱离环境给出的数字都可能误导你。

显存观察最直接的方式是另开一个终端持续采样：

# 持续采样显存占用，间隔 1 秒 nvidia-smi --query-gpu=timestamp,memory.used,memory.total,utilization.gpu \ --format=csv -l 1

跑一次长文本请求，观察曲线上的三个点：请求前的基线、请求峰值、请求结束后的回落。基线看服务本身的开销，峰值看你这次请求的最大压力，回落看有没有释放干净。如果请求结束后显存没有回落到基线附近，说明可能有缓存没清理，连续批处理时就会越跑越紧。

第二个观察维度是上下文长度的影响。同样是摘要任务，输入三千字和输入三万字，显存占用和响应时间都不是线性关系。稳妥的做法是固定模型和参数，只改chunk_max_chars，从 1500 开始每次翻倍，记录响应时间和是否发生截断，找到你这个环境下的合适值。这个实验成本很低，但能避免大量“为什么摘要不完整”的困惑。

第三个维度是递归层数。两级摘要和三级摘要的质量差异，往往不如你想象的大，但耗时差异很明显。如果第一级的要点保留得足够好，两级通常就够用。层数越多，信息损失和延迟都在累积。

降低显存占用的常规手段有这么几个：缩短单次上下文长度、减少并发、使用更小规模或量化程度更高的模型、把不需要的部分挪到 CPU。前两个是参数调整，后两个是部署选择。要提醒的是，量化会带来质量波动，摘要任务对细节保真度有一定要求，量化程度过高时容易出现人名错位、因果颠倒，建议做一次对比测试再决定。

避免端口冲突和进程残留也有讲究。服务异常退出后，端口有时仍被占用，重启会报地址已被使用。排查顺序是：先查端口占用，找到进程号，确认是自己启动的推理服务再终止，不要盲目杀掉不认识的进程。

# 端口排查通用流程 lsof -i :8000 # Linux / macOS，找到 PID kill <PID> # 确认是该服务后再终止 # Windows PowerShell netstat -ano | findstr :8000 taskkill /PID <PID> /F

还有一个实践建议：把空载基线和一次标准请求的耗时记在一个小本子上，每次换模型、改参数、升级驱动之后重新测一遍。有了对照，你才能在出问题时快速判断是环境变了还是输入变了。

8. 常见问题与排查方法

下面这些是在长文本摘要流水线里出现频率最高的问题，按现象归类。

除了表格里的这些，还有两个场景值得单独说。

一是长文本里夹带表格、公式、脚注。这类内容在分块时容易被切断，导致摘要出现意义不明的片段。处理方式是在切块前先做清洗，把脚注编号、页码、页眉页脚去掉，表格单独成块并标注类型。

二是多语言素材。如果你处理的是外文原版再翻译成中文摘要，建议分两步走：先用原语言摘要保证理解准确，再翻译成中文。一步到位的跨语言摘要，在专有名词上出错率明显更高。

9. 最佳实践与使用建议

第一，先固定一套最小可运行配置。模型标识、上下文长度、分块大小、温度、重试次数，这五项定下来存档，后面所有对比实验都以它为基础。没有基线的调参全是玄学。

第二，输入、中间结果、最终输出分三个目录管理。输入放原始切分文件，中间结果放每块要点，最终输出放结构化摘要。目录分开的好处是排查问题时能精确定位到哪一层出了偏差，而不是对着一坨结果发呆。

第三，提示词版本化管理。六句话摘要的提示词一定会反复改，建议每次改动都留一份，标注改动原因和效果差异。用文件名带日期的方式就够了，不必上复杂工具。

第四，把校验环节做成固定步骤。至少检查三项：句数是否为 6、JSON 能否解析、关键人名是否出现在原文中。这三项能挡掉大部分低级错误，而且实现成本很低。

第五，批量任务一定要有日志和失败清单。日志记录每个文件的开始时间、耗时、状态，失败清单单独一份。跑完先看失败清单，再看结果数量，最后抽查几份内容。这个顺序不能乱。

第六，接口服务只对本机或内网开放。如果确实需要外部访问，加鉴权、限流、访问日志三件套。一个无鉴权的推理服务暴露出去，风险不只是被人白嫖算力。

第七，涉及版权素材的处理要有明确约定。原文不落地到不受控的环境，输出以摘要和要点为主，公开演示时替换成公开可用的素材。团队内部最好有一条明确规则：哪些材料可以上传、哪些只能本地处理。

第八，归因类结论必须标注来源类型。哪些是文本证据支持的，哪些是模型推测的，哪些是你补充的外部信息，在输出里分开写。这条在对外发布时尤其重要。

第九，定期做人工抽检。模型摘要的稳定性会随着输入类型变化而波动，比如叙事类文本表现好，不代表技术文档表现也好。抽检不用多，每批抽两三份，人工读一遍，问题能提前发现。

第十，别把六句话当成终点。这条流水线真正的价值是把长文本变成可索引的中间层，六句话只是最外层的展示形态。往上可以接 RAG 检索，往下可以拆成章节级、人物级、事件级的细粒度索引，那才是能持续复用的东西。

10. 总结与下一步

回到最初的问题：六句话能不能读完一本书。从工程角度，能压缩出六句结构清晰、覆盖主要叙事维度的摘要，这件事本身是可实现的，前提是你接受它必然会丢信息。真正决定质量的不是模型多大，而是分块是否合理、提示词是否给了明确维度、中间结果有没有落盘、结果有没有校验。

最先值得验证的功能，是 5.1 里的带维度约束的六句话摘要。它不需要长文本，一段两三千字的素材就能跑，能最快暴露你这条流水线的提示词问题。跑通之后再加上分块和递归，难度是递进的。

最容易踩的坑有三个：一是切块按字符硬切，把句子切断；二是没有中间结果落盘，合并阶段一出问题就得全量重跑；三是归因任务不给候选维度，模型输出一堆正确的废话。这三个都不是模型能力问题，是流程设计问题。

下一步可以往两个方向扩展。一个方向是把摘要结果接进检索引擎，做成“先摘要索引、再原文召回”的两段式 RAG，长文档问答的准确率会有明显改善。另一个方向是把六句话的结构化成字段，做跨作品对比分析，比如不同作品的冲突类型分布、情感锚点类型分布，这类结构化数据比自然语言摘要更适合做统计和可视化。

如果想再往前一步，可以试试让模型在输出六句话的同时，为每句话附上可回查的原文位置。这一步会显著提升结果的可信度，也会逼着你在分块阶段就保留位置信息，属于一次不大但很值得的架构调整。