上周，一个做财务的朋友给我发来消息，说他们团队每个月处理报销时最头疼的就是收集票据。客户发来的邮件里，照片、截图、PDF 混在一起，文件名乱七八糟，财务同事得花大量时间手动分类、重命名、归档。他问我：“有没有什么工具，能让客户把所有票据往一个链接里一扔，后台自动把它们按类型、日期或项目分好类？”

这让我想起最近在 Hacker News 上看到的 Sorted Receipts。它的核心思路很直接：给客户一个固定链接，客户通过这个链接上传各种格式的票据文件，后台用大语言模型（LLM）自动识别票据内容并分类。听起来像是解决了财务流程中的一个具体痛点，但这类工具真正有价值的地方，往往不在“能分类”这个表面功能，而在于它是否能把一次性的技术演示，变成可长期稳定运行的自动化流程。

在实际工作中，我们见过太多“演示时很惊艳，落地时问题百出”的 AI 工具。Sorted Receipts 的思路本身并不复杂，但它的长期价值取决于几个关键环节：LLM 识别的准确率到底有多高？支持哪些文件格式？批量处理时会不会漏单？分类规则能不能自定义？出错后有没有人工复核的入口？这些细节，才决定了一个工具能否从“玩具”变成“生产力”。

1. 为什么“扔进一个链接，自动分类”听起来简单，做起来难

从表面看，Sorted Receipts 要解决的问题很明确：把零散的票据文件自动分类。但如果你拆开来看，这个过程至少涉及五个环节：

1. 文件接收与解析：用户可能上传图片（JPG、PNG）、PDF、甚至扫描件。系统需要能解析这些格式，提取出图像或文字内容。
2. 内容识别：从票据中提取关键信息，如商户名称、日期、金额、税号、商品明细等。这里既要用到 OCR（光学字符识别），也要用到 LLM 的理解能力。
3. 分类逻辑：根据识别出的信息，按预设规则（如按商户类型、日期范围、项目代号）自动归类。
4. 结果输出：生成结构化的分类结果，可能是文件夹结构、CSV 表格或直接导入财务系统。
5. 异常处理：当识别失败、文件损坏或规则不匹配时，系统要有明确的处理机制。

这五个环节中，最容易出问题的不是 LLM 本身，而是前后端的衔接。比如，如果用户上传的是一张光线暗淡、拍摄模糊的小票照片，OCR 提取的文字可能残缺不全，LLM 再强也无法准确判断这是一张“餐饮发票”还是“交通票据”。又或者，如果 PDF 是扫描版且没有可选的文字层，解析失败的概率会大幅增加。

在实际落地时，这类工具的价值不在于“100% 准确”，而在于“能处理 80% 的常规情况，并把剩余 20% 明确标记出来供人工复核”。如果一味追求全自动，反而可能因为个别识别错误导致后续流程全乱。

2. LLM 在票据分类中的真正作用：理解上下文，而不只是识别文字

很多人容易把 LLM 在票据处理中的作用简单理解为“更聪明的 OCR”。其实不然。传统 OCR 只能把图像中的文字提取出来，但 LLM 能做的是理解这些文字的含义，并据此做出分类判断。

举个例子，一张票据上可能同时出现“咖啡”“笔记本”“服务费”等字样。传统规则引擎可能需要你预先设定关键词列表（如“咖啡”->“餐饮”、“笔记本”->“办公用品”），但 LLM 可以根据整张票据的上下文，判断这更可能是一张在咖啡馆开会时产生的消费凭证，从而自动归到“会议支出”类别下。

这种上下文理解能力，是 LLM 在这类场景中的核心价值。它不需要你预先穷举所有可能的商户名称或商品关键词，而是通过少量示例或自然语言描述，就能学会你的分类逻辑。

但这里也有一个陷阱：LLM 的判断并非绝对可靠。如果训练数据中缺乏某些特定类型的票据（如某种地方性发票），或者分类规则过于复杂（如“金额超过 1000 元且商户名称不含‘科技’二字的票据归为 A 类”），LLM 可能产生意想不到的误判。

因此，在实际部署时，更稳妥的做法是：

1. 先从小样本开始：用 20-30 张典型的票据测试 LLM 的分类准确率。
2. 设置置信度阈值：只有当 LLM 对分类结果的置信度超过一定值（如 85%）时，才采用自动分类；低于此阈值的，转入人工复核队列。
3. 保留人工修正入口：允许用户在自动分类后手动调整，并将修正结果反馈给系统，用于后续模型优化。

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，系统按主题、方法、发表年份自动打标签。
• 行政单据处理：员工上传请假条、报销单、采购申请，系统自动路由到相应审批人。

这些场景的共同点是：

1. 输入非标准化：文件格式、内容布局多样。
2. 理解依赖上下文：不能单纯靠关键词匹配，需要理解语义。
3. 分类规则灵活：不同组织、不同时期规则可能变化。
4. 容错性要求高：允许部分错误，但要有人工复核机制。

当你把 Sorted Receipts 看作一个“LLM 驱动的文件自动化”案例时，就能更清楚地看到它的潜力和边界。

5. 落地建议：先验证核心环节，再逐步扩展

如果你正在考虑使用或搭建类似工具，我建议按以下顺序推进：

第一步：最小可行性验证选 10-20 张最具代表性的票据，手动测试 LLM 的识别准确率。重点关注：

• 能否正确提取商户、日期、金额等关键字段？
• 分类结果是否符合预期？
• 哪些类型的票据容易识别错误？

第二步：流程串联把文件上传、解析、LLM 调用、分类结果输出整个流程跑通。哪怕只是单张票据的处理，也要确保端到端可运行。

第三步：批量测试用 100-200 张真实票据进行批量测试。观察：

• 并发处理时系统是否稳定？
• 平均处理时间是多少？
• 有没有漏处理或重复处理的情况？

第四步：异常处理与人工介入故意上传一些模糊、残缺、格式异常的票据，检查系统的容错能力。确认人工复核入口是否顺畅。

第五步：集成与优化将工具集成到现有工作流中，并持续收集用户反馈，优化分类规则和模型表现。

这个过程中，最忌讳的就是一上来就追求 100% 全自动。更务实的做法是接受“机器为主、人工为辅”的混合模式，先把大部分简单重复的劳动自动化掉，让人的精力集中在处理异常和优化规则上。

Sorted Receipts 展示了一个很好的方向：用 LLM 解决那些规则模糊、文件多样的自动化任务。但它的长期价值，取决于能否在准确率、稳定性、成本、可配置性之间找到平衡点。如果你正在面临类似的文件处理痛点，不妨从一个小样本实验开始，亲自感受一下 LLM 在实际场景中的能力和局限。毕竟，再好的工具，也只有真正用起来，才能知道它是否适合你的工作流。