流式接入 -- 怎么突破输入的限制（ChatGPT 实现原理）？
上文中我们有提到，除了输出有 2048 token 的限制外，不仅如此输入也是有的，我们的输入不能超过 4096 token，否则就会被 openAI 拒绝。事实上，在真实的业务场景，如果涉及代码，这个限制是很容易被超过的，那么这个问题我们可以怎么解呢？
我们可以采用相同的思路，建立流，并通过 webSocket 保持一个持久化连接，我们知道 gpt 的问题在长连接的状态下是可以保有上下文的，通过拆解我们的问题，将一个大问题分解为多个小字符串输入给 gpt，从而达到突破输入限制的目的，我们来看下面这段示例代码。
const WebSocket = require('ws'); const ws = new WebSocket('wss://api.openai.com/v1/chat/completions'); let buffer = ''; ws.onopen = function() { ws.send(JSON.stringify({ "model": "gpt-3.5-turbo", "messages": "test", "temperature":0.5, "max_tokens":1024, "n":1, "stream":true })); }; ws.onmessage = function(event) { if (typeof event.data === 'string') { buffer += event.data; let lines = buffer.split('\n'); if (lines.length > 1) { console.log(lines[0]); buffer = lines[lines.length - 1]; } } }; ws.onerror = function(event) { console.error(event); }; process.stdin.on('data', (data) => { let message = data.toString().trim(); ws.send(message); console.log('You: ' + message); }); function terminate() { console.log('WebSocket disconnected.'); process.exit(); } ws.onclose = function(event) { console.error(`WebSocket closed with code: ${event.code}`); terminate(); }; process.on('SIGINT', function() { console.log('\nClosing WebSocket...'); ws.close(); }); process.on('unhandledRejection', function(reason, p) { console.error(`Unhandled Rejection at: ${p}. Reason: ${reason}`); terminate(); }); 复制代码
在上面的示例中，我们用 websocket 建立了一个持久化连接，需要注意的是，参数中我们为它开启 stream: true，这个参数将响应数据流式返回，这样可以在使用 WebSocket 或其他无状态通信协议时，实时处理生成的响应文本，这样就可以在需要长时间持续对话时节省请求时间和开销，并使对话过程更加自然连贯。
看完这部分相信大家会有一个额外的收获， web chatgpt 是怎么实现的？是的，也是采用这种方式，用 websocket 建立持久化连接，持续输入获得答案。
GPT应用篇
抛砖引玉 -- 基于 GPT 模型的自动化测试 vscode 插件（GPT Unit Test)
在完成上面的学习后，相信大家对 GPT 模型和它的接入都有了初步的认知，可能已经对做一个自己的应用跃跃欲试了，在这里想提醒一下大家：
因为 GPT 模型本质上是一个训练集模型，这意味着你问它的所有问题，都会上传到外部，注意隐私和数据安全是很重要的事情，一些内部或者公司内的代码或者敏感信息不要拿来问 GPT 哦～
我们言归正传，在应用篇我会以我最近写的一个 demo -- "基于 GPT 模型的自动化测试 vscode 插件（GPT Unit Test)" 为大家讲解应该如何应用 GPT 模型到你感兴趣的方向中，希望对大家有一定启发。
这个插件已经发布到了 vscode extensions，大家可以直接安装使用
插件的使用很简单，在安装完成插件后，文件夹和文件的右键目录中会多出一个选项 generate unit test，点击后如果没填写有效 openApi key 会要求填写，鉴权完成后即可自动为需要的文件目录或是文件生成单元测试，当然也支持 ignore 文件和测试库等配置，具体的大家可以阅读 readme，其中有更详细的解答。
因为是个 demo,所以可能仍然有bug，但是主流程上经过测试是没有问题的，如果你出现不能使用的情况，可能是以下情况：
- 中国区ip被锁，需要替换虚拟 ip, 因为底层它用的还是 openAI 的能力
- vscode 的 engines 版本低于 1.77.0，这个需要升级 vscode 版本
- 输入的 token 限制，测试文件过大，这个 demo 版还没支持，目前测试下来 300 行上下的文件测试质量还是很在线的
- 其他的一些问题，这个你可以在评论区或是按照 readme 中贡献 & issue 的方式联系我，我会尽快答复你
当然这个插件也许不一定会继续迭代，这只是我技术建设抽离出来的一个 demo 版本，在隐私性没办法做得更好，所以只适合 C 端项目（GPT 是公开的），后续的迭代可能都会以我内部对应的技术建设项目为主（大家用不了0x0），所以这也是我不开放贡献的核心原因。
如果是插件主流程阻塞的问题我也许还是会修的，目前看来没有，主要还是会根据我的个人时间来决定（几乎没什么个人时间）。
虽然但是～我想这个插件作为一个 AI 应用方向，用来抛砖引玉我相信会是很好的借鉴，也期待得到更多大家的反馈。下面我们就来具体谈谈这个插件是如何设计的。
场景还原 -- GPT Unit Test 是如何设计 & 与 GPT 模型结合的？
我们先来看看这个插件的流程图
其实可以看到整个流程是并不复杂的，除了 openAI 的流式接入外，主要的逻辑都只是一些 i/o 操作，而且这边我们并没有与 GPT 建立持久化连接。
因为在这个 case 中，单元测试有一个重要的特点，就是单一原则上体现比较强，在对于一个组件的测试中，我会拆分为 n 个文件，每个文件独立测试，依赖的部分 gpt 则采用 mock 的方式完成，即 A 引用 B, 那么 A 的单测中只保证 B 和 使用 B 调用的内容存在，而 B 的功能则在 B 的用例中跑。
经过上面的拆分，一个组件的测试我们将不再需要关注整体，GPT Unit Test 的最小粒度就被拆分为了文件，而不是组件或是其他代码集合。接下来只需要按照常规的遍历文件系统，逐步以流的方式写入就行，具体接入的代码在 GPT 接入篇有讲解，还不清楚的同学可以回过头看看。
方向调研 -- 如何判断 GPT 模型在某个方向的可行性？
回顾上面的过程，我们可以发现 AI 的应用技术门槛并不高，相反更高的反而是方案的设计以及你如何去应用，就像是一个“万能”（偶尔会胡说八道）的接口，只要可以找到对应方向的使用规律，就很容易拿到预期的结果，并做一些事情。
这里帮大家提取了这个过程真正需要关注的、消耗时间的三点：
- 可靠性验证：保证 AI 帮你完成的事情是可靠的，这个过程需要经过大量 case 对比，将 AI 完成的用例和我写的进行对比，看看谁优谁劣，这里怎么对比的我就不赘述了，单元测试的部分不是这篇指南关注的重点。当然最后我得出了结论，AI 写的用例覆盖率、mock 和单一原则都很在线，不亚于我写的。
- 通用性问题的总结：你使用 AI 不仅是解决单个问题，那么在每次解决之后，这些问法之间是否有共通的地方，能否总结出在一定微调后就可以使用的通用性问题，这个过程需要经过反复测试，并补充边缘情况的限制。比如 GPT Unit Test 使用的通用性问法就是这个
使用 jest 和 xxx （插件暴露出来给用户配置，暂时提供三个，mocha， enzyme 和 react-testing-library ） 为下面文件覆盖单元测试，要求所有的用例代码写在一起，且覆盖率达到 100%。需要测试的文件路径为 zzz (文件系统里取出来） ，且在单元测试的文件上一级目录，需要使用相对路径完成引用，请注意引用路径。请根据上述要求给出完整可用，具备有效依赖引用的代码。需要覆盖单元测试的文件代码如下 yyy
- 结果是否规律可提取：每次拿到的结果是否存在一定规律，能否按照一定的格式或者套路提取出你需要的内容，这也是为什么我要求 gpt 把所有的用例代码写在一起的原因，通过这种方式我就能使用正则提取出代码块，再进行文件写入，这个同样也是需要通过 case 测试并对通用性问题进行补充的。
如果说，你感兴趣一个方向，并且希望这个方向可以使用 AI 提高效率，或者创造收益价值，那不妨回顾一下这三点，如果这三点都想清楚了，那 GPT 模型在这个方向一定是大有可为的。
你也可以做到！-- 将 GPT 模型应用到某个方向的可复刻实践方案
经过上面的学习，相信很多同学心里都已经有了自己的答案，将 GPT 模型应用到某个方向的可复刻实践方案无非就是三点：
- 可靠性验证
- 通用性问题的总结
- 规律性结果提取
当我们处理一个大问题的时候，我们有一个常见的算法思路，就是分治法，通过把大问题拆解为小问题，再逐步将小问题解决，从而达到解决大问题的目的。在将 OpenAI 应用到某个方向的时候，也是相同的道理。
以自动化测试为例，如果我需要使得 OpenAI 能够批量去处理某些场景，那么首先 OpenAI首先要能解决某个例子的自动化测试用例生成，因为一个都不能解决，那就不用去考虑批量或者说更多场景的事情了。
如果每个小问题都逐一解决后，我们需要考虑的就只剩下对比这些问法中间的共同点与不同点了，通过这个过程，提取出通用性问法就是能够应用到这个方向的关键了。 就和动态规划的动态表达式一样，难的并不是动态规划，而是表达式的提取，当完成这一步 OpenAI 在这个方向的应用就已经完成大半了。
在拿到通用性问法后，至少可以说明这个方向是可行的了，在绝大多数场景下，一个合适的问法都可以拿到一个比较有规律的答案，我们通过正则等字符串处理的方式就能拿到最终的结果。如果结果比较多样性，那大概率是因为通用性问题缺乏一些限制。
就比如“为下面文件生成用例，要求覆盖率100%，且当前文件路径为xxx，请使用合理的相对路径引入"远远比“为下面文件生成用例”得到的答案更具备规律性，如果因为结果不够规律，不知道该怎么提取结果，在放弃前不妨试试多加一些限制（即使这些限制在你看来像是废话）
当前这些更像是纸上谈兵，具体怎么问也要结合实际场景，和大量 case 测试后才能提取出来，不妨大胆试试，宁愿犯错，也不要什么都不做。不仅是测试，类似代码优化、性能优化、代码迁移重构其实 AI 都可以做到，而且我相信大有可为，至少在这个领域，想法💡远比技术要更有价值。
小结
这篇指南我们分别就 GPT模型、GPT模型接入、GPT模型应用三个方向结合例子详细学习了 GPT 的高阶玩法 -- GPT模型自动化应用，不管是搭建一个私服 chatgpt，还是利用 gpt 的能力完成一些工程化，或者是代码优化的内容，都可以参考上面的部分，相信大有可为～
还是那句话，在这个领域，想法💡也许远比技术要更有价值，GPT 的应用还远不及此，最近推出的 GPT 克隆人、AutoGPT 都让人眼前一亮。
也许有一天流浪地球 2 中的数字生命也不再是幻想，如果用 websocket 搭建两个 gpt-3,并且通过一定的数据微调让他们扮演两个人，互相对话训练又会发生什么呢？
这个方向有太多可以探索的东西，希望大家可以不设边界，多去尝试，也许真的你就是改变世界的那个人～如果对这方向有疑惑或者需要探讨的内容，也欢迎大家在评论区与我交流！
