我在大模型下的编码方式

128 阅读5分钟

如今,新一代的人工智能已经非常流行,自2022年11 OpenAI 发布 ChatGPT3.5 以来,标志着人工智能新的范式已经开始,也就是 GPT(Generative Pre-trained Transformer),也就是生成式人工智能。

自从 ChatGPT3.5 发布以来,我便开始使用,工作中已经很难离开它了,但是,对我的工作影响最大的当属 ChatGPT 前一段时间推出的自定义 GPT,为什么呢?

我们先看看作为程序员,它是怎么影响我的工作的,直接看过程(默认大家对ChatGPT有一定的了解,不知道可以网上搜索,太多太多的文章介绍,还有他们的官网等等):

完全可借鉴的实战

  1. 进入 ChatGPT,创建一个自定义 Spring Boot GPT
  2. 指令里,进行了详细的约束,比如:技术栈使用 Spring Boot、Hibernate、Spring Security、JUnit 等,遵循 Google Java Style Guide 编码规范等等,这里可以写很多很多。
  3. 如果有必要,给这个自定义的 GPT 上传私有文件,让它了解更多信息。
  4. 经过不断的调试,直到生成符合要求的代码,这个规范的 GPT 便可给自己和团队使用了。
  5. 与这个 GPT 深入的沟通模型定义,聚焦关键实体及关键字段。
  6. 不断的询问改进后的模型的优缺点,直到输出一个能够支撑核心业务且可高度扩展的模型。
  7. 再次生成符合 Hibernate ORM 最佳实践的模型。
  8. 开始与它讨论 Controller、Service、Component等,应用一些最佳原则,比如单一指责、高内聚低耦合等等。
  9. 反复锤炼根据这些模型和业务,讨论应该生成哪些 Controller 以及每个应该具备的核心方法。
  10. 不断询问它这么做的优缺点,直到你认为合理为止。
  11. 在这个过程中,可以试着让它生成一个业务中复杂的逻辑,观察具体效果。
  12. 和它不断的交流依次生成Controller、Service等。
  13. 讨论系统瓶颈,考虑到分布式系统、多实例等,引入 Redis 和 RabbitMQ 解决缓存、统一状态管理、提高吞吐量等。
  14. 考虑到业务的清晰和可扩展,让它统一状态码、统一异常处理、DTO、ViewModel,对Controller、Service进一步改造。
  15. 给Controller、Service等生成单元测试。
  16. 自测系统,与GPT一起修改 bug、改进系统17、配置 Swagger,生成 API 文档,给另一个 GPT 使用。
  17. ......
  18. 压缩整个项目,给 GPT 让它做优缺点分析,继续改进系统...

显然这不是研发一个 demo 的步骤,这是实践的结果,由于上下文长度的限制,由于 GPT4 还没有强大到什么都会,有些问题需要反复沟通才能解决,需要帮他修正上下文中的错误点。有句话描述 GPT「你觉得难的问题,它也觉得难」,打铁还需自身硬。

刚才生成的 API 文档有什么用呢?后端基本完成,现在还需要开发前端。

  1. 再次打开 ChatGPT,创建一个自定义 Vue GPT
  2. 在指令里,进行了详细的约束,比如:技术栈使用 Vue3、Vue Router、Pinia、Element Plus等,使用 TypeScript、使用单文件组件和组合式 API、遵循 Element 设计原则,数据请求严格遵循 API 文档等等。
  3. 上传 API 文档,以及其它数据,让它了解更多信息。
  4. 调试,生成符合要求的功能完备的组件 -- 经过反复调试,基本可以生成直接使用的组件。

由于GPT的局限性,也是在特定领域没有很好的交互支撑,需要一个个生成组件,然后自己组合代码。

  1. 与 Vue GPT 讨论组件功能,生成功能交互完备的组件。
  2. 交互上,比如按钮提交,实现 UI 状态管理:禁用交互、视觉反馈、状态恢复等。它做的非常好。
  3. 与之交流、生成符合 API 文档的请求响应拦截器,进行错误统一处理及提示。
  4. 生成单元测试。
  5. 运行代码及单元测试,一起排查问题,修复问题。
  6. ......
  7. 压缩整个项目,给 GPT 做优缺点分析,继续改进系统...

前端涉及到与用户的交互比较多,页面也多以组件形式组织,目前很难让 GPT 直接生成完整复杂的页面,紧凑的组件目前完全没有压力,太复杂也不行,太复杂生成的就类似于 demo,但是代码结构依然有用。

实战后的思考

整个过程下来,可以联想到之前的低代码平台,但是在新的范式下,这是完全不一样的逻辑。如果结合GPT开发一款软件研发工具,可以适用很多的场景和需求,面对不同的场景只是增益效果不同而已。就像现在的GitHub Copilot Chat,基本上对使用者都有帮助,然而他还需要多多改进,如果支持自定义 Copilot 就好了。

上面的开发步骤,生成的代码质量非常高,然而它与开发工具是完全割裂的,ChatGPT 会改进这一点儿吗,我想,应该不会。如果设想,它怎么才能做到?ChatGPT 可以支持一种新的插件模式,对话框右侧显示插件,通过规范好的类似 JSON-RPC、DAP、IPC 等协议机制与对话框通信。对话过程中,可以随时读写目录、读写文件、调试代码获得结果反馈等等... 也许有更加完善的方案有人在默默耕耘。