把 PDF 丢给 Claude 让它抽表格，拿到的东西形式上是张表，但列错位一格、本该分开的行合并了、或者数值落到错的表头下面。看着挺像那么回事，对一下源文件才发现问题。
最快的修法： 提前把准确的列名和顺序告诉 Claude，让它输出 CSV，再验三行。一条这样的 prompt 就能在重试第一次时修掉绝大多数「列错位」的情况，因为你把 Claude 原本要去猜的网格直接抹掉了：
The table on page 4 has 5 columns in this order: Name, Date, Region, Revenue, Margin. Output every row as CSV with that header. Negatives may appear as (1,234) — keep them negative.
这是 PDF 工作里最常见的失败之一，因为绝大多数 PDF 把表格存成「按坐标摆好的文本块」、没有任何行列元数据。先搞清楚底层到底怎么回事，修法会很不一样：截至 2026 年 6 月，你发一份 PDF 给 Claude 时，它会把每一页转成图片、同时抽取文本层，然后把两者放在一起推理（见 Anthropic 的 PDF support 文档）。所以它既不是纯 OCR、也不是纯坐标解析——是「视觉 + 文本」一起上。这点很关键：如果视觉层质量差（低分辨率扫描、字太小、某页被转了 90 度），或者文本层是一堆没网格的坐标块，Claude 重建出来的表就会漂。把更弱的那一层修好，准确率通常立刻上去。
先判断你是哪一类
动手改之前先花 20 秒做这个分诊。用 Preview（macOS）或 Acrobat 打开 PDF，照下面对一对。
| 你看到的现象 | 最可能的成因 | 跳到 |
|---|---|---|
| 选「一个单元格」一拖就选了整行 | 没有表结构，靠坐标推断 | 成因 1、Step 2 |
| 输出行数比源差 1 或差 2 | 合并 / 多行单元格 | 成因 2、Step 3 |
| 表头被当数据行，或者直接丢了 | 表头有样式没标记 | 成因 3、Step 2 |
| 在文件里搜不到任何文字 | 扫描图片，做过 OCR | 成因 4、Step 4 |
| 两栏报纸排版被读成一张大宽表 | 多栏页面排版 | 成因 5、Step 5 |
| 负数变正、货币消失 | 会计数字格式 | 成因 6、Step 7 |
| 整体大致对但发虚 | PDF 太密太大撑爆上下文 | 成因 7、Step 6 |
常见原因
按底层成因的命中率从高到低。
1. PDF 把文本存成坐标位置、没有真正的表结构
绝大多数 PDF（尤其是 Word、PowerPoint、扫描件导出的）按 xy 坐标摆文字。没有「第 3 行第 2 列」这种标记。Claude 靠间距加页面图片推网格，间距不规则就推错。
怎么判断：用 Preview 或 Acrobat 打开 PDF，试着只选中一个单元格。如果一拖就选了整行，说明 PDF 没有表结构。
2. 合并单元格和多行单元格让行检测乱套
跨两行的单元格、或者一个单元格里塞了一段折行文字，行推断就模糊了。Claude 要么把相邻行合并、要么把一行拆成两行。
怎么判断：数源文件的行数和 Claude 输出的行数。差 1 或差 2 就是这个特征。
3. 表头视觉上是表头、结构上没标记
表头那行用加粗显示，人看是表头，PDF 存的方式跟其他数据行一模一样。Claude 可能把表头当数据行处理或者直接丢掉。
怎么判断：看 Claude 输出第一行是列名还是数据。
4. 扫描件 OCR 出错
纯图片型 PDF 没有文本层，Claude 几乎全靠页面图片。OCR 那类错误（1 vs l、0 vs O、小数点 vs 逗号）和排版没对齐会直接传染到表格里。
怎么判断：在文档里搜任意一个词（Cmd/Ctrl+F）。搜不到说明是扫描件、没有真正的文本层。
5. 多列页面排版被当成一张大宽表
有些报告用两栏排版。Claude 可能横跨整页读、把无关的列合到一起。
怎么判断：看页面。两栏报纸式排版、中间有分栏空隙，就是这个原因。
6. 数字格式（括号负数、货币符号）
会计 PDF 经常用 (1,234) 表示负数、$1,234.56 表示货币。Claude 可能不一致地剥符号、或者把括号负数读成正数。
怎么判断：抽几个数和源文件对一下。符号错、货币丢，就是这个特征。
7. PDF 太密或太大，没到页数上限就撑爆了上下文
Anthropic 文档明确提到：密集的 PDF（很多小字号页、复杂表格、大量图形）可能没到页数上限就把上下文窗口填满，大文件即便走 Files API 也可能失败。一旦这样，靠后的页就被「读糊」了，那些页上的表格也跟着漂。
怎么判断：是只在靠后的页、或只在最密的页上准确率掉下来吗？那是这个成因，而不是表格本身的问题。
开始前
- 想清楚最终要什么形式：CSV、JSON、Markdown 表、纯文本叙述，prompt 写法都不一样。要回灌进表格，CSV + 显式表头最稳。
- 有原始 Excel 或 CSV 就直接用，从 PDF 抽永远有损失。
- prompt 之前先用 Acrobat 或 Preview 打开 PDF 看结构。
- 收集这些信息：页数和表格数、数字原生还是扫描、列数行数、有没有合并单元格、页面排版（单栏/多栏、横向），以及 Claude 输出里正确的一行和错误的一行各举一例。
一步一步修复
Step 1：先看 PDF 源结构
Acrobat 或 Preview 打开，试着选中一个单元格。一拖就选整行，那就是没有表结构、抽取要靠坐标加图片推断。先把预期摆正，也好判断是该修文件（Step 4-5）还是只修 prompt（Step 2-3）。
Step 2：prompt 里写明表格结构
提前把表格形态说清楚：The table on page 4 has 5 columns in this order: Name, Date, Region, Revenue, Margin. Extract all rows as CSV with that exact header. Numbers may use parentheses for negatives — preserve them as negative. 把列名和顺序点明，就抹掉了导致列错位的「猜网格」环节。Anthropic 自己的建议是：引用页码时用 PDF 阅读器里显示的逻辑页码，这样 Claude 能锚到正确的那一页。
Step 3：先抽一行做验证探针
让它：Read row 7 of the table on page 4 and output each cell on its own line, prefixed by its column name. 强制 Claude 锚到结构、而不是粗扫，同时能暴露出错位是从哪一格开始的，你据此修正表头列表、再跑整表抽取。
Step 4：扫描件先 OCR；复杂表先用工具抽再让 Claude 清洗
如果是扫描件，先跑一遍高质量 OCR（Acrobat Pro 的 “Recognize Text”，或 ABBYY FineReader），让真正的文本层在 Claude 看到之前就存在。带边框和合并的复杂表，先用专门工具抽出来，再把 CSV 贴给 Claude 让它修对齐和数字格式。这比让 Claude 从原始 PDF 直接抽靠谱得多。
Camelot（Python、免费）是截至 2026 年 6 月最常用的主力：单元格之间有可见框线的表用 flavor="lattice"，靠空白分隔的表用 flavor="stream"，拿不准就用 flavor="auto" 让它自己选。Tabula 和 AWS Textract 是备选；嘈杂扫描件想要托管式的 OCR 加表格模型，Textract 值得一试。
Step 5：多栏页面先拆栏再发
页面是两栏的话，先转成单栏，免得 Claude 横跨分栏空隙去读。Acrobat 里把页面导成可重排格式（或用拆分/裁剪工具），让每一栏成为独立的块再发。一次性处理零散页面时，把页面从中间裁成两半、各半单独发，也管用。
Step 6：又密又长的 PDF：拆开 + 用大上下文模型
如果是靠后的页或更密的页准确率往下掉，把文档拆成几段、每段一条 prompt 抽，然后在 Excel 里拼回去。表格密集的活用最新的大上下文模型——截至 2026 年 6 月，Claude Opus 4.7 和 Sonnet 4.6 都是 1M token 上下文，能在「读糊」之前装下多得多的密集页。API 上单次请求最多 600 页、32 MB 总量（老的 200k 上下文档位是 100 页）；Web 端遇到特别大的 PDF，最好上传前先拆开。
Step 7：会计 PDF 在 prompt 里锁死数字格式
加：Treat (1,234) as -1234. Treat $1,234.56 as the number 1234.56 with currency USD. Output two columns: amount, currency. 消除数字解析歧义、堵住符号翻转。
怎么确认修好了
- 输出表头和源文件表头一字不差、顺序也对。
- 输出行数等于源文件行数（差一格的问题没了）。
- 随机抽三行（比如第 3 行、第 15 行、最后一行）一格一格比对都对得上。
- 数字总和（如果有）能和源文件合计对上，负数也保住了符号。
这里的错误几乎都是系统性的、不是随机的——只要有一项不过，同一个缺陷通常会重复出现，修一下表头列表或数字规则，整张表就一起好了。
长期预防
- 内部报告 PDF 旁边同步发一份 CSV，下游就能完全跳过抽取。
- 扫描件先用高质量 OCR（Acrobat Pro、ABBYY）跑一遍再丢给 Claude。
- 任何可能被机器读的文档都别用两栏排版。
- 处理财务或科研数据的 Claude Project 加一条自定义指令：
When extracting tables, first echo the assumed header row for user confirmation, then output the data. - 重复性流程里搭一个 Camelot 或 Tabula 预抽取步骤，把干净 CSV 喂给 Claude。
- 如果 Claude 似乎完全无视图表和表格的视觉内容，去 Settings → Feature Preview 确认视觉 PDF 处理是开着的——老账号里有个 “Visual PDFs” 开关，它控制着图片层。
容易踩的坑
- 拿到 Claude 抽出来的表不验证就用。错误是系统性的，对几下就能抓出来。
- 直接问「把表给我」、不指定列。Claude 会自己推网格、经常推错。
- 把扫描件直接贴进去、没有真正的文本层还指望干净结果。先做 OCR。
- 忘了合并单元格和脚注行会把行检测搞乱。
- 不告诉 Claude 怎么解析括号负数，就直接当正数处理。
常见问答
- 为啥列正好差一格？ 一般是表头那个单元格折成两行了，或者第一列异常宽把网格推断带偏。在 prompt 里把表头点明（Step 2）就能修。
- Claude 能读扫描 PDF 吗？ 能——它把每页当图片、再加上抽出来的文本一起分析。质量看扫描分辨率。关键内容先单独跑一遍 OCR，让真正的文本层存在。
- 抽什么格式最稳？ CSV，prompt 里把表头显式写出来。Markdown 表好看，但回灌进表格时损失更大。
- 模型版本有差吗？ 有。新模型处理排版推断明显更好；表格密集和长文档用最新的 Claude Opus 4.7 或 Sonnet 4.6（截至 2026 年 6 月为 1M token 上下文）。
- 宽表或长表要不要拆到多条 prompt？ 要——按页或按段抽，再在 Excel 里拼回去，避免密集页上的上下文劣化。
- 大小上限是多少？ API 上单次请求最多 600 页、32 MB 总量（老的 200k 上下文模型是 100 页）。Web/App 上传遇到特别大的 PDF，先拆开再传。