【Dify + EdgeOne】你奶奶也会做一个“智票通”,轻松票据自定义提取+防数据泄露

0.引言

在以往使用 Dify 搭建 AI 应用的过程中,我最大的感受是:它已经把 AI 应用开发变得非常简单了。

我之前写过一篇文章,感兴趣的可以去看一看:【Dify + Bright Data MCP】:零代码构建AI社媒分析师,自动采集YouTube/TikTok/Instagram数据并生成商业洞察

不过,问题也很明显:

Dify 应用虽然在后台已经能跑通,但更多时候还是停留在"自己测试、自己使用"的阶段。如果想让其他人也能像使用正式产品一样打开网页、上传文件、输入内容、得到结果,就还需要解决前端页面和部署上线的问题。

这一步对于小白来说,往往就是最难的"最后一公里"。

EdgeOne 正好补上了这一环。它提供了 Dify 前端模板和一键部署能力,可以把已经在 Dify 中搭建好的 AI 应用,快速变成一个可以在线访问的网页工具。

Dify 负责搭建 AI 能力,EdgeOne 负责把它发布出去,让别人也能方便使用。

1.为什么要做"智票通"?

很多人在日常工作里都会遇到一个很麻烦的问题:发票、票据、报销单据一多,手动整理就非常耗时间。

比如要从一堆发票里提取:

金额、税额、发票号码、开票日期、购买方名称、销售方名称......

如果一张一张看、一条一条复制,不仅效率低,还很容易出错。更重要的是,票据本身往往包含企业名称、税号、金额等敏感信息,如果随便上传到不确定的平台,也存在一定的数据泄露风险。

所以我想做一个简单但真正实用的 Agent 工具:用户只需要上传票据,再输入自己想提取的字段,系统就可以自动识别票据内容,并返回结构化结果。

最终,我采用了 Dify + EdgeOne 的技术架构,搭建了一个智能票据提取助手 ------ 智票通

它的核心目标很简单:

让小白也可以快速搭建一个属于自己的票据解析工具,减少重复录入,提高整理效率,同时尽量降低敏感票据在多个平台之间反复流转的风险。

效果展示

Dify工作流在线地址:udify.app/workflow/vY...

EdgeOne发布地址:ai-customer-service03-kahnya39.edgeone.run/(默认域名链接仅提供限时预览)

原发票内容:

EdgeOne发布后提取:

2.AI编程开发流程

2.1 需求分析

在正式搭建之前,我先把需求拆成了几个最核心的功能。

"智票通"不需要一开始就做得特别复杂,它只需要解决一个明确的问题:

用户上传票据,输入字段,系统自动提取,并返回结构化结果。

所以这个项目的基础需求可以拆成四步:

1.用户输入提取字段

例如:金额、税额、发票号码、购买方名称。

2.用户上传发票文件

支持图片、PDF、文档等常见票据格式。

3.AI 识别票据内容

自动读取票据中的文字信息,并根据用户指定字段进行提取。

4.返回结构化结果

尽量用 JSON、表格或者清晰的字段格式展示,方便后续复制、整理和导出。

2.2 技术栈介绍

这个项目主要使用两个工具:

  • Dify:负责搭建 AI Agent 工作流;
  • EdgeOne Pages:负责快速部署前端页面,让用户可以通过网页访问这个工具。

整体架构可以理解为:

2.1 Dify

Dify 是一个比较适合搭建 AI 应用的平台。它可以通过可视化工作流的方式,把大模型、提示词、变量、文件输入、知识库、工具调用等能力组合起来。

对于不会写太多代码的人来说,Dify 的优势是:

  1. 可以通过拖拽节点搭建工作流;
  2. 支持输入变量和文件上传;
  3. 可以接入大模型完成文本理解和信息抽取;
  4. 可以通过 API 对外提供服务;
  5. 适合快速做出 AI 应用原型。

在"智票通"这个项目里,Dify 主要负责三件事:

  1. 接收用户上传的票据;
  2. 识别票据中的文字内容;
  3. 按照用户要求提取指定字段。

2.2 EdgeOne

EdgeOne Pages 可以理解为一个前端部署平台。

如果只在 Dify 里面测试应用,虽然可以跑通流程,但用户体验还是偏"后台工具"。如果想把它做成一个真正可以访问的网页应用,就需要一个前端页面。

EdgeOne Pages 的作用就是帮助我们快速部署一个前端项目,让用户可以通过浏览器直接使用"智票通"。

在这个项目中,EdgeOne 主要负责:

  1. 部署前端页面;
  2. 对接 Dify 应用 API**;**
  3. 提供一个更接近真实产品的访问入口;
  4. 让项目从"** 工作流** Demo"变成"可访问网页应用"。

2.3 为什么Dify* EdgeOne

我选择这套组合,主要是因为它对小白比较友好。

需求 对应工具 原因
搭建 AI 工作流 Dify 不需要从零写 Agent 后端
文件上传与字段输入 Dify 原生支持变量和文件输入
发票内容识别 Dify + 大模型 适合做结构化信息抽取
前端页面部署 EdgeOne Pages 可以快速上线网页
API 调用 Dify API 方便前端调用
快速做 Demo Dify + EdgeOne 开发成本低,适合小白上手

简单来说:

Dify 负责"聪明的大脑",EdgeOne 负责"可以访问的网页"。

这两个结合起来,就可以比较快地搭出一个可用的智能票据提取系统。

3.Dify ------ 智票通

3.1 新建一个空白应用。

首先打开 Dify 控制台:cloud.dify.ai/apps

新建一个空白应用,输入内容如下:

智票通 - 批量发票智能解析 用户上传发票 + 输入想提取的字段,例如"金额、税额、发票号码、购买方名称" → 系统自动识别并返回结构化结果。

这样,一个基础的 Dify 应用就创建好了。

3.2 输入节点

接下来进入工作流配置。

在输入节点中,我设置了两个核心变量:

变量一:提取字段

这个变量用于接收用户想要提取的内容。

例如用户可以输入:

金额、税额、发票号码、购买方名称、销售方名称、开票日期

变量名称可以设置为:

yaoqiu

变量说明:

用户希望从票据中提取的字段,可以是金额、税额、发票号码、购买方名称等。

变量二:发票票据

这个变量用于接收用户上传的发票文件。

变量名称可以设置为:

shuru

文件类型建议选择:

  • 图片;
  • PDF;
  • 文档。

这样可以兼容常见的票据格式,比如:.jpg / .png / .pdf / .docx

3.3 字段标准化

用户输入字段时,往往不会特别标准。

比如有的人会输入:

钱数、税、发票号、买方、卖方

但系统最好能理解成:

金额、税额、发票号码、购买方名称、销售方名称

所以我在工作流里增加了一个"字段标准化"节点。

这个节点的作用是:

把用户随意输入的字段,转换成更标准、更适合抽取的字段名称。

具体提示词如下:

Markdown 复制代码
你是一个发票字段标准化助手。请将用户输入的字段转换为标准发票字段。

【用户输入】



【可用标准字段】
- invoice_number:发票号码
- invoice_code:发票代码
- issue_date:开票日期
- buyer_name:购买方名称
- buyer_tax_id:购买方纳税人识别号
- seller_name:销售方名称
- seller_tax_id:销售方纳税人识别号
- item_name:项目名称/商品名称
- amount_without_tax:不含税金额/金额
- tax_rate:税率
- tax_amount:税额
- total_amount_with_tax:价税合计/总金额/小写金额
- total_amount_uppercase:价税合计大写
- remarks:备注
- 具体的你也可以按照它里边有的进行提取

【规则】
1. 用户输入"金额"时,默认映射为 amount_without_tax。
2. 用户输入"总金额""合计金额""价税合计"时,映射为 total_amount_with_tax。
3. 用户输入"税额"时,映射为 tax_amount。
4. 无法识别的字段,normalized_field 填写 unknown。
5. 只输出 JSON。

【输出格式】
{
  "fields": [
    {
      "user_requested_field": "",
      "normalized_field": "",
      "description": ""
    }
  ]
}

比如用户输入:

钱数、税、发票号、买方

系统可以标准化为:

Plain 复制代码
[
  "金额",
  "税额",
  "发票号码",
  "购买方名称"
]

这样后面的发票抽取节点就会更稳定。

3.4 发票抽取

接下来是整个工作流最核心的部分:发票抽取。

这个节点负责读取用户上传的票据文件,并根据标准化后的字段列表,提取对应内容。

提示词如下:

JavaScript 复制代码
你是一个专业的发票和票据解析助手。

用户会上传一张或多张发票/票据文件,并提供需要提取的字段列表。请你根据票据内容,准确提取对应字段。

要求:
1. 只提取用户要求的字段;
2. 如果某个字段在票据中没有找到,请返回 null;
3. 不要编造票据中不存在的信息;
4. 如果上传了多张票据,请分别返回每张票据的结果;
5. 输出必须为结构化 JSON;
6. 金额、税额、价税合计等字段需要尽量保留原始格式;
7. 如果票据内容不清晰,请在结果中标注"识别不清"。

用户需要提取的字段:
{{标准化字段列表}}

用户上传的票据文件:
{{invoice_files}}

请按照以下格式输出:

[
  {
    "文件名": "文件名",
    "字段1": "提取结果",
    "字段2": "提取结果",
    "字段3": "提取结果"
  }
]

这个提示词有一个关键点: 不要让模型自由发挥,而是要求它严格按照 JSON 输出。

因为票据提取的结果后面很可能还要进入 Excel、数据库、报销系统或者财务系统,所以结构化格式非常重要。

3.5 测试智票通

这里我选择上传了一张真实的票据,并要求提取信息如下:

发票号码,开票日期,票价,出发站和到达站,电子客票号

我们可以得到的结果如下:

可以看到,Dify 成功地对我们的需求进行了一个处理。

4.EdgeOne

Dify 里的工作流跑通之后,下一步就是把它变成一个真正可以访问的网页。

这里我选择使用 EdgeOne Pages。

EdgeOne Pages 模板库里提供了一些适合 Dify 应用的前端模板,例如:

全场景应用模板使用教程:Dify Frontend Starter Template - EdgeOne Pages

智能客服模板使用教程:AI Customer Service Template - EdgeOne Pages

4.1 选择 EdgeOne Pages 模板

这里我们选择智能客服模板:

在EdgeOne Pages模板库中选择 Dify 前端模板,点击部署

4.2 获取 Dify API Key 和 API URL

获取Dify应用的API KEY和API URL,并在Pages项目设置中填写

Dify API Key Dify API URL

4.3 在 EdgeOne Pages 中填写环境变量

4.4 等待部署完成

然后整个过程只需要耐心等待即可。

配置完成后,EdgeOne Pages 会自动开始部署。

整个过程不需要太复杂的操作,只需要等待构建完成即可。

部署成功后,会生成一个访问链接。

打开链接,就可以看到属于自己的"智票通"网页应用。

我的测试地址是:

md 复制代码
https://smartinvoice-batch-parser-kgfzi2xw1b.edgeone.app/

进入页面后,上传票据并输入字段,就可以完成提取。

下面我们就实际地来测试一下:

5.发布

5.1 Dify操作中心发布

除了通过 EdgeOne 发布网页,我还把这个应用发布到了 Dify 市场。

模板地址:

md 复制代码
https://marketplace.dify.ai/template/lucianaib/%E6%99%BA%E7%A5%A8%E9%80%9A%20-%20%E6%89%B9%E9%87%8F%E5%8F%91%E7%A5%A8%E6%99%BA%E8%83%BD%E8%A7%A3%E6%9E%90?templateId=14b0845b-290c-4779-83c3-5b31edb24b37&creationType=templates

这样,其他人如果对这个项目感兴趣,也可以直接获取模板。

不过需要注意:

Dify 市场模板只是让别人更方便复用工作流,但如果想让普通用户直接访问,仍然需要结合 EdgeOne 这类前端部署工具。

也就是说:

  • Dify 市场适合分享应用模板;
  • EdgeOne Pages 适合把应用发布成网页产品。

两者解决的问题不一样,但可以组合起来使用。

5.2 EdgeOne发布

后的效果如图中所示,成功地进行了提取:

6.遇到的问题

在第一次部署成功以后,它显示:

Please check if your app mode matches the right API route.

原因:这个"智票通 - 批量发票智能解析"是 Workflow 应用 ,但 EdgeOne 前端可能把它当成了 Chat / Agent 去调用了。

解决办法:

EdgeOne 的 Dify Frontend Starter 模板中 NEXT_PUBLIC_APP_TYPE 支持:

Plain 复制代码
workflow

由于这里的第三个选项为"非必选项",所以在设置的时候有的人不会注意,但这里也是需要进行设置的。

7.总结

这次用 Dify + EdgeOne 搭建"智票通"的过程,整体体验还是比较顺畅的。它让我明显感受到,现在做一个 AI 应用已经不再是"必须会全栈开发"的事情,而是可以通过可视化工作流和前端模板,把一个想法很快变成一个能访问、能使用的网页工具。

当然,在实际配置过程中也有一个需要注意的地方。

7.1 需要注意的地方

这次我遇到的主要问题,是 EdgeOne 模板里的 NEXT_PUBLIC_APP_TYPE 这个选项容易被忽略

因为它在配置页面里并不是特别显眼,而且看起来像是一个"非必选项",所以第一次部署时很容易不填。

但如果你的 Dify 应用是 Workflow 类型,这里就必须设置为:

Plain 复制代码
workflow

否则前端可能会把 Workflow 应用当成 Chat / Agent 应用去调用,导致接口路径不匹配,最终出现类似:

Plain 复制代码
Please check if your app mode matches the right API route.

所以这里需要特别提醒一下:

如果你用的是 Dify Workflow 应用,一定要检查 EdgeOne 环境变量里的 NEXT_PUBLIC_APP_TYPE 是否设置为 workflow

这个问题本身不复杂,但对于第一次使用模板的小白来说,确实容易卡住。

7.2 值得表扬的地方

除了这个小配置点之外,Dify 和 EdgeOne 的组合真的非常适合 AI 应用快速落地

Dify 负责把 AI 能力搭起来。

它让我们不用从零写复杂后端,也不用自己处理模型调用、文件输入、提示词编排这些问题。通过可视化工作流,就可以快速完成票据识别、字段提取、结构化输出等核心能力。

EdgeOne 则负责把这个 AI 应用发布出去。

它解决的是"最后一公里"的问题:让原本只能在 Dify 后台测试的应用,变成一个可以通过网页访问的工具。用户不需要理解工作流,也不需要知道 API 怎么调用,只需要打开网页、上传文件、输入字段,就能直接使用。

所以这套组合最让我满意的地方是:

Dify 让 AI 应用"能做出来",EdgeOne 让 AI 应用"能给别人用"。

这对小白和创作者来说非常重要。

因为很多 AI 应用卡住的地方,不是想法不够好,也不是工作流跑不通,而是做完之后不知道怎么发布、怎么让别人访问、怎么变成一个真正像产品的工具。

而 Dify + EdgeOne 正好把这条链路打通了。

这次的"智票通"只是一个很小的案例,但它证明了一件事:

AI 应用不一定一开始就要做得很复杂。 只要能解决一个具体问题,并且能让别人方便使用,它就已经具备了实际价值。

从这个角度来看,Dify 和 EdgeOne 的组合非常适合用来做 AI 工具原型、活动 Demo、轻量级 SaaS 页面,以及各种创作者的小应用。

它让 AI 应用从"我自己能跑",真正向"别人也能用"迈进了一步。

相关推荐
python在学ing2 小时前
前端-CSS学习笔记
前端·css·python·学习
Bug-制造者2 小时前
【Vue3 实战】全局错误处理体系搭建:实现业务与错误彻底解耦
前端·javascript·vue.js
程序员老邢2 小时前
【技术底稿 37】Spring Boot 3.x 自动装配 “死锁” 排查:3 个注解实现条件化装配与 Mock 兜底
java·spring boot·后端·自动装配·rag·技术底稿
悟空瞎说2 小时前
# Git 交互式变基:优雅整理提交历史,告别杂乱 PR 记录
前端·git
用户434309241693 小时前
Day29:图片上传 + 存数据库(Multer + MySQL)
数据库·后端
码路高手3 小时前
Hermes Agent 整体了解
后端·架构
还有多久拿退休金3 小时前
DragSortTable:一个让我怀疑人生的滚动重置 Bug
前端
日月云棠3 小时前
JAVA数据结构与算法 - 基础:链表
java·后端
渐儿3 小时前
组件库开发入门到生产(从零封装到 npm 发布)
前端