智能化时代：什么才是拥抱大模型的正确姿势

从大模型及软件开发的本质性问题出发的思考

我试图从大模型和软件开发的本质性的问题出发做一些思考。大家知道，现在 ChatGPT 能力相当于3.5，后面4.0，今天 GPT 无法实现的功能，也许在下一个迭代就能实现。因此，我试图从大模型训练本质性过程以及软件工程本质性的困难出发，看看到底有什么不足，几个思考不一定成熟。

思考1：软件开发的规模和复杂性会从人机两个方面形成限制能力

到目前为止，大模型成功的样例仅是数百行代码的软件，而复杂的软件是两三百甚至两三千万行代码的大系统。这时候一个人掌舵全局不太现实。大模型是等着去引导它，对于一个大系统来说，一定需要不断掌舵，最后复杂性使掌舵的人自己都没办法找到正确方向，而且它的过程不是线性的，到了真正的软件开发解决复杂问题，需要画思维导图，为了解决某问题派生出几个子问题，像线程不断 fork。另外大模型对于复杂问题的全局掌控能力可能是有限的，有人说大模型是类似一种贪心法，它的基本预训练过程是预测下一个 token，这样一种局部化的训练过程对掌控全局的能力可能有限。

思考2：大模型缺少抽象思维能力

从形象化的理解来讲，大模型学习方式趋于平面化，它的训练过程就是基于大量文本，这样一种训练方式使得对大范围的抽象设计缺少相应的掌握和应用能力；另外是精确性不足，因为大模型是概率性模型，我们的程序错一个字符，找出这个错误可能要花很多时间。但大模型很容易生成80%-90%的对，甚至95%对，但是差这么一点点，还需要人去把关。

再补充一点，因为需要人来帮忙把关，所以很多传统软件设计观念、方法仍然成立，因为传统模块化信息隐藏就是为了使复杂性能够被掌握，比如说通过分解和抽象之后，阅读某段代码不用去太多考虑其他部分，既然需要人去帮忙检查代码，刚刚讲的这些问题依然存在。

思考3：软件开发中存在大量难以捕捉的暗知识

大家回想一下我们很多的知识都在白板上，我们在白板上的图，可能第三个人看不懂，我们俩边写边画，看完之后各自回去把活干好了，这些东西大模型去哪学？首先没有记录下来，即使记录下、拍了照、录了音，让大模型能理解吗？我们在很抽象层面上做了一点交流，大家懂了，大模型可能是学不到的，而且有些东西非常抽象。

思考4：大模型对复杂系统的维护支持不足

大模型不是一锤子买卖，很多时候，我们编写的代码都是放在一个已有项目的上下文里，这个项目已经存在好多年，你写的是其中一部分，怎么去掌握整个大的软件项目的架构设计，它的各个部分API 等等这些复杂上下文，这些东西我觉得大模型也是不擅长。

02

拥抱大模型正确姿势

首先，我这个保守派也认为应该拥抱大模型，也承认它对我们的影响是颠覆性的。但是我们确实要区分软件类型，比如像我讲的基于云原生平台，平台很厚导致应用层可能很薄，对这样一些系统有可能深层次起的作用还是比较多的。但对大规模复杂性来讲，实现端到端的代码生成还是不现实的。拥抱大模型对于企业来讲是正确甚至是必要的一个方向，但是我们想实现系统和全面的智能化开发还有很多工作去做。

建议1：扎实做好数字化和知识化的积累

很多时候我们依靠敏捷团队相互 review 代码，我们相互很熟悉且信任。什么叫数字化程度？代码为什么改这个地方，犯错的原因能不能追溯一下。某个故障案例，同类的 bug 为什么在公司一遍又一遍的放？我听过好多公司人讲同一段代码公司写了很多遍，我还在写第九遍第十遍（重复实现相同功能）这就不能说数字化程度很好。数字化程度没做好，更不要说知识化了。

以前有个报告说软件开发最大的浪费是知识的浪费、重复思考的浪费。我们经常花时间将一段代码读懂，过一段时间又忘了，或者同事过一段时间花同样的精力将这份代码重读一遍，这就是知识的浪费。这方面工作不做好，指望大模型一步跨越进共产主义，我觉得不现实。不要指望大模型来了，从此以后就可以把码农裁掉一半，我觉得也不太现实。

建议2：重视基本能力建设

契约式设计的发明人，Bertrand Meyer 写了一篇文章认为大模型会复兴软件工程领域的一些根本性的技术，包括需求分析、规格说明和软件验证。

我觉得这些经典的传统技术在大模型时代可能应该会焕发青春，但还是要考虑跟数据驱动大模型技术怎么有机结合，但同时也要结合数字化和知识化基础建设。

建议3：建立大模型/人/工具之间的智能交互引擎

第三个建议更多是学术要探索的事。未来真的想要实现不是30%-50%，而是3-5倍效率提升，一定是要考虑怎么样实现人机协作，人就是我们的开发人员，机包括大模型，但是不只大模型还有各种工具，把他们的能力进行有机融合、高效协同，实现软件开发的超级自动化。

近期好文：

重磅解读：2023 XOps 十大关键词

“DevOps时代”公众号诚邀广大技术人员投稿