夜雨聆风
AI大模型时代,软件开发的未来前景︱大模型研发管理
会议推荐
2026第五届中国项目经理大会
2026第三届中国医药企业项目管理大会
本文目录
#大模型与 IDE：软件开发的进化和一点思考
#代码革命：AI大模型如何重塑软件开发的未来
# 智能化软件开发微访谈·第三十四期 基于大模型的软件智能化开发实践
# “大模型驱动的软件研发”助推企业研发智能化升级
一、大模型与 IDE：软件开发的进化和一点思考
（原创 潘智祥 Felix的上下文）
蹩脚的方法
我最早从 2022 年上半年开始使用 Github Copilot， 但是那时候使用体验一般，提示的速度很慢，准确度也不够，提示的内容不是我想要的。没觉得对于工作有什么实质性的帮助，后来就没继续用了。
2022 年年底 ChatGPT 爆火之后，我大概在 2022 年 12 月或者 2023年 1 月开始使用它。我使用的最多的场景就是写代码，主要以 Python 函数和 shell 脚本为主。使用的方法就是我在对话框中用文字描述我的需求，然后让ChatGPT 输出代码。一开始觉得非常好用，因为对于一些不太复杂的场景，准确率还是非常高的。一直到 2023 年 11 月我还经常使用这个方法，做的最极端的一个尝试是用 GPT4 给OriginBot（一个小机器人）开发监控功能，整个功能所有的代码都是以对话的形式让 GPT 生成。详细内容可以看https://panzhixiang.cn/2023/我让GPT4为OriginBot 开发了一个监控功能/。
但实际上，我很早就觉的用这种方式让 ChatGPT 来协助写代码并不是很方便。因为我要在编辑器和 ChatGPT 的对话框之间来回切换，复制黏贴代码才能调试，而且，很多时候要结合现有的代码才能表述清楚需求，这就更麻烦了，因为要把其他文件中的代码复制到 ChatGPT 的对话框。
好用的插件
我记得大概 2023 年秋天开始，阿里推出了通义灵码，我第一时间就体验了一下，感觉发现了新世界。它让我可以在编辑器内直接针对一段代码进行操作，让它为我解释代码、添加注释、优化等等，而且可以把更新的代码一键应用到原文件中，再也不用手动复制黏贴了。虽然能感觉到通义灵码背后的模型跟 GPT4 还有一定的差距，但是从使用体验角度来说好了非常多。
再后来没多久，公司就采购了企业版 Github Copilot，有了 GPT 加持的 Copilot 比起2022 年上半年的时候好用了很多，而且由于 GPT4 的模型能力比较强大，在写代码的能力上比起通义灵码更好，所以很长一段时间我是公司的项目使用企业版的 Github Copilot，个人的项目使用通义灵码。
后面陆续有很多类似的插件出现，字节的 MarsCode、智谱的 CodeGeeX 等，但我也没怎么试过，因为看介绍感觉其实都是一类风格的产品。
大模型驱动的 IDE
今年上半年我突然发现有很多人推荐 Cursor 这个IDE，各种吹捧，甚至有小学生使用 Cursor 开发了一个 app。我最初不喜欢 Cursor，因为我一直比较反感吹捧和标题党，但是架不住推荐的人太多了，而且后来有一个身边的朋友也向我推荐 Cursor，我就体验了一下 Cursor。
体验之后发现，Cursor 的火爆是有道理的。
不同于通义灵码、Github Copilot 这样的插件，Cursor 是基于 VS code 做二次开发，把大模型嵌入到用户的交互中去，体验上好很多。Cursor 还有一个比较实用的功能：codebase，它让用户可以直接跟代码库进行沟通，比如你可以直接问它某一个业务逻辑在哪个代码文件中，具体是怎么处理的，这是通义灵码这样的插件不能提供的。比如下面这个截图，是我使用 cursor 来询问originbot代码库一个问题。
红框的部分是 cursor 搜索和思考的过程，因为比较长，我没有展开来，但是从结果来看，是比较准确的，完全可以用于实际生产。
Cursor 很火的另一个重要原因是它默认使用的大模型是 claude 3.5 sonnet。这个模型在编码上的能力的确很强大，我也能理解有人说“小学生使用 Cursor 开发了一个 app”这种话了。在 cursor + claude 3.5 sonnet 的帮助下，小学生开发一个 demo 性质的 app 是完全可能的，并不难。
cursor 的免费额度很少，用完之后对于大模型的调用就要排队，排队时间还挺长的，而且自动补全功能也不可用了。不过它允许用户自己配置大模型，所以我有一段时间使用 DeepSeek + Cursor + 通义灵码的组合，以非常低的价格享受了非常好的编码辅助体验。
windsurf
windsurf这个工具是我10 月份从歸藏的 AI 资讯发现的。体验之后就再也回不去了，而且我也第一次为 IDE 工具付费，是的，我现在订阅了 windsurf pro，每个月 10 美金，但是非常值。上周在一场公司内部的大模型相关分享结束之后闲聊的时候，我向我们的 CEO 推荐了 windsurf，结果他在第二天的分享上就向别人推荐了。
windsurf 跟 cursor 非常像，cursor 有的功能 windsurf 都有（除了使用自定义的大模型），但它还引入了 flows 的功能设计， 而且 windsurf 给自己的称呼是“The first agentic IDE”。
下面这张图是 windsurf 官方对于 flows 的解释：
我用白话解释一下。假设你现在要从零开发一个项目(简单的项目)，你可以在 windsurf 的聊天窗口用文字描述清楚需求，然后它就会开始编写代码，这个过程中，它会尝试分析现有的代码和文件（如果有的话），然后制定计划，然后执行，它编写代码时候可以直接帮助你创建、更新和删除文件，如果需要安装依赖、执行测试，它也可以帮你在终端中执行命令。总之它可以帮你做任何开发过程中需要做的事情，你只需要告诉它你的需求，然后点击Accept 或者Reject 就行了。
另外，它的订阅费只有 cursor 的一半，10 美金一个月。所以我在试用结束后就付费订阅了。
依然需要优秀的工程师
虽然像 cursor、windsurf 这样的IDE 工具已经非常强大了，但是想要开发产品级的项目，依然需要优秀的工程师。「至少现阶段是这样的」。
cursor、windsurf 这样的工具，让它写个几十行的代码是没有问题的，基本上可以不做修改拿来就用。但是当项目代码稍微多一些（比如有十个以上的文件，1000 行以上代码），如果只依靠它们，会越做越乱。而且在项目的技术栈选择、架构设计和业务逻辑这些方面，也不是大模型可以独立完成的，需要有技术能力、熟悉公司情况的工程师做出决定。
从我们工程师的个人角度来看，该学的还是要学，该会的还是要会。「因为windsurf 这类工具可以提高我们的效率，但是不能提升我们的能力」。举一个我最近遇到的例子。
我一直是使用 Django 的，但是最近需要使用 FastAPI，我最开始想偷懒，直接用 windsurf 开发，但是由于我对 FastAPI 完全不会，很快就发现我没有能力判断大模型写的代码能不能用，更糟糕的是，随着项目变的复杂，「我发现我不知道应该怎么提出问题」。后来还是去学了一下 FastAPI，学它的语法、特点、注意事项和使用案例等，对它有一个基本的了解后，再进行开发，情况就好很多了。可以看到，windsurf 并不能让我掌握 FastAPI，但是在我基本了解 FastAPI，可以快速进行开发。
就我自己的经验来看，对于一门编程语言、一个框架、一个工具掌握的越好，大模型加持的 IDE 工具带来的效率提升感受越明显。因为它可以帮你做很多你会做但是耗时、繁琐的事情。
现在一个工程师的产出 = X * Y，其中 X 是工程师的个人能力，Y 是 windsurf 这样的工具带来的系数。作为一名工程师，可以利用大模型帮助我们快速提升 X，也应该以开放的心态多接触和使用类似 windsurf 这样的工具以增大 Y。
面试应该有所变化
我之前看到过一些文章，说企业和面试官很苦恼不知道如何避免候选人在面试过程中使用大模型来作弊（远程面试），也看到过一些相关的产品，既有帮助候选人使用大模型作弊的产品，也有帮助面试官检测候选人是否使用大模型作弊的产品。
我觉得企业和面试官们应该做出改变。因为大模型已经诞生，并且给软件开发行业带来了巨大的变化，不可能也不应该在日常工作中回避大模型，那么就应该考虑在面试过程中允许候选人使用大模型，并且考察他们是如何使用的。如果一个候选人只知道问大模型，并且相信大模型的所有输出，这个人大概率是不合格的，如果一个候选人从来没使用过大模型，也完全没有打算去尝试，那他大概率也是不合格的。
软件工程师是一个夕阳行业
前不久在一个大模型技术分享会上，有一个人说“我们所从事的其实是一个夕阳行业“。在某种程度上，我是认可这句话的，因为随着大模型技术的发展，也许要不了几年，软件工程师的需求会极大减少，当然了，也包括 SRE、DevOps、测试这些岗位，甚至也包括很多算法类的岗位。
我还是坚持我在你或许真的不如大模型中的观点：工程师不会被大模型取代，但是不使用大模型的工程师会被善于使用大模型的工程师取代。
二、代码革命：AI大模型如何重塑软件开发的未来
（原创 rain雨雨编程 rain雨雨编程）
引言
在AI的推动下，软件开发正经历着翻天覆地的变化。本文将简要分析AI大模型如何优化开发流程、面临的挑战及应对方法，并以实例展示其影响力，预测其未来趋势。
传统软件开发 VS AI参与的软件开发
传统软件开发：
-
手工编码：依赖开发者手动编写代码，重复性劳动多。 -
人工测试：测试过程依赖人工编写测试用例和执行测试。 -
需求分析：通过会议和文档收集需求，容易受到主观理解的影响。 -
设计决策：设计师基于经验和直觉进行设计，缺乏数据支持。 -
维护成本高：软件维护和更新需要大量人力投入。 -
迭代周期长：从需求到部署的整个周期较长，响应市场变化慢。
AI参与的软件开发：
-
自动化编码：AI辅助自动生成代码，减少重复性工作。 -
智能测试：AI生成测试用例和执行测试，提高测试效率和覆盖率。 -
数据驱动的需求分析：利用NLP技术从大量数据中提取需求，减少误解。 -
基于数据的设计：AI分析用户行为数据，提供设计决策支持。 -
维护自动化：AI监控软件性能，自动修复常见问题。 -
快速迭代：缩短开发周期，快速响应市场变化和用户反馈。
简而言之，AI让软件开发更高效、低成本，并且更灵活快速。相比之下，传统开发依赖人工，效率较低。随着AI技术的发展，特别是在AI大模型的应用上，我们预见AI将在软件开发中发挥越来越关键的作用。 投票
AI大模型的定义
AI大模型，也称为基础模型，是指具有大量参数和复杂结构的机器学习模型，能够处理海量数据、完成各种复杂的任务，如自然语言处理、计算机视觉、语音识别等。这些模型通过大量的数据和参数进行训练，以生成人类类似的文本或回答自然语言的问题。
核心应用场景
-
代码自动生成：工具如CodeGeeX可以根据自然语言注释描述的功能自动生成代码，也可以根据已有的代码自动生成后续代码，补全当前行或生成后续若干行，帮助你提高编程效率。 -
智能代码审查：AI模型分析代码质量，检测潜在漏洞或不符合最佳实践的部分，实现智能化的代码审查。 -
自动化测试：AI大模型能够自动生成测试用例和执行测试，大幅提升测试效率。据IDC报告显示，使用AI大模型的自动化测试工具可以使测试周期缩短50%以上。 -
需求管理：AI大模型通过自然语言处理技术，自动从用户反馈和历史项目数据中提取需求，减少需求分析的时间和成本。
优势
-
提高开发效率：AI大模型通过自动化代码生成和测试，显著提高了开发效率。 -
降低成本：减少了对人工编码和测试的依赖，节省了人力成本。 -
提升软件质量：通过智能测试和优化技术，提高了软件的质量和稳定性。
挑战及应对策略：
-
数据隐私与安全
-
挑战：AI大模型需要大量数据进行训练，这涉及到用户数据的收集和处理，如何保护用户隐私成为一个重要问题。 -
策略：开发者需要严格遵守数据保护法规，采用加密、匿名化等技术手段，保护用户数据的安全和隐私。 -
模型的可解释性
-
挑战：AI大模型的决策过程往往是一个“黑箱”，其内部的工作原理和决策逻辑难以解释，这对于需要高度可靠性和安全性的软件开发来说是一个不容忽视的问题。 -
策略：研究和开发更加透明的AI模型，提高模型的可解释性，使其决策过程更加清晰和可追溯。 -
技术的成熟度
-
挑战：虽然AI大模型在某些领域已经取得了显著的进展，但在软件开发领域，其技术的成熟度和稳定性仍有待提高。 -
策略：不断优化AI大模型的技术，提高其在软件开发中的稳定性和可靠性，减少技术风险。 -
技术集成和兼容性问题
-
挑战：将AI技术集成到现有的开发流程中可能会遇到技术兼容性和集成难度。 -
策略：采用微服务架构和容器化技术，提高系统的灵活性和可扩展性，降低集成难度。 -
技能差距和人才培养
-
挑战：AI技术的发展要求开发人员具备新的技能和知识，但现有人才可能难以满足这些要求。 -
策略：加强教育培训，鼓励开发者学习AI和机器学习相关的知识和技能，提高团队的整体技术水平。 -
伦理和社会责任
-
挑战：AI技术的应用可能会引发伦理和社会责任问题，如算法偏见和歧视。 -
策略：建立伦理审查机制，确保AI技术的公正性和道德性，避免对特定群体的不公平对待。
重塑开发流程
AI技术的发展，尤其是AI大模型的兴起，正在深刻地重塑软件开发的各个环节。
1. 需求分析阶段
在传统的软件开发流程中，需求分析是一个需要大量沟通和文档编写的阶段。AI大模型通过自然语言处理（NLP）技术，可以自动解析用户需求文档、邮件交流等非结构化数据，快速提取关键信息，辅助需求分析师更准确地把握用户需求。
2. 设计阶段
AI大模型可以利用机器学习算法，识别用户行为模式，推动产品的个性化和智能化，从而辅助设计阶段。AI工具能够自动生成多个UI设计原型，快速获得用户反馈并进行迭代优化。
3. 编码阶段
AI大模型的应用使得编码阶段发生了革命性的变化。工具如GitHub Copilot能够根据开发者的自然语言提示自动生成代码，甚至理解上下文，从而大幅减少重复劳动。
4. 测试阶段
AI大模型可以自动生成测试用例和测试数据，提高测试的覆盖率和效率。一家软件公司使用AI工具自动生成全面的测试用例，覆盖了更多的边界条件和异常情况，提高了测试覆盖率和质量。
5. 部署阶段
AI大模型的应用也改变了部署阶段。通过自动化部署和监控，确保系统的稳定运行。例如，一家互联网公司使用CI/CD工具和AI监控系统，实现自动化部署和实时监控。
6. 维护阶段
在软件上线后，AI大模型可以进行日常维护和更新，修复bug和添加新功能。AI能够实时分析用户使用数据，提供反馈，帮助开发团队快速迭代和优化产品。
新的流程和模式变化
-
敏捷开发：AI辅助的敏捷开发，快速响应变化，缩短开发周期。 -
智能化IDE：集成开发环境将更加智能，提供实时代码建议、自动修复错误和性能优化。 -
个性化开发支持：AI将能够根据开发者的习惯和项目需求，提供个性化的开发支持。
未来发展趋势
-
AI与低代码/无代码开发的融合：将大幅降低软件开发的门槛，使更多非技术背景的人员能够轻松参与到软件开发的过程中来。 -
协作效率的优化提升：AI将优化跨团队协作流程，提高沟通和任务协调的效率。 -
数据安全管理的全面强化：通过数据加密技术和访问控制技术，构建起坚不可摧的全流程数据安全防护体系。 -
个性化开发体验的深化：AI将为开发者提供更加个性化的服务，激发开发者的创造力。
综上所述，AI大模型正在深刻地改变软件开发的各个环节，从需求分析到部署运维，从开发模式到团队协作，从产品服务到用户体验。虽然AI大模型带来了很多优势，但也面临着数据隐私、模型可解释性、计算资源、模型偏差和法律伦理等方面的挑战。通过不断的技术创新和规范管理，AI大模型将在未来继续推动软件开发的发展，创造更多价值。
具体案例
-
CodeGeeX：一个智能编程助手，它可以根据自然语言描述自动生成代码，支持多种编程语言，极大地提高了开发者的工作效率。 -
腾讯混元大模型：腾讯发布的大模型，它在推理分析、创意生成、情绪感知等方面展现出强大的能力，为软件开发带来了新的可能性。
AI大模型的发展不仅仅是技术的进步，它还预示着软件开发流程和模式的全新变革。随着技术的不断成熟，我们有理由相信，AI大模型将成为软件开发中不可或缺的一部分，为开发者带来前所未有的便利和效率。
三、智能化软件开发微访谈·第三十四期 基于大模型的软件智能化开发实践
（CodeWisdom CodeWisdom）
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是我们明年期望重点尝试的场景的。另外如何通过知识工程和数字地图把内部各种软件开发知识进行整合，帮助架构师和开发人员快速理解一个复杂工程的架构现状，演进过程，组件依赖，代码缺陷模式提升整体的研发认知能力，也是很有意思的事情。
四、“大模型驱动的软件研发”助推企业研发智能化升级
（华为云软件工具链）
随着人工智能的发展，AI大模型在各个行业开始广泛应用。利用AI大模型打通工具链，提高产业价值已成为趋势。在全球科技竞争加剧的情况下，软件工具链的发展成为国家信息安全与科技创新的关键。如何利用AI大模型推动软件工具链发展，加速软件研发，成为当前的研究热点。
为进一步推进产学研用深度融合，聚焦软件工具链的研发与应用，4月9日下午，由华为云计算技术有限公司、北京中关村科学城创新发展有限公司主办，中国北京(海淀)留学人员创业园、北京中关村科学城科创服务有限公司协办的“大模型驱动的软件研发新范式推广&开放合作” 中关村基础软件创新中心系列沙龙第一期活动在中关村发展大厦正式举办。此次沙龙活动，旨在搭建交流互动、资源共享、合作创新平台，汇聚数十位技术专家、大咖及技术企业相关从业者。海淀区科学技术和经济信息化局局长、中关村科学城管委会产业促进二处 处长 何建吾参加活动并致辞，华为云PaaS产品部部长 徐峰参加活动并致辞、中关村科学城公司副总经理 戴廉、中关村科学城科创服务公司总经理 袁玲等，沙龙深刻讨论了软件研发创新创意的新工具、新范式、新风口。
是基座、是平台、是未来，海淀牵手华为云聚合众智
海淀区科学技术和经济信息化局局长、中关村科学城管委会产业促进二处 处长 何建吾在致辞中表示，中关村科学城是全国乃至全球软件创新发展高地，此次和华为云合作共建中关村基础软件创新中心，就是要汇聚各方力量，从操作系统、数据库、中间件、开发工具、处理器等构建自主可控的基础软件底座；同时，紧抓链主企业，利用AI大模型打造各行业标杆型应用，推动各行业信息系统的自主可控发展，把中关村科学城打造成中国名副其实的软件自主创新高地。
【海淀区科学技术和经济信息化局局长、中关村科学城管委会产业促进二处 处长 何建吾】
华为云PaaS服务产品部部长徐峰在发言中提到，随着大模型、人工智能等先进技术的持续发展，软件工具链正逐步朝智能化、自动化方向发展，这中转变不仅提高了软件开发效率，还显著改善了质量、稳定性和用户体验。华为依托自身30余年的技术积累，借助智能底座优势，致力于开放技术、能力、工具和服务，助力企业技术迭代发展。以研发大模型为基础的应用，在金融、航空航天、汽车、生物医药等千行万业上，已经开始高效发挥作用。
在软件产业聚集的中关村科学城举办沙龙活动，通过汇聚更多伙伴的能力和技术，共同为我国软件产业的繁荣发展贡献力量，这是一个好的开端。
【华为云PaaS服务产品部 部长 徐峰】
融合智变，解锁开放共享、创新研发新通路
AI大模型正在迅速崛起，在技术领域持续释放潜能。抓住时代机遇，利用AI所带来的技术红利已成为技术竞争中的核心要素。如何有效地运用AI大模型来赋能软件技术创新发展，如何充分释放AI的生产力，已成为当今技术企业必须深入探讨的关键议题之一。
活动上，华为云软件安全服务域专家分享了软件工具链发展历程及合作策略。他表示，当下软件发展从代码为中心走向工具链和模型的中心，并且要重新定义AI的新范式，加强工具链合作带领海淀企业共同发展。
【华为云软件安全服务域专家】
华为云智能化软件研发专家则根据以上对趋势的分析，带来了华为研发大模型实践及分享。专家以AI编程为切入点，介绍了利用大模型自动生成代码的原理、历史与效果，从软件内涵的扩展、对工具链的影响等方面分析了大模型将给软件研发带来哪些主要的变化，并结合例子展示出大模型的确将大幅提升软件研发的效率。同时，也详细展示了华为内部在研发大模型的实践，介绍了华为的智能研发助手 CodeArts Snap的三大关键技术：高质量的训练数据构建，自动评估与人工评价的双反馈机制，以及自动补充上下文信息。
【华为云智能化软件研发专家】
创新引领，好工具使能技术落地快人一步
在实践中，充分利用智能化工具加速产品落地，是当前融入AI时代的关键方式。抓住时代脉搏，首要之务是保持对新兴技术和工具的敏感度，借助智能化工具融入发展，以确保企业在技术竞争中持续保持领先地位。
为进一步加深企业对智能化工具的理解，华为智能化测试工具技术专家在现场分享了测试用例智能化生成的多个场景案例。详细介绍了华为云CodeArts智能化测试解决方案的优势，包括测试脚本代码生成助手和API场景级零代码测试机器人ATGen。从核心痛点出发，梳理了系统测试代码生成过程中，测试脚本代码生成助手在存量特性增强自动化测试防护网、全新特性和新业务测试自动化开发等场景的应用，为在场技术企业提供了系统测试代码生成提质增效的新灵感。
【华为智能化测试工具技术专家】
在更专业、技术性更强的学术交流环节中，企业之间也开始了一场互助讨论。通过与专家进行一对一交流，与会企业解决了智能化测试方面的具体问题，找到了自身技术发展的突破口，克服了技术发展的瓶颈。此外，许多企业还通过此次活动提供的平台与上下游产业企业积极联系，为未来合作奠定了基础。
这次以技术为核心的沙龙在企业之间的高效沟通中圆满结束。未来，华为云与中关村科学城公司将联合举办更多不同领域的沙龙、论坛等活动，为海淀地区集聚人才、汇聚智慧、贡献力量。
1、如您转载本公众号原创内容必须注明出处。
2、本公众号转载的内容是出于传递更多信息之目的，若有来源标注错误或侵犯了您的合法权益，请作者或发布单位与我们联系，我们将及时进行修改或删除处理。
3、本公众号文中部分图片来源于网络，版权归原作者所有，如果侵犯到您的权益，请联系我们删除。
4、本公众号发布的所有内容，并不意味着本公众号赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本公众号证实，对本文全部或者部分内容的真实性、完整性、及时性我们不作任何保证或承诺，请浏览者仅作参考，并请自行核实。
