今天准备跟大家聊一下随着AI大模型和MCP协议生态的发展，对传统的低代码产品和RPA机器人产品所带来的一些影响。
因为在一年多前我其实就聊过这个话题，但是最近一年的时间AI大模型、AI编程、AI智能体，包括最近的MCP协议生态的发展太快了，导致原来我们对这两个产品的影响分析会出现一些变化。
1. 低代码平台影响分析
首先我们先讲一下低代码，大家都知道其实低代码平台的产品，它的本质仍然是辅助我们编程，仍然是可能会生成源代码或者是生成低代码产品模板引擎能够解析的元数据。
图片
但是低代码平台产品它实际做了两个重要的事情。
第一个事情它就是把我们日常开发编程常用的一些开发规范开发规约，包括页面规范，异常日志处理规范，公共组件使用规范等全部做标准化和统一。同时对底层的类似消息，缓存，安全技术组件，公共的系统管理和流程引擎，多语言支持，多组织支持，多数据库支持等进行提前预置。这些往往都是我们实际大量软件开发工程实践的经验模式抽象和积累。
第二个点就是低代码平台产品，它不能够完全自然语言进行交互，平台希望你用更结构化的方式把你的需求告诉它。所以说由于你告诉它的内容偏结构化，所以说低代码平台在实现这个功能的时候，它往往实现了更加的精确和准确。
图片
而上面两个点刚好就是我们现在的AI辅助编程工具，类似于Cursor或通义灵码这类工具最欠缺的地方。包括最近我在使用Cursor工具的过程中也逐渐的发现了这个问题。
即虽然说类似Cursor工具也支撑你提前进行Rules规则设置并将其提前模版化。但是实际上你要把我原来大量工程项目实践，开发形成的通用规约，界面的展现方式风格，包括通用的一些日志异常安全处理规则全部告诉Cursor，你还是需要花大量的时间去整理，去不断的和AI工具交互和调整。
其次，由于和AI辅助编程工具交互的时候更多的使用非结构化的自然语言，导致对提示词的写法并没有严格要求。那么如果提示语写的太随意，往往生成出来的代码问题就会比较多，你需要不断的和Cursor交互去修正这些问题。
所以一对比就会发现，AI辅助编程工具虽然有强大的代码生成能力，但是却没有你原来做项目大量的私有化工程经验实践的积累或内置。同时由于提示语的随意性，导致这个AI辅助很难上升到组织级工程实践。
图片
在AI大模型出来后，很多低代码厂商也在积极应对，包括提出了AI+低代码的概念。但是我们也看到一种结合的情况如下：
即低代码平台讲大模型内嵌作为自己的底座，让AI辅助来生成低代码平台特有的元数据，模型文件，配置模版等。这些东西可能原来我需要借助低代码平台的元数据管理功能，界面设计功能来花费大量时间录入的地方，现在可以通过自然语言全部帮我生成各种配置元数据。
但是我认为这种方式除了简单的提升低代码平台的配置速度外，并没有其它大的用处，这种AI+低代码平台的结合没有太大的意义，而且本身还是生成的低代码平台厂商特有的元数据和模版文件，不具备任何通用性。随着大模型和AI辅助编程工具的发展，这种强行结合会逐步被淘汰。
而更好的一种方式反而应该是将你多年做低代码开发实践形成的这种隐性的经验或者是规约把它模板化，把它作为你用AI辅助编程工具的关键的输入，通过这种方式去进一步调优AI辅助编程工具，那么就会极具相当的竞争力。
简单总结就是核心是AI编程工具，是以AI编程工具为主体的基础上融入我们原有的软件工程私有经验实践，并将这些内容模版化形成特有领域知识模块融入到AI编程工具里面去。
2. AI大模型对RPA机器人产品影响
第二个再来讲一下AI和RPA机器人的关系，大家都知道RPA机器人它实际上更多的就是模拟人去做相关的操作，不管是操作本地的资源文件，还是说通过浏览器到网上去做相关的案件操作，或者是爬取网页。
我原来其实对于AI大模型对RPA的影响我没有说的太透，但是最近特别是随着 MCP模型上下文协议出现，包括AI通用智能体的出现，我发现对RPA这么一个产品会造成相当大的一个影响。
举个简单的例子，我可能有一个简单的需求，就是需要去爬取最近一周的热点事件或者是新闻，然后在本地形成一个word文档。
这个事情我原来通过RPA机器人可以快速的实现，当然你也可以开发一个AI智能体做简单的编排来实现。但是随着MCP协议和大量MCP Server能力提供生态的完善，你连AI智能体都不用开发了，整个事情AI大模型完完全全可以帮助你全部完成掉。
因为AI大模型已经具备了相应的访问你本地资源的能力，类似数据库，文件系统，也具备了通过浏览器的代理去访问网页爬取资源的能力。同时AI深度思考模型还可以很好的做好任务的规划，分解，大模型自己就能够搞清楚哪些需要借助大模型通用能力，哪些需要调用MCP Server提供的API服务能力，然后最终再将其组合在一起完成特定目标和任务。也就是大模型本身也完全具备传统RPA才有的流程或任务的编排能力，而且更加智能化。
在我前面讲MCP协议也谈到，有了MCP协议后，等于统一构建了一个标准统一的API能力层，更加方便大模型按某种标准统一的接口方式来访问外部资源和工具。任何资源的访问都涉及到客户段和服务器端，大家都按统一的标准进行开发，无须再进行额外的开发适配工作。对于可以复用的API能力，只要开发好相应的MCP Server接入即可，后续只要写MCP Client端直接调用即可。
特别是随着MCP生态不断发展，以后连特有AI智能体开发都不需要，就是一个通用AI智能体搞定所有问题。
所以再回来分析，短期来看RPA还有哪些优势？
其一是RPA可能会做相当多跨系统，跨人机多次交互的地方。
第二个点就是RPA模拟人的时候，他可能还会去做相应的一些数据操作数据录入的工作。比如说我需要访问本地的文件，拿到一个Excel以后逐条的登录到税务网站去做相关的税务报税处理。税务报税界面它可能是一个结构化的界面，它需要去做相关的动作，对于这种输入的操作，它对结构化的要求相当的严格。这一类东西短期你要通过智能的AI代理全部完成，具备一定的难度，这一些可能是短期AI大模型没办法替代的。
但是回过头来讲RPA和AI大模型它之间究竟是什么样一个关系呢？两者究竟是相互竞争还是最终融合？
图片
这里一个关键就是谁为主体，谁来编排谁的问题。
第一种情况就是主体还是RPA产品，但是我RPA再去做流程任务编排的时候，我会把AI大模型的能力作为我的一个编排节点，比如说爬取网页还是RPA来做完的，但是扒取完的网页的内容去做内容总结，我可能调了AI大模型的能力，这是第一种方式。
第二种方式就是我再去做通用的AI智能体里面，虽然说有各种丰富的MCP Server提供通用化的API能力给我使用，那么有一些工作可能仍然是类似于需要模拟一些人工处理才能形成的能力。那么对于RPA机器人我能不能也作为一个MCP Server的能力节点接入到AI里面去？这个也是我们可以考虑的一个关键思路。
上面两种思路大家一定要注意，随着通用AI智能体，随着逐渐丰富的MCP Server能力的提供，第一种方式将会越来越会被替代掉。而更多的融合我的理解仍然是以AI大模型为主，RPA仅仅是能力提供组件进行接入。
所以说基于我刚才的一个简单的分析，大家可以看到随着AI大模型和MCP 生态的发展，包括通用AI智能体的发展，是对于传统的低代码开发和RPA机器人产品都会造成很大的影响。但是这个影响又不是说简单的替代原有的两个产品，更多的仍然要去考虑这两个传统的产品怎么样去跟AI大模型做更好的一些深度融合和集成。
好了，今天的简单分享就到这里，希望对大家有所启发。
