输出：确定与开放
规则引擎对同一输入给同一结果，便于审计与复现；生成式模型输出开放，能处理未枚举的表达，但需要复核。二者不是替代关系，而是按任务的确定性程度分工。
维护：改规则与改知识
规则系统靠改代码与配置，变更需测试；生成式系统靠改知识、提示词与检索，变更快但影响面难预判。因此后者更需要版本管理与回归评测，否则一次调整会牵连其他场景。
输入：结构化与非结构化
RPA 擅长在固定界面上搬运结构化数据，界面或格式一变就失效；生成式模型能读非结构化文档，但抽取结果要校验字段与数值，否则错误会直接进入下游系统。
验收：用例与评测集
规则系统用测试用例覆盖分支即可；生成式系统要评测集加人工抽检，还要看拒答是否合理。把两者混用一套验收模板，结论一定失真，也无法比较供应商。
组合：模型在前规则在后
常见做法是模型做理解与草拟，规则做校验与拦截，例如金额区间、日期格式、必填条款。规则兜底能显著降低错误外发概率，也让审计有据可查。
适用与不适用
适合谁
- 正在做技术选型的架构师
- 已有 RPA 或规则系统需要升级的团队
- 需要向业务解释为何不能全自动的负责人
不适合谁
- 输入输出完全固定、无需语言理解的流程
- 不接受人工复核的对外场景
典型场景
某企业的发票录入原本用 RPA 按固定模板搬运，供应商换格式后频繁失败。团队改为模型识别字段、规则校验税号与金额格式、人工确认异常，失败率下降且异常有了明确处理路径。
可执行步骤
- 列出任务输入形态与输出确定性要求
- 标出哪些环节必须可审计、可复现
- 用模型处理理解与草拟，规则做校验
- 为混合流程设计异常与人工确认路径
- 两部分分别按用例与评测集验收
常见坑
- 用生成式模型替换所有规则判断，审计时无法解释结果来源。
- 只升级模型不建校验规则，格式错误直接进入下游系统。
- 评测沿用功能测试模板，只测正常路径，异常输入全部漏掉。
- 忽略 RPA 与模型的接口稳定性，界面小改就导致整条链路中断。
自检与验收清单
- 是否标出必须可复现的环节
- 是否设置规则校验兜底
- 异常是否有明确处理路径
- 两部分是否分别验收
- 界面或格式变更是否有监控
常见问题
有了生成式 AI 还需要 RPA 吗？
需要。固定界面的重复操作仍由 RPA 更稳，生成式模型适合处理界面之外的非结构化信息，两者组合比单独使用更可靠。
怎么保证结果可审计？
把模型输出与依据一起留存，关键字段用规则复核，并记录人工确认人与时间。只存最终结果，事后无法还原判断过程。
能把规则全部交给模型吗？
不建议。涉及金额、日期、资质编号等强格式内容，规则校验成本低且可靠，交给模型反而增加不确定性。
混合流程该怎么验收？
分段验收：规则部分用用例覆盖分支，模型部分用真实样本跑评测集，再看两者衔接处的异常是否都有明确处理人。只报一个整体准确率，无法说明错误出在哪一段，也无法判断问题是否可复现，上线后很难定位责任。