引言：它来了

当我们对《流浪地球 2》中人工智能 MOSS 产生无尽的科幻联想之际，GPT 已经通过大规模数据预训练，拥有了理解、生成文本的能力，并在多个行业引发了巨大冲击，从客户服务到市场营销，从医疗健康到教育，都带来了颠覆性的变革，AI 元年悄然而至。

在软件研发领域，它能够帮助我们提高开发效率、改善代码质量、代码自动生成吗？本文依托于一个老项目数据库重构的背景，和大家一起探讨下 GPT 在研发重构过程中的应用实践。

重构：困难重重

已服役十余年的项目，应客户要求去除商业数据库中间件，使用 postgreSQL 替换 Oracle，经过十余年的业务加载和迭代，启动重构存在很大的考验与风险：

数据库方面：数据库中存在大量的存储过程、函数、动态 SQL 需要进行语法差异转换，并且调用链情况较为复杂，在存过、函数、动态 SQL 之间存在着互相调用的情况，耦合度比较高。

代码方面：祖传架构方面，老式集群模式的项目下代码工程多，工程中的技术框架经过很多轮的迭代，包含 JDBC、MyBatis、FreeMarker、EJB、工厂模式等。业务实现方面，有大量的存过、函数调用，并且 SQL 的组装无处不在，有字符串拼接、StringBuffer、StringBuilder、mapper.xml、自定义 XML 等方式。

综合来看，这是一项具有挑战性的任务，技术上没有瓶颈，但实施上困难重重：

• 代码走查需仔细，否则范围难控制；

• 对于人员经验要求高，需要熟悉框架，能够识别、发现、解决问题；

• 大量的 SQL 和代码改造，具备高度经验化、高重复化的特征；

• 项目多人员参与，经验参差不齐，如何保障重构质量。

GPT：研发团队小助手

为了提升效率，引入了 chatGPT 作为研发小助手，并按使用场景给它分了三个角色，看看它具体可以帮我们做什么：

下面让我们通过重构中 java 代码处理的一个典型场景示例，带大家一起感受一下它的魅力：

第一步：准备好需要处理的 java 代码段，和指令。

第二步：问答交互式协助，就如同使用钉钉、微信聊天一样，输入上面的代码段+指令，让它帮我们处理。

最后：AI 的响应结果符合预期，并且给出了详细的汇总分析。由此可见，只要指令够准确，它就可以快速完成代码段的分析、改造和总结，效率很高，整体耗时不会超过 10 秒钟。

盘它：工欲善其事必先利其器

使用过程中发现 chatGPT 在高度经验化、重复化的任务处理中表现不俗，研发一个以它为底座的重构工具势在必行。细心的你，会发现上面的截图并不是来自需要科学上网的 chatGPT，而是源自我们做的接入 GPT API 的重构小工具。

自动走查，解决走查困难问题

用内置扫描器来替代人工走查，当前工具预置扫描器已支持 java 代码、DDL、xml 扫描，精确的按任务文件维度，处理一个超大文件，在保证上下文完整的情形下，拆解成符合 AI token 要求的较小任务单元（代码段）。

对扫描拆解的代码段，按照预置场景下的命中策略，判断是否需要送 AI 处理，打标识生成真正的待办任务。

这样不再依赖于人工走查和人员经验，既节约了时间，又减少了疏漏，同时一定程度上提升任务转化效率及准确率。

可视化项目管理

传统的数据库重构项目研发管理，代码走查完成后，由研发经理分配到人，现在不需要了。工具提供项目维度的管理，将 AI 交互使用场景分类，进行场景化管理，场景扫描生成任务后，自动均匀分配给项目研发人员。

例如，Oracle2PostgreSQL 的重构项目，包含的两种场景：

DDL 转换场景：将 Oracle 数据库中的表、存储过程、函数、视图等 DDL 导出到文件中，文本扫描器扫描生成 DDL 转换任务，分配给研发人员进行审核后，就可以直接交给 AI 处理；

代码工程转换场景：上传或 git 拉取代码工程并托管，javaparser、文本扫描器会对代码工程做自动走查扫描，将需要处理的 java 类、mapper.xml 文件等，作为任务，分配给研发人员，待审核后，直接交由 AI 处理。

提供任务可视化及闭环管理，项目管理者在监控界面上对场景任务的分配情况一目了然。

一键 AI 处理

数据库替换重构项目中，需要研发经理做好技术背调，并输出任务清单，然后对研发团队进行赋能和分配任务，接下来研发人员按包路径维度，结合背调知识库，逐个修改。这样做的缺点是容易代入个人编码习惯，无法标准化，可能会带来不必要的 BUG，对业务产生影响。

工具自动化后，研发人员只需要关注分配的任务，按照任务清单对代码段审核，就可以一键送 AI 处理，AI 会响应输出结果代码段或 SQL，然后针对预处理后的 AI 返回结果，进行人工校准，就可以一键复写生成 java 类和 SQL。

人机交互模式，将高度经验化、重复化的部分研发工作，交由 AI 处理，研发人员做好审核和校验，充分利用了 AI 编码能力，节约了工作量，同时提升了准确率和代码质量。

干货：一点心得

模型选择：text-davinci-003 模型 or gpt-3.5-turbo 模型

01 模型和使用场景分析

text-davinci-003 是基于 GPT-3 的模型，适用于广泛的自然语言处理任务，包括对话生成、问题回答、文本摘要和翻译等。它功能强大但相对较慢，适合复杂和深入的文本处理，不要求实时性。

gpt-3.5-turbo 是基于 GPT-3.5 的模型，具有高性能、低延迟的特点。它适用于快速生成文本的场景，如在线聊天机器人、客户支持自动化和内容创作辅助。在对话和短文本方面表现出色，响应速度快。

02 token 和频次限制

两种模型对于每分钟调用频次、交互 token 均有限制。开始我们倾向于选择 token 大和调用频次高的达芬奇模型，但试验后发现，在转换速率和准确率上 gpt-3.5-turbo 要远优于达芬奇，可是基于 chatgpt 更高的时效和性能要求，OpenAI 对它做了更多的限流控制。

综上，gpt-3.5-turbo 模型更加适合用于高效率、高质量的生成型任务，在算力性能和实时性方面优势很大，选择接入它没错。

turbo 模型速率限制解决方案

turbo 的限流控制很让人头疼，于是工具研发中引入了令牌桶算法，支持接入多个 apikey，完美解决了限流问题。

令牌桶算法（Token Bucket Algorithm）是一种流量控制算法，用于控制资源访问速率。它是一种经典的算法，常用于网络传输、API 限流、请求调度的场景。

token 限制解决方案

提炼出 java、xml、DDL 文件不同的特征，通过预置的 Java 类扫描器和文本类扫描器，保障上下文完整性，以及符合交互的 token 限制。

场景命中策略

openai 是收费的，内测中免费账户流量很快就耗费殆尽。如何筛选命中有效内容，把实际需要处理的内容交给它很关键。

基于这些考虑，抽象出了场景的概念，在场景下预置不同的正则表达式策略，并提取符合策略规则的内容/代码段，提交给 AI 处理。

AI 交互指令校准

让我们再接着思考：在特定使用场景下如何设置合理角色和 prompt？又怎么固定返回我们想要的结果？

• 模型选择、加载：需要分析场景任务选择合适的模型，将模型加载到计算环境中，以便进行后续的校准和交互；

• 样本数据准备：为了进行指令的校准，我们将需要问询的数据整理成样本数据；

• 指令示例：样本数据和特定的场景指令集，组合形成待校准指令集；

• 筛选指令：根据不同指令的响应，选择符合预期的指令作为场景的 prompt。

人机交互的设计

初版设计思路为：扫描->AI 处理->回写，验证后发现存在着准确性、及时率的一些问题，于是我们考虑使用半自动-人机交互模式来解决这些问题，流程优化为：扫描->任务审核->AI 处理->任务校准->回写，并且提供差异比对和异常重送的功能，以提升交互准确率。

总结：说点想说的

随着 AI 的不断发展和应用，其强大的自然语言预处理机制和大数据的魅力，在各个领域展现出巨大的潜力。在代码解释分析、代码生成、知识库检索等方面也拥有无限可能，未来，我们可以期待它作为研发的好帮手，发挥更重要的作用。