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

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