引言

随着人工智能技术的迅猛发展，将AI能力整合到开发流程中已成为现代软件工程的重要趋势。在本文中，我将以一个实际项目为例，详细介绍如何构建一个AI代码审查工具，帮助你理解AI应用开发的基本流程和关键技术点。无论你是AI领域的新手，还是希望扩展技术视野的开发者，这篇文章都将为你提供有价值的入门指南。

AI应用开发的基础知识

在开始构建AI应用之前，我们需要了解几个基本概念：

大型语言模型(LLM) ：如OpenAI的GPT系列，是现代AI应用的核心引擎 API集成 ：通过API调用AI服务，无需自己训练复杂模型 应用架构 ：设计合理的架构以支持AI功能和业务需求 安全性考虑 ：保护API密钥、验证请求来源等安全措施

之前一直不理解为什么程序员圈子总是说 前端娱乐圈 ，前端圈子这么受鄙视么，虽然我也是前端。直到最近的一个事情，我才发现的确事出有因。

起因是在公司内部开发一个统一认证系统，不可避免涉及用户登录、授权、鉴权什么的，无意间看到一个npm包 connect-ensure-login ，能够判断当前请求是否登录。

当时就惊了，心想是什么黑科技居然能无视框架、认证系统，就能识别当前请求是否已经登录。本来想着挺神奇，结果看了源码才发现，就是调用下 passport 绑定到 Express Request 上的方法。。。😅就这也能出个包。。。

ChatGPT 刚出来时，各类的 GPT 客户端层出不穷，交互秒杀官方网页版，我本人也几乎不用官方页面。直到某一天，所有的第三方客户端都无法显示 GPT 的回复了，网上一查，说是 OpenAI 升级了页面，数据管道从原来的 EventSource 升级成了 WebSocket，这才造成几乎所有的第三方客户端全部阵亡的情况。 虽然大家很快跟进了修改，但是作为开发者，我们还是有必要了解下，为什么 OpenAI 要进行升级，WebSocket 有什么优势吗？

ChatGPT 的网页应用就是一个标准的聊天应用，信息交互比较频繁。但是，这个频繁只是相对的，首先我们与 ChatGPT 主要数据是文本，其次 ChatGPT 只会在我们发出消息后才会回复消息，不会主动向我们发送消息，所以官方一开始就选用了单向数据推送、传输数据为文本的 EventSource 作为消息管道。

但随着 OpenAI 的政策变化，网页版 ChatGPT 功能越来越强，现在已经支持文件上传，各种数据类型已经不是 EventSource 能承载得了了。可能你会想，文件上传就使用 HTTP 协议实现一个新的接口不就好了？增加一个功能就要增加接口，随着页面功能越来越多，ChatGPT 的 HTTP 连接会非常多，连接建立也是会消耗时间造成延迟，在聊天类应用上不合适；而且浏览器对于同一个网址的 HTTP 连接是有数量限制的，Chrome 的限制是 6 个，也就是同一个网址，只能同时存在 6 个 HTTP 连接，后续一律等待，直到前面的连接有断开。这对基于 HTTP 的 EventSource 简直就是灾难。基于数据类型、网络性能、浏览器限制等种种考虑，OpenAI 进行了升级，将 EventSource 替换成了 WebSocket。

虽然 ChatGPT 已经使用了 WebSocket 了，但是这不妨碍我们学习它的打字机效果的实现，下面将通过三种方式实现。

1. Stream 流式传输