（1）

数据结构+算法=程序。

每个学计算机的人都听过这个公式。

这个公式是尼克劳斯沃斯在1976年出版《算法+数据结构：程序》一书中提出。尼克劳斯沃斯还是Pascal编程语言的发明人，而且他还在1973年出版《系统程序设计导论》一书中提出了“结构化程序设计”这一概念。尼克劳斯沃斯是瑞士人，在苏黎世工学院上完本科后又到加拿大莱维大学取得硕士学位，后又到美国加州伯克利大学取得博士学位，博士毕业后担任斯坦福大学计算机系教授。

（2）

可能是在中国，也可能是在中国企业应用软件业，这个公式得修订一下，应该是：

数据结构+业务逻辑=程序。

业务有多复杂，程序代码就有多复杂。程序就相当于现实业务的一个快照、电子翻版。现实业务变化了，程序就必须变化。所以中国定制化项目特别多，其实本质都是自己带球让球把自己给绊倒了。

我是一路从程序员-技术总监-CTO过来的。我过去做程序员时，我负责的那个系统算是核心系统，和很多其他系统有关联性，其他系统老需要更新我所属系统的数据表中的状态值，这样就导致了其他系统只要有业务逻辑变化，我的系统就必须要随之改代码，甚至我的系统会出现异常。

后来我觉得这样干不是个事，于是我就写了一个状态机，而且还把状态机的配置放在外面配置文件中。这样，遇到其他系统业务逻辑变化时，我就不需要改我的系统，我的系统也一直保证稳定不出异常了，而且只需要改一下配置文件即可，很灵活。

但是很不幸，我后来去做平台基础研发去了，接任维护的程序员打开我的代码一脸懵逼，现实业务他理解，但是他理解的现实业务，在我的代码中没有看到对应的程序逻辑，他在脑海里形不成这两者的映射关系，他没法下手修改代码。

我曾经甚至还想过用AOP模式和IOC模式来彻底解决问题，但是因为我转去做平台研发了所以我就没再动了。后来我想了想，绝大多数程序员都不知道啥叫AOP模式和IOC模式，我的代码倒是非常稳定了，但是他们也不会维护了。

我再说一个事，是去年发生的。我和一个下属过去讨论一个业务场景，我叨逼叨说了一大堆业务的介绍，我这个下属眨巴眨巴眼睛说：这不就是个偏导函数么？

对，在别人眼里那是业务逻辑，在他眼里就是偏导函数。

我们老提应用架构，其实应用架构重点包含两方面：一方面就是把业务抽象成模型，最好抽象到能用数学公式来推导、解释，这样就会保证严密完备、简单、稳定。另一方面就是设计好模块与模块、系统与系统之间的集成接口，让接口设计的稳定并可向下兼容。

（3）

从2015年以来，第三次人工智能热潮在中国兴起。

数据结构+算法=程序这个公式，又需要修订修订了，我提出的是：数据+模型=程序。

从数据结构升级到数据，从算法升级到模型。

数据结构和数据的分别，大家很好理解，相当于骨架和肉的关系。

而算法带有因果性，模型带有相关性。因果性和相关性这是两个完全不同的东西。

所以，从2018年以来，设计模型，越来越重要了。但啥叫模型，模型设计的常用方法有哪些，你知道吗？

（4）

从2018年Google提出Transformer和预训练模型以来，我感觉：数据结构+算法=程序这个公式又得改改，应该改成：预训练模型=程序。

也就是说：模型即程序。

大家看2019年Open AI Lab公布出来的GPT-3巨模型，你可以用它搞很多应用任务。

在人工智能时代，数据是隐私不能泄露，模型是核心也是要保密，但数据+模型被预训练后，就炼成了一个最终的巨模型，可能整个模型就是高达几十T的文件，你既看不到数据也看不到模型，你只能用它。而且由于部署这个巨模型、运行这个预训练巨模型，消耗的资源和算力太高，所以巨模型未来的商业模式就是公有云提供服务。Huggingface现在就在探索这条路。

所以以后的程序员在写算法呢，还是在写业务逻辑代码呢，还是在设计模型呢，还是在训练模型呢？你们说呢？

（5）

预训练模型这个套路现在还不好。因为海量数据一旦炼成知识，这个预训练模型就算版本化固定了。如果你还想加入新的知识，你还需要再预训练。

我理想中的套路应该是：海量数据随着业务的发生，通过万物互联IoT源源不断送进模型，这个模型持续不断地增量训练，利用各种学习模式（如对比学习、强化学习等等）持续不断地自我优化，这就成了活的模型和活的程序，这样就不用像现在中国的企业应用软件程序员，现实业务变就必须业务逻辑代码变。