把发票塞进本地4B模型，他朋友用完说不想回头

为什么一张印度餐厅的账单，能把云端发票识别服务打回原形？一位软件工程师给出的答案很直接：因为那张账单根本不该离开笔记本。

他做的是一个本地优先的应付账款工作台，名字叫 LedgerLens。把 PDF 或照片拖到本机，跑在 127.0.0.1 上的 Ollama 里，由 Gemma 3（4B） 抽取供应商、日期、税额、总额和明细行，SQLite 存历史。文件不进 OpenAI，不进 Textract，也不进某个来路不明的 SaaS。

触发点是他自己的收据堆。Swiggy 转来的餐厅小票、承包商发票、一张满是 GST 的印度收据——用美国数据训练出来的云端解析器，处理起来像在开玩笑。他试过的每一个“智能收件箱”，第一件事都是先上传文件，然后再道歉。

正方：本地跑得动，而且够用

他给出的理由带着参数感。4B 的开源权重模型小到能塞进笔记本的 GPU 或 CPU，又大到在给定 schema 时能吐出结构化的发票 JSON。他没有为这一周去微调模型，而是约束它：首次尝试绑定 schema，重试时回退到原始 JSON，再用确定性的 OCR 补全 GSTIN、CGST、₹ 和 Swiggy 式表头。

第一个真实文档是一张 Swiggy/KFC 的合并 PDF。Gemma 返回了供应商 KFC（Swiggy Limited）、发票号、日期、INR 1,092.90、分类“Meals & Dining”，以及明细行（Epic Savers Chicken Bucket、打包费）。这就是产品本身。

整条流水线是一个可轮询进度的任务：上传 → OCR（40%）→ Gemma 抽取（60%）→ 查重与规则（80%）→ 落库（100%）。OCR 文本被当作不可信输入，系统提示词里写明了这一点。他的判断是，一个把整份 PDF 当“用户”吞下去的闭源聊天 API，正是提示注入从供应商信纸走进来的路径。

反方：这套东西的门槛在哪

他自己列了要改的地方。想在 GST 发票上微调 Gemma，而不是靠正则补全；审阅面板需要真正的 PDF 渲染，字段那一侧已经扎实，预览还欠火候；以及一个一键安装包，让朋友不必知道 npm run dev 是什么意思。

最后这条来自真实反馈。他把 LedgerLens 摆到朋友 Raj 面前，让他丢一份文档进去，看着 Gemma 填满审阅面板。Raj 用了，然后大致说了句：在其他发票通用工具上，他不会再回头了。Raj 没付钱，他也没要。Raj 接下来提的需求很无聊也很正确——“别让我开两个终端”。

技术栈全部落在本地：前端 React 19 + Vite + Three.js，后端 Express + better-sqlite3（WAL）+ Tesseract + Ollama。推理走 Ollama + Gemma 3，开源权重、离线、每 token 零成本；OCR 用 Tesseract.js，扫描页不需要云端视觉 API；数据库是 SQLite WAL，一个文件，扛得住 ctrl+c。Windows 下账本存在 %LOCALAPPDATA%\LedgerLens，其他平台在 ~/.ledgerlens。

他还做了一个 3D 硬币架当导航，每枚硬币是一个工作区：概览、发票、收据、审阅、供应商、支出、自动化、报表、本地 AI、设置。这部分是额外的，Raj 真正在意的是收件箱。

我的判断

没有云端部署是故意的，整个卖点就是回环地址。他的原话逻辑是：如果把它做成托管 SaaS，他卖的就是自己拒绝买的东西。

这笔账他算得很清楚。闭源发票 API 做三件事：给文档定价，每页都是别人账单上的一个行项；转移秘密，客户 PDF 变成接近训练数据的流量；冻结模型，闭源抽取器是一个带服务条款的黑箱。而本机上的 Gemma 是沉没成本，一次 ollama pull 而已。

如果推理是每页 0.04 美元，一个月 200 张发票就是一笔费用；如果推理是用户 GPU 上的 4B 模型，产品可以是一次性工具，而不是一份会漏数据的订阅。他给付费版本的说明已经写好了：发票留在你的磁盘上，Gemma 负责打字，你点一次批准。

这套东西能不能撑起生意另说，但它至少回答了一个具体问题：一台没有联网的笔记本，能不能把别人的数据留在别人控制不了的服务器之外，并且跑起来不花钱。他的答案是三个“能”。