扩写的正确姿势：人工先锁框架，AI 按提纲填段落，别让它自由发挥

一、问题的重新定义：扩写失败不是能力问题，是控制权问题

把一段三百字的提纲交给模型，要求扩写成三千字，多数情况下模型能交出通顺的文本。但只要逐段核对，问题就会暴露：第二段把第五段的论据提前用掉了，第四段的篇幅只有第一段的三分之一，某个关键数据在三个段落里被"重新表述"了三遍，而提纲里明确要求展开的技术细节被一笔带过。文本读起来没问题，结构却塌了。

这类现象在工程实践中被反复记录。Anthropic 在2024年发布的长上下文提示工程指南中指出，当任务要求模型在长输出中维持多个约束时，约束的遵守率会随输出长度增加而下降，且下降并非线性，而是在输出中后段出现明显衰减^[1]。Google DeepMind 团队在2023年的"Lost in the Middle"研究中给出了更具体的证据：模型对上下文中部信息的利用率显著低于首尾部分，这一效应在需要跨段落保持一致性的任务中尤为致命^[2]。

本文评述：把上述现象简单归因为"模型能力不足"是偷懒的解释。更准确的描述是——扩写任务本质上是一个多约束满足问题，而当前主流的自回归生成方式并不天然擅长处理"全局约束"。模型逐token生成，每一步只对已生成内容做局部条件化，它没有一张全局的结构地图。当人类把"写一篇结构合理的长文"这个任务整体抛给模型时，等于要求它在生成第一个字之前就隐式规划好全文结构，并在几千字的生成过程中始终不偏离——这恰恰是自回归解码最不擅长的事。

所以问题应该重新表述：不是"模型能不能写好"，而是"结构决策权应该放在谁手里"。人类擅长全局规划、取舍判断、逻辑校验；模型擅长局部展开、语言组织、风格迁移。扩写流程的设计目标，就是让两者各司其职，而不是让模型"自由发挥"。

核心判断：扩写质量的方差，主要来自结构控制权的分配方式，而非模型参数规模。同一模型在"自由发挥"与"提纲约束"两种模式下，输出结构一致性差异可达数倍（基于笔者对公开评测集的人工复核，属整合观察，非受控实验数据）。

这一判断有可检验的推论：如果控制权分配是主因，那么即使换用更强的模型，"自由发挥"模式的结构问题依然存在；反之，即使使用中等规模模型，只要提纲约束到位，结构一致性也能显著改善。后文第三章到第六章给出的流程，正是围绕这一推论设计的可操作路径。

二、理论支撑：为什么提纲能约束生成漂移

2.1 自回归解码的局部性缺陷

自回归语言模型的生成过程可形式化为 P(y_t | y_<t, x)，即每个token只条件依赖于提示 x 和已生成前缀 y_<t。这意味着模型在写第800字时，对"全文还剩多少字""第1200字要讲什么"没有显式表征。它只能通过注意力机制间接访问提示中的提纲信息，而注意力权重会随距离衰减、被中间内容稀释。

Liu 等人2023年的研究量化了这一衰减：在需要从长上下文中间位置检索信息的任务中，模型准确率相比首尾位置下降超过20个百分点，且该现象在不同规模模型上普遍存在^[2]。本文评述：这解释了为什么"把提纲放在提示开头、然后让模型一口气写五千字"的做法效果不稳定——提纲在生成后段实际上已经"淡出"了模型的注意力焦点。

2.2 结构化提示的约束效应

2024年前后，多项工作开始系统研究"结构化提示"对输出可控性的影响。微软研究院在2023年的"Prompting Is Not All You Need"系列讨论中提出，将任务分解为显式的结构化槽位（slot），可以显著降低模型在长输出中的指令漂移^[3]。Wei 等人提出的思维链（Chain-of-Thought）虽然主要针对推理任务，但其核心机制——用显式中间步骤约束生成路径——同样适用于长文扩写^[4]。

更直接的证据来自结构化解码方向。2024年，多篇工作探索了在解码阶段施加语法或模式约束（如JSON Schema、正则表达式）来保证输出格式^[5][6]。这类方法把"结构约束"从提示层面下沉到解码层面，从概率上排除了不合规的输出路径。

笔者认为，提纲约束的作用机制可以类比为"软性的结构化解码"：提纲不直接干预token概率，但通过把长任务切分为多个短任务，让每个短任务的生成都重新以提纲片段为强条件，从而在工程上逼近结构化解码的效果。这是"分块生成"策略的理论依据。

2.3 检索增强与外部记忆的启示

RAG（Retrieval-Augmented Generation）在2020年由Lewis等人提出后，2023—2025年经历了从"检索文档"到"检索结构化知识"的演进^[7]。其核心思想——在生成时动态注入外部信息，而非依赖模型参数记忆——对扩写流程有直接借鉴意义。

本文评述：把提纲的每个节点视为一个"检索键"，在生成对应段落时把该节点的完整信息（包括前文已写内容摘要、后文待写内容摘要、关键术语表）作为上下文注入，本质上是在做"结构化检索增强"。这比单纯把全文提纲塞进系统提示更有效，因为它保证了每个段落的生成都处在"信息新鲜"的状态。

机制	作用层面	对长文扩写的意义
注意力衰减	解码	提示中部的提纲信息易被忽略
结构化提示	提示	显式槽位降低指令漂移
结构化解码	解码	从概率上排除不合规输出
检索增强	上下文	按需注入段落级上下文

三、阶段一：人工锁框架——提纲的颗粒度设计

3.1 提纲颗粒度的三档划分

提纲太粗，模型自由发挥空间过大，结构依然会漂；提纲太细，人工成本高且丧失模型的语言优势。实践中可以把提纲颗粒度分为三档，按文章类型选择。

档位	颗粒度	适用场景	单段目标字数
粗提纲	章级 + 要点	创意文案、观点评论	400–800
中提纲	节级 + 论据槽位	技术教程、产品文档	200–400
细提纲	段级 + 首句 + 术语表	学术综述、合规报告	120–250

本文评述：颗粒度的选择本质上是在"人工成本"与"结构风险"之间做权衡。一个可操作的判据是——如果某段落的论证依赖前文某个具体结论，就应把它拆到段级并显式标注依赖关系；如果某段落只是并列陈述，节级颗粒度即可。

3.2 提纲的六要素结构

一个能真正约束模型的长文提纲，每个节点至少应包含六个要素。这套结构参考了技术写作中的"信息映射"（Information Mapping）方法，并结合长文生成的约束需求做了扩展^[8]。

节点ID: S3.2
标题: 提纲的六要素结构
目标字数: 350
核心论点: 六要素结构能把"写什么"和"怎么写"分离，降低模型歧义
论据槽位:
  - 要素定义（人工填写）
  - 方法来源（需引用）
  - 操作示例（人工提供或模型生成后校验）
依赖节点: S3.1（颗粒度划分）
禁止内容: 不要展开具体工具推荐（留给第七章）
术语表: 信息映射 / 论据槽位 / 依赖节点
首句锚点: "一个能真正约束模型的长文提纲，每个节点至少应包含六个要素。"

六个要素中，依赖节点和禁止内容是最容易被忽略、但对抑制漂移最有效的两项。依赖节点告诉模型"这段可以引用前文哪个结论"，避免重复论证；禁止内容告诉模型"这段不要碰什么"，避免越界。

3.3 篇幅分配的量化方法

篇幅失衡是自由发挥模式的典型症状。人工锁框架时，应把总字数按节点权重显式分配。一个实用的权重公式：

节点字数 = 总字数 × (节点权重 / 权重总和)

节点权重 = 0.4 × 论证复杂度 + 0.3 × 信息密度 + 0.3 × 读者关注度

其中三项均按 1–5 分人工打分。
（该公式为笔者基于技术写作实践提出的经验模型，非受控实验结论）

举例：一篇12000字的文章，某节点论证复杂度4分、信息密度3分、读者关注度5分，权重为 0.4×4+0.3×3+0.3×5=4.0。若全文权重总和为100，则该节点分配约480字。这个数字写进提纲，模型生成时就有了明确的长度目标。

四、阶段二：上下文锚定——给每一段装上"定位销"

4.1 什么是上下文锚点

上下文锚点（context anchor）指在生成某个段落时，随该段落提示一并注入的、用于定位该段在全文位置的信息集合。它至少包含四类：前文摘要、后文预告、术语表、风格样本。

这一思路与2024年多篇长文本生成工作提出的"层次化上下文管理"一致。例如，Meta 在2024年关于长文档摘要的研究中采用"滚动摘要"策略，即每生成一部分就压缩为摘要供后续使用^[9]。本文评述：滚动摘要解决的是"前文太长"的问题，而锚点机制进一步解决了"后文未知"的问题——让模型知道"我这段是为哪段做铺垫"。

4.2 锚点的生成与维护

锚点不必全部人工撰写。可操作的流程是：人工写提纲时给出"前文摘要"和"后文预告"的要点，由模型在每段生成完成后自动更新滚动摘要，供下一段使用。具体步骤如下：

1. 初始化：人工为每个节点填写"前文依赖"和"后文铺垫"两个字段，各限50字以内。
2. 生成时注入：生成节点 N 时，提示中包含：节点 N 的提纲、节点 N-1 的实际输出摘要（150字）、节点 N+1 的提纲要点。
3. 生成后更新：用模型对节点 N 的实际输出生成150字摘要，写入滚动摘要缓冲区。
4. 术语一致性：维护一张全局术语表，每次生成时注入当前节点涉及的术语条目。

【系统提示】
你是技术文章扩写助手。严格遵守以下规则：
1. 只写当前指定节点，不越界到其他节点内容
2. 目标字数误差不超过 ±15%
3. 首句必须使用给定的"首句锚点"
4. 不重复前文摘要中已出现的论据
5. 术语使用必须与术语表一致

【当前节点】
ID: S4.2  标题: 锚点的生成与维护  目标字数: 380
核心论点: 锚点可半自动维护，人工给要点，模型做压缩
论据槽位: 滚动摘要机制 / 四步流程 / 提示词结构

【前文摘要（节点S4.1实际输出）】
……（150字）

【后文预告（节点S4.3提纲）】
讨论锚点注入的token成本与优化策略

【术语表】
上下文锚点：生成段落时注入的定位信息集合
滚动摘要：每段生成后压缩的递进式摘要

4.3 token 成本与优化

锚点注入会增加每次调用的输入token量。按上述结构，单次生成输入约600–900 token，输出300–500 token。若全文30个节点，总输入约2万–2.7万token，输出约1万–1.5万token。以2025年主流API定价区间估算，成本可控，但需注意两点优化：

• 滚动摘要严格限长，超过150字即触发再压缩，避免累积膨胀。
• 术语表按节点动态裁剪，只注入当前节点涉及的条目，而非全表。

关于长上下文模型的成本特性，可参考 Anthropic 官方文档中的上下文管理章节^[1]，以及 OpenAI 的提示缓存（prompt caching）机制说明^[10]——后者对重复注入的提纲部分可显著降本。

五、阶段三：分块生成——切分策略与提示词工程

5.1 切分粒度与生成顺序

分块生成的核心决策是：按什么顺序生成。常见有三种策略，各有适用场景。

策略	顺序	优势	风险
顺序生成	从头到尾	上下文自然累积	前段错误向后传播
骨架优先	先写各段首句	先锁定全文节奏	首句与展开可能脱节
依赖拓扑	按依赖图排序	被依赖段先写	需人工维护依赖图

本文评述：对技术文章，推荐"骨架优先 + 依赖拓扑"的混合策略——先让模型为所有节点生成首句（此时不注入前文，避免干扰），人工快速审一遍节奏，再按依赖拓扑逐段展开。这样既锁定了全文骨架，又保证了论证顺序。

5.2 提示词的四段式结构

经过多轮迭代，一个稳定的扩写提示词可归纳为四段式：角色与规则、当前任务、上下文锚点、输出格式。第四章已给出示例，这里补充几个工程细节。

规则要可判定。"写得专业一些"不可判定，"不使用第一人称""每段不超过4句"可判定。规则条数控制在5–7条，过多会互相稀释。

输出格式要显式。要求模型输出纯段落文本，不要markdown标题、不要自加小标题。否则回填时还要清洗。

温度参数要低。扩写任务推荐 temperature 0.3–0.6。过高会导致术语漂移和事实发挥，过低会导致句式重复。这一区间是笔者在多类技术文本上的经验值，具体应结合模型版本调整。

5.3 长段落的二次切分

当单节点目标字数超过600字时，建议二次切分为2–3个子块，每个子块单独生成。原因在第二章已述：输出越长，约束衰减越明显。二次切分时，子块之间共享同一节点提纲，但各自有不同的"子论点"。

节点 S5.3（目标600字）拆分为：
  S5.3-a（250字）：问题陈述 + 现象举例
  S5.3-b（200字）：机制解释 + 引用
  S5.3-c（150字）：工程建议 + 过渡句

三个子块共享：节点核心论点、术语表、前文摘要
各自独有：子论点、首句锚点

六、阶段四：校验回填——一致性检查与事实核验

6.1 三类校验

生成完成不等于任务完成。回填前必须过三道校验，缺一不可。

1. 结构校验：逐节点核对字数是否在目标±15%内、首句是否为锚点句、是否越界写了禁止内容。
2. 一致性校验：检查术语是否统一、同一论据是否被重复展开、前后结论是否矛盾。
3. 事实校验：所有数据、引用、人名、年份必须回溯原始来源。模型生成的具体数字默认不可信，除非提示中已提供。

关于事实校验的必要性，2023年多项幻觉研究给出了量化证据：在开放域问答中，即使是最强模型，无检索支撑时的事实错误率仍显著高于有检索支撑的场景^[11][12]。本文评述：扩写场景下，模型倾向于"补全"它认为合理的细节，这些细节往往看起来专业但并无出处，因此事实校验必须作为独立环节，不能与结构校验合并。

6.2 自动化校验脚本思路

结构校验和一致性校验可部分自动化。以下是一个伪代码思路，供工程实现参考：

for node in outline:
    text = generated[node.id]
    # 1. 字数校验
    assert abs(len(text) - node.target) / node.target < 0.15
    # 2. 首句校验
    assert text.startswith(node.anchor_sentence[:10])
    # 3. 禁止词校验
    for kw in node.forbidden:
        assert kw not in text
    # 4. 术语一致性
    for term in node.terms:
        assert term in text or term not in node.required_terms
    # 5. 重复论据检测（与滚动摘要做相似度比对）
    sim = cosine_sim(embed(text), embed(rolling_summary))
    assert sim < 0.85

# 事实校验单独走人工 + 检索流程

这套脚本能拦下大部分结构性问题，但拦不住"看起来对、实际错"的事实问题。事实校验建议采用"检索比对"：对每个含数字或引用的句子，用检索工具回查原始来源，人工确认。

6.3 回填与终稿润色

校验通过后回填，还需做一轮全文润色，重点处理三类问题：段落衔接、指代消解、节奏调整。这一轮建议人工主导，因为衔接质量依赖对全文意图的理解，模型容易"过度平滑"而抹掉必要的转折。

工程经验：回填后的终稿润色，人工修改量通常占全文5%–12%（基于笔者对若干技术文档项目的观察统计，属整合经验数据）。低于5%往往意味着提纲过细、模型发挥空间被压缩；高于15%则说明提纲约束不足或模型选择不当。

七、工程化落地：工具链、模板与自动化脚本

7.1 最小可行工具链

不必一上来就搭复杂系统。一个最小可行工具链只需要三样东西：一个提纲编辑器（YAML/JSON即可）、一个调用脚本、一个校验脚本。

组件	推荐方案	说明
提纲编辑	YAML + 任意编辑器	结构清晰，易版本管理
生成脚本	Python + 官方SDK	支持重试、日志、缓存
校验脚本	Python + 正则 + 嵌入模型	结构校验自动化
版本管理	Git	提纲与生成结果同仓管理

7.2 提纲 YAML 模板

meta:
  title: "文章标题"
  total_words: 12000
  style: "技术、克制、少形容词"

terms:
  - name: "上下文锚点"
    def: "生成段落时注入的定位信息集合"

nodes:
  - id: S1
    title: "问题的重新定义"
    target: 800
    thesis: "扩写失败是控制权问题，不是能力问题"
    args: ["失败模式举例", "注意力衰减证据", "控制权分配框架"]
    depends: []
    forbidden: ["具体工具推荐"]
    anchor: "把一段三百字的提纲交给模型……"
    prev_summary: ""
    next_preview: "理论支撑：提纲为何能约束漂移"

7.3 与现有工具的衔接

如果已经在用某些写作工具，可以把上述流程嵌入。例如，用 Obsidian 管理提纲节点，用其插件调用API；用 Notion 的数据库管理节点状态；用 LangChain 或 LlamaIndex 组织提示链。相关教程可参考：

• Anthropic 官方提示工程文档：https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering
• OpenAI 提示缓存指南：https://platform.openai.com/docs/guides/prompt-caching
• LangChain 结构化输出教程：https://python.langchain.com/docs/how_to/structured_output/
• LlamaIndex 长文档处理：https://docs.llamaindex.ai/en/stable/

本文评述：工具只是载体，关键是把"提纲—锚点—生成—校验"这条流水线固定下来。工具换了几轮，流程不变，经验才能积累。

八、边界与反例：哪些场景不该锁框架

8.1 创造性写作

小说、诗歌、广告创意的价值恰恰在于"意外"。过度锁框架会把生成压成模板，抹掉语言的新鲜感。这类场景建议用"粗提纲 + 高温度 + 多候选"，把框架约束降到最低，靠人工筛选而非结构约束来保证质量。

8.2 探索性研究综述

当作者自己还不确定文章结论时，过早锁框架会固化错误方向。这类场景建议先做"自由探索式生成"——让模型就主题生成多个视角的短文本，人工阅读后再提炼提纲。框架是探索的产物，不是探索的前提。

8.3 强时效性内容

新闻快讯、实时评论等场景，框架约束的收益低于时效损失。此时更适合"检索 + 短生成 + 快速人工审"，而非完整四阶段流程。

场景	推荐框架强度	理由
技术文档	强（细提纲）	结构可预期，一致性要求高
学术综述	强（细提纲）	引用与论证链要求严
创意文案	弱（粗提纲）	需要语言意外性
探索性综述	先弱后强	结论未定，框架后置
新闻快讯	弱	时效优先

九、前沿预判：从提示词约束到结构化生成协议

9.1 结构化生成协议的雏形

2024—2025年，业界开始出现"结构化生成协议"的雏形。OpenAI 在2024年推出的 Structured Outputs 功能，允许开发者用 JSON Schema 约束模型输出^[13]。Google 的 Gemini 系列也支持类似的响应模式约束^[14]。这些能力目前主要用于API返回格式，但其底层机制——在解码阶段施加模式约束——完全可以扩展到长文结构。

本文评述：可以预见，未来的长文生成工具会把"提纲"从提示词中的自然语言，升级为可校验的结构化协议。提纲不再只是给模型看的文字，而是驱动解码过程的约束条件。到那时，"人工锁框架"将从"写提示词"演变为"定义Schema"。

9.2 多智能体协作的扩写架构

2023年以来，多智能体（multi-agent）框架在复杂任务上展现出潜力。将扩写流程拆分为"规划者—写作者—审校者"三个角色，由不同模型实例承担，已在部分开源项目中实现^[15][16]。规划者负责维护提纲与依赖图，写作者负责段落生成，审校者负责一致性检查。

笔者认为，多智能体架构的价值不在于"更多模型"，而在于把不同性质的约束分离到不同角色。规划者关注全局结构，写作者关注局部语言，审校者关注一致性——这比让单一模型同时满足所有约束更符合工程直觉。但需注意，多智能体会增加调用成本和协调复杂度，对短文本任务未必划算。

9.3 评估体系的缺口

当前长文生成的评估仍以"流畅度""相关性"为主，缺乏对"结构一致性"的系统度量。2024年已有工作提出针对长文的结构评估指标，如段落主题一致性、论据覆盖度等^[17][18]，但尚未形成共识标准。

本文评述：评估缺口是制约方法迭代的关键瓶颈。没有可靠的度量，就无法判断"锁框架"到底改善了多少。建议工程团队在内部建立自己的结构评估表，哪怕粗糙，也比没有强。评估维度可包括：字数偏差率、术语一致率、论据重复率、依赖满足率。

十、结语

扩写的正确姿势，说到底是把控制权放对位置。人负责"写什么、写多少、先写谁"，模型负责"怎么把这一段写顺、写清、写到位"。提纲、锚点、分块、校验这四步，都是为了让这条分工线清晰可执行。

本文提出的流程并非唯一解，也不适用于所有场景。但它的核心判断——结构决策权应留给人——在可预见的未来仍然成立。模型会越来越强，长上下文会越来越长，但"全局规划"与"局部生成"的能力差异不会自动消失。把这条差异变成流程设计的前提，而不是指望模型自己弥合，才是工程上稳妥的做法。