技术 · 进阶
大表格先建索引，别整本喂给 AI
索引一次，查询千次
把「让 AI 读一份 1.7GB 的 Excel」从一次性硬啃改成可复用流水线：**先一次性扫全表建索引（编号 → 名称/规格/单价/子表/行号/图片位置）**，之后每次出清单只读索引 + 命中的几张图，1.7GB 源表再也不打开。本页给全流程五步、为什么有效的机理、适用边界、六问自测，以及表格场景专属的 7 个坑（行号 0 起还是 1 起、重号覆盖、整行漏收、公式在手机端空白等）。
方法 · 一图看懂
1
先判该不该建索引 — 「源表结构稳定」+「需要反复查」两条同时成立才建；只读一遍就完的任务，建索引比直接读还贵
2
一次性扫全表，抽成索引 — 每条记录抽：业务编号 → 名称、规格、单价、所在子表、行号、图片位置；产物是几百 KB 级的清单文件（实战里 1.7GB 压成 889.9KB）
3
非文字资产按编号单独存 — 图片、附件天生不在单元格里，靠「读文字」带不出来；导出后按业务编号命名另存，索引里只留文件引用
4
日常查询只读索引 — 出报价、出清单时只喂索引 + 命中的那几张图；源表不再进上下文，每天出清单从大半天压到几分钟
5
查不到也不中断 — 编号缺货、查不到就直接列进缺货清单提醒，不因为一条缺失停下整批——优于事后被客户发现少了东西
原理 · 为什么有效
「查字典」不是「把字典从头抄一遍」。源表稳定、结构化、几乎不变，把它整本塞进上下文，等于每次查询都重付一遍全量读取的成本与出错概率——而每次重读，都可能翻车在不同的地方。一次性抽取把「每次读全量」换成「读一次 + 反复读索引」：模型每次只拿到「地址」，不再拿「整本书」，上下文占用、耗时、出错面同时下降。代价是索引会过期：源表一变就必须重扫，否则你查的是一张过期地图。
适用场景
适合：体量大（几百 MB 到 GB 级）、结构稳定、需要按编号反复查的表格 —— 报价单、物料清单、台账、对账单、历史订单。
不适合：只读一遍就完的一次性任务（建索引的固定成本收不回来）；表结构天天在变的（索引追不上改，维护成本反超收益）；以及需要跨表做复杂关联计算的（该上数据库或写脚本，不是靠一份索引清单）。
自测 · 7 问
你的源表是不是「结构稳定 + 要反复查」两条都成立？缺一条就先别建索引。
索引里有没有行号、图片位置这类定位字段？没有的话，查到了也取不回原文。
图片、附件这类非文字资产，是不是已经按业务编号单独存了？
行号用的是 0 起还是 1 起，跟导出工具对齐过了吗？差 1 会让整表图片上移一行，肉眼几乎看不出来。
有没有同一个编号对应两条记录？默认的「后者覆盖前者」会让其中一条静默消失。
索引条数和源表有效行数对得上吗？对不上，就是有整行被收录规则漏掉了。
需要给客户看的那些公式列，在手机 / 微信预览里显示得出来吗？
怎么上手 · 验证步骤
按这个顺序做，七个坑都在对应位置：
1. 先用常规工具打开源表 —— 打不开（异源软件导出、格式不规范）就绕开：xlsx 本质是压缩包，拆开按需读某一块。
2. 抽索引，同时解决「图片和行怎么对上」 —— 浮动图片不属于任何单元格，答案在图片自身的坐标（贴在第几行第几列），先定位行、再读该行的编号；⚠️ 行号有两套算法（0 起 / 1 起，差 1），用错了整表图片整体上移一行，最后只能导 PDF 逐行核对才抓得出来。
3. 查重号 —— 同编号对应两个产品时，程序默认后者覆盖前者，一款产品静默消失；重复编号自动加后缀（如 编号#356）。
4. 查漏行 —— 收录规则要求「纯编号」，运营却在编号栏写了产品名，这批行会被整行漏掉；判据是「索引搜不到、但表里确实存在」，单独捞出来补进索引。
5. 处理图片位置 —— 图片全挤在格子左上角时要手算偏移量（Excel 内部单位极细，一像素≈九千多个单位）。
6. 公式改成算好的数字 —— 只写公式不存结果，手机 / 微信预览里就是空白；这份表是发给客户看的，不是给人回去改公式的，稳定比优雅重要。
7. 统一图片格式 —— 某些多帧内部结构会让程序崩，插入前统一重存为标准格式，顺带压缩。最后把整条链路固化成固定动作（可沉淀成「技能」，一句话触发）。
拿三条记录做回查：① 索引里的行号回源表打开那一行，名称 / 单价对不对得上；② 带图的几行，索引指向的是不是这张产品的图 —— 重点看首行和最末行，行号错 1 最容易在两端暴露；③ 索引条数 vs 源表有效行数，差额能不能逐条说清是哪一类行（重号 / 漏收 / 空行）；④ 随便报一个不存在的编号，看它是不是进缺货清单，而不是让整批中断。