把 PDF 对账单丢给大模型,让它提取成表格——这件事现在谁都能做,提示词写十行就行。
问题在于:它抄错一行,你怎么发现?
一份两百行的流水,模型漏掉第 47 行,或者把某一笔的借贷方向搞反,输出看起来完全正常: 日期是日期,金额是金额,格式整整齐齐。你把它导进账里,几周后对不上,再回头查是哪一步出的错。
这才是"AI 读文档"在财务场景里真正的门槛。不是识别率,是可信度。
对账单本身自带一个校验式:
`` 期初余额 + 贷方合计 − 借方合计 = 期末余额 ``
这三个数都印在对账单上。如果模型提取的流水加起来对不上印着的期末余额,那就一定有问题—— 漏了行、重了行,或者借贷方向搞反了。
所以我把它做成了工具的硬性一步:每次提取完,代码自己算一遍勾稽,对不上就明说。
我拿一份 6 笔流水的对账单,删掉其中一笔 642.30 的云服务费,但保留原本的期末余额, 然后丢给它:
``json { "balanced": false, "opening": 12400, "credits": 8300, "debits": 9195, "closing_stated": 10862.7, "closing_computed": 11505, "difference": 642.3, "note": "does NOT balance by 642.3 — a row is likely missing, duplicated, or has debit/credit swapped." } ``
差额 642.30,和我抽掉的那笔分毫不差。
完整的那份则是 "balanced": true,6 笔全出,单次成本 $0.00022。
这里有个容易被忽略的设计选择:加总和比对全部在代码里做,模型一个数字都不算。
模型擅长的是语义判断——"这一列是借方还是贷方"、"这行的日期是哪个格式"。这些几何和 正则做不了。但算术是模型最不该碰的地方:它会算错,而且算错的时候同样自信。
所以分工是:模型只负责"看懂这是什么",代码负责"算得对不对"。这样勾稽结果才是一个 独立的校验——如果让模型自己校验自己,它可能连错误一起编圆了。
做这个的过程中撞到一个自己的 bug:PDF 文本层里的中文有两个隐形坑。
一是"工"可能不是"工"——很多 PDF 把汉字映射到 Unicode 的康熙部首区(U+2F2F), 字形和正常的"工"(U+5DE5)一模一样,肉眼和复制粘贴都看不出差别,但对程序是两个字符。
二是中文会被切碎——PDF 解析库读中文时常按字拆开,拼接不当就会在字与字之间插进分隔符, "摘要"变成"摘 要",列名匹配全部失效。
修完之后中文对账单和英文一样:6 笔全出、勾稽平。如果你也在做中文 PDF 解析,这两条值得一查。
免注册、有免费额度:
`` curl "https://ainetcafe.com/t/extract_statement?url=你的对账单URL" ``
返回结构化流水 + 勾稽结果。扫描件走视觉模型(单页约 $0.007),有文本层的走确定性解析 (约 $0.0005,便宜十几倍),自动选路不用你操心。
它不替你记账,只告诉你"这份数据能不能信"。 对不上的时候它会说对不上, 而不是给你一份看起来很整齐的错数据。
---
利益披露:ainetcafe.com 是我做的,上面的工具匿名就能用。做勾稽自检这一步的原因很直接: 市面上做"AI 读对账单"的工具不少,但没有一个告诉你它这次读得对不对。 而在财务场景里,一份不知道对不对的数据,价值接近于零。
给你的 agent 接上 AI 网吧(一行 MCP)→