AI 编码，曾被认为是这波生成式AI中最先可能落地的场景。但因为不像聊天、搜索、自动驾驶那样“出圈”，AI编码的重要性正在被低估。
目前，有29%的大模型应用场景是让AI来辅助写代码。在一些先驱企业，一线研发人员使用AI编码辅助工具的占比超过了80%，全员配备的情况也并不少见。而在头部模型厂商上百页的技术报告里，“加大训练过程中代码权重”被更频繁地提及，编码能力也成为检验基础大模型能力的关键指标。
所以AI 编码到底发展到了什么阶段？它在企业落地会遇到哪些具体挑战？为什么它依然是投资人最看好的三大场景之一？“人类不再需要学习编程”的预言还有多远？
我们请到了两位嘉宾来聊一聊这些话题。
一位是通义灵码的产品技术负责人神秀。通义灵码是阿里云和通义实验室联合出品的智能编码辅助工具，插件下载量已超过400万，国内用户规模第一。
另一位嘉宾是趣丸科技的研发效能负责人黄金。趣丸旗下的TT语音是英雄联盟、王者荣耀、和平精英等五大头部电竞职业赛事的官方合作平台。今年4月趣丸正式成立了AI效能团队，正在全面引进智能编码的工具。
以下是对谈的内容精选：
主持人：首先从一个最基本的问题聊起，为什么最新发布的Llama 3.1和Mistral Large 2 都特别强调了自己的代码能力？要如何理解代码能力是检验一款大语言模型能力的关键指标？
神秀：我觉得有两方面原因。首先，代码本身也是一种特别的语言，所以在大语言模型里面训练大量的代码数据，可以让整个大模型的推理和分解能力有比较大的提升，这是非常有效的。其次，从应用场景来看，调查显示大概有29%的大模型应用场景是人们希望大模型帮他去写代码。换句话说，编程是大模型应用非常重要的一个领域，所以今天各大厂商都非常重视大模型在编码领域的表现，也非常重视使用高质量的代码去训练模型。
主持人：通义灵码现在用的是多大参数的模型？
神秀：我们在公共云上给开发者提供的是通义最好的模型，千亿级的参数。过去大家可能会用小参数模型，但反馈并不好。我们发现大参数模型，再加上互联网实时RAG，能有效提升代码生成的质量和问答的精准度。现在，大参数+实时RAG的架构已经成为AI编码产品的标配，因为提升精准度对开发者来讲是一大刚需。
主持人：目前最常用的场景有哪些？
神秀：我们可以参考通义灵码的这几个数据：首先，今天70%由AI生成、被人类采纳的代码还都是来自于代码补全。所以，在IDE里做代码的直接续写，一定是门槛最低、开发者最直观能感受到的能力。所以我们也一定要把代码补全能力做到最好。
第二，在问答这块，我们发现大概有七成的问答是自由问答。他可能圈选一下代码，让AI做简单的优化，或者针对不会写的一段代码提出一个问题，或者让大模型直接生成一个算法，类似这样的场景是非常多的。这些本质上都是一种学习。过去我需要去查搜索引擎，还要甄别各种各样的垃圾信息，现在可以直接问大模型。在这种场景下，对大模型回答的精准度也是有非常高的要求。
主持人：我的一个前端工程师朋友还提到了一个场景：因为她正在学一门新的编程语言，可以通过AI工具的问答功能，让她更快掌握这门新语言。
神秀：对，这也是一种典型的学习场景。当然，还有一些深层次的代码任务。代码解释算是一个入门，更深层次的我们认为有两个，一个是单元测试，还有一个是代码优化或者叫code review。这两个其实也都跟质量和精准度相关。所以我们可以很清楚地看到，首先肯定要解决效率问题，再解决质量问题。
主持人：现在已经到了解决质量问题的时候了，人们对大模型有越来越高的精度要求。
神秀：是的。但我们认为，普遍来讲现在做单元测试和code review的产品都没有达到一个非常好的水平。举个例子，今天在单元测试的一些复杂case上，一次性编译通过率在30%，也就是说70%的还需要人类进行修正。
主持人：从趣丸的角度，除了代码的采纳率和准确率之外，在选一款AI编码工具时，最看重的还有哪些？
黄金：作为企业，我们选择一款工具，就要考虑到工具在企业内部能不能很好地落地，或者说能不能跟企业内部的系统有机结合。以AI编码工具为例，我们会非常看重企业内部的知识库能不能便捷导入。当然，也包括工具的功能点是否完善，能不能提供像企业级RAG等企业特别关注的功能，有没有个人采纳率的统计——如果没有这些数据，其实我们很难评估工具为企业带来的实际价值，无法计算投入产出比。
在这些方面，我们认为国内像通义灵码这样的产品相比国外的AI编码产品更有优势，能力支撑上更全面、更友好。
主持人：这些点都非常重要，也很值得产品方关注。目前，趣丸内部哪些场景是使用AI编码工具比较多的？
黄金：经过我们的调研，除了代码补全之外，基本所有人都会用代码解释的功能。神秀刚刚提到，这是一个相对“深层次”的场景，但其实也是个刚需场景。因为在企业内部，所有开发者可能最不喜欢的一件事就是去读别人的代码、去理解别人的代码。现在AI工具可以帮他去解释代码，这就省去了大量的时间。我们看到的数据是，基本上每人每天都会至少使用一次。
主持人 ：代码解释会有上下文长度的限制吗？
黄金：目前大模型上下文都比较长，也会有一些函数特别长，存在多轮对话后超过上下文长度的。
但是我们通过工程或者是规范层面就可以很大程度上解决这个问题。因为在一般开发过程中，是不允许一个函数写上万行这种情况存在的，所以通常经过多轮对话都能解决问题。我们在调研中，只有3%的用户反馈，因为解释的代码附加上下文很长，在很多轮对话后，会有超出token的情况。
主持人：除了代码解释之外，还有哪个场景用的比较多？
黄金：因为我们内部正在启动一个项目，把过去C++的遗留项目全都转成用Golang和 Java语言，所以这也是一个需求很大的场景。目前来看，大模型可以完成百分之四五十的工作，剩余的一些工作还是需要我们手动去改。这里就涉及到神秀刚刚说的“准确度”问题。我们当然希望AI写出的代码可以直接用在工程上，而不是之前要读别人写的代码，现在改成读AI生成的代码。
主持人：目前趣丸内部有多少人在使用AI编码工具生成代码？
黄金：在整体的研发人员中，扣除一些研发负责人，占比应该超过了80%。我们对AI编码工具接触比较早，最初引入时，内部也有过一些争议，是否真的能带来价值。试验了将近一年后，我们做了一次调研，目前内部有超过60%的人认为 AI 编码对提效是比较明显的，有超过10%的人认为提升巨大。一些编程语言的AI生成代码占比甚至能达到百分之四五十。
主持人：这个语言是Java吗？
黄金：对。
主持人：Java采纳率特别高，原因是什么？
神秀：首先，Java的整体语料非常丰富，工程框架也比较标准化，所以模型在Java上的表现肯定会更好。
另外，从通义灵码线上的数据来看，有四成的开发者是Java开发者，这是我们的第一大语言。今天中国开发者对Java真的是情有独钟。所以我们会重点去优化Java的表现，也取得了很不错的效果。
其实阿里云云效团队做通义灵码这款产品之前，在2021年就开始做代码助手小模型了。当时这款小模型就支持了两种语言，Java和Python。这次，我们也把过去两年多在Java上的调优经验迁移到了通义灵码上，包括跨文件的解析、整体幻觉的消除、框架的调优、单元测试的经验，甚至一些代码规约等，我们都做了融入。
所以很多使用者反馈，今天通义灵码的Java能力，不管是跟国内还是国外同类型产品PK都有一定优势。
主持人 ：很厉害。我知道通义灵码支持200多种编程语言，其中有哪些语言的表现是有待提升的吗？趣丸可以提提建议。
黄金：从我们目前内部使用情况来看，像Dart这样的小众语言效果会差一些，像VUE之类的前端语言可能需要持续优化。
神秀：黄金提到的前端语言，确实会稍微难一些。首先，今天很多企业都有个性化前端框架，不一定是基于开源的。所以，如何让大模型能够感知到企业个性化框架的特点，生成可用的代码，是要解决的第一个难点。第二，前端语言是脚本型语言，代码引用链解析、程序分析等等都不太一样，需要去做特别的定制和优化。第三，前端语言的版本特别多，比如像我们经常说的VUE2、VUE3，语法或API都完全不同，我们还要让模型能清楚地识别各种框架的差异。
我们已经在加紧优化中。通义灵码的用户群体很大，用户每天都在“踢我们的屁股”，给我们反馈bad case，让我们持续优化改进。虽然修正bad case非常花心力，但因为我们是做公共云服务，只要解决一个bad case，能够辐射到的客户范围就非常广，所以对我们来说这是件好事。
主持人：你提到的第一个难点——让大模型理解企业个性化框架的特点，包括理解企业具体的业务，其实是AI编码工具普遍面临的挑战。
黄金：这一点我们深有体会。我们不能回避一个事实：大模型都是基于公开数据去训练的，如果把一个大模型直接引入到企业内部，它一定是个“外地人”。要想把这个大模型变成“本地人”，我们需要做什么？
我们总结下来，就是把公司所有的产品需求、内部代码、自动化测试用例等等都建成一个公司私有的知识库。把这些知识库赋能给大模型，最终大模型才能产生我们想要的效果。
首先，是产品的知识库。比如说功能开发，我们可以直接在辅助工具里引入这一部分产品需求作为上下文，去提升生成代码的相关性。
其次，过去我们产生了很多测试用例，都与产品质量紧密相关。所以我们也建了一个测试用例的库，并推出了AI生成测试用例的产品，它会根据我的产品文档去生成测试用例，再把这些东西全部沉淀下来，形成一个知识库。
代码，其实是企业内部数量巨大的资产。针对过去的代码仓库，我们也建了一个项目数据库进行索引，用在代码生成和单元测试用例生成。
之前我们遇到的问题是单元测试用例生成的准确率很低。现在简单的测试用例开发者都能搞定了，剩余复杂的就通过代码仓库的索引、通过语法树去获取生成测试用例需要的所有信息，然后通过Agent生成，采用率有了大幅提升。
我们也在考虑沉淀个人的知识库，让AI了解你负责什么业务，你之前写过什么代码，最终成为开发者的一个分身。
主持人：非常有启发。接下来我们聊几个业界讨论比较多的问题，也想听听两位的观点和解法。一个是关于代码安全的问题。
黄金：在我们决定引入AI工具时，讨论最多的当然也是代码安全。但首先要看到，AI生成代码是一个必然趋势。要迎接这个趋势，就要做好相应的准备。如果一概而论、一刀切，只会导致落后于人。
我们的思路是企业内部要对代码进行分类分级。我们规定了哪些代码库可以直接用AI补全。很多代码其实都是从开源社区来的，如果不涉及内部的核心业务逻辑，或者核心算法，我们都会鼓励开发者去使用AI工具。同时在人员上，我们也根据工作是否涉及机密进行了划分。
神秀：从产品建设方的角度，我们尊重每个企业对代码安全的要求，同时我们要看有什么技术可以帮助企业去解决问题。
我们从2017年开始做云效产品，云效其实就是企业在云上托管代码的平台，承担了上万个企业私有代码的存储。所以我们深知代码和代码安全对一个企业的价值。我们为中大型企业设计了灵码专属版。“专属版”其实是云上独立部署的实例，跟其他企业做了网络层面的隔离，首先保证了不会因为横向越权而出现代码泄漏。第二，我们将实例与企业内网进行专线连接，杜绝了外部对实例攻击的可能。第三，保证代码的合规存储，企业代码在云上全链路都不会存储，从技术原理上就规避了代码泄露。目前，已经有一大批国营企业、制造业企业和有核心算法的科技企业都开始使用通义灵码的公共云专属版。
当然，关于“代码安全”的另一个面向，人们也会担心AI生成的代码本身就不安全。我们正在考虑设计一个后处理机制，通过异步化的扫描将不安全的代码识别出来，来确保新写的这段代码对整个代码库是安全的，不会引入新的安全漏洞。
主持人：对于AI可能生成不安全的代码，趣丸有什么应对思路？
黄金：AI 确实可能会生成存在风险泄露的一些代码。过去我们是一个人写代码，另一个人审核，现在我们也基于同样的思路，在AI 提交代码的时候，用另一套AI 去review代码，检查其中有没有安全风险。除了基于传统的Sonar扫描做防范，我们还有一套基于大模型的新型策略。如果有安全风险，AI会拒绝你提交，也会给出修改建议等等。
主持人：类似SFT中的reward model，很有启发。下一个问题，如何看待copilot辅助代码生成和端到端需求实现的Agent这两种产品形态？
神秀 ：Devin出来之前，我们并不是特别相信Agent能够独立完成一个端到端的需求或者代码任务。虽然大家有一些尝试，但是没有笃定这个方向是一定能够在短期实现的。Devin的突然出现给大家打了个样，今天确实通过Multi-Agent的架构，可以实现端到端的AI自主编程。所以紧接着，像OpenDevin这样的开源项目，或者像SWE-bench这样的榜单，都出现了。同时也出现了大量编程领域的创业公司都在做Agent。可以说，Devin的出现相当于掀起了一个浪潮，让全世界聪明的大脑都看到了一个非常有前景的机会。
最近灵码也开发了Agent版本，并登陆了SWE-bench Lite的榜单，Agent的编码问题解决率达到了33%。我觉得这是一个不错的成绩。我们也计划九月份左右能推出一些类Agent的灵码产品。但这只是一个开始，我们估计可能还需要半年到一年的时间不断去打磨，最终才能做到部分生产级的落地。
我们深知今天大模型想要实现端到端的需求解决，还有很长的路要走。所以，我们更倾向于在一些能够确定上下文的场景先落地，如果要选择一个产品建设路径的话，我们也会这样一步一步来。
主持人：AI编码工具会取代程序员吗？
神秀：从大模型目前的原理来看，它更擅长模仿。比如它更擅长有固定范式的一些工作，或者是过去很多人都已经做过的事情，因为有大量的过往数据可以参考。在这种机制被打破之前，我认为大模型更多地还是做重复性的工作。
所以说不管是代码助手，还是Agent应用，目前看来都更多是帮助开发者去做他们不愿意做的一些事。
黄金：我的看法类似。从目前大模型的能力来看，要达到替换人的这个地步，还有一段路要走。
还是以Devin为例，我们很早之前就测试过Devin，实际测试下来缺陷还比较多。另一个问题是，如果要让Devin写一个贪吃蛇游戏，它可以很快生成，但实际上我们做过调研，真正完全从零开始的需求在公司里可能只占了不到25%。剩余百分之七八十的需求都是在原来一个巨大的项目中去更改代码。这时候Devin的局限性就很大，他没办法在一个很大的项目中按照要求去实现修改需求。你需要花费大量的精力，来描述清楚你的需求。
另一方面，对一个程序员来说，编码只是一部分工作。还有很多包括架构、产品设计上的工作，大模型无法替代。只是说现在这种自动化的编码工具的出现，会促使开发队伍的人才转型，我们要向更具创造力、更高价值的方向转变。
主持人：从写代码到整体的研发效能提升，中间有多大的 gap？
黄金：研发本身是一个极其复杂的系统，研发效能的提升也不是由单一因素决定的。还是让调研的数据说话，一个研发人员真正写代码的时间占比可能在百分之二三十。剩下大量的时间需要沟通、测试、写文档、设计等等。
所以我们也会问：在研发过程中，你还需要哪方面用AI帮你做效能提升？
主持人 ：这是个好问题。所以具体还有哪些方面可以让AI帮忙呢？
黄金：目前，我们已经从产品研发、测试到运维的各个阶段都做了尝试，都有一定的AI工具落地。除了之前介绍的那些，我们还有个产品助手，他会和你进行多轮交互，再把需求转换成一个比较规范的产品文档。在研发阶段除了AI辅助编码工具，还有AI review代码。在测试阶段我们用AI去生成测试用例，根据我的产品需求生成库用例，然后帮我排期。在运维阶段，我们基于Multi-Agent做了一套运维机器人。它可以帮你提单，帮你查询资源，帮你做一些简单的故障定位，甚至帮你跟进故障，发现风险，并通过多轮沟通来解决风险。当然这些方面，AI的表现都还有待提升。
主持人：最近这一年半年，整个国内AI编码类产品的普及程度有多大提升？未来会是什么样的增长趋势？
神秀：我们其实有一个判断，六个月之内，AI编码类产品在头部企业和先驱型企业都会落地。如果再放眼一年之内，可能每个企业或多或少都会使用。换句话说，会无死角地覆盖。
主持人 ：趣丸内部现在的推广速度是什么样的？
黄金：我们从最开始只有 10% 不到的人使用，经过一个季度，已经达到了 80% 以上了。我们也定了今年下半年的目标，把整体的 AI 代码生成占比提升到 35% 以上。
主持人：大家的期待和希望努力的方向很一致，我们也期待很快能看到神秀说的，每一家企业都用上AI编码工具。
点击阅读原文**，下载使用通义灵码！**
