自然语言开发、零代码、低代码，到底谁才是软件开发的银弹（零代码应用开发）

不管是软件产品的用户、还是软件公司的老板，或是写代码的码农，都苦软件开发这个行当久矣，很难见到一个行业属于甲方、乙方、从业人员都在骂的行业，软件开发行业就是。

甲方骂我给了那么多费用，为啥还满足不了我的需求，到处都是bug，交付时间老是延误。

乙方老板骂甲方，你就这点钱，还三天两头改需求，动不动就要我两天搞完，我又不是超人；乙方老板也骂员工：我一天养你们那么多人，开着高薪，你们怎么连这么简单的功能都做不好，给我加班！！！

码农：这些需求你们都没想好就要我开发，现在三天两头改怪我咯，天天催我上线，我连单元测试都没时间，就这点工资还每个月都拖。

看吧，三输局面，没有哪个行业有那么多豆腐渣工程，没有哪个行业利润那么薄，没有哪个行业员工那么辛苦，996最早哪来的？可不就是软件开发行业传开的吗！

看过软件工程领域圣经《人月神话》的人，都知道银弹（银弹就是可以让强大的狼人被一击毙命的武器），软件工程借银弹来比喻那种一招制敌，解决软件工程中所有问题的终极武器。

可惜几十年过去了，软件开发领域的从业者们还是没有找到银弹。但最近几年涌现的低代码、零代码，甚至AI大模型、自然语言编程让人们不既让大家又看到了一丝曙光。

可现实远没那么理想，低代码被大家批成业务人员不会用，开发人员不愿用；零代码更是被嘲讽成玩具，AI大模型和自然语言编程也是说着很美，但真到工作中又不顶事，很难大规模工程应用。

难道最终还是没有办法吗？实际上确实不存在银弹能一劳永逸的解决所有问题，但也许另一条“合纵连横”的道路能把这些各有优势的技术和产品集中贯通起来，成为真正的银弹。

不知道我在说啥的，继续往下看，我们现在把软件开发按照开发模式划分为四个层次，分别是：

1、传统硬编码的开发模式：这个无需多说大家都明白；

2、低代码开发：大部分常见、简单开发通过前端拖拉拽和系统配置开发完成，复杂和个性化的需求依然能够采用代码编写的方式完成（代表：各种**云）；

3、零代码拖拉拽式开发：不需要写代码，靠界面上组件的拖拉拽操作以及系统配置即可完成软件开发（代表：钉钉宜搭、百度爱速搭）；

4、自然语言开发：语音也好、文档也好、文字也好，只要是人类语言说出来的，就能作为需求输入完成软件开发（代表：微软Copilot，中国电信星辰大模型·软件工厂）。

现在大部分软件公司还停留在第一个传统模式开发的层次上，啥项目都是硬编码，好点的积累了很多可复用的库或功能模块，再有个好的研发管理流程就已经算不错的公司了。

另外，部分头部软件公司或有想法的公司在保留部分传统硬编码的开发方式下，大部分产品的开发和项目实施已经转到低代码开发模式中，比如像金蝶、用友、致远、泛微以及一众saas软件企业，在长期的业务实践中，他们总结积累了自己的研发基座，这些研发基座基本就是低代码平台，这些基座让他们提高了开发效率，增强了研发的过程管理。

我拿我所在的小公司举例，因为忧患意识比较强，所以也很早自研了自己的低代码平台用以项目和产品的研发，现在除了20%的历史遗留项目外，公司80%的项目都已转入低代码开发模式，在此模式下已跑了两年，也未出现很多人诟病的复杂项目无法开发的情况。

当然低代码最大的客户并不是软件公司，而是信息化经费充足，组织规模较大的企业，但低代码在这些大型组织内还是一种尝试性的应用，并未大规模的采用后用以替代原有系统和开发模式。

零代码在软件公司中较为罕见，更多的是在一些非专业软件公司，如系统集成商，个人工作室和一些甲方用户里在小规模的使用。

而自然语言编程更是处于早期，微软公布（不是发布）类似产品的demo也才过去几个月的时间，所以现实中并未见到实践案例。

那这些软件开发平台类产品到底什么才是最好的呢？

以我个人浅见，提供给用户的软件开发平台最好的肯定是自然语言开发，简单易学、受众面广，但是以现有的技术和模式来说，自然语言开发在可以预见的很长时间内，局限性还很强，搞不定很多用户需求。

那怎么办呢？我的看法就是“合纵连横”，何谓“合纵连横”，我们先来看看这几类产品对应的用户类型划分。

1、传统硬编码：软件公司开发工程师；

2、低代码：懂技术的入门级开发人员，如：软件公司的初级开发工程师、甲方客户的开发人员；

3、零代码：略懂技术的甲方IT人员或软件公司里的产品经理；

4、自然语言开发：完全不懂开发技术的用户，如甲方的市场、销售、老板等人员。

从用户面来说，从上向下兼容容易，能用硬编码开发软件的码农自然也能用自然语言开发（虽说现在很多开发人员不愿意这么干）。但从下向上兼容就不可以了，一步都不可以，不懂技术的人甚至连零代码用起来都别扭，更别说低代码。

很多人会说那么多年下来，搞软件开发都是码农主力，为啥你非要去纠结普通业务人员来参与软件开发，原因如下：

1、普通人员比软件工程师人力成本低；

2、甲方的业务人员比乙方的软件工程师懂业务；

3、产品经理比软件工程师更懂需求和产品设计；

所以“合纵连横”下有没有可能出现一种新的软件开发协作模式，把多种软件开发平台集成在一起，让各类项目相关人员一起协作来完成软件开发。比如：

先由甲方的业务人员用自然语言开发模式搭建出系统的基本功能框架，这个框架能够表达出用户的基本需求、数据组成、展现形式。甲方业务人员在软件开发方面的能力极限也就到此为止，整个项目的完成度可达到20%-50%；

下一步，在此基础上，由甲方的IT人员或乙方的产品经理进一步用零代码把这个“毛胚房”开发成“简装房”，这一步的成品已经达到产品原型的地步，但相比传统的产品原型，这个成品里一些没有复杂业务逻辑的简单功能已经能够直接运行，产品经理的天花板也就到这里，整个项目的完成度可达到40%-70%；

第三步就可以由乙方的初级研发工程师使用低代码平台完成简单代码的编写和复杂产品的配置，到这一步时，整个项目的完成度可达到60%-90%，进入“精装房”阶段；

到第四步只剩下少数技术难度较高的特殊需求，或是要对平台进行底层代码编写才能满足的需求，但也只需要乙方少量的高级工程师或系统架构师就能完成。

以上已经是一个较复杂项目“合纵连横”各步的完成情况。但实际很多项目并未这么复杂，甚至有10%的项目在第一步就能完成，20%的项目在第二步就能完成，30%的项目第三步可以完成，只有40%的项目才会走到最后一步（以上数据依据本公司项目实践所得，不代表行业整体情况）。

“合纵连横”带来的好处就是，甲方业务人员深度参与，业务需求在第一步就能得到充分的梳理和“释放”，减轻了业务需求不明给后期带来的众多问题，同时甲方人员的深度参与，也会使其获得成就感和参与感，进而对项目提供更多的支持和配合。

对乙方来说，因为甲方的加入，自身的工程量减轻，清晰的需求也避免了后期的反复，同时只需人力成本较低初级工程师就能完成绝大部分工作，也大大减轻了项目的实施成本。实施成本的降低也会反哺甲方的信息化建设，使其用较少的经费就能完成更多的项目建设。

这样的项目模式在业内极少见，很多同行肯定也要说，你这个太复杂了，甲方爸爸不光出钱，还得陪你一起搞研发，哪个甲方爸爸愿意这么受累？

确实有这个逻辑存在，但就我的感受，我们服务的客户，特别是大型客户、企业客户，越来越希望能够深度参与到项目建设过程中，而不是仅仅当个项目经理等着验收成果，现在很多项目甲方甚至派遣产品经理、开发人员随同乙方的项目团队一起开发，就是为了自己的项目过程不走偏，同时在项目结束后能够从乙方手里全盘接手项目。

“合纵连横”这种模式有其很大的优势，但现在鲜有这方面的实施案例，造成这种情况并不是甲方不接受，而是乙方没有集自然语言开发、零代码、低代码、原生代码于一体的软件开发平台，自然无法实施。但从逻辑和理论以及我司这些年的实践经验看，确实不乏是一颗能够解决软件工程问题的“银弹”。

这样的软件开发平台集四种开发模式为一身，当高维度开发模式不能满足项目需求时，可降维使用低一维度的模式继续项目开发，同时这样的软件开发平台要能集成研发过程管理系统就更加能使项目开发如虎添翼，方便甲乙双方项目人员的工作协同进而提高研发效率和质量。

以上过程本人已部分实践，欢迎同行探讨。