VTJ.PRO 在线应用开发平台的业务模块（应用、DSL、模板、订单、智能体、技能）

聊到在线应用开发平台，很多人第一反应是“低代码”或者“零代码”，但真正在行业内折腾过的人都知道，这两者之间有一条很宽的分界线。VTJ.PRO 的设计思路，更像是在这两者之间找了一个平衡点：普通用户靠模板和可视化配置快速起步，专业用户用 DSL 描述复杂逻辑，再往上还有智能体和技能层来承接 AI 时代的交互方式。这篇文章我打算把这六个模块掰开揉碎，讲讲它们各自解决什么问题、模块之间如何协作，以及实际落地时容易踩哪些坑。

如果你正准备自建一个类似的在线开发平台，或者正在做技术选型，这篇文章应该能帮你省掉不少调研时间。我会把视角放在“模块化设计”和“业务闭环”这两个核心点上展开。

1. 整体设计思路：为什么是这六个模块，而不是一个大而全的引擎

任何一个在线应用开发平台，本质上都是在回答三个问题：应用长什么样、应用怎么被创建出来、应用怎么产生价值。VTJ.PRO 把这三个问题拆成了六个模块，各自承担明确的职责。

先给一个整体视角的概括：

这个模块划分的最大好处是职责边界清晰，迭代互不阻塞。比如模板模块升级，不需要改动运行时核心；智能体模块调整交互策略，也不会影响 DSL 的解析逻辑。如果你经历过那种一个巨石应用里改一行代码要回归全部功能的日子，就会明白这种边界感有多重要。

1.1 模块划分背后的三个关键取舍

我在实际设计类似平台时反复权衡过三件事，这里直接说结论：

第一，DSL 不追求“全能”，而是追求“可解释”。 很多团队在做 DSL 时会陷入功能膨胀的陷阱，想把所有业务逻辑都用 DSL 表达。VTJ.PRO 走的是另一条路：DSL 负责描述应用的页面结构、数据绑定和事件流转，复杂的业务计算让渡给后端服务和技能模块。这个取舍的好处是 DSL 的解析引擎可以保持轻量，前端渲染和后端执行都能获得更好的性能。

第二，应用和模板是分离的实体，不是附属关系。 这意味着模板可以独立于应用进行版本管理和质量评估，应用可以选择在某个版本模板的基础上 fork 出自己的 DSL，之后完全脱离模板独立演进。这个设计对商业化很重要，后面讲订单模块时会细说。

第三，智能体和技能不是“锦上添花”，而是应用的一种使用方式和能力来源。 从架构上看，智能体可以理解为“对话式的前端”，技能可以理解为“即插即用的后端能力”。它们和传统的页面交互、API 调用是并行的路径，而不是替代关系。

1.2 模块化带来的实际业务收益

从项目运营角度看，这种模块化设计带来的收益非常直接：

• 开发并行度大幅提升：平台团队可以按模块组建小分队，DSL 引擎组、模板设计组、智能体组互不干扰。
• 生态开放有边界：第三方开发者可以上传模板、发布技能，但无法触碰应用运行时核心，安全性可控。
• 商业策略灵活：模板可以免费引流，技能可以按调用计费，智能体可以按会话收费，订单模块统一承载这些计费模式。

2. 应用模块：从“表单配置”到“运行时容器”的进阶

应用模块是整个平台的门面，用户创建、编辑、发布、运行应用都在这个模块里完成。很多低代码平台的应用模块做得像“表单收集器”，功能有限、扩展性差。VTJ.PRO 的应用模块更像是一个容器化的运行时环境，它不关心应用具体长什么样，只负责把 DSL 描述的内容安全、稳定地运行起来。

2.1 应用的生命周期与场景状态管理

一个标准应用的生命周期包括：创建草稿、DSL 编辑、配置技能