关于node.js:一个合格的-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、点个赞不过分吧（磕头！）下期再见！