赞
踩
作者 |《新程序员》编辑部
出品 | CSDN(ID:CSDNnews)
回顾计算机发展初期,当时软件并没有被单独划分为一个学科,软件开发也更多被视为一种开发者基于自身直觉和经验而展开的“艺术”。直到 1968 年,NATO(北约)第一次提出了软件工程(Software Engineering)概念,软件开发才终于向系统化和规范化演进。
56 年后的如今,当 AI 浪潮席卷全球,软件开发领域再次迎来变革:一场前所未有的智能化革命正在发生。在大模型、深度学习等技术飞速发展下,智能化技术正在深刻改变着传统开发流程——从需求分析到设计实现,从代码生成到测试验证,每一个环节都在朝着更高效、更智能的方向发展。
为此,在 7 月 4 -5 日于北京正式拉开帷幕的 2024 全球软件研发技术大会(SDCon)上,我们特设“软件开发智能化”主题论坛,汇聚了来自阿里、百度、腾讯、字节、蚂蚁、京东、非十科技的 9 位一线技术专家,共同探讨智能化在软件开发全生命周期中的应用与实践。本场论坛,不仅是对软件开发智能化现状的总结,更是对未来趋势的展望。
那么接下来,让我们一同踏上这场探索未来软件开发的智能之旅。
大模型的火热带来了 AI 应用的井喷,那么在各种落地场景中,最高频刚需的到底是什么?
根据 Datos 针对 2023 年 5-6 月 ChatGPT 用户使用情况的分析、其中编程以 29% 占比高居榜首的结果来看,通义灵码产品技术负责人陈鑫认为答案很明显:编程就是最高频的 AI 应用场景。
在陈鑫看来,大模型对软件领域的深远影响主要体现在两个方面:编程事务性工作的替代和知识传递模式的改变。
编程事务性工作包含两种,一种是个体工作,例如研发人员的重复性工作、简单工作、沟通工作等,如今已可以用大模型做普遍替代;另一种是协作工作,例如研发管理流程化、缺乏灵活性,组织产生效率竖井,响应能力弱等,这部分也可以酌情交给 AI,无需复杂的协同流程。
开发者的知识传递,包括代码规范的优化和宣导、相关培训等,目前多数还在通过口口相传的方式进行传播。而通过强化模型本身的能力、让大模型更加聪明,智能化研发工具链可让一线开发者直接赋能。
在这种影响下,大模型创造出了新的人机交互模式:LLM as Copilot、LLM as Agent 和 LLM as Multi-Agents——从产品形态来看,代码大模型产品演进的三个阶段亦是如此。
(1)阶段一:代码辅助生成(Copilot 阶段)
这个阶段不会改变软件工程专业分工,主要增强领域专业技术,AI 研发工具辅助人完成任务,即:工具负责赋能人员提效,人负责主导、提示及确认。需要注意的是,代码助手核心有 4 个需要攻克的技术难点:生成准确度、推理性能、数据个性化和代码安全。
首先是生成准确度,它要求过硬的基础模型能力。其次是推理性能,陈鑫建议可通过分级缓存、丰富的模型组合,实现速度与准确兼顾。
例如,训练小参数代码模型来完成时延敏感型的代码补全任务;中等参数模型可提供代码解释、注释生成、单元测试、代码优化等常见代码技能;至于对模型知识面、编程能力、推理能力有更高要求的研发问答,则需要最大参数模型并叠加互联网实时RAG技术,消除模型幻觉,提升回答质量。
至于数据个性化,需要企业级代码补全、研发问答检索增强。而代码安全则要求全链路的安全防护:通过代码加密技术防止传输过程泄密,通过本地向量存储降低云端存储泄密风险,以及通过敏感信息过滤避免密钥信息意外传出。
(2)阶段二:任务自主处理(Agent 阶段)
相较于 Copilot 阶段,陈鑫形容这个阶段的代码智能体更像是单一职能专家,具备一定自主任务规划能力以及使用工具的能力,自主完成预定任务。可实现工程级别的代码生成与问答,利用检索增强技术结合大模型,实现例如代码查找,业务逻辑生成,SQL 生成,整库功能解读等复杂问答能力。
(3)阶段三:功能自主研发(Multi-Agents 阶段)
所谓 Multi-Agents,意为多 Agents 基于 AI 调度共同协作完成任务,实现从需求->代码->测试的全流程自主化——换句话说,即 AI 程序员般的存在。陈鑫指出,前两个阶段对软件开发的效率提升大概在 10%-30% 之间,但到第三阶段将突破这个上限,甚至可以达到 50%-70%。
对于未来的智能软件研发工具链形态,陈鑫认为 AI 程序员的出现不至于颠覆现有的 Devops 流程,但能充分利用和简化当前的 Devops 流程。此外他还预测,未来 AI+Serverless 或许会成为一种主流的编程架构。
进入 AI 时代后, 国内外各大公司纷纷下场,光是 AI 智能编码助手就涌现了几十款。但具体如何让大模型驱动的智能代码助手更好地落地、切实有效地提高研发效率,是许多开发者面临的一堵高墙。
基于这个问题,百度资深研发工程师王初晴带来了 AI 编程辅助工具文心快码(Baidu Comate)落地背后的经验分享。
2022 年 ChatGPT 的爆火让大模型走到台前,自此 AI 应用百家争鸣,生成式 AI 也为软件开发带来变革,由此衍生出了 AI 原生研发新范式。在此背景下,文心快码(Baidu Comate)诞生了。
当前,百度内部 Comate 代码生成占比 30%,实现全局提效超过 10%,注册企业数 10000+,用户采纳率高达 44%……王初晴表示,这一连串的可观数据,得益于 Comate 全方位、多角度地提升效果与体验。
精准
准确性是智能代码助手最关键的一点,没有它一切都是空谈。要想提升准确性,首先要打造一个专属的代码模型,即严格把控数据源,再对模型进行训练和推理加速。其次,基于编程现场的知识增强也是提高精准性的途径之一,而信息的压缩与排序也能提供更有效的知识,包括对本文件进行精细化信息提取,对跨文件进行信息压缩和优先级/相关性排序。
除此之外,为了最大程度提高精准性,还需要在各个环节将模型与工程相结合:
(1)用户请求:动态延迟触发,进行用户行为预测;
(2)推理前:Neighbor / Dependency / Embeddings 获取,精细化上下文提取;
(3)推理中:智能判断推理长度;
(4)推理后:语法正确性校验,低质内容过滤,重复性、安全性检测。
极速
编码过程是一个连续、专注的过程,若智能代码助手出现中断、等待情况,对持续编码的工程师无疑是负面反馈。因此王初晴认为,代码续写的性能诉求相比普通文本生成更高,在保证推荐准确性的前提下,需要关注响应速度。目前,经过模型层、框架层、工程层的多重优化,Comate 代码续写端到端响应时延在 600 ms 以内。
安全
代码是企业的核心资产,守护企业代码,确保代码数据安全,是每个智能代码助手应该做到的。Comate 对代码做了多层加固,来保证安全性:在模型训练前,会对训练数据进行严格的过滤和清洗,去除或替换敏感信息,如个人信息、商业秘密等;在线推理时,对模型的输出进行实时监测,识别并过滤掉可能包含敏感信息或违规内容的输出;数据传输时,会采用加密协议,确保通信内容在传输过程中被加密,防止中间人攻击;最后,在数据上传前,对敏感数据进行脱敏处理,如替换、掩码或删除敏感字段。
开放
除了以上三点外,为了能让其更好地适应不同组织和个人、取得更好的智能化效果,开放性也十分重要。有了开放性,企业和开发者就无需重复建设即可快速大模型能力,无限扩充平台场景,还能更适配团队的业务知识,适配团队规范、固化团队流程。
智能
最近很火的智能体,也是百度开发团队的研究方向之一。王初晴表示:“目前我看到智能体在很多场景都展现出了巨大的潜力和价值,这很可能也是未来智能研发助手的一个发展方向。”
朝着智能体这个方向,则要求代码助手:能听懂需求,按顺序执行需求拆解、制定计划、生成代码、调试运行等步骤;与开发者同频,依靠对编程现场的理解,帮助开发者解决繁琐、重复的问题;此外,还可基于 RAG 实现智能代码检索技术,从而解决 LLM 的幻觉等问题。
提到对未来的展望,王初晴认为生成式 AI 将显著推进软件研发智能化进程,从人强机弱逐渐演变成人强机强,应用架构也必将化繁为简。
围绕“代码大模型与软件工程的产品标品之路”这一主题,腾讯云 AI 产品负责人汪晟杰在本次论坛中带来了深刻且富有洞见的演讲。
根据信通院调查显示,超 70% 企业在软件开发阶段应用了大模型等 AI 技术,其次是软件测试。而在软件开发中,又以编码辅助、代码沟通为最高频的使用需求。汪晟杰从代码大模型的秩序性、逻辑性和上下文感知性这三个特点切入,提出可结合工程方式,辅助来让大模型更好的懂工程,即利用 AI 技术改进软件工程的过程和方法,实现软件开发的智能化、自动化。
然而在软件工程 + AI 助手这个过程中,存在难以避免的挑战:准度/评测,成本/算力,质量/安全。整体来说,大模型成本与体验之间极限拉扯,需准度评测保证模型质量,另外要求安全保护资产。对此,汪晟杰给出了确保代码大模型“好、快、准”的三大要素:数据安全 = 好;IDE + 编码效能 = 快;对话 + 工程理解 = 准。
那么对于一个懂工程的 AI 代码助手,怎样才能做到最佳使用范式?汪晟杰表示,需要学会使用更好的提示词工程,而提示工程的基本原理,基本可总结为以下 3 个“S”:
单个 Single:始终将提示集中在单个、定义明确的任务或问题上。
具体 Specific:确保说明明确且详细,最好能附带一个示例或者模拟信息结构。具体且具象带来理解会带来更精确的代码建议。
简短 Short:在具体的同时,保持提示简明扼要。这种平衡确保了清晰度,而不会使腾讯云AI代码助手超载或使交互复杂化
紧接着,汪晟杰分享了在他视角下 AI 对工程项目的探索思路。首先,单元测试是软件工程 3.0 中要解决的“难啃骨头”,更偏向代码重构,因为测试是个专项领域。而单元测试与 AI 的结合面临三个问题:测试方法种类多、框架多;项目本身不具备可单测功能,难以 mock;生成质量难以运行,无标准最佳实践。
针对单元测试 + AI 的挑战,汪晟杰表示有一些可行性探索:增加示例代码,感知框架;语法树找相关跨文件,依赖文件的调用链;策略感知 Mock 对象,生成完成可执行单测。不同语言、不同框架对应不同的单测模型,是目前模型层面上的可探索之路,同时也需要给大模型更多的提示词来帮助大模型理解。对于软件工程 3.0, 智能体也将会发挥巨大的单元,并以 AI 为驱动力,与各个环节发生协同、推理、反思。
本质上来说,AI 辅助类工具与 Devops 一样,都是研效工具且是强运营产品。但 AI 代码助手这类产品不同于人们已经熟知的 Devops,它还很新,因此如何让产品变得标品化至关重要。汪晟杰解释道,所谓标品,就是希望这个软件是一个单纯干净的软件,尤其工具类软件更要做到足够小而美。例如,辅助类工具就只是辅助类工具,无需连通别的系统或把 Devops 串起来之类的,这样无论在什么环境下它都能运行。对于未来 AI 的演进方向,汪晟杰也在最后进行了预测:AI+CDE,即通过多智能体的有机结合,在云开发环境中利用 AI 自主完成全套开发流程直至最终上线。
提及软件智能研发,蚂蚁集团研发效能技术负责人姜伟带来了《基于 CodeFuse 进行智能研发的思考与探索》的主题演讲。
过去人们曾以为,创作型工作(如绘画,编曲,写作,编码)不容易被 AI 取代,但莫拉维克悖论否定了这个传统看法,并提出无意识的技能和直觉才需要极大的运算能力——这也确实是目前 AI 领域最难解的问题之一。
如果换个角度,也侧面说明在理论上,大模型助力智力型创造(写代码)会更容易。
姜伟指出,自 ChatGPT 出现由此推进全球 AI 发展后,研发模式奇点正在发生,即基础模型与 AI 生成工具正在重塑技术人的工作方式,AI 将改变软件研发的工具,诞生“Dev Tools 2.0”。但在这一过程中,智能研发产品的落地会面临诸多挑战。
结合 CodeFuse 的开发过程和落地经验,姜伟总结出了 5 种挑战及相应解决方案。他强调了一点:代码底座大模型≠产品落地。
挑战 1:代码底座大模型需要证明其代码能力(打榜),并要求生成代码符合逻辑。通常的解决方案是对模型进行预训练 + MFT 微调。
挑战 2:自回归训练从左往右,模型只能普通续写,无法利用上下文代码进行填空。解决方案是利用 FIM(Fill In the Middle)这种方式训练,即可充分利用上下文的代码信息。
挑战 3:在自适应粒度方面,由于常规训练无代码语法,停止位置不可控。解决方案是通过 BlockFIM 完全丢弃规则前后处理,自适应决策代码生成粒度,以此让模型自主停止。
挑战 4:单文件感知范围有限,业务逻辑不准。解决方案是用 RepoFuse 仓库级补全,实现仓库级感知,为模型提供更多信息,以此找到正确的业务定义。
挑战 5:在推理部署这个环节,响应速度敏感,要求代码补全在几百 ms 以内,解决办法是通过 ModelOps 技术加速。
聚焦当下的经验分享过后,面向未来姜伟也有着属于自己的思考:“人类的行走能力已经通过汽车、飞机进行了质的提升,极大拓展人类范围,甚至探索太空;人类的视觉能力也已经通过电子显微镜、太空望远镜进行了质的提升,可以观察原子和遥望星空;人类的理解和创造能力正通过 LLM 进行大幅提升中,且其继承和共享或许更加高效....”
基于以上想法,展望未来代码大模型的发展趋势,姜伟认为有以下两种可能:
其一,编写软件的门槛急剧降低,给机器下达指令不再是程序员的专利,人人都能用自然语言去创建应用;
其二,AI 工程师将替代人类软件工程师完成各类研发工作,届时软件开发不再是“脑力”劳动密集型行业,编写软件效率将急剧提升。
在这场由生成式 AI 技术引领的软件行业革命中,京东云在 6 月推出了基于大模型的智能编码应用 JoyCoder,其智能代码评审、批量生成单元测试等独家功能,引发了诸多开发者的关注。
在本场论坛中,京东研发效能平台工程域负责人刘兴东带来了《京东的 AIGC 革新之旅:通过 JoyCoder 实现研发提效》的主题演讲。
提及 AIGC 对软件行业的影响,刘兴东用一句话概括:整体水平提升,促进行业发展;但挑战与风险并存,需要整体进化。由于 AIGC 的应用,软件开发的成本和效率都得到了显著改善,自动化技术也提高了代码质量、减少了人为错误,然而过度依赖或许会导致人们忽视审核过程,缺乏创新和生产力。
面对这种情况,如何借助 AIGC 进行研发场景提效就是个关键问题。
对此,刘兴东表示在软件开发的场景中,AIGC 技术与 DevOps 流程的结合尤为重要。DevOps 涵盖了从需求分析到上线部署的全流程,通过 AIGC 技术,可显著提升这一过程的效率,具体包括:
(1)需求分析:AI 分析;
(2)系统开发:报错分析、单测生成、代码生成、代码评审、代码优化、文档生成、漏洞修复;
(3)系统测试:AI 测试工具、测试代码生成、精准测试生成、缺陷分析;
(4)部署上线:指标异常检测、智能文本分析、根因分析。
进一步聚焦到编码环节,AIGC 技术也带来了显著的效率提升和质量保证。除了用自然语言即可快速实现代码编写这一点,刘兴东指出,AIGC 技术还能通过大模型对内部文档和代码库的理解,快速定位公司内部或外部的通用代码片段,从而避免重复开发,促进代码的复用和标准化,某种程度上也能助新人更快融入开发团队,缩短适应周期。
基于以上原因,京东研发了基于大模型的智能编码应用 JoyCoder,兼容多种大模型并适配国产化环境,在 DevOps 全流程的每个步骤中都能做到“强力辅助”:
通过人机会话,将需求描述更加标准化,生成标准的用户故事,后面设计阶段能让自然语言生成对应的代码模块。
在代码编辑区可以使用代码补全功能对编码过程进行辅助,代码注释能够自动生成注释内容,减轻负担。代码解释和代码评审能让研发人员快速理解代码,让新成员快速熟悉代码,提高工作效率。
快速生成单元测试和接口文档,减轻研发人员的负担,对问题代码提出修复建议,并将安全扫描和规约检测左移到编码阶段。
目前,京东约 70% 的研发人员(12000 人左右)已安装 JoyCoder,生成代码采纳率超过 30%,助力开发周期缩短 20%——如刘兴东所说,JoyCoder 的目标是提升研发者的幸福感,实现快乐编程的目标。
在大语言模型(LLM)的加持下,工程和应用层面的创新日新月异,在开发者最为熟悉的研发领域亦是如此——在这之中,我们需要怎样一款 IDE?在字节跳动豆包MarsCode团队技术专家天猪看来,下一代 AI IDE 必备三大要素:开发者体验、Cloud 云原生和 AI 原生支持。
(1)追求开发者体验
不仅要颜值在线,下一代 AI IDE 还需确保质感、交互体验,即打造开发者日常爱用的 IDE,拥有秒级极速启动和 UI 交互优化专项。与此同时,灵活组装 + 可定制也是提高 IDE 开发体验的一个途径。
(2)Cloud
与 WebContainer 进行对比后,天猪建议选择容器方案为主,其具有能力完备、隔离性高、环境一致等优势。但这个方案的推进也存在难点:一是复杂度高,具备较高的技术门槛,二是资源开销成本高,需专项优化。对于后者,天猪认为可通过成本审计、深度定制调度策略和碎片整理,以提升资源利用率,同时智能休眠策略,也能实现更快的回收和冷启。
(3)AI 辅助编程
关于 AI IDE 的设计思路,天猪分为了两个部分:研发提效(代码补全、代码推荐、代码生成、自动修复),辅助决策(项目理解、联网搜索)。
研发提效 - 更快地完成编码
代码生成:根据自然语言生成所需代码,目前形态为 Side Chat / Inline Chat,交互方式仍在持续摸索迭代中。
代码补全:预测下一个字符,关键点在于高性能低延迟的模型(用于 Context 上下文提取)以及 Prompt Engineering。此外天猪强调,代码补全的测评指标不能只看采纳率(容易被误导,无法指导后续优化),应该使用更全面、合理的指标——CPO(Character per Opportunity)= (尝试率) x (反馈率) x (采纳率) x (每次采纳平均 token 数) x (token 平均字符长度)。
代码推荐:代码补全有个局限性,即它解决的是编写全新代码的问题,但无法胜任存量代码的修改和删除。因此,需要能够预测下一个编辑动作的“代码推荐”,可基于代码大模型基座,学习和提取 Git Commits 中海量的用户编辑行为信息来实现这个功能。
自动修复:针对 Bug 进行分析和规划,自主完成修复。可通过 Agent + 工具、静态调试(LSP、AST、Lint)和动态调试(断点调试,通过运行来逐步获取执行链路的上下文)和最终测评,来实现高质量的代码自动修复。
辅助决策 - 提供高质量回答
项目理解:多维度理解项目代码信息,针对项目进行问答搜索。这个功能的关键点在于快速索引代码知识图谱,意图识别、RAG 召回策略,学会如何剪枝出最合适的上下文。
联网搜索:通过查询预处理、网页分析与提取内容和召回与后处理,确保 IDE 接入搜索引擎后可提供即时、准确的研发信息。
目前多数情况下 AI 在编程中的角色只是辅助,但天猪表示由 AI 驱动编程的未来已经可以看到一些苗头了。在演讲最后,他再次强调 AI 与人类并非敌对关系:“AI 与人类不是竞争关系,我们希望打造一款软件,能让开发者的效率变得更高,从而能让开发者成为超级程序员,把更多的时间和效率花在思考和创造上。”
以 GPT 为代表的自然语言大模型的出现,催生了以大模型为技术基底的代码自动生成技术的快速发展。而非十科技 CTO 刘政宁认为,尽管类似自然语言大模型,都是语言生成,但代码生成具有固有的特点,如语法结构、逻辑关系、长上下文等,不能简单直接套用自然语言大模型。
刘政宁解释道,自然语言大模型可以与知识图谱结合,但程序语言的分析难以建立知识图谱,需要建立抽象语法树作为中间表征。不仅如此,代码生成对正确性的要求也远高于自然语言生成。因此代码大模型训练对准确度的要求很高,通常需要更大的参数量和更多的数据,也就导致了更高的资源需求和更长的训练时间。
资源要求高、推理延迟大、部署成本高……这些大模型训练过程中的常见难题,到底该如何解决?刘政宁给出的答案是:国产深度学习框架计图(Jittor)。
Jittor 由清华大学推出,支持国产芯片与国产操作系统,拥有 2 个别具一格的创新点:
创新 1:元算子融合。提出元算子概念和元算子融合策略,只需三类 18 个元算子即可融合得到深度学习计算所需的算子,易于优化、扩展和维护,硬件适配性强。
创新 2:统一计算图。提出统一计算图思想,采用动态切分、静态子图融合的计算策略,兼顾动态图灵活和静态图高效的特点,支持跨迭代融合。
得益于 Jittor 的元算子融合技术、高效分布式计算、动态 swap 机制等,刘政宁指出相比于国际主流框架,基于 Jittor 的模型库性能得到了显著提升,更重要的是基于 Jittor 的大模型训练也得到了优化。
首先是显存优化。传统数据并行模式下,所有 GPU 都要存储一份模型参数和优化器,而 Jittor 实现了零冗余优化器技术(Zero Redundancy Optimizer),将模型、优化器分片存储到不同GPU上,实现显存高效利用。其次是分布式训练,Jittor 可实现多类并行模式并高效结合。
相比 Deepspeed+PyTorch,Jittor 的训练和微调速度提升 20%,内存消耗减少 30%,甚至在相同硬件资源条件下,支持训练模型大小提升 30% 以上。因此,基于计图的大模型训练,可以做到精度完全对齐,并降低训练成本、增大模型规模。
与此同时,Jittor 在大模型推理过程中也解决了许多难题。例如,Jittor 可通过内存直通读取,减少内存拷贝数量,大大提升模型加载效率。又例如,基于元算子的内存切分技术与统一内存管理,Jittor 能让数据在显存,内存和硬盘之间快速切换,避免显存和内存消耗过大的情况。此外,通过减少冗余的显存占用和 GPU 计算,Jittor 还实现了低延迟、高吞吐,可进一步提升大模型推理速度。
那么,基于 Jittor 的大模型服务实践效果究竟如何?以非十科技基于 Jittor 训练部署的 AI 编程助手 Fitten Code 为例。据刘政宁介绍,Fitten Code 核心体验已超越 GitHub Copilot,不仅在 Human-Eval 测试中的代码生成准确率超过 Copilot,另外生成速度也比 Copilot 快 36%。
现如今,AIGC 逐步融入软件研发的各个阶段,大模型也推动了人机协同模式发生新的演进。在这样的背景下,本论坛中阿里云算法专家张昕东带来了《人机协同趋势与效果提升实践》的主题演讲。
AIGC 所带来的新人机协同模式,大体可分为三个阶段:
一是 LLM as Copilot,主打人机对话能力,可解决单点事务性工作效率问题。
二是 LLM as Agent,主打自主完成任务能力,可解决复杂任务协同效率问题。
三是 LLM as Facilitator,主打跨领域复合型整合能力,可解决信息整合、分析、决策问题。
紧接着,张昕东揭示了当前人机协同模式存在的普遍挑战。首先在输入长度上,每次问答无法采集和输入所有知识,过长的上下文稀释信息,影响性能;其次是推理速度,补全等高频业务场景需要低延时交互,多轮交互,自主规划等依赖快速迭代;再者是频繁幻觉出错,依赖人类互动纠偏,多轮交互依赖单轮鲁棒输出和格式;最后是协同惯性,人类还处于从个人编程到辅助编程的适应阶段,常常无法描述清楚需求和给到完整上下文。
基于人机协同模式三个阶段的特点,张昕东表示:目前处于 Copilot 模式,且正在加速发展,趋向成熟;同时 Agent 模式也初见端倪,即将投产。
从当前人机协同模式的现状来看,面临的最大痛点就是效果问题。为此,张昕东结合通义灵码的实践经验,分享了以下 4 种效果提升手段。
望:眼观六路,采集必要输入
在代码生成过程中,大模型有时会产生“幻觉”,张昕东指出这不仅是 AI 的问题,即使是人类开发者也需要通过查看相关代码片段、调用动态方法以及使用 IDE 的语法分析工具来确保代码的准确性。为了克服这个问题,可以在大模型训练阶段构建一个大规模离线跨文件数据集,具体步骤包括数据清洗过滤去重、元信息索引、区域信息解析和跨文件还原。进而,在大模型推理阶段实现跨文件感知,提高代码生成的准确性、减少“幻觉”。
闻:耳听八方,贴合用户习惯
让模型和工具适应用户的使用习惯,需要考虑触发时机和生成粒度。对此,张昕东建议可通过 few shot 方式给到模型输入,通过提供追问引导用户完善需求,另外让用户自定义额外要求,以此让模型感知仓库和用户的行为习惯。
问:韦编三绝,拆解细分需求
基于安全高效的库内检索,进一步构建企业级检索增强方案,其中包含 RAG 检索服务、Embedding 服务、向量服务和 SFT 模型微调,实现通过统一的入口将知识赋能给用户,提升整体效率和用户体验。
切:晴空一鹤,自主拟人协作
到了这一步,研发领域需要多智能体协同,例如产品经理 Agent、架构师 Agent、项目经理 Agent、工程师 Agent 和测试 Agent 一起协作,最终进化为 Multi-Agent,基于 AI 调度共同完成任务。
关于对未来 AIGC 研发赋能展望,张昕东表示:“不管未来 AI 怎么变,有两点是不会变的。一是 AI 一定会融入到我们研发的方方面面,二是 AI 一定会帮助人类得到更好的研发效率跟研发体验。”
以 GitHub Copilot 为代表的 AI 开发助手,目前正在极大提高开发者的编码效率和准确性。而蚂蚁集团高级技术专家、OpenSumi 负责人王兴龙认为,当前研发插件存在种种限制,导致企业只能通过 IDE 开放出来的有限 API 来做代码研发助手,无法与 IDE 做更加深度的集成。
“当前智能研发插件陷入了困境。”王兴龙表示,智能研发插件有很强的依赖性,即这些插件必须依赖于 IDE 提供的插件 API。而这种依赖性意味着插件的功能和性能受限于 IDE 自身的能力和接口,导致无法完全发挥 AI 的潜力。
随着大模型 AI 技术的不断突破,这一问题变得更加突出。王兴龙指出,尽管 AI 能力的上限不断提升,但智能研发插件只能实现其中的 50%,而 AI 原生 IDE 却能够实现 100%。这种差距表明,传统的插件模式已经无法跟上 AI 技术发展的步伐,难以满足现代软件开发的需求。通过这些观察,王兴龙提出了未来智能研发的全新模式:不再是简单的“插件 + AI”,而是“IDE + AI”。
作为国内唯一一款开源 IDE 框架,OpenSumi 已经完成 IDE 向 AI IDE 的转型。基于 OpenSumi 的实践经验,王兴龙详细介绍了 AI 原生 IDE 框架的核心思路:
(1)行为模式的转变。传统 IDE 通常通过命令行或图形界面来下达命令,而 AI 原生 IDE 则转变为通过描述意图来执行操作,使得开发过程更高效。
(2)以“用户诉求”为中心,将场景下的相关任务整合在一起。根据用户的需求自动调配各种资源和工具,以此大幅提升开发效率,减少开发者在不同工具之间切换的时间和精力。
(3)交互模式的变革。新模式下,编辑器与 AI 交互的区域成为最核心的区域。开发者可以更便捷地获得 AI 的支持,无论是代码生成、错误提示,还是优化建议,都可以在一个集成的界面完成。
(4)最后,确保极低的切换成本。
紧接着,王兴龙分享了其团队在开发 AI 原生 IDE 框架过程中的宝贵经验与反思。
首先他强调“数据优先”,为了确保 AI 原生 IDE 能够提供高质量的功能和服务,需要对数据进行微调和评测。其次,王兴龙建议选择高频场景作为切入点,例如开发者在日常工作中使用频率极高的代码补全和 Inline Chat。此外,在构建 AI 原生 IDE 框架的整个过程中,需以规模、使用率、采纳率这三个核心指标为驱动。通过持续监测和优化这些核心指标,能在很大程度上确保 AI 原生 IDE 在实际应用中实现最佳效果。最后,聚焦到 AI 原生 IDE 背后的关键技术,王兴龙主要介绍了最重要的代码补全相关技术:可通过 FIM(Fill In the Middle),BlockFIM 和仓库级补全,来提升代码补全技术。
谈及对未来的规划,王兴龙表示:“不论是插件还是 IDE,目前还处于以人为主、AI 为辅的阶段,但在智能 Agent 这一人机协同新范式下,未来必将演进为 AI 为主、人类仅需简单调整的时代。”
正如以上嘉宾演讲的内容所说,从代码生成到自动化测试,AI 的应用正在彻底改变传统软件研发流程。然而,随着 AI 技术的不断进步,如何将这些技术有效地融入实际的软件开发实践中,依然面临诸多挑战。
在本论坛中,阿里通义灵码产品技术负责人陈鑫、腾讯云开发者AI产品负责人汪晟杰、字节跳动豆包MarsCode团队技术专家天猪和蚂蚁集团高级技术专家王兴龙在 CSDN &《新程序员》执行总编唐小引的主持下,围绕“AI 编程时代,软件研发落地实践的挑战”的主题,展开了一场更为深度的技术探讨和经验分享。
(从左到右依次为:唐小引、陈鑫、汪晟杰、天猪、王兴龙)
针对企业该如何用 AI 代码助手实现 ROI 最高的疑问,陈鑫认为采纳这类产品并非最大的问题。关键问题在于如何让企业所有员工,无论新老,都能高效使用大模型工具。他提到了一个“两极分化”的现象:初级员工通常对大模型技术表示高度认可,资深员工却有抵触心理,担心其可能会替代他们的工作。因此,企业需要开发个性化的能力,使大模型真正理解和辅助员工的工作,增强其对技术的信任感。尽管 AI 编程工具的初期成本可能较高,但陈鑫相信从长远来看,可能会实现 20%、30% 甚至 50% 的效能提升,这将极大推动企业的发展。
在 AI 编程落地过程中,用户隐私和安全性是所有开发者都非常关心的问题。对此,汪晟杰首先指出安全性不等同于私有化部署,还包括语料、提示词、伦理等方面,以及处理敏感问题时可能拦不住的情况。这就需要应用端和模型层面的配合,甚至可能需要其他模型来干预。不论在公有云环境还是私有化场景中,都需要有过滤机制,同时在数据输入到输出的整个过程中进行全链路加密,确保不会将数据存储在磁盘上或用于模型的二次训练。
除了安全性,相关体验指标也是用户在选择代码补全产品时重点考虑的一个因素。在这个方面,天猪认为采纳率虽然重要,但很容易被操控,不应完全依赖它,还需要结合更全面的指标来评估 AI 编程工具的实际效果——CPO(Character per opportunity,由尝试率、反馈率、采纳率、每次采纳平均的 token 数等五个因子相乘得到)。他表示:“采纳率和 CPO,一个是体验指标一个是真实价值,这两个数字其实要结合到一起去看。”
谈及 AI 影响下本地 IDE 和 Cloud IDE 的变化,王兴龙指出,对于用户来说,AI 的来临并不会在很大程度上影响他们原本的选择,因为二者都可以通过 AI 技术提升开发体验。但对于开发团队来说,这或许是一个弯道超车的机会:“有了 AI 加持,我们可以在自研过程中跳过一些比较难的事情,而这对于 VSCode 系的 IDE 来说,可能是弯道超车 IntelliJ IDEA 一个机会。”
在圆桌讨论的最后,陈鑫抛出了一个十分值得开发者深思的问题:“AI 时代总有一天会变成 AI 为主、人为辅,到时候我们还会需要一个非常强大的 IDE 吗?相比之下,一个能随时与人频繁交互的 IDE 可能更重要,而那时 Cloud IDE 的拐点可能就要到了。”
以上,便是本场“软件开发智能化”论坛的精彩内容。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。