我对低代码的理解

将逻辑抽象能力做一个分层：

1. 抽象层次的底层是 PL（Programing Language），图灵完备
2. 抽象层次的顶层是具体场景或功能的实现
3. 低代码处于以上两者之间，不具备底层的灵活性，但有定制顶层形态的能力

基于以上定义进一步分析，

失去底层抽象灵活性后，低代码只能应对特定的场景。因此首要问题是场景是什么，边界在哪里，需要能够明确定义才能去做对应的低代码。如果说什么都能做，那就是扯淡。其实这个论点可以延伸到很多领域上，明明不是图灵完备的底层设计，却强行发展领域范围外的能力，最终沦为抽象泄露的四不像。

说到抽象泄露，因为低代码本质是封装，工程关注点就是如何设计封装。好的封装能够完全屏蔽被封装者的复杂度，提供一套针对特定领域的接口。如果使用者还要去学习底层原理，甚至通过黑魔法调用底层 API 才能用好这套封装，那么这个封装就是失败的。

要意识到低代码的引入本身也是新的复杂度，这个复杂度对比原生方案的 ROI 是要提前考虑的。

像界面化或者语音化本质跟低代码没什么关系，只是交互形式而已，最终都是会转化成中间代码。所以核心还是设计中间代码本身。对编程场景而言，使用 LIB、DSL 这样的中间代码是效率更高的方式，拖拽和语音反而是流程上的冗余；对非编程场景，提供上层交互，去做上层交互到中间代码的转化才有价值。