今天準備跟大家聊一下隨著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大模型做更好的一些深度融合和集成。

好了，今天的簡單分享就到這里，希望對大家有所啟發。