面对AI4SE，你是降临派还是拯救派？

AI4SE的意思是AI,aka.LLM 在软件工程中的应用。

笔者认为会经历以下的几个阶段:点上辅助 ，由点到线，由点到面，奇点来临。

点上辅助

目前来讲AI4SE还以点上辅助为主。目前在IDE中通过智能化插件来赋能研发是LLM落地的一个典型场景，应用也最为广泛。例如在IDE中代码续写环节，用户可以通过tab键来接收LLM辅助生成并推荐的代码，效果已经优于原先由IDE供应商开发的续写插件了。因此，我们可以看到不同的智能化插件甚至是以智能化思路重新设计的IDE,如前段时间红得发紫的cursor。

有公司或者组织围绕着现行的研发流程和交付工序，规划了更为宏达的目标，从需求到开发、测试、运维的各个环节来应用大模型进行赋能。仿佛只要把原先软件工程中的各个环节（例如CMMI的22个PA）加上一个“智能化”或者 “LLM赋能”, AI4SE就能实现了。（以下是临时找的一个图，版权归原作者所有。）

笔者认为即使都实现了，也还是在点上，只不多有一堆点而已。而从数学上来看，一条线上就包含了无数个点。也就是无论多少个点，也就是一堆点而已。

由点到线

点上辅助环节的确能提高不少的软件研发的效率。不过这一类的解决方案，存在一个比较严重的问题，也就是LLM解决方案只扮演一个工具的作用，赋能环节必须依靠用户主动发起，有用就用，想用才用。对于最终结果的取得，起决定性作用的还是人。所以无论用不用大模型来辅助，首先和最根本的还是要解决人的主动性和意愿问题。

说到这里，可能读者已经感觉有点抽象了，毕竟这是一个正经的技术公众号。来举个例子，

SonarQube是非常多的团队在使用的代码扫描工具，可以通过它找出不少代码缺陷和安全问题，包括代码覆盖率指标等数据。通过团队会使用SonarQube提供的QualtiyGate(质量门禁)，通过设置“增量问题清零，增量覆盖率达标”的门禁来控制项目的代码问题不再增多，新增/修改代码的覆盖率得到保障。看上去这个举措的效果是挺好的。

不过，这其中还有一个存量问题和全量覆盖率如何整治的问题。而对于遗留代码，很多开发团队和开发人员都是抱着“只要线上没问题，最不要动代码”的思路，自身就没有去主动消减这些遗留问题。SonarQube里面的问题数量也就常年维持在高位了。

这时候，现行再好的工具，无论是LLM的还是传统的，都不能去解决这个问题。

这里插一句化打个岔，最近SonarQube官方发布了SonarQube AI, 通过LLM来分析和解决SonarQube扫描发现的问题。

还是以代码扫描为例，在这个环节，笔者想到了引入问题解决智能体，来实现问题发现-分析-解决-验证-关闭的全过程。这样，就实现了AI4SE的第二个阶段，从点到线。

例如，目前的流水线均已有托管和自动触发扫描的问题，把代码中的问题上报到sonarqube服务端。问题解决智能体在收到扫描结果后，就可以通过问题分类，将问题分发给后续的代码问题、安全问题、单元测试问题等专项问题解决智能体。

例如，对于某个代码问题，SonarQube可以提供详细的问题说明，以及问题对应的正向案例和反向案例。此外，它还指出了包含问题的是具体哪一行代码。 综合上述这些信息， 以目前代码大模型的能力，甚至是通用大模型的能力，都能分析并得到如何修改问题代码并给出修改后的正确代码以及配套的单元测试用例。修改后的代码，如果再通过单元测试用例的验证，就可以认为这个问题能够被解决了。

问题解决智能体就可以调用工具来生成补丁、代码合并请求(MP/PR)等方式来向代码库维护者来提交代码了，并监听结果。如果直接被接受，则完成问题的修复，如果维护者有新的评论，则再一次进入前述循环直至完成。

通过这样的方式，无论是新增问题还是存量问题，可以借助于LLM和智能体实现问题数量的削减。 这就是LLM能力从点到线的一个设想，标志着AI4SE从一个依赖人使用的工具演变成了能完成一项具体任务的智能体。（写到这里，感觉有点像K8S 云原生申明式API的设计思路，用户通过YAML申明需要几个pod，由K8S来负责启动和守护，出了问题pod挂掉了，K8S自动拉起直到达到预设目标）。如果用《三体》当中的一个武器来类比，可能是《古筝行动》中的飞刃。

风险提示：LLM能力不及预期，智能体发起MR/PR的代码职责归于审批人所有。

从线到面

如果能通过（多）智能体来实现某项任务的自主完成，就可以考虑尝试端到端的工作任务实现了。

以软件测试为例，笔者曾经写了一篇文章《LLM赋能测试活动实现端到端自动化的四个环节八项关键任务》,畅想了一下如果要实现软件测试活动的端到端自动化，至少需要在4个阶段实现8项关键任务。感兴趣的读者可以点击链接。目前来讲，业界已有不少团队在某几项关键任务上已经有成功案例或者是尝试，如 基于LLM的单元测试生成，你在第几级？、自动化用例执行的误报分析等。如果用《三体》当中的一个武器来类比，可能是《古筝行动》中的水滴，有接近无限光滑的无限坚硬的表面。

奇点来临

基于LLM的应用 X 基于LLM的软件工程 = ？

前面所说的这些，都是在现行软件工程的实践体系上应用LLM实现自动化和智能化的过程，也就是现行的物理定律都还是存在的。随着LLM在软件行业的全面应用，我们的应用系统也将逐渐由LLM来实现。在下面这篇发表于SEI官网的文章当中，两位教授提出了以下一个矩阵。

随着LLM应用于软件工程的深入，最终会出现用基于LLM的软件工程去实现基于LLM的业务系统的情况。后续的业务系统开发可能就是 数据 + LLM, 研发过程就是数据训练/微调+ 提示词工程、知识库建设等活动。甚至记得当DeepMind横空出世的时候，就有专家提出来过，未来用AI写代码，是不是就不再需要现行的人类可读的编码语言了，而是AI自己发明的语言。那么，我们现在所熟悉的软件工程，如代码编写、制品构建部署、测试、运维等，随着对象形态的变化，可能也会发生剧变。用现在的时髦话来讲，就是软件工程会形成新的范式。例如，目前的配置管理，主要是围绕着代码、制品、文档等实体，而未来的配置管理，是不是就主要管数据和提示词了？

奇点来临之后会是什么样？目前来讲还不清楚。如果用《三体》当中的一个武器来类比，我猜你一定想到了那个“智子”

那么回到文章的题目，当“智子”开始闪烁的时候，你是哪一派？