InvoiceSnap AI：本地AI将收据照片转为结构化支出表

从收据到表格：一个轻量级本地AI工具

自由职业者、独立开发者和小企业主常被收据管理困扰——手动将收据信息录入电子表格既耗时又易错。InvoiceSnap AI 尝试用开源AI解决这一痛点：上传收据图片，由OCR和本地大模型提取关键信息，用户核对后即可导出CSV。

项目作者在GitHub开源了完整代码（Leafyte/InvoiceSnap），核心思路是“小步快跑”：不做大而全的记账平台，只聚焦收据扫描到结构化导出的单一工作流。

功能拆解：识别、编辑、导出

应用从收据中提取四个字段：商户名、日期、总金额和支出类别（餐饮、杂货、交通、购物、水电、办公等）。提取结果呈现在可编辑表格中，支持逐项修正、删除记录、查看总额，并导出CSV。

技术栈保持精简：后端Flask负责OCR处理、AI调用、数据规范化和API路由；前端用原生JavaScript处理上传、表格交互、浏览器存储和CSV导出。收据图片经后端处理后不保存为应用文件，支出记录存于浏览器localStorage，省去了远程数据库和账户系统。

作者强调，这一设计让代码库易于理解、修改和本地运行。

技术核心：OCR与Gemma模型的分工

工作流分为两步。第一步用Tesseract OCR读取收据文字：图片先经Pillow预处理（灰度化、增强对比度、方向校正、必要时放大），再由OCR输出原始文本。原始文本往往包含换行、识别错误和格式不一致，无法直接使用。

第二步将OCR文本发送给本地Ollama服务运行的Gemma开源模型，指令要求返回包含商户、日期、金额和类别的结构化JSON。后端随后做规范化：验证类别是否在预定义列表中，统一支持的日期格式，再将结果传给前端。

这种职责分离是关键——Tesseract负责“读”，Gemma负责“理解与组织”，Flask负责处理与校验，JavaScript负责展示与管理。作者坦言模型仍会出错，尤其在图片模糊、OCR不完整或收据上出现多个金额时，因此人工复核环节不可省略。

作为兜底，当本地AI请求失败时，应用会尝试用正则表达式和关键词规则提取信息，并标记结果供用户重点核对。

Tesseract OCR 是一个由HP实验室发起、现由Google维护的开源光学字符识别引擎。它通过训练好的语言模型将图片中的文字区域转换为可编辑文本，支持100多种语言。Tesseract对清晰、端正的印刷体识别效果较好，但对模糊、倾斜或手写内容容易出错，因此常需配合图像预处理（如灰度化、二值化、去噪）来提升准确率。在本项目中，Tesseract承担的是“从像素到字符”的底层转换，其输出质量直接决定了后续大模型能否正确理解收据内容。

Ollama 是一个用于在本地运行开源大语言模型的工具，提供简洁的命令行和API接口，支持Llama、Gemma、Mistral等模型系列。它负责模型下载、加载、推理调度和内存管理，让开发者无需深入底层框架即可在个人电脑上调用大模型。本项目通过Ollama在本地运行Gemma模型，所有AI推理请求都发往本机服务，从而避免将收据文本发送到远程API，兼顾了隐私与成本。

本地AI的价值与边界

隐私是首要考量。收据可能包含个人消费、商业支出等敏感信息，本地运行意味着图片由用户自己的电脑处理，AI请求发往本地Ollama而非远程服务商，减少了数据外发的需要。作者也明确提醒：这不等于安全保证，用户仍需自行保护计算机、浏览器数据和本地服务。

成本方面，本地运行开源权重模型避免了托管API的按次收费和使用限制，但硬件、电力、安装和维护成本依然存在。对于处理收据量可控的小工具，这一权衡值得尝试。

灵活性同样重要：模型可替换、提示词可调整、不同本地模型可针对同一批收据样本评估，开发者不必将应用绑定在单一托管服务商上。

开源权重模型 指模型参数（权重）以公开许可发布、任何人都可下载和本地运行的大语言模型，如Gemma、Llama系列。与只能通过API调用的闭源模型不同，开源权重模型允许开发者在自己的硬件上完成推理，无需按次付费，也不受服务商的使用限制或政策变更影响。代价是用户需自行承担硬件（尤其是GPU显存）、电力、安装配置和维护成本，且模型能力通常弱于顶级闭源模型。对于收据信息提取这类任务，开源权重模型已能胜任，因此成为本地优先方案的合理选择。

适用人群与商业想象

目标用户包括追踪业务支出的自由职业者、整理项目采购的独立开发者、管理收据的小企业主、整理个人开支的学生，以及需要准备支出表的顾问。作者明确表示该工具不替代会计软件，也不提供税务建议。

关于商业化，作者提出两种可能：免费本地版加付费安装协助、定制或集成服务；或面向自由职业者和小企业提供特定类别与导出要求的定制版。但他强调这些只是潜在模式，需求、提取准确率和付费意愿都需真实用户验证。

局限与改进方向

当前版本的主要挑战包括：收据图片质量参差影响OCR准确率；语言模型可能误判日期、总额或类别，财务记录需人工复核；本地运行对硬件有要求，模型启动和推理需要时间；此外缺少认证、云同步、银行集成、自动税务计算和多用户支持。

作者计划优先提升可靠性而非堆叠功能：添加样本收据用于可重复测试、改进日期与货币检测、高亮不确定或缺失字段、支持PDF发票、优化不同业务类型的分类、提供更详细的支出报表导出。

PDF发票 与收据图片的处理路径存在差异：PDF可能是扫描件（本质是图片，需先栅格化为图像再走OCR），也可能是原生电子发票（文字以文本对象存储，可直接提取而无需OCR）。后者能绕过OCR误差，提取准确率更高，但需要解析PDF结构或使用专用库。支持PDF意味着应用需判断PDF类型并选择相应处理管线，同时处理多页文档和更复杂的版面布局，这是当前版本尚未覆盖但计划扩展的方向。

小结

InvoiceSnap AI 是一个务实的开源实验：用Tesseract、本地Gemma模型、Flask和轻量前端组合出可用的收据管理流程。它证明了开源权重模型能以较低门槛融入实际软件，也展示了“本地优先”在隐私和成本上的取舍。对于想探索本地AI应用的开发者，这个代码库是一个不错的起点。