AIGC+软件开发新范式白皮书

AIGC+ 软件开发新范式 AIGC+NewParadigmofSoftwareDevelopment 通义灵码系列实战电子书 更多内容， 进入阿里云云原生官方公众号了解 24 20/目录 趋势洞察04 01当「软件研发」遇上AI大模型05 ALIBABACLOUDNATIVE 02谈谈我对AIGC趋势下软件工程重塑的理解20 03微调工程师岗位可能并不存在，但使用AI编码工具已经成为刚需36 AI程序员系列41 04我们团队来了一位新同事，主动要求帮忙敲代码！欢迎AI001号42 05阿里云首个AI员工入职，围观开发工程师使用反馈44 06“AI程序员入职系列”第二弹：如何利用通义灵码光速改写项目编程语言？46 07通义灵码实战系列：一个新项目如何快速启动，如何维护遗留系统代码库？49 08通义灵码牵手阿里云函数计算FC，打造智能编码新体验54 荣耀时刻56 09国内唯一！通义灵码入选全球智能编码助手使用率TOP榜单57 CASESTUDIES 10阿里云参编业内首个代码大模型标准，通义灵码获2023AI4SE“银弹”案例59 趋势洞察 01当「软件研发」遇上AI大模型 大家好，我是通义灵码的产品技术负责人陈鑫。过去有八年时间，我都是在阿里集团做研发效能，即研发工具相关的工作。 我们从2015年开始做一站式DevOps平台，然后打造了云效，也就是将DevOps平台实现云化。到了2023年，我们明显感觉到大模型时代来了以后，软件工具将面临着彻底的革新，大模型和软件工具链的结合，使软件研发进入下一个时代。 那它第一个落脚点在哪？实际上就是辅助编程，所以我们就开始打造了通义灵码这款产品，它是一个基于代码大模型的的AI辅助工具。今天我借这个机会和大家分享通义灵码技术实现上的一些细节以及我们如何看待大模型在软件研发领域的发展。 我会分为三个部分来分享。第一部分先介绍AIGC对软件研发的根本性影响，从宏观上介绍当下的趋势；第二部分将介绍Copilot模式，第三部分是未来软件研发Agent产品的进展。为什么我会提到CopilotAgent，稍后我给大家讲解。 4 —.AIGC对软件研发的根本性影响 这张图是我过去几年画的一张图，我认为企业研发效能的核心影响因素是这三点。 第一点是人员技能。人员技能决定了企业研发效能的一个非常大的因素，比如说谷歌可以招聘到个人能力强于他人十倍的工程师，一个人等同于十个人，那由一群十倍工程师组成的一个小团体，战斗力就很强，甚至可以实现全栈，他们的角色分工可能就非常简单，工作非常高效，最终的效能也非常大。 但是实际上我们企业内部，尤其是中国企业，没有几个能够达到谷歌的水平。这是客观影响因素，我们认为人员技能是效能基石，当然也是效能的破局点。 第二点是协同消耗。在我们不可能要求每个工程师能力强大的基础上，每个人一定是有专业分工的，比如有些做软件设计，有些做开发、做测试、做项目管理。这些人组成的团队随着软件架构的复杂度越来越大，组织的复杂度也会正相关的变大，这就造成了协同消耗也会越来越大，最终拖慢了整体的研发效能。 第三点是成本控制。我们发现做项目的时候人员不可能总是富裕的，永远是缺人手，也不可能有无限的资金去招到十倍工程师，所以这也是一个制约因素。 今天在AIGC的时代，这三个因素已经产生了一些根本性变化。 在人员技能上，通过AI辅助可以快速将一些初级工程师的能力提升。这个其实在国外是有一些报道的，初级工程师使用了代码辅助工具的效果是明显高于高级工程师的，为什么呢？因为这些工具对于初级工作的替代，或者说它的辅助效果是非常好的，所以它可以快速补齐初级工程师的能力短板。 在协同消耗上，如果今天AI能够变成一个超级个体，实际上它对流程协同消耗的降低是有帮助的。比如一些简单的工作就不需要跟人打交道了，AI直接就可以做，也不需要给每个人都讲一遍需求应该怎么测试，AI做简单测试就可以了，这样时间的效率就提升了。所以可以通过超级个体去有效的降低协同消耗。 在成本控制上，实际上AI大量的用法就是代替事务性工作，包括现在用代码大模型去做代码辅助，也是希望代替70%的日常事务性劳动。 那具体来看的话，会有这四个挑战以及智能化的机会。 第一个是个体效率，刚刚也给大家介绍了，大量研发工程师的重复工作和简单沟通都可以通过AI来完成了，它是一个Copilot模式。 另外一个协作效率，一些简单的工作直接让AI做，可以使协同消耗降低，这点刚刚我已经讲述的比较清晰了。 第三个是研发体验，过去DevOps工具链关注的是什么？一个接一个拼成一个大的流水线，拼成整个的工具链。其实每个工具链在不同的企业里可能有不同的使用习惯，甚至有不同的账号体系、不同的界面、不同的交互、不同的权限。这种复杂度给开发者带来了非常大的上下文切换成本和理解成本，这在无形中让开发者其实很不爽。 但是在AI时代发生了一些变化，我们可以通过统一的对话入口，用自然语言的方式去操作很多工具，甚至在自然语言的窗口里解决很多的问题。 我举个例子，比如过去查一个SQL到底有没有性能问题，我们应该怎么办？可能先在代码里面把SQL语句抠出来，把它变成一个可执行的语句，再放到一个DMS系统里面诊断一下看看它有没有用索引，有没有问题，然后再人工判断一下到底要不要改这个SQL去优化它，最后再到IDE里把它变更掉，这个流程需要切换多个系统，要做很多的事情。 那在未来，如果我们有代码智能工具的话，就可以圈选一个代码，问大模型这个SQL有没有问题，这个大模型可以自主的调用一些工具，比如DMS系统去分析，并且拿到的结果可以直接通过大模型告诉我SQL应该如何优化，直接告诉我结果，我们只需要采纳它就可以解决，整个操作链路会被缩短，体验就会提升，从而提升研发效率。 第四个是数字资产，过去大家写了代码放在那都变成了屎山代码或者说是负债，当然里边有非常多优秀的金矿没有被挖掘出来，然后还有很多文档想要找的时候找不到了。 但是在AI时代，我们做的最重要的事之一就是需要去梳理我们的资产以及文档，通过SFT、RAG的方式去赋能给大模型，让大模型变得更聪明，更加符合企业的个性化理解，所以今天这种人机交互方式的变化，会带来体验上的变化。 人工智能从刚刚的几个影响因素再往下拆，它核心是带来了三种人机交互方式的变化。第一种是AI会变成一个Copilot，和工具进行结合，然后人可以指挥它帮我们完成一些单点的工具。到第二阶段，实际上大家应该有共识了，它变成Agent，也就是它具备了一些自主完成任务的能力，包括自主写代码或者做测试。其实工具扮演的是一个多领域专家，我们只需要给定上下文并完成知识对齐即可。第三个阶段我们判断AI可能会变成一个决策者，因为在第二阶段决策者还是人，在第三阶段有可能大模型会具备一些决策能力，包括更高级的信息整合分析能力。这时候人会更多的聚焦于业务的创意和纠偏，很多事情都可以交给大模型做。通过这种不同的人机模式的变化，让我们整体的工作效率会变高。 还有一点是我们刚刚讲到的知识传递形式也发生了根本性的变化。在过去是通过口口相传、通过培训，老带新去解决知识传递的问题。未来很有可能不需要这样，只需要让模型具备业务知识和领域经验，让每一个开发工程师都使用智能化工具，它的这些知识就可以通过工具传导到研发过程中，就会变成右边图上所示的现在DevOps的一站式工具链。积累了大量代码和文档资产后，将这些资产梳理清楚跟大模型放在一起，通过RAG、SFT，模型嵌入到DevOps工具的各个链路，从而又产生更多数据，形成了这样的正向循环，一线开发者在这个过程中就能享受到资产带来的红利或者说能力。 以上就是我从宏观的角度介绍了现在大模型影响研发效率的核心因素，以及两个最重要的形态改变：第一个是人机交互的形态发生了改变，第二个是知识传递的方式发生了根本性变化。现在由于各种各样的技术限制以及大模型发展阶段的问题，我们做的最好的还是Copilot人机交互模式，所以接下来就介绍下我们的一些经验，如何去打造最佳的这种Copilot人机交互模式。 二.打造最佳Copilot姿势 我们认为代码开发的人机交互模式，目前只能解决比如小任务的问题、需要人工采纳的问题、高频次的问题，像代码补全，AI帮我们生成一段，我们接纳一段，再生成一段，再接纳一段，这种频次非常高的问题，还有短输出的问题，不会说一下子就生成一个工程，甚至不会一下就生成一个类，我们每次都是生成一个函数或者几行。为什么要这样来做呢？其实和模型本身能力的限制有很大关系。 因为我们现在上下文宽度还非常有限，假如要完成一个需求，没有办法把所有的背景知识全部交给它一次性搞定，所以要不就是通过Agent去拆成一堆的小任务，逐步解决。要不就在Copilot模式里让它完成一个最简单的工作，比如按照一个注释去生成一小段代码，这样我们叫做解决小任务。 在人工采纳上，人工现在必须对代码大模型生成的结果做判断。目前做的好的可能也就是30%-40%的采纳率，也就是说我们有超过一半的生成代码实际上是不准确的，或者是不符合开发者预期的，所以要不断的消除幻觉问题。 但是让大模型真正能在生产级使用最重要的还是要人工确认，然后高频次是不要生成太多，每次生成一点，因为人工去确认这段代码是否ok的成本也是影响效能的，后文会讲一些我们的思考和我们做的事情，通过高频次去解决准确性率有限问题。另外短输出主要是考虑性能和成本问题。 现在代码助手这种模式，实际上是特别精确的命中了大模型的一些技术限制，才让这样的产品能够快速落地，它有一个非常好的时机。在我们看来，开发者最喜欢的Copilot模式，是以下四个关键词：高频刚需、触手可及、知我所想、唯我专属。 第一个是我们要解决高频和刚需的场景，这才能让开发者觉得这个东西是真的有用，而不是个玩具。 第二个是触手可及，也就是随时可以唤醒它，随时可以帮我们解决问题。不再像以前需要通过各种搜索引擎去搜索代码，它就像在我身边一样，随时可以唤醒它帮我解决问题。 第三个是知我所想，也就是它回答我问题的准确度，以及它在什么时机回答我的问题都是非常重要的。 最后还要为我所属，它能懂我私有的一些知识，而不是说只了解完全开源的东西。我们把这四点具体再展开讨论一下。 高频刚需 我们需要判断什么是软件研发最高频的场景。我这边有一些真实的数据，第一个数据来自JetBrains在2023年做的一个开发者的生态报告，整理了开发者最耗时的活动，其中可以看到百分之七八十都是编写代码，理解代码及互联网搜索、调试、写注释、写测试。这几个场景实际上就是代码智能工具的功能，像通义灵码这样的产品最核心解决的问题，其实就是最高频的问题。 后面这两个数据是通义灵码线上几十万用户的数据分析。我们现在线上采纳的代码，73%来自于补全任务，27%来自于问答任务的采纳。所以今天大量的AI替代人去写代码，还是在IDE的行间生成，这是从真实的情况下反映出来的一个结果。后面是使用问答功能的比例，有76%的比例是来自于研发问答，剩下的10%是代码优化和解释代码等等一系列的代码任务。所以绝大部分的开发者还是在使用我们的工具去问一些常用的研发知识，或者通过自然语言的方式让代码大模型生成一些算法，解决一些小的问题。 其次的23%才是我们真正的一些细节的代码任务，这是给大家一个数据洞察。因此我们就有了核心的目标。第一，我们要解决好代码生成的问题，尤其是在行间生成。第二，要解决研发问题的准确度以及专业性问题。 触手所及 我们最终要讲的是打造沉浸式编程体验，我们希望今天开发者绝大部分的问题都可以在IDE里面解决，而不是需要跳出。 过去我们的体验是什么？是遇到问题去互联网搜索，或者问问别人，问了一圈以后再自己判断，最终写上代码复制放到IDE里面调试编译，不通过了再去查，这样的话就会非常耗时。我们希望能在IDE里面直接问大模型，让大模型帮我生成代码，这样体验就很爽。我们通过这样的一个技术选择，解