首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >【Dify + EdgeOne】你奶奶也会做一个“智票通”,轻松票据自定义提取+防数据泄露

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

原创
作者头像
LucianaiB
发布2026-05-19 18:32:28
发布2026-05-19 18:32:28
3080
举报
文章被收录于专栏:AIAI

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工作流在线地址:https://udify.app/workflow/vYQWiboCqWL2EUlJ

EdgeOne发布地址:https://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 控制台:https://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 应用从“我自己能跑”,真正向“别人也能用”迈进了一步。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 0.引言
  • 1.为什么要做“智票通”?
    • 效果展示
  • 2.AI编程开发流程
    • 2.1 需求分析
    • 2.2 技术栈介绍
      • 2.1 Dify
      • 2.2 EdgeOne
      • 2.3 为什么Dify* EdgeOne
  • 3.Dify —— 智票通
    • 3.1 新建一个空白应用。
    • 3.2 输入节点
      • 变量一:提取字段
      • 变量二:发票票据
    • 3.3 字段标准化
    • 3.4 发票抽取
    • 3.5 测试智票通
  • 4.EdgeOne
    • 4.1 选择 EdgeOne Pages 模板
    • 4.2 获取 Dify API Key 和 API URL
    • 4.3 在 EdgeOne Pages 中填写环境变量
    • 4.4 等待部署完成
  • 5.发布
    • 5.1 Dify操作中心发布
    • 5.2 EdgeOne发布
  • 6.遇到的问题
  • 7.总结
    • 7.1 需要注意的地方
    • 7.2 值得表扬的地方
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档