长文档拆解成结构化大纲的提示词工程实操教程

👁 67 次阅读

先把目标说清：大纲不是目录，而是可执行的结构

很多团队把长文档拆解理解成让模型生成一份目录，结果得到的是漂亮但不可用的标题列表。真正可执行的结构化大纲，至少应包含六类信息：章节层级、主题句、支撑要点、关键术语、证据位置、块间关联。章节层级决定阅读顺序，主题句说明这一节解决什么问题，支撑要点让后续写作或问答有素材，关键术语避免同义混用，证据位置保证每个结论都能回到原文，块间关联则处理交叉引用和前后照应。
在写提示词之前，先把字段定下来。字段一旦确定，提示词就有了验收标准；字段不固定，模型就会在每次调用时自由发挥，后续归并会非常痛苦。建议用一张字段表约束输出，例如块编号、章节路径、候选主题、支撑要点、关键术语、证据片段、关联块编号。字段不必多，但每个都要能被人工复核。
还要区分抽取与生成。抽取式任务要求模型从原文找信息，允许留空或标注需回看原文；生成式任务才允许概括和改写。长文档大纲更适合先抽取、后归并、再少量改写。这个顺序能显著降低编造和遗漏。

拆解流程总览：分块抽取、块间归并、全局校验

一个可复用的流程是：清洗文档、按结构分块、块级抽取、分批归并、全局校验、格式化输出。每一步都产生可检查的中间产物，不要把全部工作压进一次提示词。清洗阶段保留标题层级和段落边界；分块阶段给每块编号并记录章节路径；抽取阶段只输出块级要点；归并阶段把相似主题合并成树；校验阶段专门找缺口和冲突；输出阶段再转换成 Markdown、YAML 或表格。
这样做的好处是可控。模型一次只处理有限上下文，注意力更集中；中间结果可以抽样检查；出错时能定位到某个块或某次归并，而不是面对一份无法追溯的大纲。对于很长的文档，可以先把章节标题和首段抽出来做一级骨架，再对每章内部做二级展开。骨架负责稳定层级，块级抽取负责填充细节。
建议给中间文件统一命名，例如 chunks/part_001.txt、extract/part_001.yaml、merge/round_01.yaml、outline/final.md。命名稳定后，脚本和人工复核都能复用。下面给出一组分块命令和最小脚本，参数只是示例，实际按文档长度和模型上下文调整。

步骤一：清洗与分块，给每块留锚点

清洗时优先做四件事：统一换行符，去掉重复页眉页脚，保留标题标记，保留表格标题与注释。不要把表格直接删掉，表格往往承载关键约束。分块时优先按标题切，其次按段落边界切，最后才按长度硬切。硬切容易切断条款和论证，必须保留前后重叠段落，或者在块首写明上一块结尾主题。每块都要带块编号和章节路径，这是后续追溯的锚点。
可以用一个简单的 Python 脚本先跑通分块。下面的示例按空行分段，再按长度上限合并，输出到 chunks 目录。生产环境可以再加入标题识别和重叠窗口。

from pathlib import Path

def split_text(text, max_chars=3500):
    paras = [p for p in text.split(chr(10) + chr(10)) if p.strip()]
    chunks = []
    buf = ''
    for p in paras:
        if len(buf) + len(p) + 2 > max_chars:
            if buf:
                chunks.append(buf)
            buf = p
        else:
            buf = buf + chr(10) + chr(10) + p if buf else p
    if buf:
        chunks.append(buf)
    return chunks

raw = Path('long.md').read_text(encoding='utf-8')
parts = split_text(raw)
out = Path('chunks')
out.mkdir(exist_ok=True)
for i, part in enumerate(parts, 1):
    (out / f'part_{i:03d}.txt').write_text(part, encoding='utf-8')

运行方式可以写成：

python split_doc.py --input long.md --max-chars 3500 --out chunks

注意脚本示例没有实现命令行参数解析，实际使用时可以把参数接到 argparse，或先用固定路径跑通。分块后人工抽查几块，确认标题、条款编号、表格说明没有被切断，再进入抽取。

步骤二：写块级抽取提示词，只抽不编

块级抽取的目标不是写漂亮标题，而是把这一块里可用的结构信息提取出来。提示词建议写成五段：角色、输入、任务、约束、输出格式。角色要限定为结构分析助手；输入要带块编号和章节路径；任务要明确列出字段；约束要强调只抽取原文、不扩写、信息不足时留空；输出格式要固定，方便后续脚本解析。
下面是一个可复制的模板。方括号内容按实际替换，输出字段可以按文档类型增删。

你是一名长文档结构分析助手。请只做抽取，不做扩写。
输入：
块编号：{chunk_id}
章节路径：{section_path}
正文：
{chunk_text}
任务：
1. 提取该块候选主题，最多三条。
2. 提取支撑要点，每条不超过一行。
3. 标记关键术语和定义。
4. 给出可回查的证据片段，保留原文关键词。
5. 如果发现与其他块的关联线索，写入关联线索。
约束：
- 所有要点必须来自输入正文。
- 信息不足时写『需回看原文』，不要补全。
- 不要生成最终目录，不要改写原文标题。
输出字段：
chunk_id
section_path
candidate_topics
supporting_points
terms
evidence
links

配置侧建议把温度调低，输出长度设上限，避免模型在一小块里写成长篇摘要。一个 YAML 配置示例如下，参数按实际模型调整。

task: chunk_extract
temperature: 0.2
max_output_tokens: 1200
instruction: 只抽取原文信息，不扩写，不补全
output_fields:
  - chunk_id
  - section_path
  - candidate_topics
  - supporting_points
  - terms
  - evidence

抽取完成后不要急着合并。先抽查若干块，看是否出现三类问题：把例子当主题、把背景当结论、证据片段与要点对不上。发现后改提示词，而不是逐条手工修。提示词里可以加一句『优先保留原文中的名词短语和编号』，对制度、手册类文档很有用。

步骤三：归并块级结果，生成可追溯的树状大纲

归并阶段处理的是块级结果，不是原文全文。先把块按章节路径排序，再把候选主题聚类。归并提示词要模型做四件事：合并同义主题、保留来源块编号、标出冲突、控制层级深度。不要一次把所有块塞进一个提示词，可以按章节分批归并，再对章节结果做一级归并。分批的边界尽量与原文结构一致，减少跨章误合。
归并提示词可以这样写：

你是一名大纲编辑。请把下列块级抽取结果合并成树状大纲。
输入：{batch_id} 的块级结果列表。
任务：
1. 按章节路径建立父子关系。
2. 合并同义或高度重叠的主题。
3. 每个主题保留来源块编号。
4. 发现同一主题下要点冲突时，单列冲突说明。
5. 层级不超过四级，标题使用名词短语。
约束：
- 不新增原文没有的主题。
- 无法判断归属的要点放入待定区。
- 每个二级主题至少有一个来源块编号。
输出格式：
一级主题
  二级主题
    支撑要点
    来源块：part_001、part_004

归并结果建议保存为中间文件，不要直接当最终稿。可以要求模型同时输出一个待定区，把无法归类的要点放进去。待定区往往暴露分块问题或原文结构不清，后续人工处理比强行归类更可靠。对于跨章节重复出现的概念，可以建一个术语表，在大纲中用统一名称，并在来源块里保留不同表述。

步骤四：校验提示词，检查覆盖、层级与证据

校验是独立步骤，不要让归并模型顺便自查。校验提示词只做检查，不直接重写。检查三件事：覆盖、层级、证据。覆盖看每个块是否至少被一个主题吸收，或是否进入待定区；层级看父子关系是否合理，有没有把并列要点塞进子节点；证据看每个支撑要点能否回到来源块。还可以检查标题是否空泛、术语是否统一、表格内容是否遗漏。
校验提示词示例：

你是一名大纲质检员。请检查给定大纲与块级结果的一致性。
输入：大纲、块级结果列表、块编号清单。
任务：
1. 列出未被任何主题覆盖的块编号。
2. 列出层级关系可疑的节点，并说明原因。
3. 列出缺少证据或证据不匹配的要点。
4. 列出标题空泛、同义重复、术语不一致的节点。
5. 输出修正建议，不要直接重写全文。
约束：
- 只依据输入材料判断。
- 建议要指向具体节点或块编号。
- 无法判断时标注『需人工复核』。

人工复核时优先看三类节点：一级主题是否覆盖主要章节，二级主题是否回答该章核心问题，支撑要点是否可执行。对于制度、合同类文档，还要检查适用范围、例外条款、生效条件是否被遗漏。校验结果可以回流到归并提示词，形成一轮修正，但不要无限循环。通常一轮校验加一轮人工修订就能达到可用状态。

步骤五：输出为可用的结构化格式

最终输出格式取决于下游用途。给人读，用 Markdown；给表格工具，用 CSV；给程序消费，用 YAML 或 JSON。无论哪种格式，都保留块编号和证据字段。Markdown 适合快速评审，YAML 适合后续脚本处理。下面是一个 YAML 片段示例，字段可按需增减。

outline:
  - id: sec_01
    title: 适用范围与基本原则
    level: 1
    summary: 说明文档适用对象与总体原则
    evidence: part_001
    children:
      - id: sec_01_01
        title: 适用对象
        level: 2
        points:
          - 明确适用主体
          - 明确排除情形
        evidence: part_001、part_002

如果输出 Markdown，可以用标题层级加来源块标注：

# 一级主题
## 二级主题
- 支撑要点一
- 支撑要点二
来源块：part_001、part_004

输出后做一次机械检查：每个二级主题是否有来源块，每个来源块是否真实存在，层级是否连续，标题是否重复。机械检查能拦住大部分低级错误，剩下的再交给人工判断。

提示词模板：把角色、任务、约束拆开写

提示词工程不是堆形容词，而是把任务边界写清楚。一个稳定的长文档大纲提示词通常包含：角色限定、输入说明、任务步骤、字段定义、禁止事项、输出格式。角色限定让模型进入结构分析模式；输入说明告诉它块编号和章节路径的意义；任务步骤把复杂动作拆成顺序；字段定义让输出可解析；禁止事项拦住扩写和编造；输出格式降低后处理成本。
可以准备一套三层模板：块级抽取模板、章节归并模板、全局校验模板。三层模板分开维护，不要混成一个巨型提示词。每次修改只改一层，便于比较效果。变量用花括号占位，例如 {chunk_id}、{section_path}、{chunk_text}，替换时确保不把提示词指令混进正文。对于重要项目，把模板和输出样例放在版本库里，记录每次修改的原因和抽查结果。
还有一个小技巧：在提示词中要求模型先输出『本块结构判断』，再输出字段。结构判断只需一两句，说明这块是定义、流程、条件还是例子。这样后续归并时更容易判断要点权重。不要让模型输出长篇推理，短判断即可。

不同文档类型的策略对比

不同长文档的结构差异很大，分块和提示词不能一套打天下。下面表格给出定性对比，实际使用时按文档特点调整。

文档类型	主要难点	分块策略	提示词重点	验收要点
制度规范	条款交叉引用多，例外条件多	按章节和条款编号切分，保留上下条	抽取适用主体、动作、条件、例外	条款编号可回查，例外不遗漏
研究报告	论证链长，图表与结论分离	按研究问题和章节切分，图表单独成块	抽取问题、方法、发现、限制	结论有证据，限制条件保留
技术手册	步骤依赖强，前置条件多	按任务和步骤切分，保留命令上下文	抽取前置条件、步骤、结果、故障处理	步骤顺序正确，命令不截断
会议纪要	发言分散，决议与讨论混杂	按议题切分，保留发言人与时间线	抽取议题、决议、待办、责任人	决议与讨论分开，待办可执行
书籍章节	概念递进，例子多	按小节切分，概念定义单独成块	抽取概念、论证、例子、前后关联	概念不重复，层级不过深
合同条款	定义与义务交织，引用密集	按条款和定义切分，保留引用关系	抽取主体、义务、权利、违约、例外	定义一致，义务主体明确

表格里的策略不是固定规则，而是起点。制度规范更怕漏例外，技术手册更怕步骤断裂，研究报告更怕结论脱离证据。写提示词时把对应风险写进禁止事项，比泛泛要求『准确』有效得多。

常见失败模式与修正方法

第一种失败是大纲过细。模型把每个例子都提升为二级主题，导致层级膨胀。修正方法是限制层级深度，要求二级主题必须能回答一个章节问题，例子只能作为支撑要点。第二种失败是标题空泛，例如『相关内容』『其他说明』。修正方法是要求标题使用名词短语，并优先保留原文中的小标题和编号。
第三种失败是跨块重复。同一概念在多个块出现，归并时没有合并。修正方法是先建术语表，再在归并提示词中要求同义合并并保留来源块。第四种失败是证据丢失。大纲看起来合理，但要点找不到原文依据。修正方法是把证据字段设为必填，校验阶段专门列缺少证据的节点。第五种失败是表格和注释被遗漏。修正方法是在清洗阶段保留表格标题，在分块时让表格单独成块，并在校验清单中加入表格覆盖检查。
还有一种隐蔽失败是提示词把抽取和改写混在一起。模型一边找信息一边润色，最后很难判断哪句来自原文。修正方法是拆成两轮：第一轮只抽取，第二轮只做有限改写，且改写必须保留来源块编号。对于高要求场景，可以让第二轮只改标题，不改支撑要点。

可执行建议：今天就能跑起来的最小闭环

先选一篇结构清楚、长度适中的文档，不要一上来处理全部资料。按本文流程跑一个最小闭环：清洗并分块，抽取前三个块，归并成一个小树，做一次校验，人工抽查来源块。重点观察三件事：块编号是否贯穿始终，证据是否能回查，标题是否比原文更清楚。跑通后，再把分块脚本参数化，把三层提示词模板固化到版本库，并为不同文档类型各留一份配置。
建议把每次输出都保留中间文件，不要只存最终大纲。中间文件是调试提示词的依据，也是团队协作的接口。每周抽一份文档做回归测试，比较修改前后的覆盖率和人工修订量。最后提醒一句：提示词负责约束模型，流程负责兜底。先把字段、分块、归并、校验四件事做扎实，再追求更漂亮的标题和更复杂的自动化。