每个月末，报销真正消耗时间的从来不是填单子，而是收票。餐饮、打车、住宿、火车票、机票分别躺在不同邮件里，有的带 PDF 附件，有的只有一个「点击下载」的链接，还有的把几张票一起塞进 ZIP。这次我把「收票」这一段交给本地自动化处理，工具是 DeepSeek Harness 插件 @ethanyoq/dsh-invoice-downloader（项目名 InvoiceFlowAI，仓库 EthanYoQ/Invoice-Downloader），站点把它归在「dsh 原生插件 · platform」。
起点：邮件都还在邮箱里
它连接的是自己的邮箱，目前覆盖 QQ 与 163 两套 IMAP 生态，服务器分别是 imap.qq.com 与 imap.163.com，端口都是 993（SSL/TLS）。DSH 插件版的入口在右侧边栏的「发票下载」，首次使用做三件事：选择保存位置、安装一次本地引擎、填写 IMAP 授权码。
dsh plugin --profile web add @ethanyoq/dsh-invoice-downloader
dsh web --profile web有一个前置动作要预留时间：首次安装需要联网下载 Python 依赖和 Chromium。稍好的一点是 rapidocr-onnxruntime 的 pip wheel 自带默认 PP-OCRv3 模型，不用再手动下模型。装完之后，每次扫描就只是点一下运行。
漏斗：先判断哪些邮件不值得读
扫描不是「每封邮件都过一遍 AI」。程序先跑四层漏斗——白名单域名、主题关键字、正文检测、二维码扫描——把非发票邮件筛掉。月末邮箱里有对账单、订阅通知、验证码、营销邮件，全都丢给模型既慢又浪费额度；README 写的设计意图正是降低误识别率与 API 费用。
通过的附件还要过一级三级决策：
A 层（丢弃）：Tracking pixel、Logo、装饰图（≤32px）—— 直接跳过
B 层（暂存）：附件 >5MB、ZIP 解包失败 —— 保留但不处理
C 层（归档）：正常 PDF / OFD / XML —— 进入 AI 提取流程ZIP 是递归解包的，几张票打成一个包的邮件不会漏。
拿不到附件的邮件：链接发票自动恢复
月末最烦的是「您的发票已开具，请点击下载」这类邮件。工具有三级 PDF 恢复：百望云走 Playwright 自动化（登录 → 点击下载 → 捕获文件 → 字段匹配验证），国税、诺诺、航信走 HTTP 直接下载并做本地字段校验，未知网页则走「网页转 PDF」，检测登录与验证码后以 A4 格式渲染。三者最终都落成本地 PDF，再进提取流程。另外，住宿发票与水单、打车发票与行程单会自动配对并相邻命名归档，不用自己把两张文件凑到一起。
提取：两层模型引擎加一层本地兜底
发票落到本地后先做本地 OCR，OCR 文本再发送给当前选择的 DeepSeek 模型提取字段。识别由三层防线承担，任何一层成功即采用结果：Track A（OCR + LLM）先提取文字结构再理解，README 标注为精度最高；Track B（glm-4.5V 视觉）直接「看图」，适合复杂排版或图片类发票；Local Fallback 是本地正则规则，断网可用、零 API 消耗。票种杂、排版不统一时，自动切换比「单一路径跑得顺」更省心——不需要先判断这张票该走哪条路。
落地结果长什么样
跑完之后是一个清楚的目录树：
发票整理/
├── 火车票/ └── 20260315-北京-上海-火车票.pdf
├── 机票/ └── 20260301_机票_1280.00_中国国际航空.pdf
├── 住宿发票/ ├── 20260310-住宿-01-发票_888.00元.pdf
│ └── 20260310-住宿-01-水单_888.00元.pdf
├── 打车/ ├── 0312-滴滴-01-发票_45.50元.pdf
│ └── 0312-滴滴-01-行程单_45.50元.pdf
├── 餐饮/
├── 待人工复核/
├── 非目标公司发票/
└── summary_report.xlsx命名规则可读：日期在前，票种与金额在后，同一笔业务的发票与凭证相邻。过去我要在一堆 发票.pdf、发票(1).pdf 里靠打开确认，现在文件名本身带信息。分类规则还支持自然语言，例如 README 里举的「滴滴大于100元放进大额」。
Excel 汇总与「待人工复核」
summary_report.xlsx 覆盖发票清单与金额汇总，替代的是最机械的录入工作。但有一个目录值得说明：待人工复核/ 不是故障，而是设计的一部分——AI 识别置信度不足时，材料会自动进这个队列等待人工确认，常见诱因是图片模糊、非标准票据或加密 PDF；非目标公司的发票则单独归到 非目标公司发票/。换句话说，它减少的是收集与录入，不是复核。指望它替你把税务与会计口径也对齐，是方向性的误解。
两次需要提前知道的坑
坑一 · 授权码和邮箱密码不是一回事
认证失败最常见的原因，是把登录密码填进了授权码的位置。163 的授权码要在「开启 IMAP 服务」弹窗里生成，是 16 位字母组合，只显示一次且大小写敏感；QQ 则要走「管理服务 → 生成授权码」流程。还有一条容易踩：修改 QQ 密码后授权码自动失效，需要重新生成。
坑二 · 别把「本地处理」读成「零外发」
README 的隐私承诺是「所有邮件、发票文件均在本地处理，不上传任何服务器」，同时写明 GLM API 仅接收发票图片（Base64）用于文字识别，不发送邮件原文内容。两句话要合起来读：邮件与附件留在本地，但启用 GLM OCR 或视觉识别时，发票图片本身会发往智谱 AI 的服务端。接受这个边界的场景可以用，不接受就不该装。
版本、维护与安全档位（如实记录）
- npm 包
@ethanyoq/dsh-invoice-downloader当前版本 0.1.1；许可 Apache-2.0，再分发需保留版权与许可声明及 NOTICE 署名； - Node 引擎要求
^22.19.0 || >=24；未声明 dsh 版本约束； - Star 507（GitHub API，2026-10-15 实测）；站点未给出周下载量，因此不做下载量推断；
- 最近一次提交在 19 天前，站点静态检查快照 2026/10/11；
- 信任档位 已验证（L4 · 真实安装）：本站已于 3 天前在 dsh 0.2.0-rc.2 下真实安装成功；
- 安全扫描 🔵 含敏感能力，站点列出 11 处证据（含读写、删除本地文件），尚无人工评估；站点尚未对该插件做风险分级，原文是「暂未覆盖，不等同于无风险」；
- 只支持 Windows x64 与 macOS Apple Silicon；授权码由 DSH 凭据服务保存，不写入插件设置或扫描日志。
作者口径也要照写：作者不保证发票数据或生成结果的准确性、完整性、合法性、税务合规性、财务合规性与会计合规性，所有结果必须由用户自行核验后再使用。
总结
把收票、识别、归档、汇总四段交给本地自动化之后，月末真正需要人做的只剩复核与提交；想对照同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：每月固定要收一批电子发票的个人与自由职业者；邮箱在 QQ 或 163 生态、愿意开 IMAP 授权码的人；手上是 Windows x64 或 macOS Apple Silicon 机器的人。
不适合：邮箱不在 QQ / 163 生态，或不愿开 IMAP 授权码的人；使用 Linux 或 Intel Mac 的人（只支持 Windows x64 与 macOS Apple Silicon）；不接受发票图片会发往智谱 AI 的人。
标签：发票整理助手、DeepSeek Harness、邮箱发票自动化、IMAP 收票实践
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。