彭鑫-大模型时代的软件智能化开发：分析、思考与展望

⼤模型时代的软件智能化开发：分析、思考与展望 彭鑫复旦大学计算机科学技术学院pengxin@fudan.edu.cnhttp://www.se.fudan.edu.cnhttps://cspengxin.github.io 大模型冲击波 前哈佛大学计算机科学教授、谷歌工程主管 MattWelsh预测：生成式AI将在3年内终结编程，到那时候软件开发团队中只有两类人会保留，即产品经理和代码评审人员 码农们的焦虑 说了这么多年程序员要被AI取代，狼终于来了 研究者们的焦虑 一大波SOTA纷纷被ChatGPT轻松超越很多研究课题似乎没必要做了 迷茫… 确定：大模型助推软件开发进入新的智能化时代 不确定： 这种软件开发的智能化新时代是什么样的？ 在可见的未来软件开发模式将 会发生什么样的变化？有哪些开发岗位会消失？ 又有哪些新的开发岗位会出现？ 哪些软件工程研究还值得做？ 如果软件开发只剩下产品经理和代码审核员，软件设计还需要考虑吗？软件维护和代码质量还是个问题吗？软件测试还需要研究吗？ 冷静思考 类比：20年前所研究的软件复用和软件产品线 通过代码复制粘贴和API调用广泛实现局部复用并不难，难的是通过需求和设计规划实现系统性的定制化产品开发（例如软件产品线所宣称的那样） 与之相似，利用ChatGPT在软件开发过程中广泛实现局部的智能化辅助支持 （例如代码片段生成和技术问答）并不困难，难点在于如何利用它们实现端到端、系统性的生成式开发 重温经典软件开发的根本性（Essence）困难和偶然 FrederickP.Brooks.NoSilverBulletEssenceandAccidentsofSoftwareEngineering.Computer,Vol.20(4),April1987. 性（Accident）困难：根本性的困难在于对于构成抽象软件实体的复杂概念结构的构思 （主要是需求和设计），而产生这种抽象软件实体的编程语言表示只是偶然性的困难。 基于大模型的端到端生成式应用开发 分十次交互得到完整实现 ①创建游戏框架 ②使用GUI替换控制台 ③在GUI上显示一个L形方块 ④移动方块并且进行碰 撞检测 ⑤旋转方块 ⑥落下方块并且创建一个新的方块 ⑦检测游戏结束 ⑧增加整行消除功能 ⑨加入所有类型的方块 ⑩增加计分能力 实践经验 •整个过程几乎没有人工参与编写代码，生成的代码绝大多数都是正确的 •看起来懂设计，不仅是简单堆砌代码实现 功能，在恰当提示下代码质量一流 •从整个过程可以看到很好的由外而内，从宏观到微观的设计思想 •能较好地记住编程上下文，但是也会犯错 •具备自动化编写测试的能力，质量不比人类写的差 •由于俄罗斯方块是一个在通用领域很常见的问题，本文的测试不具备在专有业务领域的代表性，在专有业务领域是否可以达到相同的水准需要更为仔细地评估 张刚.ChatGPT结对编程实录：提升生产力，还是被代替？https://mp.weixin.qq.com/s/sUMt9oyASUU0eO9jlCurEw 大模型能掌握需求分析与设计吗？ 端到端的生成式软件开发需要逾越需求分析和软件设计这两座大山 ChatGPT似乎具有一定的分析和设计能力 •根据给定的高层需求自动生成细化需求，同时进行条目整理 可能的问题 •需要开发人员掌握整体的迭代过程，其中需要融入一定的设计思考 •根据要求自动生成需求描述的规范化表示，•开发人员需要不断检查ChatGPT产生的结 例如UML顺序图 •根据需求自动生成数据库表结构设计以及相应的建表SQL语句 •根据需求自动生成包含多个类的设计结构 •根据开发人员的提示以一种增量的方式逐步生成应用代码（这要求对原有的代码实现结构有理解） •根据一般的设计原则对代码进行自动化重构以提高可理解性和可扩展性 果，及时发现ChatGPT的错误并提醒修正 •特别是在需求分析过程中，ChatGPT进行需求细化主要依据常识或某类软件的共性特征，可能遗漏一些重要需求 •创新性或个性化需求也需要开发人员进行 补充 思考1：软件开发的规模和复杂性从人机两个方面形成了限制 •随着软件规模的增大，人脑可能已经无法掌控整个代码生成过程 •大模型本身对于复杂系统开发过程的全局掌握能力可能有限，经常出现顾此失彼的情况 •人工代码审核的需要使得人的理解和判断力可能成为瓶颈 思考2：大模型缺少抽象思维能力同时精确性不足 •大模型善于基于平面化的上下文以及提示信息产生相关内容，但对于大范围的抽象设计决策可能缺少相应的掌握和应用能力 •大模型概率性的本质与软件功能逻辑的精确性之间存在冲突 思考3：软件开发存在大量难以捕捉的“暗知识” •软件开发中的很多需求和设计知识并不存在明确的文字记载，它们可能存在于脑海中、白板上或讨论中 •此外，这类知识高度的抽象性甚至模糊性也使得大模型难以学习和应用这些知识 思考4：大模型对复杂系统的长期维护支持不足 •企业软件系统一般都有着很长的生存周期，其中的软件维护和演化过程中蕴含着很多软件工程问题和挑战 •大模型对于复杂软 件系统需求、设计及实现的全局理解及相应的维护支持能力可能不足 从大模型及软件开发的本质性问题出发的思考 拥抱大模型的正确姿势 大模型在一些编程任务上的优异表现让很多人感到很兴奋，同时也对大模型颠覆软件工程、实现全面的生成式软件开发的前景感到很乐观，但要谈大模型的软件开发能力首先要区分软件类型 对于小规模的软件应用，甚至适合最终用户编程的应用开发任务，利用大模型实现端到端的完整代码生成是完全可能的 对于大规模的复杂软件系统而言，根据需求陈述实现端到端的完整代码生成还不太现实。 拥抱大模型对于软件企业提质增效而言肯定是一个正确甚至必要的方向，然而要想实现系统和全面的软件智能化开发，还有很多基础性的工作需要去做，同时还有一些关键问题需要探索 建议1：扎实做好数字化和知识化积累 扎实做好数字化和知识化积累 •在扎实做好软件开发的数字化和知识化积累基础上与大模型结合实现更系统的智能化开发支持 •例如，构建领域通用组件库、建立 代码克隆及软件供应链的跟踪体系、建立开发任务及代码修改追踪关系、建立设计及代码映射关系 •这些数字化和知识化建设本身就可以提高软件开发质量和效率 大模型不仅可以为软件开发的数字化和知识化提供技术和业务背景知识，而且还为我们整合数字化和知识化平台中的信息和知识提供了一种有力的手段 软件开发自身数字化程度很低 •软件开发自身的数字化程度很低，例如：重新发明轮子的现象十分普遍；每次代码修改的前因后果不清楚，开发任务关联以及代码修改所带来的影响缺少系统化的记录 •软件中所蕴含的需求和设计知识缺少明确的描述以及与代码的清晰映射关系，导致开发人员经常就相同的问题重复思考 •在这种情况下奢望大模型直接带来跨越性的全面智能化开发体验可能是不切实际的 建议2：重视需求/设计/验证等基本能力建设 ChatGPT这类大模型并不会带来编程的终结，而是会复兴软件工程领域的一些根本性的技术，如需求分析、精确的规格说明以及软件验证（包括动态测试和静态分析） —BertrandMeyer《CommunicationsoftheACM》博客文章 这些软件工程传统技术有望在大模型时代重新焕发青春，但可能需要考虑如何与数据驱动的大模型技术有机结合 同时需要加强需求、设计、测试等方面的数字化和知识化基础设施建设 建议3：建立大模型/人/工具之间的智能交互引擎 核心问题：如何将人（开发人员）和机（大模型及各种工具）的能力有机融合和高效协同，实现软件开发的“超级自动化” 智能交互引擎主导，将开发人员的经验判断与各种工具的能力以及大模型的智能有机结合，并实现高度顺畅的智能化和自动化开发过程 主观和经验判， 如需求和设计决 大模型（外脑） 智能交互引擎实现开发人员与大模型之间的人机交互过程的会话管理，以“多线程”的方式与大模型开展交互式探索同时支持这些探索线索的按需拆分与归并 静态检查、编 译、测试以及 策、结果审核 交互引擎（内脑） 开发库查询等 开发人员（关键决策）开发工具（具身能力） 面向智能化软件开发的大模型增强 代码上下文 代表性技术：Cursor（https://www.cursor.so）从当前项目中选取可能相关的少量代码上下文 填充Prompt模板，为大模型补充项目上下文 当前修改的代码文件内容 光标位置前后20行代码 对话历史中的代码片段、标识符 项目定义的标识符 最近修改的20个文件里面相似的代码片段 验证反馈 通过自动化工具对大模型所生成的代码进行验证，通过结果反馈推动大模型迭代改进结果 代码理解：为代码生成自然语言解释（利用大模型），形成代码理解反馈 代码检查：代码静态检查工具结果反馈 编译器：编译结果反馈 测试执行：单元测试执行结果反馈 项目文档/文档库 利用各种大模型应用开放框架实现特定项目开发文档及相关背景知识的融入 项目开发文档：需求文档、设计文档、API文档、技术问答等 项目开发库：需求库、缺陷库、版本库等 业务/技术背景知识：特定领域业务及技术相关的术语表和知识图谱等 总结与展望 拥抱大模型对于软件企业提质增效而言肯定是一个正确甚至必要的方向，但是如何实现系统和全面的软件智能化开发还需要冷静思考，同时还有很多基础性的工作需要去做 对于企业而言对于学术界而言 扎实做好软件开发的数字化和知识化积累以及需求、设计、验证等软件工程基本能力建设仍然是十分重要的，而且也是实现更高水平的智能化开发的基本条件 面向系统和全面的软件智能化开发还是有很多工作可以做的，这也要求我们在理解大模型能力的基础上对于软件系统的复杂性以及软件需求和设计有更深的理解 谢谢！