AI时代留给低代码时间不多了

鲁班大叔_007
178 阅读17分钟

低代码会消失吗？

他们说2021年是低代码元年，到处都是低代码融资消息。如今三年过去了低代码早就没有了往日荣光，现AI都能自己写代码了，低代码是不是时日无多了？我的结论是相反的，在AI加持下低代码将焕发新生。但是我们不能再继续采用传统的思路开发低代码平台，否则AI也救不了。

传统低代码的弊端

为什么程序员抵触低代码？ 有人说：“是因为低代码抢了程序员的工作，就像马车夫抵触汽车一样，但时代车轮滚滚向前... ”这种话极其愚蠢。照这么说IDE那不也淘汰了不少人的工作 ，程序员应该抵触它吗？好用的工具大家只会拥抱它，而低代码被抵触就是不好用，用它就是给自己添堵。 它本来就不是设计给程序员用的，而是让实施人员在客户现场就把业务给拖拽出来。现实是实施人员拖不出来，最后只能程序员来拖，原本复制粘贴能搞定的事，现在硬生生要拖个半天，换谁心理都会堵得慌！

为什么实施人员拖不出业务来？为什么程序员用低代码反而效率更低了？因为基于拖拽的低代码有一个矛盾：就是功能越强大配置项越灵活，它的使用难度就会越大。它的操作过于分散，需要频繁的打开各种窗口进行配置。功能强了不会用，功能弱了没人用这就是低代码的尴尬。

我是如何设计低代码的？

2024年7月我有幸参与了某国民级大厂的工作流编排项目，客户诉求是通过拖拽就能把后端的流程生成了，我问这个产品最终谁来用? 他说业务人员、产品经理、程序员都会用，但是前期先给程序员用。他这么说我就明白了，如果我按传统方式设计这个产品，最后结果又是业务人员不会用，程序员不想用，领导强制用的内耗局面。

Snipaste_2025-08-13_14-17-45.png

我的办法就是双向编辑，为这个流程场景专门设计一款领域语言 DSL(Domain Specific Language) ，程序员通过编辑器写DSL来实现业务，而业务人员则使用流程设计器来生成DSL。两种方式随时可以切换。复杂的业务编写DSL实现，而基础功能则使用设计器实现，既保证了功能与灵活性又保证了易用性。

image.png

视频演示： www.bilibili.com/video/BV1or…

代码的顶级理解

低代码平台应从灵活性、封装性、整体操作量、易用性四个维度进行考量，而很多团队都把力气花在易用性上（可视化操作），而忽略了另外三个维度的建设，这样的平台既没有地基也没有内核。

image-20250813144239331.png

让四个维度均衡发展，为特定场景设计专门的语言（DSL）是一个值得我们一试的路径，理由如下：

  1. 复杂度控制： DSL的语义边界更窄，更容易控制项目的复杂度，不会像GPL（通用语言）一样让程序员随意发挥
  2. 封装性： DSL（Groovy）和它的宿主语言（java）是无缝衔接的，组件可以封装在宿主中然后在DSL中调用，既保证了和GPL一样的封装性又不会把复杂度带入DSL中。
  3. 整体操作量： DSL本身带有大量语法糖，再加上各种组件的封装、还有文本编辑特性（如全局搜索替换） 使得它的整体操作量远低于GPL和设计器。 低代码追求不就是低成本吗？而整体操作量就是成本之一。
  4. AI 生成： DSL代码量更少，语义边界更窄 使得其更容易被大模型生成，而且生成之后也容易验证。
  5. 易用性： 与GPL相比 会有更简单的语法 对程序员的水平要求不高，其难度类似写SQL语句，但是非技术人员还是操作不了。

在满足业务情况下降低代码量，降低整体操作量才是真正的低代码，而不是把原来敲键盘（写代码）的操作换成点鼠标（设计器）这样做反而会增加整体操作量。

可视化和设计器同样重要，因为非技术人员短时间无法掌握DSL编写，而低代码平台中又沉淀了大量的行业模板，可视化设计器可以让业务或实施人员把这些模板价值发挥出来。 但从头到尾用设计器构建整个业务，甚至整个项目我是不是赞成的，因为成本上不划算。

做好低代码DSL设计是关键

DSL语法必须足够简洁好用，其扩展性、易用性、执行性能都应该得到保证，否则适得其反。

DSL的简洁性

网易 CodeWave 低代码平台也采用了 DSL 设计，其语言命名为NASL (Next Application Specific Language) 下一代描述应用的领域特定语言，名字非常宏大。

image-20250812115517738.png

其逻辑是使用设计器生成NASL代码，再把NASL转译成java代码或vue代码运行。这是一种单向编辑的设计，无法把直接编辑的 NASL 反转为设计器视图。

image.png

官网解释这种设计好处是 “NASL主要编辑方式是设计器，并利用可视化对复杂的语言特性做了屏蔽和简化”

但我个人认为这是一种糟糕的一种设计，NASL既不能写又很难看懂，它作为‘语言’的意义是什么？为什么不直接用设计器生成Java代码或Vue代码？其采用通用语言的方式去设计DSL也是错误的，它既不像DSL也不像GPL(通用语言)，只会增加使用者学习成本和维护成本。

下图左边是NASL代码右边是我们设计的DSL代码，同样都没学过相关文档，但你更容易看懂哪个？

image-20250812123258582.png

DSL的扩展性

业务是复杂的，所以DSL扩展性必须足够强，啥功能都不支持，哪怕再简单也没人用。 这里我们基于Groovy来设计DSL，在扩展性上有天然优势，扩展一个任务或某个机制只需要添加一个类或一个方法那么简单。相比Coze 、Dify钉钉等采用常规的Json或Yaml方式，成本不到其十分之一。

比如下面我要给Http任务添加一个超时重试机制，我只需要在方法中加一个retry 方法即可，此时DSL就直接支持重试了，不需要编写任何引擎解析代码。

image-20250812164937202.png 如果采用 json 方式，一定要先声明一大堆参数，然后在执行引擎中解析这些参数，最后才能实现该功能。

得益于DSL扩展能力，我曾仅用一天时间完成了和微信公众平台、以及扣子的集成对接，实现了一个智能客服的业务。DSL集成能力包括：

  1. 微信消息与事件触发器：
  2. 异步循环查询扣子回复状态
  3. 读取扣子消息回复
  4. 回复微信消息

下面我把相关DSL 贴出来， 你可尝试看看 如果换成其它平台 需要扩展多久，扩展之后复杂度又有多高？

init {
    listen weixin on "text"  // 监听微信的文本消息 然后触发流程
}

//发起对话
coze_chat= HTTP {
    url="https://api.coze.cn/v3/chat"
    method="POST"
    json """
    {
      "bot_id": "7522033712146841639",
      "user_id": "${input.body.FromUserName}",
      "stream": false,
      "auto_save_history":true,
      "additional_messages": [
        {
          "content": "${input.body.Content}",
          "content_type": "text",
          "role": "user",
          "type": "question"
        }
      ]
    }
    """
    bearerAuth config.cozeToken
}

// 循环遍历结果是否返回
waitCozeMessage= EACH {
    // 查30次
    from 0..30
    delay 2000
    // 访问状态
    HTTP {
        url="https://api.coze.cn/v3/chat/retrieve"
        params["conversation_id"]=coze_chat.result.data.conversation_id
        params.["chat_id"]=coze_chat.result.data.id
        bearerAuth config.cozeToken
    }
    filter {
        it.data.status == 'completed'
    }
    //读取消息
    HTTP {
        url="https://api.coze.cn/v3/chat/message/list"
        params["conversation_id"]=coze_chat.result.data.conversation_id
        params.["chat_id"]=coze_chat.result.data.id
        bearerAuth config.cozeToken
    }
    first()
}

// 回复消息
returnMsg= weixin.post {
    url="/message/custom/send"
    json """
        {
            "touser":"${input.body.FromUserName}",
            "msgtype":"text",
            "text":
            {
                 "content":"${waitCozeMessage.result.data[0].content}"
            }
        }
    """
}
start {
    async {
        run coze_chat
        run waitCozeMessage
        run returnMsg
    }
    "success"
}

因为扩展成本低所以可以快速扩展互联网上的应用

image-20250521171959484.png

也可以快速集成企业级开发中复杂的第三方组件：

image-20250521171920462-5065423.png

DSL执行性能

该DSL本质上就是Groovy代码，Groovy最终会编译成class 在JVM中运行，所以它的性能接近java原生语言。相比如Dify 、Coze、n8n等在沙箱中运行逻辑，就引擎本身而言，其性能差距达上千倍。

下图是拿我写的引擎与n8n比较，同样的业务逻辑 100线程达到3000/s并发 ，而n8n只有6/s。

image-20250609175051195.png

事实这远没到达引擎极限，我做了压力测试，在我的个人电脑上 （MacBook Pro 2019 Cpu：Intel Core i9 8核 2.3 GHz、 内存16 GB） 可以跑到每秒3.5万的并发。

项目数据
jvm配置java1.8 -Xms4g -Xmx4g -XX:MaxMetaspaceSize=1024M
压测线程数12
压测时间5分钟
QPS35856
任务平均用时0.38毫秒
CPU1100%
Young GC436次, 用时37526ms
Full GCFull GC: 1次,用时31ms
内存信息老年代：388M 、元空间：27M 、新生代1264M
类加载类加载数：4829 类卸载数：0
执行总数10756912次
失败0次
成功率100%

详细数据：

总数:10756912 QPS:35856, 最大:258.80ms,最小:0.11ms,平均:0.34ms,总用时:3612789.08ms
Young GC: 436次,用时37526ms Full GC: 1次,用时31ms 
Code Cache:17/18/240 M
Metaspace:27/30/256 M
Compressed Class Space:3/3/248 M
PS Eden Space:1264/1318/1318 M
PS Survivor Space:22/23/23 M
PS Old Gen:388/2731/2731 M
类加载数：4829 类卸载数：0

工作流系统开班教学

为什么开班？

不止一个人问我 ，为什么不继续卷产品？而是走被很多人看不起的教学路线？

因为技术本身不能创造价值，只有在客户那落地最终用起来才有价值。但做为一个B端产品光有技术是不够的。渠道、营销、客户关系每个环节的份量都不比技术轻，这些不是我擅长的，所以我采用教学的方式，我每多教会一个人产品的渠道就会多一条，离客户也就更近一步。

另外这种双向编辑的DSL本身是用的人越多、它就越稳固生态就会越好、用的人也就会更多，这是一种正向循环。只有毫无保留的教学才能赢得大家和市场的信任。

课程特点：

  1. 项目背景是一线大厂真实项目，今年3月份才结的项，历时8个月完成。

  2. 学完这个项目后 ，其完全具备商业化的能力，你可直接用于商业化，我还会指导你如何向客户做 POC。

  3. 无论是低代码还是Ipass集成平台或是AI工作流量平台，应用场景是很广泛，市场持续在增长，这是一门值得大家投入的生意

    根据IDC 最新发布的《中国企业级集成平台（iPaaS）市场跟踪报告》显示，2024 年中国iPaaS 市场规模突破42.6 亿元人民币，同比增长38.7%，预计到2027 年将达到115 亿元。

  4. 这个项目全程由我带队设计实现，没有人能比我更熟悉它，所以整个技术栈我都会跟你讲明白。

  5. 项目从头到尾带大家逐行实现一个，答疑都是实时的

  6. 你要以用它来找工作，也可以用在你们公司 ，这个价值比背面试八股文有用多了。

  7. 一个真实背景的前沿项目，可以让你真正学到从0到1的完整技术栈和推进过程

教学方式：

  1. 视频录播+课程源码+教学文档+1对1答疑+POC指导

你的收获：

  1. 你将获得一个双向编辑的工作留编排系统和源码（企业级可商用）。
  2. 获得该工作流编排系统前后端所有源码
  3. 获得该系统2年的持续更新
  4. 获得该系统的完整教学 （视频+文档+源码+1对1实时答疑）
  5. 如果你需要在客户那进行POC，提供方案咨询（限时2年）

课程价值与适合人群：

  1. 企业技术管理者： 满足企业的集成编排需求，打造通用的编排产品，降低边际成本。
  2. 程序员： 从0到1掌握商业化项目完整实现，增加简历亮点，打造个人技术标杆。
  3. 测试人员：可用于集成测试。另外测试人员和客户更近，更能理解业务场景，通过编排快速构建业务场景从而争取商业机会
  4. 运维人员： 或用于构建自动化运维流程。此外可与apisix结合打造可编排的API网关。
  5. 独立开发（创业者）： 工作流集成的市场非常活跃，无论个人还是一线大厂都在从事该领域，此外它与业务场景深度绑定的特殊性，所以不会出现赢家通吃局面，后来者仍可入局。

以下是已报名人员学习该项目的真实目的：

image-20250812205133806.png

教学内容：

阶段一：快速掌握Groovy特性

项目的执行引擎与DSL基于Groovy ，所以你必须熟悉Groovy的基本语法，尤其是跟Java有区分的特性，比如元编程、闭包、方法执行链等，这些都与DSL设计有关。

如果你已熟练使用groovy语言，可跳过《快速掌握Groovy语法特性》、《Groovy元编程特性》、《Groovy闭包机制与应用场景》相关内容，但《Groovy在DSL中的应用》是必修的，因为涉及经验性的内容，网上没有相关资源可供学习。如果时间允许建议你全部都过一遍，以免漏掉重要知识点。

学习目标：

  1. 快速掌握Groovy语言的基本结构
  2. 掌握Groovy元编程的特性
  3. 掌握Groovy闭包机制与应用场景
  4. 掌握Groovy的脚本机制及原理
  5. 理解groovy性能与安全机制优化
  6. 理解Groovy在DSL中的应用优势
  7. 理解Groovy底层原理

阶段二：从0到1手写API编排引擎

我们需要在1个月完成引擎最核心代码的编写，借助Groovy元编程的能力 ，引擎的关键在于设计 ，反而编码量并不大。该阶段我需要完成从触发器、到任务、到编排的完整流程实现。

学习目标：

  1. 引擎整体结构设计

  2. 触发器设计与实现

  3. 任务设计与实现

    • 脚本任务、分支条件任务、多分支任务..等
    • HTTP任务、EACH迭代任务、JDBC任务..等

  4. 编排指令设计与实现

    • run 执行指令 when 分支指令
    • async异常指令、join并发等待指令

  5. config 公共配置与实现

  6. 自定义任务机制设计与实现

  7. App应用集成与扩展

    1. 应用自定义触发器
    2. 应用自定义任务

阶段三：一口气集成10款热门应用

引擎写完了如何才能加深对引擎的理解，光看视频和文档是不够的必须上手去练习 。做应用集成就是最好的练习， 同时配合一些业务效果更好。比如实现微信的智能客服 ，把Coze中的热门工作流复刻出来。

学习目标：

  1. 《微信公众平台集成》
  2. 《企业微信集成》
  3. 《淘宝开放平台集成》
  4. 《飞书开放平台集成》
  5. 《钉钉开放平台集成》
  6. 《抖音开放平台集成》
  7. 《抖店开放平台集成》
  8. 《DeepSeek大模型集成》
  9. 《DouBao大模型集成》
  10. 《ChartGpt大模型集成》
  11. 《Kimi大模型集成》

阶段四：构建开箱即用apiFlow (后台控制器)

目前Api Flow仅支持Java程序员添加依赖手动构建，这加大了用户触达门槛，同时也限制了用户基数范围。为了解决这一问题本阶段将做一个标准化的集成系统 ，可一键使用允许java之外的程序员或测试人员使用：

学习目标：

  1. 集成系统可以一键独立启动
  2. 可基于Docker一键拉取并启动
  3. 支持基于Spring boot零配置集成
  4. 提供后台控制器WEB界面，提供dsl编辑更新、查看l状态、监控记录等功能
  5. dsl编辑语法服务
  6. 提供dsl任务的单步调试功能
  7. 支持动态注册应用信息
  8. 支持动态配置数据库连接信息

阶段五：企业内部应用集成(多协议)

目前api flow已基本满足外部系统集成场景，但企业内部应用集成场景却无能为力，企业内部有着更为复杂的集成场景，如：集团与各子公司、合作伙伴 、以及云上SAAS都需集成打通对接。为此我们需要让api Flow支持更多的协议， 以适用企业内部的架构环境。系统需完成

学习目标：

  1. rpc协议扩展

    1. 支持gRpc远程调用
    2. 支持Dubbo远程调用
    3. 支持Thrift远程调用
    4. 支持微服务远程调用
    5. 支持常见分布式注册中心Eureka、Consul、ZooKeeper、Nacos

  2. MQ消息队列扩展

    1. ActiveMQ 扩展
    2. Kafka 扩展
    3. RabbitMQ扩展
    4. MQTT协议支持

  3. 支持Apollo分布式配置

  4. 主流存储方案如：Redis、neo4j、mongoDb、elasticsearch、excel

  5. 自定义协议支持与扩展

阶段六：构建可视化流程编辑器

目前ApiFlow一边接入更多应用，一边扩展支持更多的协议 ，功能上已满足绝大部分应用场景，同时控制台也使易用性得到了提升。但和那些优秀的商业化集成系统相比，还差最后一个可视化流程编辑器。有了它用户门槛将进一步降低，到达非技术人员也能使用。另外可视化使的流程更容易理解，让你的项目更容易推广和传播。

可视化编辑器应到成如下目标：

  1. 单个dsl文件可直接生成流程图，不依赖额外数据存储
  2. 通过拖拽生成流程图，可直接保存成DSL文件
  3. DSL文件与流程图之间可进行双向编辑，任何一方的编辑都可无缝转成另一方
  4. 支持节点的拷贝，包括拷贝至另一流程图
  5. 支持流程图编辑时前进后退
  6. 支持节点另存为模板
  7. 支持节点详情编辑
  8. 支持节点单步调试
  9. 支持历吏记录保存
  10. 支持节点的表单界面输入
  11. 支持输入时动态提示
  12. 支持基于节点属性进行外观装饰
  13. 支持可视化查看执行流程

价格：

统一价格 3980元 。若它是一个普通项目可能你会觉得贵，但这个项目背景可是7位数呀，现在你4位数就可以拿下。 另外比起去买别人的产品，这种掌握在自己手里的产品更可靠。

关于作者：

写了十几年代码，做了六年技术培训，一心想做一个伟大的产品，目前是自由职业者，目前从事工作流以及AI相关项目研究，如果你看好该项目就找大叔咨询吧。中年码农挣口饭吃，非诚勿扰感谢理解。

联系大叔本人：z276386551

avatar
文章
阅读
粉丝