一人抵一队：两周交付三个月的AI项目，我只换了底座

两周上线一个企业级AI票据识别系统，工具选型：为什么是BuildingAI？

梦梦代码精

630人浏览 · 2026-02-12 17:37:40

梦梦代码精 · 2026-02-12 17:37:40 发布

两周上线一个企业级AI票据识别系统：一个独立开发者的“开挂”实录

上周五下午，一个老客户找到我：“林工，我们财务部每天手工录入300多张发票，月底对账要加三天班。能不能两周内给个方案，自动识别发票、校验真伪、关联报销单？”
我第一反应是：两周？这是要逼我请外援啊。
结果我没请外援，请了个开源平台——BuildingAI。
昨天，系统上线，财务总监发来微信：“小伙子，省了我们一个实习生编制。”

这事要是搁三年前，我绝对不敢接。
一个完整的票据智能识别与报销系统，涉及OCR模型训练、票据验真接口对接、工作流编排、用户权限分级、计费与额度管理——正经需要一个产品经理+后端+前端+算法工程师的配置，至少三个月起步。

但这次，我一个人，两周，从零到一交付上线。
这篇文章不吹水，全程记录我是怎么用 BuildingAI 把这个项目“怼”出来的。

一、需求拆解：客户要的到底是什么？

客户是一家中型商贸企业，痛点非常具体：

员工通过钉钉提交报销，但需要人工审核发票照片，识别票面信息、计算金额、查验发票状态。
财务每天在“看发票”这件事上消耗大量精力，还容易漏掉连号发票、红冲发票。
管理层想按部门统计报销费用，但现有系统只有流水账。

我拆出的技术模块清单：

OCR识别模块：支持增值税发票、出租车票、机票行程单等7种常见票据。
发票验真模块：对接国家税务总局的发票查验平台（需要模拟登录或调用第三方接口）。
工作流引擎：从提交图片 → OCR → 验真 → 关联报销单 → 推送财务审批，全流程自动化。
用户与权限系统：员工、部门主管、财务、管理员，四层角色，数据隔离。
计费模块：按次扣费（企业内部结算，虚拟币或部门预算）。
前端界面：至少一个员工上传入口和管理后台。

传统开发模式预估：

OCR：要么自研模型（需要标注几千张发票，训练、调参），要么采购第三方API（还得写集成层），3天起步。
工作流：如果从零写状态机，光异常处理就能卡一周。
用户/计费：看似简单，实则关联数据库设计、JWT鉴权、支付/扣费接口，没有一周下不来。
总工时：3人 × 3个月 = 9人月。我一个人做，乐观估计也要半年。

客户说两周，要么我疯了，要么工具疯了。

二、工具选型：为什么是BuildingAI？

我给自己列了四个必选项：

OCR能力必须内置或极低成本接入，最好有现成的票据识别模型。
工作流必须可视化，非技术人员也能看懂逻辑，便于后期交接。
用户/权限/计费必须原生支持，我绝不想从零写扣费逻辑。
开源 + 私有化部署，客户的发票数据不能出内网。

我把市面上能打的工具扫了一遍：

Dify：工作流强，但OCR靠集成外部API，用户体系和计费需要二次开发。
扣子：多智能体协作方便，但私有化部署是企业版才有的功能。
n8n：自动化神器，但和AI模型集成要写不少胶水代码。
BuildingAI：内置OCR应用市场 + 原生工作流 + 全套用户/计费模块 + Apache 2.0开源。

我决定用 BuildingAI 做 “应用底座”，把80%的通用能力交给它，我只写那20%的业务定制逻辑。

【选型日志 - 2025.03.17】

经过一下午的PoC，确认以下事实：
1. BuildingAI 应用市场里已经有“增值税发票OCR”应用，安装即用，识别率目测>95%。
2. 工作流编辑器支持HTTP节点，可以直接调用第三方验真API。
3. 用户模块自带部门、角色，完全满足客户“员工-主管-财务”分层需求。
4. 计费系统支持“按次扣费”，可以给每个部门预充值预算额度。
5. docker-compose up -d 后，整个后台就摆在那了，连登录页都做好了。

决定：不再自研核心模块，用BuildingAI重构整个系统。

三、实战记录：两周到底在做什么？

第一天：部署与初始化

# 客户给了一台8核32G的虚拟机，Ubuntu 22.04
git clone https://github.com/buildingai/buildingai.git
cd buildingai
cp .env.example .env
# 修改数据库密码、Redis配置
docker-compose -f docker-compose.prod.yml up -d
# 访问 http://192.168.1.100:3000，初始化管理员账号

整个过程不到20分钟。
登录后台，界面长这样（文字描述）：左边导航栏是“智能体”、“工作流”、“应用市场”、“用户管理”、“计费中心”……一个SaaS平台该有的，全给了。

第二天：搭建OCR识别核心

我打开 应用市场，搜索“发票”。
排第一的是官方认证的 “智能票据识别” 应用，支持增值税发票、出租车票、火车票、机票行程单。

点击“安装”，耗时3秒。
安装后，该应用出现在“智能体”列表里，我可以像调用函数一样在工作流中调用它。

【工作流测试片段】

步骤1：上传图片（前端通过API传给BuildingAI）
步骤2：调用“智能票据识别”应用
输入：image_url
输出：{
  "invoice_code": "044002200111",
  "amount": "1280.00",
  "date": "2025-03-15",
  "type": "增值税专用发票"
}
步骤3：日志输出识别结果

第一张测试发票，识别全对。OCR这块，我一行代码都没写。

第三天至第五天：构建验真与工作流

客户要求对接国家发票查验平台。
官方没有开放API，我们找了个第三方服务商，提供HTTP接口。

在BuildingAI工作流编辑器里，我拖了一个 “HTTP请求” 节点：

- id: verify_invoice
  type: http
  method: POST
  url: https://api.verify-invoice.cn/v1/check
  headers:
    Authorization: Bearer ${env.VERIFY_API_KEY}
  body:
    invoice_code: ${steps.ocr.output.invoice_code}
    amount: ${steps.ocr.output.amount}
    date: ${steps.ocr.output.date}

然后加一个 “条件分支”：

如果验真返回 status: "正常" → 进入报销流程。
如果返回 "已红冲" 或 "查无此票" → 直接拒绝，并推送消息给申请人。

整个流程从上传图片到返回结果，平均耗时3.2秒。
我以前做过类似的，光写这个状态机就得两天，现在拖拽连线，半小时搞定。

第六天至第八天：用户、权限与计费配置

BuildingAI的用户模块支持多租户级的数据隔离。
我创建了四个角色：

employee：仅可上传票据、查看自己的报销进度。
dept_manager：可查看本部门所有报销单，有初审权限。
finance：可查看全公司报销单，有终审权限。
admin：管理后台、配置计费套餐。

计费方面，客户要求每个部门每月有500元的“AI识别额度”，按次扣费（0.2元/次）。

我在 计费中心 新建了一个套餐：

套餐名称：部门月度预算
定价模式：预充值
初始额度：500元
扣费规则：调用一次“智能票据识别”应用扣除0.2元
适用对象：部门（通过用户组绑定）

全部配置完，耗时1小时。
如果自己写数据库表、设计扣费逻辑、对接支付（虽然这里是内部结算），保守估计要5天。

第九天至第十二天：前端定制与API对接

客户不想让员工学习新系统，希望直接在企业微信工作台里打开一个H5页面，上传发票。

BuildingAI提供了完整的API，包括用户登录、调用工作流、查询额度等。
我花了三天写了一个轻量级的Vue 3前端，代码量不到200行。

核心逻辑：

// 调用BuildingAI的OCR工作流
async function uploadInvoice(file) {
  const formData = new FormData();
  formData.append('image', file);
  
  const res = await axios.post('/api/flow/run/invoice-ocr-verify', formData, {
    headers: { Authorization: `Bearer ${userToken}` }
  });
  
  // 返回结果直接显示给用户
  return res.data;
}

第十三天至第十四天：测试与交付