SETalk精彩回顾：ChatGPT对软件工程的新机遇上篇

正式开场前，我们先来看一段Copilot X的实操视频  

编码提效55%，75%开发成就感强！！！实操动手实操Copilot X 五大核心功能体感如何？惊叹非常的丝滑，更有强大的代码刷，test pilot，代码可视化等功能～～

主持人（茹炳晟）: 

像Copilot，Copilot X这样的工具的普及对我们的软件工程师来讲意味着什么？

换句话说，当这些工具普及之后我们工程师会不会失业呢？

会不会有很多原来的工作都被机器做掉了呢？

从中短期来看,这些工具到底对我们的研发的流程有什么样的影响? 

相信很多人看完之后也都满脑类似这样的问题，下面就请我们直播间两位大咖专家，王昊奋老师，彭鑫教授一起来聊聊，和大家共探LLM时代无限可能，我们Opentalk开放聊，形式不设限。

对话嘉宾 ：王昊奋 OpenKG联合创始人 同济大学特聘研究员 / 彭鑫 复旦大学  计算机科学技术学院副院长

昊奋老师：首先这个工具肯定是看起来非常Impressive，大家一定会觉得“哇”，好像是一个新的时代已经来临了，它是一个极大的生产力解放工具。

 先来看软件本身的研发的流程：

主持人（茹炳晟）:  大模型出来之后程序员会不会下岗？一线工程师有了这种工具，是变得更忙，还是更轻松？

彭鑫教授：从去年11月底ChatGPT出来，到后面GPT-4，震撼一波接着一波，不断突破我们的想象空间。回顾一下我的感受，最早copilot出来的时候，能够实现整函数，整方法的代码生成，我觉得确实进展很大，但没有那么震惊，因为它看不懂代码，只是按照概率模型生成了一段代码，但这段代码他没法解释，也不会改。但到了chatgpt，gpt-4就都实现了。像刚才演示的，它看得懂代码，你选一行，他就能够给出一个解释。不光我们企业界开发人员在那里瑟瑟发抖，其实对学术界冲击也很大，直白一点，我们今年规划的好几个研究就不做了，因为大模型全会了，我们要规划怎么去拥抱大模型。

上面演示Copilot X的功能，像leetcode 接雨水还不太能显出他的本事，基本还是片段代码层面的能力，百度上都有，比较像高级百度的功能。这些任务的特点是只要基于当前代码，基本几十行范围内就能搞定的事，不需要更多其他代码，也不用懂架构设计就能搞定这些。

其实大模型能做的更多，还有更高级的应用让我印象更深刻：之前一个沙龙群，张刚老师试过从头到尾一行代码都不写，生成一个俄罗斯方块、或者贪吃蛇，更加震撼。从一句句和它聊天，开始画个框，再加一些规则，写个碰撞、旋转，从界面不断完善，慢慢的引导，确实不用写一行代码它就可以把一个程序给写出来，当然这个程序规模不大。

首先像低级程序员，比如外包，20年前对日的软件外包，日本的客户连SQL语句都帮你写好的这种，肯定就很容易被取代。

越到这个时候，越是我们要想经典的一些东西，布鲁克斯在没有银弹那篇文章写过：软件开发的困难分为：accidental和essential。Accidental是偶然的困难，在于怎么把一个想法用代码表示出来，这部分相对不那么难。另外一种是概念上的，需求和设计essential的这部分的困难其实更难。软件工程过去几十年的进展，大多数都在accidental层面。比如20多年前我们还没有很好的IDE，那时候还用文本文件，直接写Java代码、C代码编译，到后来有了IDE，有很多语法提示，就不用去记那么多API了。到现在accidental层面一直在进展，当然今天大模型带来的进展远远比我刚讲那些要大的多。确实首先一些简单编程任务真的不太需要太多初级程序员，因为大模型很擅长把非常相似的地方做杂揉和组合。让一部分不会写代码的人也能基于大模型写，把简单劳动和复杂劳动分界线，往上又抬高了一点。

原来有些我们认为属于复杂劳动，需要专业人员才能做的，现在可能不需要了。像业界资深技术专家，大模型的出现他会很高兴，以前他肯定要配合几个初级程序员一块工作，他把设计想好之后，等着他们来实现，实现后可能代码质量还不咋地，还得花时间改，最后他的想法才能得到验证。这个迭代周期是比较慢的。

现在有了大模型，初级程序员的工作大概率会被大模型所取代，这个变化我觉得是显而易见的。

接下来就说哪些是不容易被取代？

就像刚刚讲的大模型不擅长什么呢？我理解不一定对，欢迎拍砖。

大模型不擅长创新性的东西，比如你让他生成个操作系统，解决我们卡脖子问题，他可能也做不到那种很创新，有挑战性的代码。

另外一个就是规模和复杂性问题，特别大规模的软件系统，到目前为止，大模型出来之后大家很乐观，我其实还是比较保守的，我们还是要想一想，比如一个几百万行代码的复杂软件系统，可能需要一个团队几十个人开发，那大模型能干多少事情，特别是在需求和设计层面，大模型在这么大范围的上下文理解能力，还是个问号。刚刚演示几个例子，他不需要了解太多的项目上下文，单个文件差不多就能把活干了。我只要把这段代码秀给你，你可能马上就能看到这段代码哪里写的不对，哪里格式不好，来帮你调对吧，不需要懂整个项目的业务上下文，或者是整个架构设计。

所以我觉得大规模的复杂软件的架构设计它其实是很难学的，当然如果给他足够的数据可能也能学会。但重点是设计的数据不是那么容易获得的，我经常把它叫暗数据，我跟腾讯专家也聊过，其实我们很多设计在哪儿呢，在白板上，白板上画了个草图，然后大家靠着脑子里的经验一画就懂了，然后去写代码。这个大模型是不好学的，不能假设说只要有数据。

另外一个：抽象能力是大模型比较困难的，我们的设计是非常抽象的，他跟代码的对应关系非常抽象。刚刚演示的例子，比如增加一个控制条输出或者是写的不好地方，这些都是代码层上比较扁平的，没有太多抽象。其实也有人试过用大模型做需求分析，比如给它一个需求，做一个聊天功能或者做一个BBS，它能帮你细化出一些功能，那是因为这种应用很多，那种简单，常规的功能它能帮你输出来的。刚才例子：帮我把leetcode 接雨水写出来，马上就把代码生成了。这个例子太完美了，以至于我们会质疑他的能力，因为连我要做什么都讲的很含糊需求，他就全干了，这事不得打个问号么。就像我提出一个很模糊的要求，你不来跟我慢慢的澄清，不来跟我聊聊需求，一下把解决方给我，你觉得解决方我能敢用吗？

所以大概率是两种情况：

第一种情况是这个玩意网上到处都有，你提出，他直接就拿过来给你。

第二种就是他可能随便给了你个东西，因为大模型一本正经胡说八道，这个也是大家诟病比较多的。

大模型写代码，它代码质量总体是非常好的，这个我承认，可能比很多程序员写的都好。因为他看过太多的代码，但问题是他十句话里藏着一个问题，也有可能十句真话藏一句假话。在对话过程中它经常这样，那么在代码里面也是，可能有一两个bug，但这两个Bug你要找到它并且修复它是要花很大功夫的。

主持人（茹炳晟）:

总结：现在的ChatGPT或者LLM类大模型在软件工程上基本能解决很多单点的提效，但是不能解决软件工程的问题，不能解决架构设计的问题。

但是从本质上来讲，就光这一点单点的效能提升，他也带来了很多可能性。

像刚才讲的人月神话，软件的两个复杂度：一个本质复杂度，一个随机复杂度

随机复杂度真正来自于规模，规模又分软件本身的规模，还有就是人的协作沟通的规模。

软件做到后面越来越难做，成本越来越高，边际收益越来越低。一个主要原因是因为后面做不快了，团队太大，整个沟通成本变得非常高。如何能够让一个研发团队始终维持在一个比较小的规模上，能用这种小团队的这种范式去做软件演进的话，这个其实是有可能的。

以前软件规模大，小团队是做不了的，但是现在，很多单点的能力都可以用Copilot、LLM大语言模型去做单点生成，人更像一个架构师去做更有高瞻远瞩的工作。 

……未完待续，敬请期待ChatGPT对软件工程的新机遇下篇