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的要符合实际

三、 实施方案与核心代码落地

这块就是我告诉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 消息实时性与持久化

当用户发送消息时，流程如下：

1. API 调用：前端调用 /api/chat/conversations/:id/messages 发送消息。
2. 后端落库：消息存入 MySQL，确保不丢失。
3. 实时推送：后端调用 Hub.PushToUsers，Hub 将消息通过 WebSocket 实时推送到目标用户的客户端。
4. 回执通知：支持消息已读/未读状态更新，并通过 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 系统的落地，几大技术挑战：

1. 高性能：通过 Go 协程和 Channel 实现了异步非阻塞的消息分发。
2. 分布式扩展：引入 Redis Pub/Sub 解决了单机连接上限问题，系统可水平扩展。
3. 用户体验：引入心跳机制保证连接稳定性，引入在线状态实时通知和输入指示器，提升了产品的互动感。
4. 安全性：在 WebSocket 升级阶段通过 JWT 进行身份校验，确保只有合法用户能建立连接。

该方案支撑了私聊、群聊、好友申请、实时状态更新等核心 IM 功能。

结语

整体来说，后端实现挺严谨的，也能实现闭环；前端用gemini确实很好，但是也不能百分百还原页面，细节还要手动调整，只要你描述详细代码逻辑实现的很好；不管前端还是后端如果用AI跑通整个项目是不可能的，但是独立功能或者小型项目或者是非业务类型的实现还是很好的；

当然，有时候也会犯病，东扯西扯的，还是需要手动调整；如果0基础用AI实现项目的话企业级的项目还是不行的，如果是demo还是可以的。

目前来说，AI还是不能完全代替程序员的，将来可能会；但是程序员配AI辅助开发确实能极大地提升效率，会轻松很多，0基础就算了，个人感觉0基础使用AI写项目的路还很长，如果是写demo，练手的项目那当我没说。

openAI创始人曾说过，AI不是代替某个岗位的，而是伙伴关系

所以，AI趋势下也不要过多在乎那些营销号，而是拥抱AI让AI成为伙伴！

等有时间了会把相关代码整理到仓库中。如果觉得不错麻烦给个赞吧,给大家拜个年磕一个

效果图：