跳至正文

我用AI写了个游戏服务器和管理后台,顺便对比了各大模型的编程能力

从微信云开发迁移到自建服务器的心路历程,以及GLM、miniMax、Kimi等国内大模型的实战评测


前言

作为一名前端为主的游戏开发者,最近完成了一个重要的技术迁移——用AI把小游戏的后端能力从微信云开发迁移到了自建服务器,同时还让AI顺手写了个管理后台。

今天分享下这段迁移经历,以及对国内外主流AI模型在编程能力上的个人评测。


一、为什么要从云开发迁移到自建服务器?

1.1 调用次数额度不够

我的小游戏主要依赖两项后端能力:

  • 云数据库:存储用户数据
  • 云函数:处理数据存储和排行榜逻辑

微信云开发每月有20万次调用额度,听起来不少,对吧?但实际上根本不够用。这里有个坑:云开发的调用次数是双倍计数的。

举个例子:

  • 游戏前端请求一次云数据 → 调用云函数算 1次
  • 云函数再去请求数据库 → 又算 1次

也就是说,每请求一次数据至少算2次调用。如果是排行榜功能,做一次排名可能要请求多次数据库,消耗就更大了。

虽然我在前端已经做了延迟存储和合并,但调用次数仍然远超限额。

1.2 实时推送的缺失

另一个缺点是:云开发无法做实时推送。想对用户数据做实时统计、推送消息都很不方便。

1.3 解决方案:自建WebSocket服务器

于是我决定:让AI写一个WebSocket后端服务器,支持实时双向通信。

说实话,这种纯逻辑、不涉及UI交互的代码,让AI写非常合适。几轮对话下来,核心代码半小时就完成了,还包括文档:

本项目是一套为小游戏编写的 Node.js 后端服务器,主要提供:

- 用户登录 / 注册
- 排行榜查询
- 用户数据存取与更新
- WebSocket(ws/wss)长连接服务
- 后台管理系统(实时监控、服务器状态查看)

技术栈:

- Node.js + TypeScript
- WebSocket(基于 `ws` 库)
- MongoDB(使用 Mongoose 访问)
- Express(后台管理API)
- React + Ant Design(后台管理前端)

....

当然,后面还是花了不少时间做适配和调试:

  • 心跳机制(防止连接假死)
  • 断线重连(提升用户体验)
  • 正式部署上线(服务器、SSL证书配置等)

整个迁移过程断断续续也用了几天,但相比从零手写,效率已经高太多了。

1.4 关于SSL证书的小提示

微信小游戏对服务器有个硬性要求:必须使用 HTTPS 或 WSS 协议。所以必须配置SSL证书,否则前端无法正常连接。


二、AI写代码:GPT vs Gemini

写服务器代码时,我主要用TRAE国际版,AI模型以 GPT 为主,中间也用了 Gemini

总体感受:

GPT给出的方案更全面,考虑边界情况更周到,代码一次通过率高。但代价是Token消耗有点大,尤其是对话多了后。而 Gemini 在解决bug上有奇效,常常有惊喜。


三、管理后台开发:国内大模型实测对比

游戏服务器搭好了,但作为一个专业的开发者,总得了解服务器的运行状态吧?

于是我又让AI写了个游戏管理后台,功能主要是 实时查看在线人数、监控CPU和内存占用。

3.1 成本倒逼的"国产替代"

我原本订阅的是TRAE国际版Pro会员,以前按次数计费,每月都用不完。但最近TRAE改成按Token计费后,消耗飞快,月额度居然不够用——前面写服务器代码就消耗殆尽了。

而上下文长了后,GPT的每次对话至少消耗0.5美元,简直是"吞金兽",每多说一句话都感觉心痛。于是我同时打开了TRAE国内版,用国内免费大模型来帮忙。

3.2 三大国内模型实战PK

🥉 GLM:基础功能OK,复杂需求翻车

一开始用GLM-4.7写管理后台的基础功能:统计在线人数、展示CPU和内存占用。

这部分完成得不错,代码逻辑清晰,功能正常。

但当我提出复杂一点的需求,给后台管理系统的页面增加分栏显示,左边栏是功能区,右边栏是展示区。问题出现了:

GLM-4.7开始"糊涂"了,改了2、3次都是错的,布局总是对不上,要么报错要么显示空白。

🥇 miniMax:一次搞定,效率惊人

眼看GLM-4.7搞不定了,我迅速切换到 miniMax-2.5

结果:一次就搞定了!

后续又陆续增加和调整了几个功能:

  • 添加实时日志查看
  • 优化数据刷新
  • 调整UI样式

全部一次对话搞定,代码质量稳定。

唯一的缺点:miniMax的回答稍显简洁,代码默认不带注释,需要在提示词里明确要求。

🥈 Kimi:还算可靠,中规中矩

中间也穿插使用了Kimi,感觉表现介于GLM和miniMax之间,偶尔会出现幻觉,对话自相矛盾。

3.3 最终效果

最终的后台管理界面如下,对一个非专业后端来说,我已经很满意了。

同样让AI帮我整理好了功能文档:

一个基于 Web 的实时监控平台,用于监控微信小游戏服务器的运行状态和在线用户情况,并提供配置管理功能。

### 实时监控
- ✅ 在线用户数统计
- ✅ 用户游戏时长统计
- ✅ 服务器性能监控(CPU、内存、运行时长)
- ✅ 在线用户列表(显示最近20个)
- ✅ 在线用户趋势图表

### 配置管理
- ✅ 客户端版本更新配置
- ✅ 实时配置更新,无需重启服务器
- ✅ 配置持久化存储
- ✅ 支持强制更新和最低版本号设置

### 技术特点
- 🚀 15秒自动刷新,低性能影响
- 📊 图形化界面,直观展示数据
- 🔐 密码登录保护
- 📱 响应式设计,支持多端访问
- 🎨 基于 Ant Design + ECharts,界面美观
- 🔄 配置实时生效,无需重启

## 🏗️ 技术栈

### 后端
- **Node.js** + **TypeScript**
- **Express** - Web框架
- **WebSocket (ws)** - 实时通信
- **systeminformation** - 系统信息获取
- **jsonwebtoken** - JWT认证
- **MongoDB** - 数据存储
- **Mongoose** - MongoDB ODM

### 前端
- **React 18** + **TypeScript**
- **Vite** - 构建工具
- **Ant Design 5** - UI组件库
- **ECharts 5** - 数据可视化
- **Axios** - HTTP请求
- **React Router** - 路由管理

四、国内大模型编程能力排名(个人评测)

基于这次实战体验,我的个人排名如下:

排名 模型 编程能力 特点
🥇 miniMax ⭐⭐⭐⭐⭐ 代码准确率高,复杂需求也能一次搞定
🥈 Kimi ⭐⭐⭐⭐ 还算可靠,偶尔幻觉
🥉 GLM ⭐⭐⭐ 基础功能OK,复杂需求容易翻车

当然,这只是基于我这次特定场景的体验,不同场景下各模型的表现可能会有差异。

4.1 总结

  • 多模型协作是常态:不要死磕一个模型,灵活切换能省很多时间
  • 提示词要明确:想要注释、想要错误处理、想要边界情况处理,都要在提示词里说清楚
  • 综合对比,GPT略微更全面稳定,但成本也更高。国内模型在特定场景下可以替代

五 联系作者

作者的公众号和博客会不定期分享一些游戏开发技巧和上线实战经验,欢迎关注,共同进步!

作者同时创建了一个游戏开发交流群,供朋友们技术交流、学习合作、问题求助等,感兴趣的朋友可以关注我的公众号,并留言加群

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注