在数字化转型中，企业面临“语义鸿沟”挑战，当前的自动化仅解决语法互通，缺乏对业务意图的理解。为解决这一问题，构建以本体为核心的业务语义框架（BSF）是关键。BSF通过定义业务概念、关系和规则，为AI Agent提供认知与行动基础，实现从流程自动化到决策自主化的跨越。通过用例分析，BSF在智能伙伴发现、解决方案组合及故障处理中展现了显著价值，为生态系统智能化升级提供了核心支撑。

AI编程正从代码补全向规范驱动开发演进，大模型能力提升是关键。开发者逐步转向定义问题和验证解决方案，核心技能变为编写精确规范。知识工程成为AI编程从玩具到工具的关键，构建AI可读写知识体系至关重要。工具形态分化融合，IDE与CLI界限模糊，未来将形成统一开发体验。

去哪儿网创新推出可视化营销画布系统，通过拖拽式节点编排解决传统配置工具灵活性不足问题。系统采用XFlow框架实现流程图功能，自研高性能引擎支持复杂策略执行，覆盖触发、分流、权益发放等全流程。独创子流程嵌套与策略表格功能，实现配置复用与精细化管理。上线后配置效率提升90%+，日均新增订单超3000单，核心接口响应时间稳定在50ms内。

目前国内除了阿里云、华为云，很多PaaS企业，包括涂鸦IoTPaaS、有赞云、徐工吉利工业互联PaaS、恒生Light云等等，都在推出或者计划推出低代码平台。文章尝试通过对应用软件研发发展阶段的分析，提供一个看待这一趋势的视角。

NASL是轻舟低代码平台提供给开发者的一门可视化编程语言，在此前分享中有不少人对此感到困惑，今天我们围绕NASL做一些解读，希望大家对NASL及低代码实现原理有更深入的理解。

低代码不是先有标准再出现的事物，它是研究机构对一类具备某些特性的高生产力应用开发平台（HPaPaaS）的归纳。不同类型的低代码厂商虽然目标相近，但是出发点和发展路径不尽相同。今天我们来聊一聊轻舟低代码想法的萌发和产品发展的情况。

如何低成本构建产品能力去支撑多条业务线、多租户。

低代码开发平台（LCDP）是无需编码（0 代码）或通过少量代码就可以快速生成应用程序的开发平台。通过可视化进行应用程序开发的方法，使具有不同经验水平的开发人员可以通过图形化的用户界面，使用拖拽组件和模型驱动的逻辑来创建网页和移动应用程序。这两年越来越多的公司和开发人员开始自研低代码平台来达到降本提效的目的。今天和大家分享一下低代码平台开发过程中遇到一个问题和对应的解决思路。

低代码平台不是什么新鲜事儿，很早就有了。比如国内早期的建站程序 Discuz，云平台上一键快速部署企业网站的服务，这些是不是低代码平台呢？我觉得这些都是。如果泛化低代码的概念，前端 UI 组件库算不算低代码呢？甚至一切可以通过 UI 操作批量生产交付物的平台，应该都算低代码。因为它们都提供了一些开箱即用的功能，降低了日常研发的复杂度和成本，提升了交付效率。

随着微服务诞生，前后端分析已成为常态，然而前端编程属于弱语言变更，使用场景广泛。随着前端大牛的增多，涉及到前端框架也不计其数，如果想开发一些高阶前端应用程序，你必须去掌握npm、webpack、react/vue、typescript等多种框架应用，同时还需要熟悉ES5、ES6语法定义。对于简单的项目入门还比较方便，涉及到一些数据状态管理情况下，需要解决的事情会变得更加复杂。

然而在我们开发过程中会遇到很多表格展示、表格筛选、表格排序，以及简单的增删查改的应用程序，利用现有的框架服务进行研发时我们会变得更负重，需要花费大量的时间成本以及掌握更丰富的框架应用。前端如此强大，难道都没有一款能解决这些同类型服务么。其实在13年百度FEX-TEAM团队都已经在开始构建低代码平台，在19年正式对外开放amis低代码框架，解决了我们无需掌握webpack、react/vue、typescript以及es6等这些高阶应用，只需要大家会写json字符串就可以开发出前端应用。

本文旨在探索与介绍如何通过“流量录制”、“流量回放”代码套件降低白盒测试成本，持续提升移动端代码可测性。

低代码平台中，如何在 “后端没有现成 API ” 的场景下快速开发出可使用的后端接口。

我们希望通过低代码这种方式来提高工程师的效率，一方面，通过配置而不是写代码的形式开发页面，极大减少开发和维护的时间，实现快速增量与迭代；另一方面，通过这种非编码的方式，避免快速迭代而产生的技术债。

距离 https://github.com/baidu/amis 第一行代码的提交已有七年，距其开源也过去了将近三年的时间，amis可视化搭建平台早已成为百度内部使用最广的低代码平台，在此基础上孵化出的对外商业版本 “爱速搭” 在金融，政企，工业等行业也有了自己首批客户。

星链是京东科技消金基础研发部研发的一款研发效能提升的工具平台，面向后端服务研发需求，尤其是集成性、场景化、定制化等难度不太高、但比较繁琐的需求。

在理解了服务端低代码平台设计实现的基础上，能够让大家更好的使用低代码平台扩展出更多的能力，丰富工具的打造，知道什么时候可以使用，如何使用。

kuta将来可能会走向内部开源，可以帮助kuta后来开发者对前面搭建的kuta架构有个高度概括的认识，在目前kuta中间层的基础上，扩展出更多的低代码能力，丰富目前kuta低代码平台所支持的功能。