回顾计算机发展初期，当时软件并没有被单独划分为一个学科，软件开发也更多被视为一种开发者基于自身直觉和经验而展开的“艺术”。直到 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 进行智能研发的思考与探索
提及软件智能研发，
蚂
蚁集团研发效能技术负责人姜伟
带来了《基于 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 必备三大要素：开发者体验、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）和动态调试（断点调试，通过运行来逐步获取执行链路的上下文）和最终测评，来实现高质量的代码自动修复。
辅助决策 - 提供高质量回答
目前多数情况下 AI 在编程中的角色只是辅助，但天猪表示由 AI 驱动编程的未来已经可以看到一些苗头了。在演讲最后，他再次强调 AI 与人类并非敌对关系：“
AI 与人类不是竞争关系，我们希望打造一款软件，能让开发者的效率变得更高，从而能让开发者成为超级程序员，把更多的时间和效率花在思考和创造上
。”
刘政宁：基于计图框架的代码大模型
以 GPT 为代表的自然语言大模型的出现，催生了以大模型为技术基底的代码自动生成技术的快速发展。而
非十科
技 CTO 刘政宁
认为，尽管类似自然语言大模型，都是语言生成，但代码生成具有固有的特点，如语法结构、逻辑关系、长上下文等，不能简单直接套用自然语言
大模型。
刘政宁解释道，自然语言大模型可以与知识图谱结合，但程序语言的分析难以建立知识图谱，需要建立抽象语法树作
为中间表征。不仅如此，代码生成对正确性的要求也远高于自然语言生成。因此代码大模型训练对准确度的要求很高，通常需要更大的参数量和更多的数据，也就导致了更高的资源需求和更长的训练时间。
资源要求高、推理延迟大、部署成本高……这些大模型训练过程中的常见难题，到底该如何解决？刘政宁给出的答案是：
国产深度学习框架计图（Jittor）
。
Jittor 由清华大学推出，支持国产芯片与国产操作系统，拥有 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
，主打跨领域复合型整合能力，可解决信息整合、分析、决策问题。
紧接着，张昕东揭示了当前人机协同模式存在的普遍挑战。首先在输入长度上，每次问答无法采集和输入所有知识，过长的上下文稀释信息，影响性能；其次是推理速度，补全等高频业务场景需要低延时交互，多轮交互，自主规划等依赖快速迭代；再者是频繁幻觉出错，依赖人类互动纠偏，多轮交互依赖单轮鲁棒输出和格式；最后是协同惯性，人类还处于从个人编程到辅助编程的适应阶段，常常无法描述清楚需求和给到完整上下文。
