2024年AIGC+软件开发新范式白皮书.pdf

AIGC+软件开发新范式AIGC+New Paradigm of Software Development通义灵码系列实战电子书2024ALIBABA CLOUD NATIVECASE STUDIES/目录010409趋势洞察AI 程序员系列荣耀时刻02051007030608当软件研发遇上 AI 大模型我们团队来了一位新同事，主动要求帮忙敲代码！欢迎 AI 001 号国内唯一！通义灵码入选全球智能编码助手使用率 TOP 榜单谈谈我对 AIGC 趋势下软件工程重塑的理解阿里云首个 AI 员工入职，围观开发工程师使用反馈阿里云参编业内首个代码大模型标准，通义灵码获 2023 AI4SE“银弹”案例通义灵码实战系列：一个新项目如何快速启动，如何维护遗留系统代码库？微调工程师岗位可能并不存在，但使用 AI 编码工具已经成为刚需“AI 程序员入职系列”第二弹：如何利用通义灵码光速改写项目编程语言？通义灵码牵手阿里云函数计算 FC，打造智能编码新体验0542570441562044594936465454第一点是人员技能。人员技能决定了企业研发效能的一个非常大的因素，比如说谷歌可以招聘到个人能力强于他人十倍的工程师，一个人等同于十个人，那由一群十倍工程师组成的一个小团体，战斗力就很强，甚至可以实现全栈，他们的角色分工可能就非常简单，工作非常高效，最终的效能也非常大。但是实际上我们企业内部，尤其是中国企业，没有几个能够达到谷歌的水平。这是客观影响因素，我们认为人员技能是效能基石，当然也是效能的破局点。当 软件研发 遇上 AI 大模型趋势洞察大家好，我是通义灵码的产品技术负责人陈鑫。过去有八年时间，我都是在阿里集团做研发效能，即研发工具相关的工作。我们从 2015 年开始做一站式 DevOps 平台，然后打造了云效，也就是将 DevOps 平台实现云化。到了 2023 年，我们明显感觉到大模型时代来了以后，软件工具将面临着彻底的革新，大模型和软件工具链的结合，使软件研发进入下一个时代。那它第一个落脚点在哪？实际上就是辅助编程，所以我们就开始打造了通义灵码这款产品，它是一个基于代码大模型的的 AI 辅助工具。今天我借这个机会和大家分享通义灵码技术实现上的一些细节以及我们如何看待大模型在软件研发领域的发展。我会分为三个部分来分享。第一部分先介绍 AIGC 对软件研发的根本性影响，从宏观上介绍当下的趋势；第二部分将介绍 Copilot 模式，第三部分是未来软件研发 Agent 产品的进展。为什么我会提到 Copilot Agent，稍后我给大家讲解。01这张图是我过去几年画的一张图，我认为企业研发效能的核心影响因素是这三点。一.AIGC 对软件研发的根本性影响76趋势洞察第三个是研发体验，过去 DevOps 工具链关注的是什么？一个接一个拼成一个大的流水线，拼成整个的工具链。其实每个工具链在不同的企业里可能有不同的使用习惯，甚至有不同的账号体系、不同的界面、不同的交互、不同的权限。这种复杂度给开发者带来了非常大的上下文切换成本和理解成本，这在无形中让开发者其实很不爽。但是在 AI 时代发生了一些变化，我们可以通过统一的对话入口，用自然语言的方式去操作很多工具，甚至在自然语言的窗口里解决很多的问题。我举个例子，比如过去查一个 SQL 到底有没有性能问题，我们应该怎么办？可能先在代码里面把 SQL 语句抠出来，把它变成一个可执行的语句，再放到一个 DMS 系统里面诊断一下看看它有没有用索引，有没有问题，然后再人工判断一下到底要不要改这个 SQL 去优化它，最后再到 IDE 里把它变更掉，这个流程需要切换多个系统，要做很多的事情。那在未来，如果我们有代码智能工具的话，就可以圈选一个代码，问大模型这个 SQL 有没有问题，这个大模型可以自主的调用一些工具，比如 DMS 系统去分析，并且拿到的结果可以直接通过大模型告诉我 SQL 应该如何优化，直接告诉我结果，我们只需要采纳它就可以解决，整个操作链路会被缩短，体验就会提升，从而提升研发效率。第四个是数字资产，过去大家写了代码放在那都变成了屎山代码或者说是负债，当然里边有非常多优秀的金矿没有被挖掘出来，然后还有很多文档想要找的时候找不到了。但是在 AI 时代，我们做的最重要的事之一就是需要去梳理我们的资产以及文档，通过 SFT、RAG 的方式去赋能给大模型，让大模型变得更聪明，更加符合企业的个性化理解，所以今天这种人机交互方式的变化，会带来体验上的变化。人工智能从刚刚的几个影响因素再往下拆，它核心是带来了三种人机交互方式的变化。第一种是 AI 会变成一个 Copilot，和工具进行结合，然后人可以指挥它帮我们完成一些单点的工具。到第二阶段，实际上大家应该有共识了，它变成 Agent，也就是它具备了一些自主完成任务的能力，包括自主写代码或者做测试。其实工具扮演的是一个多领域专家，我们只需要给定上下文并完成知识对齐即可。第三个阶段我们判断 AI 可能会变成一个决策者，因为在第二阶段决策者还是人，在第三阶段有可能大模型会具备一些决策能力，包括更高级的信息整合分析能力。这时候人会更多的聚焦于业务的创意和纠偏，很多事情都可以交给大模型做。通过这种不同的人机模式的变化，让我们整体的工作效率会变高。第二点是协同消耗。在我们不可能要求每个工程师能力强大的基础上，每个人一定是有专业分工的，比如有些做软件设计，有些做开发、做测试、做项目管理。这些人组成的团队随着软件架构的复杂度越来越大，组织的复杂度也会正相关的变大，这就造成了协同消耗也会越来越大，最终拖慢了整体的研发效能。第三点是成本控制。我们发现做项目的时候人员不可能总是富裕的，永远是缺人手，也不可能有无限的资金去招到十倍工程师，所以这也是一个制约因素。今天在 AIGC 的时代，这三个因素已经产生了一些根本性变化。在人员技能上，通过 AI 辅助可以快速将一些初级工程师的能力提升。这个其实在国外是有一些报道的，初级工程师使用了代码辅助工具的效果是明显高于高级工程师的，为什么呢？因为这些工具对于初级工作的替代，或者说它的辅助效果是非常好的，所以它可以快速补齐初级工程师的能力短板。在协同消耗上，如果今天 AI 能够变成一个超级个体，实际上它对流程协同消耗的降低是有帮助的。比如一些简单的工作就不需要跟人打交道了，AI 直接就可以做，也不需要给每个人都讲一遍需求应该怎么测试，AI 做简单测试就可以了，这样时间的效率就提升了。所以可以通过超级个体去有效的降低协同消耗。在成本控制上，实际上 AI 大量的用法就是代替事务性工作，包括现在用代码大模型去做代码辅助，也是希望代替 70%的日常事务性劳动。那具体来看的话，会有这四个挑战以及智能化的机会。第一个是个体效率，刚刚也给大家介绍了，大量研发工程师的重复工作和简单沟通都可以通过 AI 来完成了，它是一个 Copilot 模式。另外一个协作效率，一些简单的工作直接让 AI 做，可以使协同消耗降低，这点刚刚我已经讲述的比较清晰了。98趋势洞察还有一点是我们刚刚讲到的知识传递形式也发生了根本性的变化。在过去是通过口口相传、通过培训，老带新去解决知识传递的问题。未来很有可能不需要这样，只需要让模型具备业务知识和领域经验，让每一个开发工程师都使用智能化工具，它的这些知识就可以通过工具传导到研发过程中，就会变成右边图上所示的现在 DevOps 的一站式工具链。积累了大量代码和文档资产后，将这些资产梳理清楚跟大模型放在一起，通过 RAG、SFT，模型嵌入到 DevOps 工具的各个链路，从而又产生更多数据，形成了这样的正向循环，一线开发者在这个过程中就能享受到资产带来的红利或者说能力。以上就是我从宏观的角度介绍了现在大模型影响研发效率的核心因素，以及两个最重要的形态改变：第一个是人机交互的形态发生了改变，第二个是知识传递的方式发生了根本性变化。现在由于各种各样的技术限制以及大模型发展阶段的问题，我们做的最好的还是 Copilot 人机交互模式，所以接下来就介绍下我们的一些经验，如何去打造最佳的这种 Copilot 人机交互模式。因为我们现在上下文宽度还非常有限，假如要完成一个需求，没有办法把所有的背景知识全部交给它一次性搞定，所以要不就是通过 Agent 去拆成一堆的小任务，逐步解决。要不就在 Copilot 模式里让它完成一个最简单的工作，比如按照一个注释去生成一小段代码，这样我们叫做解决小任务。在人工采纳上，人工现在必须对代码大模型生成的结果做判断。目前做的好的可能也就是30%-40%的采纳率，也就是说我们有超过一半的生成代码实际上是不准确的，或者是不符合开发者预期的，所以要不断的消除幻觉问题。但是让大模型真正能在生产级使用最重要的还是要人工确认，然后高频次是不要生成太多，每次生成一点，因为人工去确认这段代码是否 ok 的成本也是影响效能的，后文会讲一些我们的思考和我们做的事情，通过高频次去解决准确性率有限问题。另外短输出主要是考虑性能和成本问题。现在代码助手这种模式，实际上是特别精确的命中了大模型的一些技术限制，才让这样的产品能够快速落地，它有一个非常好的时机。在我们看来，开发者最喜欢的 Copilot 模式，是以下四个关键词：高频刚需、触手可及、知我所想、唯我专属。二.打造最佳 Copilot 姿势我们认为代码开发的人机交互模式，目前只能解决比如小任务的问题、需要人工采纳的问题、高频次的问题，像代码补全，AI 帮我们生成一段，我们接纳一段，再生成一段，再接纳一段，这种频次非常高的问题，还有短输出的问题，不会说一下子就生成一个工程，甚至不会一下就生成一个类，我们每次都是生成一个函数或者几行。为什么要这样来做呢？其实和模型本身能力的限制有很大关系。1110趋势洞察第一个是我们要解决高频和刚需的场景，这才能让开发者觉得这个东西是真的有用，而不是个玩具。第二个是触手可及，也就是随时可以唤醒它，随时可以帮我们解决问题。不再像以前需要通过各种搜索引擎去搜索代码，它就像在我身边一样，随时可以唤醒它帮我解决问题。第三个是知我所想，也就是它回答我问题的准确度，以及它在什么时机回答我的问题都是非常重要的。最后还要为我所属，它能懂我私有的一些知识，而不是说只了解完全开源的东西。我们把这四点具体再展开讨论一下。高频刚需我们需要判断什么是软件研发最高频的场景。我这边有一些真实的数据，第一个数据来自 JetBrains 在 2023 年做的一个开发者的生态报告，整理了开发者最耗时的活动，其中可以看到百分之七八十都是编写代码，理解代码及互联网搜索、调试、写注释、写测试。这几个场景实际上就是代码智能工具的功能，像通义灵码这样的产品最核心解决的问题，其实就是最高频的问题。后面这两个数据是通义灵码线上几十万用户的数据分析。我们现在线上采纳的代码，73%来自于补全任务，27%来自于问答任务的采纳。所以今天大量的 AI 替代人去写代码，还是在 IDE 的行间生成，这是从真实的情况下反映出来的一个结果。后面是使用问答功能的比例，有 76%的比例是来自于研发问答，剩下的 10%是代码优化和解释代码等等一系列的代码任务。所以绝大部分的开发者还是在使用我们的工具去问一些常用的研发知识，或者通过自然语言的方式让代码大模型生成一些算法，解决一些小的问题。其次的 23%才是我们真正的一些细节的代码任务，这是给大家一个数据洞察。因此我们就有了核心的目标。第一，我们要解决好代码生成的问题，尤其是在行间生成。第二，要解决研发问题的准确度以及专业性问题。触手所及我们最终要讲的是打造沉浸式编程体验，我们希望今天开发者绝大部分的问题都可以在 IDE 里面解决，而不是需要跳出。过去我们的体验是什么？是遇到问题去互联网搜索，或者问问别人，问了一圈以后再自己判断，最终写上代码复制放到 IDE 里面调试编译，不通过了再去查，这样的话就会非常耗时。我们希望能在 IDE 里面直接问大模型，让大模型帮我生成代码，这样体验就很爽。我们通过这样的一个技术选择，解决了沉浸式编程体验的问题。补全任务是一个性能敏感型任务，它的输出需要在 300 到 500 毫秒，最好不要超过一秒，所以我们有一个小参数模型，它主要是用来生成代码的，而且它的大部分训练语料也来自于代码。它虽然的模型参数很小，但是在代码生成的准确度上非常高。第二个我们要去做好专项任务，我们还有 20%30%实际上的任务是来自于这些，包括注释生成、单元测试、代码优化、运营错误排查等七项任务。我们目前使用了一个中等参数模型。这里主要考虑的，一是生成效率，二是调优。一个非常大参数的模型，我们调优的成本是很大的，但是在这种中等参数模型上，它本身的代码理解和代码生成效果已经不错了，所以我们选择了中等参数模型。然后在大模型上面，尤其是我们 70%多的研发问题回答上，我们追求的是高精度，而且追求的是实时的一些知识。所以我们通过一个最大参数的模型，叠加了我们的 RAG 技术，让它外挂了一个近乎于实时的基于互联网的知识库，所以它回答的质量和效果就非常高，并且能大幅消除模型幻觉，提升回答质量。我们通过这样的三个模型支持了整个沉浸式编程的体验。1312趋势洞察第二点是我们要实现多端，因为只有覆盖了更多的端，才可以覆盖更多的开发者。目前通义灵码支持 VS code 和 JetBrains，主要解决的是触发问题、展示问题，还有一些交互性问题。最核心层次下面，我们本地 Agent 服务是一个独立的进程。这个进程跟上面的插件之间会进行通信。这个进程最主要解决的是代码核心的一些能力，包括代码智能补全的部分，会话管理的部分，智能体。此外，语法分析服务也非常重要，我们要解决跨文件引用的问题等，都需要语法分析。如果我们要做本地的检索增强，我们还需要轻量级的本地向量检索引擎。所以整个后端的服务实际上是通过这样的方式就可以快速的实现扩端。我们还有一个特色，我们有一个零点几B的本地离线的小模型，来实现个别语言的单行补全，这是可以脱网去做的，包括 JetBrains 最近也上了一个跑在本地的小模型。通过这种方式，也会保证我们的一些数据安全隐私问题，比如本地的会话管理、本地的存储，全部都放到了本地电脑上。知我所想知我所想对于 IDE 插件这个工具而言，我认为有几点。第一是触发时机，在什么时候触发，对于开发者体验的影响也非常大。比如我在空格的时候要不要触发？IDE 已经生成提示的时候要不要触发？在删除这段代码的时候要不要触发？我们大概有超过 3050 个场景去梳理，到底在这个场景上要不要进行代码触发，这部分通过规则就可以搞定，只要一点点细心去摸索，去调研开发者体验，就可以解决，这不是很高深的技术。但是在代码生成长度方面，我们认为是比较难的。因为在不同的编辑区的不同的位置，它生成什么样长度代码，直接影响了我们的体验。如果开发者只是倾向于生成单行代码，带来的问题就是开发者不能理解整个生成的内容，比如生成一个函数，他不知道这个函数到底要干什么，生成一个 if 语句，他不知道 if 语句里边的业务逻辑是什么，就没有办法完整的判断功能单元，影响了他的体验。我们用一些固定的规则去做，也会导致一个问题，即它会比较死板。所以我们的做法实际上是基于代码的语义信息，通过训练的方式，经由大量的样本，让模型理解了今天在什么场景下应该生成多长，我们实现了由模型自动判断类级别、函数级别、逻辑块级别及行级别的生成力度，我们把它叫做自适应的生成力度决策。我们通过做这项大量的预训练，让模型去感知，从而提升了生成的准确度，这块我们认为也是一个比较关键的技术项。再往下最关键的就是如何去消除模型的幻觉，因为只有幻觉得到足够的消除，才能够提升我们的采纳率。所以我们一定要实现基于库内的跨文件上下文感知，在这里，我们做了很多的基于代码的语义分析，引用链追踪，相似代码以及动态语言类型推导等。最关键的就是想方设法的去猜开发者在这个位置补全他可能需要什么样的背景知识，这些东西可能还会涉及到一些语言、框架、用户习惯等，我们通过各种各样的东西将它的上下文获取出来，并且进行优先级排序，把最关键的信息放到上下文里面去，然后给到大模型进行推导，让大模型去消除幻觉。通过这样的技术就可以实现跨文件上下文感知的测试集，我们的准确率从 22%提升到了 66.9%，我们还在不断的去精进提升补全的效果。1514趋势洞察最后一个是我们本地的库内检索增强。刚刚其实也说了，上下文感知也只是猜测开发者在触发位置的上下文。更多的场景是今天开发者要问一个问题，让大模型基于本地的库内所有文件去帮我解决一个问题，比如帮我修复一个 bug，帮我增加一个需求，帮我填充一个文件，自动实现增删改查，甚至帮我的 Prompt 文件增加一个新的包的版本，类似这样的需求其实有很多，要实现的话实际上是要给大模型外挂一个检索引擎。因为我们不可能把整个工程的文件全部塞给大模型，因为上下文宽度的影响，我们必须使用到一个技术，叫做本地的库内检索增强。这个功能就是来实现我们基于库内的自由问答的，在本地去建立一个库内的检索增强服务，我们判断这样的方式对于开发者的体验是最好的，安全性也是最高的。代码不需要上传到云端，就可以完成整个链路。从整个链路上来讲，开发者问一个问题以后，我们就会去代码库提取需求的关键信息进行任务拆解，拆解完了做本地的向量检索召回，然后再做检索的结果合并及重排，以及去企业内部的数据知识库检索，因为企业有统一的知识库管理，是企业级的。最终把全部的信息汇总起来发送给大模型，让大模型去生成和解决问题。在这里我列了一些简单的场景和需要注意的事项，包括代码应该怎么处理，文档应该怎么处理，代码过来要进行过滤、清洗、结构化，然后才能够可用。在我们训练的过程中，要去考虑开放域数据和私域数据的混入。比如我们要去做一些不同的参数调整，在检索增强上，我们要考虑不同的检索增强策略，我们其实也是在不断的进行探索，包括如何在代码生成场景里面命中我们所需要的上下文信息，以及我们在问答场景里面如何去命中我们需要的回答的上下文信息，这属于检索增强。唯我专属我觉得企业要想让代码大模型真的能实现一个非常好的效果，都逃不过这一关。比如如何实现企业数据的个性化场景，比如在项目管理阶段，如何能够让大模型按照需求/任务/缺陷内容的一些固有的格式和规范去生成，帮我们实现一些需求的自动拆解、自动续写、自动总结等等。开发阶段可能是大家最关注的，经常有企业会讲要有符合企业自己的代码规范，引用企业自己的二方库，调用 API 生成 SQL，包括使用企业自研的一些前端框架、组件库等等，这些都属于开发场景。测试场景也要生成符合企业规范的，甚至是理解业务的测试用例。在运维场景，要时刻查找企业的运维知识，然后去回答，去获取企业的一些运维的 API 快速生成代码。这些都是我们认为要做的企业数据化个性化场景。具体的做法是要通过检索增强或者微调训练的方式来实现。1716趋势洞察我们要做的就是企业级的检索增强方案，企业级的检索增强方案目前的架构图大概是这样。中间是知识库的管理服务，包括数据解析的调度、问题的理解、整理回答、结构化的解析、数据分块等等，核心的能力在中间这块，向下是我们比较常用的 Embedding 的服务，包括大模型的服务、向量的存储和检索。向上是我们管理的一些后台，在这个场景下支持了我们关于文档的检索增强以及代码生成的检索增强。代码生成也就是补全这个场景的检索增强它所需要的处理方式和技术跟文档其实还是略有不同。过去我们跟复旦大学也做过几年的学术研究，非常感谢他们的付出，我们也有一些论文在发表，当时我们测试集的结果也是用一个一点几 B 的模型，再配合检索增强，它实际上的准确率和效果就可以达到一个大概 7B 以上模型的同等效果。三.未来的软件研发 Agent 产品演进我们认为未来软件研发一定会进入到 Agent 时代，也就是说它具备一些自主性，并且它可以非常容易使用我们的工具，然后理解人类的意图，完成工作，最终会形成一个如图所示的多智能体的协同模式。就在今年三月份，Devin 的诞生其实让我们感觉到这个事情真真实实的被加速了，我们从来没有设想到这个事情能够完成一个真实的业务项目，我们过去都没有想象到，甚至我们都觉得这个事情可能还要一年以后，但是它的出现让我们觉得，今天真的可以通过大模型拆解数百上千个步骤，并且一步一步执行，出现问题它还可以自我反思，自我迭代，有这么强的拆解能力和推理能力让我们非常意外。随着 Devin 的诞生，各个专家学者就开始投入，包括我们通义实验室，马上发起的一个项目叫 OpenDevin。这个项目在短短的几周内 star 数就超过了 2 万，可以看到大家对这个领域非常的热情。然后马上开源了 SWE 的 Agent 项目，把 SWE-bench 的解决率又推升到了 10%以上，过去的大模型都在百分之几，推升到 10%已经接近了 Devin 的表现，所以我们判断在这个领域的学术研究会非常快，我们大胆猜测一下，很有可能在 2024 年年中左右的 6 到 9 月份，很有可能 SWE-bench 的解决率会超过 30%。我们大胆猜测一下，如果能够达到百分之五六十解决率的话，它的测试集实际上是一些真实的 Github issue，让 AI 完成 Github 上面的 issue，可以去修复 bug，去解决需求的这样一个测试集。如果这个测试集能够让 AI 的自主完成率达到百分之五六十，我们认为真的是可以在生产级中落地了。至少一些简单的缺陷可以交给它来修复，这是我们看到的目前业界的一些最新的进展。1918这个产品图会分为三层。最下面是基础层，对于企业来讲，可以先把基础层做好。比如现在可以引入一个代码大模型，我们虽然没有马上实现 AI Bot，但是现在已经具备了 IDE 代码生成插件的这些能力，已经可以做一些工作了，就是 Copilot 的模式。Copilot 模式在基建层上面，进化了 Agent 这一层，实际上基建是可以复用的。该做的检索增强、微调训练和知识库，现在就可以做起来了。这些知识的梳理，资产的积累，是来自于原来 DevOps 平台的积累。现在就可以通过一些提示词工程的方式，将现在基础的能力层跟整个 DevOps 工具链进行结合。我们做了一些实验，在需求阶段要想让这个大模型来实现一个需求的自动拆解，我们可能只需要将过去的一些拆解数据，还有现在的需求拼成一个 prompt 给大模型，大模型就可以比较好的去完成拆解并且完成人员的分配。在实验中发现，结果的准确率还是蛮高的。其实现在整个 DevOps 工具链，并不需要所有东西都要用 Agent 或者都要用 Copilot。我们现在用一些提示词工程，就有很多场景可以马上去赋能，包括我们在 CICD 过程中的自动排错，在知识库领域的智能问答等都可以实现。在实现多 Agent 以后，这个 Agent 可以在 IDE 里面透出，也可以在开发者的门户，即 DevOps 平台透出，甚至在我们的 IM 工具里面透出。它实际上是一个拟人的智能体。本身这个智能体它会有自己的工作区，在这个工作区里我们的开发者或者说管理者可以去监控它到底是如何帮我们完成代码编写的，如何帮我们完成测试的，它到底在互联网上获取了什么样的知识去完成工作，会有一个它自己的工作空间，最终实现整个任务的完整流程。趋势洞察但是这张图也不是马上就能实现的，现在从技术路线上来讲，我们会沿着这四步逐步实现。第一步我们现在还在做单库的问答 Agent，这个领域是非常前沿的，我们现在在做单库的问答 Agent，近期会上线。下一步我们希望推出能独立完成编码任务的 Agent，它的作用主要是具备一定的自主规划能力，可以使用一些工具去了解背景知识，能够自主的完成单库范围内的编码任务，还不是跨库，可以想象一个需求有多个代码库，然后前端也改、后端也改，最终形成一个需求，我们觉得还很远。所以我们先实现单库的编码 Agent，下一步我们会去做测试 Agent，测试 Agent 可以基于代码 Agent 的生成结果，自动完成一些测试任务，包括理解任务的需求、阅读代码、生成测试用例，并且自主运行。如果这两步的成功率做的比较高的话，我们就会进入到第三步。让多 Agent 基于 AI 调度共同完成任务，从而实现从需求到代码到测试的全流程自主化。从工程的角度来讲，我们会一步一步这么来走，确保每一步都达到一个比较好的生产级落地，最终去做产品。但是从学术来讲，他们研究的速度会比我们更快，现在我们是从学术、工程讨论的，我们还有第三个分支就是模型演进。这三条路就是我们现在阿里云和通义实验室一起联合在做的一些研究。最终，我们会形成一个 Multi-Agent 概念架构，用户可以跟大模型进行对话，大模型可以进行任务的拆解，然后有一个多 Agent 协同系统。这个 Agent 可以外挂一些工具，它有自己的运行环境，然后多 Agent 之间可以互相协同，它们还会共享一些上下文机制。2120趋势洞察谈谈我对 AIGC 趋势下软件工程重塑的理解今天给大家带来的话题是 AIGC 趋势下的软件工程重塑。今天这个话题主要分为以下四大 部分。第一部分是 AI 是否已经成为软件研发的必选项；第二部分是 AI 对于软件研发的挑战及智能化机会，第三部分是企业落地软件研发智能化的策略和路径，第四部分是我们现有的可采纳的、可落地的工具，在这一部分我也会重点介绍通义灵码整体的产品能力和概况。这张图是麦肯锡最近发布的一个研究报告，大家可以看到他把软件工程列在了整张表格的右上角，也就是影响最大、影响速度最快的一部分。他为什么会有这样的观点？这是因为在大模型时代，我们发现大模型在代码生成和整体的逻辑推理方面是特别擅长的，所以涌现出了类似 Github Copilot 这种非常有代表性的智能编码工具，可以瞬间提升大量企业开发工程师的研发效率，而且 Copilot 是至今为止在世界范围内商业化最成功的大模型的领域之一。这位美国的 KOL，他也有同样的观点。他认为在大模型时代，可能有大量的技能会被替代，我们 10%的技能会被 1000 倍的提升，这个跟我们的观点是相似的，尤其是在大模型时代，大模型可以大量地替代开发者的日常事务性工作，这部分的占比很可能超过 70%，让开发者得以聚焦于剩下 30%的业务和技术的创新。这张图给大家展示的是前一段时间 JetBrains 的一个调研报告，他们在 26500 名工程师之间做调研，想看一下今天有多少开发者已经开始熟练地使用生成式 AI 工具，这份调研也出乎很多人的意料，调研显示，现在 84%的开发者已经在或多或少地使用生成式人工智能工具了。02这张图是我过去几年画的一张图，我认为企业研发效能的核心影响因素是这三点。一.AI 已经成为软件研发的必选项2322趋势洞察这张图也是微软针对 Github Copilot 用户发放的一份调研问卷，了解他们使用类似 AIGC 的代码助手对整个的研发效率或者说研发体感有多少提升，可以看到有很多指标都是 80%以上的，或者接近 80%。其实我们也针对通义灵码的使用者发放过类似的调研问卷。有超过 80%的用户都感觉到使用工具以后生产力有了大幅的提升，跟这个调研报告也非常吻合。根据前面的调研报告和后面相关的调研数据，大家可以看到，在世界的开发者范围内，AI 已经成为了开发者的必选项，我们软件研发的未来一定是 AI 驱动的场景。其中有哪些场景是开发者最耗时，也是最想提效的场景？他们在这里也做了一个调研，就如左图所示，首先是编码场景，然后是理解代码，接着是互联网搜索，也就是查询各种各样的研发问题，以及进行调试、编码注释、写测试、代码评审等等一系列的工作。这张图大家可以看到，有哪些场景是 AI 助手辅助频率最高的？有以下几个：第一个是使用自然语言去询问软件开发的一些问题，包括生成代码、生成代码注释、解释代码、生成测试等等。其实大家可以发现这一个调研的结果跟上一个其实是非常吻合的。也就是说在我们最高频的场景下，AIGC 其实能起到非常关键的作用。这也是为什么代码智能生成工具已经逐步成为了每个企业必须采用的一项产品的原因。二.软件研发挑战及智能化的机会2524个操作入口。第四，是数字资产的提升。过去企业内部有很多优质的代码、框架、规范等等，很难瞬间交给开发者，让每一个开发者去遵守。接下来我们会将这些数字资产利用检索增强或者微调训练的方式跟大模型结合起来，不断地在大模型上积累这些资产，而不是使现在产生的代码成为负债，这些积累的资产可以让软件工程师的效能进一步提升。通过这样的方式形成正循环，就可以大幅提升研发效率。在上图的右侧，大家可以看到每一项的改进，实际上都在解决软件研发的一些本质复杂性。比如说一致性问题、可变性问题、复杂性问题和一些知识显性化问题等等。因此我们认为，AI 对于软件研发的影响是深刻的，尤其是在未来 3 到 5 年，软件研发的流程和软件研发范式会出现颠覆性的变化。趋势洞察在 2023 年 6 月，我们组织过一次大规模的专家研讨会，在这个研讨会上大家都在讨论智能化未来对软件研发或者软件工程领域的深刻影响。在这个会上，我们有位专家提出了一个观点，他认为软件工程是人类历史上第一次大规模的集体智力的协作活动，它本身是有本质的复杂性在的。例如人月神话的作者所讲的，他认为软件本质的复杂性是现在软件系统中无法规避的内在特性，比如复杂度、一致性、可变性和不可见性。在过去的若干年，为什么软件效能或者说研发效率提升非常困难，就是因为这些维度没有得到非常好的解决。今天在大模型时代，通过 AI 逐步地去替代人类的事务性工作后，它可以起到非常大的改进作用。我们总结下来有以下四大方面。大模型目前已经在深刻的改变智力协作模式，比如说现在常见的代码翻译，从我们的自然语言进行编程，像一些简单的需求，现在可以直接让大模型完成编码。但是现在复杂的业务需求还没有办法完成。不过随着大模型技术的发展，解决这个需求其实就是时间问题。第二个是知识检索。在海量的知识里，通过对话的方式可以快速地找到相关知识，由大模型输出，变成顺滑的自然语言。第三个是头脑风暴。其实这是现在开发者最常用的功能之一。比如使用通义千问时，让它给我写个算法，然后不断的纠正它，让它按照我的意图去修改代码，最终就会形成一个可以直接拿来用的代码片段，这个大家现在已经用得很熟练了。第四个是大模型非常擅长的整理归纳。我们可以用它来整理我们的需求、整理文档和知识，这四种模式实际上已经在改变我们的智力协作模式。第一，是对个体效率的提升。例如我们可以采纳类似 AI 的智能代码助手，它可以大幅的代替研发人员的重复性工作、简单性工作。我们认为它是一种 Copilot 的模式，辅助各个角色去提升自己的工作效率。第二，是对协作效率的提升。因为有很多专业的分工，它们之间存在一些效率的竖井，互相沟通协作的一些偏差等等。当 AI 逐步地去替代事务性工作，并且形成了 AI 为主、人为辅的编程模式的时候，大家会发现一些角色的分工可能会出现模糊化。比如产品经理写完了需求，是不是可以马上交由 AI 去完成大量的编码工作，然后由工程师进行校验，测试人员进行简单的测试回归，AI 也可以起到非常重要的测试作用，接下来就可以顺利的发布上线。如果是这样的一个以 AI 为主、人为辅的模式，其实人和人之间的沟通协同问题就可以很好地解决。第三，是研发体验的提升。在大模型时代，我们会构建软件研发的智能化大脑。这个大脑的表现可能是一个对话框，或者是一个对话形式。这个对话框会成为我们很多操作工具的入口。比如现在大家会发现，IDE 这种智能编码插件，它也有对话框，有 IDE 的编码，这就会成为我们写代码的一个入口。同样在我们原来的 DevOps 工具上，也会有这样一个对话的入口。在这个入口里我们可以完成很多工具的操作，解决很多问题。它有效地使现有的工具散乱问题得到了解决，统一了整2726趋势洞察第二个我们认为它在向纵深去拓展，更深度的去接管编码过程。比如 Github Next 上面的一些项目，我们可以看到未来的一些趋势。比如让大模型去预测下一个编辑位置，让大模型直接完成需求到代码的自动编写以及我们甚至可以通过自然语言描述的方式，让大模型编写好一个框架，直接生成整个代码，也就是说实现自然语言编程。这些在业界都有相应的探索，大家有兴趣的话可以去看相关的 Demo，还是非常酷炫的。第三个是我们认为现在已经在逐步的向横向扩展，也就是说会贯穿到 DevOps 的整个链路。比如可以用大模型进行辅助的文档查阅、生成评审、辅助编写，大模型已经开始逐步渗透到软件工程的各个领域。看到这张图，我们可以跟过去十年的软件工程模式说再见了。因为在过去，我们一直追求的是整体的 DevOps 全链路一站式体验以及构建效能洞察数据体系，去找到效能改进点，不断推进研发效能提升。在未来十年，我们认为是以大模型为驱动的智能化软件研发体系，也就是有智能化的软件研发工具链，及大语言模型和相关的数字资产，再配合智能的决策辅助，去帮助企业大幅提升软件研发效率以及突破现有的效能瓶颈。在未来，我们主要有以下三种方式可以和 AI 进行协同。第一种是聊天模式，可以和 AI 聊我们的需求架构、编程思路，让它给我相应的建议。第二种是实时模式，在编码过程中大模型可以在背后给我相应的辅助，它是实时性的，帮我发现错误、推荐代码。第三种是伴随模式，也就是它随时随地可以被召唤出来完成一些事务性工作。比如帮我们做代码评审、异常排查等等，这三种模式会成为未来的主流。从技术的角度来看，我们也认为会有以下三大趋势。第一个是基础模型的变化，越来越长的推理上下文以及越来越大的参数量。其实现在 GPT4、GB3.5、GB4 都是非常大的千亿级的参数，包括现在的通义千问、通义灵码也是如此。随着模型的参数量越来越大以及推理上下文越来越长，模型它能感知的知识以及它能处理的任务会越来越复杂。现在它可能还只是完成一些简单的编程任务，在未来很有可能会完成复杂需求的编写。三.企业落地研发智能的策略对于企业而言，在这个 AIGC 或者说大模型爆发的时代，应该如何去落地研发智能化，它的路径和策略是什么？2928趋势洞察在需求阶段、编码阶段、集成测试阶段、发布部署阶段、咨询学习阶段、效能管理阶段等各个阶段实现智能化升级。首先可以在编码阶段进行切入，逐步向测试阶段、发布部署阶段进行扩展。像一些和需求与业务连接的复杂场景，可以放到最后去进行提升，通过这种方式逐步落地，最终实现端到端的智能化改造。接下来我讲一些简单的场景，给大家参考。例如我们可以实现智能的项目管理，可以实现细化需求，拆分子需求，智能的指派负责人，拆分任务等等，这些工作都可以交给 AI 来做。在这里我们推荐企业采用三个阶段来逐步构建研发的智能化。阶段一，可以先引入 DevOps 基础大模型去构建研发智能大脑。如我们通过编码场景，在 IDE 的编码助手的场景中进行落地。为什么我们会选取这个场景？是因为我们发现大模型目前的技术瓶颈，还没有办法实现一些非常复杂的大面积的编码。但是在跟人类 pair 的场景下，它就可以起到非常好的作用。比如说代码续写，圈选一段代码去进行单元测试生成、代码注释生成，这些都非常擅长，而且它的效果也非常好。所以说我们认为可以在这个场景先进行切入，先去落地，取得最大的效能红利，我们把这个过程叫做 Landing。阶段二，我们建议是以长期效率为核心，持续的治理和构建个性化数据。也就是说要实现企业的模型个性化，提供全量、全要素的数据，比如优质的代码数据，优质的业务文档数据，将这些数据收集起来，构建企业个性化的数据集。再通过检索增强或微调训练技术跟大模型结合起来，构建一个企业私有的研发大脑。我们把这一步叫做 Growth。阶段三，要以大模型为中心，完成整个研发工具链的智能化升级。比如将研发领域的各种工具都接入大模型，进行智能化的整体改造，实现端到端的智能化，进一步的代替各种研发工程师的事务性工作，我们把这一步叫做 Expanding。从阶段一、阶段二到阶段三，循序渐进的这种模式是我们比较推荐的。现在一般企业都有整体的软件研发的全生命周期管理的工具链，也有沉淀出来的企业非常好的一些数字资产。将数字资产跟大模型结合，进一步去赋能工具链，然后工具链又可以正向地产生更多的资产，因此形成一个循环，让效能越来越高，这就是我们期待的一个模式。3130趋势洞察我