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

项目地址：github.com/ltyzzzxxx/g…

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

前言

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

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

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

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

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

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

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

基础功能

1. 支持 GPT 对话聊天功能

   • 这一点是最基本的，这是任何一个类 GPT 应用都具备的特点

2. 支持 GPT 输出内容呈现为 Markdown 格式

   • 市面上绝大多数 GPT 应用均支持这一点，毕竟很多时候都是程序员在用 GPT，所以免不了和代码打交道。为了用户体验，在我看来这一功能是必须实现的。

3. 支持 GPT 输出形式为流式输出，即实现 “打字机” 效果

   • 这一点在我看来也是必须的，因为从用户体验角度出发，流式输出能够让你感受到 GPT 似乎是在一边思考，一边回复，更加仿真。同时，它也解决了响应时间内，输出框白屏或加载的用户体验问题

4. 支持 GPT 记录上下文，即实现 “记忆” 功能

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

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

5. 支持 GPT 配置功能，支持用户配置 API Key、GPT 模型参数等

   • 这一点虽然是基础功能，但并非必备功能。因为一些类 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 Terminal 项目的更多细节并解锁更多玩法的话，请到其主页查看哦。

看在我这么认真的份上，大家点个Star、点个赞不过分吧（磕头！）下期再见！

服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net