这三样技术再不分开看AI产品经理的选型会越做越糊涂先说个我前段时间评审会上真实发生的场景某供应链项目要做采购发票的自动化处理业务方提了一堆需求老板问用RPA还是低代码还是大模型现场三个名词来回抛最后谁也没说清楚为什么选这个、不选那个。这其实不是个别现象AI产品经理这两年越来越频繁地被推到技术选型的决策位上但RPA、低代码、大模型这三樣东西在很多人脑子里的边界是模糊的——一说到自动处理就全往大模型上靠一说到搭个页面就只知道低代码一说到机器人就默认RPA。这篇指南就专门解决这个问题。我按自己实际做项目的思路把三者的本质拆开、把选型判断框架列出来再给几组高频场景的组合配方最后聊聊产品经理在这类选型里最容易踩的坑。写之前先说明白这是一篇偏决策视角的选型指南不是技术源码分析——适合AI产品经理、数字化转型负责人、以及需要给业务方拍板技术路线的同学收藏着用后面做方案评审时可以直接拿出来对照。1. 三者到底是干什么的先把边界画清楚选型才有的聊选型为什么会乱根源在于大家把RPA、低代码、大模型放在了一条线上比较好像它们是功能重叠的同类工具。其实它们的解决问题方式完全不同看问题的维度也不一样。我给三者的定位是RPA管手低代码管骨架大模型管脑子。1.1 RPA的本质模仿人类操作电脑的数字员工RPA的核心逻辑不是编程而是模拟人在图形界面上的操作——打开某个业务系统、登录、找到某个页面、读取字段、录入数据、点击按钮、下载文件、再切到另一个系统粘贴。它走的是看见什么操作什么的路子依靠界面元素定位控件识别、图像识别、OCR辅助来驱动业务流程。我在某供应链项目里实际见过一个典型的RPA场景采购部门每天要把ERP里的到货单逐条录入到另外一套财务系统再做一次三单匹配。人工操作平均一单要6分钟上了一个RPA流程之后变成40秒准确率从97%提到99.5%。但要注意RPA解决的是流程确定、规则明确、重复劳动的问题。它不理解业务含义只执行动作。你让它处理一份没有固定格式的合同、判断条款是否合理它就傻眼了——因为它根本不是在理解文档它只是在搬运和填表。RPA最大的特点也是它最大的软肋依赖界面稳定性。只要业务系统改版、按钮位置变了、登录页加了验证码流程就断给你看。我见过某项目上线两周后因为目标系统发了一次前端版本升级整个自动化流程瘫痪了大半天。所以选RPA之前必须先确认你面对的系统有没有稳定的操作界面、有没有可用的API这两个条件至少要占一个。1.2 低代码的本质快速搭建业务应用的脚手架低代码要解决的是应用系统建设速度慢的问题。传统开发一个后台管理系统前后端联调、数据库设计、权限控制、测试上线没有几个月下不来。低代码平台把这些东西模板化、组件化、可视化拖拖拽拽就能搭出表单、列表、审批流、仪表盘、权限模型。很多平台还内置了数据库、用户体系、API网关连数据处理逻辑都可以通过配置完成。低代码最典型的应用场景是公司内部缺一个小工具——比如一个项目进度跟踪看板、一个销售周报收集表、一个工单派发系统。这类需求的特点是逻辑不复杂、用户量不大几十到几百人、迭代频繁用传统开发方式太慢太贵用低代码平台一两周就能出可用版本。它和大模型的区别很直接低代码能帮你把应用框架搭好但它不提供智能。你可以在低代码系统里做数据统计、做流程审批但它没法跟你对话、没法帮你写总结、没法理解用户随口说的一句话。低代码是骨架它把应用的形态撑起来但里面装的业务流程是固定的、规则是写死的。遇到那种需求还没想清楚的项目低代码也有风险——因为它把业务逻辑固化成了表单和流程改一次需求就是改一次模型频繁改起来并不轻松。1.3 大模型的本质具有生成与理解能力的智能内核大模型和前两者的差别是代际的。RPA和低代码都是确定逻辑的执行器和容器大模型则是用参数化方式压缩了海量知识的概率引擎它能理解自然语言、生成自然语言、抽取信息、分类归纳、总结推理。它会写一段周报、会从合同里提取关键条款、会根据对话上下文回答用户问题——这些都是规则写不出来的能力。但正因为它是概率模型它有两个天然的边界。第一是不确定性同一个问题问两次答案可能不一样面对需要精确计算、严格强校验的场景它不适合单独使用第二是幻觉它可能在信息不足时一本正经地编造内容。我用大模型做过一段合同摘要抽取正常条款它抽得又快又准但遇到那种末尾附加的特殊约定模型会把不存在的违约责任条款也脑补出来。这就是选型里最关键的一个分水岭你的业务到底容不容忍可能出错且错误不固定的结果。1.4 三者不是三选一而是三层架构想明白三者的本质之后正确的问题就不是用哪个而是哪个为主、哪个为辅、怎么组合。我自己的实践经验是一个完整的自动化智能化系统往往是三层结构底层RPA负责和外部系统打交道承担手脚的角色把数据取回来、把结果写回去中间层低代码负责把业务流程编排成应用做数据存储、权限控制、人工审核节点保证整条链路是可见、可控、可改的最上层大模型负责真正需要理解力的部分比如文档理解、对话、分析、总结输出结果后再交给RPA去执行或者低代码去流转。这套组合我后面会在场景案例里展开说。现在先把结论放在这选型的本质是给需求里不同的环节找对应能力最匹配的技术层而不是找一个大而全的万能工具。2. 选型判断框架五个维度决定需求落在哪个技术层理解了边界之后下一步就是建立一个可复用的判断框架。我自己在项目里用的是一套五维判断法每来一个需求就拿着五个问题过一遍基本能定调。判断维度核心问题偏向RPA偏向低代码偏向大模型流程确定性规则能否被完整写下来规则明确、步骤固定流程可建模、节点清晰规则无法穷举、需要语义判断交互形态用户和系统的交互方式系统对系统、界面操作人用浏览器/APP操作自然语言对话、文本生成交付物形态最终交付的是什么自动化执行流程可访问的业务应用智能问答/生成/抽取能力变更与维护业务和界面多久变一次界面稳定但业务易变需维护脚本流程变更需改模型模型需要Prompt调优和数据治理容错与合规出错代价有多大中需要人工复核兜底低规则内可完全确定高幻觉不可消除这五个维度不是并列的判断顺序很重要。我实际使用时的判断逻辑是这样的——先看第一维度流程确定性如果业务流程连最熟悉业务的人都说不清楚那就是规则无法穷举直接引导往大模型方向考虑如果规则能写得一清二楚再看最终要交付什么。要是交付物是一个自动执行的流程比如定时抓取数据、批量录入、跨系统搬运那RPA是主干要是交付物是一个别人要天天用的系统比如审批、看板、数据填报那低代码是主干要是交付物是一个智能交互能力比如客服问答、文档审核、内容生成大模型跑不掉。2.1 关键细节规则能不能写清楚是所有判断的起点我在多个项目里验证过一件事很多需求刚开始看起来都很适合大模型但聊深了发现90%的环节其实是有标准规则的。比如客服系统用户问我的订单到哪了规则是查物流接口返回状态这是确定性逻辑用户问帮我看看我为什么被扣了这笔钱很可能涉及账单、优惠券、活动规则叠加规则复杂但勉强可穷举只有用户问你觉得我应该选哪个方案这才真的需要生成式理解和推理。所以我会建议产品经理在选型第一轮先做一个动作和业务方做一次规则穷举工作坊把所有已知的判定条件列出来看能不能画成流程图。能画的就是RPA或低代码的范畴画不出来的才是大模型的菜。这个工作坊能帮你避免大量用大炮打蚊子式的选型错误。2.2 成本模型单价便宜的RPA三年总成本未必便宜第五个维度成本模型单独说一下因为它最容易让人误判。很多决策者第一眼看到的差异化因素就是价格RPA单个机器人一年几万块低代码平台按用户订阅大模型API按token计费看起来差别很大。但真正比较的应该是三年总拥有成本TCO包括采购/订阅费、实施和定制费、维护人力和培训费、规则变更时的调整成本、基础设施如果私有化部署还要算算力、出错带来的风险补偿成本。我见过一个典型误判某财务共享中心选了RPA来做单据录入采购成本不贵但后续每个新供应商的单据格式不同都得改脚本一改就是半天起三个业务系统升级一次所有流程重新测一遍一年花在维护上的人力超过当初采购价的数倍。反观另一个项目直接用低代码平台做了个数据录入应用让供应商自己填结构化表单彻底绕开了“识别非标准单据”的坑。选型不能只比较技术单价要把后续生命周期成本一起拉进表里。3. 高频场景选型组合六类真实需求直接对照参考判断框架是道具体场景是术。下面这几类场景是我在各类项目里反复遇到的高频需求每个都给了推荐的技术组合和理由你拿自己正在碰的需求对照一下大概率能找到对应项。3.1 跨系统数据搬运与批量录入RPA单干偶尔OR辅助典型例子ERP系统里的采购单需要人工搬运到财务系统、政务审核结果的批量回填、多平台店铺订单的汇总导出。这类需求的核心是系统间没有API或者有API但开放权限申请不下来而界面操作路径固定、规则简单。推荐方案是RPA单干。实施要点先梳理清楚源系统和目标系统的界面操作路径录制脚本然后对异常分支做兜底——比如页面加载超时、目标字段弹校验、数据重复提示这些都要提前埋重试和告警。OCR是否加取决于源系统是不是有非结构化图片比如扫描件里的单据编号如果全是文本框OCR完全是多余成本。这套方案上线最快、见效最直接但要在运维SLA里写清楚源系统每次发版后48小时内必须跑一次回归验证要不然断了没人知道。3.2 内部管理工具的快速搭建低代码主导别扯上大模型典型例子销售团队的周报收集与汇总、项目进度跟踪看板、内部工单流转、行政采购审批应用。这类需求的典型特征是有明确的使用群体内部员工、明确的流程节点填表→审批→归档、不需要对外暴露也没有复杂的智能判断。推荐方案就是低代码平台直接搭。有人会觉得现在不加上AI都不好意思立项但我建议这种需求克制一点。销售周报收集就是表单审批汇总统计你非要嵌入一个用大模型自动给每个销售的周报打分先不说Prompt怎么写才能评得公平光是销售为什么愿意被AI点评这个组织问题就够你吃一壶的。低代码在这里的价值是快速交付、灵活迭代——你花一周搭出来的版本用两周时间根据用户反馈改了三个迭代这种节奏只有低代码能给到。3.3 非结构化文档处理大模型负责理解RPA负责端到端执行典型例子每天收到几百份来自不同供应商的合同文本、扫描版发票、PDF对账单需要把核心字段抽出来进系统做比对、触发后续流程。这类需求单靠RPA做不了——RPA能做的是找到文件→打开文件→复制粘贴的机械动作它不认识合同里的违约责任和付款条件单靠大模型也做不了端到端——大模型能抽取但谁来触发任务、谁来把抽取结果写回系统、谁来处理失败任务这时候就是组合最典型的架构RPA负责编排任务定时扫描邮箱/共享目录下载文件按规则重命名归档大模型负责抽取调用OCR识别扫描件文字LLM按既定字段清单提取关键信息输出JSON低代码或简单后端服务负责结果流转抽取结果写入数据库匹配规则库做初步校验异常项推送给人工审核处理。我做过一个相对成功的合同要素抽取项目就是用这个组合跑的。项目上线后人工介入率从100%降到20%但要注意剩下的20%是必须留给人审的因为模型在长段落、多义表述上依然会出错靠规则兜不住。3.4 企业知识库问答大模型为核心低代码做编排界面典型例子企业内部政策问答机器人、设备运维知识库助手、培训资料智能检索。这类需求的核心是要让用户用自然语言问问题并且基于企业内部的文档作答——不是开放域闲聊要引用依据、要来源可溯。推荐架构是大模型RAG检索增强外面套一层低代码做的问答工作台。RAG的思路说起来很简单先把企业知识文档做向量化入库用户问题进来后先检索最相关的片段再把片段作为上下文丢给大模型生成回答。这样做的好处是大模型不需要重新学习企业内部资料更新知识库就是更新索引成本低、可控性强。难点在于知识库的切分粒度、检索召回质量、以及答案引用来源标注——这些要花大量时间调。产品经理在这里要把握一条底线凡是回答里标注仅供参考的场景大模型可以上凡是回答结果直接驱动业务动作比如决定是否放款、是否审批通过的场景必须有人工复核节点大模型只能做初筛建议。3.5 报表生成与推送三层各干一段最出团队效率感典型例子经营日报自动生成每天早上9点前把前一天的销售、库存、履约数据汇总成图文报告推送给管理层。这个场景特别适合给刚接触这套组合的业务团队当入门样板因为每个环节都清晰RPA或应用内的数据接口负责跨系统取数——从ERP、CRM、物流系统拉数据低代码负责数据汇聚和中间表存储——定好口径算出指标GMV、订单量、转化率、异常提醒大模型负责把指标数据转写成自然语言段落——昨日GMV环比上升12%主要受某区域促销带动但华东仓履约异常率有所上升需关注低代码再负责最后一步的发布——生成H5页面或接入IM机器人推送。这套链路跑通之后日常写周报的时间能压掉70%以上而且口径一旦锁死就不会再出现每个部门报的数对不上。唯一的提醒是大模型生成的文字结论要接入人工抽检机制不能默认无条件信任尤其涉及对外发布的内容。3.6 踩过才知道的禁忌别用大模型硬扛确定性规则流程最后给一个反向场景。某项目想做采购订单的自动审批原先的设想是订单进来大模型读一遍订单内容再结合供应商历史表现自动决定是否放行。这个方案我一听就觉得有问题——订单审批是典型的强规则场景金额超预算就驳回、新供应商必须先审资质、历史有三次以上延迟交付就自动降级。这些都是可以用规则引擎明确写出来的判定条件为什么非要让大模型来做一旦模型判断逻辑漂移连出错的依据都没有。我给这个项目的建议是订单信息用OCR或API结构化判断逻辑全部用确定性规则写大模型最多用来做一件事——给审批人生成一句话的决策摘要辅助人做判断。规则给确定性大模型给解释性分工各得其所。这算是我在做选型组合时一条很重要的经验让能力归位别为了AI而AI。4. 选型之后的落地关键动作一周PoC、供应商清单与退出机制技术选型最容易犯的错是把它当成一次性决策——选完了写进PPT了就以为结束了。实际上选型方案只是一个假设需要通过小范围验证来证明它成立。我建议每个项目在正式立项之前留出一到两周做PoC概念验证并且按照标准动作来检查候选技术方案。4.1 一周PoC该验证什么不能只演示跑通了PoC的目的不是看供应商演示Demo而是回答三个问题第一方案在你的真实数据和真实环境里能不能跑通第二异常情况出现时是谁、用什么方式兜底第三这个方案维护起来要什么级别的人力和成本。我一般把PoC压成五天头两天拿真实数据跑核心链路比如100份真实单据过一遍模型抽取第三、四天人为构造异常场景坏数据、重复数据、超大文件、字段缺失第五天让一个没有参与前期配置的同学尝试自己调整规则或Prompt看释放维护门槛高不高。很多项目在PoC第三天就会暴露问题——比如某个RPA流程在锁屏状态下跑不了、某个低代码平台和公司现有的统一登录系统对接不上、某个大模型在特定格式合同上漏抽率超过30%。这些问题在PPT阶段永远看不到但在第五天你会对自己的选型方案有一个非常清醒的判断。4.2 供应商方案能力评估清单四个必看项不管选RPA、低代码还是大模型方案我都建议从四个角度去评估供应商而不是被功能清单牵着走集成能力是否能和你现有的账号体系、权限体系、数据源无缝对接。很多平台演示时很漂亮但接企业微信/钉钉登录就卡壳这个必须在PoC前就确认。可维护性是否有完善的开发/配置界面、日志、监控告警。这意味着以后业务变了是自己人改还是天天找供应商排队。审计日志尤其重要自动化系统一旦在合规审查时拿不出操作记录麻烦很大。私有化/混合部署能力数据要不要出域、出域是否符合合规要求这是硬底线。大模型方案尤其要弄清楚敏感数据是否会被用于模型训练是否支持私有化部署或脱敏后再调用云端API。生态完整度RPA看有没有组件市场、低代码看有没有行业模板、大模型看有没有配套的向量数据库和标注工具。生态完整度直接决定你后续扩展功能的成本。4.3 提前写好退出机制和技术方案一起过会我强烈建议在立项文档里专门留一页写失败条件包括PoC阶段核心指标不达标、上线后X个月内人工复核率超过预设阈值、年度总维护成本超出预算比例上限、关键供应商出现服务中断或者重大安全事件。这些条件一旦触发方案就该启动降级或切换流程。很多团队不喜欢写这种东西觉得晦气。但据我的项目经验写了退出机制的项目往往更敢于尝试并更快拿到结果不写的项目反而会在一个不太合适的方案上反复打补丁越陷越深。退出机制不是给项目判死刑而是给决策者一个心理安全垫——我们试过指标不行所以换路比我们也不知道行不行但PPT已经报上去了要体面得多。5. 产品经理最容易踩的四个坑花钱买来的项目教训最后这部分是我最想讲的——前面都是方法论这里全是真金白银买来的经验教训。产品经理在这个领域踩坑往往不是技术理解不到位而是在决策机制、沟通口径和预期管理上出了问题。5.1 把流程自动化包装成AI项目导致预期管理全面失控有个项目原本只想解决财务对账自动化的问题一套RPA配上几条规则就能完成80%的工作。但汇报的时候团队用了打造财务智能大脑这类措辞结果老板和业务方对系统的预期直接变成了以后任何财务问题它都能回答异常数据它能自己分析和解释。上线后发现它只能做对账不能做预测业务方当场就觉得被欺骗了。我的建议是汇报时宁可说的保守把智能的边界讲清楚——它能自动执行X类流程能辅助做Y类判断遇到规则之外的Z类情况会转人工。预期这个东西一旦被拔高再要降下来代价非常大。把自动化说成智能化来立项短期好看长期爆炸。5.2 低估了权限申请和合规审批的时间消耗技术上两星期能跑通的PoC往往要等一个月的系统权限审批。某项目做RPA要对接核心业务系统的数据库只读账号安全团队要求先做半年的操作审计、限定操作时间段、配备录屏留痕一等就是两个季度。还有项目用了大模型API来处理合同数据法务直接要求数据脱敏、签署数据处理协议、限定模型供应商只能按请求处理不能留存数据——这一个合规流程走下来又是大把时间。产品经理在做项目排期时必须把权限申请、安全评审、法务合规这三项时间单独列出来不能默认技术验证通过可以上线。提前把相关团队拉进项目周会里让他们从第一天就知晓自动化方案要做什么、数据流向是什么永远是值得的投资。5.3 没有提前定义AI出错到多少要熔断的阈值大模型方案的容错率必须在立项时量化。你说准确率98%听起来很高但你们每天处理10000个请求2%就是200个错误请求如果每个错误请求都会触发下游一个人工处理甚至一次客诉那实际可接受阈值可能是99.9%。我在某文档抽取项目里就吃过这个亏上线前测下来字段抽取准确率99.2%觉得稳了结果上线后发现有个特定供应商的单据格式一直搞错出错率集中在该类单据上导致对应流程频繁卡住。后来补了一个分维度监控熔断机制——某个来源、某类格式、某个字段的准确率下降到阈值系统自动停用自动化转为人工处理。产品经理在做大模型方案时一定要和业务方一起定义清楚错误率指标拆到哪些细分维度达到什么数值就停线上自动流程停掉之后谁来兜底。这些细节写在方案里比上线后再开会救火强一百倍。5.4 只算机器人单价和API单价忽略隐性成本前面提过TCO了但正因为太多人忽视我再强调一遍。某RPA项目的隐性成本包括每次上游系统改版后的脚本修复和回归测试平均每次消耗2-3个人日、日常监控和异常处理值班每周至少一个人半天、以及流程优化的持续投入。三个隐性成本加起来往往超过采购本身。低代码平台的隐性成本在业务变了之后模型怎么改版本、平台本身升级时二次开发的兼容成本。大模型的隐性成本在Prompt调优、知识库更新、标注数据准备和每次效果回归测试——这些都要持续投入人力。产品经理一定要在方案通过前把第一年维护人力清单做出来并且在立项材料里写清楚第二年起每年预计的维护投入会落在哪个团队、多少人天避免上线后无人维护的情况。最后说点我的个人体会做这类选型做得多了我自己的习惯逐渐沉淀成一套三层过滤法每次遇到新需求都会走一遍第一层问业务流程的规则能不能穷举——能就往RPA或低代码走不能才考虑大模型。第二层问最终要交付的是执行流程、业务应用、还是智能能力——这就决定了三者的主从关系。第三层问谁来做异常兜底和日常维护——如果没人兜底不管技术多先进都一票否决。最后再分享一个小技巧我写选型方案时习惯在文档第一页放一张决策否决项清单把数据不出域、权限可审计、有监控告警、有维护责任人这几条列在最前面。只要有一条不满足这个方案就不值得往下细化。这样不但能帮自己快速过滤不合适的技术路线也能让评审会上的各位把注意力从哪个技术很酷拉回哪个方案真的能长期运作。这个习惯帮我挡掉了很多后期麻烦也算是一次次踩坑之后的自我修正吧。