浅评ChatGPT在软件开发上的辅助能力（附GPT-4对比）
APP宣发
01
背景
于去年正式公测后，凭借其强大的自然语言处理能力迅速获得业内广泛关注，特别是辅助软件开发上，初步表现出了令人满意的能力，然而正当业内积极探索引入后的新工作模式之时，又发布了基于GPT-4架构的升级版本，在语言理解、逻辑推理、情感分析等方面赋予了更优的表现，甚至引入了多模态的能力。这一升级让人印象深刻的同时，也让人对的能力有了更多的不确定：
– 在软件开发上究竟能提供多大的辅助？
– 在GPT-4的加持之下，在软件开发辅助上的表现是否真的更加优秀？
– 传统软件开发究竟又会因此发生怎样的变化？
带着这些疑问，我们以两个前后端分离的本科课程项目为素材，以具体的项目场景为背景，对在软件开发上的辅助能力进行了简要的测评。
（注：为方便行文，后文提及的GPT-3.5指“基于GPT-3.5的”，GPT-4则指“基于GPT-4的”。）
02
需求生成
第一部分，我们模拟一个从零开始的开发场景，开发者只有一个关于目标系统的基础概念，将需求分析和细化工作全部交给生成。为了结果尽可能细致，我们在时加入了功能和非功能性需求的拆分。
▲ 对目标系统的概念描述
▲ GPT-3.5生成的功能性需求
▲ GPT-4生成的功能性需求
仅从功能性需求上看，双方的答复整体没有太大偏差，GPT-3.5的结果更加详细，GPT-4的结果相对比较“概括”，与我们问题中的“尽可能完善”有一定出入。
▲ GPT-3.5生成的非功能性需求
▲ GPT-4生成的非功能性需求
在非功能性需求上看，GPT-4的结果涉及的内容更加丰富，但缺点是内容与教务系统场景结合并不紧密，反而是GPT-3.5考虑到了实际的业务场景。例如关于高并发，GPT-3.5提到“能够在繁忙的选课期间保持稳定的性能”，而GPT-4只是笼统地说“系统应能在高并发场景下正常运行”。
03
需求细化
第二部分，我们模拟实际开发过程中收到初步需求描述，需要进一步细化进行开发和验收的场景。
我们给定一个较为具体的需求描述，要求根据该描述进行需求的条目化，同时还要求其识别出尽可能多的用户故事，并写出相应的验收标准。
3.1 基于简单需求描述进行细化
我们提前告知对后一段文字进行需求的识别和条目化，然后将项目的初步需求描述分别喂给GPT-3.5和GPT-4，获得以下结果：
▲ 项目初步需求描述
▲ GPT-3.5的需求分解
▲ GPT-4的需求分解
从结果观察，GPT-4生成的条目更多，对有些需求进行了更细粒度地拆分,对于相同需求的描述也显得更为简单。例如GPT-3.5回复的第二条座位签到功能，在GPT-4生成的结果中被细分为了4、5、6三条。
但是需要注意的是，GPT-3.5和GPT-4都存在需求遗漏的情况。例如GPT-3.5的结果中缺少关于“靠近插座的座位应该有特殊标记”的需求，GPT-4的的条目化结果中忽略了“预约必须以整点为单位”这个较为重要的约束。
3.2 基于需求识别用户故事
做完初步需求分析后，我们尝试让生成用户故事，进一步分解任务的细节：
▲ GPT-3.5生成的用户故事
▲ GPT-4生成的用户故事
从结果上看，GPT-4表现得要比GPT-3.5要丰富和细致，值得注意的是GPT-4在用户故事中使用了第一人称“我”而不是第三人称来进行讲述，或许正是基于这一点，它能够更加“体会”需求中的一些人性化成分，比如第11条的故事中讲述道：“我希望能够清楚地看到靠近插座的座位”，这十分贴合我们日常学习生活中的想法和感受。
此外，前一轮分析中的遗漏在这里的影响也进一步扩大，构建的系统中似乎彻底遗忘了原始需求中的一部分要求，如果缺少人为检验，这部分的缺失会引起较多后续问题。
3.3 基于需求制定验收标准
在需求上的最后一步尝试时让为我们生成对应需求的验收标准。
▲ GPT-3.5生成的验收标准
▲ GPT-4生成的验收标准
从验收标准来看，GPT-3.5是以模块为最小单位，而GPT-4的结果粒度更细，更易直接实施。
04
编码辅助
第三部分，我们模拟项目的迭代场景，在项目出现新的需求或挑战时，考察能否在现有的项目代码基础之上直接为我们生成可用代码及必要的辅助提示。
我们主要考虑以下三个问题：1.给定一段较长的功能性需求的文本，让其进行代码生成以满足需求。2.向其询问非功能性需求的具体实现方式。3.给定部分已经实现的功能性代码，要求其添加非功能性优化代码。
4.1 根据功能性需求生成代码
▲ 项目功能需求描述
我们给定了上方这段很长的功能性需求描述，要求直接为我们生成代码，尝试它是否具备跨文件设计系统的能力。
▲ GPT-3.5的答复
GPT-3.5在这个问题上打了太极，回避了直接生成代码，只用自然语言进行了一部分步骤描述，这自然不是我们所期待的，于是我们尝试针对某一需求进行更加细致的提问：
▲ GPT-3.5生成的代码
任务细化后，GPT-3.5就用户模块的内容生成了具体代码，并且按照文件和架构拆分为了、、dao三部分，符合框架的开发习惯，几乎是拿来即用的。
而在GPT-4上进行相同的尝试，我们发现GPT-4在面对最初的长篇需求时，就直接按照要求进行了代码的生成。
GPT-4不仅进行了完成了从需求分析、设计、实体抽取到代码框架的编写，而且以用户模块为例，展示了层和层的具体写法，相较于GPT-3.5，还考虑到了层的接口和实现，内容非常细致。以它呈现的大体框架为出发点，还可以针对相应的部分进行进一步的代码生成，逐渐形成系统级别的代码。
▲ 要求生成其他模块的代码
这里值得注意的是，在进行进一步提问以获取更加详细的功能代码时，需求描述应尽量清晰。例如即便第一轮提问已经涉及了全部功能，但要求实现具体功能代码时，列出需要实现的具体功能名称（例如提问”能否给出个人信息维护、学院/专业信息维护的具体实现代码“）比简单使用代词（例如提问”能否给出上述功能的具体实现代码“）的效果要更好。
现在我们已经得到了为教务管理系统生成的一个大体的代码框架，接下来我们将在IDEA中新建一个Maven项目，并把这些代码放入相应的java文件中观察代码是否存在错误，并且根据代码来让回答、解决相关的问题。
▲ 项目目录
首先观察中的代码，在此过程中，我误将其中的认为是一个自定义的实体类，故而在此我要求其生成一个实体类。但没有受到我的“误导”，而是纠正了我的错误，同时解释了该实体类该如何使用。
▲ 并没有受到“误导”
在按照它的建议导入完包之后，各个类本身便不存在问题了，现在需要将目光投向类。在之前的过程中只为我们生成了及，所以还需要生成Major与的接口及其实现类：
