关于chatgpt:我用低代码结合ChatGPT开发每天多出1小时摸鱼

腾小云导读

GPT 呈现之后，很多人揣测大量的软件都会因为其呈现而重写。本文次要是低代码平台与 ChatGPT 联合的一些思考以及实际。冀望与各位读者一起搭上 AI 这列慢车，为开发提提速～

目录

1 背景

2 Demo 演示

3 思路

3.1 ChatGPT+ 代码生成工具联合模式

3.2 ChatGPT 代码生成现状

3.3 现阶段可行的思路

3.4 案例

4 设计实现

4.1 架构分层

4.2 插件化

4.3 研发调整

5 总结

01、背景

从摸索模型驱动开发开始，我始终在思考一个问题：“软件，是否能够用更简略、更人性化的形式生成”，ChatGPT 给我了一个必定的答复。

咱们此前依据畛域模型在生成代码方面进行了一些摸索，心愿用建模工夫高倍率置换编码工夫。随着代码工具的不断完善，效率晋升越来越难，因为模型是形象的而实现是具体的，模型所承载的信息并不足以间接生成代码，肯定须要 “人” 来补充信息，这部分工作 工具无奈替“人”来实现。

直到体验了 ChatGPT，在震惊于它弱小的能力同时，咱们也就“如何将 ChatGPT 引入咱们的代码生成工具来晋升研发效力”进行了思考，并且疾速搭建了一些 Demo 验证成果。

02、Demo 演示

“Talk is cheap. Show me the code”，先看成果：

视频可移步到公众号观看

这里演示了工具基于畛域模型生成代码的流程，在第 3 到 5 步 工具集成了一个基于 ChatGPT 接口实现的插件，该插件主动提取模型中的中文类名、成员变量名、成员函数中文名，而后将中文名以及翻译用处、命名格调输出到 ChatGPT 失去翻译后果，并主动填充回工具，最初生成代码。

这里仅仅是简略地应用了 ChatGPT 的翻译能力，却给咱们带来了微小的晋升，设想一下一个我的项目数十个类名、数百个成员变量名以及函数名须要依据中文翻译为英文，有些词还要应用翻译软件翻译后再依据应用用处（类名应用名词或者名词短语、办法名应用动词）转换词性，而后调整为大驼峰或者下划线连贯等格调，这是如许无趣和繁琐的工作，而当初只须要一键填充，而后做渺小调整即可。

仅接入了 ChatGPT 的翻译能力就提效如此显著，那如果将 ChatGPT 的能力封装为一个一个插件嵌入到整个研发过程，那会达到什么成果呢？

03、思路

3.1 ChatGPT+ 代码生成工具联合模式

3.1.1 模式一：间接生成软件

这种模式让 ChatGPT 了解人类语言并编写软件，例如 ChatGPT 齐全能够生成一个可运行的贪吃蛇小游戏，当然严格意义上这种模式并不是 ChatGPT 和代码生成工具联合，因为基本不须要代码生成工具参加，这无疑是最简略、最天然的软件开发形式。

遗憾的是通过测试发现：ChatGPT 现阶段并不能间接通过对话编写出 残缺的、简单的软件， 因为软件有本人的 外围域常识， 而且不同的团队都有本人的标准、环境等要求，例如谷歌应用 gRPC 框架、部署在谷歌云，而亚马逊的研发框架和部署环境与谷歌齐全不同。咱们不可能将这些信息全副输出到 ChatGPT（这些信息太多了，通过会话形容这些信息须要大量的工作，除了思考性能以外也放心敏感信息泄露问题）。现阶段该模式无奈实现。我想，只管 AutoGPT 的呈现阐明 AI 的确能够从 0 到 1 实现一个我的项目，但我想没有人敢将它生成的我的项目间接利用于生产环境。

3.1.2 模式二：生成代码片段

通过会话将代码上下文信息输出到 ChatGPT，它基于这些信息欠缺、编辑代码，例如 Copilot 插件就是该模式。测试发现 ChatGPT 生成代码片段的品质比拟高且比较稳定。

该模式和模式一的区别是代码是“工具”将 ChatGPT 生成的“代码片段”进行组织，最终造成残缺的软件。

3.1.3 模式三：生成 DSL

将自然语言转换为 DSL，而后基于 DSL 生成代码或者软件，这种模式和计划二的区别是 ChatGPT 不间接生成代码，代码是由工具依据 ChatGPT 生成的 DSL 生成。ChatGPT 生成 DSL 绝对稳固，这种模式生成的代码品质绝对前两种模式更加牢靠。

3.2 ChatGPT 代码生成现状

“知彼知己，百战不殆”，咱们首先要对 ChatGPT 的能力有个清晰意识，这样能力抉择正确的模式。咱们浏览了一些 GPT-4 能力测评论文，也做了大量的试验验证，说几个有意思的点：

在理论场景中咱们写代码所依赖的信息十分多，除了以后文件的上下文还可能跨文件、跨零碎、跨仓库……然而因为 ChatGPT 对输出长度的限度，将所有依赖信息输出到 ChatGPT 是不事实的（工夫老本、敏感代码泄露）；另外一个问题是交互模式，如果代码是离线生成还好，但如果是“和 ChatGPT 结对编程”对实时性要求是十分高的，设想一下如果 Copilot 每次生成提醒都须要 1 分钟你还会用吗？

3.3 现阶段可行的思路

联合上述信息，咱们认为只管目前 GPT4 能力十分弱小，然而并不能做到全自动生成利用，尤其是针对某个行业须要匹配该行业的最佳实际和畛域常识，须要遵循团队研发标准。 这些是 ChatGPT 现阶段所无奈做到的。那基于 ChatGPT 现有的能力，如何嵌入到代码生成工具中呢？我作了一些浅显的思考：

读到这里兴许会有疑难，这显著就是 模式二和模式三的联合，为什么要分两次让 ChatGPT 生成代码呢？我上面用一个案例进行具体解释。

3.4 案例

3.4.1 信息提取

如上图所示，这是零碎用例“接管车位状态变动”的剖析序列图，通过剖析序列图咱们能够失去如下信息：

int 泊位:: 来车(){
  // 1、取值班人员
  排班(工夫). 取值班人员(值班人员序号);
  if(失败){
    打印日志
返回失败错误码
  }
  return 0}

3.4.2 构建 DSL 生成代码

显然上述信息并不足以生成代码，以“泊位:: 来车”这段伪代码为例，要想映射为一段合乎 C ++ 语法的代码，至多还须要欠缺上面这些信息：

做完这些工作后，咱们能力将上述伪代码应用结构化的语言形容以便生成代码，例如：

{
    "return_type":"int",
    "function_name":"ArriveCar",
    "param":[],
    "impl":[
        {
            "entity":"Scheduling",
            "function":"GetShiftPersonnel",
            "return_type":"int",
            "param":[
                {
                    "type":"int",
                    "name":"number"
                }
            ]
        }
    ]
}

事实上须要配置的信息远远不止这些，而且实现这些工作的常识都在“人脑”中，只能人来实现，  构建能够生成的代码的 DSL 并不简略。当然咱们能够通过一些办法来缩小人的工作：例如将填空题批改为选择题（大多数配置都是勾选操作而不必输出文字）、总结最佳实际增加默认选择项（例如成员变量默认不生成 Get 函数）等等，然而 始终有一部分工作是繁琐、反复、低效且须要人来实现的， 例如上述步骤中的中文依据应用情景不同翻译为不同词性、不同格局的英文单词。而这部分工作就须要引入 ChatGPT 来实现，由人来翻译 500 个中文词可能须要 50 分钟（10 个 / 分钟），而让 ChatGPT 来翻译仅须要几秒钟。

3.4.3 欠缺代码

通过第一步从模型提取信息、第二步将信息转换为生成代码所须要的 DSL，这时候咱们就能够生成代码了，上面是咱们生成的代码目录的一个案例：

咱们关上上述目录中的头文件、PROTO 文件不仅称心的点了拍板。但当咱们点开泊车类的 .cpp 文件见到上面内容不仅吐槽：生成的代码并不能间接运行！

// 来车
int ParkingSpace::ArriveCar() {//// MDD-TAG-BEGIN:[flow][slot-ArriveCar][函数实现]
  int ret = 0;
  // 取值班人员
  Scheduling scheduling (/* 请填充参数 */);
  ret = scheduling.GetShiftPersonnel(number);
  if (ret != 0) {LOG_VERR("--->> 谬误事件名 <<---", ret, "GetShiftPersonnel_ERR");
    return ret;
  }
  return ret;
  //// MDD-TAG-END:[flow][slot-ArriveCar]
}

是的，到这一步大部分的办法实现并没有生成。 在这里剖析一些起因，以上图中的伪代码为例，如果要生成代码须要人补充什么信息呢？

仅仅是这么几行伪代码就须要补充如此多的信息，如果这些信息都是由人来配置，那和间接写代码有什么区别呢？IDE 通过敌对的提醒，间接写代码甚至比在工具配置后生成代码效率更高！

所幸的是，无需人工配置，只有咱们将伪代码转换为业务代码所须要的头文件定义等输出到 ChatGPT，它就能够主动推导实现，生成代码。这就是为什么要“分两次让 ChatGPT 生成代码”。第一次是生成 DSL 以便代码生成工具生成品质有保障的代码框架、头文件定义等，第二次是依据曾经生成的代码持续欠缺业务代码。

思路曾经很明确，要想落实为具体计划，那就须要代码生成工具有一个好的设计，这里的好是指“模块化、低耦合、可扩大”，上面介绍代码生成工具的设计实现。

04、设计实现

4.1 架构分层

（图源网络）

上图中标红的局部“模型和引擎独特决定了利用的实现水平和扩展性”。本文不是讲领域建模的内容，因而建模常识这里不做探讨，咱们重点探讨引擎的设计。补充一下零碎的架构分层如下：

协定栈: 定义代码生成引擎输出的格式化构造，能够的话这个构造能够作为标准规范供各种低代码平台通用应用，当然如果可能做到这点就能 解决掉低无代码平台的互联互通问题（难而正确的事），是对整个行业无利的事件。

代码生成引擎： 对协定栈的实现，定义了代码生成的模版，将输出的数据进行解决后依据需要填入到不同的模板中，生成 C++、TS 等代码。

引擎插件： 基于引擎进行拓展，例如使引擎更灵便，反对更多的协定。咱们和 ChatGPT 联合实际上就是对 ChatGPT 的能力进行封装，实现为一个个的插件辅助人来实现工作，进步代码生成工具的易用性。

代码生成工具: 对引擎以及插件的封装，是面向用户的产品。

4.2 插件化

明确了架构的分层，咱们和 ChatGPT 集成的计划也就自然而然地明确了：将模型映射代码的过程拆解为一个一个的工作，剖析哪些工作现阶段是由人实现的且 ChatGPT 曾经具备相应的能力，则基于 ChatGPT 的能力分装为一个一个的插件，帮助人实现相应的工作，晋升效力。 上面咱们解说对几个插件的思考。

4.2.1 代码生成插件

让 ChatGPT 来生成代码，Prompt 须要蕴含如下三局部信息：有什么、用什么、做什么。

有什么： 上文曾经解释了咱们是让 ChatGPT 生成品质绝对稳固的代码片段，即某一个函数的实现。“有什么”实际上就是函数的入参、类的成员变量以及全局变量。入参和类的成员变量能够通过解析畛域模型失去，而全局变量则定义在代码生成的模版中，是一些固定的值（个别是全局配置）。

用什么： 即实现该办法须要哪些实体类办法、边界类办法、根底库。实体类办法在 3.4.2 展现了，DSL 生成代码后曾经有了实体类办法的头文件；边界类办法即对外零碎接口的封装，须要进行对立治理，因而也能够很不便地失去。

根底库分为官网库和第三方库，官网库无需输出，ChatGPT 能够推导出应用正确的办法，而第三方库因为太多咱们暂不解决，咱们的目标原本也不是生成 100% 的代码，无奈生成的这部分就交给研发去补充吧（别忘了研发还有 Copilot 等利器）。

做什么： 须要欠缺的代码逻辑，就是伪代码，在 3.4.3 有做展现，这里不再赘述。

插件将上述信息拼接为 Prompt，剩下的就交给 ChatGPT 吧，例如上述泊位:: 来车办法最终由 ChatGPT 欠缺为:

// 来车
int ParkingSpace::ArriveCar() {//// MDD-TAG-BEGIN:[flow][slot-ArriveCar][函数实现]
  int ret = 0;
  // 取值班人员
  Scheduling scheduling (time(nullptr));
  ret = scheduling.GetAttendant(number_);
  if (ret != 0) {LOG_VERR("GetAttendant", ret, number_);
    return ret;
  }
  return ret;
  //// MDD-TAG-END:[flow][slot-ArriveCar]
}

4.2.2 翻译插件

正如第二章所演示的成果，这个插件咱们曾经实现实现了。目前大多数建模工具反对填写英文名称，然而英文名称为非必填字段且大多数人不习惯应用英文建模，咱们提取模型中未关联英文单词的中文，拼接为 Prompt 调用 ChatGPT 对立翻译，一键填充。

当然咱们所须要的插件不仅仅这两个，咱们也脑爆了单测生成插件、SQL 生成插件等等一系列的提效插件。

4.3 研发调整

咱们评估如果依照这样的思路，实现代码生成工具能够节俭 90% 以上的工作量，大概剩下的 10% 是如下工作：

代码走查： 下面曾经说了 ChatGPT 生成的代码只是绝对稳固，因而生成的代码默认应用 /* 和 */ 包裹正文掉，必须通过研发确认代码正确且调整结束后才能够删除正文投入使用。

代码欠缺： ChatGPT 无奈生成 100% 的代码，例如上一个接口产生了一个两头后果缓存起来，该接口会应用，思考到 ChatGPT 的性能、插件实现的复杂性、OPENAI 接口免费价格等因素，咱们不可能把上一个接口的信息拼接到 Prompt。这部分逻辑研发间接编写代码所付出的老本远远低于应用 ChatGPT 所需老本。

单元测试： ChatGPT 写单元测试的品质远远超出我的设想，它会思考边界条件等等各种因素，如果是针对根底库生成的测试用例代码简直不须要批改就能够间接应用，然而如果是管制类等业务代码的测试用例却不能应用，例如上述接口中的 JScode 是小程序产生，毫无疑问 ChatGPT 无奈结构出这样的参数，是 Mock 还是调用可测试性接口获取还须要研发依据理论状况做出调整。

无论如何，因为业务自身的复杂性，咱们不可能寄希望于应用一个工具生成所有代码，肯定有一部分代码是工具所无奈实现的，仍然须要人来参加。

然而这部分工作能够通过 Copilot、IDE 插件等工具来辅助提效。

05、总结

各位仍需注意，如果 间接应用 ChatGPT 有敏感信息泄露危险，各团队能够依据须要独立部署 AI 模型。对于集体开发者能够应用一些开源模型，例如 Vicuna、LLaMA 等。

迄今为止 AI 工具的呈现次要还是为了便当人类，而不是代替人类。加以学习利用，这些工具兴许能为帮忙开发提速。欢送开发者们在评论区交换。

-End-

原创作者|邬豪杰

技术责编|张晋铭

各位开发者有没有用过 GPT 辅助工作呢？GPT 能与哪些技术联合碰撞火花？还能有哪些利用场景？欢送在腾讯云公众号评论区中留言。咱们将选取 1 则最有创意的评论，送出腾讯云开发者 - 靠枕 1 个（见下图）。6 月 5 日中午 12 点开奖。