上周一个做财务的朋友给我发来消息说他们团队每个月处理报销时最头疼的就是收集票据。客户发来的邮件里照片、截图、PDF 混在一起文件名乱七八糟财务同事得花大量时间手动分类、重命名、归档。他问我“有没有什么工具能让客户把所有票据往一个链接里一扔后台自动把它们按类型、日期或项目分好类”这让我想起最近在 Hacker News 上看到的 Sorted Receipts。它的核心思路很直接给客户一个固定链接客户通过这个链接上传各种格式的票据文件后台用大语言模型LLM自动识别票据内容并分类。听起来像是解决了财务流程中的一个具体痛点但这类工具真正有价值的地方往往不在“能分类”这个表面功能而在于它是否能把一次性的技术演示变成可长期稳定运行的自动化流程。在实际工作中我们见过太多“演示时很惊艳落地时问题百出”的 AI 工具。Sorted Receipts 的思路本身并不复杂但它的长期价值取决于几个关键环节LLM 识别的准确率到底有多高支持哪些文件格式批量处理时会不会漏单分类规则能不能自定义出错后有没有人工复核的入口这些细节才决定了一个工具能否从“玩具”变成“生产力”。1. 为什么“扔进一个链接自动分类”听起来简单做起来难从表面看Sorted Receipts 要解决的问题很明确把零散的票据文件自动分类。但如果你拆开来看这个过程至少涉及五个环节文件接收与解析用户可能上传图片JPG、PNG、PDF、甚至扫描件。系统需要能解析这些格式提取出图像或文字内容。内容识别从票据中提取关键信息如商户名称、日期、金额、税号、商品明细等。这里既要用到 OCR光学字符识别也要用到 LLM 的理解能力。分类逻辑根据识别出的信息按预设规则如按商户类型、日期范围、项目代号自动归类。结果输出生成结构化的分类结果可能是文件夹结构、CSV 表格或直接导入财务系统。异常处理当识别失败、文件损坏或规则不匹配时系统要有明确的处理机制。这五个环节中最容易出问题的不是 LLM 本身而是前后端的衔接。比如如果用户上传的是一张光线暗淡、拍摄模糊的小票照片OCR 提取的文字可能残缺不全LLM 再强也无法准确判断这是一张“餐饮发票”还是“交通票据”。又或者如果 PDF 是扫描版且没有可选的文字层解析失败的概率会大幅增加。在实际落地时这类工具的价值不在于“100% 准确”而在于“能处理 80% 的常规情况并把剩余 20% 明确标记出来供人工复核”。如果一味追求全自动反而可能因为个别识别错误导致后续流程全乱。2. LLM 在票据分类中的真正作用理解上下文而不只是识别文字很多人容易把 LLM 在票据处理中的作用简单理解为“更聪明的 OCR”。其实不然。传统 OCR 只能把图像中的文字提取出来但 LLM 能做的是理解这些文字的含义并据此做出分类判断。举个例子一张票据上可能同时出现“咖啡”“笔记本”“服务费”等字样。传统规则引擎可能需要你预先设定关键词列表如“咖啡”-“餐饮”、“笔记本”-“办公用品”但 LLM 可以根据整张票据的上下文判断这更可能是一张在咖啡馆开会时产生的消费凭证从而自动归到“会议支出”类别下。这种上下文理解能力是 LLM 在这类场景中的核心价值。它不需要你预先穷举所有可能的商户名称或商品关键词而是通过少量示例或自然语言描述就能学会你的分类逻辑。但这里也有一个陷阱LLM 的判断并非绝对可靠。如果训练数据中缺乏某些特定类型的票据如某种地方性发票或者分类规则过于复杂如“金额超过 1000 元且商户名称不含‘科技’二字的票据归为 A 类”LLM 可能产生意想不到的误判。因此在实际部署时更稳妥的做法是先从小样本开始用 20-30 张典型的票据测试 LLM 的分类准确率。设置置信度阈值只有当 LLM 对分类结果的置信度超过一定值如 85%时才采用自动分类低于此阈值的转入人工复核队列。保留人工修正入口允许用户在自动分类后手动调整并将修正结果反馈给系统用于后续模型优化。3. 从单次演示到稳定运行工程化落地的四个关键点如果一个工具只能处理零星几张票据那它的价值有限。真正的挑战在于如何让它稳定、批量地运行。以下是四个常被忽略的工程化要点3.1 文件预处理与标准化上传的票据文件质量参差不齐。有些可能是手机随手拍的高清图有些可能是扫描仪生成的灰度 PDF还有些可能是从邮件里转存过来的低分辨率截图。如果直接把这些原始文件扔给 LLM识别效果会很不稳定。更可靠的做法是增加一个预处理环节图像增强自动调整亮度、对比度矫正倾斜裁剪无关背景。格式统一将非 PDF 文件转换为 PDF或统一解析为图像序列。文字层提取优先尝试从 PDF 中提取可选文字层失败后再降级到 OCR。这些预处理步骤能显著提升后续 LLM 识别的准确率和稳定性。3.2 分类规则的可配置性不同的团队对“分类”的定义可能完全不同。有的按费用类型交通、餐饮、办公有的按项目代码有的按日期区间还有的按客户名称。一个固定的分类规则很难满足所有需求。因此工具应该允许用户自定义分类逻辑。理想情况下你可以通过以下方式配置自然语言描述直接告诉 LLM “把星巴克、Costa 的票据归为‘餐饮’把出租车、地铁票归为‘交通’”。示例学习上传几张已分类的票据作为示例让 LLM 学习你的分类标准。规则组合支持金额范围、商户名称关键词、日期条件等规则组合。可配置性越高工具的适用范围就越广。3.3 批量处理与状态管理当同时上传数十张票据时系统需要能并行处理并清晰展示每张票据的处理状态待处理、识别中、已完成、需人工复核。这涉及到任务队列、并发控制和状态追踪等后端能力。对于财务这类对数据准确性要求高的场景还需要考虑处理日志记录每张票据的识别过程、使用的模型版本、关键提取字段、分类依据等便于后续审计。失败重试对于因网络波动或临时资源不足导致的处理失败应支持自动重试。结果导出支持将分类结果批量导出为 Excel、CSV 或直接对接财务软件 API。3.4 成本与性能平衡LLM API 调用是按 token 数或请求次数计费的。如果每张票据都调用一次高性能 LLM成本可能会迅速上升。在实际使用中需要根据票据的复杂程度选择合适的模型简单票据格式规范、文字清晰先用轻量级 OCR 规则引擎处理只有规则无法判断时才调用 LLM。复杂票据多页 PDF、混合内容直接调用高性能 LLM但限制并发数避免账单失控。此外还可以通过缓存机制减少重复识别如果同一商户的票据格式基本固定可以缓存识别结果后续类似票据直接复用。4. 不只是票据这类“LLM文件自动化”思路的延展场景Sorted Receipts 的思路其实可以扩展到许多类似场景。任何需要从半结构化文档中提取信息并自动归类的任务都可以参考这个模式法律文件管理客户上传合同、诉状、证据材料系统自动按案件、日期、类型分类。学术资料整理研究人员上传论文 PDF系统按主题、方法、发表年份自动打标签。行政单据处理员工上传请假条、报销单、采购申请系统自动路由到相应审批人。这些场景的共同点是输入非标准化文件格式、内容布局多样。理解依赖上下文不能单纯靠关键词匹配需要理解语义。分类规则灵活不同组织、不同时期规则可能变化。容错性要求高允许部分错误但要有人工复核机制。当你把 Sorted Receipts 看作一个“LLM 驱动的文件自动化”案例时就能更清楚地看到它的潜力和边界。5. 落地建议先验证核心环节再逐步扩展如果你正在考虑使用或搭建类似工具我建议按以下顺序推进第一步最小可行性验证选 10-20 张最具代表性的票据手动测试 LLM 的识别准确率。重点关注能否正确提取商户、日期、金额等关键字段分类结果是否符合预期哪些类型的票据容易识别错误第二步流程串联把文件上传、解析、LLM 调用、分类结果输出整个流程跑通。哪怕只是单张票据的处理也要确保端到端可运行。第三步批量测试用 100-200 张真实票据进行批量测试。观察并发处理时系统是否稳定平均处理时间是多少有没有漏处理或重复处理的情况第四步异常处理与人工介入故意上传一些模糊、残缺、格式异常的票据检查系统的容错能力。确认人工复核入口是否顺畅。第五步集成与优化将工具集成到现有工作流中并持续收集用户反馈优化分类规则和模型表现。这个过程中最忌讳的就是一上来就追求 100% 全自动。更务实的做法是接受“机器为主、人工为辅”的混合模式先把大部分简单重复的劳动自动化掉让人的精力集中在处理异常和优化规则上。Sorted Receipts 展示了一个很好的方向用 LLM 解决那些规则模糊、文件多样的自动化任务。但它的长期价值取决于能否在准确率、稳定性、成本、可配置性之间找到平衡点。如果你正在面临类似的文件处理痛点不妨从一个小样本实验开始亲自感受一下 LLM 在实际场景中的能力和局限。毕竟再好的工具也只有真正用起来才能知道它是否适合你的工作流。