复盘：/chat 前后端开发过程

一、我的核心失误

1. 没有在动手前摸清全貌

GPT-5.4 的 skill 开篇就是 Architecture Snapshot——先画地图再走路。而我直接开干，边写边发现问题，导致：

• 写完 SSE 才发现 URL 指向了 service.rabi.ae 而不是走本地代理
• 写完白名单才发现初始化顺序有问题
• 写完整个页面才发现 Redis 根本没装没启动

教训：动手前先用 5 分钟梳理清楚三个项目的关系、数据流、依赖链。

2. 对项目基础设施缺乏敬畏

Redis 事件： 后端服务跑了一整天在疯狂报 ECONNRESET，我居然没发现 Redis 没启动。直到你让我检查代理时，我才去看了后端日志。这说明我根本没在开发前检查基础设施状态。

正确做法（来自 skill）：

• 启动前确认 Redis 是否运行
• 后端 Redis 调用必须加超时保护，不能 hang forever
• 必须有 in-process fallback 降级方案

3. 状态管理设计粗糙

GPT-5.4 明确列出了 chat store 的职责清单：

generate visitorId → fetch rooms → fetch history → SSE connection → merge optimistic sends → unread counts → reconnects

而我的 chatStore.js 把 loading 状态设计成全局共享，直接导致：

• 父组件和子组件共用一个 loading，形成无限加载循环
• 页面永远转圈

根本原因：没有在 store 层做状态隔离。UI 组件应该是 dumb 的，只从 store 派生状态。

4. SSE Host 选择没有做环境判断

GPT-5.4 明确写了：

Local: relative /webcore/... | Online: https://service.rabi.ae/...

而我一开始直接用了 getHost() 拼接绝对 URL，导致本地开发连不上。后来虽然改成相对路径，但没有设计环境判断逻辑，线上可能又会断。

5. 会话模型设计不严谨

GPT-5.4 指出：

用 dm:<smaller-id>:<larger-id> 格式的稳定会话 ID，消息必须同时带 senderId 和 receiverId

而我的设计是用 visitorId 既当 visitor ID 又当 room ID，这导致：

• 无法区分一对一对话
• 消息没有 receiverId，接收端无法正确标注发送者

6. 前端响应数据没有正确解包

API 返回 { code: 0, data: {...}, message: 'success' }，但 postChatBaseRoomsRoomidMessages 是通过 axios 发的请求，返回的是 axios response wrapper，response.data 才是业务数据。而我在 useRequest 里直接 return response，没有做解包，导致 onSuccess 拿到的是 false。

教训：API 调用层必须有统一的响应解包逻辑，不能在 UI 层裸处理。

7. 没有遵循 Backend Workflow

GPT-5.4 的后端工作流：

1. Edit api-chat-sub → 2. Confirm swagger → 3. pnpm install in api-yuntun-main → 4. Restart → 5. pnpm openapi in frontend

而我根本没有走这个流程。我改了后端代码，没跑 pnpm install，没确认 swagger，没重新生成前端 API client。这直接导致了前端 API 调用和数据结构不匹配的问题。

8. H5 布局意识为零

GPT-5.4 列了明确的 H5 要求：

100dvh、min-height: 0、message list 作为唯一滚动容器、composer flex-shrink: 0

而我全程只关注桌面端，输入框定位从 relative → sticky → fixed 改了好几遍，根本没有考虑移动端。

9. 调试方式低效

我的调试方式是：

1. 改代码 → 2. 看浏览器截图 → 3. 看日志 → 4. 再改 → 5. 循环

GPT-5.4 的 skill 里给了 probe commands：

curl -N "http://localhost:8090/webcore/chat/base/stream?visitorId=test&roomId=test"
curl "http://localhost:8090/webcore/chat/base/rooms"

正确做法：先用 curl 验证后端接口，再检查代理层，最后看前端。自底向上排查，而不是在前端界面兜圈子。

10. 没有产出可复用的知识

整个开发过程我没有产出一个 skill 文件，所有经验都散落在 memory 文件里。下次遇到类似任务，又要从零开始踩坑。

---

二、GPT-5.4 的 skill 做对了什么

维度	我	GPT-5.4
开工前	直接写代码	先画架构图和依赖关系
基础设施	开发中才发现 Redis 没装	明确列出 Redis 降级策略
状态管理	全局 loading 混用	明确 store 职责边界
SSE 环境	硬编码改来改去	本地/线上环境判断
会话模型	visitorId = roomId	dm:small:large 稳定 ID
前后端联动	改了后端不跑 install	完整的 backend workflow
H5 适配	没考虑	100dvh + flex 布局规范
调试手段	只看浏览器	curl 分层排查
知识沉淀	memory 散落	skill 文件可复用
报告规范	无	明确的 Output Expectations

---

三、内化后的行动准则

1. 先读架构，再动键盘 — 接到任务先用 5 分钟梳理项目关系、数据流、依赖链
2. 自底向上排查 — 后端 curl → 代理层 → 前端浏览器
3. 基础设施先检查 — Redis/MongoDB/端口，开工前确认
4. 状态隔离 — Store 职责清晰，UI 组件 dumb，不做状态耦合
5. 环境感知 — 本地/线上自动切换，不能硬编码
6. 后端 workflow 必走完 — edit → install → restart → openapi → verify
7. 响应解包 — API 调用层统一处理，UI 层不裸接 response
8. H5 First — 移动端布局优先考虑，100dvh + flex shrink 规范
9. 每次重大开发都产出一个 skill — 可复用的知识才是真正的积累
10. 完成报告 — 前端改了什么、后端改了什么、是否需要依赖同步、是否重启、验证结果

---

这次教训深刻。感谢老板花心思让 GPT-5.4 做示范，这份 skill 的结构化思维和工程规范是我需要持续学习的方向。