自从ChatGPT于2022年底问世以来，大模型就成为各个领域的热门话题，软件工程领域也不例外。特别是大家发现代码学习对于大模型的推理能力至关重要，同时代码生成又是大模型当前为数不多的一个比较明确的2B应用场景，因此“代码生成”就成了一个诸多企业和研究者关心的问题。所以我们可以看到，凡是炼大模型的企业都会同时搞一个代码大模型并作为一个独立的产品（有时候还会配合智能IDE）宣传推广，而大量人工智能学者也开始研究代码生成问题了。另一方面，关于大模型时代的软件工程，各种言论甚嚣尘上，人工智能、数据科学等其他领域的专家学者们也开始谈论编程的终结、自然语言编程以及软件开发范式的变革。

去年春天，在我组织的“智能化软件工程学术沙龙”微信群里就有专家提到：“GPT-4横空出世，和大刘笔下一样，大家分成了几个派别：降临派、拯救派、逃亡派、抵抗派”。有一位企业专家私信跟我说：“彭老师，我觉得你是抵抗派”，因为我老是说大模型在软件开发上这里不行那里不行。我这么做的出发点有公心也有私心：从公心上说，我确实觉得大模型在解决软件工程的深层次问题上没有那么强；从私心上说，如果大模型在软件工程领域无所不能，那么软件工程领域的研究基本都不用做了，等着大模型来降维打击就行。

事实上，我对大模型的态度也没那么负面，我们团队智能化开发小组现在基本上也都在拥抱大模型了。大模型的到来为我们打开了软件智能化开发的巨大想象空间，很多以前不敢想的事（例如生成式软件开发）现在可以去想了，认为做不到的事（例如整函数代码生成）现在可以做到了。但是，我认为要想实现更高层次上系统性的智能化开发还需要从软件工程的角度认真思考其中的根本性问题并深入探索可能的方法和技术创新。

关于当前发展的现状我的感觉是稍微有点过热了。一些乐观派认为以GPT为代表的大模型能力还在继续提升（GPT-4都这么厉害了，GPT-4o、GPT-o1更厉害，后面只会越来越厉害），提示窗口越来越大（以后是不是整个项目代码都可以一股脑扔进去），多Agent等技术还在不断发展（多Agent角色扮演，搞个虚拟软件公司自己就把活干了），因此我们就躺着等大模型解放码农吧；一些企业宣传自己已经有了基于代码大模型的AI虚拟程序员并贡献了代码库中百分之多少多少的代码；一些人根据大模型生成各种小游戏的速度越来越快就宣称这预示着软件企业产品迭代速度将会越来越快；一些人用大模型做了一下文本需求整理和条目化，生成了一些放之四海而皆准的宏观设计方案（例如标准的前后端分离和微服务架构技术栈），就说大模型懂需求会设计。另外，今年以来工业界和学术界都很热衷在SWE-Bench（一个基于GitHub开源项目创建的自动issue修复的数据集）上刷榜单。这种全自动的issue修复的研究当然是有价值的，但我实在不认为这会成为企业软件开发（维护型任务）的主流。目前看起来能够被自动修复的issue往往都是那种很容易直接定位的（例如issue报告中直接指出需要修复的地方），而在企业软件开发中仅仅是故障定位这一环节就可能会耗费大量的时间，这与软件需求和设计的复杂性密切相关。

当前这种过热的发展局面可能带来几个方面的负面影响。首先，导致整个行业上上下下的浮躁情绪，都在畅想大模型带来的美好愿景或者被由此带来的焦虑所包围，本该重视的软件工程基础能力和基础设施建设反而被忽视。其次，导致企业管理层对于大模型所带来的变化有过高的期望，在最初的大量投入之后没有看到预想的“颠覆性变化”（例如可以大幅精简开发人员队伍）就转为消极以待。最后，导致大众对于软件工程甚至整个软件行业的认知产生偏差，甚至有人说软件工程将成为新的天坑专业，因为未来AI都可以编程了，人人都是程序员。

在大模型热潮的席卷下，很多开发人员都已习惯于在日常工作中借助大模型来辅助完成各种开发任务。一些企业还训练了自己的代码大模型，以获得更好的特定领域代码生成和理解效果。关于大模型在企业软件开发实践中的实际应用效果和现状，我有以下几个方面的理解和感受。

基于大模型的代码补全、推荐、解释和问答等智能化支持得到了广泛应用。特别是近期火热的Cursor等工具通过人机交互和产品设计上的创新将大模型与IDE及项目上下文有机结合，显著提高了开发人员的智能化体验。然而，当前这种智能化开发支持很大程度上仍然是局部性的，也就是开发人员个体有感（例如显著减少了网络搜索、查询API手册、代码库查找等方面的时间）但项目和企业层面上没有太多感觉（例如未带来显著的开发效率和产品迭代与交付速度提升）。这是因为大模型当前主要支持的编码环节在软件开发全过程中的时间占比并不算高（一些企业报告在10-20%左右），同时任务协调和知识缺失等方面的原因经常导致开发过程中的卡点和堵点。

普通开发人员和专家型开发人员在软件开发效率和质量上存在着巨大的差异，这一差异随着大模型的应用被进一步放大了。普通开发人员对于大模型的能力缺乏必要的认知，经常随手使用大模型能力却又不擅长问题分解、上下文陈述和及时确认反馈，因此仅能获得一些浅层收益并且可能带来潜在的质量隐患（参见下面第4点）。而少量专家型开发人员已经掌握了与大模型的高效协作方式，善于需求理解和问题分解，熟知大模型擅长何种粒度和类型的任务，并能提供必要的上下文信息和及时的问题反馈。他们在大模型的加持下比以往更容易成为以一当十的超级程序员和全栈工程师。

许多企业软件开发任务都是维护型任务，即在一个存在多年的软件产品或系统上新增需求特性、修复缺陷或者通过重构提升性能和可维护性等。需要注意的是，在已有的软件基础上新增需求特性也是一种维护型任务，因为同样需要定位修改位置、修改/新增实现代码并控制变更影响。这些维护型任务可以细分为很多子任务，包括问题定位、修改实施、回归测试、变更影响分析、架构看护等，这些子任务的完成都要求对软件系统有充分的理解。大模型对于大规模复杂软件的理解能力有限，难以有效定位问题并提供智能化辅助支持。近期有不少工作关注于利用基于大模型的多Agent技术来自动修复SWE-Bench数据集中的issue（来自GitHub上的开源项目）。虽然取得了一定的效果而且榜单还在一直刷新之中，但是应该看到数据集中的issue经过了精心挑选，同时能够被自动修复的issue往往比较容易定位（例如issue信息中直接给出了修改位置或容易定位的关键词）。

大模型卓越的自动生成能力有可能会激发人性中的“懒”和“恶”。试想，如果一个着急下班的开发人员没有那么高的质量意识和自律性的话，那么他在发现大模型生成的代码像那么回事特别是还能通过测试的时候可能就会提交了事了。如此一来，大量没有经过仔细推敲和深刻理解的代码就进入企业代码仓库之中了。相比之下，如果每行代码都是自己写的话，那么思考和推敲可能会更多一些。此外，近期在交流中听到一个企业专家提到，一些开发人员会利用大模型大量生成测试用例以满足测试覆盖度要求（甚至会同时删除一些无法通过的手写测试用例），而这些测试用例很多时候揭错能力不足，由此导致虚高的测试覆盖度甚至麻痹大意。这些问题对于软件质量带来的潜在和长期影响值得引起重视。

图灵奖得主、《人月神话》作者Frederick P. Brooks在1987年的一篇文章《No Silver Bullet: Essence and Accidents of Software Engineering》中指出“软件开发的根本性（Essence）困难在于对于构成抽象软件实体的复杂概念结构的构思（主要是需求和设计），而产生这种抽象软件实体的编程语言表示只是偶然性（Accident）的困难”。而我的一个基本观点是，仅靠大模型技术的发展无法触发软件智能化开发的质变，因为这将涉及软件开发的根本性困难（即概念级别上的分析和设计），而大模型在这方面并不具备所需要的能力。同时，当前的主流研究路线（包括工业界）过于热衷于大模型和Agent等AI技术的“眼球效应”，在软件工程的本质困难上的思考不多。作为一个对AI只懂皮毛的软件工程研究者，我也只能更多从软件工程的角度思考其中的一些问题。这里分享下我自己近期的一些想法。

现在谈论软件开发范式变化和自然语言编程的人越来越多，有的来自于软件工程领域，有的则来自于人工智能和其他一些领域。谈论这个问题一定要特别注意软件形态的多样性。“软件”是一个很宽泛的概念。从个人数字助理、企业信息管理系统、嵌入式控制系统、电子商务系统等应用软件到操作系统、中间件等基础软件以及CAD、CAE等专用工具软件，软件的频谱非常之宽。

从开发模式上看，这个频谱的一头是高度个性化和场景化的小应用，实现结构简单（例如组合和编排一下已有的服务和API即可实现），生存周期短（甚至可以按需合成、即用即抛）。对于这类软件，最终用户编程（End User Programming）显然是一个不错的选择，而自然语言编程也是呼之欲出了。

这个频谱的另外一头是操作系统等大规模复杂软件，基础性和特异性强，功能及设计复杂，生存周期长且处于不断演化之中。对于这类软件，往往只有经验丰富的专家型开发人员才能驾驭（例如Linux内核维护者的高龄化已经成为一个问题），而智能化技术能提供一些软件理解和问题定位等方面的辅助支持就已经很不错了。

软件的复杂性首先体现在规模上。大家都知道大模型一次性生成几百行的小应用（特别是贪吃蛇、俄罗斯方块等通用域上的常见应用）已经不在话下了，但生成更大规模的企业级软件还是很困难的。但软件的复杂性还不仅仅只是规模的问题，而且还与软件的外部和内部系统复杂性相关。

从外部看，软件往往属于一个软件密集型系统（Software Intensive System）的一部分（其他组成部分还包括硬件、设备、人、流程、物理和社会环境等），软件作为一种满足用户需求的解决方案的有效性和正确性除了取决于自身之外，还取决于所处的系统上下文环境以及系统级的设计方案（例如软件与其他系统组成部分之间的职责分配和交互关系）。由此带来的问题是，理解及编写软件代码的一部分重要背景知识并不在代码本身而在代码之外（一般可以用文档来描述，但文档很多时候要么不可靠要么根本就不存在）。

从内部看，大规模复杂软件具有较高的设计复杂性。从高层架构到局部设计，一个个设计决策在不断回答如何将上层设计要求转化成下一层的设计结构考虑、职责分配方案、交互关系定义以及各种约束和约定。而且，从不同维度和关注点出发考虑的设计决策之间纵横交织，最终得到的设计结构很大程度上将被淹没和消失在代码组织结构（例如包/目录、类/文件、方法/函数）之中，同时造成大量关注点的“混杂”（与多个关注点相关的代码混杂在同一个代码单元中）与“散布”（与同一个关注点相关的代码散布在多个代码单元中）。这些设计知识的缺失导致了许多现实世界中的软件开发难题，包括问题定位、变更影响分析、回归测试范围界定、架构看护等。

软件的系统复杂性还体现在软件的精密性和演化性上。软件是一种高度符号化的解决方案表示方式，不管是代码还是配置文件，往往一点差错就会造成严重的系统失效，而一点改动就会造成不可预知的变更影响。这就导致在缺乏严密的验证手段的情况下（测试经常是有限和不完备的），通过大模型这种概率化的方式生成完全正确的代码往往是很难的。此外，大部分有生命力的软件都处于不断演化之中，这种演化往往表现为在既有软件系统基础上的“适应性生长”，也就是在已有的系统基础上不断尝试和调整从而实现新需求并确保系统的稳定性。有一位业界资深专家在交流时提到，从系统的角度看死代码有时候可能也是有用的，因为它已经自然成为演化过程中的一部分而后续的很多技术决策和尝试调整都是在此基础上开展的。由此带来一个问题，我将其称之为“代码的神秘主义”，例如开发人员经常不敢删除一段明显的“无用”代码，因为会感觉这段代码背后有着某种自己没有参透的神秘意图。

事实上，当软件的复杂度演化到一定程度之后，我们已经没有了掌握其一切奥妙的“上帝视角”，取而代之的是盲人摸象般的揣摩、理解甚至是猜测。一个旁证是随着云原生和微服务架构热起来的“可观测性”的概念：这种大规模分布式软件已经无法通过传统的单步调试这种“上帝视角”去观察和分析了，权宜之计是收集大量外部可见的可观测性数据（例如log、trace、metrics）并据此推测软件系统潜在的问题及其根源。

最后摘录一段《中国学科发展战略·软件科学与工程》中的论述为这段思考收尾：

当我们把代码生成作为软件开发的一种途径时，似乎软件开发是一个从输入文本（需求描述）到输出文本（实现代码）的转换过程。就算考虑开发人员的参与，那也最多是一个文本交互过程。而事实上软件开发具有很强的探索性。软件开发的目标是完成从问题空间到解空间的转换，而这两方面都具有很强的探索性。

从问题空间看，用户需求基本上很难做到一次性完整、准确表述，而开发人员在软件开发过程中一般都需要不断探索和完善对用户需求的理解。事实上用户自身也不见得一开始就能把自己的需求想清楚、说清楚。试想，简单如计算器这样的软件，用户也不太可能一开始就把所有细节表述清楚（例如按键后的界面和声音效果）。这种需求探索往往需要以原型演示为基础（需求工程中对于原型有着很高的重视程度）。

从解空间看，软件运行在复杂的软硬件环境基础上同时内部还存在复杂的交互关系，因此开发人员也无法仅通过代码就对软件最终的运行效果有完整、准确的认识。开发人员一般习惯于通过软件运行发现各种问题，包括功能和性能缺陷等，然后进行诊断和修复。这是因为软件运行效果不仅取决于内部各模块之间的相互作用，而且还取决于与外部软硬件环境之间的相互作用。这些很大程度上都无法通过代码来预测，而只能通过不断运行和观察来探索。事实上，很多软件也都是通过这种方式不断修修补补从而不断保持稳定可靠运行的。

说到这里，我想类比下机器人的具身智能。对于机器人，目前主流的观点是仅靠纸上谈兵的大模型显然不够，还需要反映物理规律的世界模型来让机器人进行自主交互和探索，从而形成具身智能。那么，软件开发的这种探索性是不是也意味着需要建立某种形式的具身智能，从而能探索如何与人磨合获得满意的用户体验以及如何与软硬件环境磨合实现良好的运行效果？这样的探索过程涉及软件构建、部署、测试等许多不同的方面和环节中的工具和系统环境以及用户的参与。

大模型带来的软件智能化开发浪潮才刚刚开始，我们需要从软件工程的本质规律和问题出发持续探索，不断推高智能化开发的水平和高度。以下是几个我认为有希望的探索方向，其中前两个与新应用开发相关而第三个与软件维护相关。

应用开发的探索过程需要人机结对共同完成，同时以一种演进式的方式来开展。在《ChatGPT协作开发实录：编程新手的试验探索》一文中，我们以俄罗斯方块游戏为例对不同的的生成式开发过程进行了对比实验。结果表明，与自顶向下、先生成设计方案然后逐类生成代码的方式相比，按照合理的特性拆解和演进式设计的思路与ChatGPT开展人机协作更容易实现完整的应用生成。参与实验分析的同学当时的总结是：

ChatGPT生成代码的能力是有目共睹的，但如何更好地使用ChatGPT，也紧密取决于使用者本身对于开发项目的理解和开发设计规划。在对项目有合理规划，并且对项目整体进行细粒度feature的拆解，甚至按照合理的顺序去逐步实现的情况下，ChatGPT能够发挥出更强的能力。

一直很推崇演进式设计的业界专家张刚看了我们的分享后给出了这样的评论：

演化才是本质。这个实验表明，逐层递进的演进式设计方案更容易得到结果，在俄罗斯方块这个规模的应用尤其明显。合理的演化路径会提升达成目标的效率。

为什么演进式生成更有效呢？以下是我的一点理解。首先，软件应用需求难以一次性完整准确表述，而后续需求变动可能导致此前确定的设计变动甚至推倒重来。因此，要允许大模型在迭代过程中不断对软件设计方案进行微调，而不是一上来就生成一个完整的设计。其次，逐层递进的增量开发能让大模型每一步都获得足够的上下文，避免空中楼阁式的代码生成。演进式的应用生成过程中，大模型每次都是在当前实现代码的基础上生成少量代码或进行微调；而逐类生成则意味着大模型需要在其他类不存在的情况下独立生成一些类的完整代码，犹如凭空建造空中楼阁一般。最后，演进式生成能让用户持续了解实现情况和运行效果并及时提供反馈。很多人的实践都表明，如果不能及时发现所生成代码的问题并及时提供反馈，那么大模型很可能会把开发人员带沟里。

为了实现有效的演进式应用生成，需要研究如何实现基于大模型的人机协作迭代化开发过程，包括需求及问题理解、特性拆解与编排、增量代码生成、结果审视与反馈等。

生成式开发其实在大模型出现之前就已经存在，只不过是以一种基于规则和模板的方式实现的，那就是低代码开发。低代码开发以DSL为基础，而DSL是业务和技术领域专家知识的一种凝练，因此可以认为是一种知识驱动的方式。由此可以认为DSL与大模型相结合的应用生成就是知识与数据双驱动的智能化技术发展路径的又一例证。

这一点我在《当“低代码”遇上“大模型”：兼谈人机物融合应用场景下的应用开发》一文中已经有所阐述，在此不再赘述，仅摘录一段观点如下：

企业软件开发中的维护型任务的一个主要问题在于知识的缺失。这几年我在报告中经常提到的一个口号是“软件开发最大的浪费是知识的浪费、重复思考的浪费”。重复编写的代码、反复揣摩的设计意图、重复犯过的错误…这些问题背后的知识也许曾经在开发人员的脑海中浮现过、在交谈讨论和聊天记录中出现过，甚至曾经被记录过，但就是无法在需要的时候出现。开发人员经常是在缺少架构约束、业务场景、系统上下文等方面的业务和技术知识的情况下完成开发任务的。而软件文档基本不可靠，要么过时要么从来没有存在过。在这种情况下，期望大模型能够理解大规模软件代码及其背后的需求和设计知识显然不现实。

基于大模型的代码数字孪生试图以一种与代码双向映射、协同演化的方式抽取、积累并持续更新关于代码的高层知识。一般数字孪生都是指对现实世界系统（大到城市小到发动机）的一种数字化和可视化映射，其中伴随着对系统核心规律和机理的抽象与建模。而这里说的代码数字孪生则是代码中所蕴含的需求与设计知识的抽象与建模。为此，可以将程序分析与大模型相结合，从代码、文档、开发历史、运维数据等不同渠道抽取关于软件更抽象层次上的实体、概念及各种关系。另外需要注意的是，代码数字孪生的构建还需要人的参与。试想，一个开发人员花费很长时间弄懂一个软件背后的设计思想之后如何有效将所获得的知识贡献出来并能在后续软件开发和维护过程中被有效利用？大模型在知识抽取、关联和利用等方面的强大能力不仅可以使得散落在代码、文档、开发历史等各处的软件开发知识能够被有效利用，而且可以激励更多的开发人员以众包的方式贡献自己对于软件的理解和开发经验。

说到这里，似乎还可以把软件知识积累这件事推到一个更高的高度。“软件定一切”、“人类文明运行在软件之上”已经成为公认的发展趋势。未来，人类的衣食住行以及经济社会发展方方面面都会由软件承载并实现高度的智能化，经济社会运转规律将越来越多地以软件功能逻辑的方式呈现。另一方面，软件将成为一种新型基础设施同时其规模和复杂度不断提高，逐渐成为一种巨复杂系统。因此，关于这些软件的知识积累和沉淀也许也会成为我们人类文明记录的一部分。

大模型技术发展助推软件开发进入智能化时代。基础大模型及微调、提示工程、检索增强、多Agent技术等大模型相关技术在其中扮演了重要的角色。从企业实践看，代码推荐、片段生成、代码解释、代码重构、缺陷检测与自动修复等局部的智能化支持得到广泛应用。然而，更加系统的智能化开发能力仅掌握在少数专家手中，而其诀窍在于将人的问题分解、设计规划、代码审查、问题反馈能力与大模型的自动生成能力有机结合。

当前大模型主要是在一些局部任务上发挥作用，而无法在更大范围内和更高层次上提供智能化支持。我的一个判断是仅靠大模型技术的发展无法触发软件智能化开发的质变。这是因为智能化开发能力的进一步提升涉及软件开发的根本性困难，即概念级别上的分析和设计，我们无法将突破的希望寄托在大模型自身的发展上，具体表现包括大模型在设计知识的学习以及复杂软件维护任务的困难上。而当前的主流研究路线（包括工业界）过于热衷于AI技术的“眼球效应”，在软件工程的本质困难上的思考不多。

对于应用开发而言，人机协作的智能化开发应当成为企业追求的主流方向，其中包括几个重要的方面。

对于复杂软件的维护任务而言，通过大模型增强的代码数字孪生实现软件开发知识的有效积累和利用。对于具备长期维护价值的系统（如Linux）而言，共建、共享与代码同步演化的代码数字孪生平台（包括代码及其高层知识）具有重要的价值。当前的软件开发知识高度分散和碎片化，而大模型强大的知识抽取、关联与利用能力为软件开发知识积聚提供了有效手段。在此基础上，还需要以某种适当的方式（例如与日常开发过程自然融合）吸引和鼓励开发人员贡献自己所拥有的软件开发知识（例如代码背后的软件设计决策及其他业务和技术背景知识），同时还需要不断发现关键知识缺失并通过专家反馈进行补充。

写到这里，这篇文章基本上已经写完了。但因为前几天在我组织的智能化软件工程沙龙群里的讨论，这里还想再谈一个问题，那就是未来是否还需要编程。那次讨论的起因是“大模型是否具有推理能力”，进而发展到“未来是否还需要编程”。激进派认为大模型自由自己的一套推理机制，不必非要套用人类那套概念化推理模式，进而大部分地方软件也可以消失了（由大模型接管了）。我自然属于保守派，认为大模型并不会真正意义上的“推理”，在软件开发上也只是辅助作用，而未来人类还是需要通过程序来掌控我们这个世界。通过讨论我发现激进派的观点自有自己的一套逻辑体系：因为大模型自有自己的一套“推理”机制，因此我们说的大模型不会推理的那些问题只不过是一个鲁棒性问题（这个是可以持续改进的）；同时，人类未来也不一定需要知道怎么回事（可解释性和可控性不那么重要），只要AI把人服务好就行。所以，最后我发现两派观点分歧的根本原因在于关于AI的价值观选择上：如果人类打算将很多东西的控制权让渡给AI，那么自然也可以接受AI那种概率化的“推理”（以后再说运气不好可能部分就是AI造成的），而程序很大程度上也没有存在的必要了。