低代码新思路
当前现状
低代码当前分为两个流派
- Schema + Runtime Engine（解释执行派）
- design 拖拉拽 -> schema -> engine（运行时）+ UI
- 特点：运行时依赖引擎、页面是“配置驱动”的、Schema ≈ AST / DSL（运行时的逻辑）、强动态/强联动、升级引擎 = 所有页面一起升级
- 代表：Formily、阿里 LowCode Engine
- 缺点：运行时复杂、Debug 难、性能受引擎影响、离开平台就跑不了
- codegen 派
- design -> ast -> code gen -> vue/react 源码
- 特点：ast是编译期间的结构
在真实工程世界里，代码生成派往往活得更久。
进一步分析两派
- Schema + Runtime Engine（解释执行派）
- 特点
- 1️⃣ Schema 已经接近 DSL / AST
- 包含：逻辑表达式、条件渲染、动态校验、生命周期钩子
- 内部通常：Schema JSON、Expression AST、Rule Engine
- 👉 本质上已经是一个解释执行系统
- 2️⃣ 设计器能力极强
- 3️⃣ 运行时引擎极复杂
- 1️⃣ Schema 已经接近 DSL / AST
- 弊端
- ❌ 性能天花板明显：多一层解释、多一层抽象、表达式频繁求值，复杂场景，性能一定不如原生代码。
- ❌ Debug 成本高：错误发生在 runtime、堆栈是引擎内部、用户配置 + 引擎逻辑交织
- ❌ 团队心理成本：高级编程人员不愿意使用低代码
- 更像“产品级平台”，而不是“工程级工具”
- 特点
- Codegen 派
- 特点
- 1️⃣ 工程化能力非常强：你生成出来的东西，看起来就是高级前端写的。
- 2️⃣ AST / 模板技术非常成熟：
- Babel / TS AST、Code Template + AST merge、增量生成（不覆盖用户手写代码）、区块锁定（// region）
- 👉 已经是“编译器工程”的成熟玩法。
- 3️⃣ 与真实项目天然融合：
- 代码进 Git、能 Code Review、能逐步重构、能脱离生成器独立运行、这是 压倒性优势。
- 生成代码 = 编译期付出成本，运行时零额外负担
- 弊端：
- ❌ 代码是持续演进的，但是生成的代码是一次性，如何持续增量演进呢？
- ❌ 缺乏中间语义层，现在本质是字符串模版的拼接，无法diff，也不可逆转，一次性使用，硬伤
- ❌ 复杂逻辑支持几乎为0，只能生成模版
- ❌ 没有设计态，其实就是没有schema、ast的支持
- 导致现在开源项目plop、hygen，第一代codegen几乎走进历史尽头，无法承载下一代的低代码的功能
- 特点
- 应用场景不同
- Runtime 派适合：（更多是产品）
- 非前端人员参与、业务规则频繁变化、表单即产品（如问卷、流程）、配置即数据（可存数据库）
- Runtime 派适合：（更多是产品）
- Codegen 派适合：（更多是工程化工具）
- 正规前端团队、中大型工程、有性能要求、生命周期长
两派开始融合
- 设计态：Schema + Runtime
- 交付态：Code Generation
- 拖拽 -> Schema / AST -> 导出源码（Vue / React） -> 项目内长期维护
- 运行时引擎：只存在于设计器、不进生产包
我的疑问
- 疑问：
- Runtime 派多一层解释，但是最终生成代码较少，是不是性能更优？
- 解答：
- 是的，Runtime 派在“源码层面”代码量更少；
- 但在“运行时层面”，代码量和执行路径反而更大，而且更热。
- 也就是说：👉 Schema 把“重复的业务代码”压缩掉了，👉 但同时引入了一坨“永远在跑的通用引擎代码”
- 运行时代码“少”，但执行路径“长”：1️⃣ 通用引擎代码是“常驻 + 热路径”，2️⃣ 重复逻辑并没有消失，而是“参数化执行”
- Runtime 派不是在“减少代码”，而是在“集中代码”。
- 一个关键但容易忽略的点：👉 JIT 很难优化 Schema 驱动的代码路径
融合
基本概念
- 概念与定义
- 1️⃣ 设计态 = Schema / Runtime（支持拖拽、联动、表达式）
- 2️⃣ 交付态 = 高质量源码（Vue / React，可维护）
- 3️⃣ 运行时不依赖低代码引擎（或依赖极小）
- Schema 只存在于“设计阶段”，而不是“生产运行阶段”
- 关键组成部分
- 1️⃣ 设计态引擎（Schema + Runtime）
- 2️⃣ Schema → AST → Codegen（最薄弱，但最关键）
- 3️⃣ 工程级 Codegen 基础设施（反而最成熟）
- 融合派最难的不是 AST 技术，而是“工程边界设计”
- 技术难点：
- 1️⃣ 把「动态逻辑」提前到编译期
- 这件事本质是：DSL 设计、AST 编译、代码结构生成
- 👉 这是“前端编译器工程”，不是普通业务开发
- 2️⃣ 保证“生成代码 ≈ 人写代码”
- 这是门槛最高的一点：可读性、可维护性、可演进性
- 3️⃣ 不锁死开发者
- 你随时可以抛弃低代码平台，但代码还能活
正确路线
- 不要先造设计器
- 先设计一套：可编译 Schema，明确编译期边界
- 从 Schema → Vue3 Codegen 打通一条最小链路
- 再反推设计器需要什么能力
边界（核心点）
- 编译期：编译哪些内容、支持哪些功能、限定范围边界是重点，如果不限制就有回到现在的runtime schema一派的困境中了；
- 如果边界是所有js都支持，直接低代码平台就可以生成所有的代码，看起来就是不需要程序员了，但是复杂功能、尤其语义复杂表达，可以生成高质量的代码吗？
- 因此限定schema的边界是核心，要收敛，如果是结构性产物使用schema，可规模化的进行规模化，而语义性的则预留出来，让程序员补充开发，最好可以支持增量开发；
- 涉及边界的几个难点要考虑：
- 复杂联动：最多考虑到纯依赖的部分，副作用不允许
- 表达式：编译到什么程度，编译成什么形式最合理？
- Schema 更新 → diff / 增量生成？如何演进？是全覆盖还是区域锁定？
- 用户手写代码如何保护？生成器只生成骨架层，业务逻辑在自定义层，生成器不影响自定义层
与AI Codeing的关系
- 现在AI变成看似基本可以替代低代码了？实际是这样吗？
- AI的优势是胶水代码、长尾交互，但是有时候会生成结果不可控，风格不一致的问题，AI code本身也需要约束和锚点
- 而schema和低代码最大价值正是，提供稳定的结构约束与可验证的接口。
- 未来应该是三层结构：
- schema/IR作为结构和约束，生成模版化代码，解决一致性问题
- 支持可编程的扩展点
- ai 在扩展点完成长尾实现，代码补全，复杂交互
- 总结：
- schema/codegen 能解决的是“结构性重复”，解决不了“语义性复杂”。
- 融合派的成功不取决于表达式/联动能否无限增强，而取决于：能否划清生成与手写的边界，并在边界内做到可演进。
- AI 会成为生成“长尾逻辑”的主要手段，但它必须被 schema/类型/测试/约束所锚定，才能进入生产。
深入融合
- 到底哪些是适合schema的，哪些是