关于AI时代的程序架构的变化

以ChatGPT为代表的AI出现，表示着AI的零点时刻已经突破。现在AI的使用已经不用再多说了，实际上是已经侵入到各行各业。所有人都在疯狂寻找本行业AI的使用场景，这样的盛景只在互联网刚出现的时候能感受到。

马化腾说，这个AI有可能像电一样是重要的未来的基础元素。我感觉还是很有可能。原来波士顿动力的机器人做的都只是翻跟头跑步，给人感觉是四肢发达头脑简单，感受不到智能的存在。但是结合摄像头语音控制。以及生成式AI，目前已经有公司实现了用语音命令机器人做一些原来做不到的事情。例如对机器人说“把红色的苹果放到某某的照片旁边”，然后机器人听到之后照做。这种场景中，人工智能的驱动力就体现出来了。前两年很火的华为天才少年稚晖君的创业也是做这个事情，特斯拉的“擎天柱”也是这个路线。

对于应用程序开发者而言，我们的如何来使用人工智能？ThoughtsWorks说他们做了一系列的实验：提升devops的效果；在编程实验中使用AI最终提升20%到30%的效率；也尝试了对应用程序来进行重构，用一些Dsl来做指导，引导AI生成代码；同样也探索了AI在业务逻辑层面的适配。但是我认为这个还不够。没有真正抓到开发的痛点。

开发的痛点是编程不快吗？是设计不深入吗？是DevOps不连贯吗？

是需求变化！

我们到现在为止是怎么对待需求的？“需求的变化要进行遏制，否则会导致程序的改动量太大”！即使是我们现在推行号称“拥抱变化”的敏捷开发，实际上也没有对业务的变化百依百顺，还是以遏制居多。

但是你要知道客户最害怕的是什么？他们害怕的是软件写的太固定，没有办法适应业务的需求。更害怕的是软件都已经开发完了，但是业务又变了。而对开发者来说，害怕的是软件还没编完，客户的需求变化了（当然，编完了就不怕了，毕竟可以让客户加预算嘛）！

我发现现在的软件行业里，ISV和客户之间形成了一种奇怪的博弈逻辑：所有人都在围绕着一个抽象的名词“需求变化”在进行博弈，没有人想着怎么真正解决客户的问题。

要知道，客户的市场在不断变化，任何一个公司要适应变化才能够有生存。客户之所以找我们开发软件，是因为他们想要一个能够适应市场变化的IT工具，帮助他们快速适应市场需求。客户和ISV没有一方是愿意需求变化的，但是又不得不去适应。如何适应？传统的手段能做到的不多，所以面对需求变化，要么耍赖，要么遏制。

未来AI进入应用程序，解决的一定是适应变化的问题！

若干年前，我和朋友在讨论应用分层的概念的时候，发现了应用系统中的“胶水层”。在领域驱动设计（DDD）中也明确分了用户界面层（UI层）、应用层（Application层）、领域层（Domain层）、基础设施层（Infrastructure层）。在需求变化的时候，每一层受到的影响也不同：界面层变化最大，但是代价较低；应用层变化较大，但牵一发动全局，会影响到其他各层；领域层深入到原子化的业务，只要不做根本性的变化，基本可控；基础设施层则受影响很小，除非架构大变化。

这个“胶水层”就是“应用层”。为了让应用层可以底层本快速适应需求变化，马丁福勒推出了dsl的概念。试图用解释性语言解决应用层变化过快的问题。主意不错，但业界实际上没做好，没有完全解决。SOA则提出了编排的概念，试图用后期流程图的方式把应用层的变化以低成本的实现。我和朋友则是提出了用nodejs来做业务的编排和适配（属于是重复发明轮子了）。

直到AI的出现。我认为基本解决了这个问题。

因为有AI的出现，应用层要继继续拆分。一些固化的，重要的流程用dsl或者编排的方式进行。但是一些灵活的业务串联，就会通过AI来进行关联和匹配，并以AI理解的方式调动整个企业应用系统的执行。也就是说，流程依然存在，但是流程会变得更细和碎片化。用AI组合这些流程，形成最终交付的应用系统形态。

在这种形态中，跨流程会变得更容。但是大而全复杂的流程将会消失。

从这个意义上来说，因为AI的出现，复杂应用比简单应用面临更大的挑战和淘汰的风险。

如果你做ERP的或者做财会的。或者是做MES的小企业，那么恭喜你！小ISV翻身做大的时代又来了。新出现的独角兽一定是AI占很大比重的软件开发企业。

同理。只要能解决并适应业务变化的问题的软件，市场上就会很受欢迎。

之前有一个做etl的企业，做出了一个在网上做流程整合的，叫做Cloud HUB，听说活得不是很好。如果沿着刚才的思路往下延伸，互联网上面向个人的业务整合都瞬间变得有价值起来。