「数字孪生」低代码，到底是「内用」还是「外用」？

最近一段时间和同行交流，讨论到了一个和「数字孪生低代码」相关的话题，相较于去年，无论是数字孪生还是元宇宙的热度其实本质上都有所下降，不少大厂的元宇宙相关的业务的投入也都集中性的开始收缩，转而将资源投入到了GPT相关领域。

而在「数字孪生」领域中被寄予平台化的希望的「低代码」平台，自然也走到了一个路口，尤其是对于资源非常有限的团队来说，是要继续投入产品化还是就此打住，是服务于内部生产的「节流」，还是要争取进一步的标准化销售，实现「开源」。

1、为什么要在这个时间点讨论这个问题？

一、去年在市面上其实出现了很多类似的产品，我没有做广泛的调查，但是从个人感受上来说，并没有产生一个非常突出的明星化产品，类似Cesium、UE4或者是Unity之类的，所以应该还是有些东西没有踩对，而且在这里面通常要考虑标品的销售以及定制项目的比例，如果都是定制项目带来的标品销售，这种情况应该区别来看。

二、在一些典型的大屏类项目交付的过程中发现，其实很多厂商的交付都开始采用了这类「低代码平台」进行交付，而且绝大多数都是自有产品，所以这类产品在厂商内部应该是广泛应用于交付了，那内部验证成功之后，是不是就一定会有别人愿意买？

2、服务于内部生产这个逻辑成不成立？

估计在规划「数字孪生低代码」这个产品的时候，应该很少是奔着解决自己内部的生产效率的问题，而更多的是希望能够借此实现项目化到平台化的转变，但是如果对外销售的情况不理想，或者现阶段只能包在自己的项目里面进行销售，很多团队往往就会把产品目标调整为服务于「内部生产」。

服务于内部生产这个逻辑到底成不成立，主要还是看效益，能算得过来帐就成立，算不过来帐就不成立，比如同样的需求，内部研发交付的成本可以大量的节省则逻辑就通顺，但是如果在需求一定的情况下，产品研发+项目实施的成本并没有降下来这个逻辑就不成立。

服务内部生产其实还有一个指标就是市场预估，未来的需求是增加的还是下降的，这个要判定清楚，如果未来交付需求可能会持续增加，那预先投入资源进行一些提前的准备，那这种逻辑也是通的，在疫情期间不仅仅是数字孪生，信息化很多领域的需求其实都是有所放缓的，那随着放开需求会不会反弹也是需要做市场的分析。

但是如果只是短暂的为了回避经营的压力，而说目前是定位服务内部，要么就是产品的研发节奏规划不清晰，要么就是自欺欺人，因为自己要说清楚为什么现在不行未来就一定行。

3、低代码到底有没有价值？

如果只能回归内部生产，则必然会涉及到一个疑问：低代码平台到底有没有价值？

这个问题其实过去一年也是讨论了很多，但是这种讨论更多讨论的是通用性的价值，而在本文更多讨论的是在数字孪生领域低代码平台到底有没有价值。

首先3D可视化一定是有价值的，最直观的就是「看的更直观、效果更好」。但是在基础的SDK和应用之间是否还存在一个低代码平台这个是值得讨论的。

其实当前的大屏从形态上来看仍然是（GIS制图产品+BI类产品+物联网数据接入产品）的融合，从BI的视角上来看，其实算是BI类产品的一个分支或者是升级，所以BI产品所具备的一些特征在数字孪生产品上也会体现出来，从GIS的视角上来看，当前的数字孪生本质上是对过往2D制图的一个升级和变革，在3D的场景下，过去2D制图的一些理论、方法和技术都不再适用了，所以需要发展出一种新的产品类型来支持。

但是这些东西本质上都还是3D化带来的的产品价值提升，而且这两个领域其实在过去的操作模式上其实都是有「低代码」这个特征的，比如GIS的一些数据处理以及样式配置这些东西，其实都是通过配置交互完成的，所以大家才会想着一定要在数字孪生的基础上加上低代码。

而且在数字孪生领域有一个有一个低代码应用非常成功的例子，其实就是UE的蓝图和Unity的ShaderGraph，他本质上是一种可视化的开发平台，我发现我们公司的开发小伙伴用了这些可视化的开发工具之后，其实对这个工具的依赖性就比较强了，比如我们团队的一个小伙子，他用完ShaderGraph之后，我再安利他直接写Shader脚本，他就会比较抗拒，好的东西一定是「用了之后就回不去了」。

4、低代码前面应该有个「1」

那低代码这么有价值现在为啥还会面临很多都要绑定在项目里卖呢？其实在这里面，我个人的理解，低代码其实是加分项，是一个增值服务的内容，其实它并不创造核心价值，所以应该类似Unity或者UE一样，引擎是核心主体这个「1」，他本身是不是低代码并不重要，不是你也得用他，后面的低代码产品是一种新的开发模式选择。

比如Mapbox Studio这款产品就是基于MapBox的引擎和高质量的数据构建的，即使没有这个Studio产品大家还是会用MapBox这个引擎。

当前的一些低代码整体感觉只是一个流程上的改造，而且很多产品的成熟度还不够，这种改造说白了有的还挺麻烦，上手了之后呢，又发现有很多功能是支持不了的，还需要用很多奇技淫巧来适应，还不如自己开发来的省事，没有这些工具似乎大屏开发也没遇到什么问题。

所以低代码的前提是需要把这个核心价值强化。

5、产品化的前提是具备「先机」

数字孪生低代码平台化其实除了需要具备核心的价值外，还有一个非常重要的点就是：产品化的「先机」，其背后是用户习惯的养成。

产品化在信息化领域一直是一个热门的话题，尤其政府信息化领域需求难以标准化，所以产品化很难做，但是这种难以标准化的背后其实主要方法论的缺失，一般情况下，一个产品能够比较好的标准化同时又能够得到比较好的认可的前提是首创了一种独特的行业理念、方法和技术，首先这个东西是你们最先提出来的，然后大家都会以你的理念为标准，自然你做出来的产品以及标准就是事实上的行业标准，这个是非常重要的，所以大家才为什么说一流的企业是做标准的，因为他的理念和研发都是具备了这种标准化「需求」或者说是「标准化解决方案」的先机，这个时候就会培养用户的习惯，而跟随的往往需要四处突围做微创新，产品化的窗口就比较少。

我们平时考虑问题的逻辑大多数都是因为我项目做的多了或者有政策我们就产品化，我这给出的视角更多的是构建行业领先的产品则其实是需要具备这样的「先机」条件的，所以在数字孪生低代码这边其实也是需要考虑清楚自己的「先机」条件是什么，尤其是那些看似很高大上但是并没有带来产品提升的设计。

所以你们的数字孪生低代码产品2023年到底是「内用」还是「外用」，欢迎讨论。

– END –

线下活动