关于 GPT 提升研发效率的一个思考

[winixt]

TLDR

可将需求文档喂给 GPT，让 GPT 给出代码的实现版本。然后用 AST 分析 GPT 生成的代码，转换成特定场景的编码（代码 or schema等等）。之所以还需要用 ast 做一次转换，主要原因有两点：1. GPT 是文本生成，本质上不具备逻辑能力，而软件是逻辑的一层层抽象，需要精确性。2. GPT 跟具体项目结合时，往往不具备对应项目的上下文信息，生成的代码不能很好的跟原项目契合。

思考过程

为了避免名词理解的不一致，这里先对文章内容易出现争议的名字下定义（仅限于本文章内）：

low-code: 可视化的拖拉拽生成页面/生成逻辑的平台。

有 GPT 还需要 low-code 吗？

要，low-code 能降低编码门槛，其一： GPT 输出代码的非逻辑性，实际并不能降低编码门槛，它输出的代码还是需要能看的懂，改的动。其二：GPT 输出的代码目前还不具备系统性，还只是一些代码片段。

GPT 如何跟 low-code 的结合？

low-code 平台的输入、输出都是确定性的，GPT 与 low-code 的结合点主要在于“输入”上，比如复制图片或者文本上去，解析转换（因为 GPT 没有 low-code 本身的上下文信息，因为需要通过 AST 或者其他手段，将 GPT 的输出做一层解析转换）成 low-code 需要的输入，用户再基于 low-code 做进一步的调整和修改，进一步提高 low-code 的编码效率。

GPT 让需求文档直出代码有了希望

目前开发流程中有一块常见的重复工作：需求文档对业务逻辑描述一遍，开发又用代码将需求文档逻辑再描述一遍（曾经有 coder 自嘲为“需求文档翻译机”）。计算机界曾经有很多大牛尝试解决这个问题，大体的思路是定义一种不具备二义性需求描述规则，包括一些 uml 图什么的，然后基于需求描述直接生成代码。最后都死于学习成本过高，产品不爱，开发不屑。这个问题的本质是，在 GPT 之前，计算机对自然语言的理解不够，没有低成本的办法在自然语言和代码之间建立桥梁。

使用 GPT 将需求文档直出代码，可能遇到的问题是，GPT 不具备生成目标项目的上下文信息，生成出来的代码不能很好的跟原项目契合，比如上下文中的一些组件和业务逻辑。将 GPT 输出的结果经过一层 AST 转转，补充具体项目的上下文信息，替换一些逻辑，能让输出的代码更可用，需要开发手动调整的代码量更少。