每当我们面对一种新的开发方式时，“XXX会取代程序员吗？”总会成为热议的话题——其反面实际上是在探讨“如何让越来越多普通人能够脱离代码的束缚，同时又能够进行编程？”
从这个意义上看，无论GPT生成式代码，还是惯常意义上的无代码开发，都是为了让更多有想法和洞察、但代码无能的人实现编程自由。数据显示，现在全球有编程能力的人只有 1300 万， 1400 万左右就只占全球人口 0.33% 左右的一个比例。
因此大家觉得，GPT 4发布会上展示的一张草图的照片就能生成一段可运行代码的操作，简直炫酷到家了。
但是从实际落地层面来说，大家会发现，即使 AI 可以产出代码，但这个代码离真正可以被部署到生产环境，或者说被任何的有价值的业务逻辑给使用起来，中间还有非常大的一个gap。
再说，大语言模型的代码产出是没办法让人完全信任的，因为它总会有一些“自以为是的合理想象”，也就是说在完全的精准度上面仍需要进一步提升。这个代码如果给到一个完全没有技术背景的同学，他其实是很难分辨好和坏的。作为自然语言大家都可以看得懂，但是作为代码的话，它这个壁垒本身的存在会造成它离真正安全交付和使用还有一段距离。
相比较而言，无代码选择了对代码进行可视化封装的方式，门槛也比传统意义上的编程会显著低 10 倍以上，那对没有技术背景的人来说，就能容易地进行测试和结果评审，去评估安全性、可用性以及稳定性等等，毕竟我们也在背后做了很多投入——包括怎么样把应用从可视化到真正交付的过程当中，这个自动托管的服务器的部分，都是由我们平台来进行提供的。
从GPT生成代码和无代码开发的特性来看，我反倒觉得，无代码和AI在场景上的融合，恰恰是一个非常明显的大趋势，微软也已经把自家的无代码平台Power APP与ChatGPT 做了整合。
我喜欢把这二者比喻成左脑和右脑的关系，大模型更像是一个感性的右脑，他会理解你的需求和意图，而可视化的无代码平台更像一个理性的、可信赖的左脑。大模型擅长“循循善诱”，一层层把你的需求翻译出来，无代码平台擅长逻辑编排、稳定交付，两相结合的话，我们的开发工作流很可能会被重构，自动化水平大幅度提高。
Zion主要从两个阶段切入与AI场景的结合。第一个阶段，通过和AI的整合来提升开发效率，这跟微软推出的基于office场景的copilot能力有异曲同工之妙，通过自然语言的交互，你可以快速把意图表达给我们的系统，大语言模型理解后，会自动化调用系统的能力快速搭建起来某个应用交付给你，就像copilot交付PPT、word大纲一样；当然，为了让这个工作流顺利构建起来，我们会在前期投入更多精力做好工具能力的封装，比如GPT的能力、文心一言的能力等。
那第二个阶段的话，随着模型的训练， AI 甚至可以扮演产品经理和设计师的角色，如果你可以提供一个完整的PRD的话，我们的系统可以把它直接翻译成一个软件，然后可以进行快速验证， MVP 的上线进行测试等；或者说，它可以和你一起共创产出这个PRD文档，在这个跟AI沟通和互动的这个过程当中，其实就是逐渐帮助你把你的需求和软件的诉求梳理出来。
而在传统的流程当中，作为业务方，你会跟一个产品经理沟通，产品经理会跟设计、工程师、运维沟通，然后最后会回到测试这边，整个形成一个闭环。在有AI和无代码工具加持的情况下，有些环节前期就可以自动化掉，当 AI 没办法提供这个能力的时候，那产品经理、设计师、工程师可以再介入进来。
但是，SaaS、无代码、AI这些变革一浪未平一浪又起，好些企业可能连信息化都没有真正完成，怎么才能参与到这个进程中来呢？
我一直把数字化这件事分成三层来看待，也就是交互层、业务逻辑层和数据层。在所有数字化的过程中，第一步一定是业务数据化，达成初期采集数据、结构化数据这个目标，企业可以尽可能选择一些轻量化、低风险、负担小的切入方式，最简单的就是挑选一些适合自己业务场景的工具，比如可以来找我们，使用Zion无代码的方式快速搭建一些符合自己业务需求的应用；如果说是可以直接产生价值的话，建议从偏营销、偏运营的一些场景入手。
很多企业都会有一个误区，觉得数字化的第一步是招工程师，这其实是错的。事实上，数字化转型第一步是要找到一个PM，因为他在这里扮演的一个角色是把业务的需求翻译成数字化的产品。这个人可能只是扮演产品经理的角色，但未必非得是一个产品出身的人，他可能是你信息化部门的负责人，也可能是你们业务部门里面喜欢技术的某个同学。有这个人，后续工具的落地就会比较容易了。
无论采取何种开发方式，对于商业痛点的判定、目标受众的考量、业务逻辑的梳理，都是先于开发工作而存在的。
– END –
报告下载
大佬观点
