表格切片读：header_read 先找锚点再动手

复盘一次翻车。人事的员工台账，二百一十七行、十四列，让我检查工号有没有重复。我当时的指令是"把表格整个读一遍，检查重复工号"。AI 读完回报：第 82 行工号与第 9 行重复。人事同事去查，第 82 行没有问题——真正重复的是第 88 行。数字不会冤枉人，翻车的是我：把整张表丢给模型读，它读串了行。

这篇复盘这次翻车，讲清楚表格的正确读法：切片读，先找锚点，再动手。

错误一：把"读全表"当默认动作

二百多行的表整表读进去，模型要在几万个单元格里保持行列对位，任何一个环节滑动一行，后面的结论全部错位，而且错得很有底气——行号、内容都报得有模有样。事后分析，串行大概有两个原因：一是那张表带合并单元格，视觉上的"第三行"和坐标系里的第三行根本不是一回事；二是"第82行"从表头起算还是从数据行起算，我和 AI 没对齐口径——人以为说清楚了，机器以为理解了，两头都冤。回头看我的需求，其实只涉及两列：工号、姓名。正确的打开方式是切片读：先用 header_read 拿表头结构和每列的位置，再用 column_read 只读目标列。读得少，对得准，还省 token。

后一点展开说说。这一年大家都在谈 Token 成本优化，但表格场景里切片读的最大收益根本不是省钱——是读的范围越小，串行错位的概率越低。省 token 是副产品，降错误率才是主菜。整表读看似一步到位，实际是把风险和账单一起拉满。

错误二：没先看文档体量

后来我学乖了，拿到长文档先看元信息：文档元数据接口会给字数、段数和"是否建议分块"的提示；正文文本超过约八万字符，硬读会撞上 DOCUMENT_TOO_LARGE，正确姿势是分块接口分页往下翻。表格同理：宽表、长表都别整表丢，按列切、按块读，是长文档时代跟 AI 打交道的基本功。

正确姿势长这样

先做 header_read，把表头每一列的列名和位置列出来，不要读数据行

只读"工号"和"姓名"两列，列出工号重复的行号和对应姓名

第一步只读表头，成本极低，先让 AI（也让自己）对表格结构建立准确认知；第二步只读目标列，在小区间里做比对，重复行号一次报准。找到行号之后，后续无论改值、加批注还是插行，都按显式坐标执行——锚点校验对不上会报 LOCATE_MISMATCH，工具宁可失败，也不在错的位置上写东西。

错误三：没让 AI 先复述坐标

这次翻车后我还养成了一个习惯：任何写操作之前，先让 AI 把目标坐标复述一遍——“将处理第几行第几列”，人扫一眼就知道对不对，成本一秒钟。这一步真拦下过问题：AI 口头结论说的是第 82 行，报出来的坐标却是第 88 行，以坐标为准重新对表，错位当场现形。记住一句话：口头结论和执行坐标是两回事，盯坐标，别盯结论。结论可以错，坐标必须对，因为工具只认后者。

再进一步：锚点是所有表格操作的地基

在"合计"行上面插入一行，列结构和上一行一致

这条插行指令能准确落地，靠的也是同一套逻辑：AI 先读表定位"合计"行的锚点，换算成坐标后才执行插入。切片读找锚点，不只为"读"，更为一切后续操作打底。先看清楚，再动手——这条车间里的老规矩，在 AI 操作表格这件事上同样成立，而且因为 AI 错起来不带犹豫，这条规矩更加性命攸关。

适合谁：管人事台账、库存表、项目周报、成绩单这类"行多列多"表格的人。边界也要讲：超宽表（几十列）建议分列多次读，一次也别贪多；切片读也不是万灵药，如果比对逻辑本身要跨十几列，就老老实实分几轮读，每轮报一次坐标，别指望一口吞；切片读覆盖不到的信息不要让 AI 硬猜，它读不到就是读不到，这时候该换一种切法，而不是换一种祈祷方式。