把 Gemini 3.6 Flash 这类低延迟模型放进文档处理流程，通常要把任务拆成「输入准备」「提示词约束」「输出校验」三段。模型调用是这三步里最直接的一步，真正影响字段质量和流程稳定性的，反而是前一步的文本整理，以及后一步的结果核验。缺少任何一段，输出都更容易出现字段缺失或格式混乱。

低延迟模型适合处理中短文档的结构化提取、摘要和分类；复杂版式、超长文本和扫描件必须先做文本化预处理。提示词要提前约束输出格式，并用「未提及」规则压制推测补全。结构化输出不能直接充当入库结果，金额、日期、编号等关键字段至少要做一轮人工抽检。

先把文档变成模型能读的文本

部分多模态接口可以直接接收 PDF 或图片，但直接传文件的抽取效果会随版式和清晰度波动。更可控的做法是先把文档统一整理成纯文本，再进行下一步。处理顺序可以这样安排：

• PDF 优先检查是否带文字层：用 PDF 文本抽取工具直接导出，速度快且不易乱码；导出内容为空或乱码，基本可以判定为扫描件。
• 扫描件先走 OCR：保证扫描分辨率足够，同时识别后要抽查关键字段，确认字母和数字没有混淆。
• 转成文本后先看阅读顺序：多栏版式、表格和页眉页脚经常打乱顺序，需要确认关键字段是否被切到不同位置。
• 超长文档按页或按章节拆分：每个分块保留少量重叠，比如上一块末尾多留几十个字，避免跨块信息被切断。

文本化这一步之所以值得花时间，是因为它让流程可审计、可回放。后续提示词调整或模型版本变化，都可以用同一份文本输入对比输出变化，而不必重新处理原始文件。

用提示词把输出形状锁死

文档处理任务最容易出现的现象，就是模型不按约定格式输出：字段多出来、日期格式漂移、找不到的信息被补全。建议在提示词里把字段清单、输出格式、缺失信息处理方式一次性写清楚。下面三个模板可以按任务类型直接改。

模板 A：结构化字段提取（合同、发票、单据类）

请从以下文档中提取字段。
字段清单：合同编号、签署日期、甲方全称、乙方全称、合同金额、付款条件。
输出要求：只输出 JSON，不要解释。
缺失字段：必须写「未提及」。
金额字段：只保留阿拉伯数字和货币单位。
文档内容：
{文档文本}

模板 B：长文摘要（会议纪要、报告类）

请按以下结构整理这份会议记录：
1. 决议事项
2. 负责人和截止时间
3. 遗留问题
如果信息在原文中没有出现，写「未提及」，不要推测。
只输出中文，不要附加开场白。
会议记录：
{文本块}

模板 C：多文档快速分类（归档、筛选场景）

判断下面每个片段属于哪种类型：合同、发票、规范、其他。
对每个片段输出：编号、类型、判断依据（不超过15个字）。
片段：
{文本块列表}

模板中的「{文档文本}」是占位符，替换成实际内容即可。「缺失字段写未提及」这条规则值得保留，它把模型的猜测行为转换成显式标注，后续校验时更容易定位遗漏项。在实际接入时，提示词本身也建议带上版本号，例如在请求参数或输出元数据里标记 prompt_v1.2，方便批量跑完后追溯是哪一版提示词产生的结果。

参数建议与结果校验

模型参数对文档任务的影响，主要集中在稳定性和措辞变化上。结构化提取任务建议把 temperature 调到接近 0，保证同源文档的重复处理结果一致。摘要类任务可以把数值放宽到 0.3-0.5，让措辞更自然，但不要继续调高，否则容易发散。输出长度按任务本身设置，而不是提前给一个很大的值，因为多余输出会稀释关键字段的密度。不同 API 服务对参数的支持和默认值可能不同，接入时先结合环境确认这些配置是否生效。

结果校验建议从三个角度入手：

• 硬字段逐一核对：金额、日期、编号不能因为格式合法就信任，需要对同一批原始文档逐条比对。
• 格式一致性检查：连续处理多份同类文档时，同一字段的写法容易漂移。
• 反向检查「未提及」：模型推测为未提及的内容，需要确认原文里确实不存在。

校验的产出不是「本次有多少条相符」这一类计数，而是决定哪些字段可以自动化流转、哪些字段必须保留人工兜底。建议留一批历史文档做回归样本，后续每次调整提示词，都拿这批样本重跑一遍，观察字段分布是否变化。

判断边界：不是所有文档都适合 Flash 类模型

超长合同如果条款密集、金额分散出现在多个章节，单次输入容易漏项，需要拆分后交叉核对。财务附注或合并单元格较多的表格，文本化之后结构信息会大量丢失，单纯靠模型补结构风险较大。另一个值得注意的场景是下游环节对审计要求严格的任务，比如金融或司法材料，模型输出只能作为中间结果，整套流程要保留原始文件、文本版本和提示词版本，供后续追溯。

判断一条文档处理流程是否跑通了，标准不是「模型有没有给出回复」，而是字段稳定、缺失可查、格式统一、回归样本不退化。达到这几点，再把流程逐步交给自动化处理，会更稳妥。