开元体育从“功能实现”到“智能跃迁”--低代码平台的AI赋能之路

　　开元体育从“功能实现”到“智能跃迁”--低代码平台的AI赋能之路关于#普元 ● #AI产品家：在探索AI创新的征程中，产品与AI研发实践是推动技术落地的关键环节。本文是“普元产品+AI研发实践系列”的一篇文章，将带您了解我们在这一领域的独特视角与实践经验。

　　近年来，OpenAI的ChatGPT开启了大模型AIGC的广泛应用浪潮。2024年底至2025年初，DeepSeek V3和R1的惊艳亮相，如同两颗重磅炸弹，在AI领域引发了巨大震动，让人工智能这一概念真正走进了大众视野，成为全民热议的焦点。

　　与此同时，“低代码”一直是IT领域备受关注的热门话题之一。作为企业应用开发的重要技术手段，低代码技术也在不断演进。随着AI和低代码平台在企业中的逐步深入应用，开发平台从“功能实现”迈向“智能跃迁”的升级，已成为各大企业和厂商积极探索的重要方向。

　　作为低代码平台的提供商，普元一直在低代码平台的AI赋能之路上不断探索，致力于为开发者和最终用户带来更智能、更高效、更便捷的体验。本文将围绕低代码与AI结合的场景和思路展开探讨，为您呈现这一领域的前沿思考与实践路径。

　　Agent智能体开发平台，专为需求分散、个性化强且总量庞大的长尾场景而生。它借助AI大模型，能快速构建智能体，通过自然语言交互、智能推荐和实时数据分析，灵活应对动态场景。

　　然而，对于传统企业级应用（如ERP、CRM、MES等），这类复杂业务场景并非Agent智能体平台的强项。传统低代码平台在企业级应用建设和系统稳定性方面更具优势，其交互方式也不易被对话式交互取代。

　　因此，低代码平台在复杂业务支撑和稳定性方面不可替代，而AI智能体平台则在灵活性和智能化开发上更具优势。并且，在低代码平台中，可以融合大模型基础能力和RAG / Function Calling / AI Workflow 等智能体构建技术对业务智能化场景进一步赋能。两者的结合，将推动企业级应用开发进入“低代码+AI”的双驱动时代，具备这种特征的低代码平台，也会逐渐晋升为具备传统企业级应用开发能力的智能体，助力企业在数字化转型中实现高效与稳定的平衡。

　　低代码平台用于数字化应用建设，支撑应用软件的全生命周期，包括开发交付、运行监控、运维和运营等环节。这些环节的核心用户包括开发人员、业务人员、运维人员和运营人员。因此，低代码平台的目标是为这些用户提供智能化的辅助工具。

　　我们需要把AI大模型LLM当作一个“人”来看待，比如，一个知识丰富的实习生。那么我们可以把一些技能教给TA，由TA来帮我们完成一些具体的工作任务。

　　在应用建设的不同阶段，这个“实习生”可为不同角色提供智能化支持：为开发人员提供低代码智能开发助手，为业务人员提供智能业务导航和业务助理，为运维人员提供智能运维支持，为运营人员提供智能运营分析助手……

　　在IT领域，AIGC（生成式人工智能）应用最成功的当属智能编码助手。无论是国内还是国外，各种开发工具和Copilot插件都为程序员带来了巨大的效率提升。

　　与传统的纯编码开发不同开元体育·(中国)官方网站，低代码平台采用的是拖拽配置的可视化开发模式，更加直观高效。不过，不同厂商的低代码平台都有自己独特的DSL语言和模型结构设计。这也意味着，为低代码平台打造智能开发助手，虽然和传统编码助手有相似之处，但在具体实现上却有独特的要求。

　　上图展示了编码助手的工作原理。通常，AI编码助手的背后是一个专门为编程预训练的代码生成模型，比如GPT-4/Codex、CodeLlama、Anthropic-Claude、Qwen-coder、Deepseek-Coder等（仅列举部分，排名不分先后）。这些模型基于海量代码数据进行预训练，具备强大的代码生成能力。

　　在实际使用中，编码助手会读取当前项目中的代码、配置文件和依赖库等信息作为知识背景。它还会结合当前打开的文件、正在编辑的代码内容以及光标位置前后的代码片段，生成一个“提示词”。将这个提示词交给大模型后，模型会生成相应的代码片段，供程序员选择是否使用。

　　低代码产品的DSL语言和配置通常由产品提供商自行设计，缺乏统一标准。因此，在LLM预训练时，这类知识很难被涵盖。那么，是否需要自行训练私有模型呢？这是否会带来较高的成本？

　　AI生成或推荐合适的模型字段，这里可以直接应用大模型现有的能力给出结果。也可以结合企业已有的数据模型资产结合RAG技术来进行推荐。这一步大模型完全胜任。

　　依据确定的模型字段，生成一个私有的DSL数据结构或JSON数据结构，在这里通过提示词的明确格式要求，给出样例的情况下，绝大多数大语言模型是可以完全胜任的。

　　需要大模型解析前面生成的数据结构，再根据自己已有的知识推荐不同字段使用什么表单组件，枚举类字段同时给出字典码表推荐。这一步同样依赖提示词的优化，绝大多数大语言模型是可以完全胜任的。提示词和结果示例如下：

　　基础LLM能够胜任部分低代码开发辅助场景，比如根据用户需求生成低代码模型、DSL配置，以及进行国际化文本提取和翻译等。

　　对于低代码模型生成和配置助手，基础LLM已足够，无需代码生成专用LLM或推理型LLM。以DeepSeek为例，推荐使用DeepSeek-V3，而非DeepSeek-R1或DeepSeek-Coder。此外，LLM模型微调的必要性也不大。

　　代码生成场景则更适合使用专业的代码生成LLM，例如低代码平台中的脚本开发或代码编辑场景，其原理与专业编码助手类似。

　　前面提到，我们可以把AI大模型看作一个知识扎实但缺乏实践经验的实习生。虽然理论基础过硬，但在复杂场景下，比如一键生成大型企业级应用，AI大模型还无法完全胜任。企业级应用软件的交付需要严格的质量评估，而AI生成的代码，目前程序员的采纳率仅在30%到60%之间。AI自动生成的软件大多只能作为演示程序，上线前仍需大量修改和验证。而程序员往往不喜欢修改别人的代码，这增加了实际应用的难度。

　　因此，工程化方法仍然是主流。我们需要将智能化场景合理拆分，分阶段推进，并在关键步骤中留给开发者确认和调整的空间。只要每个阶段都能产出高质量的结果，最终的整体效果就能满足预期。在这个过程中，AI大模型可以为程序员带来一个个小惊喜，逐步赢得开发者的认可。

　　在探索智能化辅助场景时，我们首先要明确目标场景的预期效果，并提前规划一套科学的评估方法。在实现过程中，要注重细节优化，并持续进行效果评估。甚至可以借助大模型实现自动化评估，快速发现问题并改进。这听起来是不是有点像我们熟悉的软件工程实践？

　　当然，功能上线后，收集用户的真实反馈数据至关重要开元体育·(中国)官方网站。基于这些反馈，我们进一步优化调整，形成完整的闭环。

　　传统应用软件对准确性要求极高，开发过程中对场景实现的可控性至关重要。AI Workflow技术正是将成熟的工作流技术与AI大模型的交互能力相结合，从而显著提升智能助手在任务处理过程中的控制能力。

　　正如前面提到的，推理大模型（Reasoning Model）更适合处理模糊发散型任务，其原理是通过大模型自主推理和任务规划来形成最终结果。然而，在软件开发中，我们更多面对的是具体明确的需求，开发者需要将任务拆解并逐一实现。AI Workflow可以将这一过程有序编排，将AI智能融入其中，确保最终结果既准确又可控。开发者会发现，这样的智能助手更加可靠。

　　在数据模型生成场景中，AI Workflow可以优化场景步骤，比如结合数据资产推荐、字段与数据标准的结合等，让整个场景更加完善。

　　在低代码页面的国际化翻译场景中，AI Workflow可以改进翻译过程，模拟专业翻译团队的工作模式，通过不同步骤的分工协作，如翻译、校对、按要求改进等，使最终翻译效果接近专业人员水平。

　　总之，AI Workflow是为传统应用软件的业务场景智能化赋能的重要手段。未来，我们还会深入探讨它的更多可能性。

　　2025年，AI技术正迎来应用大爆发的元年，通过AI与传统低代码平台的互补、AI大模型的“拟人化”协同以及AI Workflow技术的赋能，企业级应用开发正迈向一个更加智能、高效的时代。篇幅所限，本文先从如何做好低代码智能开发助手谈起，对于应用软件生命周期阶段仍有很多更有价值的场景值得探讨。在这个AI飞速发展的时代，让我们一起探索开元体育·(中国)官方网站、交流、分享，并期待AI为我们带来的每一个惊喜时刻（Aha moment）。

　　普元低代码产品经理，十余年产品研发与架构设计经验，目前负责普元低代码开发平台产品设计以及发展规划。参与过国家电网、浦发银行、兴业银行等用户大型平台项目建设与实施。