干货分享 | 用iFlyCode从0到1实现简易小程序调用大模型的公共构件

今天介绍一个使用iFlyCode的实际案例场景，在其帮助下从0到1建立一个基于小程序的全新的大模型公共构件。

01 背景

当前大模型火热的时代，亟需各客户端快速接入大模型API的方式，当前已有Web JS-SDK形式的大模型接入构件，还需新开发一个基于FinClip小程序的轻量构件。在iFlyCode的帮助下可以快速搭建一个可用的公共构件。

02 用iFlyCode高效编码

首先最关键的是大模型服务的鉴权，鉴权的通信是HTTP的通信方式，首先需要将JS代码翻译成FinClip代码：

输入：

输出：

现在，我们知道了HTTP的通信方式。接下来，我们需要调用大模型服务的鉴权：本例子中，鉴权需要MD5的加密，因为之前的MD5文件是TS代码，现在我们让大模型把翻译成小程序需要的CMD模块。

输入：

输出：

按照上面的步骤，我们获得了基于小程序的MD5加密工具文件。接下来就是进行鉴权了。我将原有的TS鉴权方式输入给AI。

输入：

输出：

然后，我们调试一下，鉴权步骤通啦！

接下来，我们需要进行大模型能力的调用了。大模型能力在这里采用的是WebSocket通信，序列化的协议是protobuf。按照上面的思路，将WebSocket相关的调用API翻译成小程序API：

根据AI的提示，我们将所有的API替换成小程序API。

接下来我们开始发送消息给大模型：

竟然报错了，按上面的流程，目前只有Protobuf序列化三方库没有进行更换，所以问AI：

果然，protobufjs不能使用，于是我另找了一个专门为小程序使用的protobuf库，引入到文件中，再试一下：

成功啦！这样我们就完成了小程序端针对大模型API通信层的打通。

03 用iFlyCode优化维护代码

做完上述两步，我们的代码能跑了，但是这还不足以成为一个公共构件，我们需要优化一些异常场景、增加代码的可读性、确保代码的健壮性。

代码解释

首先，我们需要考虑Web WebSocket中经常发生的一个问题：背压(Back Pressure)。在onmessage 回调中最好建立一层缓冲区防止网络内存被打满，特别是在移动端，网络内存的占比更为重要。在这个案例中，我们采取Stream流式API来建立数据缓冲区，将通信数据封装成可读流和可写流，我们找到了原有的Web 代码实现，正准备打算移植到小程序中时：

纳尼？这是一段火星文吗？怎么都看不懂它在干嘛。莫慌，还好iFlyCode有代码解释功能。我们选中这段代码后，会自动解释：

这样就豁然开朗了，因为请求大模型场景中，消息是不断从服务端推送的，所以我们需要建立一个可迭代的可读流，上面的代码正是做了这样一层的封装。由于这套API在小程序中可以使用，所以直接移植过去。

代码优化

上面的背压处理是我们自己发现的一处可优化的地方，那么还有其他可优化的地方吗？Emmmm....暂时想不到了，先把我们的代码复制给iFlyCode吧，听说它有代码优化和代码审查的功能呢！

检查一下，确实这些地方没有考虑到呢，赶紧修复一下这些小漏洞。

代码注释

刚刚，我们针对一些异常场景、边界场景做了处理，我们根据上面的代码思路优化了代码之后，需要让后面阅读的人知道我们这些是在做什么、为什么这么做，以增加代码的维护性。那么接下来就是一个重要步骤了：我们要对方法、属性进行注释。好，开始吧，让我们打开通信的基类文件：

好家伙，一个通信基类竟然有7个属性、13个方法，代码中还有其他的文件、其他的子类，这要一个一个注释，估计每个几小时都下不来。还好，我们有iFlyCode的文档注释功能。只需选中待注释的文档，就能自动化注释了：

由于代码较长，我们展示部分代码块的注释效果：

可以看到，它的注释是比较精准的，完全符合我们上述讨论的优化思路。

单元测试

作为一个合格的开发，我们需要对代码进行相应的自测，确保功能正确性，通过编写单元测试是一个很好的自测实践，可以确保我们构件中的各个功能模块能够正常工作，满足预期的需求。但是，编写单测模块往往是耗时、重复的工作，iFlyCode有单元测试的功能，我们尝试使用一下，看看效果。

PASS！我们顺利完成了整个构件的最后一部分：自测。

通过上面的步骤，我们就完成了一个基于web js代码从0到1实现了小程序端大模型的一个可用的公共构件了，让小程序端的开发人员使用我们的构件也能快速接入大模型API啦。基于上面的构件，我们简单开发了一个demo页面，展示如下：

好了，我们这次的分享就到这里啦 ，快开始你的AI编程之路吧！