以下内容经由SE小助手编辑整理自3月28日SETalk直播间大咖对话：“ChatGPT对软件工程的新机遇”线上沙龙访谈，内容很干货，万字长文，建议收藏和分享给更多关注同学一起来看。点击关注公众号持续获得最新资讯。
正式开场前，我们先来看一段Copilot X的实操视频
编码提效55%，75%开发成就感强！！！实操动手实操Copilot X 五大核心功能体感如何？惊叹非常的丝滑，更有强大的代码刷，test pilot，代码可视化等功能~~
25分钟带你体验ChatGPT for SE的强大！！！，视频时长24:53
ChatGPT对软件工程的新机遇
SETalk系列沙龙
对话嘉宾：
王昊奋 OpenKG联合创始人，同济大学特聘研究员
彭鑫 复旦大学 计算机科学技术学院副院长
茹炳晟（主持人） 腾讯Tech Lead，腾讯研究院特约研究员
看起来非常Impressive，大家一定会觉得“哇”，好像是一个新的时代已经来临，一个极大的生产力解放工具。
先来看看软件研发的流程：
第一：链路非常长
第二：研发工程师的工种越来越细分
第三：从单点的PC桌面软件-->移动端软件-->分布式云端软件-->云原生云边端协同软件。
复杂度越来越高，软件研发的难度越来越大，周期越来越长，成本越来越高，并且Bug的数量会随着增多，很多问题暴露。
Copilot这样一个生产力工具，第一：拉高了下线：很多原来没有能力开发复杂软件的程序员，或者开发复杂软件，代码质量无法控制、非常耗时才能完成的程序员，帮他降低了门槛。低代码和无代码工具都有一定危机了，可能通过Copilot，无代码和低代码时代真正来临了。
第二：虽然有了Copilot工具，像茹老师刚才演示Leetcode代码，是因为大模型见过类似Leetcode代码，并不需要告诉它，要完成什么代码，而只是在Leetcode上面，非常简短的描述，就可以完成。
充分告诉我们，以后在很多研发岗位面试过程当中不要死记背题、刷题，同时数据结构和算法的教育或培训应该发生变化，应该把原来知识型的教授转换成思路型的教授。知识这件事情我们永远比不过大模型，完全可以通过大模型赋予的能力作为我们的外脑来增强。做重复的工作，是最容易被淘汰的。相反，原来不会写代码，但是对需求的表达相对比较清晰、调理，逻辑性比较强的人，对他们绝对是利好的。
以前都说Talk is cheap，Show me the code，现在反过来了，在大模型的支持下Talk is no cheap，动动嘴皮子，模型可以自动帮我们生成Code。
从去年11月底ChatGPT出来，到后面GPT-4，震撼一波接着一波，不断突破我们的想象空间。回顾一下我的感受，最早copilot出来的时候，能够实现整函数，整方法的代码生成，我觉得确实进展很大，但没有那么震惊，因为它看不懂代码，只是按照概率模型生成了一段代码，但这段代码他没法解释，也不会改。但到了ChatGPT，GPT-4就都实现了。像刚才演示的，看得懂代码，你选一行，他就能够给出一个解释。不光企业界开发人员瑟瑟发抖，其实对学术界冲击也很大，说实话我们今年规划的好几个研究就不做了，因为大模型全会了，后续我们要规划怎么去拥抱大模型。
上面演示Copilot X的功能，像leetcode 接雨水还不太能显出他的本事，基本还是片段代码层的能力，这些任务的特点是只要基于当前代码，基本几十行范围内就能搞定，不需要更多其他代码，也不用懂架构设计。其实大模型能做的更多，还有更高级的应用：比如大模型从头到尾一行代码都不写，生成一个俄罗斯方块、或者贪吃蛇，更加震撼，当然这个程序规模不大。
首先像低级程序员肯定就很容易被取代，比如外包。越是这时候，我们越要想经典的一些东西，布鲁克斯在没有银弹那篇文章写过：软件开发的困难分为：accidental和essential。Accidental是偶然的困难，在于怎么把想法用代码表示出来，这部分相对不那么难。另外一种是概念上，需求和设计essential的困难其实更难。
软件工程过去几十年的进展，大多都在accidental层面。比如20多年前我们还没有IDE，用文本文件，直接写Java代码、C代码编译，到后来有了IDE，有很多语法提示，就不用记那么多API了，到现在accidental层面一直在发展。当然今天大模型带来的进展远远比我刚讲那些要大的多。确实一些简单编程任务真的不太需要初级程序员，因为大模型很擅长把非常相似的地方做杂揉和组合。让一部分不会写代码的人也能基于大模型写，把简单劳动和复杂劳动分界线，往上又抬高了一点。像业界资深技术专家，他会很高兴大模型的出现，以前他要配合几个初级程序员一起工作，他设计好后靠初级程序员来实现，完成后可能代码质量还不高，他还得花时间改，最后想法才能得到验证。这个迭代周期是比较慢的，现在有了大模型，初级程序员的工作可以被大模型所取代，这个变化我觉得是显而易见的。
接下来就说哪些是不容易被取代？
就像刚刚讲的大模型不擅长什么呢？我理解不一定对，欢迎拍砖。
大模型不擅长创新性的东西，比如你让他生成个操作系统，解决我们卡脖子问题，他可能也做不到那种很创新，有挑战性的代码。另外一个就是规模和复杂性问题，几百万行大规模的软件系统，可能需要几十个人开发，大模型能干多少事情，特别是在需求和设计层面，在这么大范围的上下文理解能力，是个问号。
大规模的复杂软件架构设计大模型是很难学到的，当然如果给他足够的数据可能也能学会，但设计的数据不是那么容易获得的，我经常把它叫暗数据。我跟腾讯专家也聊过，其实我们很多设计在哪儿呢 ? 白板上的草图，大家靠脑子里经验一画就懂，然后写代码，这些暗数据很难获得。
抽象能力是大模型难学到的，设计跟代码的对应关系是非常抽象的。刚才例子：leetcode 接雨水，大模型马上就把代码生成了，这个例子太完美了，以至于我们会质疑他的能力。如果连我要做什么的需求都讲的很含糊，大模型不来跟我进一步澄清、细聊需求，而是马上就实现了，这样的解决方大家敢用么？这种大概率有两种情况：
第一种情况是这个信息网上到处都有，你提出，他直接就拿过来给你。
第二种就是大模型可能随便给了你个答复，毕竟大模型一本正经胡说八道，也是大家诟病比较多的。
我承认大模型写代码，总体代码质量是非常好的，可能比很多程序员写的都好，因为他看过太多的代码。但问题是：他十句话里藏着一个问题或一句假话，要找到它并且修复它是要花很大功夫的。
大模型的上限是什么？包括Open AI的人自己都不知道。对比ChatGPT和GPT4的上下文的大小，ChatGPT差不多是4,000 token，GPT4是32k token。32K token是什么概念？差不多25,000个词，50几页的A4纸的word文档。GPT-4演示的过程当中，是希望把模型做大，把上下文做长，把各种各样可能使用到的数据都充分利用上，使它产生各种各样神奇的能力，包括涌现，形成很多复杂问题分解的思维链等。像彭老师讲的，通过多轮引导生成俄罗斯方块或贪吃蛇，可以给大模型更长的上下文，从而更容易地学习和记住相关的模式和规则。这种情况下，只需要一种机制，能够将多个关联的上下文进行合并，就可以让大模型更加系统化地使用这些知识，向前迈进一大步。
我们一直诟病大模型是生成式的，一本正经胡说八道，可能也没有时效性。最简单的，现在用ChatGPT，基本上就用Chrome里面的插件web ChatGPT，大家基本都知道，现在的ChatGPT有自己的plugin，很大一部分是在解决增强式的语言模型。
第一点：增强使用工具的能力
像copilot，还是copilot X，不管什么版本，在这个过程当中他会使用各种各样的CICD、代码编译、运行甚至发布等。
第二点：增强推理能力
随着上下文的增加，推理能力一定会有更大的容量，只是我们并不知道，这个容量到底是能走两步还是三步，还是直接就从需求到最终的部署模型、应用。
第三点：ACT的能力
它可以有更多的行为和动作，增强式的语言模型会随着ChatGPT的plugin催生很多东西。现在已经不是Open AI在做这件事情，而是全世界的开发工程师都在帮他，所以ChatGPT出来之后，为什么有很多像ChatPDF的应用。
比如以前开发Linux级别复杂的代码，我们需要神级程序员，现在有了LLM之后它的能力也是与时俱进，适用性越来越强，让中等或者相对有一定年资的工程师有机会逼近神级程序员，相当于他们用了外挂，使他变的更强。这样情况下会出现很多超级个体，通过人机协同，我们就能完成规模比较复杂的软件。一旦有更复杂的模型，更好的软件催生出来，现阶段的瓶颈和天花板其实就会被打破，拉高了我们的下线。另一方面是极大的拉高我们的上限，原来可能是周或者天级别，现在就是分钟秒级别。
研发人员具备的需求解读能力和需求翻译能力，还有需求分解能力，架构能力，我觉得这件事情大模型不是那么容易做。大模型时代一个新的工种：提示工程师，引导模型生成一些东西，激活它，启发它，在这个过程当中进行需求分解，架构引导，将很多抽象的内容进行具象，或者往具象的方向引导。不同水平的人，最后即使用了同样的大模型，同样的工具，可能产生的质量是不一样的。原来的资深研发人员甚至包括架构师、需求分析的人，他们可能会类似于现在大模型提示工程师，成为大模型时代软件开发提示工程师，产生新的细分岗位和需求，我们需要与时俱进。
第一点
大模型生成的Code，要做Code Review，找到他当中可能存在的错误其实也要花很多时间。
第二点
现阶段很多资深提示工程师生成文案和编剧这样的内容，其实你要输入给他的东西一点都不比他生成的东西少，最后数据量可能也是2到3倍，只是把你从原来的工作转到了其他方面
你极度依赖他，对他的结果极度相信，结果他给你埋了一个坑，最后导致产生了很不好的后果；另一种是你极度不相信他，他生成的代码越多，软件构建越多，用来验证和review的代价并没有完全被消减。
大模型可以看做是一种新型IDE，使得我们现有的工作变得简单，透明。
编程趋势的变化，最早机器代码，到汇编到高级语言，到面相对象，发展脉络就是编程的抽象层面越来越接近人的思维方式而远离机器。最早的软件程序是要解决充分利用机器资源的问题，越接近机器越高效，后面随着硬件逐渐的发展，逐渐变成解决人的复杂性问题，所以刚刚讲的用自然语言驱动变成好像是很自然的趋势。
未来趋势是统一门户，目前软件开发的一个很大问题是上下文切换，需要不断地在不同的应用程序之间切换，如搜索网页、查看Word文档、打开聊天工具等。大模型可以通过建立统一的门户，将这些不同的应用程序统一管理和交互，从而解决上下文切换的问题，这种方式可以使开发人员更专注于他们的应用程序开发。
AI技术的发展我们要始终保持敬畏，我跟我们团队老师和学生讨论，经常讲要想一想这个技术路线的天花板。哪些会成为天花板呢？
第一点：人会成为瓶颈
以俄罗斯方块为例 ，一个人一个小时，一行代码不写通过大模型生成俄罗斯方块，那是因为俄罗斯方块的复杂性比较小，他脑子里对整个俄罗斯方块程序的整体复杂性有完整的掌握，每一步给的提示都非常恰当，当这个软件规模变成几百万，几千万的代码，人会不会成为瓶颈？
第二点：Code review
编译器的输入是高级语言的代码，高级语言本身有严格的语法，编译的翻译过程也非常严格。但是大模型用自然语言驱动是概率性生成，无法保证精确性。现实的软件需要多人评审，协调工作。大模型生成的代码还是需要强调可读性和可理解性。
大模型难以完全接管复杂软件项目，因为有很多暗知识，需要静下心来把研发数字化和知识积累做起来。软件开发最大浪费是知识的浪费，需要重复思考的浪费。
从自然语言到代码这种翻译是概率性的,而且需求可能本来就没讲清楚，如果你很有经验，我跟你讲了一个需求，你可能在动手写代码之前会先确认需求，再写代码。但是大模型可能他就按照他理解的直接生成了，会给你带来误解。即使AI能力再发展，精确性也无法保证。
关于设计方面，我认为需要帮助大模型做研究和探索，比如挖掘软件工程中的暗知识并数字化喂给大模型。此外，需要先打好软件工程的基础，做好研发数字化和知识沉淀，才能更好地利用大模型。
建议将系统建成之后，通过特定的工具或流程将Feature到Task任务，包括Bug，Code Commit以及后续的持续集成全过程拉通，并以特定的格式方式喂给大模型。这样做可以帮助大模型更好地理解需求，从而提高生成的代码质量。
大模型来了之后，对我们学术界冲击很大，之前我们规划的研究：做代码解释就不做了。现在大模型提示词可能很长，长到比写代码还要费劲，那我们软件工程研究的就是如何自动化那些原来只有高手能写的东西，让普通人也能用。可能做的就是把提示词自动化，做一个管道工具，在用户的IDE界面和大模型之间做双向沟通，同时还能结合知识图谱，提出更好的问题，做更好的提示，这个工具还能掌握很多提示模板，和大模型打交道。对工业界来讲，这方面再加强能让AI的能力能迸发的更好。
现在关键问题是如何将单点的能力串成完整的流水线，实现企业级的大规模软件开发，并能够比较系统化地使用它。像复用code reviews，局部软件复用一点都不难，难的地方在怎么让整个软件基于复用开发，从偶然性的局部复用扩张到系统性的复用。
大模型怎么变成项目级的生产力工具，变成一个大平台，我觉得还是有很长的路要走。
目前有三大派
第一派：LLM for SE
就是我们今天在聊的重点，怎么利用大模型的强大能力来解放生产力，或者说简化软件工程的流程。
第二派：SE for LLM
LM已经形成生态，包括LLM自身在模型生产过程当中，MLOPS机器学习研发、训练、部署、运营一体化，在LLM过程中变得非常严苛，涉及到多级多卡情况，它的复杂程度远比我们想象的高很多。大模型不仅有数据，代码，在模型训练的微调和推理之外还有新物种，例如 Hugging Face 中的 Hub 模块，怎么对他进行有效的管理，就需要SE更好的设计。还有LLM模型的中间件，做模型的路由、评估， prompt提示的优化，和外部第三方工具的编排。这些都是我们在云原生软件工程过程当中 微服务、Devops带来的价值。
到后面人变成了瓶颈，因为人的memory是有限的，适合在小数据上面。在LLM开发中，确实需要一些工具和方法来简化记忆、分工和协同，以适应大规模代码的生产。在现代软件工程当中我们这些工具都有，开发人员可以使用这些工具和方法来更好地管理和维护代码，从而更好地适应大规模代码的生产。
复杂软件的开发和 AI系统开发的人的思维方式不完全一样，很多能做AI系统开发的人理解的复杂性，和我们软件的复杂性是两种不同的复杂性，所以说这两种复杂性是需要进行叠加、甚至乘积才能产生更复杂、更高效的，AI驱动复杂软件的迸发和成熟。
第三派 LLM as SE
模型的出现确实会对软件工程的链路和条例带来一定的挑战，在某些特定领域，中间态的过程其实没有必要了，端到端的开发方式，不需要做code review，使得开发人员能够更加专注于业务逻辑的实现。但是不可能在所有的情况产生，为什么：
- 第一， 没有记载过的，数据永远不可能做组合泛化的情况，大模型一定是追随者的角色。
对于大多数人，在整个研发工作年限中，复杂度达不到上限的情况下，确实就是LLM as SE，直接从需求到产品，这样的情况在一些相对可控和简单的软件或明确、能充分习得的地方是可以产生的。 - 第二，用生成式大模型从需求到最后生成软件是不是完全不靠谱的东西？它毕竟是一个完全基于概率语言模型。Yann LeCun一直在抨击说我们现在自回归了只用解码器的一种大模型会产生非常大的diverse和不可控的因素，例如answer set的长度和多样性，但在大多数情况下，他的多样性和可变性没有这么多的情况，此外，生成式大模型的生成结果也可能受到编码器、解码器和其他因素的影响，因此我们希望它是在一个确定的，明确语义的空间里。
我们唯一需要对生成式模型做出的改变是可控生成。可控生成有两种：- 第一种：自然可控，它逃离出去的可能性非常小，永远在如来佛的手掌心里面，那基本上我们就可以放心的将这些工作交给他。完全的安全和完全可控制这件事情是不需要追求的，但是他需要在一个很小的概率里面。
- 第二种：需要给生成式大模型增加更多的知识，特别是暗知识，使其能够根据约束和设计产生更好、更高质量、可控的生成。这将是我们后续重点发展的方向。第一什么叫暗知识，第二暗知识怎么表示，第三暗知识不是数字化的，仅通过专家提示是不是一个最高效的方式、即使他是最高效的，我们也通常需要多轮迭代来优化模型。这里面有大量的不确定性和各种可能性，不同的可能性会带来效果有非常大差别，需要通过最佳实践、理论指导和证明来约束和证明。
- 第三，大模型的一个重要限制是其成本，很多情况他所产生的价值还不如招一些程序员划算。
做即时战略时候到底是发展科技术去造出高级兵种，还是用很廉价的低级兵种去抱兵做群海战术，我觉得这件事情是留在我们软件工程面前一个新的话题，企业需要权衡投入产出比。
我们也知道60分到90分和90分到100分， 90分到100分花的代价会高很多。所以千万不要因为大模型现在能做到一些东西，就完全拥抱大模型，不需要人了。也不要变成完全悲观，无视技术的发展，我们应该进入到当中的量子纠缠态，叠加态，让各种情况都出现。刚刚讲到的需求分解，架构设计，我觉得这件事情永远逃不掉，只是说是从一种表达方式变到了另一种表达方式。大方接受它，这样的心态更利于我们理性看待大模型，给软件工程带来新的机遇和变革。
首先是测试还有界面设计，测试经常有图片要处理，当然还有界面设计本来就有图，多模态的应用能做的很好，把美工画的界面设计稿，自动转换为前端代码，实现多模态的应用，像阿里等等有些企业已经有这种工具。
我以前上需求工程的课，当时一本书里提到,场景描述的创造层次是可以逐步提升，最详细或创造层次最低的是录像，把录像喂给大模型读，读完之后是不是可以转成结构化的场景表示。我感觉普通软件跟多模态相关的不算特别多，能想的基本是跟UI有关的。当然一种例外，像机器人，他是在物理学中存在的，他本来就是个多模态的交互模式。
在LLM出现之后，在应用大模型方面走的最激进的细分领域之一是RPA（机器流程自动化）。为什么？
第一点 RPA原本是一种自动化技术，但是为了让它能够更好地理解和执行任务，需要将其与多模态技术结合使用，将场景描述转换为结构化的流程，并将API调用等任务转换为可重复执行的结构化流程，这一定是多模态相关的。
其实炳晟刚刚讲的也存在，GPT 4最强的东西是在于做非自然图像的理解，特别是对于图表。例如，它可以通过嵌入在Word文档、PPT或其他文字工作中，帮助解决原本RPA难以解决的文档智能处理问题。现在，GPT 4可以通过Document AI技术，非常好地解决这一问题。非自然图像蕴含了很多领域知识，暗知识，对大模型来说，这种暗知识是人通过类似于提示的东西引导或者增强他。
另一方面，为什么先是语言模型迸发出来，因为语言是包含知识最密集的非自然信号。虽然视觉和语音也包含信息，但由于动物也具备类似的能力，其中包含的信息密度不够高，因此在理解方面存在一定的局限性。而非自然图像包含的信息量相对于自然图像丰富很多，特别是领域知识的信息，通过增强这些内容，有望让人类更充分地理解。
大模型另一个很重要的点就是对也错，对的就是GPT-4，它可能是涂鸦或草稿画了一些东西，然后它被称为sketch to code或sketch to HTML，加上CSS和JS的代码。这件事情本身并不稀奇，因为chat GPT或大模型做的所有这些东西我们都曾经做过，甚至在一些评测的benchmark数据集上比那些好。如果我们按照原来刷Sota的角度来说，它可能还不如以前，那为什么我们这么兴奋？因为单一的模型解决了很多成千上万的任务，它的通用性决定了这一切，所以从这个角度来说，软件工程如果始终要在很多界面和上下文中切换，没有统一的门户情况下，这件事情一定是会被某种技术或某种范式颠覆的。大模型正好利用AI的理念，成为支撑万物的基座。
数据管理和数据治理过程中有很多任务是使用GPT进行数据补全、清洗、纠错和理解等，以前需要使用ETL完成这些任务，现在GPT可以通过自然语言处理进行这些任务，从而使得数据管理和数据治理变得更加高效。我们需要大模型可控的生成结构化的内容，这件事情已经发生了，大家可以看到一些新型的数据库非常积极地拥抱大模型。甚至之前的Augmented BI就是增强式BI，能帮你做一些聚合、分析、扩充清洗等等，原来的数据链路不仅是建模，过程当中所有内容都会像原来的代码和自然语言处理一样重新的进行复盘，有些任务可能用LLM直接就做完了，或者LLM与原来的方法结合可以达到前所未有的高度。
我补充下LLM to Code，要看不同的应用类型，像上层应用，自然语言驱动，包括刚刚讲的只review功能就够了，举个例子比如我有很多场景，把一些资源API都封装好，只要编排API就能够完成应用，像智能家居，智能座舱。但是也有很多应用涉及非常详细的代码，还有复杂逻辑，目前看让大模型做的精确还是很难的。
比如说严格确定性的数值运算和和逻辑推理的话，用大模型即使他能做，其投入产出比和性价比其实是非常低的。
思维链有两个不确定性和挑战
- 第一件 当模型的参数量达到600亿及以上时，才会产生思维链的涌现。
- 第二件 一般来说，视觉大模型的参数量约为百亿，而语言大模型的参数量约为千亿。因此，当我们看到一个1,750亿的GPT时，它的规模非常庞大。另外，像Palm的参数量约为5,400亿，而Golfer的参数量差不多为2,600亿。DeepMind的大模型规模与此类似，其思维链推理长度约束在2跳左右，勉强能达到3跳。对于复杂的任务，人类可能需要对其进行分解或进行递归或迭代调用，以使其能够在一个可承受的搜索空间内完成任务。在这种情况下，不要过于依赖大模型，还是要依靠自己的经验和知识来启发它，就像知识注入一样。我们可以通过引导、注入和引导之间的协同来实现更好的效果。这个问题还没有一个完全定论，需要进一步探索和研究。
我认为测试代码的自动生成或测试脚本的自动生成有两个层面。一个层面在文字层面，它可能会列出一些测试场景、测试方法，相当于它能够枚举出一些测试的case，并自动生成测试代码。但这个地方有一个主要问题是Oracle的问题，也是整个过程中很难的一件事，Oracle最终还是需要人工的确认。
- 第一层面：方法论层面
就是让你可以在设计测试用例时有一些方法论上的支撑。这可以帮助你避免一些常见的问题，如测试场景单一、测试方法过于简单等。通过让你考虑多样性和边缘情况，你可以更好地覆盖整个应用程序的各个方面。 - 第二层面： 框架式测试用例
它实际上是在这个过程中形成了一些框架式的测试用例，这些测试用例中会有一些占位符（placeholder），它们并不代表它们可以直接执行，但只需进行微调或简单修改，就可以解决自身的重复性劳动和代码本身的问题。 - 第三层面：如果代码本身的取值范围已知，那么在采样过程中可以非常均匀地进行采样，使得生成的测试用例能够覆盖整个应用程序的各个方面。但是对于代码中不确定的部分，需要进行人工确认。这个过程相对来说不难，但需要一定的知识和经验。
我认为小模型一定需要，现阶段基于大模型加原来软件工程会产生很多设计模式，大模型加小模型，很重要的在于加上私域流量，本地或者离线的知识做增强的过程当中一定是需要小模型，不仅仅是prompt 提示，甚至是需要小模型或其他的组件来帮助你。
office 365的copilot提到几个东西非常需要
-
- 第一件 Your data，你的数据怎么开始应用
- 第二件 中间是office copilot，旁边是GPT4大模型，下面是微软的图谱Microsoft graph。
Microsoft graph在数据通过prompt方式和大模型交互，生成和产出过程当中，做你本身prompt的引导，prompt的细化和扩展，以及对于整个结果过程去做granding。不光是一个组件，一定是需要一个组合去解决问题。
所以说小模型不会没有，他一定会更多，甚至因为有很多开源，大家都训得起或者调得起的模型。国内大家都在大练各种各样的中型模型，在本地部署，性价比和很多方面能达到一个折中或者权衡。然后又能跟saas上面公开可访问的大模型结合，甚至已有的一些确定性的工具，包括数据库工具、搜索引擎的工具等等，形成LLM时代新的一些design pattern，提升生产力
马上预约:【返场篇】ChatGPT对软件工程的新机遇
