Well

你最后一次手动抄发票号是什么时候？

又到月底。财务办公室里堆满了从各个供应商、电信运营商、云服务商发来的邮件，每封邮件里藏着一张 PDF 发票。你要打开附件、复制发票号、粘贴到表格里——重复 40 遍。眼睛花了，手腕酸了，时间没了。

Well App AI 做的事，就是把这套重复劳动彻底消灭。它是一个 Chrome 扩展，在你浏览网页时自动"认出"发票，帮你从 Gmail、WhatsApp、各类电商后台里把它们捞出来，标准化之后直接导入到 QuickBooks、Xero，或者导出成 CSV、JSON、UBL 格式。整个过程，不需要你动手。

截至目前，Well 支持 100,000+ 个网络平台，从 AWS、GitHub、Hetzner 等主流云服务商，到你叫不出名字的法国电力公司个人后台，全部覆盖。

---

一个创始人的"被迫"发明

Well App AI 诞生于创始人 Bastien 的亲身痛点。作为 SaaS 公司创始团队的一员，他每月要处理来自十几个国家的供应商发票——有的是德国电信的 PDF，有的是法国电力公司的网页后台，还有的藏在 WhatsApp 消息里。"我不想花时间在这些事上，"他在 GitHub README 里写道，"AI 可以做这件事。"

2025 年 4 月，Well App AI 以 MIT 协议正式开源，迅速获得 335 颗 GitHub 星标（数据截至 2026 年 6 月）。项目团队随后推出了 MCP（Model Context Protocol）协议支持，让 Claude Code、Cursor、Windsurf 等 AI 编程助手也能直接调取发票数据，把财务自动化嵌入了开发者日常工作流。

它是怎么工作的？

你可以把 Well 理解成三层叠加的自动化工具：

第一层：浏览器扩展（Contributing Mode） Chrome 扩展是 Well 的核心入口。用户安装扩展后，在 Contributor 模式下浏览任意发票后台，AI 会"观察"用户的操作步骤，自动生成一份"蓝图"（blueprint）——本质上是一份结构化的浏览器自动化脚本。这套蓝图会被保存到仓库的 ai-connector/ 目录下，其他用户复用时不需要重复录制。举个例子：你去 Hetzner 后台手动点了几下，Well 的 AI 记住了这个流程，从此 Hetzner 的发票就可以一键批量拉取。

第二层：发票提取与欺诈检测（AI 模块） 两个独立的 AI 子模块负责核心智能处理：

• ai-invoice-extractor：调用 OpenAI GPT-4o、Mistral、Google Gemini 等多模型，从 PDF、图片（JPG/PNG）中提取发票字段（金额、日期、发票号、供应商信息），支持多语言。底层使用 Vercel AI SDK (ai 包)，实现了模型无关的 Provider 切换。
• ai-invoice-receipt-fraud-detector：在 OCR（基于 Tesseract.js）提取的基础上，用 OpenAI 模型对发票图像进行真实性判断，检测重复报销、金额篡改、供应商冒名等常见欺诈场景。依赖 pdfjs-dist 处理 PDF 文档。

第三层：数据导出与集成（exporters） 提取后的发票数据可以通过工厂模式注册的新导出器，转换成任意格式：JSON（API 使用）、CSV（电子表格）、XML（企业系统）、UBL 2.1（国际电子发票标准）、QuickBooks IIF、Xero CSV。导出器架构完全插件化，新增格式只需在 exporters/ 目录添加一个 Python 类，无需修改核心逻辑。

多端接入：扩展、MCP、CLI 全覆盖

Well 提供了三种接入方式，适合不同的使用场景：

接入方式	适用人群	核心价值
Chrome 扩展	财务人员、运营	一键从浏览器提取，批量处理
MCP Server	开发者、AI 助手用户	在 Claude/Cursor 中用自然语言查询发票
CLI 工具	运维、极客	curl 一行安装，管道式数据处理

以 MCP 为例，接入方式极其简洁：

# Claude Code 中
/plugin marketplace add WellApp-ai/Well
/plugin install well@well
/mcp  # 然后在交互菜单中认证

# 或者直接填入 MCP URL（任意 MCP 客户端）
https://api.wellapp.ai/v1/mcp

认证采用 OAuth 2.0 + PKCE，无须手动粘贴 API Key，CLI 和 MCP 使用独立的 OAuth 客户端，互不影响。认证信息缓存在本地（CLI: ~/.well/credentials.json），安全且可移植。

开发者友好：TypeScript monorepo 的工程实践

项目采用 monorepo 结构，由三个核心子包构成：

Well/
├── ai-invoice-extractor/        # 发票提取 CLI（TypeScript/Bun）
├── ai-invoice-receipt-fraud-detector/  # 欺诈检测（TypeScript/Bun）
├── ai-connector/                 # 100+ 连接器（社区贡献的蓝图）
├── plugins/well/               # MCP Server
├── cli/well                    # Python CLI 工具（标准库，无依赖）
└── shared/                     # 共享类型定义

代码质量在开源项目中属中上水平：

• 依赖 Biome（Rust 写的 linter/formatter）做代码风格统一，速度比 ESLint 快 10 倍
• Vitest 单元测试框架，测试覆盖率数据可见
• 完整的 TypeScript 类型定义，无 any 逃逸
• 严格的 Zod schema 校验外部输入
• Node.js >= 20 要求，支持 ESM 模块

不过需要指出两个值得关注的工程局限：

1. 根目录缺少 package.json，整体项目没有统一的构建入口，各个模块需要独立安装依赖
2. ai-invoice-receipt-fraud-detector 声明 private: true，内部实现细节不对外开放

隐私与合规：不是说说而已

Well 在隐私设计上下了功夫：浏览器扩展不存储任何密码，所有认证走 OAuth 云端授权通道。数据处理完全符合 GDPR（欧盟通用数据保护条例） 和 CCPA（加州消费者隐私法） 要求。这对于一个财务数据处理工具来说，是基本底线也是核心卖点——毕竟没有哪个公司的财务负责人愿意把发票数据交给一个安全性存疑的工具。

局限与风险

没有任何工具是银弹，Well 也不例外：

1. 依赖云端 API：整个业务逻辑（OCR、AI 提取、存储）跑在 wellapp.ai 的服务器上，用户对数据有完全的依赖性。一旦服务中断，发票提取流程随之中断。没有本地化部署选项，这可能不适合数据主权要求严格的金融、医疗行业。

2. 蓝图质量参差不齐：ai-connector/ 目录下 60+ 个连接器来自社区贡献，水平不一。部分连接器维护频率低，当供应商网站改版时可能失效——虽然官方声称有"self-healing"（自愈）机制，但实际效果仍需用户自行验证。

3. 欺诈检测精度有限：ai-invoice-receipt-fraud-detector 基于 OCR + LLM 图像理解，在发票图片模糊、光线不佳或布局非标准时，误检率会上升。官方 roadmap 中仍标注"launch public beta"为待办项，当前属于 pre-release 状态。

4. 国际化覆盖不均：目前 60+ 个连接器主要覆盖欧美主流服务，对亚洲市场（尤其是中国、日本、韩国）的本地化平台支持有限。

行业意义：从"人找发票"到"发票找人"

Well 的出现，折射出一个更大的趋势：财务自动化的最后一公里。过去十年，企业资源规划（ERP）系统解决了财务记账的结构化问题；但在发票"入口"这个环节——从供应商网站把数据捞进来——一直依赖人工。Well 用 AI 填平了这个 gap。

类似的产品路径在个人记账领域已有先例：银行 API 授权 + AI 分类让 Mint、YNAB 等工具流行；在 B2B 场景下，Well 的 100,000+ 平台覆盖目标更加激进，护城河也更深——每一个新增连接器都是对竞品的壁垒。

MCP 协议的接入是点睛之笔。当 AI 编程助手能够实时访问你的财务数据，意味着"让 AI 帮你分析上个月的供应商支出"这类需求，从科幻变成了 well invoices unpaid 这样一行命令的事。这才是 AI 对财务工作流的真正渗透方式——不是取代财务软件，而是成为财务软件的"神经系统"。

---

本分析基于 GitHub 仓库最新代码（2026-06-11 更新）和官方文档完成。