一张采购申请进入系统后，工作流可以把它送到对应审批人。若企业的规则允许跨系统传递，RPA 或 API 可在申请获批后搬运已确认字段；但这不等于供应商已确定，更不等于采购订单可以直接发出。附件名称不统一、申请理由写在邮件里，或申请金额与报价不一致时，还需要先整理证据和处理例外。AI 适合辅助理解这些非结构化信息，不能替采购人员作出业务决定。
三者不是互相替代的产品名称。更实用的分法是：AI 负责理解与判断辅助，工作流负责状态和路径，RPA 或 API 负责确定动作。流程最终是否可靠，取决于这三层能否把异常交给正确的人，而不是某一层是否被包装成“全自动”。
先看一条流程为什么会卡住
以一条需要询价的采购申请为例，示意路径是：提出需求、按企业规则审批、采购核实规格并询比价、确定供应商与交易条件、再按订单授权流程生成或发出采购订单，最后回写状态。不同企业的审批和寻源顺序可能不同，不能把申请获批等同于下单获批。真正让流程停住的，往往是下面这些情况：
- 申请人把关键规格写在附件或邮件正文里；
- 同一物料在两个文件中使用了不同名称；
- 申请金额与报价金额不一致，或已签合同的条款与拟下单内容冲突；
- 审批通过了，但缺少生成采购订单所需的字段；
- 系统页面发生变化，原有自动录入步骤无法继续。
这些问题不属于同一种故障。有的是信息理解问题，有的是流程规则问题，有的是执行工具问题。若不先分层，企业很容易把所有异常都归因于“AI 不够智能”或“RPA 不稳定”。
AI、工作流与 RPA 分别负责哪一层
AI 流程自动化：处理理解、归类与判断辅助
AI 适合面对邮件、附件、自然语言说明和不完全统一的字段。它可以提取信息、识别缺项、归类请求、对照规则并形成待确认结论。例如，它可以把申请单、报价文件和合同中的金额放到同一张核对表中，并指出冲突位置。
但 AI 不应在证据不足时自行补齐事实。涉及供应商选择、预算例外、合同责任或付款承诺的决定，仍需要责任人确认。
工作流：管理状态、路径、审批与等待
工作流回答的是“任务现在处于什么状态、下一步交给谁、满足什么条件才能继续”。它可以规定金额超过某个范围时增加审批节点，也可以等待材料补齐后再进入采购复核。
工作流擅长把已明确的规则变成可追踪路径。若规则本身含糊，或者输入内容无法直接判断，工作流需要 AI 或人工先把情况整理清楚。
RPA 与 API：执行已经确定的动作
RPA 可以模拟人在界面上的点击、复制和录入，适合页面稳定、步骤固定的操作。API 则在系统提供正式接口时直接传递数据，通常比模拟界面更稳定，但仍受字段、权限和接口规则约束。
无论使用 RPA 还是 API，执行层都不应该自行解释业务例外。上游没有确认字段和动作时，执行层应停止并返回错误，而不是猜测后继续。
三层如何组成一条可控的自动化链
一条可控的任务链可以这样运行：
- AI 从申请单、邮件和附件中提取字段，标记缺项与冲突；
- 责任人确认需要人工判断的事项；
- 工作流根据金额、部门和风险规则选择审批路径；
- 申请审批、供应商及订单所需确认都完成后，RPA 或 API 才执行相应的已授权系统操作；
- 执行失败或返回异常时，工作流将任务交回指定责任人。
这里最重要的不是步骤数量，而是每一层只承担它有证据、有权限完成的工作。关于具体采购流程如何形成首个闭环，可以参考从询价到比价的采购流程自动化实践。
三种常见错配，都会让自动化失控
用 RPA 处理需要理解的输入
当邮件格式、附件版本和字段名称经常变化时，继续堆界面脚本会产生大量脆弱分支。更稳妥的做法是先把识别和异常整理独立出来，再把已确认字段交给执行层。
用 AI 绕过明确的流程规则
已经有审批权限、金额阈值和责任人的流程，不应让模型自由决定下一步。AI 可以解释材料和提示风险，路径控制仍应由明确规则负责。
把工作流误当成业务判断
工作流能判断“字段是否为空”，不代表它理解缺失字段对合同或交期的真实影响。涉及业务语义时，需要可靠的数据来源、AI 辅助或责任人确认。
改造现有流程时，先做一张三层拆解表
选择一条高频流程，把每一步分别标记为“判断、编排、执行”，再补充四项信息：输入来源、所需权限、失败表现和人工接管人。
如果一个步骤同时写了“理解附件、决定是否放行、登录系统录入”，说明任务还没有拆清。先把它分成可验证的小步骤，再选择 AI、工作流、RPA 或 API。还没有确定首个自动化任务时，可以先用制造业 AI 首任务评分表比较任务价值、可行性与风险，避免把工具名称当成完整交付。
