文档摘要和表格整理都能交给 Gemini agent 处理，但两类任务的失败点不在同一处：摘要类任务的失败常常是读漏细节，或者概括时把事实改掉；表格类任务的失败常常是字段错位、单位不统一。因此判断顺序建议是，先看手上材料是连续文本还是结构化表格，再决定单次调用要拆成几步，而不是先去纠结哪类任务更适合 Gemini agent。通常的做法是，摘要类任务先固定输出骨架（要点条数、必须原样保留的实体），表格类任务先固定字段映射（目标列名、来源列、空值规则），再按读取、处理、输出三段分开调用。
如果只问哪类任务更适合 Gemini agent，通常是两者都能做，差别在可校验程度。表格整理的结果能用行数、列名、单位去比对，出错位置比较容易定位；文档摘要的结果依赖语义判断，更需要在事实层面做人工核对。建议先按读取、处理、输出三段拆开，每段留一个能对回原文或源表的产物，再根据材料规模决定是否合并成一次调用。
分别写出文档摘要和表格整理的任务目标
任务目标写得含糊，后面的拆解和检查就无从下手。建议把两类任务的目标都写成四段：输入范围、输出形态、必须保留项、禁止项。下面两个提示词骨架可以直接改成自己的内容，只需替换尖括号部分。
任务：对输入文本做摘要
输入：<正文，超长时按小节分两次传入>
输出：3-5 条要点，每条不超过 40 字；末尾一句 60 字以内总述
必须保留：人名、机构名、日期、金额、条款编号，原样照抄
禁止：补充原文没有的原因和结论；原文未提到的写「原文未说明」任务：把输入表格整理成固定列
输入：<表头行 + 数据行，跨页时每段都带上表头>
输出列：日期 | 事项 | 责任人 | 金额 | 备注
规则：日期统一为 YYYY-MM-DD；金额只留数字并统一到元；缺失值留空，不推测
输出格式：CSV，首行为列名两类任务的结果样例形态差别很大。摘要的结果是少量句子，对错要人来读；表格整理的结果是行数和列名都能数的结构，可以先写一小段脚本比对行数、列名和取值枚举，再去看内容是否对得上。
比较两类任务的输入结构差异
输入结构直接决定 Gemini agent 的读取方式和出错位置，下面这张对照表可以用来快速判断手上这份材料该按哪种方式拆。
| 对比维度 | 连续文本（文档摘要） | 结构化表格（表格整理） |
|---|---|---|
| 读取方式 | 按顺序读，语义依赖上下文 | 按行列读，语义主要靠表头 |
| 分段方式 | 按标题或段落切，小节之间保留少量重叠 | 按行块切或按列分组，每段都要重复表头 |
| 对齐关系 | 摘要句 ↔ 原文位置 | 目标列 ↔ 源表列 |
| 常见失败 | 跨段指代错、数字与主体错配、概括时加了因果 | 合并单元格、跨页表头丢失、单位混用造成错位 |
| 可自动校验的点 | 较少，基本靠人工核对事实 | 较多，行数、列数、枚举值、合计都能脚本比对 |
由此可以得到一条保守建议：把表头和前几行样例一起传给 Gemini agent，通常比只传数据体更稳；长文档按小节传入，并把上一节末尾一小段带进下一节，通常比整篇一次传入更稳。这两种做法都属于降低单次任务的复杂度，不涉及模型本身的行为改动，具体是否有效还要结合自己的材料看输出。
把大任务拆成可验证的小步骤
通用拆解按读取、处理、输出三个阶段走，每个阶段留一个能被检查的产物。拆到什么粒度可以用一句话判断：如果这一步的产物没法和原文或源表对上，就说明还没拆到位。
task: 文档摘要
steps:
- id: read-1
action: 按小节切分输入，列出小节标题
check: 小节数量与原文标题数量一致
- id: extract-1
action: 逐节抽取人名、日期、金额
check: 每个实体都能在原文检索到
- id: merge-1
action: 合并去重实体
check: 去重后条数不多于各小节之和
- id: write-1
action: 生成要点与总述
check: 每条要点都能指回某一小节表格整理用同一套骨架，只改内容和校验条件：读取步骤换成读表头和前几行样例，检查项是列名与源表一致；处理步骤负责行列映射和单位统一，检查项是输出行数与源表数据行数一致；输出步骤生成 CSV，检查项是首行列名与约定顺序一致。三个阶段分开之后，出错位置通常能直接落到某一步，重跑范围也跟着缩小。
为每类任务设置人工检查点
检查点建议放在输出之后、进入正式存档或入库之前，不要塞在流程中间。中间态往往不适合人读，来回插入人工确认也容易打断连续处理。
文档摘要的事实核对点：
- 数字与日期：是否与原文一致，有没有把区间写成单点；
- 否定词与范围词：不、除、仅、至少这类限定是否被保留；
- 主体归属：动作由谁发出，有没有张冠李戴；
- 引用内容：引号内的表述是否原样，有没有被顺手改写；
- 总述部分：有没有出现原文没写的因果或判断。
表格整理的数据对齐点：
- 列名映射：目标列能否一一对应到源列，有没有凭空新增的列；
- 行数：输出行数与源表数据行数是否一致，合并单元格拆开后是否补全；
- 单位与量纲：金额、数量是否统一单位，千分位与百分号是否处理干净；
- 空值语义：空白和 0 是否被区分，缺失值有没有被填入推测内容；
- 重复与合计：有无重复行，合计行能否与明细对上。
用同一份材料跑一次拆解后的任务
想判断拆解是否真的有用，建议用手上同一份材料各跑一次，把过程按下面的结构记录下来。记录重点是错误出现在哪一段、修正时要重跑多少，而不是哪一次输出看起来更顺眼。
材料：一份多页会议纪要 / 一份几百行的报销表
做法A（未拆解）：一次调用直出摘要或整表
做法B（拆解后）：读取 - 处理 - 输出三段，逐步保留中间产物
记录项：
- 错误出现在哪个阶段
- 修正时需要重跑的步骤
- 输出与原文或源表的对齐方式记录几次之后一般会看到三种情况：错误集中在读取阶段，说明切分方式或表头传递需要调整；错误集中在处理阶段，说明字段映射规则写得不够明确；错误均匀散布在最终输出里，说明任务可能还要继续往下拆。拆解也有代价，调用次数变多，去重和拼接的工作转移到流程里，这部分属于取舍，可以结合自己的材料规模和核对能力决定拆到哪一层。