Paperless AI 能帮你完成什么工作
下面是根据工具能力整理的操作建议，输入、交付标准和人工核对由你确定。
场景 01 · 已经部署 Paperless-AI 的管理员盘点现有文档扩展依赖
- 先准备
- 现有配置、文档资料、标签规则与模型信息
- 怎么做
- 编辑建议：先保留资料和配置副本，再检查处理范围与被修改的字段，记录依赖后决定后续方案。
- 得到什么
- 可用于迁移评估的依赖清单
- 使用建议
- 不要在尚未备份时批量重跑文档，也不要把停止维护理解为已有数据自动消失。
查看操作流程示意
场景 02 · 已有分类结果的资料维护者复核已有的 AI 分类
- 先准备
- 样本文档、原文及其标签和类型
- 怎么做
- 编辑建议：对照原文检查标题、对应方和分类，记录误分类模式并调整后续人工复核要求。
- 得到什么
- 经过核对的分类问题清单
- 使用建议
- 同名组织或含混文档不能仅靠标签作结论。
场景 03 · 需要继续维护文档库的人规划后续文档问答方案
- 先准备
- 可用数据副本、现有检索需求和部署条件
- 怎么做
- 编辑建议：分别核对文档管理、模型调用、标签规则和问答需求，查看候选方案当前文档后再安排迁移。
- 得到什么
- 明确功能需求与未确认项的迁移计划
- 使用建议
- 不要把作者提到的未来集成当作已发布替代，也不要假定旧索引可直接通用。
Paperless AI 软件界面
Paperless-AI 官方项目保留的历史 RAG 界面，可见检索条件、回答和来源；原图敏感字段已由项目方遮盖，项目已停止维护。
Paperless AI 是什么
旧实现通过 OpenAI 兼容接口或 Ollama 分析已有文档，能够修改标题、标签、文档类型和对应方。它依赖 Paperless-ngx，并不是独立的文档管理系统。
本指南用于理解历史能力、检查现有部署和准备后续迁移。仓库提到 Paperless-ngx 未来官方 AI 集成，但这句话不能证明某项新能力已经上线。
Paperless AI 的主要功能
历史自动处理会修改文档元数据
旧实现检测 Paperless-ngx 新文档并分配标题、标签、类型及对应方，现有用户需知道哪些字段可能由 AI 改写。
历史 RAG 支持文档问答
产品曾基于文档语义提供检索和自然语言问答，可用于查找相关合同或账单，但答案仍需回到原文。
保留手动分类入口
旧说明列出用于手动 AI 标签的网页入口，便于针对敏感或特殊文档逐项处理；实际可用性取决于已有部署。
用规则限定处理范围
旧版本提供处理过滤规则、自定义输出标签与兼容模型后端，迁移时需要分别检查这些配置依赖。
如何开始使用 Paperless AI
确认维护公告与当前部署
阅读仓库维护状态，记录自己使用的版本及与 Paperless-ngx 的连接方式。
保存文档与配置副本
在改动现有部署前保留原文、元数据和规则配置，明确哪些资料属于上游文档系统。
抽查处理范围和结果
选择已有样本文档检查标题、标签、类型与对应方，确认模型调用和过滤规则依赖。
评估迁移再安排变化
以当前候选工具文档为准核对功能，先明确数据与规则差异，再决定是否停用或替换扩展。
费用与使用条件
选择前了解
- 使用方式
- 私有部署 / 网页
- 收费结构
- 免费
官方仓库已明确不再维护；MIT 代码许可不包含模型 API 与部署成本，需依赖 Paperless-ngx。
免费方案可能有功能或额度限制，商业用途需另看许可条件。
仓库已明确不再维护
作者正在考虑重写，但说明可能不完成或不继续维护；不能把路线图当作有保证的更新计划。
它依赖 Paperless-ngx 与模型后端
扩展需要上游文档系统及 OpenAI 兼容或 Ollama 等后端；开源代码不等于所有调用和运行资源免费。
自动处理可能改写重要字段
标题、标签、文档类型和对应方都可能由模型生成，应保留原文并逐项检查。
未来官方 AI 不等于现成替代
维护公告仅提到 Paperless-ngx 即将提供官方集成，实际可用功能需另看该产品当时发布说明。
Paperless AI 常见问题
Paperless-AI 还在积极维护吗？
当前仓库明确写明不再维护，作者没有承诺重写完成或继续维护。
它能单独管理全部文档吗？
它是 Paperless-ngx 的扩展，需要现有文档管理系统，不是独立替代品。
开源就代表所有 AI 使用免费吗？
不是。项目采用 MIT 许可，但模型 API、设备和部署资源需要自行承担。
已部署用户应先做什么？
先保留文档和配置副本，检查自动处理规则与已有分类，再评估后续维护或迁移方案。