5.28

从地图定位到飞书机器人：一次运维系统体验优化记录

今天主要围绕两个方向优化了项目：地图管理体验和飞书机器人响应速度。这两个问题看起来一个偏前端交互，一个偏后端链路，但本质都一样：系统不仅要“能用”，还要让用户感觉“可靠、清楚、有反馈”。

地图功能最开始的问题是定位不够准确。后来发现，偏差不一定来自代码本身，而是来自坐标体系不一致。国内常见的地图坐标有 BD09、GCJ02、WGS84，如果站点坐标来源和底图坐标系对不上，放大后就会明显偏移。于是我们给地图增加了“坐标来源”选择，并支持不同坐标系之间转换。

另一个体验问题是站点标记。单纯在地图上放一个圆点不够直观，用户很难知道这个点代表哪个站。所以地图标记改成了“点位 + 站名标签”的形式，点击侧边栏站点后，地图会自动回到该站点中心并放大，右侧展示站点图片、设备状态、维修员、管理员等业务信息。

为了进一步解决小偏差，还增加了人工校准功能。不过默认拖动站点并不严谨，所以后来改成必须先点击“进入校准模式”，再拖动或点击地图移动站点，最后手动保存校准坐标。这样既避免误操作，也符合业务系统对数据准确性的要求。

登录体验也做了调整。之前是登录弹窗，后来改成独立登录页。不同角色登录后看到不同菜单和功能权限，比如管理员、站区管理员、巡检员、维修员的页面和操作权限都不一样。这让系统更接近真实业务场景，而不是所有人看到同一个后台。

飞书机器人这边，主要问题是回复慢。分析后发现，webhook 本身已经能很快返回 200，真正慢的是后台查询、AI 生成和飞书回复接口。于是增加了“快速首响”机制：如果 1.2 秒内还没生成最终答案，机器人会先回复“收到，正在查询系统并组织回复，请稍等…”，然后继续处理最终结果。同时也优化了飞书 HTTP 连接池，并在项目启动时预热飞书 token，减少第一次回复的等待时间。

今天的收获是：很多“体验问题”背后其实都是链路问题。地图偏差不是单纯前端点位问题，而是坐标来源问题；机器人慢也不只是 AI 慢，而是用户缺少即时反馈。把这些链路拆开，逐段优化，系统就会从“功能能跑”慢慢变成“真的好用”。