百度 Comate 提升编码效率，释放 10 倍软件生产力

XXQ2024年03月11日约 8 分钟

各位线上的开发者朋友们，今天我的分享主要分为四个方面。

首先是 AIGC 发展和 Comate 落地的大背景；
第二是百度 Comate 以及它使用的相关技术；
第三是 Comate 在百度内部的落地情况和使用效果；
最后，展示一个实际的 case 让大家去感受下百度 Comate 在实际工作中是如何帮助大家进行开发和协同的。

软件研发领域的变革实际上一直都在进行。人们始终都在以「高效、智能和持续演进」的理念来指导软件的发展。

随着技术的不断提升，软件开发的门槛正在逐步降低。二十年前，我们实现一段代码可能会需要用到汇编语言，再往前更多年的时间我们可能会用到纸带打孔这样非常古老的方式来进行编程。而现在，由于有足够先进的现代语言、开发工具和足够简单的依赖框架，开发者的开发工作逐渐变得简单，程序开发也朝着「体力活」的方向去演进。

但是，当开发门槛降低，大量从业人员涌入后，软件质量并没有出现正比增长。

第一个的原因在于，程序员在开发过程中会受到各种各样客观因素的影响（如工期太紧、实现太困难或者是缺少资源依赖），并不能把自己最好的一面展示出来，很多时候不得不向现实妥协一些东西。有时，开发者也会直接将外部代码放到自己的代码中。这些外部代码对项目来说可运行，但是并不具备可维护性。

另一方面，对于初级开发者人员来说，他们希望精进自己的技术。而最简单、最直接的办法就是去实现 Util。我们发现，在开发者社区里面有很多同样功能的类，或者同样的代码片段去实现类似的能力。但这些代码的质量有高有低，效果并不尽如人意。

回首过去的技术积累，我们发现，AIGC 在内容生成领域在引领着一次又一次的变革。在十年前，AI 能够帮助我们生成一小段新闻稿，比如说一场球赛，谁传球给了谁、谁得分了这样的一些简单的描述。到了近几年，AIGC 的能力有了质的突破，具备了在逻辑上进行思考的能力。在绘画、音乐、视频等领域，AI 也逐渐渗入，极大释放了内容生产者的相关工作，内容的生产方式也逐渐发生质的变化。

那 AIGC 能否帮助开发者更简单、高效地生成代码，提升研发效率呢？在回答这个问题之前，我们需要思考一个问题：代码究竟是什么？本质上来说，代码是一组构建计算机程序的指令，即计算机所执行的命令。换句话说，代码并不是机器可直接去运行的指令，也不是人可直接去理解的文字，而是人和机器交流的中间语言。因此，它需要满足语法严格、结构固定、有迹可循这三个标准。

首先解释下语法严格。代码的语法规则实际上相较于自然语言是更加严格的。对汉语来说，汉字所出现的位置并不影响阅读者对于一段话的理解。但对于代码来说不行。int 1=a 和 int a=1 是两个完全不同的概念，前者是完全不可编译，计算机不可理解的。

其次是结构固定。如果在代码中出现了 else，那前面必然会有 if，它不能单独存在，代码结构一定符合某种规律。

最后是有迹可循。当开发者要实现某个功能，比如说要对一组数进行排序。我们自然而然会想到要用快速排序、冒泡排序或者归并排序。当开发者想去设计一个多样类的结构时，自然而然会考虑到用设计模式。为什么会这样？因为前人已经帮我们总结好了很多的经验，在处理某一类问题的时候，已经有很多现成的解决这类问题的方法和沉淀下来的经验。而这才是我们去模仿学习提升，促使整个行业不断发展的原因。

有了这三个标准后，我们会发现，既然当前大语言模型已经能够去理解较为模糊的自然语言，那也一定可以理解更结构化的代码，帮助开发者提升开发效率。

此外，让我们回顾一下之前开发者们是如何提升自己的工作效率的。开发者是一群「很懒」的人，他们不希望把自己的时间、自己的精力浪费在无谓的事情上，永远都会去寻找效率最高的方法。1991 年之前，没有任何能够去帮助开发者提升效率的工具。到了 1991 年，第一个 IDE 出现了。虽然它只有在写完代码后触发编译这么一个简单的动作，但在之后的一段时间里，就出现了可基于语法树补全的 IDE，能够基于 API 给出相关的推荐，极大地加速了开发者的开发效率。也就是在这个时候，整个软件行业有了第一次质的飞跃。

到了 2021 年，AI 补全又往前跨了一大步。之前 IDE 自带的补全能力虽然能够补全某一句话，但并不具备任何业务理解或者需求理解能力。但 AI 不一样，它可以基于上下文的内容推荐相关的代码。基于此，我们认为到 2030 年，所有的编程语言可能都不会存在。所有开发者都会通过和大模型的交流实现对应的需求。开发者只要把需求用人类能够理解的自然语言描述清楚，那么 AI 就能够去实现对应的代码逻辑。

所以我们在这里大胆的预测，AI 可能是在未来是每个开发者最重要的辅助工具了，就像是现在的计算机、IDE 以及高级语言。

在帮助开发者提高研发效率之前，我们必须要知道开发者们每天都在干什么。

对于我来说，我每天最多的工作是编程。但在我编程的时候，我并不是一直都在写代码，在这个过程中可能会有各种各样的角色的转换，比如需要去做业务分析、实现业务代码，然后再去验证这段代码的正确性。比如业务分析过程实际上就是人和人的交流的过程，研发需要通过和产品经理或者业务方的交流去理解需求，并把它抽象出来最终实现在代码中。而在编码过程中，开发者需要去找到对应代码的实现逻辑，把抽象思维通过代码描述告知给计算机。在这个过程中，开发者可能会去搜索之前的实现，去看其他人的代码能不能复用。最后，在代码编写完之后可能还需要去验证需求以及查找错误。

为了提升开发者的工作效率，考虑到如上的开发过程，我们可以思考：既然开发人员需要搜索，那为什么不能主动推过去？既然开发者需要去阅读文档，那为什么不能把这些知识通过一种更容易理解的方式给到开发者们？既然需要去验证代码，那么为什么不帮助开发者生成大家都不喜欢做的单元测试，更专注于代码本身实现？这也是百度推出了 Comate 的出发点，它的寓意是 Coding Mate Powered by AI——你身边的 AI 编码伙伴。

Comate 希望能够让开发者聚焦在重要的事情上，不要在重复的事情上消耗过多的精力，以期让开发者发挥更大的价值。而随着开发者和 AI 的不断磨合，我们也希望开发者在开发过程中使用的数据能够更好地被 AI 所理解，让 AI 为开发者们提供更好的服务。

但在实际开发过程中，开发者可能会有不同的开发需求，比如说在写代码的时候，开发者会希望模型尽可能地跟上自己的思考速度。举个例子，当某一行代码没写完之前，就希望 AI 就能告诉自己，后面的代码应该怎么写。只有这样，编码助手对开发者来说才有意义。当开发者与编码助手交流需求的时候，希望它可以更深层地理解问题。此时速度可能没有那么重要，对需求的深层次理解才是开发者更期待的结果。所以我们的 Comate 会根据不同的场景提供不同的实现方式。

那有了一个好模型是不是就足够了？其实还不够，数据质量的优劣是影响模型好坏的重要因素。百度在数据，尤其在技术上的数据方面具有非常大的优势。我们通过获取开源的代码，和结合百度内部的一些数据，构建了代码数据集，能够支持 100 多种语言的推荐和续写能力。

同时我们也希望能够充分发挥百度的技术优势，为更多开发者提供技术上的支持。因此我们也做了很多人工精调的高质量代码问答对，能够让模型的输出效果更好，让模型的理解力更强。

那有了好的模型和数据后，是不是我们的产品就水到渠成了？也不是。开发者在使用产品过程中的使用体验也非常重要。百度在开发工具领域已经有了多年积累，我们在内部打造了一套完整的开发流程和完整的开发工具，这些工具能够让开发者们用的舒服、用的爽，提升开发者的幸福感，可以让产品更便于开发者使用。

有了这样一些积累之后，Comate 也成为了国家重点研发计划「基于编程现场大数据的软件智能方法和环境」中一个重要的组成。

目前，Comate 在「帮你想」、「帮你写」和「帮你改」三个方面发力。

帮你想主要体现在 Comate 可以在需求调研和产品设计阶段为开发者提供帮助。比如它可以帮助开发者澄清需求、拆解任务、代码解释以及在不熟悉的技术领域提供问答服务
帮你写主要体现在代码开发场景下，Comate 可以帮开发者去生成一些比较重要的业务代码，为开发者提供一臂之力。
帮你改主要体现通过理解业务代码，发现其中潜在的风险、漏洞、安全问题。能够帮助代码更健壮，性能更好。

除此之外，Comate 也支持了 100 多种框架和语言，而且场景支持非常丰富，尽可能地满足了每一种开发者人群的诉求。比如，常见的前端开发、后端开发，服务端、软件、硬件、APP、车在内的开发场景，都能被百度 Comate 所覆盖到。

为了让大家更方便使用到它，Comate 支持了市面上大多数主流的 IDE，能够让大家在顺手的工具中使用，实际体验到 AI 编码助手的相关能力。

目前我们也推出了 Comate SaaS 版，欢迎大家可以百度上搜索「百度 Comate」去实际感受一下，希望可以在实际工作中能够去帮助到大家。

和大家分享一下 Comate 在百度内部的实际使用效果。目前，百度内部 80% 的工程师都在使用 Comate 来辅助自己开发。对不同的用户，它的采纳率也有不一样的水平。我们发现头部用户的采纳率已经达到了 60%，而整体的采纳率也在 40%以上。目前在百度内部提交的代码中，有 20% 都是由 Comate 生成的。

在这里我们也为大家提供了一个链接，扫码后就可以开启试用。