用 AI Builder 读取传真送达的订单 ── 减少手动录入转录的现实设计与局限

「四成的订单还是靠传真。看着一体机吐出来的订单，一件一件敲进销售管理系统里」。在制造业、批发业的咨询中，这真的是经常听到的说法。紧接着出现的还有「和客户的关系还没到能拜托对方改用 Web 下单的地步」「越是大客户，对方的订购系统就越是以发送传真为前提，动不了」这类情况。

改善传真订单大体有两条路线。一条是迁移到 Web 订单或 CSV 导入，「废除传真」的路线。另一条是保持接收传真的现状，把读取和转录自动化，「与无法废除的传真共处」的路线。前者已经在另一篇文章《把传真订单迁移到 Web ── 双轨运行期的设计与分阶段迁移实务》中讨论过。本文谈的是后者，也就是把传真作为 PDF 数据接收，用 AI Builder 的文档处理读取，插入人工确认后再对接到订单台账和核心系统的设计。

先说在前面，这套机制不会、也不应该做到「全自动」。即便如此，如果能把每天 1～2 小时的转录作业，压缩到「只需确认读取结果」的几十分钟，对很多公司来说都是值得的投资。本文将基于 Microsoft Learn 可查证的规格，梳理能自动化到什么程度、局限又在哪里。

1. 先说结论

• 传真读取自动化的前提是以数据（PDF）而非纸张来接收传真。要从用一体机的传真转发功能或云传真服务把接收到的传真文件化、汇集到 SharePoint 开始。
• AI Builder 的文档处理自定义模型，可以从订单这类独有版式的单据中提取字段和表格。学习以「同一版式的单据＝集合」为单位，每个集合至少需要 5 份（最多 20 份）样本。¹²
• 无论是固定模板文档还是通用文档，两种学习类型都支持日语，FAQ 中也明确写明支持提取手写文字。不过在传真质量的实际单据上究竟能读到什么程度，必须用自家样本加以验证。³²
• 流程的关键在于用置信度分数分流。提取结果会为每个字段附带 0～1 的分数，因此要设置分支：高置信度自动记录到台账，低置信度则转给人工确认。不要放弃「全部由人来核对」这一底线，而是设计成「让确认变轻松」的形式。⁴
• 不要试图读取所有客户的单据。由于机制是按版式区分集合，只针对件数排名靠前的客户的定型订单也能见效。低质量单据可以增加样本至 15～20 份，这是官方给出的应对建议。²⁵
• AI Builder 另外需要消费型的积分。文档处理按页消耗，自定义模型的消耗速率比预构建模型更高。随着 2025 年 10 月宣布的 AI Builder 积分分阶段终止，体系正在向 Copilot 积分过渡。⁶⁷
• 读取并非万能。根据件数、客户数量、单据的定型程度不同，Web 订单迁移或 EDI 有时才是正道（参见第 8 章的判断表）。

2. 「废除」与「读取」── 不要混淆两条路线

在接到传真订单相关的咨询时，首先要确认的是「对方是否是可以废除传真的客户」。

迁移到 Web 订单，是需要客户改变行为的举措。正如分阶段迁移那篇文章所写，应该从件数多、系统上又能配合的客户开始依次迁移，在效果大的地方优先减少手动录入。但另一方面，怎么也动不了的客户会一直存在。对方的订购业务就是以传真为前提在运转、负责人年纪大了没法拜托其改用 Web 录入、又或者自家公司本来就不处于「可以拜托对方」的强弱关系中——这类客户的传真，现实地看，恐怕会以数年为单位持续存在。

于是「读取」这条路线便应运而生。关键在于，这两条路线并不互斥。

「读取」路线最大的优点，是完全不要求客户做出任何改变。在分阶段迁移的双轨运行期间，它也能作为降低传真渠道处理成本的手段发挥作用。反过来，它的局限也很明确：读取精度不可能达到 100%，因此确认这道工序会一直存在。如果试图读取每个客户版式都不同的所有单据，模型的维护会让人疲于奔命。正因如此，能迁移的客户就迁移，剩下的客户则读取其传真——要以这样的组合来思考。

另外，以邮件附件形式送达的 PDF 订单的处理方式，已经在《用 Power Automate 自动处理邮件收到的订单・发票 PDF ── 保存、分类、通知与读取的设计》中讨论过。如果传真是通过邮件转发接收的，接收之后的设计正是本文与邮件那篇文章的交汇之处。

3. 前提：以「数据」形式接收传真 ── 停留在纸质阶段就无法开始

能传给 AI Builder 的只有文件。如果运营方式是把一体机打印出来的纸张再重新扫描一次，那只是把手工作业从转录变成了扫描，谈不上自动化。首先要做的是，建立接收到的传真无需人工介入即可作为文件保存下来的路径。现实中可行的选项有两个。

• 一体机的传真转发功能。多数商用一体机可以在不打印接收传真的情况下，将其保存到指定文件夹（扫描到文件夹）或以邮件附件形式转发出去。具体设置需要向机型说明书和维护服务商确认。
• 云传真服务。把传真号码整体迁移到云服务，通过邮件或 API 以 PDF 形式接收传真。这样可以无需更换一体机即可实现数据化，但号码可携性以及资费体系需要逐一向服务商确认。

无论走哪条路径，都建议把落地点统一到 SharePoint 的文档库。因为 SharePoint 连接器提供「已创建文件（仅限属性）」触发器和「获取文件内容」操作，可以直接把保存动作作为后续读取流程的起点。⁸ 如果是通过邮件转发接收，则可以在前端加一个流程：用共享邮箱接收邮件，把附件 PDF 保存到 SharePoint（这一设计与邮件附件那篇文章的第 3～4 章完全相同）。

关于文件格式有一点需要注意。根据一体机的转发设置，传真有时会以 TIFF 格式保存。AI Builder 的文档处理在训练模型时只能使用 PDF、JPG、PNG，但在云端流程中运行已训练好的模型时，也可以处理 TIFF。³ 不过考虑到学习样本的准备工作，转发设置直接选择输出 PDF 会更省心。同时也要留意，可处理的文件大小上限为 20 MB，图像文件的尺寸限制为 50×50～10,000×10,000 像素。³

4. AI Builder 的文档处理能做什么

自定义模型的学习机制

AI Builder 的文档处理，是一种利用样本单据来学习「这份单据的哪个位置写了什么」的自定义 AI 模型。创建模型时，首先要选择文档类型。¹

如果是客户的定型订单，基本上选固定模板文档即可。接下来，定义想要提取的信息。可以指定字段（订单编号、订单日期、客户名称、送货地点等）、表格（品名・数量・单价等明细行）以及复选框。¹

学习的单位是集合。所谓集合，就是「同一版式单据的分组」，像客户 A 的订单与 B 公司的订单这种版式不同的单据，需要分到不同的集合。每个集合需要上传至少 5 份样本文档，并对字段和表格的位置进行标注后再训练。每个集合最多可上传 20 份样本，每个模型最多可创建 200 个集合。¹³ 高质量文档往往 5 份就足够，而低质量的扫描件官方 FAQ 中建议使用 15～20 份。²

创建模型的步骤

由于训练与测试不会消耗积分⁹，先动手做一个是最快的捷径。界面上的操作路径如下（菜单名称按 Microsoft Learn 的表述）。¹

1. 登录 Power Apps（make.powerapps.com）或 Power Automate（make.powerautomate.com）。
2. 打开左侧栏的 … More（更多） > AI hub。如果常用，可以固定（Pin）在那里方便调用。
3. 从 Discover an AI capability 中选择 AI models。
4. 选择 Extract custom information from documents（从文档中提取自定义信息）。
5. 选择 Create custom model，向导就会开始。
6. 在 Choose document type 中选择文档类型。若是客户的定型订单，选 Fixed template documents（固定模板文档）。
7. 在 Choose information to extract 中，通过 +Add 定义想提取的项目。可以添加文本、数字、日期、复选框、表格，数字可以在此指定小数点符号（. 或 ,），日期可以指定年月日的排列顺序，表格可以指定列结构。
8. 按版式分别建立集合，每个集合上传5 份以上的样本（JPG、PNG、PDF）。如果两家客户版式不同，就建立两个集合。
9. 在上传的每份样本上，对第 7 步定义的项目所对应的位置进行标注。
10. 用 Train 进行训练，用 Quick test 进行测试。确认读取结果符合预期后，就发布（公开），使其能够从流程中调用。

如果在自家样本尚未到手的阶段只想先试试操作，也可以用 Microsoft 提供的样本数据来创建模型。¹

另外，与第 6 步选择的文档类型不同，模型内部还持有一个文档智能（Document Intelligence）的版本（v4.0 / v3.1）。这个版本由最后一次编辑的时机决定，可以在 Settings > Published model version 中确认。表格与单元格的置信度分数只有 v4.0 才能获得，较旧的模型只要重新编辑、重新训练、重新发布，就会升级到 v4.0。¹

对日语与手写文字的支持

处理日语单据时应确认的要点，可以在 Microsoft Learn 中查到以下内容。

• 无论是固定模板文档还是通用文档，两种学习类型的支持语言中都包含日语。³
• 官方 FAQ 中明确写明「文档处理可以提取印刷文本和手写文本」。²

不过，这里要如实说明。「支持」与「自家的传真能以实用精度读取」之间是有距离的。传真分辨率低，字迹模糊、粘连、倾斜是家常便饭。手写的数量修正或潦草的备注能否读出来，取决于单据的书写方式。文档处理的模型训练与测试都是免费的⁹，因此在做导入决策之前，请务必用实际接收到的传真 PDF 本身作为样本进行训练和测试，确认在自家单据上的精度。如果用清晰的原始 PDF 来训练，实际运行时却用传真，就容易因为测试与生产环境的画质差异过大而导致精度上不去，这是常见的失败模式。

与预构建模型的区别

AI Builder 还提供无需训练的预构建模型。其代表是发票处理模型，可以在不训练的情况下提取发票编号、开票日期、付款金额等通用字段，支持的语言中包含日语。¹⁰ 如果是发票处理，先试试这个是最快的捷径。

另一方面，没有面向订单的预构建模型。像订单、采购单、送货单这种版式因公司而异的单据，官方 FAQ 中也把它作为固定模板文档自定义模型的典型例子举出²，本文的主题——传真订单，正属于自定义模型的领域。

5. 流程整体设计 ── 插入人工确认

整体结构如下。关键在于正中间的「人工确认」，省略这一步的全自动结构，出于后文所述的理由，并不推荐。

flowchart TD
    Fax[客户发来传真] --> Digitize[一体机的传真转发 / 云传真服务<br/>以 PDF 形式保存至文件夹或邮件]
    Digitize --> Save[保存至 SharePoint 文档库<br/>包含接收时间的唯一文件名]
    Save --> Trigger[启动云端流程<br/>触发条件为已创建文件]
    Trigger --> AIB[AI Builder 处理文档<br/>提取订单编号、客户、交期、明细]
    AIB --> Score{置信度分数判断<br/>例如主要字段是否均达到0.9以上}
    Score -- 高置信度 --> Ledger[记录至订单台账列表<br/>状态为自动读取完成、未确定]
    Score -- 低置信度 --> Review[向负责人发送确认请求<br/>Teams通知加原始PDF链接]
    Review --> Fix[与原件核对后修正并确定<br/>状态为已确认]
    Ledger --> Batch[汇总列表统一确认并确定<br/>状态为已确认]
    Fix --> Entry
    Batch --> Entry[录入核心系统－仅限状态为已确认的行<br/>CSV导入 / Power Automate for desktop]

读取步骤

在流程中，向「处理文档（Process documents）」操作传入训练并发布好的模型，以及从 SharePoint 获取的文件内容（这个操作在 2025 年 5 月由「从文档中提取信息」更名而来）。输出中包含所定义各字段的值（{字段} value）与置信度分数（{字段} confidence score），以及表格中每个单元格的值与分数。对于多页文档，还可以指定要处理的页面范围来控制消耗量。⁴

在实现上要注意，提取出来的值全部以字符串形式返回。要把数量或金额写入台账的数值列，需要用 int/float 表达式转换，货币符号和空白则用 replace 表达式去除。日期也需要用 formatDateTime 表达式统一格式。⁴ 传真号码和订单编号的全角半角差异，也建议在这一步就做归一化处理，这样后续的核对会更轻松。

确认步骤 ── 这是关键

读取结果的确认，比较容易搭建的有以下两种形式。

1. 在台账列表的状态列上流转确认。将订单台账保存为 SharePoint 列表，读取结果以「待确认」状态登记，负责人在列表上对照原始 PDF（附件或链接）进行修正，再把状态改为「已确认」。以状态变更为「已确认」作为触发条件，启动后续处理。把台账从 Excel 迁移到 SharePoint 列表的设计，已经在《把 Excel 台账替换为 SharePoint 列表》中讨论过。
2. 用 Teams 审批来流转确认。使用审批（Approvals）连接器的「开始并等待审批」操作，配合自定义响应，让负责人在「直接登记」「需要修改」这类选项中做出判断。审批的搭建方法与响应的处理，在《用 Power Automate 搭建审批流程 ── 将纸质与邮件签核、申请电子化》中有详细说明。¹¹

无论采用哪种形式，都要把通知统一汇集到 Teams 频道，并务必附上指向原始传真 PDF 的链接。¹² 确认工作的本质是「读取结果与原件的核对」，如果打开原件很麻烦，确认工序就容易流于形式。

从台账到核心系统

把已确认的数据录入核心系统的方式，取决于核心系统一侧的入口。如果有 CSV 导入功能，把已确认数据整理成 CSV 再导入是稳妥的做法。如果没有导入功能、只能通过界面录入，那么用 Power Automate for desktop 进行界面操作的自动转录就是一个选项。这一设计已经在《用 Power Automate for desktop 实现核心系统转录自动化》中讨论过。整个流程的错误处理（读取失败时的通知、重新执行）可以直接沿用《Power Automate 的错误处理与重试设计》中的思路。

6. 与精度共处 ── 即使无法全部读取也能见效

用置信度分数分流

以「读取有可能出错」为前提，设计的核心就在于如何使用置信度分数。分数为 0～1，越接近 1，表示提取值正确的可能性越高。⁴ 在实务中，可以按如下方式划分：

• 订单编号、客户、交期、明细等主要字段全部达到阈值（例如 0.9）以上 → 标记为「自动读取完成」录入台账，负责人只需汇总核对整个列表，做确定操作即可
• 只要有任意一项低于阈值 → 标记为「待确认」转给负责人，在通知中明确列出分数低的字段，让其对照原件修正

实现上只需一个「条件」操作即可。在「处理文档」之后放置条件，从动态内容列表中选择 {字段名} confidence score，与阈值比较。如果要对多个主要字段一并判断，可以把条件切换为高级模式（表达式），用 and 连接。以下 <...> 按 Microsoft Learn 示例的写法，代表「从动态内容中插入的位置」。⁴

and(
  greaterOrEquals(<订单编号 confidence score>, 0.9),
  greaterOrEquals(<客户名称 confidence score>, 0.9),
  greaterOrEquals(<交期 confidence score>, 0.9)
)

写表达式时有两个要点。

• 值与分数的类型不同。 {字段} value 是字符串，而 {字段} confidence score 以 0～1 的 float 类型返回，因此分数可以直接进行数值比较。只有在把金额或数量本身用于条件判断时，才需要用 float() 或 int() 转换。⁴
• 明细表的单元格也带有分数（{表名}{列名} confidence score）。不过一旦引用了表格的列，该操作就会自动被放入「Apply to each」循环中。如果想对整张明细表一并判断，比较好处理的做法是准备一个变量（例如把 minScore 初始化为 1.0），在循环内把每一行的分数与当前值比较并保留最小值，循环结束后再统一与阈值比较一次。⁴ 另外，表格与单元格的置信度分数，只有文档智能 v4.0 的模型才能获得。¹

在条件的「是」分支登记为「自动读取完成」录入订单台账，在「否」分支分流到 Teams 通知与待确认登记，这一章讲的分流逻辑就直接变成了流程本身。

请注意，即便是高置信度一侧，也不代表可以省略确认本身。分数只表示「正确的可能性较高」，并不是正确性的保证。即使高置信度，也仍然会出现读错的情况，因此只把人做过确定操作的「已确认」行交给核心系统这道关卡，与分数无关，必须始终维持。可以根据分数调整的，是确认的分量（是汇总统一确定，还是逐条修正），而不是要不要确认。

阈值不要一开始就定死，而应根据运行开始后「明明标记为自动、实际却是错的」这类件数，边观察边调整。重要的是，错误的成本是不对称的。即便过度倾向于「待确认」，也只是让确认的工作量略有增加而已；但如果误读的内容被自动放行，就会导致误发货。拿不准的时候，把阈值定得高一些。

传真画质这一宿命

文档处理的要求中写着「从纸质扫描应为高质量图像」「嵌入文字的 PDF（文本 PDF）不会出现乱码或位置偏移，更为理想」。³⁵ 传真恰恰处于这一理想的对立面。即便如此，还是有能做的对策。

• 让学习样本使用实际的传真件。如前所述，用与实际运行时相同的画质来训练是第一要务。低质量图像的情况下，官方建议把样本增加到 10～15 份以上。⁵
• 向发送方争取提升质量。对于重要客户，有时可以拜托对方「用高画质（精细）模式发送」。虽然整体路线是不要求客户改变，但发送按钮旁边的一个设置，属于比较容易拜托的范畴。
• 不要勉强读取读不出来的单据。字迹模糊严重、手写内容占大半这类单据，往往会常态化地流向待确认。这时也需要判断，把该客户排除在读取对象之外，照旧改回手动录入。

版式因客户而异的问题

订单的版式，有多少个客户就有多少种。文档处理的设计正是通过集合来吸收这种差异，可以按版式分别建立集合，汇总到一个模型中（最多 200 个）。³ 不过，集合越多，样本收集与标注、精度验证、跟进版式变化的维护成本也就越高。只要客户改了订单的样式，对应的集合就得重新训练。

正因如此，起步方式不应是「全部读取」，而应是「只读取件数排名靠前的客户的定型订单」。假设传真订单每月有 600 件，排名前三的客户占了 350 件，那么只需 3 个集合（各 5～20 份样本）的模型，就能覆盖近六成的转录工作。剩下的部分照旧手动录入即可。这正是分阶段迁移那篇文章中「从效果最大的地方开始动手」原则的读取版，Web 迁移时的客户分类（A/B/C）也可以直接沿用。先在试点中打磨出一套模式、测量效果之后再逐步增加集合，这种推进方式能够防止模型维护把人拖垮。

细节上的限制也要确认一下。目前不支持跨页字段，也不支持跨页折行的明细行。³ 对于多页订单较多的客户，明细的设计需要格外注意。

7. 许可与费用感 ── 积分这一消费模式

AI Builder 的操作，是在 Power Automate 许可证之外，每次执行都会另外消耗消费型的容量。如果不了解这一点就开始搭建，在生产环境中很可能会遇到 NoCapacity 系列的错误。⁹

机制是这样的：文档处理会按处理的页数消耗积分（即便页面上没有提取对象数据，也照样消耗）。² 消耗速率因功能而异，在官方的速率表中，自定义模型的文档处理为每页 100 AI Builder 积分，预构建的发票处理等为每页 32 积分，在 Copilot 积分体系下，作为内容处理，则定义为每页 8 Copilot 积分。⁶

积分的获取途径，以往主要有以下两种。⁹

• AI Builder 容量附加组件：每个附加组件 100 万积分
• Premium 许可证附带的种子积分：每份 Power Automate Premium 许可证附带 5,000 积分

积分以租户为单位汇集，由管理员分配到各环境中使用。粗略估算一下，Premium 附带的 5,000 积分相当于自定义模型文档处理 50 页的量。如果单页订单每月不超过 50 件，用附带的额度就能覆盖；如果每月有 600 件，就属于需要购买附加组件或 Copilot 积分的规模了。

消耗量的概算

具体金额会因时点和合同而变化，本文不作讨论，但消耗的积分量可以根据公开的速率表自行计算。自定义模型的文档处理为每页 100 AI Builder 积分，在 Copilot 积分体系下，作为内容处理为每页 8 Copilot 积分。⁶ 只需乘以每月的读取页数即可。

这一计算思路，与 Microsoft 官方 FAQ 中的示例（收据处理 32,000 件×32 积分＝1,024,000 积分 → 用 1 个附加组件加 5 份 Premium 来补足）相同。⁹ 实际需要支付的金额，是把这个消耗量乘以自家合同的单价（附加组件或 Copilot 积分的价格、汇率及折扣的适用情况）算出来的。Power Platform 许可证指南（PDF）中有速率卡，报价请以该指南和最新的价格信息为准进行确认。⁹

需要注意的是，消耗量按月重置，未用完的部分不会结转到下个月。⁹ 如果为了应对旺季的高峰而多备一些额度，淡季用不完的部分就会白白浪费。通过指定页面范围来减少无谓的读取、把读取对象限定在件数排名靠前的客户上，这类设计层面的节约，会直接体现在费用上。

积分耗尽时的应对

如果流程因 NoCapacity、EntitlementNotAvailable、QuotaExceeded、No capacity was found、Credit usage exceeds allocation 等错误而失败，需要确认分配给该环境的积分。流程设计器中会出现「All AI Builder credits in this environment have been consumed（此环境的 AI Builder 积分已全部用尽）」的修复面板。⁹

确认与应对的步骤如下。⁹

1. 打开 Power Platform 管理中心的 Licensing（许可证） > Capacity add-ons（容量附加组件） > Summary 标签页，确认已购买、已分配、已消耗的积分数量。
2. 各环境的消耗量可以通过 AI Builder 消耗报告确认。把当月的数据汇总起来，就是该环境的月消耗量。
3. 如果不够，可以在同一画面的 Add-ons 标签页中，通过 Assign to an environment 重新分配到环境（可以调用整个租户或其他环境的富余部分）。
4. 如果仍然不够，可以考虑追加购买容量附加组件（仅限现有客户，截止到 2026 年 11 月 1 日）或购买 Copilot 积分、开通按量计费。

这里有一个需要牢记的规格。一旦给环境分配了积分，该环境就不会自动使用租户中未分配的积分。⁹ 「明明整个租户还有余额，偏偏这个环境就是停了」这种事故，如果不了解这项规格，就很难找到原因。反过来，没有分配过积分的环境，会使用租户中未分配的部分。建议在正式运行之前，与管理员一起确认要放置读取流程的环境处于哪种状态。

不过，这一体系目前正处于过渡期。2025 年 10 月，Microsoft 宣布了 AI Builder 积分的分阶段终止。2025 年 11 月 1 日起，新客户将无法购买 AI Builder 容量附加组件，而2026 年 11 月 1 日，附加组件的续订将终止，Premium 许可证附带的种子积分也将被废止。AI Builder 的功能本身不会消失，仍可继续通过 Copilot 积分使用。过渡期内的优先顺序是：先消耗 AI Builder 积分，用尽后消耗 Copilot 积分，两者都没有时执行才会被阻断。⁷

总而言之，就是「读取需要与执行量对应的额外成本，而这种成本所用的『货币』正在切换」。本文不列出具体金额，但请根据每月的传真件数×页数，用速率表估算消耗量，并结合最新的价格信息进行确认。关于 Power Automate 一侧的许可证（标准/高级连接器的界限），已经在《Power Automate 的许可 ── Microsoft 365 免费到什么程度，什么时候需要高级版》中整理过。

8. 该选哪条路 ── 判断表

对于传真订单的应对，AI Builder 读取并不是唯一的答案。按件数、客户数量、单据的定型程度来划线，大致可以整理成下表。

判断上的直觉，最快的方法是数一数「同一版式的单据每月会送来多少张」。如果有几家客户这个数字很大，读取就会奏效。如果每种版式的张数少、客户数量却多，读取模型的维护就不划算，Web 迁移、EDI，或者干脆继续手动录入，反而更合理。

还有一点不能忘记，那就是确认工序的定位。读取自动化带来的效果，不是「转录归零」，而是「转录变成确认」。在效果测量时，请用同一把尺子，去比较导入前的录入时间与导入后的确认・修正时间。把待确认率（低于阈值、转给人工的比例）与自动放行后的误读件数一并追踪，可以为阈值调整和集合追加提供判断依据。

9. 总结

以传真送达的订单实现自动化，可以作为与「废除传真」不同的另一条路线来设计。整理一下，就是这样：

首先，通过一体机的转发功能或云传真服务，把接收到的传真 PDF 化，汇集到 SharePoint。停留在纸质阶段，什么都无法开始。接下来，把 AI Builder 的文档处理自定义模型，限定在件数排名靠前的客户的定型订单上进行训练。每个集合至少 5 份，传真质量的样本要多备一些，训练时使用实际接收到的传真。然后，用置信度分数区分自动与待确认，插入人工确认之后，再流向台账和核心系统。不追求全自动，反而能让导入更快、运行更稳定。

在费用方面，必须确认消费型积分的估算，以及从 AI Builder 积分向 Copilot 积分过渡的时间表。而且，读取终归只是「与无法废除的传真共处」的手段。能配合的客户就迁移到 Web 订单或 CSV 导入，剩下的传真则用读取来减轻负担。把这两条路线组合起来，手动录入的总量才会降到最低。

从传真订单的 PDF 化、读取流程的设计，到确认步骤与核心系统对接的打磨，以及与 Web 迁移的组合方式，如果您想一边验证自家单据能做到什么程度，一边推进这项工作，欢迎从下方的咨询领域与我们联系。

相关文章

• 把传真订单迁移到 Web ── 双轨运行期的设计与分阶段迁移实务
• 用 Power Automate 自动处理邮件收到的订单・发票 PDF ── 保存、分类、通知与读取的设计
• 什么是 EDI？如何让企业间的订购业务更轻松 ── 从传真、邮件、手动录入迈向数据对接
• 用 Power Automate for desktop 实现核心系统转录自动化 ── 将 Excel、纸质单据的手动录入替换为 UI 自动化
• 省力化投资补助金能否实现传真订单的网络化？── 使用一般型的订购系统投资思路

相关咨询领域

合同会社小村软件（合同会社小村ソフト）可以为您提供从传真・邮件送达单据的读取自动化设计，到确认流程的搭建，再到与现有销售管理系统、核心系统对接的全方位咨询。

• 技术咨询・设计评审
• Windows 应用开发
• 联系我们

参考链接

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

AI Builder 能读取日语的传真订单吗？

有充分的可能性可以读取。AI Builder 的文档处理自定义模型，无论是固定模板文档还是通用文档这两种学习类型，都支持日语，FAQ 中也明确写明支持提取手写文字。不过传真的分辨率较低，容易出现字迹模糊、字符粘连和倾斜，实际能读到什么程度取决于单据本身和线路质量。在做导入决策之前，强烈建议以实际接收到的传真 PDF 为样本训练模型，先确认在自家单据上的精度。

训练模型需要多少份样本单据？

每个「集合」（汇总同一版式单据的分组）至少需要 5 份样本文档。每个集合最多可登记 20 份，高质量文档通常 5 份就够用，而像传真这样低质量的扫描件，则建议使用 15～20 份。如果不同客户的订单版式不同，需要按版式分别建立集合（每个模型最多 200 个集合），从件数最多的客户的定型订单开始入手是比较现实的做法。

读取出来的结果可以直接登记到核心系统吗？

不建议无人值守地直接流转。AI Builder 的提取结果会为每个字段附带 0～1 的置信度分数，因此必须设置分支：分数高的自动记录到订单台账，分数低的则通知负责人，让其与原始传真图像核对后再确认修正。只把已确认的数据交给核心系统录入（CSV 导入或通过 Power Automate for desktop 转录）这样的结构，可以防止读取错误直接演变成发货错误的事故。

使用 AI Builder 需要什么样的费用？

AI Builder 的操作每次执行都会消耗消费型的积分。文档处理按读取的页数消耗，自定义模型的消耗速率比预构建模型更高。以往由 AI Builder 积分（容量附加组件或 Power Automate Premium 附带的 5,000 积分）来支撑，但 2025 年 10 月宣布了 AI Builder 积分的分阶段终止，正在向 Copilot 积分过渡。Premium 附带的种子积分将于 2026 年 11 月 1 日终止，新引入时请务必确认最新的许可证体系。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。