index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html
![]()
文章指出，在AI代码生成能力快速增长的背景下，软件开发的系统复杂性问题应得到更多重视。作者强调，编程不等同于软件开发，后者涉及长期演化、复杂环境、精巧设计和持续维护。文章通过“贫嘴张大民的小屋”这一生动案例，阐述了理解软件演化历史、设计决策约束以及系统复杂性管理的重要性。同时，文章分析了软件的三重角色和形态（解决方案、工具应用、复杂系统），并指出AI技术在不同形态的软件实现中发挥着不同作用。“自然语言编程”适用于特定场合，如“即用即抛”的解决方案和用户演示，但在专家掌控的复杂软件开发中仍面临限制。文章呼吁在拥抱AI技术的同时，正视软件的系统复杂性，避免盲目乐观，并在深刻理解软件工程原理的基础上，构建智能化开发的理论和方法体系。
🌳 系统演化的视角：如同“贫嘴张大民的小屋”的例子，软件系统是不断演化的，理解其设计需要追溯其发展历史和演变过程，许多独特的设计决策是在各种约束和权衡下形成的。
🧩 编程与软件开发的本质区别：编程侧重于通过计算过程解决特定问题，而软件开发旨在构建和维护长期稳定运行的复杂系统，后者需要考虑异常处理、非功能性需求、复杂的社会物理环境以及模块间的协作。
🔄 软件的三重角色与AI的应用差异：软件可以被视为一次性解决方案、稳定工具应用或持续演化的复杂系统；AI技术在规划解决方案、生成工具应用原型方面表现出色，但在理解和支持复杂系统开发方面仍有局限性。
🗣️ “自然语言编程”的适用性考量：虽然“自然语言编程”在快速生成演示原型和某些扁平化业务软件中展现潜力，但在面对需要深厚领域知识和复杂系统设计的场景时，仍依赖于专家经验和细致的人机协作。
🏗️ 正视系统复杂性与审慎拥抱AI：在AI代码生成能力飞速发展的当下，更应重视软件固有的系统复杂性，避免盲目鼓吹“自然语言编程”等口号，而应基于软件工程的基本原理，稳健地探索和构建智能化软件开发的理论和实践体系。
彭鑫 2025-11-03 08:01 上海
AI代码生成能力快速增长的当下，更应该正视其中的系统复杂性问题
熟悉我的朋友知道，我一直在强调大模型在复杂软件开发中的局限性，特别是系统复杂性的挑战和软件设计的难题。去年10月份我所写的《大模型时代的软件智能化开发：我们在哪里？该往何处走？》这篇文章比较全面地论述了我在这些方面的思考，特别是软件形态的多样性、软件的系统复杂性、软件开发的探索性所带来的问题和挑战。 今年6月份我专门针对系统复杂性这一问题写了一篇文章《代码数字孪生：回归软件的复杂系统属性》，其中特别论述了为什么“大模型一锅炖”的思路（即将复杂软件开发问题的解决寄希望于大模型自身能力的提升和输入窗口的增大）无法解决复杂软件开发的问题。我的主要观点是，软件经过长期演化之后将体现出越来越强的系统独特性，各种软件维护任务都需要在回顾历史、厘清软件发展变化的来龙去脉的基础上才能理解所面临的软件开发问题并作出问题定位、修改决策、变更影响分析、架构看护等方面的决策。 以上两篇文章已经比较全面地论述了系统复杂性问题及其对基于大模型的软件智能化开发所带来的重要影响。这次经过一段时间的酝酿又打开Word写下这篇文章的原因主要是某次讨论的时候我的脑海里突然浮现出“贫嘴张大民的小屋”这个生动的案例和深刻的隐喻，同时对一些流行的说法有了更多思考，希望集中进行一些回应。让我们先从“贫嘴张大民的小屋”说起。 1．“贫嘴张大民的小屋”中的系统复杂性隐喻
《贫嘴张大民的幸福故事》是二十多年前一部很流行的平民生活轻喜剧，有电视剧和电影两个版本，分别由梁冠华（就是后来饰演那个老说“元芳你怎么看”的狄仁杰的演员）和冯巩主演，我都看过。这部剧主要反映北京四合院中一大家人清贫但乐观的生活故事，其中有一段讲述了张大民的小屋的故事：张大民好不容易讨到心仪的媳妇但家里房子不够住，思索再三只好在院里搭了一间“特别的”小屋。这间小屋的特别之处在于有一棵大树，邻居不让砍，于是张大民只好设计了这样一个树干贯穿小床和房顶的屋子。
如果把包含这间屋子在内的整个四合院比喻成一个软件系统的话，我们可以从“贫嘴张大民的小屋”中体会到几个关于系统复杂性的隐喻。首先，有生命力的软件总是处于持续演化之中，理解软件（特别是软件设计）需要理解它的整个演化历史。张大民家的四合院也许解放前是某个大户人家的宅院，后来分给了几户人家，又随着几个家庭的变迁而不断变化，包括张大民小屋的形成也是演化的产物。其次，软件演化过程中的很多设计决策都是在大量的约束和权衡之下做出的，经常涉及许多可知和不可知的复杂考虑，同时决策结果有很强的独特性。张大民的这间小屋是一个奇怪的屋子，如果没看过前面几集那么很难理解为什么屋子里头会有一棵树。一个学习了很多房屋建筑的大模型可能学到了很多共性模式，但绝对没见过这种奇怪的小屋。最后，软件的长期可持续发展需要建立在对于软件的系统复杂性以及相关的设计知识的掌握基础上。让我们设想一个场景：多年以后，你收购了张大民家的这个四合院，看到了这间奇怪的小屋，那么这间屋子能否改造、这棵树能否砍掉呢？如果你知道这间小屋的来龙去脉以及这个奇特设计的来源，那么你可以很容易就决定把树砍了重新盖房（可能还要咨询一下城管和规划部门，这可能是随着时代变化新增的约束），因为整个四合院都是你的了，反对砍树的邻居都已经搬走了。如果你不知道呢？那么你可能会疑惑，甚至相信这棵树有什么神秘力量，于是决定保险起见还是先不动为好。熟悉企业软件开发的朋友应该都能体会到这个故事中的复杂系统隐喻和我想表达的意思。正如我在《代码数字孪生：回归软件的复杂系统属性》一文中所阐述的：“大模型一锅炖”这样的技术路线可能难以较好地支持复杂企业软件开发任务，复杂软件的理解与分析（如问题定位、修改决策、变更影响分析）需要“系统2 ”的结构化分析思维（慢速、需要努力、消耗认知资源的分析性思维），支持这种理解与分析的关键是软件开发及演化知识的持续沉淀与积累。 2．“编程”不等于“软件开发”
我们以往对于软件和程序、软件开发和编程（或程序设计）之间的区别说的总不是很清楚。例如，经典的软件工程教科书一般会告诉我们“软件=程序+文档”，看起来好像如果我们不考虑用户文档和开发文档的话，那么程序差不多就是软件了，那自然编程差不多就是软件开发了。然而，随着过去几十年信息化的发展，软件已经渗透到我们的社会经济生活以及社会物理空间的方方面面，“软件定义一切”的发展趋势已经形成广泛共识。在这种新的发展趋势下，我们有必要重新审视“编程”与“软件开发”的区别。编程是以通用计算机可执行的程序的形式为我们提供现实问题的解决方案。从经典的“算法+数据结构”这一定义可以看出，程序更强调通过一种计算过程为用户提供问题解决方案。而软件开发的目标则是构建并维护一个软件系统。这里软件系统与程序之间的区别包括以下几个方面。
软件系统着眼于长期稳定运行并有效应对各种特殊情况软件系统所提供的不是一个一次性解决方案，而是一个长期稳定运行的系统并由此建立某种秩序。为此，软件不仅需要考虑主要的功能实现，而且还要考虑各种异常情况处理，同时针对性能、可靠性、安全性等非功能性需求进行相应的设计和实现。
软件系统根植于复杂的社会物理环境之中软件系统往往是一个更大的软件密集型系统中的一部分，这个大系统中还包含物理环境、设施设备、用户及其他各种社会物理要素。软件系统往往需要置于所处的社会物理环境之中才能确定其需求以及最终的满意度。
软件系统包含复杂而精巧的设计结构，各个部分密切配合软件系统包含很多模块，每个模块各自实现不同的职责同时相互协作，形成一种复杂且精巧的结构。虽然每个模块可能都是通过程序实现的，但这些模块之间的协作关系以及整体的非功能性设计显然已经超出了一般意义上的“编程”的范畴。与之相应，每个模块中局部的程序规约显然不再直接取决于原始的问题和用户需求，而是由逐层精化的设计方案所决定。
软件系统需要经历长期的演化和维护过程软件系统根植于复杂的社会物理环境之中，外部的各种因素变化以及技术本身的发展都会导致软件自身的演化。为此，软件设计需要考虑长期演化和维护的需要，例如采用松耦合设计、强调可扩展性等。此外，软件系统经历长期的演化和维护之后，自身的规模和复杂性不断增长，从而使得进一步的修改越来越困难。
让我们通过一个例子来类比一下。一个小老板带着一伙人干成了一笔买卖，赚了一笔钱，现在考虑如何公平合理地把钱分一下，让大家都满意。此时，他需要的是一个一次性的解决方案，不管是哪位睿智的长者给他出个主意还是找个计算机能手编个程序算一算，反正只要最终能产生一个大家满意的分配方案就行。接下来，这个小老板逐渐成长为一个管理一家公司的大老板，他希望为整个公司构建一个工作评价与薪酬管理系统，用于收集和分析每个员工的工作情况，同时管理员工的薪酬评定和发放。这套系统的建立无疑为公司建立了一套秩序，每个员工都会根据系统中的逻辑进行工作评估和薪酬发放。同时，这个系统需要综合考虑多个方面的功能性和非功能性需求，例如为防止错漏而实现的账目比对功能、针对安全性需求的敏感数据加密以及流程监控与审计机制、针对可靠性需求引入的分布式存储和多副本服务部署等。此外，系统包括许多相互协作的软件模块同时随着时间的推移不断演化。例如，由于业务量持续上升，系统经常出现日志打满的现象，为此系统又额外引入一个定期的日志转储和清理的功能，并由一个参数配置来决定自动触发频率。这些不断扩展且一环套一环的设计考虑逐渐堆积出一个复杂且精密的软件系统。事实上，编程与软件开发的区别是一个长久以来存在的问题。但为什么过去我们似乎不用太过在意这个问题，而现在我们需要特别阐述和强调这个问题呢？我想主要是三个方面的原因。
软件复杂性不断增长随着互联网的兴起，过去二三十年我们的数字化和信息化建设飞速发展，软件的规模和复杂性不断增长。当前企业软件开发越来越多面临的是存量系统的维护性开发任务，复杂性挑战凸显。
软件定义一切的发展趋势软件加速渗透到人类的社会物理空间，导致软件需求理解及设计方案所涉及的信息物理融合以及人机交互因素越来越复杂，同时系统的可靠性与安全性要求越来越高。
大模型代码生成能力越来越强软件设计与编码之间一直以来都难以分离，很多设计决策都是在编码过程中逐渐引入的（即所谓的演进式设计）。随着大模型代码生成能力的不断增强，编程（规约和边界清晰情况下的局部方案实现）与软件开发（面向不确定且持续演化需求的系统构建）之间的区分越来越明显：大模型擅长前者并将逐渐接管很多具体的编程工作，但对于后者则只能起到一些辅助建议的作用。
3．软件的三重角色和形态
我们正在讨论的话题还涉及到一个更加根本性的问题，那就是“软件是什么”。按照经典的软件工程教科书的说法：“软件=程序+文档”。很长时间以来，我们都有意或者无意忽略“软件”与“程序”、“开发”与“编程”之间的区别。这在过去似乎也没有太大问题，反正把程序写好也不是件容易的事情，也要思考很多软件开发的深层问题。但是现在，大模型表现出了很强的代码生成能力，以至于很多人相信自然语言编程的时代已经到来，而程序员和软件工程师都要失业了。这种情况的出现倒逼我们去思考“软件”与“程序”、“开发”与“编程”到底有什么区别，这其实也跟“软件是什么”这个问题密切相关。长久以来，我们经常会赋予软件很多不同的角色和定位，例如解决方案、工具应用、复杂系统等。这几种角色和形态对于软件都是适合的，但在大模型流行的当下，我认为我们要认真看待三者之间的根本性区别了。
解决方案用户实现一个目标的解决方案，如果这个目标是一次性的那么对于用户而言重要的目标的实现而不是软件本身。例如，用户想要喝上一杯美式咖啡，那么用哪个APP或者派人跑腿去买都无所谓，只要及时喝上咖啡并且成本可接受那么就可以了。
工具应用用户解决一类问题的软件工具，功能稳定，部署和运行环境简单。例如，最终用户使用的各种桌面工具，运维工程师自己开发并使用的各种脚本化部署运维辅助工具，以及一些简单的信息系统。
复杂系统具备较高外部和内部复杂性的软件系统，部署和运行环境复杂，有较高的性能和可用性要求，同时处于持续演化之中。例如，互联网公司提供的各种在线服务系统，以操作系统为代表的各种基础软件等。我们可以如下表所示从多个不同角度去理解三者之间的区别。对于解决方案而言，其核心要求是在控制成本以及确保完成时间合理的情况下帮助用户达成目标，一般可以在现有的工具和应用基础上通过方案规划和能力编排来实现。这种解决方案可以是一次性的（即用即抛），也可以保留后多次复用并按需调整，因此其设计复杂度较低，主要挑战是理解用户意图、完成目标和任务拆解、面向已有能力实现映射和适配。对于工具应用而言，其核心要求是正确实现用户所期望的功能并确保较好的性能和易用性，一般可以在流程和算法规划以及数据设计基础上通过编码来实现。这种工具应用可以根据用户需求的变化阶段性（例如半年）进行版本更新，设计结构较为扁平化，因此其设计复杂度一般不高，主要挑战是基于准确需求分析的业务和数据设计（如业务流程、数据库结构、算法逻辑等）以及特性（feature）之间的交互关系管理。对于复杂系统而言，其核心要求是在确保功能正确性和性能的同时提供较好的可用性和安全性保障，一般需要在理解系统整体设计的基础上仔细分析和定位问题并通过慎重的设计决策实现增量的功能实现和问题修复。这种复杂系统可能会根据用户需求频繁和持续地进行更新（特别是线上系统），具有复杂的外部运行环境和内部模块结构，因此其设计复杂性一般都比较高，主要挑战是在系统理解基础上的设计权衡决策以及面向系统持续演化需要的系统复杂性管理（如架构看护和设计重构等）。
形态核心要求持续演化要求设计复杂度主要挑战
解决方案目标达成、成本、完成时间无到低无到低意图理解、任务拆解、能力映射
工具应用功能正确性、性能、易用性低到中低到中需求分析、业务和数据设计、特性交互管理
复杂系统功能正确性、性能、可用性、安全性中到高中到高系统理解、设计权衡决策、系统复杂性管理
为什么要在大模型和Agent等AI技术迅猛发展的当下强调这三种软件形态的区别呢？因为AI技术对于这三种软件形态的实现能力存在着本质性的区别。对于解决方案而言，AI技术可以通过GUI Agent等形式直接进行方案的规划、实现以及执行过程中的动态调整，甚至可以在运行时按需合成程序并执行，此时人工编程已经不再需要。对于工具应用而言，AI技术可以基于用户需求描述生成较完善的软件Demo，或者在专家型开发者的加持下增量迭代地实现完整应用开发，此时人工编程已经成为辅助手段。对于复杂系统而言，AI技术在缺少开发历史和设计知识的情况下，很难形成高层的系统理解并提供自动化开发支持，此时人类开发者的知识和经验仍然发挥着主导作用，而AI技术主要是提供一些辅助支持（如问题分析和修改决策建议以及局部的代码补全）。我在《大模型时代的软件智能化开发：我们在哪里？该往何处走？》一文中谈论“软件的多样性”的时候提到过“软件频谱”的概念：这个频谱的左边一头是高度个性化和场景化的小应用，而右边一头则是以操作系统和互联网线上服务系统为代表的巨复杂系统。这里讨论的解决方案、工具应用和复杂系统三种软件形态大致位于这个软件频谱的左边、中间和右边。需要注意的是解决方案、工具应用和复杂系统这三种软件形态是从不同角度对软件的刻画，因此在某个具体软件系统中也有可能会混杂其中的两种或多种形态。例如，面向用户的场景化解决方案也可能会通过代码的形式沉淀留存并不断演化，最终形成一个面向广大用户提供高可用服务的线上复杂系统。设想一下，一个在线旅行服务系统既可以面向用户的某一次出行需求规划并提供全程方案，又可以通过手机App的形式让用户自己订票选座，同时自身还可以随着不断演化而形成一个越来越复杂的系统。 4．“自然语言编程”的适用场合
随着大模型和Agent等AI技术的发展，所谓的“自然语言编程”以及相关的“氛围编程”等口号开始流行甚至不绝于耳。很多人都在谈论软件开发的范式将要发生变革，“自然语言编程”的时代已经到来，甚至进一步推出“软件专业将成为新的天坑专业”这样的判断。“自然语言编程”这种口号的流行自然有一定的道理，因为我们还是经常可以在周围看到一些这方面的“成功故事”。事实上，只要是在身体力行地去实践和探索AI在软件开发中的能力边界而不是出于各种目的盲目吹捧和夸大AI的作用，“自然语言编程”方面的经验分享还是很值得去了解和学习的。根据我所了解到的各方面的经验分享以及我个人的理解和思考，“自然语言编程”的适用场合大致分为以下几种情况。
“即用即抛”的解决方案如前所述，大模型Agent在理解用户目标的基础上可以规划一个解决方案，通过灵活组合已有的能力和服务甚至动态合成一段程序来满足用户目标。
“即用即抛”的用户演示已有的大模型Agent可以根据用户需求描述生成一个用于用户演示的软件原型，虽然很多内部功能还未完全实现同时还可能存在一些bug，但足以通过界面操作向用户展示所构想的软件会是什么样的。事实上，这种用户演示就是经典需求工程方法中所强调的“抛弃型原型”。
扁平化的业务软件一些专家型开发者利用智能化开发工具所提供的大模型Agent能力实现了接近于“自然语言编程”的软件开发模式。他们在提供高质量甚至具有一定结构化的需求描述以及经过精心设计的软件实现规范和约束的基础上，驱动大模型Agent生成代码并迭代化地进行问题修复，直至得到完整的软件产品。整个过程中开发者很少甚至完全不需要手动编写代码，其主要任务是提供需求描述和实现规范、及时检查结果并提供反馈。
专家掌控的复杂软件一些专家型开发者利用Ask模式驱动大模型生成代码，辅助完成更加复杂一些的软件开发项目。在此过程中，开发者通过需求分析和设计规划，将软件开发拆解为较小的开发任务（我经常比喻成“画田字格”）并提供必要的上下文提示（除了功能描述之外可能还包括相关约束和提醒）让大模型生成代码，然后审核结果并及时提出问题和反馈。在此基础上，开发者手工进行代码的集成、适配和必要的调整。这几种开发方式之间的对比如下表所示，这其中大模型和Agent等AI技术所发挥的作用也各不相同。对于“即用即抛”的用户演示而言，AI技术凭借自身所学习的大量通用功能实现和代码模式可以一次性生成可供客户理解的演示系统，但千万不要指望产品经理可以按照这种模式得到完整可用的软件产品，否则就像我们此前的分享《氛围编程上头，工程实践下头：自然语言编程的真问题》中介绍的那样陷入迭代修改的无底洞。但我们确实也观察到一些专业开发者利用智能化开发工具所提供的Agent能力实现了中等规模（如10万行左右代码）的软件产品开发。这类软件虽然规模不小，但具有扁平化的设计结构，不同模块或子系统之间功能相对独立，可以分而治之。同时，扁平化的设计结构也使得报错信息以及增量的需求表达可以很容易映射到代码中相应的位置并由大模型进行修改。但我们应该看到，实现这种开发模式的开发者需要深刻理解所使用的开发框架以及大模型代码生成的特点，并据此通过系统提示对代码组织结构、功能实现方式等方面给出明确的约束和指导。至于更加复杂的软件，专家型开发者还可以依靠自己的能力和经验进行任务拆解，然后驱动大模型根据提示生成局部代码并完成系统集成。这是一种非常深入的人机协作开发模式，整个开发过程的整体规划和推进节奏都由开发者来掌握，因此要求开发者具有较强的分析设计能力和自制力。为什么要强调自制力呢？因为当大模型几秒钟吐出几百上千行代码时，开发者的理解能力和判断力将成为主要瓶颈，同时很容易在倦怠之中放弃对代码的严谨要求。当开发者逐渐放松警惕开始以一扫而过的方式和差不多就行的心态审核大模型所生成的代码时，他们也正在失去对于大模型代码生成过程的控制。 开发方式适用对象能力要求AI的角色代码规模
“即用即抛”的解决方案普通用户表达目标规划并执行完整方案无
“即用即抛”的用户演示产品经理理解业务一次性生成全部代码小
扁平化的软件产品具有一定经验的开发者理解业务并具备一定开发能力生成全部代码并根据反馈不断调整小到中
专家掌控的复杂软件专家型开发者具有较强的分析设计能力和自制力根据提示生成局部代码并按要求修改中到大
需要特别强调的是，专家掌控的复杂软件生成式开发在现实中往往还存在一些相关的限制。首先，这种方式一般适用于从零开始的新开发项目，这样就不会存在遗留系统理解的负担以及“贫嘴张大民的小屋”这般“神秘的”遗留设计。其次，少数几位（甚至就是单个）专家型开发者需要牢牢掌控整个开发过程，从而确保对整体设计的把握以及高质量的实现代码。如果这种精英化开发方式被打破，一些仅具有有限能力、经验和责任心的开发者参与集中，那么专家型开发者可能也无法再延续此前的成功故事了。5．结束语
在大模型和Agent等AI技术代码生成能力爆发式增长的当下，我们更应该正视软件开发中的系统复杂性问题。我们一般所谈论的编程以及大模型所擅长的代码生成主要都是面向解决方案和工具应用的构造，而企业软件开发很多时候在构造的是复杂系统。特别是在人机物融合智能化大发展的背景下，软件将更加深入地渗透到社会物理空间以及各行各业之中，同时更加广泛地连接各种原本孤立的局部系统，从而形成越来越高的系统复杂性。因此，我们在大力拥抱大模型和Agent等AI技术的同时也要更加谨慎地去讨论“自然语言编程”以及“软件开发范式的变革”这样的口号。正如我最近作报告经常说的，就像“抛开剂量谈毒性是耍流氓”一样，抛开软件的形态去谈软件开发范式的变革和软件开发效率的提升也是不合适的。我们需要在深刻理解软件工程根本原理和企业开发实践的基础上，通过长期的努力和坚持去构筑软件智能化开发的理论和方法体系，而不是在“大跃进”式的口号喧嚣中盲从盲动最后留下一地鸡毛。这篇文章讲的主要是智能化开发（AI4SE）的问题，但最后我还想再讲一下智能化系统（SE4AI）的问题。软件正在加速渗透到社会物理空间并逐渐成为重要的新型基础设施。即使在汽车等一些行业中，大家已经在迫不及待地高喊“AI定义”的口号，但正如我在《智能化时代的软件人才培养》一文中所指出的，最终赋能千行百业、释放智能潜力的一定是智能化软件系统，而AI模型将作为这种新型软件系统的一类重要组件存在并发挥作用。以Agent为主要形态的新型智能化软件正在涌现（我们也有一个组在做GUI Agent和AI云原生系统），甚至大家已经在构想和试验以Agent为主体的大规模交互与协作，因此不确定性甚至社会性正在越来越多地被引入软件世界。但也不要忘了，这一切都是建立在确定性的大规模软件基础设施系统之上的。就像我们人类社会，个体之间以一种自主和智慧化的方式开展交互和协作，促成社会经济生活的繁荣发展，但这一切都是建立在稳定可靠的现代化基础设施（如交通、能源、通信、金融服务等）之上的。同时，自主和智慧化的个体交互也需要建立规则和相应的监管机制，从而在激发不确定性所带来的创造性的同时维护人类文明的价值观。 作者简介
彭鑫，复旦大学计算与智能创新学院副院长、教授，国家级高层次人才计划入选者。中国计算机学会（CCF）杰出会员、软件工程专委会副主任、开源发展委员会常务委员，中国汽车工程学会汽车基础软件分会副主任，《Journal of Software: Evolution and Process》联合主编（Co-Editor），《ACM Transactions on Software Engineering and Methodology》、《软件学报》等期刊编委。2016年获“NASAC青年软件创新奖”，2023年入选上海市东方英才拔尖项目，2024年获得“中创软件人才奖”。主要研究方向包括软件智能化开发、AI原生与云原生系统、泛在计算软件系统、智能汽车及工业软件等。多次获得IEEE Transactions on Software Engineering年度最佳论文奖、ICSM最佳论文奖、ACM SIGSOFT杰出论文奖、IEEE TCSE杰出论文奖等奖项。担任2022年与2023年CCF中国软件大会（CCF ChinaSoft）组织委员会主席与程序委员会共同主席。阅读原文
跳转微信打开
