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 进行智能研发的思考与探索
提及软件智能研发，蚂蚁集团研发效能技术负责人姜伟带来了《基于 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 工程师将替代人类软件工程师完成各类研发工作，届时软件开发不再是“脑力”劳动密集型行业，编写软件效率将急剧提升。
刘兴东：京东的 AIGC 革新之旅：通过 JoyCoder 实现研发提效
在这场由生成式 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 想要提升研发者的幸福感，实现快乐编程的目标。
天猪：从研发视角聊聊字节跳动的 AI IDE
在大语言模型（LLM）的加持下，工程和应用层面的创新日新月异，在开发者最为熟悉的研发领域亦是如此——在这之中，我们需要怎样一款 IDE？在字节跳动豆包MarsCode团队技术专家天猪看来，下一代 AI IDE 必备两大要素：开发者体验和 AI 原生支持。
（1）追求开发者体验
不仅要颜值在线，下一代 AI IDE 还需确保质感、交互体验，即打造开发者日常爱用的 IDE，拥有秒级极速启动和 UI 交互优化专项。另外灵活组装 + 可定制化也是提高 IDE 开发体验的一个重要途径。
与此同时，若下一代 AI IDE 能实现开箱即用的云端开发环境，则具有能力完备、隔离性高、环境一致等优势。但天猪也指出，这个方案的推进存在难点：一是复杂度高，具备较高的技术门槛，二是资源开销成本高，需专项优化。对于后者，天猪认为可通过成本审计、深度定制调度策略和碎片整理，以提升资源利用率，同时智能休眠策略，也能实现更快的回收和冷启。
（2）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 一定会帮助人类得到更好的研发效率跟研发体验。”
王兴龙：大模型时代企业如何打造专属 AI 原生 IDE
以 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 技术的不断进步，如何将这些技术有效地融入实际的软件开发实践中，依然面临诸多挑战。
在本论坛中，阿里通义灵码产品技术负责人陈鑫、腾讯云开发者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 的拐点可能就要到了。”
