低代码/可视化技术的最终形态是什么？
传统低代码/可视化开发技术通过黑盒规则引擎运行，这种设计极大制约了应用系统的扩展性。它们用更少的表达能力换取更简单的使用方式，在企业级复杂场景下必然走向失败。真正的可视化开发不应该限制表达能力，而是让开发者用可视化的方式编排各种系统模块和技术能力，从黑盒DSL（Domain Specific Language）引擎转向开放的编排协议，从受限的表达转向无限的可集成性。
DSL引擎的表达能力受限
企业应用的复杂性在于需求的不可预测性和企业之间的必然差异。DSL只能表达设计者能够预见的场景，当遇到DSL无法表达的需求时，只有两条路可走。
第一条路是扩展DSL语法，结果是语法越来越复杂，最终变得难以维护。这种扩展什么时候是个头？第二条路是在某些地方放弃DSL搞特殊处理，结果是系统一致性被破坏，用户被迫在两套体系之间切换。
所以，DSL的局限性不是设计够不够好的问题，也不是实现质量好不好的问题，而是技术路线的本质约束。不要企图设计出一个表达能力更强的DSL，这是一条死胡同。
DSL引擎的技术集成能力受限
DSL解释引擎是封闭的黑盒，只有平台方才能修改，用户和第三方无法扩展。然而，现代技术生态是高度开放的，技术迭代日新月异，npm有300万+包，Github上有海量开源项目。用户想用新的技术，却不得不等平台方适配。封闭的DSL解释引擎永远追不上技术演进的速度。
可视化开发不是要可视化地完成所有编程
上述DSL的两重限制都建立在一个错误的假设上，即错误地认为可视化开发就是用可视化方式完成所有编程工作。
一个应用系统由结构和过程构成，编程擅长表达过程逻辑，编排擅长表达结构关系，二者互为补充。低代码/可视化开发技术的终极形态一定是面向编排的，且保留编程能力，即面向编排的系统架构、开发框架、可视化开发工具以及应用代码。这正是JitAi始终坚持的技术路线。
面向编排的系统架构
面向编排的系统架构基于开放的架构协议而非封闭的DSL解释引擎。JitAi的JAAP（JitAi Ai Application Protocol）从结构上定义应用系统的构建标准，且JAAP与应用的具体技术实现无关。每个应用模块都是自描述的，可在运行时相互感知、驱动，支持动态加载和热插拔替换。
JitAi通过Meta/Type/Instance分层结构定义系统模块。Meta定义场景类别，Type封装技术实现并开放配置项，不同的Instance承载差异化的业务配置。
面向编排的开发框架
企业级应用系统基本都是由门户、页面、组件、模型、服务、审批、事件、任务、权限、组织架构、登录方式、数据库等Meta构成。JitAi的开发框架将这些元素封装为不同的元素族类，提供了大量开箱即用的Type元素。开发者只需创建自己的多个Instance即可组装编排出完整的应用系统。
JitAi开发框架支持开发者扩展定义自己的元素、改写官方的元素，不存在表达能力受限和技术集成能力受限问题。
面向编排的可视化开发工具
编排结构的最佳方式就是可视化。JitAi的可视化开发工具支持将所有应用模块可视化展示，并支持可视化编辑和配置。可视化能力不仅覆盖JitAi开发框架中的所有元素，还可以覆盖到开发者自定义的元素，只需要按照JitAi的规范为自定义Type元素实现可视化编辑器即可。
在JitAi可视化开发工具中进行应用模块的组装编排，可以实时预览效果，并且自动生成高质量的原生代码，这些代码可以被自由修改。
面向编排的应用代码
代码作为应用开发的产物，存在于每个独立的系统模块中。JitAi的应用模块之间完全没有静态依赖，作为一个独立资源包可以在不同应用中自由复用。你不需要再到处复制代码片段，然后再去调整其在不同应用中的兼容性。这种级别的编排复用能力在基于标品大量定制化交付企业项目时非常实用。