CodeWisdom
基于大模型的软件智能化开发实践
微访谈·第三十四期
背景介绍
自从ChatGPT于2022年底横空出世，大语言模型（简称“大模型”）在软件工程领域学术和产业界都得到了广泛关注。当前，基于大模型的代码补全、推荐、解释和问答等智能化支持得到了广泛应用。然而，当前这种智能化开发支持很大程度上仍然是局部性的，而企业在开发质量和效率上并未感觉到显著提升。另一方面，大模型的出现加剧了开发人员的分化，专家型开发人员和普通开发人员在大模型的加持下能力差异比以往更大。那么，当前软件企业在基于大模型的智能化开发方面开展了哪些实践？取得了什么样的效果？面临的问题和瓶颈在哪里？未来应当如何突破？围绕这些问题，本次微访谈邀请了多位来自企业一线的技术专家分享实践经验，分析相关问题，同时对未来的发展方向进行展望。
主 持 人
彭鑫
复旦大学
复旦大学计算机科学技术学院副院长、教授，教育部长江学者特聘教授。中国计算机学会（CCF）杰出会员、软件工程专委会副主任、开源发展委员会常务委员，中国汽车工程学会汽车基础软件分会副主任，《Journal of Software: Evolution and Process》联合主编（Co-Editor），《ACM Transactions on Software Engineering and Methodology》、《Empirical Software Engineering》、《Automated Software Engineering》、《软件学报》等期刊编委。2016年获得“NASAC青年软件创新奖”，2023年入选上海市东方英才拔尖项目，2024年获得“中创软件人才奖”。主要研究方向包括软件智能化开发、云原生与智能化运维、泛在计算软件系统、智能网联汽车基础软件等。研究工作多次获得IEEE Transactions on Software Engineering年度最佳论文奖、ICSM最佳论文奖、ACM SIGSOFT杰出论文奖、IEEE TCSE杰出论文奖等奖项。担任2022年与2023年CCF中国软件大会（ChinaSoft）组织委员会主席与程序委员会共同主席，以及ICSE、FSE、ASE、ISSTA、ICSME、SANER等会议程序委员会委员。
访
谈
嘉
宾
蒋奕
华为2012实验室IDE内核科学家/首席专家，软件IDE实验室主任，当前主导AI Native IDE的设计、研发与落地。曾作为首席架构师主导华为第一个自研编译器HCC以及方舟编译器的架构设计与产品化研发。多次获得代表华为公司最高荣誉的金牌个人奖以及金牌团队奖。加入华为之前，先后在Intel，Nvidia，Apple等公司负责编译器、工具链、程序分析工具、调试工具等全栈设计和开发，涵盖GCC，LLVM，Open64，Intel Compiler等主流编译器。
张刚
软件工程博士，资深架构师，CCF 软件工程委员会执行委员。《软件设计：从专业到卓越》、《大模型辅助软件开发：方法与实战》作者。前阿里巴巴资深技术专家、贝尔实验室杰出工程师。在需求分析、架构设计和实现等领域有超过20年的一线实践，长期致力于先进软件工程实践的探索和推广。
茹炳晟
腾讯Tech Lead，腾讯研究院特约研究员，中国计算机学会(CCF)TF研发效能SIG主席，“软件研发效能度量规范”团体标准核心编写专家，中国商业联合会互联网应用技术委员会智库专家，中国通信标准化协会TC608云计算标准和开源推进委员会云上软件工程工作组副组长，国内外各大技术峰会的联席主席，出品人和Keynote演讲嘉宾，公众号“茹炳晟聊软件研发”主理人。著有多本技术畅销书《测试工程师全栈技术进阶与实践》《现代软件测试技术之美》《软件研发效能提升之美》和《多模态大模型技术原理与实战》等，译有《整洁架构之道》《现代软件工程》《DevOps实践指南（第2版）》和《软件设计的哲学》等。
黄峰达
Thoughtworks AI 辅助研发工具与开源解决方案负责人，开源 Unit Mesh AI 辅助研发方案的发起人，包含 AI IDE 插件 AutoDev 等工具；智能体编程语言 Shire 的创始人，架构治理平台 ArchGuard 的核心开发者。他在生成式 AI 辅助需求分析、开发和质量保障方面为多家金融和互联网企业提供落地支持，著有《前端架构：从入门到微前端》《自己动手设计物联网》等多本书籍。
狄鹏
蚂蚁集团的资深技术专家、正高级工程师，同时还担任新南威尔士大学兼职副教授和浙江大学博导。他在软件工程、编程语言和智能研发领域的研究成果发表于PLDI、OOPSLA、ICSE、FSE、Micro等顶级会议。2023年，由他的团队开发的蚂蚁代码大模型CodeFuse开源，并在蚂蚁集团的全流程研发中广泛应用，显著提升了蚂蚁集团内部研发流程的效率与智能化水平，成为推动技术创新与实践结合的典范，并获得蚂蚁集团TStar最高技术奖。
刘力华
阿里云云效代码智能负责人，通义灵码核心技术专家，主要从事代码智能生成、代码智能评审、缺陷检测等领域的探索及技术应用。
李鹏
未来速度 Xinference联合创始人，曾任职平安资管管理公司模型工程化团队负责人，华为 2012 实验室分布式 Lab 副首席架构。对于分布式、GPU和其他异构及高性能计算方式有深入的研究和大型工程实践，熟悉大模型推理优化及数据处理方法，目前专注于大模型在企业和行业场景的可靠工程化落地。
赵俊民
荣耀软件工程技术负责人，主要研究如何使用大模型/程序分析技术提升架构和代码质量
访谈主题
基于大模型的软件智能化开发实践
01
您以及您所在的企业围绕基于大模型的软件智能化开发开展了哪些探索和尝试？目前效果如何？
02
当前，基于大模型的智能化开发支持（例如代码补全、生成、解释、重构、缺陷检测和修复等）在企业得到了广泛应用，但企业在开发质量和效率上并未感觉到显著提升。此外，也有一些声音提到大模型应用对代码质量也带来了一定的负面影响。您是如何看待这一问题的？导致这些问题的原因在哪里？
03
大模型的出现似乎加剧了开发人员的分化，专家型开发人员和普通开发人员在大模型的加持下能力差异比以往更大。您是如何看待这一问题的？对开发人员在大模型时代如何提升自己的能力和价值有什么样的建议？
04
围绕软件智能化开发这一主题，近期大模型及相关的人工智能技术方面有什么值得注意的进展？检索增强（RAG）、思维链、多Agent等人工智能技术对于提升软件智能化开发水平有着什么样的作用？另外，近期Cursor通过人机交互和产品设计上的创新将大模型与IDE及项目上下文有机结合，得到了广泛的关注，您对此有什么看法？
05
您对基于大模型的软件智能化开发的发展前景怎么看？企业应当如何从基础大模型、人工智能技术应用、软件工程基础能力建设等各个方面努力以提升整个企业的智能化开发水平？
Q&A记录
Question 1
主持人：您以及您所在的企业围绕基于大模型的软件智能化开发开展了哪些探索和尝试？目前效果如何？
蒋奕：
我们华为IDE去年做的是代码生成和补全。特别是C与C++上的，并且摸索了针对不同代码风格的领域模型构建sop；
今年在此基础上主要是做2个方面的探索，第一是新语言在少语料情况下的代码生成比如仓颉代码生成，第二是工程级代码生成，比如在鸿蒙领域的鸿蒙UI生成和元服务卡片生成；
除了代码生成领域的一些单点能力，我们也在探索，如何从软件工程的视角系统性的把ai能力“串”起来，成为一个新的IDE。
观点讨论
@彭鑫：@蒋奕 嗯，除了一些后端能力之外，IDE上的前端交互也很重要。最近的Cursor就是IDE上的创新。
@蒋奕：@彭鑫 是的，软件开发过程非常复杂，我们之前可能关注的很多是ai解决确定性的问题，IDE上可能面临的不同类型的任务，这是一个大的挑战。
@张刚：@蒋奕 这个工作特别有意义，代码生成只是整个软件开发过程中非常少的部分。和其他环节之间不连贯的话，反馈速度也会受到影响。
张刚：
作为一名软件开发者，我主要是以“应用大模型”为主。从去年到现在，做了许多利用大模型做辅助开发的尝试。其中有一个很完整的演示开案例“共享出行“，代码也做了开源（https://github.com/leansd/)。
从效果上看，首先最重要的还是辅助编码，这个节省了个人大量的时间。 特别是，我发现AI可以很好地和DDD的结合、和自动化测试的结合，非常有效。其次是架构。不是说大模型有多强的架构设计能力，而是因为它知识面很宽，能很好地弥补“未知的未知”的问题。 在需求方面，大模型对我的帮助其实比较一般。
观点讨论
@彭鑫：@张刚 可以介绍一下配套的大作。
@张刚：@彭鑫 嗯，补充一下我做前面的开源案例的时候，由于我刻意地想做一个开发过程实录，所以也同步记录了开发过程，最后把它整理成了一本书《大模型辅助软件开发：方法与实战》，前面在这个群里也给各位专家介绍过。
黄峰达：
我们公司在在全球有19 个国家，48个办公室，涉及到大量不同的部门和团队。在其它国家，我们看到国外对于 AI 遗留系统改造和迁移的需求，是远大于辅助开发。在国内的交付部门里，我们的尝试主要覆盖了需求、开发和测试、运维都有所覆盖 ，另外一个是结合 Thoughtworks 内部的技术实践和知识库的工具，如 AskThoughtworks 或者辅助研发团队 AI 助手 Haiven，融合软件开发的内部知识库，加速 SDLC ；
从我们之前的统计和分析效果来看，我们在不同的开发环节中实现了 2% 到 13% 的交付效率提升，尤其是在项目初期体现得更为显著。不过，对于大部分已有项目的开发环节提升会在 5% 以下，寻找变更点才是老系统的痛点；
在我司除了可以使用 Cursor 和 GitHub Copilot 等工具，我们也开源了 AutoDev IDE 插件（https://github.com/unit-mesh/auto-dev），也帮助了不少企业在内部落地 AI 辅助开发。
观点讨论
@彭鑫：@黄峰达 “ AI 遗留系统改造和迁移”具体是指？特别是这里的“AI遗留系统”是指基于AI实现系统改造迁移，还是改造的对象是AI系统？
@黄峰达：@彭鑫 国外比较聚集的是 AI 实现已有系统的改造迁移，比如大型主机，在国外很多 AI 辅助研发工具都有所涉及，如 Bloop、Tabnine 等等。
@彭鑫：@黄峰达 涉及软件翻译和迁移？
@黄峰达：@彭鑫 对，比如主机的 PL/SQL 之类的。
@彭鑫：@黄峰达 那应该跟架构现代化改造相结合，比如微服务化？
@黄峰达：@彭鑫 嗯 ，微服务也是一类目标。
@刘力华：@黄峰达 交付效率的提升如何衡量的？
@黄峰达：@刘力华 从结果来看，效率以 DORA 四个指标为主来看，几乎没有变化 。所以，2%～13% 更多的是关注开发环节。
茹炳晟：
我们在局部代码生成领域的应用是很乐观的，尤其是一些函数级需求比较明确的场景，代码局部生成辅助提效很明显，但是在更大的规模的代码生成场景下，效果还是和期望有差距。
观点讨论
@彭鑫：@茹炳晟 这个应该是比较直观的，开发人员个体对大模型的智能化效果比较有感，但团队和企业暂时好像感觉不明显。
@茹炳晟：@彭鑫 这个观点其实在最新版的DevOps DORA报告中也得到了验证。
@蒋奕：我们的思想是采取编译器前中后端的方法。
@李鹏：@蒋奕 这个怎么理解啊？
@蒋奕：@李鹏 把大规模代码生成分成几个阶段，意图理解阶段引入大模型和一些传统方法，代码生成阶段用的是确定性的方法。比如我们的UI生成，我们用一组表示UI－IR做中间表示，andriod apk 到IR可以引入大模型，IR到最后的鸿蒙代码生成是传统代码生成技术，保证代码生成确定性和质量
@李鹏：@蒋奕 那中间层的话，UI-IR 这块，IR 是不是还需要模型来微调？
@蒋奕：@李鹏 UI－IR是一组定义好的界面基本元素和组合规则，但是确实前端生成高质量的IR需要微调
@彭鑫：@蒋奕 意图理解阶段产生的是确定性逻辑表达的程序，例如伪代码？否则代码生成阶段无法用确定性方法实现。而且代码生成阶段的思路是不是跟基于DSL的低代码开发类似？
@蒋奕：@彭鑫是这个思路，本质就是想让传统技术和ai技术在链条不同位置发挥最大作用。
@彭鑫：@蒋奕 嗯，AI和DSL结合其实也是数据与知识双驱动这个思路的具体体现。
@蒋奕：@彭鑫 没错，领域知识和建模方法是我们DSL，IR的基石，这也算是给大模型减负。
赵俊民：
目前荣耀团队基于软件作业流水线引入或构建了Agent辅助研发效率提升工具集，覆盖了需求、开发、测试、运维等阶段，主要包括 1）代码生成助手：AIGC辅助代码补全 2）需求助手：AIGC辅助需求分析 3）代码QC助手：AIGC辅助代码检视（QC） 4）代码解释助手：AIGC辅助代码解释 5）问题修复助手：AIGC辅助问题修复 6）测试助手：AIGC辅助测试设计 7）缺陷管理助手：AIGC辅助测试问题单去重和查询 8）智能运维助手：AIGC辅助运维知识问答 9）AIGC辅助前端代码生成agent 10）AIGC辅助UX规范检查agent 11）AIGC辅助生成UT代码agent
在研发和IT经过试点，AIGC辅助代码开发对大家的开发效率整体上看有提升的。
1、使用效果-试点项目数据分析：代码过程质量和人均代码提交量综合有改善
2、基于高频用户数据分析，代码过程质量和人均代码提交量均有改善；基于问卷和访谈，超过70%的用户认为对开发效率和质量有帮助
3、 使用效果-试点项目用户评价(CoMagic&CoPilot)：超过75%的用户认为对开发效率和质量有帮助
当前代码生成助手业界比较成熟，目前已经在荣耀公司内部推行，其余助手还在beta阶段试用中。
李鹏：
我们是做推理服务的，自己在开发过程中，以及从推理层面对 AI 辅助编程的支持上面做了一些尝试。
开发过程中很早就采用了 github copilot ，最近也在尝试 cursor。在推理层面，针对本地部署的代码生成模型都在 xinference做了内置。例如 deepseek、llama-code等大模型
目前看来，编程辅助开发的效果不错，开发效率有较大提高。在测试、问题排查和修复方面还在探索是不是有更好的办法来提高。
观点讨论
@李鹏：微服务是否适合代码生成，我也有一点疑问。
@彭鑫：@李鹏 微服务内部代码生成应该跟单体关系不大，特殊之处在于服务拆分和部署架构。
@李鹏：@彭鑫 理解，因为我理解大模型是 stream。微服务的服务拆分和架构感觉很难隔离。
刘力华：
我们阿里云云效在智能编码、代码评审、缺陷检查等领域进行了探索，特别是我们发布的通义灵码在智能编码领域达到了不错的效果，显著的提高了开发者的编码效率，其中代码续写、注释生成、提交信息生成等是开发者高频使用的功能。在缺陷检查领域，很多场景上还无法赶超传统工具，往往只能发现一些表面问题，好处是实现成本相对较低。
狄鹏：
蚂蚁集团在基于大模型的软件智能化开发方面进行了多项探索和尝试。去年发布了AI智能编程工具 CodeFuse。CodeFuse是蚂蚁自研大模型，具有智能补全、添加注释、解释代码、生成单测、代码优化等功能。并提供IDE 插件，Cloud IDE、等多种应用方式。今年4月，CodeFuse推出“图生代码”新功能，支持开发人员用产品设计图一键生成代码，大幅提升前端页面的开发效率。
最近我们还推出了CodeFuse VAT（Virtual Agent Team）致力于打造人机协同的软件研发新范式，构建覆盖软件研发全生命周期的多智能体协同的智能研发体系，助力软件研发效能的提升。
观点讨论
@彭鑫：@狄鹏 应用效果如何？
@狄鹏：@彭鑫 在蚂蚁应用非常广泛，深入到研发的各个环节。
@张刚：@狄鹏 请教一个问题， “图生代码”创建的前端代码，和人类写的代码差别大吗？我一直觉得这个很有意义，但是比较担心它的模块化和可维护方面的情况。
@茹炳晟：@张刚 “图生代码”我觉得关键是要代码的规范性以及能够使用企业自己的前端控件库，否则就是一次性的生成，价值估计只能在MVP中体现了。
Question 2
主持人：当前，基于大模型的智能化开发支持（例如代码补全、生成、解释、重构、缺陷检测和修复等）在企业得到了广泛应用，但企业在开发质量和效率上并未感觉到显著提升。此外，也有一些声音提到大模型应用对代码质量也带来了一定的负面影响。您是如何看待这一问题的？导致这些问题的原因在哪里？
蒋奕：
我觉得首先大部分人demo都选的best case，使得大家对ai辅助研发的期望会比较高。本质的原因，我觉得在于1）对于软件开发这样一个复杂度非常高的系统工程，现今ai辅助研发是否解决了最耗时和最复杂的问题。 2）ai是否能催生新的软件开发的过程，习惯，模式，而不仅仅是让旧的模式更好。这可能是ai辅助插件与cusor这样的智慧化IDE的区别。
张刚：
大家日常说的开发效率，不仅仅是写代码的效率。特别是在大多数公司里面，很多开发任务都是基于既有的系统的演化，程序员每天也写不了多少代码。编码在整个研发活动的比重，也就在10%、15%左右的样子。 所以，如果不能在其他环节有所提升，那这个提效的效果肯定是有限的。但是，其他环节能不能也有效提升呢？我的初步探索是，还是有很大希望有比较大的提升的。 提效的关键不是写代码，也不是写需求文档，而是利用写代码的速度优势，带来更快的反馈，从而推动其他环节的效率。 这个不太容易，它涉及到流程、组织和架构等多个方面的变化。我比较容易做到，但是放到大公司里面，这个事就不太容易做。
质量方面的负面影响，我的体会不多，它生成的如果不好，那不要采纳就是了。这个前段时间彭老师的文章中提到了这个话题，确实有这种可能，只是我个人认为，这个核心还是要提升咱们从业人员的专业素养，这个不是大模型的问题。
观点讨论
@彭鑫：@张刚 “编码在整个研发活动的比重，也就在10%、15%左右的样子” ，这个似乎各个企业都是类似的反映。
@赵俊民：@彭鑫 赞同。
@狄鹏：@彭鑫 20%目前看是一个关卡。
@彭鑫：@张刚 大公司开发人员之间（包括与业务和产品经理等）经常要拉通、对齐，其实就是需求设计不清楚或不合理，职责不清、边界不明，导致经常停下来重新对齐。当然还有各类问题带来的返工以及需求变更等问题。
@茹炳晟：@彭鑫 这个过程本质是个“探索性过程”。
茹炳晟：
我理解的原因可能有以下几点：
1. 模型训练数据的局限性：大模型的性能依赖于训练数据的质量和多样性。如果训练数据不够全面，可能会导致生成的代码不够优化或不符合最佳实践。企业级代码有自己的“风格”，通用大模型对此没有特别优化。
2. 上下文理解不足：大模型可能无法充分理解项目代码的具体上下文或业务逻辑，导致生成的代码不完全符合需求。
3. 过度依赖代码生成来提升所谓的效率：开发人员可能对大模型生成的代码过于依赖，生成的代码是需要开发人员的检查和走读的，大量阅读代码的效率不见得比自己写好到那里去，本质是把“写作题”变成了“选择题”
4. 生成的代码包含隐性错误：生成的代码表面上完成了特定的功能，但是包含了隐性错误，如果隐性错误超过了开发人员的认知水平，就会被带入。
5. 生成代码的风格一致性问题：企业级代码是有“调性”的，生成代码的“调性”和原有不一致。
6. 反馈机制不足：缺乏有效的反馈机制来不断改进模型的输出和适用性，甚至出现改动方向的偏差。
局部提效是确定的，但是从全局价值来看，如果不解决需求和设计的问题，提效我的态度是中立的。
黄峰达：
只从 AI 辅助编程来看，我和一些团队聊过这个问题，结合个人的使用体验，我个人现在的结论是：
1. 开发环节效率提升不一 —— 受限于编程语言、研发流程和团队规范；
2. 代码质量是下降的。
效率上的话主要有两点：1. AI 工具，现有的 AI辅助研发方式对于增量代码提升比较有限，还是大量依赖于人来做分析，有一些环节缺乏工具配套，比如不熟悉代码库、缺少领域知识不会提问。2.流程角度，开发环节只是 SDLC 的一环节，如果我本身 DevOps 不成熟或者需求太少，缺少知识，这种提升就无从下手。
代码质量主要受：1. 团队平均水平的代码质量。也就是，别人写的代码的影响 —— AI 会参考当前代码文件和相关代码。别人喜欢用 if-else，你喜欢用 when 或者 switch，给你生成的就是 if-else。 2. 未经人工详细 review 的代码。我自身的体验是这样的，我之前还和几个 TL 聊过这个问题：你们在 code review 有没有发现，未经人工 review 的 AI 代码，他们的回答是：有，偶尔。可以反推，如果经典的 sonarlint、code review 质量环节缺少了，那么质量就下滑更严重。
观点讨论
@蒋奕：@黄峰达 使用大模型的人要有判断能力和检验的耐心，我们之前的观察是代码生成在传统开发领域的甜点3－5行。
@黄峰达：@蒋奕 但是人性是懒惰的，特别是用了 Cursor 的团队。
@蒋奕：@黄峰达 宽进严出的严很难把握啊，太严了用户负担太重，反之又控不住质量。
@张刚：@黄峰达 Cursor确实高效， 现在我觉得工作压力转移到确认Cursor生成的代码上了。
@黄峰达：@蒋奕 结合先前的架构治理平台 ArchGuard 的经验，我觉得 AI 生成内容的治理可能是未来几年的一个重点。
@彭鑫：@张刚 你觉得Cursor最核心的创新和突破是什么？
@张刚：@彭鑫 我觉得主要是体验：猜的准，便捷好用。
@彭鑫：@黄峰达 是的，现在这方面还不明显，三五年之后当AI生成的代码大量存在于企业代码库之后可能问题就会比较突出了，包括：未经过仔细推敲的代码带来的理解上的缺失以及质量缺陷。
刘力华：
开发效率指的范围比较大，包含分析、设计、编码、测试等阶段，编码只占其中一部分，通过一些开发者的反馈，这类工具在启发思路、生成胶水代码、Mock数据等很多方面还是有比较大的效率提升的，但是肯定会因人而异。除了编码阶段，其他阶段我们也在尝试通过大模型去解决一些高频的单点问题，这会比做一个通用工具去解决通用的问题会更实际有效。质量问题涉及的方面比较多，比如有了大模型生成后，开发者疏于Review代码，或者工具本身的生成质量不太高。这类问题通过Agent手段，或者代码评审阶段的大模型引入也能发现一些实际问题。当然，在部分场景下，大模型发现的问题还比较表面。
观点讨论
@彭鑫：@刘力华 “有了大模型生成后，开发者疏于Review代码，或者工具本身的生成质量不太高”：这个可能是我们需要注意的大模型应用带来的一些负面效应。
@刘力华：@彭鑫 所以CR还是很重要的，在CR中引入大模型，辅助传统工具去发现问题，目前大家用起来也还不错。
@黄峰达：@刘力华 + 1，CR 主要还得靠传统工具。
狄鹏：
在蚂蚁，智能研发被广泛应用到日常开发活动中。为了保证AI生成的代码质量，我们基于原有的研发风险质量的防范流程，将AI生成的代码进行单独统计。并依照蚂蚁的编程准则，围绕编程风格、风险质量、安全漏洞等几个方面，对了AI 和人工开发的代码进行了日常监控。对比千行故障率等实际数据，在蚂蚁的应用中，CodeFuse生成代码质量高于预期，堪比有经验的工程师。并且通过错题反馈的数据积累机制，这个效果还在明显提升。
观点讨论
@李鹏：@狄鹏 CodeFuse 做了一些什么工作啊，来提高这个代码生成质量。
@狄鹏：@李鹏 我们有错题反馈机制，来增强模型自身质量。
赵俊民：
内部也有声音提到AIGC辅助代码开发帮助不大，主要原因为业务逻辑相关的代码推荐准确率不高，主要原因包括：
1. 当前业界最先进的模型，例如gpt4o模型是saas服务，因为信息安全，公司部分场景无法使用，导致企业内部无法落地最先进的技术
2. 公司内部知识建立RAG知识库检索准确率低，导致Agent的准确性较低。公司内部的知识库质量参差不齐、格式多样，有表格类、文档类、图片类，导致数据处理复杂。表格类形式多样,文档类图文并茂，排版复杂
3. 目前开发特性都是在现有一个复杂的现有软件基础上进行演进开发，业务逻辑复杂，一个功能涉及到App，框架，内核，还会引入开源软件。大模型没有相关的知识，架构师和开发人员不知道如何把上下文输入给大模型，很难描述准确，所以对功能相关代码生成基本上帮助不大。
3）大模型的出现似乎加剧了开发人员的分化，专家型开发人员和普通开发人员在大模型的加持下能力差异比以往更大。您是如何看待这一问题的？对开发人员在大模型时代如何提升自己的能力和价值有什么样的建议？
观点讨论
@彭鑫：@赵俊民 “目前开发特性都是在现有一个复杂的现有软件基础上进行演进开发”：这是很多企业存在的问题，那就是软件开发任务基本都是维护型任务，需要在理解原有软件需求和设计上下文知识的基础上进行代码推荐和生成。
@赵俊民：@彭鑫 是的，现在基本都是这样的开发，架构非常复杂，横跨多个软件层，多个进程，端云服务。
@彭鑫：@赵俊民 是，架构复杂性绕不开。架构是从需求到代码的桥梁，缺了这一次连问题定位可能都变得很难。
李鹏：
新东西的出现总是会有一些探索，AI 开发最近一年发展较快。也出现了一些新的模式和想法，例如直接生成软件。但是可能往前走的太快，得到的问题也很多
从企业来看，因为存在大量已有代码。采用激进的AI 开发模式可能会带来很多问题。可能可取的一些做法，例如针对现有代码的问题扫描、文档补全 、测试用例和覆盖完善可能更容易带来收获。
另外，从开发模式上，开发人员在逐渐适应 copilot 辅助生成。但是 copilot 生成的方式是随机的，对企业来说，规范也很重要。如何让 copilot 的生成也能符合规范，可能是需要优化的一个方面。
Question 3
主持人：大模型的出现似乎加剧了开发人员的分化，专家型开发人员和普通开发人员在大模型的加持下能力差异比以往更大。您是如何看待这一问题的？对开发人员在大模型时代如何提升自己的能力和价值有什么样的建议？
蒋奕：
专业型工具永远都是加大分化的，所以除了掌握prompt这类看的见的使用大模型的技巧，我认为还得有把握问题本质的能力，比如软件设计，架构抽象，这些是当下大模型还做不好的事情，基于他们大模型反而能做比较好的填充。 另外就是要能识别和评判大模型给出的结果。
张刚：
我赞同这个观点。 大模型对不同个体带来的开发效率差异确实非常大。在我看来，大模型是个能力放大器，开发者有1，那放大出来可能是100，如果有10， 那放大出来就是1000， 这个差值就很厉害了。而且这个差异，非常依赖于个体的专业素养，很难被大模型的进步弥补。
从另外一个视角看， 大模型是对开发人员的巨大机会。以前开发者要在和其他人对齐任务、对齐认知上花很多时间，这个很难。现在的开发者，工作粒度可以上升一个层级，有机会不依赖其他人，就能实现完整的端到端项目，甚至去做一个完整的业务，从而在价值层次上协作。
观点讨论
@彭鑫：@张刚 我想象的情形是越是初级程序员越是滥用大模型，因为他们不知道如何分解问题、什么时候该找大模型帮忙以及如何为大模型提供必要的信息。
而专家型程序员更清楚大模型能做什么不能做什么，所以只会在适当的抽象层次和问题粒度上去找大模型帮忙，并且善于位大模型准备上下文并及时确认大模型的输出并提供反馈。
我经常想像你这样的专家碰到大模型之后那种发自肺腑的愉悦和兴奋，因为不用再带着一群初级程序员干活了，能交给他们的活大模型都能干，而且又快又好还不抱怨、
@张刚：@彭鑫 确实有这个感觉，现在想做点啥，容易了很多。
@蒋奕：@彭鑫 的确如此，了解工具不能干什么或者什么时候有风险是关键因素。
@彭鑫：@张刚 大模型给我们带来的是个巨大的机会。初级程序员岗位会减少，但随着新型数字化和智能化浪潮的发展，软件的疆域还会大幅扩大，需要专业软件工程师参加的软件开发任务会越来越多。
@彭鑫：@张刚 从你的分享看，你已经成为可以身兼多职的超级程序员了。
茹炳晟：
我非常同意这个观点，大模型的使用会让强者愈强，在合适的粒度上使用大模型，可以控制研发团队的人员规模，使开发团队保持小型化，这将大大提升沟通和协作的效率，超级个体越有可能成为现实；优秀的工程师可以聚焦在需求理解，设计优化这些更需要人的场景。
所以大模型的使用，我感觉促进了软件工程的返璞归真，各类需求文档以及设计文档的价值再次被提到重要位置。
观点讨论
@彭鑫：@茹炳晟 赞同，所以Bertrand Meyer说：ChatGPT这类大模型并不会带来编程的终结，而是会复兴软件工程领域的一些根本性的技术，如需求分析、精确的规格说明以及软件验证（包括动态测试和静态分析）。
@张刚：@彭鑫 从某种角度， 这也就是开始让“开发者”回归到真正的“开发”上来，而不再是每天纠缠在琐碎的技术细节上。
@彭鑫：@张刚 是的，开发人员关注的抽象层次进一步提升了。
@茹炳晟：@彭鑫 语言越来越“高级”，越接近问题域就越“高级”。
黄峰达：
我是比较认可这个观点的。普通开发人员如何判断 AI 生成代码、设计是否正确？上个月，有个毕业生拿 ChatGPT 回答的领域驱动设计（DDD）问题来找我，说这个 AI 和他们 TL 回答的结果不一样。他们这种相当于是，一个意图，但是问法相近，结果却不一样了。对于资深开发人员来说，我就是对的，GPT 只需要按我的结果执行就行了。
所以，结论会变成，如何获取可信的“软件工程知识”吗？要知道，其实传统的软件工程知识也是并不可信的 —— 同样的领域驱动设计的解释，在不同作者眼里是不一样的。所以，最后架构设计还是会变成 by experience。
最后，我的建议：寻找快速校验的方式，来检验 AI 内容正确性。比如架构设计，可以快速生成 API、代码校验；生成业务代码时，可以快速生成个测试试试等等。
刘力华：
专家型开发人员有更多的经验积累，更好的架构及设计能力，通过大模型辅助，能够更高效的达成目标。普通开发人员能通过大模型弥补部分经验以及知识面的不足，但是目前的工具都还无法端到端的完美生成，中间还是需要开发人员去做干预，这也依赖开发人员自身的经验以及技术能力，否则一旦生成的代码存在一些隐藏问题，普通开发人员可能需要花费更多的时间去解决。此外，专家型开发人员会基于自身积累能更好的使用大模型，而普通开发者可能需要花费更多时间才能生成出自己需要的代码。我认为开发者不应完全依赖大模型，而不去提升自身的经验及技术能力，但是需要更好的去学会如何利用大模型工具的能力。
狄鹏：
大模型的出现确实有可能加剧开发人员之间的能力分化。对开发者的技能要求也提出了新的要求。开发人员需要对新技术的适应能力更强，能够迅速学习并利用大模型来增强他们的工作效率和成果，对其要求从单纯到代码开发转移到训练数据的开发。同时，随着智能研发的普及，开发者的精力逐渐从具体的功能实现转移到了对产品功能和系统架构的设计上，开发者的架构意识和设计能力变得更为重要。
赵俊民：
软件开发是一个频谱非常宽的工作，不同类型软件开发差异也很大。对于我们工作在Android平台上系统程序员，核心是挖掘系统软件质量问题，如稳定性和性能问题。对于如何快速理解现有代码和架构是非常重要的，开发人员可以通过大模型去解释一些代码，但是这些回答有可能是错误的，专业工程师有丰富的经验可以判定是否正确或者获得一些灵感。对于普通开发人员，不知道如何进行发问及其判定答案的正确性。大模型在专业深度上可能是不够的，如我们问虚拟机中Barrier设计原理是什么，回答比较粗浅。目前我觉得大模型对我最大帮助是在尝试一些新技术上，如学习Rust，eBPF上，可以快速做一个小原型，然后自己手工去迭代。通过AIGC工具可以快速查询一些知识，提升了知识检索的效率。
观点讨论
@彭鑫：@赵俊民 嗯，大模型本身也是个通才，什么都会一些但对专家型用户而言深度和专业性可能不强。
李鹏：
如果能够使用的好，对专家型和普通开发人员，应该都会有很大的帮助；
对开发人员来说，可能需要更多的提高对构建一个系统的方法。通过和模型的互动，让模型能够分步骤理解构建系统的过程是一个难点。这就需要工程方面有更多的一些创新，cursor 采用补充文档、codebase index、或其他 rag 方法能够在一个约束的问题下产生较好的效果；
大模型的出现正在加速开发人员能力的分化，但本质上这是一个能力重构和价值再造的过程。专家型开发者通过精准的提示工程、系统性思维和对AI生成代码的高级审查能力脱颖而出，而普通开发者则需要主动学习系统设计思维、培养批判性思考能力和复杂问题解决技能。在这个以AI协作为特征的新时代，开发者的核心价值正从"写代码"转向系统架构设计、创新需求提炼和与AI的高效协作。关键不在于被AI取代，而在于如何通过持续学习和创新性思考，有效放大自身能力，在人机协作中发挥独特价值。就像Cursor等工具所展示的，未来的软件开发将更加依赖于精细的需求拆解、上下文管理和对复杂系统的深入理解，这为开发者提供了重塑专业能力的宝贵机遇。
Question 4
主持人：围绕软件智能化开发这一主题，近期大模型及相关的人工智能技术方面有什么值得注意的进展？检索增强（RAG）、思维链、多Agent等人工智能技术对于提升软件智能化开发水平有着什么样的作用？另外，近期Cursor通过人机交互和产品设计上的创新将大模型与IDE及项目上下文有机结合，得到了广泛的关注，您对此有什么看法？
蒋奕：
直觉上我还是觉得我们现有的很多以插件形式存在的ai辅助能力，是让现有的开发过程和模式变得更好，并不是新的开发模式， 这可能是跟cusor这样我们所谓智慧化IDE的区别。我们有软件工程师的职位，并没有编码工程师，调试工程师，调优工程师，就意味着这应该是一个流式的开发模式，这里我认为单靠大模型能力是解决不了的，IDE是那个真正在开发中拥有上帝视角的角色，他有这个责任解决这个本质问题。
观点讨论
@彭鑫：@蒋奕 未来IDE应该成为开发人员的同一门户，文档阅读、协作交互、资料搜索等应该会融入其中。
@蒋奕：@彭鑫 我们最近在思考一个读代码的问题，ai来临以后，对于一个新手上手一个新的大工程；可能不同角度，不同来源产生不同的信息；那什么时候应该以何种方式给开发者推送什么信息？有的可能是文字，有的可能是流图，脑图等等。
@黄峰达：@彭鑫 还有工具生态，我还比较喜欢用 Copilot 的一个点是，IDEA 提供了大量的工具集成。而像 Cursor虽然是叫 AI IDE，但是不具备真正的 IDE 能力。
@彭鑫：@黄峰达 嗯，IDE首先是个集成开发环境。如果Cursor未来通过自然语言交互把各种插件能力都融入进来了，那就又上了一个台阶了。
@茹炳晟：@彭鑫 插件的能力都用类似DSL进行表述，那么IDE就有能力来主动帮我们选择合适的插件，插件的用户是IDE，而不再是人，这样插件的生态估计就会发生变化了。
张刚：
我主要说一下我用Cursor的体验。其他方面我关注的不多。Cursor确实好用。我已经注销了我的github copilot账号，IDE只用Cursor了。Cursor最大的优势，是“猜”的非常准， 基本上你编写一个东西，它可以很容易地猜测到你后续的意图。然后许多情况下，我只需要“判断”代码是不是正确就可以了。这个是非常好的体验。
不过这里也还是有比较明显的痛点，就是审查代码也是很大的工作量。这个Cursor团队自己也在访谈中谈到这个问题，如何进一步降低开发者审查代码的负担。 这个可能既是个工程问题，也是个研究问题，值得关注。
茹炳晟：
需求本身具有“演进”的特点，但是现在我们很多时候会把需求看成是静态的，这个不符合软件工程的演化的思想，所以我感觉我们需要对更多的需求演进过程数据进行训练，来帮助模型更好地理解需求的“动态性”，关于问题4，我的观点是模型的输出可以用模型做校验和修正，从来消除不确定性，用魔法打败魔法。
黄峰达：
从结论来说工程是 1，AI 是 0，没有工程化，AI 发挥不了价值。我是搞 AI 的工程落地 ，那些酷炫的思维链等，也就是看看。比如，我们最近一直在研究的点是，如何挖掘流程中的隐性知识？比如，你编写测试用例，要挖掘出用例的策略，什么情况下关注什么？需要如何准备测试数据？然后才是，如何通过 AI 技术简化这些知识提炼的成本。在需求和开发等领域也是类似的作用，先从流程模拟人如何思考，再去结合 AI 技术。
除此，前面提到了 AI生成内容的检验成本比较高，所以我们探索的方向是结合流程 Shire 编程场景智能体语言，可以自由和不同内部工具、IDE 插件做集成。在经历了大量的调研和探索之后，从生成式 AI 能力上来说，我们更需要是传统 AI 和工程能力 —— 生成测试用例之前，生成准确的测试数据。
狄鹏：
技术的发展日新月异，去年我们还在研究如何通过网上的公开数据，rlhf+sft预训练自己的代码模型。今年我们就已经进入到大量的合成数据，强化退火来构建模型底座。如今的应用 RAG、Agent等已经普遍应用。之前简单介绍了CodeFuseVAT，目前我们还在内部试用的阶段，这个系统承载着蚂蚁对AI时代的新研发范式的尝试。其核心也是类似Cursor，Github等，通过多Agent 协同的方式，增强整体的研发效果。刚刚 彭老师 提到了10-15%左右智能化占比，要有所突破，有几种方式。除了RAG、context-aware等技术方式外，蚂蚁也在尝试通过 CodeFuseVAT做开发场景的划分和流程细化，来在局部更优的提高智能化水平。
观点讨论
@彭鑫：@狄鹏 你们前面那个抢春茶的案例分享很有意思，特别是其中DSL与大模型结合这个方面。
@狄鹏：@彭鑫 是的确给了大家很多启示。也让我们从基座到防范，对整个模型能力和质量做了体系化的建设。
刘力华：
软件开发在各种场景下都是一个复杂的行为，不可能只依靠单一信息就能完成，而RAG、Agent等技术能弥补大模型对环境感知不足的问题，减少“幻觉”问题，通过工具交互、迭代优化等方式完成更复杂的任务。Cursor的交互方式比较有特点，介于Agent与纯问答之间，没有Agent激进，但比纯问答更实用，是处于Agent技术还不完善情况下的中间态。
赵俊民：
主要对可以处理复杂任务的数字软件工程师、新的大模型发布，Agent等新技术感兴趣；我们今年基于架构师/开发人员活动旅程分析，看他们在一个项目中从事的活动及其每个活动所耗费的时间来找到效率瓶颈点。如一个架构师立项阶段需要各种数据收集，技术分析，竞品分析，用户调查；概念阶段需要进行需求分析，架构设计，设计评审等；计划阶段进行详细设计，开发阶段进行设计变更，代码Review等，测试阶段审视实现和设计的一致性。大概一个软件SE耗费时间比例技术可行性分析20%，方案设计20%，疑难问题攻关20%，会议等方案落地工作占40%，现在大模型能解决的实际工作占比非常小。SE工作很多多少脑力创造性活动，如何用大模型能力不断帮助SE人员更好的进行分析设计能力是非常重要的。Cursor平台目前主要提供了编码阶段易用的体验，对于需求分析和设计目前还没有看到很好的工具。
观点讨论
@黄峰达：@赵俊民 结合我们在其他企业的落地，需求工具不会有统一的，几乎每家公司流程都有所差异。
@赵俊民：@黄峰达 是的，跟行业也有关系。
李鹏：
Cursor 本来我用的较多，最近在用 zed.dev，也在基于 zed.dev 改成一个私有环境可以部署的 IDE。在这个过程中，觉得可以优化的地方还有很多。cursor 做了一些更精细的内容匹配设计，达到了很好的效果。但是在此基础上是不是还可以有更多的尝试，zed.dev 有一个 workflow 的设计也采用 agent 的做法，现在看上去还不成熟，不过也算是一个创新点。
Question 5
主持人：您对基于大模型的软件智能化开发的发展前景怎么看？企业应当如何从基础大模型、人工智能技术应用、软件工程基础能力建设等各个方面努力以提升整个企业的智能化开发水平？
蒋奕：
充满期望。我还是希望从IDE的角度能系统性的把大模型用起来，而不是单点的插件功能。 新的IDE架构应该拥有获取数据的能力，包括代码，用户行为，工具轨迹，历史等等，拥有处理数据的能力，最后结合大模型系统化集中解决大问题，否则IDE在开发中的上帝视角就“浪费”了。
观点讨论
@黄峰达：@蒋奕 可以试试，我们开源的 Shire 把 IDE 能力抽象为 DSL：https://github.com/phodal/shire。
@蒋奕：一个新的IDE架构其实是很难的，不过现在有了大模型技术的加持，有了像鸿蒙这样全新的生态，我认为时机已经到了。
张刚：
非常看好。我理解，大模型有了之后，开发人员原本不得不干的很多琐碎的工作，包括代码理解、编码等等，都变得轻松起来了，甚至不太需要关心了。那这样开发人员才有更多的时间和精力，去关心业务、关心需求和关心设计上去。 我觉得一定程度上，大模型相对于高级语言，可以和高级语言相对于汇编来类比。虽然大模型做不到非常精确的到代码的映射，但是抽象能力提升，这个就已经足够了。
那对于开发人员来说，要提升的核心能力，其实是“定义问题”和“解决问题”的能力。这个包含需求、架构，我理解也需要开发人员有更广阔的业务视野。这个说起来容易，做起来还是很难的。能力的成长是需要环境的， 如何能在企业，在高校教育中，创造这种成长的环境， 还需要更多的探索。不过，能想象到，大模型肯定也能在这个过程中发挥重要的作用。
对于智能化开发领域的产品和研究来说，我认为现在都还是刚刚开始，未来仍然有巨大的发展空间。
茹炳晟：
我认为需求的结构化沉淀，设计知识的结构化沉淀将成为软件工程领域应用大模型的关键。到后期，模型能力会越老越同质化，那个时候比拼的是各家业务知识的沉淀。所有最后还是数据质量（结构化沉淀本身就是数据）决定应用的高度。
黄峰达：
我觉得就算不考虑模型和算力，要企业落地还是有比较大门槛。
第一，AI 工具并没有企业想象中好用，存在大量的学习成本 ，很多开发容易放弃；
第二，软件智能化开发依赖于 AI 融合到研发流程中，大量企业缺少 AI 人才去改善内部流程、规范和提炼知识；
第三，端到端难度还是比较大，研发的智能化依赖于需求侧。过去，DevOps 推不动，所以有了在 BizDevOps，希望更多的 Involve 业务人员参加。在 AI 时代，依旧存在同样的问题。
当前阶段，我比较看好的企业智能化场景是：借助生成式 AI 把 DevOps 流程标准化、规范化，做好研发数字化。比较理想的情况是，刚好抵消标准化的成本。从结果来看，企业可以：
1. 小范围构建原型并去小范围试点，以培养 AI 人才。
2. 建立基本的规范，规范化开发流程
3. 有意识的改进现有的知识管理方式
最后，最重要的还是有人持续在内部探索。
观点讨论
@彭鑫：@黄峰达 是，软件工程基础设施和基本能力建设也非常重要，这方面打好基础大模型才能发挥更大的乘法效应。反正，在软件工程基础设施和基本能力建设没有改进，奢望大模型带来软件开发质量和效率质的飞跃可能不太现实。
@李鹏：@黄峰达 同意。
@狄鹏：@黄峰达 我非常赞同Phodal的观点，好的东西也需要循序渐进的落地。
狄鹏：
我坚信，软件智能研发是科技发展的必然方向。蚂蚁其实走的是围绕模型基座方式，将基础模型、软工应用统一思考布局。如今在Chatbot arena等权威模型能力评测中，代码已经是通用模型能力非常重要的评价指标。同时，在应用上，软件工程方向也是当今数据化最好的领域之一，其在各类模型应用技术落地上，都有着非常好的前瞻性和实用性。
刘力华：
大模型对于开发场景，可以作为一个具备高泛化能力的规则系统，同时也具有高效的集成能力。它既可以与企业内的现有传统软件集成，也可以为每个开发者提供个性化的智能服务。企业需要注重数据的采集，如果只是通用领域的大模型，很难适应企业内业务场景的需要，它可能很难明白业务专有名词的含义，只有将业务场景的广泛高质量数据通过RAG或者SFT等方式让大模型学会业务（至少是表面学会），才能在各业务应用场景中发挥效果。并且企业内也需要确认是否真的需要大模型，有些场景下很可能传统软件已经足够了，不能为了大模型而上大模型。同时，企业内的各类研发系统需要面向大模型去做适配，让大模型能够在整个软件生命周期内，它擅长的领域发挥作用。
赵俊民：
我在学习一些大模型技术的基础原理，大模型本质我理解还是通过概率模型去压缩知识，挖掘内在模式，在内容生成有一定泛化能力，但是生成内容无法保障正确性。软件开发中一部分工作现有软件的复用和组合，如一些与业务无关的基础算法，基础库，UI类等。这类工作我认为是可以通过大模型进行提升效率的。但是对于一些工作，如深度的系统优化，架构重构工作，比较创新的一些软件开发上我觉得可能帮助上还有很长的路。
我们对大模型持保守跟进状态，希望找一个重点场景进行尝试。基础大模型+企业内部数据如何有效结合应用，是目前我们努力的方向，如CodeReview是我们明年期望重点尝试的场景的。另外如何通过知识工程和数字地图把内部各种软件开发知识进行整合，帮助架构师和开发人员快速理解一个复杂工程的架构现状，演进过程，组件依赖，代码缺陷模式提升整体的研发认知能力，也是很有意思的事情。
访谈结束
CodeWisdom
一个有知识的软工公众号
发现智能化编程之道
如有侵权请联系:admin#unsafe.sh