智能报销Agent（工具）：这次，真真真真的完成一键报销
一、项目背景
痛点分析
所有TO_B为主的企业，一定都有大量的商务人员需要各种报销，差旅的、非差旅的。
即使很多公司引进了差旅平台，但商旅中的餐饮、客户送礼，或者员工的TokenPlan、toolfee等依旧逃不了报销。作为一名开发者，我自己也深受报销之苦：
- 手动填写太麻烦：每次出差回来，对着一堆发票手动录入信息，起止时间，金额汇算……少则半小时，多则一小时
- 容易出错：发票号、金额、日期输错是常事，退回来重填更闹心
- 流程割裂：发票在邮箱里、在手机相册里、在微信里，找齐都不容易
- 重复报销风险：同一张发票不小心用了两次，财务找过来很尴尬
为什么要做这个项目
我的公司内部一直用飞书审批，但个人垫付后的报销还是手工活。我想：既然 AI 这么强大，能不能我把票据给agent，我就坐等收钱就行？
于是就有了这个项目——一个连接「发票」和「飞书审批」的智能桥梁。
二、项目基本原理
技术架构
用户上传发票
↓
PaddleOCR 识别（百度飞桨）
↓
DeepSeek LLM 理解和结构化
↓
自动生成报销单 PDF
↓
自动提交飞书审批
核心技术栈
| 层级 | 技术选型 | 说明 |
|---|---|---|
| 前端 | Next.js 16 + React 19 | 最新的 Next.js，App Router 架构 |
| 后端 | Next.js API Routes | 一体化开发，不用单独搭服务 |
| 数据库 | PostgreSQL | 存储用户、邮件、审批历史 |
| OCR | PaddleOCR (百度 AI Studio) | 中文发票识别效果最好 |
| LLM | DeepSeek | 性价比高，中文理解能力强 |
| 企业集成 | 飞书开放平台 | 登录、审批、用户同步 |
三、功能亮点
1. 双模式发票采集
本地文件上传 + 邮箱自动拉取
- 支持一次上传多张发票（PDF、图片都可以）
- 可以配置报销专用邮箱，自动拉取邮件里的发票附件
- 邮箱里的发票可以勾选后一键导入
2. 智能发票理解
这是项目最核心的部分：
OCR 层：用 PaddleOCR 把发票图片转成 Markdown 格式的结构化文本
- 支持增值税普通发票、电子发票、火车票、机票行程单等
- 保留表格、金额、日期等关键信息的布局
LLM 层：让 DeepSeek 做「报销会计」
- 自动判断是「差旅报销」还是「普通报销」
- 提取每张发票的：发票号、日期、金额、销售方、税号、消费内容
- 对于差旅报销，自动拆分：大交通、市内交通、住宿、补贴
- 生成报销说明（比如：「2026-04-16 ~ 2026-04-18 北京→上海出差，拜访客户」）
3. 飞书深度集成
- 一键登录：飞书 OAuth 登录，自动同步部门、工号信息
- 自动提交审批：生成的报销单直接推送到飞书审批
- 支持两种审批流程：普通报销、差旅报销（可配置不同的审批模板）
- 状态同步：定时从飞书拉取审批状态，显示在历史记录里
4. 发票去重
- 提交前自动检查发票号是否已经报销过
- 用 PostgreSQL 的 JSONB 特性查询，性能很好
- 避免重复提交的尴尬
5. Admin 后台
- 可以查看所有用户
- 配置用户的专属报销邮箱
- 查看所有审批记录和状态
四、开发过程中的思考
1. 为什么选择 Next.js？
前后端一体化真的太香了！
- 不用单独维护前端和后端两个 repo
- API Routes 写后端逻辑，类型定义可以和前端共享
- 部署方便，Docker 一打包就完事
2. OCR + LLM 的组合拳
一开始我想只用 LLM 看图（GPT-4V），但发现两个问题：
- 贵！一张发票几毛钱，积少成多
- 慢！响应时间不稳定
后来改成 OCR + LLM：
- PaddleOCR 先把图片转文字（便宜、快速）
- LLM 只需要理解文字（便宜、可控）
效果一样好，成本降了 90%。
3. Prompt Engineering 是个细活
让 LLM 输出正确的 JSON，前前后后调了几十版：
关键经验：
- 给一个详细的 JSON Schema 示例
- 明确告诉它「哪些字段必填」
- 加上「只返回 JSON，不要其他文字」
- 代码层再加一层容错（去掉 markdown 标记、找第一个
{和最后一个}）
4. 数据库设计的取舍
用户表、邮件表、审批历史表，这三个是核心。
发票信息怎么存？
- 一开始想单独建发票表
- 后来发现直接用 JSONB 存在审批历史里更灵活
- 查询的时候用
jsonb_array_elements展开查询，性能也够用
5. 飞书 API 的坑
- 官方 SDK 有一些bug，也有可能，最后干脆自己封装了 HTTP 请求
- 至于飞书CLI，一开始我就没想用龙虾这种agent路线来做，毕竟企业真实使用要稳定、性能
- 审批文件上传要用 FormData，注意文件类型区分（image/attachment）
- 用户部门信息要调用多个接口拼接
五、未来规划
短期
- 支持更多发票类型（定额发票、出租车票等）
- 手机端优化（现在主要是桌面端，移动端支持但还没有优化）
- 审批通过后机器人自动通知
长期
- 多租户支持（给其他子公司用）
- 发票验真（对接税务局接口）
- 数据分析（部门报销趋势、高频消费场景）
六、总结
这个项目从 idea 到上线用了两周时间，现在团队里已经有十几个人在用了。
最开心的是什么？
看到同事说「现在报销 5 分钟就搞定了」，这种价值感是写多少代码都换不来的。
技术的本质是什么？
我觉得不是炫技，而是解决真实的痛点。这个项目没有用什么高深的技术，但实实在在地提升了效率。
如果你的公司也有类似痛点，欢迎一起交流，很快我讲开源此项目，配置你的数据库和llm以及飞书应用信息，就能马上用起来～！