AI辅助，两天实现一个IM系统？
前言
最近写项目的时候，有个项目中需要实现聊天系统 ，所以打算周末两天借助AI辅助进行开发，此篇文章说一下自己使用AI辅助开发的一些心得；其中会把完整的使用过程介绍一下。
后端:Claude Code
前端:Gemini
一、 架构设计
在设计 IM 系统时，要明确自己的核心目标，我们的核心目标是：实时性、可靠性、可扩展性。
在架构设计的时候其实我也请教了一下AI，有一说一都挺不错的，以下是统一话术各个AI的个人使用总结：
1.GPT
设计的比较完善清晰但是具体细节略少，整体来说还是挺靠谱的；
2.deepseek
说实话deepseek也挺好，虽然但是，我要的是整体架构设计它却给我实现一个demo（同一话术）,也是笑不活了，请看VCR
反正就是前后端代码都帮你实现了，表也贴心的帮你实现了虽然不能直接用，哈哈哈；有一说一确实挺难绷的
3.Gemini
说实话，gemini确实有点东西，整体架构设计和技术上都挺好的，而且还会根据需求分析阶段性开发。
后面也试了其他AI我就不一一说明了。。。。。
我采用的是HTTP + WebSocket + Redis的混合架构。实现过程就是用文章开头说的那俩AI实现的，然后我就给他方向和部分代码修正
1.1 核心设计
- WebSocket 模块：负责建立长连接，实现双向实时通信。
- 消息中台 (ChatHub)：负责所有连接的管理（注册/注销）、心跳检测、以及跨实例的消息分发。
- 消息流转模型
- 持久化消息：用户通过 HTTP 发送消息 -> 存入数据库 -> 推送至 Hub -> 转发给接收者。
- 瞬时事件：如“正在输入（TYPING）”，不经过数据库，直接通过 WebSocket 广播转发（追求响应速度，哈哈哈）。
- 分布式方案：利用 Redis Pub/Sub 实现跨服务器实例的消息分发。当用户连接在不同服务器上时，Redis 确保消息能够准确投递。
二、 技术选型
技术选型是我定的，毕竟不是做demo的要符合实际
| 维度 | 选型 | 理由 |
|---|---|---|
| 开发语言 | Go (Golang) | 并发性能强，原生支持 Goroutine，非常适合处理高并发长连接。 |
| Web 框架 | Gin | 轻量、高效，路由性能卓越。 |
| 长连接库 | Gorilla WebSocket | Go 社区最成熟、性能最稳定的 WebSocket 库。 |
| 存储层 | MySQL (GORM) | 消息的可靠持久化，支持复杂的关联查询（如会话列表、成员权限）。 |
| 缓存/发布订阅 | Redis | 实现用户在线状态追踪、分布式消息同步（Pub/Sub）。 |
三、 实施方案与核心代码落地
这块就是我告诉AI引导它一步一步实现的了
3.1 核心数据模型 (Model)
IM 系统的基础是会话（Conversation）和消息（Message），以下是部分数据模型设计
// Conversation 会话模型 type Conversation struct { Base Type string `gorm:"type:varchar(20);not null" json:"type"` // private, group Name string `gorm:"type:varchar(100)" json:"name"` Avatar string `gorm:"type:varchar(255)" json:"avatar"` CreatorID uint `json:"creatorId"` Members []ConversationMember `json:"members,omitempty"` // ... 更多字段 }// Message 消息模型 type Message struct { Base ConversationID string `gorm:"type:char(36);index" json:"conversationId"` SenderID uint `json:"senderId"` Sender User `gorm:"foreignKey:SenderID" json:"sender"` Type string `gorm:"type:varchar(20)" json:"type"` // text, image, file, voice Content string `gorm:"type:text" json:"content"` IsRead bool `gorm:"default:false" json:"isRead"` }3.2 消息中台 (ChatHub) 的实现
这是是整个 IM 系统的“心脏”，它维护着所有在线的 Client 连接的；这部分很重要，基本上是AI实现后我再修修改改或者引导AI帮你修改
部分代码示例：
type ChatHub struct { clients map[uint]*Client broadcast chan []byte register chan *Client unregister chan *Client mu sync.RWMutex Redis *redis.Client ChatRepo *repository.ChatRepository ctx context.Context } func NewChatHub(rdb *redis.Client, chatRepo *repository.ChatRepository) *ChatHub { return &ChatHub{ broadcast: make(chan []byte), register: make(chan *Client), unregister: make(chan *Client), clients: make(map[uint]*Client), Redis: rdb, ChatRepo: chatRepo, ctx: context.Background(), } }3.3 分布式推送与在线状态
多实例部署，使用 Redis 进行消息分发：
代码示例：
// PushToUsers 通过 Redis Pub/Sub 将消息发送给指定用户（支持跨实例） func (h *ChatHub) PushToUsers(userIDs []uint, msg WSMessage) { psMsg := PubSubMessage{ TargetUsers: userIDs, Payload: msg, } payload, _ := json.Marshal(psMsg) h.Redis.Publish(h.ctx, "chat_channel", payload) } // pushToLocalUsers 仅将消息发送给连接到“当前实例”的客户端 func (h *ChatHub) pushToLocalUsers(userIDs []uint, msg WSMessage) { // ... 锁定 h.clients 并通过 channel 发送消息 ... }3.4 连接生命周期管理 (Read & Write Pumps)
每个 WebSocket 连接都会开启两个并发协程：一个负责读，一个负责写。
- ReadPump：解析前端发来的控制指令（如正在输入）。
- WritePump：处理心跳（Ping/Pong）和下发消息队列。
四、 关键功能实现细节
4.1 会话管理
支持 私聊 和 群聊。私聊会自动检查是否已存在会话，避免重复创建。群聊则包含角色权限管理（管理员、普通成员）。
4.2 消息实时性与持久化
当用户发送消息时，流程如下：
- API 调用：前端调用 /api/chat/conversations/:id/messages 发送消息。
- 后端落库：消息存入 MySQL，确保不丢失。
- 实时推送：后端调用 Hub.PushToUsers，Hub 将消息通过 WebSocket 实时推送到目标用户的客户端。
- 回执通知：支持消息已读/未读状态更新，并通过 WS 通知发送方。
4.3 瞬时状态处理 (Ephemeral Events)
对于不需要存库的状态（如 TYPING），系统直接在 Client.readPump 中解析并转发：
// 处理正在输入状态 (TYPING) if wsMsg.Type == "TYPING" { data, ok := wsMsg.Data.(map[string]interface{}) if !ok { continue } convID, _ := data["conversationId"].(string) if convID == "" { continue } // 获取该会话的其他成员并转发 c.Hub.HandleTransientEvent(c.UserID, convID, wsMsg) }五、 落地总结
本次 IM 系统的落地，几大技术挑战：
- 高性能：通过 Go 协程和 Channel 实现了异步非阻塞的消息分发。
- 分布式扩展：引入 Redis Pub/Sub 解决了单机连接上限问题，系统可水平扩展。
- 用户体验：引入心跳机制保证连接稳定性，引入在线状态实时通知和输入指示器，提升了产品的互动感。
- 安全性：在 WebSocket 升级阶段通过 JWT 进行身份校验，确保只有合法用户能建立连接。
该方案支撑了私聊、群聊、好友申请、实时状态更新等核心 IM 功能。
结语
整体来说，后端实现挺严谨的，也能实现闭环；前端用gemini确实很好，但是也不能百分百还原页面，细节还要手动调整，只要你描述详细代码逻辑实现的很好；不管前端还是后端如果用AI跑通整个项目是不可能的，但是独立功能或者小型项目或者是非业务类型的实现还是很好的；
当然，有时候也会犯病，东扯西扯的，还是需要手动调整；如果0基础用AI实现项目的话企业级的项目还是不行的，如果是demo还是可以的。
目前来说，AI还是不能完全代替程序员的，将来可能会；但是程序员配AI辅助开发确实能极大地提升效率，会轻松很多，0基础就算了，个人感觉0基础使用AI写项目的路还很长，如果是写demo，练手的项目那当我没说。
openAI创始人曾说过，AI不是代替某个岗位的，而是伙伴关系
所以，AI趋势下也不要过多在乎那些营销号，而是拥抱AI让AI成为伙伴！
等有时间了会把相关代码整理到仓库中。如果觉得不错麻烦给个赞吧,给大家拜个年磕一个
效果图：
