2025QECon全球软件质量效能大会：基于大模型的智能化开发：复杂系统视角下的一点思考和探索

基于大模型的智能化开发：

复杂系统视角下的一点思考和探索彭鑫｜复旦大学计算与智能创新学院副院长、教授

pengxin@fu.cn

https://cspengxin.github.io彭鑫

，复旦大学计算与智能创新学院副院长、

教授

，

国家级高层次人才计划入选者。

中国计算机学会（CCF）杰出会员、软件工程专委会副主任、开源发展委员会常务委员

，

中国汽车工程学会汽车基础软件分会副主任

，《Journal

of

Software:Evolution

and

Process》联合主编（Co-Editor）

，《ACMTransactions

on

Software

Engineering

and

Methodology》、《软件学报》等期刊编委。2016年获得

“

NASAC青年软件创新奖”

，

2023年入选上海市东方英才拔尖项目

，

2024年获得

“

中创软件人才奖”。主要研究方向包括软件智能化开发、云原生与智能化运维、泛在计算软件系统、智能网联汽车基础软件等。研究工作多次获得IEEE

Transactions

on

Software

Engineering年度最佳论文奖、

ICSM最佳论文奖、ACM

SIGSOFT杰出论文奖、

IEEE

TCSE杰出论文奖等奖项。担任2022年与2023年CCF中国软件大会（CCF

ChinaSoft）组织委员会主席与程序委员会共同主席

，以及ICSE、

FSE、ASE、

ISSTA、ICSME、

SANER等会议程序委员会委员。彭鑫复旦大学计算与智能创新学院副院长、教授检索增强拓展信息来源、提高精读能力智能体增强规划和工具使用能力

1.领域知识库构建

4.生成响应

QE

主要推动力：

大模型及相关技术的发展基础大模型夯实基础

提示工程提升“思维”能力角色扮演（Role-Playing）思维链（Chain

of

Thought）

2.领域知识检索

3.融合检索信息

自然语言指令与当前代码上下文相融合

上下文将大模型的自然语言交互及代码生成能力与IDE及项目上下文相结合，通过良好的人机交互设计及上下文融合能力实现更好的智能开发体验基于代码上下文预测下一个代码编辑位置Q

智能化IDE：智能开发体验创新基于代码库及相关文档补充

基于大模型Agent的生成式应用开发基于多智能体

（Ag

e

nt

）协作的生成式应用开发MetaGPT[2]是由DeepWisdom公司等在2023年

11月发布的一个多智能体框架，其中包含产品经理、架构师、项目经理、工程师等不同角色，只需输入

一句话就可以自动输出用户故事、竞品分析、需求、数据结构、

APIs等软件制品ChatDev[1]是由来自面壁智能、北京邮电大学、布朗大学等单位的团队在2023年7月发布的大模型驱动的全流程自动化软件开发框架，拟作一个由多智能体协作运营的虚拟软件公司[1]C.Qian,etc..ChatDev:CommunicativeAgents

for

Software

Development[2]S

Hong,etc..

MetaGPT:

Meta

ProgrammingforA

Multi-AgentCollaborative

FrameworkSWE-Bench_Lite解决率榜单TOP10（截至2025年9月10日）SWE-Bench_Lite是SWE-bench数据集的子集，包含300个较简单的任务（仅涉及1个文件不超过3处修改，问题单不包含图片、超链接及对其它问题的引用，问题描述超过40个单词）SWE-Bench_Verified解决率榜单TOP10（截至2025年9月10日）SWE-bench_Verified是基于SWE-Bench测试集人工筛选和验证得到的高质量子集，共包含500个任务，每个任务有清晰明确的问题描述和有效的单元测试用例SWE-Bench也许是AI技术的练兵场，而非软件工程能力的试金石：项目以开发库为主，设计复杂度不高，隔离测试容易

基于大模型的缺陷自动修复企业实践

局部智能化支持成为常态：代码补全、推荐、解释和问答得到广泛采用

加速开发人员的分化：普通程序员频繁使用（甚至滥用）大模型，但是仅能获得少量效率提升同时蕴含滥用和迷信的风险；专家型程序员在大模型加持下成为以一当十的超级程序员和全栈工程师

个人有感企业级收益不大：企业对于大模型带来的效能提升感觉不大，主要原因是软件高层理解及维护上支持较弱研究进展

代码大模型训练和微调：不断取得进展，在小规模代码生成上表现取得较好效果

多Agent技术成为热点：多Agent技术的引入在一定程度上提升了大模型的智能化开发能力，但难以跨越软件工程本质困难的鸿沟带来质变

基于上下文的智能化IDE：

将代码仓库及IDE环境中的相关上下文与大模型的生成能力有机结合，实现仓库级代码生成、多处编辑等智能化开发辅助能力

基于大模型的智能化开发研究与实践软件开发的本质性困难在于对于构成抽象软件实体的复杂概念结构的构思（主要是需求和设计）

，而产生这种抽象软件实体的编程语言表示只是偶然性的困难Frederick

P.

Brooks.

No

Silver

Bullet

Essence

and

Accidents

of

Software

Engineering.Computer,Vol.20(4),April

1987.1、软件开发是一个逐步精化的过程，全程伴随着各种不同抽象层

次上的设计决策

，而支持更高层次软件智能化开发（完整应用开发、软件维护任务）的一个关键是软件设计能力2、代码数据所提供的信息是平面化的（缺少软件抽象）

，仅反映

最终结果（缺少决策过程）

，不足以支撑大模型获得更高层次上的智能化开发能力，设计能力的缺失是一个关键因素

软件需求和设计中存在大量难以捕捉的“暗知识”

平面化的代码学习方式使大模型难以学到抽象的设计知识

从当前实践看大模型扮演的更多仍是原子任务编码的角色3、企业软件开发中大部分是维护型任务，知识缺失是影响开发效

率和质量的重要原因，一种可行思路是在构建基于大模型的代码数字孪生，利用大模型强大的记忆、理解和关联能力以及开发人员的众包式参与实现有效的软件开发知识积累

几点认识和建议详见CodeWisdom公众号（2023年12月31日）基本观点：仅靠大模型技术的发展无法触发软件智能化开发的质变，因为这将涉及软件开发的根本性困难（即概念级别上的分析和设计）

，而大模型在这方面并不具备所需要的能力当前现状：主流研究路线（包括工业界）过于热衷于大模型和Agent等AI技术的“眼球效应”，在软件工程的本质困难上的思考不多

软件的多样性、

复杂性和探索性详见CodeWisdom公众号（2024年10月25日）软件形态的多样性软件开发的探索性软件的系统复杂性软件的频谱很宽形态多样性很强

频谱的另一头：操作系统等大规模复杂软件

基础性和特异性强，功能及设计复杂

生存周期长且不断演化

对于这类软件，只有经验丰富的专家型开发人员才能驾驭

智能化技术仅能提供辅助支持

频谱的一头：高度个性化和场景化的小应用

实现结构简单，例如组合和编排一下已有的服务和API即可实现

生存周期短（甚至可以按需合成、即用即抛）

对于这类软件，最终用户编程显然是一个不错的选择，而自然语言编程也是呼之欲出了

软件形态的多样性

软件的精密性与演化性

软件是高度符号化的解决

方案表示方式

，

一点差错

就会造成严重问题

软件通过在既有实现方案基础上持续“适应性生长

”实现长期演化

由此造成软件无法容忍细

微偏差，同时又缺少可靠

的顶层设计和统一的演化

控制

内部的系统复杂性

软件具有较高的设计复杂性，不同组成部分之间交互关系复杂

从不同维度和关注点出发考虑的设计决策之间纵横交织，关注点的混杂和散布成为常态

由此造成软件的高层意图与软件实现结构之间映射关系复杂

外部的系统复杂性

软件往往属于一个软件密集型系统的一部分

软件的有效性和正确性很大程度上取决于所处的系统上下文环境以及系统级的设计方案

由此造成理解及编写代码的一部分重要背景知识不在代码本身而在代码之外内外部的系统复杂性软件的精密性和演化性

软件的系统复杂性

软件开发的“具身智能”

软件需求的理解和分析需

要建立在问题领域的

“世

界模型

”之上

面向问题空间探索软件与

用户的交互效果及用户的

满意度

面向解空间探索软件在软

硬件基础环境之上的运行

效果及潜在问题

面向问题空间的探索

用户需求很难做到一次性完整、

准确表述

开发人员在开发过程中一般都需要不断探索和完善对用户需求的理解

这种需求探索往往需要以原型演示为基础（需求工程中对于原型有着很高的重视程度）

面向解空间的探索

软件运行在复杂的软硬件环境基础上同时内部还存在复杂的交互关系，

因此开发人员也无法仅通过代码就对软件最终运行效果有完整、

准确的认识

需要通过不断运行和观察运行效果来不断探索和调整各种设计决策面向问题空间的需求探索面向解空间的设计探索

软件开发的探索性

开发知识一锅炖

所有知识，包括特定领域知识（如业务知识和应用框架等），都以“语料”的方式在不同阶段（如预训练及各种微调）

“喂”给大模型，通过大模型融合和释放各种软件知识

代码理解一口闷

大模型输入窗口越来越长，可以将软件代码作为长序列提示词

输入，使得大模型获得关于软件的全部理解并提供问题定位、

缺陷修复、增量开发等方面的智能化支持基本假设：软件是一种特殊的文本token序列以及各种共性模式的组合，因此可以通过大模型学习从通用到特定领域各个不同层次上的共性模式并灵活运用，而软件开发的智能化就是各种共性模式（如常用算法、设计模式、API使用模式以及各种特定领域的模式化代码）的学习和利用

主流思路：

“大模型一锅炖”

软件是一种不可见的逻辑产品，是人类各种思维（例如业务关注点以及设计思路）相互交织混杂后的一种表达形式，因此内部组件/模块边界模糊、

交

互关系复杂难测，同时软件又具有高度的精密性

（高度符号化，

错一点全错）

软件作为一种现实世界问题的解决方案本身处于一个复杂的系统上下文环境中（例如硬件、

网络、

基础软件等方面的运行环境以及用户使用场景等方面的业务环境），由此导致理解及编写代码的一部分重要背景知识并不在代码本身而在代码之外

软件具有很高的内部复杂性，大规模复杂企业软件包含很多模块和组件，同时关注点的“混杂”与“散布”现象十分突出

，

导致高层问题（如一个issue单）与底层代码之间的映射关系极其隐晦、复杂；

软件常常处于持续的演化之中，大量的开发人员参与其中且各自为战、

缺少统一协调

，

导致软件呈现一种生态系统般的适应性演化过程从而逐渐形成突出的系统独特性

复杂系统论：

回归软件的复杂系统属性软件是一个复杂且精密的系统，同时随着演化逐渐形成越来越强的独特性详见CodeWisdom公众号（2025年6月5日）

理想：

每一次代码修改都在理解全局软件设计的基础上经过精心的设计和仔细的推敲

，

整个软件始终保持良好的设计结构并遵循各种通用模式

现实：

每一次代码修改都像是乱搭乱建的棚户区又经受了一次无序扩张，代码像狗皮膏药似的一层又一层贴上去

大量的代码修改都是在当时当地的现实约束下（如时间、资源、业务连续性顾虑等），由一些仅具有局部视野和有限责任心的软件工程师来实施的

由此带来的结果是，

企业级开发所面对的软件系统经常是经过长期适应性演化以及各种复杂权衡决策所产生的结果

同时还会积累大量的技术债

，并形成一个难以理解和维护的遗留系统，即使是业界闻名的成功产品背后也是如此

软件的适应性生长与越来越强的独特性软件经过长期演化之后将体现出越来越强的系统独特性各种软件维护任务都需要在回顾历史、厘清软件发展变化的来龙去脉的基础上才能理解所面临的软件开发问题并作出问题定位、

修改决策、变更影响分析、

架构看护等方面的决策DeepSeek-R1生成的图片：乱搭乱建、无序扩张的街区

代码数字孪生：

AI时代的软件知识工程

持续知识积累的需要

复杂软件的理解与分析需要

“系统2”的结构化分析思维（慢速、需要努力、消耗认知资源的分析性思维）

支持这种理解与分析的关键是软件开发及演化知识的持续沉淀与积累

，同时这种知识需要以一种结构化的方式进行表示

，并以一种可见、可理解的方式支持开发人员以众包式的方式持续参与知识贡献与积累

代码数字孪生的思想

代码元素及其关系只是软件的物理表示，软件的逻辑表示是高层的需求和设计知识

我们希望通过代码数字孪生抽取和沉淀关于软件高层知识并建立其与代码实现之间的映射关系

进一步，对于以云原生软件为代表的在线系统，其部署和运维过程还进一步融入系统演化过程及其复杂性之中，

因此我们需要进一步考虑软件系统数字孪生几方面探索软件维护应用开发代码评审几方面探索应用开发软件维护

代码评审

大模型的一次性代码生成能力在显著增强

，

常见的小规模应用可一次性生成

大模型的迭代修复能力依然较差，在已有代码基础上迭代修改经常“反复横跳”，

导致BUG激增

反映出的是大模型有限的整体理解和掌控能力，缺少对软件的高层抽象和整体构思，

经常在迭代开发过程中迷失方向一次性生成

=大部分功能

+小部分BUG迭代修复

=大部分BUG+小部分功能

端到端应用开发：

大模型代码生成Claude

3.7Sonnet

射箭小游戏一次性开发Claude

3.7Sonnet

射箭小游戏迭代开发少量需求

=完善的初始功能

需求增加

=修BUG的“无底黑洞”特性驱动的开发FDD：

Feature

Driven

Development领域模型设计模型全局约束开发一个计时器APP！7

增量特性添加4

问题澄清要支持从历史记录中重启

特性实现用户反馈开启计时器创建计时器3特性精化设计5编码、测试全局约束

前置特性上下文历史记录重启重启计时特性设计特性实现暂停计时停止计时6

修改/新需求当前特性开发上下文演进式需求与设计调整生成当前特征上下文系统设计分解特性地图自底向上自顶向下26关键步骤：特性拆解与编排、迭代开发上下文、

用户反馈、演进式需求变更

特性驱动的应用开发框架系统整体设计

1特性数量：

12代码行数：

2026UI组件数：

168特性数量

：8代码行数

：957UI组件数：

68音乐播放特性数量：

10代码行数：

1602UI组件数：

120计时器特性数量：

10代码行数：

1060UI组件数：97QE

应用开发效果茶饮点单

单词学习几方面探索软件维护应用开发代码评审

在公开数据集上表现突出：在SWE-Bench等公开数据集上表现出色，可实现较高的自动修复率

能力短板

分析入口靠猜：当代码仓库中存在多个与关键概念相关的代码位置时，Agent易受关键词干扰，误判定位目标

逻辑难以回溯：缺乏长期上下文记忆，在深度优先分析过程中难以回溯，错过关键信息

重复造轮子：修复时不善于利用已有代码，经常重复实现相似功能

自主探索式：赋予大模型在代码仓库中探索、浏览及修改的能力，结合推理机制实现问题的自动定位与修复

固定流程式：设计固定的问题定位与修复流程，引导大模型按照既定流程实现问题的自动定位与修复关键问题：缺少对项目业务逻辑及设计方案的整体理解，难以处理关注点的混杂与散布问题，同时修复正确性保障不足

基于大模型Agent的问题自动修复发展状况主要思路AutoCodeRoverSWE-AgentAgentless主要研究思路

重量级代码数字孪生：大规模复杂巨系统，有领域业务和技术文档同时需人工参与

轻量级代码数字孪生：中小规模软件系统，无需额外文档和人工参与

软件开发知识的群体汇聚

：需求与设计知识的众包式反馈与有效沉淀代码数字孪生概念和意图理解难题：

断言判断中的pag调用栈的复杂性：

难以具体确定哪些函与问题因素相关

，

逆向追溯整个调用链要分析各个层级上的数据流和状态转移，工作量呈指数增长Linux内核BUG入缺陷报错口位置e和

compound_head是什么意思？

与1的

“与

”操作是什么含义？哪些因素会导致断言失效？数需

一个Linux内核缺陷案例缺陷信息与问题代码之间逻辑鸿沟明显，概念与设计知识缺失导致问题定位和修复困难初步分析

：崩溃是由于传入const_folio_flags函数的的page参数不是大页的头页。且一般是由于同步问题导致的。定位思路

：需要检查内核在内存迁移

（migration）时对大页的处理。相关函数

：

do_migrate_range、folio

try_get、folio_unlock...page：

是内核管理物理内存的最小单元...folio：

是Linux

内核引入的一种新的内存管理数据结构

，用于表示一组连续的物理内存页...compound_head：

表示传入page不是头页是尾页...folio_try_get：

增加一个内存页的引用计数

，确保该页不会被意外释放...概念、函数解释崩

溃信息历史知识增强相关知识抽取

：do_migrate_range可能

存在内核崩溃风险。（但是讨论时能想到的corner

case都不会

真的导致问题，所以并未对逻辑进行优化）

分析思路基于大模型及项目知识实现缺陷报告精准理解与缺陷自动定位do_migrate_range()函数中对folio_test_large()函数的调用

，是为了使用folio来统一对内存页的迁移处理folio_test_large()函数可能触发BUG_ON：

因为函数传入的folio没有加锁

，可能出现头页变尾页的情况内存下线场景下

，folio_test_large()函数不会触发BUG_ON：头页变尾页需要经过“头页被释放-

>进入伙伴系统-

>被分配为新大页的尾页”的过程。

当前场景中页面已经被隔离

，无法正常进入伙伴系统进行合并和分配可能存在其他corner

case

，但是暂时想不出讨论结果：

do_migrate_range()有导致内核崩溃的风险

，

但当前场景下应该没有问题

，

故不对代码做调整历史邮件相关讨论

代码修改历史及讨论分析分析对应代码修改历史及其对应的分析与讨论

https://lore.kernel.org/all/20240827114728.3212578-1-wangkefeng.wang@huawei.com/...1）

出于性能考虑用do_migrate_range引用处的循环处理大页拆分后未处理到的子页

，

而不是直接对folio加锁（说明这两行代码在遍历子页时确实会有同步问题）2）

folio_try_get()会获取folio的引用计数待理解代码分析结论

：在组合独立页为大页时，do_migrate_range()

内的同步问题导致内核崩溃解决方案是将两行问题代码移至folio_try_get()之后融合高层概念、

演化历史追溯及大模型归纳实现问题理解和定位概

念解释

缺陷理解与问题定位相关知识归纳：历史追溯几方面探索软件维护应用开发代码评审当skb为空时，将直接return当connected和md都是true时

，tun_info一定不为空案例2误报原因:静态分析工具难以实现复杂的上下文敏感分析（1）多层嵌套上下文

（2）除了函数调用外，还涉及宏和GCC编译器内置函数等各种复杂结构CodeQL扫描Linux

Kernel（v6.9.6）的空指针解引用（NPD）漏洞的两个误报案例案例1误报原因:静态分析工具难以处理复杂的嵌套路径敏感分析

缺陷检查误报问题基于LLM

Agent的约束取值分析函数调用返回值递归推LLMAgent代码检索工具记忆机制利用大模型Agent推理关键路径约束中的约束取值范围

，

实现精准的路径敏感分析利用大模型Agent按需展开上下文进行分析

，避免深层嵌套函数导致的路径爆炸的同时

，

实现上下文敏感分析构建迭代的路径可行性分析框架，将复杂的漏洞上下文分析动态分解为多个子任务

，有效提升LLM在长代码复杂推理任务的表现逐一分析路径约束关键路径约束抽取迭代生成SMT脚本约束求解器求解路径约束基于大模型Agent的迭代路径可行性分析基于静态分析的漏洞扫描工具漏洞上下文函数调用链缺陷报告、漏洞代码变量取值范围推断提出基于大模型Agent的复杂仓库级漏洞检测误报筛除框架LLM4PFA

，

过滤内存安全漏洞误报，在企业落地中空指针解引用漏洞检测准确率94%，误报识别准确率85%DuX,etal.

Minimizing

False

PositivesinStatic

Bug

Detectionvia

LLM-Enhanced

Path

FeasibilityAnalysis.arxiv.

基于大模型Agent的缺陷检查误报消除断案例1:涉及复杂鉴权框架的鉴权涉及Java安全框架Shiro

，

Subject是

Shiro框架中表示当前用户的一个核心对象

，getSysUser()方法通过getSubject().getPrincipal获取当前已认证用户的主体信息权限检查挑