Paperless-GPT：让催款单连回原发票，先认准那串编号

发票扫进档案库，隔了几周又来一封催款通知。两份文件的名字不同、收到时间不同，却在说同一笔事项。Paperless-GPT 值得认识的一项能力，是从后来的文件中提取被引用的编号，在已有档案里查找对应原件，再建立可以双向打开的关联。

它是接在 Paperless-ngx 后面的 AI 扩展，能够建议标题、标签、往来方和自定义字段，也提供 OCR 处理路径。这里最有用的成果不是一句“我找到了”，而是让后续信件与原始文件在档案里真正接起来，交接时可以沿关系返回原文。

模型读编号，程序负责找文件

官方关联文档用了一个清楚的例子：催款信提到编号 RE-2026-0417 的发票尚未结清。系统先让模型提取这个引用，再到 Paperless-ngx 的文档内容中查找同样的编号，填写 Document Link 类型的自定义字段。打开任一端，都能跳到另一份文档。

关键在于职责被分开了。模型不直接猜档案里的文档 ID；真正的匹配由程序执行，并要求完整词匹配，R123 不会因为是前缀就匹配到 R1234。对于需要复核原件的人，这比“让模型凭语义判断两封信是不是一回事”多了一层可以说清的连接依据。

这仍然只是官方文档解释的工作方式，不是本文跑出的催款案例。关联能够帮助查证，但不会证明款项是否已经支付，也不能替代原始单据和自己的账目。

编号越常见，越不适合拿来连单。官方规则会忽略过短的引用，对纯数字编号另有要求；一个引用如果出现在超过三份其他文档中，也会被当成过于通用而跳过。模型提取错误、找不到匹配时，同样不会硬填一个结果。

这条取舍很实用。例如，中文通知里同时写着“客户号 10001”和“原发票 WZ-2026-086”，后者才更可能指向某份具体文件。客户号可能出现在历年的所有信件上，不能因为号码一致，就把新通知与每张旧发票全部连起来。这是解释规则的教学情境，未验证中文编号提取效果。

还有两个容易影响结果的条件：原发票必须先在档案库里，其内容也必须有可读取的文本。若催款信先到、原件尚未扫描，就暂时无从关联；补入原件后需要重新处理引用它的信件。扫描件只有图像、没有可靠 OCR 文本时，也不能期待编号检索自动成功。

下面的官方界面图展示的是另一份文档的标题、标签和往来方建议：原名为 scan 0011，建议标题包含 FedEx 与日期，底部仍留着 Apply Suggestions 按钮。

官方既有界面示例，说明建议可以先审再写回；它不是上述催款关联的结果图，也不证明中文字段准确率。点击可打开原图。

这个按钮对应一种值得保留的使用顺序：先挑少量文件生成建议，确认标题中的日期究竟代表开票时间还是收件时间，再把需要的字段写回档案。关联字段也可以结合手动审核使用，不必第一次就开启全自动队列。

设置时，要先在 Paperless-ngx 创建 Document Link 自定义字段，再到 Paperless-GPT 启用自定义字段生成并选中它。官方建议关联字段使用 Append 或 Update，避免 Replace 把已有的镜像关联覆盖掉。选择写入方式直接影响已有资料，不只是偏好设置。

开始条件包括已有 Paperless-ngx、Docker，以及可用的模型服务。连接外部模型时，参与提取的文档内容会交给所选端点；本地 Ollama 是另一条路线，但要自行准备模型、存储和算力。OCR 与元数据生成还可能使用不同服务，应分别核对。

另一个采用条件是：项目当前没有内置身份认证，能访问其界面端口的人也能触发处理、改变连接档案的内容。自己部署时需要限制可访问范围或加上认证，不能把默认端口直接当作可公开分享的站点。

代码采用 MIT 许可，不包含云 API 用量或所选模型的权重授权。它适合已经维护文档库、经常需要把补充文件与原件一起交接的人：从一对编号清楚、可以公开使用的材料开始，检查关联是否正确，再决定把哪些文档类型交给自动处理。