跳至主要內容

一个合格的 ChatGPT 应用需要具备什么?一文带你打通 GPT 产品功能!

ltyzzz约 2295 字大约 8 分钟

专栏目录

耗时一下午,我实现了 GPT Terminal,真正拥有了专属于我的 GPT 终端!open in new window

如何用 GPT 在 5 分钟内 ”调教“ 出一个专属于你的 ”小黑子“?open in new window

如何丝滑实现 GPT 打字机流式回复?Server-Sent Events!open in new window

我是如何让我的 GPT Terminal “长记性” 的?还是老配方!open in new window

一个合格的类 GPT 应用需要具备什么?一文带你打通 GPT 产品功能!open in new window

开发一个 ChatGPT 真的只是当 "接口侠" 吗?GPT Terminal 细节分享!open in new window

如何借助于 OpenAI 以命令的方式在 GPT 终端上画一只 “坤”?open in new window

不满足当 ChatGPT “接口侠”?轻松可视化 Fine-tuning 训练你的模型!open in new window

耗时一下午,我终于上线了我的 GPT 终端!(内含详细部署方案记录)open in new window 项目地址:github.com/ltyzzzxxx/g…open in new window

欢迎大家Star、提出PR,一起快乐地用 GPT Terminal 玩耍吧~

前言

不知不觉中,GPT Terminal 专栏已经更新了 4 节内容啦~

这 4 节内容已经基本涵盖了一个 GPT 应用需要具备的基本功能。

然而,由于市面上类 GPT 应用实在是层出不穷,五花八门,这些应用潜移默化地提高了大家的 "阈值",甚至让大家对此类应用有些审美疲劳,也有很多人认为此类应用只是简单地调用 Open AI 接口,没什么含金量。事实确实如此,但这仅只是从应用的角度来看,没有必要重复性地制作,进行无意义的 "内卷"。

倘若我们换个角度,从做一个优秀的产品,又或是学习一些有用的技术角度出发,我们或许又会有所收获。这也是今天写这篇文章的目的,我想尽可能凝练地提取出我在做 GPT Terminal 的过程中思考到的一些功能,其中涉及到的不仅仅是调用 Open AI 接口,还有一些有意思的东西,仅供大家参考~

合格的类 GPT 应用需要具备什么?

在开始分享之前,我想先问大家一个问题,如果让你来做一款类 GPT 应用,你需要考虑哪些方面,从而使得你的 GPT 不逊色于市面上其它产品?

如下是我经过思考与调研后,总结而成的思维导图。

whiteboard_exported_image (2).png
whiteboard_exported_image (2).png

基础功能

  1. 支持 GPT 对话聊天功能

    • 这一点是最基本的,这是任何一个类 GPT 应用都具备的特点
  2. 支持 GPT 输出内容呈现为 Markdown 格式

    • 市面上绝大多数 GPT 应用均支持这一点,毕竟很多时候都是程序员在用 GPT,所以免不了和代码打交道。为了用户体验,在我看来这一功能是必须实现的。
  3. 支持 GPT 输出形式为流式输出,即实现 “打字机” 效果

    • 这一点在我看来也是必须的,因为从用户体验角度出发,流式输出能够让你感受到 GPT 似乎是在一边思考,一边回复,更加仿真。同时,它也解决了响应时间内,输出框白屏或加载的用户体验问题
  4. 支持 GPT 记录上下文,即实现 “记忆” 功能

    • 这在大多数场景下是必须的,除非每条对话都是独立的。我们会通过询问 GPT 多个问题,而且这些问题之间相互关联,从而得到最终的答案。这其实也是 Prompt Engineering 中的一种技巧。

    也有例外情况,比如在 GPT Terminal 中实现的命令行翻译、中英互译角色,多数情况下我不需要它们记忆 "上下文" 。

  5. 支持 GPT 配置功能,支持用户配置 API KeyGPT 模型参数等

    • 这一点虽然是基础功能,但并非必备功能。因为一些类 GPT 应用是商业化的,用户通过付费换取 GPT 服务。这就看开发者如何选择啦,个人认为在设计之初就应确定好这款产品的定位与走向。

用户体验支撑功能

  1. GPT 响应状态下,禁止用户输入

    • 为什么我考虑到这一点?是因为我在实现 GPT “记忆” 功能时,需要将之前的问题与回复作为新一轮提问中 GPT 的输入参数。为了确保 GPT 输出的正确性与质量,我需要确保输入参数的有序性。假设我在输出还未返回的情况下强行输入,会导致 GPT 无法感知或记忆这一轮的对话。

    这一点还是挺有意思的,试想一下我们在日常生活中与其他人聊天时,可能经常存在打断对方的情况,对方也能感知到,并不会丢失上下文。希望之后 GPT 能够实现这一点吧 🤣

  2. Loading 状态提示

    • 在用户发送消息 到 GPT 开始响应这段时间,是存在请求发送与请求处理过程的,那么其中必然存在网络延时。为了避免出现白屏问题,我们可以添加简单的 Loading 提示状态,告知用户目前处于加载状态中。这也是绝大多数网站、App、小程序的惯用技巧。
  3. 网络超时提示

    • 有时会出现无法访问 OpenAI 的情况,即使用户正确配置好了 API Key,也总是无法得到 GPT 输出的内容。这时候,我们需要设置一下请求的超时时间,并且在超时后告知用户已超时,请用户确认网络是否配置正确等等内容。

拓展功能

为了做得更有意思一些,我在 GPT Terminal 中做了一些拓展。这里先简单分享给大家。更详细的解决方案,我会在第二天的文章中具体讲解!

  1. 自定义 GPT 角色功能

    • 这一点其实原理很简单,通过预先设置好上下文,作为参数 message 数组中的部分元素请求接口即可。在下一篇文章中,我会详细介绍 DIY 角色的整体解决方案(数据库设计、接口实现等)。
  2. 历史对话记录查询

    • 在普通的 GPT 应用中,聊天内容是直接展示在用户眼前的。而在终端上,由于内容过多,用户可能执行清屏操作,需要以命令的方式获取过去的聊天记录。
  3. 分角色存储对话记录

    • 为了防止多个角色共用同一上下文,造成角色定义混乱,我将对话记录进行分角色存储。

除此之外,后续我可能会引入 MidJourney 图片生成、基于 Fine-tuning 训练模型等更多玩法,这些也是属于进阶的拓展功能啦,都可以在一个类 GPT 应用中得以实现~

总结

说到这里,大家可以看到想要实现一个类 GPT 产品,需要考虑的地方并不少。我们在做的过程中,还是能够学到不少有用的技术。并且通过这一项目,我们在日后开发自己个人产品的过程中,也会更加容易考虑到很多与用户体验相关的产品细节。

在做的过程中,我也深刻体会到打磨细节的不易。虽然调用 OpenAI 接口很简单,但是想要把它做成一个真正可以交付给用户使用的 GPT 产品,实属不易。

想成为一个优秀的程序员,除了需要有过硬的开发编程能力,也需要具备一定的产品思维,这不仅能够使我们更好地理解需求,同时我们会有更加长远的设计思考。这也会反过来促进开发工作。目前,我也正朝着这一方向努力中~

后记

本来今天想要把第二篇也一起更新完的,但是想了想两篇加在一起篇幅过长,而且第二篇涉及到项目实战内容,容易看困,所以今天就先分享一些简单的内容吧,希望大家看了之后能够更加了解 GPT 应用的功能点~

这篇文章就先到这里啦~但是精彩内容还未结束,如果大家想要了解更多关于 用户体验支撑功能拓展功能 的实战解决方案,请持续关注本专栏,预期会在第二天就更新哒~

如果大家想要了解 GPT Terminalopen in new window 项目的更多细节并解锁更多玩法的话,请到其主页查看哦。

看在我这么认真的份上,大家点个Star、点个赞不过分吧(磕头!)下期再见!