企业官网建设流程全解析

这三样技术再不分开看，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是主干；要是交付物是一个"别人要天天用的系统"，比如审批、看板、数据填报，那低代码是主干；要是交付物是一个"智能交互能力"，比如客服问答、文档审核、内容生成，大模型跑不掉。

2.1 关键细节：规则能不能写清楚，是所有判断的起点

我在多个项目里验证过一件事：很多需求刚开始看起来都很适合大模型，但聊深了发现90%的环节其实是有标准规则的。比如客服系统，用户问"我的订单到哪了"，规则是查物流接口返回状态，这是确定性逻辑；用户问"帮我看看我为什么被扣了这笔钱"，很可能涉及账单、优惠券、活动规则叠加，规则复杂但勉强可穷举；只有用户问"你觉得我应该选哪个方案"，这才真的需要生成式理解和推理。

所以我会建议产品经理在选型第一轮先做一个动作：和业务方做一次"规则穷举工作坊"，把所有已知的判定条件列出来，看能不能画成流程图。能画的，就是RPA或低代码的范畴；画不出来的，才是大模型的菜。这个工作坊能帮你避免大量"用大炮打蚊子"式的选型错误。

2.2 成本模型：单价便宜的RPA，三年总成本未必便宜

第五个维度"成本模型"单独说一下，因为它最容易让人误判。很多决策者第一眼看到的差异化因素就是价格：RPA单个机器人一年几万块，低代码平台按用户订阅，大模型API按token计费，看起来差别很大。但真正比较的应该是三年总拥有成本（TCO），包括：采购/订阅费、实施和定制费、维护人力和培训费、规则变更时的调整成本、基础设施（如果私有化部署还要算算力）、出错带来的风险补偿成本。

我见过一个典型误判：某财务共享中心选了RPA来做单据录入，采购成本不贵，但后续每个新供应商的单据格式不同都得改脚本，一改就是半天起，三个业务系统升级一次，所有流程重新测一遍，一年花在"维护"上的人力超过当初采购价的数倍。反观另一个项目，直接用低代码平台做了个数据录入应用，让供应商自己填结构化表单，彻底绕开了“识别非标准单据”的坑。选型不能只比较技术单价，要把后续生命周期成本一起拉进表里。

3. 高频场景选型组合：六类真实需求直接对照参考

判断框架是"道"，具体场景是"术"。下面这几类场景是我在各类项目里反复遇到的高频需求，每个都给了推荐的技术组合和理由，你拿自己正在碰的需求对照一下，大概率能找到对应项。

3.1 跨系统数据搬运与批量录入：RPA单干，偶尔OＣR辅助

典型例子：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或低代码走；不能，才考虑大模型。第二层问最终要交付的是执行流程、业务应用、还是智能能力——这就决定了三者的主从关系。第三层问谁来做异常兜底和日常维护——如果没人兜底，不管技术多先进都一票否决。

最后再分享一个小技巧：我写选型方案时，习惯在文档第一页放一张"决策否决项"清单，把数据不出域、权限可审计、有监控告警、有维护责任人这几条列在最前面。只要有一条不满足，这个方案就不值得往下细化。这样不但能帮自己快速过滤不合适的技术路线，也能让评审会上的各位把注意力从"哪个技术很酷"拉回"哪个方案真的能长期运作"。这个习惯帮我挡掉了很多后期麻烦，也算是一次次踩坑之后的自我修正吧。