发票整理的工程思维：从混乱文件堆到结构化数据

每到年底算账，或者某天突然要给会计发报销凭证，就会面对同一个问题：收件箱下载的 invoice.pdf、invoice(1).pdf、invoice(2).pdf，桌面上来不及分类的收据截图，以及散落在各个项目文件夹里不知道属于哪个季度的账单——这些文件加在一起，构成了一个信息量足够但完全无法直接使用的「数据泥潭」。

这个问题本质上是一个数据工程问题，只是规模很小、被人手动做着。

信息提取是第一步，也是最难的一步

发票文件和普通文件的核心区别在于：每个文件本身携带着结构化信息，只是被「锁在」PDF 内容或图片像素里。文件名 invoice(37).pdf 没有任何信息量，但文件内部有日期、供应商名称、金额、单据编号——这些字段在几乎所有发票里都存在，只是位置和格式各不相同。

传统做法是人工打开每个文件，抄下关键信息，再手动重命名。这个过程慢、容易出错，而且你的大脑在做的事其实极其机械：匹配模式、提取字段、格式化输出。这恰好是 AI 做得最稳定的事情之一。

让 AI 读取每个文件、提取「日期 / 供应商 / 金额 / 描述」四个字段，并不需要复杂的提示——发票的格式虽然多样，但这几个字段的语义在各种变体里都相对稳定。对于无法提取的文件，标记「待人工审查」是正确的降级策略，而不是猜测填充。

命名约定：让文件系统变成可排序的数据库

信息提取之后，下一步是把这些信息编码进文件名。这听起来是小事，但实际上是整个流程里回报率最高的决策。

一个好的命名约定：YYYY-MM-DD 供应商 - 单据类型 - 商品或服务描述.pdf

这条规则让文件系统获得了几个能力：

• 按时间排序：日期前置，ls 或文件管理器默认排序就是时间顺序
• 按供应商筛选：find . -name "*Adobe*" 能立刻定位所有来自某家的账单
• 语义自描述：六个月后打开文件夹，不用打开单个文件就能知道里面是什么

命名约定的价值不在于第一天整理有多快，而在于未来每次「找一张去年某月的某发票」的时间从十分钟缩短到三十秒。

分层归档：分类维度不止一种

发票的归档没有唯一正确的分层方式，因为使用场景不同，最优分层也不同：

• 报税场景：按年份 → 费用类别（软件 / 差旅 / 办公室 / 专业服务）→ 供应商
• 月度对账：按年份 → 月份 → 类别
• 会计交接：按可抵税 / 部分抵税 / 个人消费做顶层分类

关键不是选哪种，而是在动手之前把这个问题想清楚——而不是边整理边决定，导致前后标准不一致。

我的实践是：在执行任何文件移动之前，先把「分层方案 + 样例变更（before → after）」打印出来确认。这一步强制自己在修改不可逆之前检查一遍逻辑，也让之后的执行有了明确的参照。复制而非移动原始文件，在验证整理结果之前保留原版，是这个流程里的安全网。

这条链路背后的通用模式

发票整理只是一个具体场景，但它背后的链路是通用的：

1. 扫描现状：摸清文件数量、类型、时间跨度，再决定策略
2. 信息提取：从非结构化载体里识别出结构化字段
3. 标准化编码：把字段写进文件名或元数据，让文件系统可以被查询
4. 分层归档：按使用场景决定分类维度，执行前先出方案确认
5. 汇总导出：生成可检索、可导入的清单，作为整个数据集的索引

这条链路在处理合同归档、研究资料整理、代码快照管理里都成立。每次面对「一堆乱文件」的问题时，先问：「这里面的结构化信息是什么，我要如何把它暴露出来？」——答案往往指向一套可以自动执行的流程。

一句话心法

整理不是把文件放进文件夹，而是把文件里的信息变成可以被机器检索的结构。