自大模型引领新一轮技术变革以来，各行各业均受到其带来的范式转变的影响。在今年四月于上海举行的全球机器学习技术大会上，我发表演讲时指出，大模型为计算产业带来了计算方式、开发方式、交互方式的三大转变。今日，软件研发技术盛会召开之际，我愿与各位共同深入探讨过去一年中关于软件开发智能化趋势转变的思考与探索历程。

在去年四月举办的全球软件研发技术盛会中，我提出了名为《五级“自动软件开发”参考框架》的论文，该框架参考了自动驾驶领域的五级分类体系，并将智能化软件开发能力划分为 L1 至 L5 共五个等级。

在这一年多的研发历程中，该参考框架通过与众多客户的紧密合作、在国内外专家的深入研讨中，持续得到优化与充实。同时，在推进软件开发智能化的实践中，我注意到业界存在一些较为显著的认知偏差。

首个误区在于codejock software，当大型代码模型工具问世后，人们会发现它在处理日常相对简单的代码任务时表现尚可，然而在具体的企业级项目中，其表现可能并未达到预期水平。这是为何呢？目前这些大模型主要依赖开源代码进行训练。我将这些代码称为结果数据，它们已经过编译、执行和正确性检验。然而，它们在训练过程中所依赖的过程数据却基本未被纳入训练范畴。这并非人类生物神经网络的学习途径，亦非大规模数字神经网络模型所采纳的正确学习模式。

第二个误区在于，当前的大规模代码模型训练主要依赖软件系统的静态属性。然而，观察Sora等模型在自然语言处理和视觉领域的训练成果，其表现明显优于代码领域。这其中的原因究竟是什么呢？在自然语言处理以及视觉识别的训练过程中，其动态特性尤为显著，诸如语言的上下文关联、事件的前因后果、叙事的线索，以及视频的时间序列等动态信息，都蕴含着丰富的知识体系和逻辑关系。然而，在软件开发领域，将这种动态特性的数据特质引入模型训练的情况并不多见。

第三个误区在于，一旦大模型问世，它们似乎能够通过图灵测试，甚至在某些领域超越了普通人的能力。这种情形很容易让人抱有一种期待，那就是寻求一种能够一蹴而就、一劳永逸的智能解决方案。去年四月，我们在上海成功举办了SDCon 2023全球软件研发技术大会。那时，众多业界同仁纷纷期待，能否将我的需求一次性传达给大模型，而大模型能否据此生成一个真正能够运行的软件项目呢？一年多的时间过去了，我们逐渐意识到这一点并不切实际。今天，我想强调的是，这种期待在长期看来同样不现实，因为智能的发展并非一蹴而就，不存在一劳永逸、立竿见影的解决方案。

第四个错误观念在于，自从Law被行业视为典范之后，众多人士纷纷渴望寻求一种全能型的超级智能。他们期望通过一个超级模型，一次性解决软件开发过程中遇到的种种复杂难题，然而这种想法极为不切实际。正如复杂的人类社会无法仅凭一位超人就能解决所有问题，复杂的软件领域同样无法仅靠一个超级模型来应对。

针对以上几个误区，我想谈一些实践和探索的观点和思考。

大模型问世后，我们中的一些人常常认为上一代的事物应当被完全摒弃，大模型为我们开启了一个全新的领域。但我想要强调的是，我们在上一代所积累的丰富经验和智慧并未被遗忘，它们非但未被抛弃，反而被 AI 技术所压缩和加速。这些经验和智慧构成了人类知识宝库的一部分。

接下来，我们将深入探讨，在大型模型盛行的当下，有哪些珍贵的经验和智慧能够助力我们在软件开发领域取得更佳成就？我们指出，软件系统具备四大复杂特性，它们分别是：复杂性、动态变化、协作互动以及混沌无序。

首先，我们需要关注的是复杂性这一概念。在处理软件系统中的复杂性时，通常有两种方法被广泛应用，首先是采用分解策略，其次是运用抽象技术。

在过程式编程领域，分解一直是一项极为有效的策略。这一理念后来催生了分层架构、组件化设计以及微服务架构等概念。然而，实践过程中我们意识到，单纯的分解并不足以解决问题，于是抽象技术应运而生，进而衍生出面向对象编程、泛型编程、领域驱动设计以及概念驱动设计等多种方法。观察大型模型的表现，我们发现它在“分解”方面表现尚可，然而在“抽象”方面则稍显不足。

观察当前大型模型辅助软件的研发水平，我们可以发现它在哪些方面表现突出？类型构建、函数编写、算法设计等低层次抽象工作似乎是其强项；然而，当面临设计模式、架构构建、系统规划等高层次抽象任务时，其表现却显得不尽如人意。针对这一现象，我们建议向大模型中引入我们在处理高层次抽象任务时积累的丰富方法论、核心原则以及优秀实践。这些内容并不局限于代码，它们还涵盖了设计图纸、设计文件等多种形式。在某种程度上，这也促进了大型模型“2”功能的增强。

丹尼尔·卡尼曼，这位诺贝尔经济学奖获得者，在《思考，快与慢》一书中，提出了人类思考的两种主要模式。第一种是系统一，它以直觉、迅速和无意识为特点，在我们日常生活的决策中占据了95%的比重。而第二种则是系统二，它依赖于逻辑、理性、规划和缓慢思考，需要我们高度集中注意力，在我们日常决策中仅占5%。 2 的能力对于大模型在软件开发领域的“抽象能力”至关重要。

在第二部分，我要探讨软件的动态特性。这种特性实际上指的是我们的软件系统持续不断地在演变。我们了解到，在软件开发领域，最初人们一直致力于追求自上而下的瀑布模型，然而，业界逐渐发现，在众多领域，瀑布模型的应用效果并不理想。究其原因，在于软件开发过程中存在一个“时间”这一变量codejock software，软件的需求、所处的环境以及开发组织等方面都在不断发生变化。

这种“动态性”在大型模型时代是否会发生转变？我认为可能性极低。因此，我们不应试图追求一次性实现完善的智能软件开发。

演化是智能的根本属性。智能并非一蹴而就，而是在不断迭代、试错与反复中逐渐成熟。在我看来，随着大模型时代的到来，敏捷软件开发并非会被淘汰，反而会从“组织层面的敏捷”转变为“模型层面的敏捷”，并且这一转变将加速敏捷开发的进程。在敏捷开发出现之前，软件开发的周期通常以年为单位进行迭代，例如在1995年、1998年等。敏捷开发模式之后，软件行业开始采用每月或每周为周期的迭代模式。然而，随着大模型时代的到来，软件开发将迈入以每日或每小时为单位的快速迭代阶段。

在加快迭代进程的同时，我们还应当对大量的软件开发流程数据实施训练，以便模型能更深入地把握软件开发的“变化特性”。在此过程中，不妨借鉴近期发布的（动态集成开发者活动）的相关内容。

参考链接：

禁止访问该博客文章，请勿尝试进入。

本质上讲，软件开发并非一个独立存在的活动，它实际上是在人类开发者、代码审核人员、错误报告者、软件架构师以及各种工具（诸如编译器、单元测试、代码审查工具和静态分析器等）之间展开的交流。我们应当将软件开发的全过程视为训练数据的来源，而不仅仅局限于最终的成品代码。通过让模型接触到开发者日常工作中所见的情境，并分析他们的互动反应，模型能够掌握软件开发的不断变化和动态特征。

在研究过程中发现，模型生成软件项目的开发流程，与人类开发团队的操作极为相似。他们首先编写较为粗略的接口和框架代码，随后逐步细化并实现，这其中也包含了多次修正和尝试的过程。这与人们最初设想的从上到下逐行编写、一气呵成的开发模式大相径庭。真正的软件开发并非如此，由人类组成的开发团队亦非如此，以大型模型为动力的智能软件开发亦不会如此。

接下来，我打算探讨架构设计中的协同工作。众所周知，随着软件系统的日益复杂化，各个组件间的配合以及服务间的协同变得尤为关键。早在1967年，一位计算机科学家便提出了著名的“康威定律”。

康威定律强调“组织的沟通协作模式直接影响到系统的设计布局”，这一点在架构设计中被公认为首要原则。进入大模型时代，软件内部是否仍需协作？答案显然是肯定的，我们依然需要大量组件或服务的协同工作。然而，此时构建这些组件或服务的，可能不再是传统的软件团队，而是单个个智能体（Agent）。这些智能体之间自然需要相互配合，而这种配合必须遵守康威定律。我将其命名为“智能康威定律”，即智能体间的协作交流模式，将直接影响系统的整体设计结构。

让我们深入探讨软件开发领域的工具，这些工具旨在在混沌无序的系统中寻找那些可确定的元素。尽管目前大型模型往往执行的是不确定性的运算，亦即概率性运算，但这并不强迫我们在所有任务中都采用此类运算。实际上，我们在大型模型问世之前已经积累了大量确定性运算的工具，这些工具在大型模型时代依然有其价值，并且有望与大型模型实现有效的结合。融合方式就是通过 Agent（工具）来实现工具调用。

概括而言，针对先前提及的软件系统的四大关键属性——即复杂性、变动性、协同性以及混沌性，在当前大模型时代智能软件开发的新范式之下，我们必须着重加强以下四个核心能力的构建：

训练并增强大型模型的抽象能力，即对2的掌握能力，这一课题具有极高的研究价值。

第二个演化关键点在于，如何在大规模软件开发全流程中提升我们的迭代速度，这不仅使我们能迅速推出高标准的软件产品，而且对模型性能的提升也具有显著作用。

第三个协作能力要求，我们必须对智能体的协作体系进行周密规划，以确保其与我们的系统设计框架相匹配。

第四个工具能力：使用工具来解决混沌系统中的确定性问题。

最后，我想探讨一下，提高软件开发智能化程度是一项复杂的系统工程。在此之前，我曾提及的四大核心能力，其背后依赖于众多基础工作的支撑，这其中包括模型构建和数据集成的相关工作。具体来说，我列出了以下十个关键领域：

首先，扩展定律并未停滞，它依旧扮演着关键角色；其次，这一点是我们对基础模型持续寄予厚望的。

第二，增强语境范围。语境范围相当于大模型的“记忆空间”，对充分展现模型效能起着至关重要的作用。在这一领域，无论是国内还是国外，都取得了迅猛的进步。

第三，对于大型软件项目而言，所包含的信息量庞大而复杂，因此大模型的长期记忆能力显得尤为关键。尽管外部检索技术如RAG等发展迅速，但在基础架构领域的创新同样值得我们期待。

第四点：关于2的进步。目前，大型模型普遍被视作高中生的智力水平。如何增强大型模型系统2的效能，这直接关系到它是否能够成为一位深思熟虑的专家级学者，进而胜任软件开发这类对智慧要求较高的工作。

第五，降低模型产生的错觉依然是行业面临的一大挑战。尽管我们不应奢望完全根除这种错觉。在某种程度上，错觉本身也是智能特性的体现，若智能缺乏错觉，其创造力也将随之丧失。

第六点：致力于研发全流程的数字化改造。具体来说，就是将研发过程中的开发者行为，诸如文档编写、设计图纸制作、代码编写、测试代码的生成、运维脚本的编写、会议纪要的整理，以及设计决策过程中的争论等，尽可能按时间顺序进行记录。接着，将这些记录下来的数据转化为数字化资料，为我们的巨型模型提供喂养材料。

第七，在软件开发领域，训练过程不仅涉及代码与文本资料，还包括大量的设计图表，如UML图、表格，以及视频等多样化的数据形式。

第八点：在软件开发过程中，众多具体任务实际上并不一定非得采用所谓的“大型模型”。相反，在高质量的专业数据集上进行训练的“小型模型”往往更为适用。这包括但不限于 Bug 的修复、开发者的测试工作以及编写整洁代码等方面。

第九点：利用模型生成代码、设计以及注释等内容，这些数据被用作其他模型的训练材料。这一做法在软件开发领域内，是一个备受关注的快速成长领域。

第十，面对繁复的软件工程项目，未来无疑将是一个由众多扮演不同角色、采用不同模型、执行不同任务的智能体共同协作的局面。

最终，我们才刚刚拉开软件开发智能化转型的大幕，途中仍有许多曲折需要我们去一一探索。期待今天的分享能够激发大家的灵感，感谢大家的聆听！

同时，我们向所有开发者朋友们提前告知，CSDN 将携手一家高端的 IT 教育平台，在2024年的下半年举办四场主题会议。我们诚挚邀请各位扫描二维码，积极参与其中。

*封面图由 Meta AI 生成

如有侵权请联系删除！