ARTICLE · 1232763
AI抽走了成长的梯子,软件工程课该怎么教?
复旦大学邯郸校区第四教学楼，这是上学期《软件工程》课程的一次项目汇报。我把讲台留给学生，自己坐到了第一排。第一个小组的两位同学走上台，一打开投屏，就给自己贴了一个标签：“重度依赖AI”。
这个标签是我要求的。那个学期，每个小组汇报时都要说明组内使用AI的方式和频率：是重度依赖、人为主导，还是某种中间状态。我不评判优劣，只想让大家正视一个事实：AI已经深度进入了这门课。
这门课我讲了十几年，甚至ChatGPT出现也将近4年了，但上个学期的情况前所未有。课程项目照例要求四人一组，以迭代方式开发一个网盘系统。分组时，一位同学提出要一个人成组，像开一家一人公司那样，试试一个人加上AI能不能搞定整个项目；还有的小组凑满了四个人，却轮流值班，每次任务由一个人借助AI完成，其他人轮空。学期中间，我忍不住问助教：为什么有些同学会把明显不达标的成果也交上来？是不是AI给了他们一种无所不能的虚幻感觉？
转折出现在第三次迭代（Lab3）。团队空间、私密空间、权限、配额、回收站、分享等需求交织在一起，一些原以为以一己之力就可以轻松搞定课程项目的同学撞上了南墙。有同学在给助教的总结里坦承：孤立任务的编程和复杂工程完全是两回事，AI可以帮他快速起步，但长期规划、复杂性控制和边界意识这些工程判断，仍然需要人来完成。
那天上台的小组里，最终得分最高的一组则走了另一条路。四个人反复讨论、反复试验，摸索出一套自己的人机协作方式：架构由人主导，AI只提供灵感；实现时用人的判断去引导AI；测试再由人把关。组长对AI并不焦虑。在他看来，AI就像解物理题时用到的数学，只是工具，得先把问题想清楚，才知道该用什么工具、怎么用。
同一门课，同样的AI工具，学生们走出了截然不同的两条路。这让我想了很久：AI已经会写代码了，而且写得越来越好，软件工程课还要教什么？又该怎么教？这篇文章根据我近期的一个报告整理扩展而来，想把这一年的观察、尝试和思考写出来，和大家交流。
一、课堂真的死了吗：新问题，与被放大的老问题
AI对计算机和软件工程教育的冲击，可以归结为两个追问。一个关于学习方式：有了B站和大模型，还需要听老师讲吗？作业和项目AI都可以代劳了，还需要自己琢磨吗？另一个关于专业价值：AI都会写代码了，还需要程序员吗？
仔细分辨会发现，这些冲击里有一些是真正的新问题，有一些则是原有问题的放大。把这两类问题分开看，是我们思考教学改革的起点。
AI带来的两类冲击，以及本文的两条回应路线
新问题：AI正在抽掉能力成长的梯子
人的成长就像爬梯子，每个阶段都有对应的命题和挑战，克服了、成长了，再往上走。传统的软件工程教育就是这样一架梯子：大一学C语言、Python，掌握编程的基本语法；大二学数据结构、算法、计算机网络；再往后接触软件工程以及软件设计、软件测试等课程。这很像木匠学徒：先学会用锯子、刨子、锤子，再学做板凳、柜子，最后才能试着盖房子。
AI正在抽掉专业能力成长的梯子
AI的出现，第一次让学生有可能跳过梯子下面的几级。今天的大学生，就像小学生碰上了计算器的发明：我们可以禁止小学生用计算器，但大学生是自由的个体，没法像管理小学生那样阻止他们用AI写代码、写报告。有其他高校的老师跟我反馈，不少学生平时编程作业做得不错，期末机考分数却比往年明显下降——很多作业已经是AI写的了。
职场上也有类似的悖论。企业渴望有经验的高级人才，却越来越不愿培养初级程序员，因为初级工作的价值正在被AI抹平；业内甚至有人把逐行手敲代码戏称为“古法编程”。可高级专家恰恰是从初级岗位成长起来的。学生在校园里跳过了底层训练，到了职场又找不到初级岗位，十年之后的高级人才从哪里来？
更值得警惕的是能力的隐性分化。很多人都已经意识到了，AI对人的能力的影响不是加法，而是乘法。分析设计能力强的开发者在AI加持下很容易成为超级个体，基础薄弱的则提升有限，甚至因滥用AI而适得其反。我在课堂上也观察到，坚持自己掌控分析设计、深入理解和验证代码的同学，更能打下扎实的工程基础；过早脱离设计和编码中推敲与思考过程的同学，则很难形成良好的品味和判断力。
老问题：AI让陈旧的课堂无处可藏
另一类问题其实早就存在，只是被AI放大了。
今年4月，科学网上一篇题为《“课堂已死”：一位大学老师的心声》的文章引起了很多共鸣。作者王春艳老师发现，学生真正依赖的已经不是课堂，而是B站、考研视频等各种讲解视频；以教师为中心、以当堂讲授为主的传统课堂，在大学里已经大面积失效。原理和脉络如果不能马上换成分数和简历上的优势，就很难抢到学生的注意力。
这篇文章说出了很多老师不愿承认的事实。其实，抬头率下降、讲授吸引力减弱，在B站和慕课时代就已出现；以教师为中心的知识输出、按知识点编排的内容、只看结果的评价，这些老问题一直都在。AI只是让它们再也藏不住了。
但我更认同这篇文章后半部分的判断：“死去的，是教师作为知识入口的时代。”今天的学生可以从网络资源和AI那里获得非常丰富、高质量的知识，不再必须依赖课堂才能学习。但面对茫茫知识海洋，他们往往不知道方向。未来的课堂真正需要留下来的，是一个锚点，让学生在更开放的探索中不至于迷失。
所以，我们今天面临的不是要不要在课堂上禁用AI的问题，而是要更彻底地完成一次转变：从以老师为中心的知识输出，转向以学生为中心的认知和能力形成。对新问题，我们通过课程实践的调整来回应；对老问题，我们尝试从教材和教学方式上重新来过。
二、锚点在哪里：编程不等于软件开发
如果课堂需要锚点，那么软件工程课的锚点在哪里？要回答这个问题，需要先回到一个基本区分：编程不等于软件开发。
今年春季学期，我还牵头开设了一门面向全校的《生成式软件开发》课程，教其他专业的同学通过和AI对话，把想要的软件聊出来。看到程序跑起来时，同学们的兴奋都写在脸上：人人都可以成为“大众开发者”了。但大众开发者离专业软件工程师还很远。那学期的软件工程课，我几乎每次开头都要花几分钟讲这个区别，就怕大家在AI的迷雾中迷失方向。
程序是一段代码，软件是一个系统
经典教科书把软件定义为“程序+文档”。但在“软件定义一切”已成为广泛共识的今天，我们有必要重新审视编程与软件开发的区别。一段程序往往功能单一、逻辑清晰；而一个软件系统：
•着眼于长期稳定运行，并且要有效应对各种特殊情况；
•根植于复杂的社会物理环境之中；
•包含复杂而精巧的设计结构，各个部分密切配合；
•需要经历长期的演化和维护过程。
一个成熟的软件系统，代码量可达数万行乃至几千万行，内外部存在复杂的相互依赖，牵一发而动全身。这就好比一栋大楼，想改一面墙，承重结构和水电管线都可能受到影响。驾驭这样的系统，需要系统观和演化观：前者看清工程的完整环境和模块间的耦合，后者预判未来的变化，并在设计时预留空间。
我常用电视剧《贫嘴张大民的幸福生活》里的一个桥段来说明演化的复杂性：张大民一家七口挤在胡同小屋里，他想在院子里加盖一间房，可巴掌大的空地上偏偏长着一棵不能砍的树，于是他干脆把树盖进了屋里。很多有着多年演化历史的企业软件系统，就像张大民家的小院，在各种可知和不可知的约束下，经历一次次修改和扩展，才成了今天的样子。
为什么今天要特别强调这一点？一方面，软件的规模和复杂性不断增长，并加速渗透到社会物理空间，对可靠性和安全性的要求越来越高；另一方面，大模型代码生成能力越强，编程与软件开发的区别反而越明显：大模型擅长前者，但从根本上缺少应对系统复杂性的手段。
功能跑通，只是冰山一角
AI对软件工程教育的双重影响
这也让我们重新认识AI对软件工程教育的影响。事实上，影响是双方面的，就像硬币的两面。消极的一面是，大量通过AI生成代码之后，学生对软件设计、高质量编码以及团队协作等重要工程实践的体验被大大削弱。积极的一面是，当AI可以快速生成代码，并且屏蔽了开发框架和工具使用等细节上的障碍之后，同学们反而有机会对更加根本的专业核心能力——分析、设计、验证——有更多的体验。
AI对软件工程教育的双重影响：硬币的两面
以前，课程项目的不少时间花在学习框架、配置环境上；现在AI把这些水面上的障碍抽走了，水面下的核心能力反而浮了出来。我们可以布置规模更大、难度更高的任务，让学生真正触及系统的复杂性。锚点就在这里：AI可以快速写出代码，但需求分析、设计规划、验证确认，以及驾驭复杂性的系统观和演化观，仍然是软件工程师不可替代的核心能力。
AI让原本淹没在大量编码细节中的软件工程核心能力浮出水面
三、我们的做法：拥抱AI，也让AI的短板显形
基于这样的判断，我们在课程中采取了两手对策：一手拥抱AI，把AI辅助开发纳入教学，同时讲清它的短板；另一手突出软件工程核心能力，通过增加项目复杂度和需求变更，让学生亲身体验AI的不足，以及分析、设计和验证能力的价值。
不禁止，而是鼓励
我没有阻止学生使用AI，反而在第一节课就鼓励大家用，同时讲清AI在复杂软件开发中的局限。教学内容上，我们增加了氛围编程（Vibe Coding）、提示工程、上下文工程、规约驱动开发（SDD）等内容，并专门讨论复杂软件智能化开发的机遇与挑战。
我们还把如何使用AI本身变成了课堂讨论的内容：邀请各小组分享自己的AI辅助开发模式，对比优缺点。开头提到的汇报时贴标签，也是出于同样的考虑：让大家在比较和反思中，找到有节制、有掌控的使用方式。
让项目只靠AI过不去
课程项目的设计花了我和助教们不少心思。项目要求以迭代方式开发一个完整的网盘系统：功能上，从Lab1的上传、下载和目录管理，逐步增加团队空间、私密空间、权限、配额、回收站、分享等；要求上，从高质量编码、单元和接口测试、版本管理和协作开发开始，逐步增加软件设计、需求分析、系统测试和持续集成。具体做了这样几方面的调整：
•强化交付质量要求，通过严格的测试暴露各种隐藏的缺陷；
•阶段性验收考察对代码的理解，要求学生讲清代码逻辑，并能手工修改代码；
•持续的需求变更和精细化的开发要求，暴露AI在软件设计、增量修改和扩展上的不足；
•提供更具挑战的选择，本科生可以参与博士生主导的一个十万行级开源项目——校内智慧学习协作平台；
•设置前沿探索任务，围绕AI辅助开发能力的评价和改进开展实践研究。
网盘项目：需求层层叠加，AI的短板逐步显形
这背后的设计思路很简单。如果同学们到学期末都可以用AI轻松搞定课程项目，那么他们不会对软件工程有什么真正的理解，甚至会质疑软件工程存在的意义。与其反复强调软件工程很重要，不如设计一个必须靠软件工程才能走下去的情境，让学生自己撞到墙，自己意识到工程能力的价值。有了AI，大家能完成规模更大、难度更高的任务；相应地，我们对学生的要求也必须水涨船高。
撞墙是痛苦的，但这份痛苦正是我们想要的。在那个十万行级的开源项目里，带领本科生的博士生助教每个周末都要逐一审阅大家的代码。很多同学的代码被反复打回重写，一开始很挫败，慢慢才开始理解什么是好的代码、什么是可持续的系统设计。他说：“你如果一直被取悦，你就不会有成长。”
四、撞墙之后：一个学期下来，我们看到了什么
学期结束后，课程助教袁子诚、李展发和修读课程的本科生吴嘉原，分别从各自的视角写了总结文章，发表在CodeWisdom公众号上。他们的观察比我在讲台上看到的更细致，也更有说服力。
助教视角：AI擅长局部，却担不起系统
助教们的第一个感受是，AI Coding已经成为默认工作流：从需求拆解、代码生成到测试和文档，大部分小组都交给编程智能体完成，前期效率确实显著提高。
但随着复杂度上升，尤其到了Lab3，系统开始涉及多种空间、权限、配额、回收站、分享、VIP规则等交叉逻辑，AI的短板逐渐显现：它擅长完成局部明确的任务，却很难承担系统级的软件工程判断。很多学生一开始觉得功能能跑起来就说明AI已经完成了主要工作，到验收和联调时才发现：单个接口正确，不代表整体流程正确；单个页面能展示，不代表业务语义一致；生成了大量代码，也不代表系统仍然可维护。
有个小组在复盘里记下了一个典型的坑：团队文件复制时，后端接口预留了teamId参数，前端调用时却没有传，目标目录就回退到了个人空间，用户看到的现象就成了团队文件只能复制到个人空间。这不是语法错误。前端和后端单独看都没有错，却没有人对整条链路负责。
验收中暴露的问题很有代表性：
•部分学生被AI带着走，而不是主动驾驭AI；
•AI生成的代码局部可用，全局设计能力不足；
•AI不会主动质疑错误前提；
•AI能生成测试，却不能保证测试有效；
•各自用AI生成模块，放大了团队的接口不一致和设计不统一。
其中第三条最隐蔽。有前端同学在提示词里假设后端已经实现了某个接口，AI不会反问这个接口是否真的存在，而是顺着假设写下去，甚至绕过后端、直接读浏览器缓存来模拟效果，然后告诉学生功能已经完成。只有在人工读代码、真实联调时，才会发现那条业务链路从来没有真正实现过。
为了判断这些问题是个案还是普遍现象，助教们设计了一套可量化的代码质量审查方法，对13个小组、总计约20万行代码进行了系统评审，记录了437条有效发现，其中高严重度问题97条。一个很有意思的规律是：越是可以在单个文件内识别和修正的问题，整体表现越好；越需要跨文件、跨模块、跨迭代判断的问题，表现越差。
13个小组代码审查中的高频问题
这些项目并不缺少分层目录、DTO、Service这些形式上的结构，事实上AI非常擅长搭出这样看起来很专业的代码结构。真正的问题在于结构、边界和领域模型没有随代码一起演化。一个最初只负责上传的FileService，几轮迭代后同时管着下载、复制、移动、回收站、配额和分享失效，上传方法的参数越来越长。每一步修改都说得过去，合在一起却成了谁也不敢动的“上帝对象”。AI擅长回答怎样把这次需求接上去，却很少追问承载需求的结构是否该变了。
还有一个小组，早期假设一个用户只有一套存储空间，到了Lab3要同时支持个人、团队、私密三种空间时，原有设计压力陡增，只能靠不断扩展数据库字段来补救。张大民家院子里那棵不能砍的树，一个学期就在代码里长了出来。
而最让我触动的，是一个被学生自己命名的现象：Who is the real agent? 代码评审不通过时，有的学生会变成“传话者”，在评审意见和AI之间来回搬运，真正做决策的似乎不是学生，而是AI。这让我想起一位业界专家的分享：他一直亲自审核AI生成的代码，有一天太累，觉得差不多就没细看；从那以后，他慢慢被架空了，等出了问题想改也改不动，因为整个系统已经不在他的掌握之中。
学生视角：AI的发展并没有让软件工程成为历史
吴嘉原所在的小组深度使用了Claude Code、Copilot、Cursor、Codex等工具，也保留了部分古法编程。回看团队与AI的对话记录，他们总结出三种人机协作模式：
•氛围编程（Vibe Coding）：按人工介入的程度，分为纯粹、监督式和约束式三种；
•精确编程（Accurate Coding）：需求原子化、没有模糊地带，让AI做小范围修改；
•启发式编程（Inspired Coding）：让AI快速生成Demo来理清思路，再推翻或部分推翻，重新设计实现。
在此基础上，他们形成了一套分工原则：设计阶段由人主导，AI可以提供灵感，但决定权归人；实现阶段人机协同，确保代码始终受控；测试阶段由人工掌控，不能全部交给AI自我测试。
设计、实现、测试三个阶段的人机分工
开头提到的那个得分最高的小组，摸索出的也正是这样一种方式。那天我在课堂上点评说，这种人机协同非常专业，正是很多一线资深工程师在采用的方式。吴嘉原在文章结尾写道：“工程的本质，永远在于用极致的秩序去对抗现实世界的随机性与复杂性。”一个大二学生能有这样的体会，我很欣慰。
先画好田字格，再让AI填空
我常用画田字格来比喻好的人机协作：人先把田字格画好，AI只负责往格子里填字。画田字格考验的是对系统全局的规划：每个格子的边界在哪里，接口在哪里，甚至还涉及一定的审美和品位。格子画对了，AI才能成为得力的助手，人机才能真正协同。
助教们的一句总结可以作为这一部分的结论：AI Coding确实降低了代码实现的门槛，但没有降低软件工程能力的门槛。经过多轮迭代和验收，不少同学不再把AI当成代码生成器，而是把它当作执行加速器，架构决策仍然由人来做。
五、试着重新搭一架梯子：从教到学，重写教材
课程项目的调整，回应的主要是AI带来的新问题。但前面说过，还有一类老问题被AI放大了，那就是以教师为中心的知识输出。只调整项目还不够，我们需要站在学生学的角度，而不是老师教的角度，重新思考整本教材该怎么写。
过去的教材：知识点很全，学生没有共鸣
传统的软件工程教材大多以知识体系为单位编排：软件过程、需求工程、软件设计、软件构造、软件测试、软件维护、项目管理……每一章对应一个知识领域，体系完整，逻辑严谨。问题在于，这是从老师教的角度组织的。学生按照知识点一个个学下来，对这些知识的作用、价值和应用却很难产生共鸣。
一个只写过几百行课程作业的大二学生，很难体会为什么需要模块化设计、回归测试和配置管理，这些知识往往只是考前要背的概念。在AI可以随时解释任何概念的今天，这样的传授更加乏力：知识本身并不稀缺，稀缺的是知道什么时候需要它、为什么需要它。
新的教材：一个软件从小板凳长成高楼大厦的故事
我们正在编写的新教材，换了一种组织方式：不再以知识体系为单位编排，而是设计了一个长线发展的故事情节。
故事的主人公，从自己家里使用的一个小程序出发。在各种力量的推动下，用的人越来越多，需求越来越多，对安全、可靠、稳定的要求越来越高，这个小程序一步一步成长，最后逐渐变成一个非常复杂的软件系统，主人公甚至要拿它去创业。整个故事分成五个阶段，每进入一个新阶段，不光需求更多了，安全性、可靠性、稳定性等方面的要求也更高了，软件的规模和复杂性也在不断上升。
更重要的是，在每个阶段，AI能发挥的作用、能帮的忙，以及它所面临的问题都各不相同。在故事的起点，主人公借助AI几乎可以独立搞定一切；随着系统越长越大，AI开始力不从心，那些只有软件工程才能回答的问题一个个冒了出来。这样，我们就把原来完整的软件工程知识体系打散，嵌入到五个阶段之中；AI辅助开发的方法，也分阶段自然地引入。
新教材：从按知识体系编排到沿着五阶段故事进阶
于是，学生不再是在不知道为什么、做什么用的情况下被动接受一堆知识，而是以开发者的身份走进一个长线故事：从做一个小板凳，到搭一间小木屋，再到盖起高楼大厦。每个阶段会遇到什么实际工程问题，引发怎样的软件工程思考，需要哪些方法和工具，知识和能力就在这个过程中自然嵌入。
打个比方，这就像一个人困了想睡觉，正好有人递上一个枕头。当学生真切地感受到系统改不动了、问题查不出来、协作乱了套的时候，模块化设计、自动化测试、配置管理、架构设计这些知识的出现，就不再是负担，而是及时雨。
其实，这和课程项目的设计逻辑一脉相承：网盘项目从Lab1到Lab4的迭代，是一个学期的缩影；新教材则把需求增长、问题暴露、工程思考、方法引入这条链条贯穿全书。
由此，新教材同时回应了前面说的两类问题。它把以知识体系为中心的编排，换成了以学生的认知过程为中心；也为被AI抽掉的那架梯子，有意识地重新搭起了台阶。每一级都是一个真实的工程问题，AI可以帮学生爬得更快，却不能替他们跳过台阶。
教师的角色：从知识入口到锚点
教材变了，教师的角色也要变。老师不再是知识的唯一入口，而是学生探索中的锚点和向导：设计问题情境，在学生迷茫时指明方向，在学生撞墙后帮助复盘和提炼。我们要进一步挖掘和锚定AI难以取代的课程核心内涵，同时借助AI实现个性化和智能化的指导，通过翻转课堂突出问题导向的探索过程。
六、我们要培养什么样的软件人才
再往前看一步，还要回答一个更根本的问题：智能化时代，我们到底要培养什么样的软件人才？
今天，从智能汽车、智能制造到智能牧场，软件定义一切的趋势越来越明显。《中国学科发展战略：软件科学与工程》指出，软件不仅是信息处理工具，也是管理各类资源、融合人机物的“万能集成器”，整个人工系统的复杂性正在向软件集中。驾驭复杂性始终是软件开发的核心挑战，AI改变了写代码的方式，却没有改变这一点。
因此，我认为智能化时代的软件人才需要两方面的素养。
一是软件定义一切的系统观：在资源层面，以软件定义的方式实现人机物三元空间中多元资源的虚拟化、分层解耦和跨域共用；在系统层面，以云边融合、边缘云原生的方式构建人机物融合系统，实现快速反馈、敏捷适应和持续演进。
二是面向人机协作开发的高阶工程能力，包括：
• 问题理解：发现问题的本质及其核心概念；
• 问题分解与管理：充分分解问题，并管理解决过程；
• 问题表达：清晰完整地表达诉求，提供必要的上下文；
• 验证与确认：快速理解和验证AI生成的结果，及时发现问题并反馈。
智能化时代软件人才的培养导向
归结起来，关键在于把AI快速探索和构建解决方案的能力，与严谨的工程化思维结合起来。
结语：回到那个周一上午
回到开头那个周一上午。汇报开始前，我花了几分钟跟同学们说：这是一个变革的时代，我们要看清大势。站在潮头、能驾驭AI的人，未来有巨大的发展空间；但如果被AI裹挥，失去了自己的判断力，就好比拄惯了拐杖的人，拐杖一丢，就什么都不会干了。
那天台上的小组，有的给自己贴上了“重度依赖AI”的标签，有的摸索出了驾驭AI的门道。他们面对的其实是同一个选择：是以作业和成绩这样的短期结果为导向，在AI的使用中一点点被架空；还是以长期的专业能力成长为目标，驾驭AI，为自己搭起成长的梯子。AI对能力的影响是乘法，而乘法有一个朴素的道理：如果自己这一项是零，乘以再强大的AI，结果仍然是零。
对我们老师而言，“课堂已死”并不可怕。死去的是教师作为知识入口的时代，教育本身并没有死。学生比以往任何时候都更需要一个锚点：帮他们在知识的海洋中找到方向，在撞墙之后看清问题，在AI的迷雾中守住判断。AI带来的新问题需要我们主动应对；被AI放大的老问题则提醒我们，有些改变早就该发生了。
我们的探索还很初步，新教材也还在编写之中。欢迎各位同行和同学一起交流、批评指正。
注：本文在AI辅助下完成，其中主要观点和逻辑来自本人。
参考与延伸阅读
1.袁子诚、李展发：《AI时代软件工程课该怎么教：来自助教视角的观察和思考》，CodeWisdom公众号，2026年7月26日。
2. 吴嘉原：《AI时代软件工程的价值：学生视角的实践体验》，CodeWisdom公众号，2026年6月10日。
3. 王春艳：《“课堂已死”：一位大学老师的心声》，科学网，2026年4月15日。
4. 吴月：《AI来了，大学课堂应该怎么变》，《人民日报》，2026年4月19日。
5. 国家自然科学基金委员会、中国科学院：《中国学科发展战略：软件科学与工程》，科学出版社，2021年。
作者简介
彭鑫，复旦大学计算与智能创新学院副院长、教授，国家级高层次人才计划入选者。中国计算机学会（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中国软件大会（CCF ChinaSoft）组织委员会主席与程序委员会共同主席，以及ICSE、FSE、ASE、ISSTA、ICSME、SANER等会议程序委员会委员。
