在线用户管理页面看似简单，迁移时却暴露出“历史记录当在线”“通知即下线”“配置名当控制开关”等错误假设。精工智能技术团队借助CODEX，从还原用户真实依赖的行为出发，重新定义会话状态模型——用长期记录管理、短期租约证明活跃，并解耦实时通知与安全失效。本文复盘了这场由迁移引发的系统性重构，分享如何把用户反馈转化为可验证规则，让AI真正成为可靠的工程协作者。
从“搬页面”到“建行为”：迁移的真正对象是什么
一次在线用户功能迁移，立项时只被当作“一个管理页面的前端改造”。但真正动手后才发现，这个页面背后缠着登录冲突判断、实时下线通知、会话活跃性心跳、权限校验和异常清理一整条链路。
如果只盯着旧页面的字段和按钮，新功能大概率长得像、用起来却处处“不对劲”——比如用户明明关闭了浏览器，系统仍提示“其他终端在线”；旧终端收到下线通知，但刷新页面后居然还能操作。
问题不在代码搬得对不对，而在于迁移对象搞错了。真正的迁移对象不是页面，是用户能够感知并依赖的行为规则。团队必须先回答：用户到底依赖什么？
什么时候可以直接登录，什么时候需要二次确认？
检测到其他终端时，是先征得用户同意，还是直接踢掉旧终端？
旧终端被下线后，是否真的无法继续访问，而不只是弹了一条提示？
浏览器意外关闭或网络闪断，系统能不能在合理时间内恢复正确状态？
页面显示、菜单角标、登录拦截，是不是基于同一套事实？
这些问题没有一个能靠“照着旧代码复制”回答。迁移的第一步，是还原行为，而不是还原代码形状。
四个常见误区：为什么“看起来一样”不等于“行为一致”
迁移过程中，团队陆续踩中四个典型误区。它们单独看都不致命，但叠在一起，足以让新系统的在线状态变得不可信。
误区一：记录即在线。 数据库里存了会话历史，系统就默认该用户“当前在线”。历史数据长期堆积，导致明明没有其他终端打开，登录时仍提示冲突。改进方向很明确：用近期活动来证明真实在线，历史记录只能做管理展示。
误区二：配置名即语义。 看到旧系统有一个叫“在线状态显示”的配置项，就误以为是登录控制的开关。追踪调用链后才发现，它只控制菜单是否渲染，跟安全校验毫无关系。配置命名不可靠，必须追踪真实调用链。
误区三：冲突即失败。 重复登录时，旧系统弹的是“账号或密码错误”。这是把业务确认场景错误地归并到认证失败里。新系统必须把“认证失败”和“业务确认”区分开，给用户明确的二选一界面。
误区四：通知即下线。 旧终端收到“您已被踢下线”的通知，但旧凭证在服务端可能仍然有效。实时通知只能改善体验，不能替代服务端撤销凭证和会话状态。真正的强制下线，必须由服务端保证确定性和安全性。
这四个误区共同指向一个关键认知转变：不再问“旧系统有哪些类和页面”，而是问“用户依赖哪些行为、这些行为在异常情况下是否仍然成立”。
会话模型重构：历史记录与活跃状态必须分开
要解决“记录即在线”的根本问题，团队重新设计了会话状态模型。核心思路是把长期记录和短期活跃拆成两个维度。
长期记录负责展示和管理——用户能看到自己有哪些设备曾经登录过，何时登录，何时退出。这部分数据可以持久化存储，用于审计和展示。
短期活跃则依赖租约机制——终端需要定期发送心跳来“续租”，证明自己此刻仍然打开着浏览器、网络连通、用户在场。系统设定一个合理的租约窗口（比如心跳间隔的两倍加上网络抖动余量），窗口内收到心跳则视为活跃，超时则自动判定为离线。
只有长期记录存在且短期租约有效，系统才把该终端视为“真实在线冲突”。 这个双重判断避免了历史数据长期占位导致的误拦截。
心跳机制的设计也做了精细处理：不是固定间隔简单轮询，而是避免请求重叠，并在用户主动退出或登录失效后立即停止发送。心跳的意义不是制造更多请求，而是让系统在没有业务操作时仍能感知终端存活，同时保证异常退出后状态能及时收敛。
实时通知与安全失效解耦：一个负责即时，一个负责确定
另一个关键设计决策，是把“实时通知”和“安全失效”彻底解耦。
实时通知走消息通道，旧终端收到下线通知后可以立刻弹窗提醒，体验很好。但消息通道可能断开，消息也可能丢失，所以实时通知只负责体验的即时性，不承载安全责任。
真正的强制下线，必须由服务端完成：撤销旧终端的凭证、销毁会话、刷新权限缓存。此后，旧终端再发起任何请求，都会被认证中间件拦截并强制跳转登录页。即使通知消息没送到，旧终端也“事实上”无法继续访问。
二者缺一不可——消息提供即时感知，服务端撤销提供确定性。迁移时，新系统已经拥有统一的通知通道，团队选择直接复用，而不是为了“和旧架构名称一致”再重建一套专用通道。判断标准不是“代码是否长得一样”，而是“行为是否一致、职责是否清楚、维护成本是否可控”。
用户反馈即校正信号：把“改提示”变成“建规则”
迁移过程中，用户陆续反馈了菜单提醒不准、重复登录提示不友好、无用户仍提示冲突、启动反馈慢等问题。团队的处理方式不是“改一句提示就完事”，而是把每次反馈转换成可验证的规则。
例如“无人使用仍提示冲突”——表面是界面文案问题，实质是系统把历史记录错误地当成当前在线。于是对应规则变成：“只有当同一账号存在其他活跃租约时，才触发冲突确认流程；仅有历史记录不触发。”然后围绕这条规则补定向测试，验证正常路径和超时回收路径。
实践原则很简单：每次反馈都写成“场景—现象—错误假设—正确规则—验证方法”五段式。这个格式让AI在后续修改时不会沿着旧假设继续优化错误方向，也方便团队快速对齐预期。
在基础设施层面，团队也明确了一条底线：当缓存或实时服务短暂不可用时，不能因为“查不到状态”就默认没有其他用户在线，否则会绕过登录控制。更稳妥的策略是明确提示“服务暂不可用，请稍后重试”，保留现有状态，等待基础设施恢复后再继续判断。基础设施故障不能被解释为用户离线。
AI的协作角色：组织证据、执行修改、验证结果
这次重构中，CODEX承担了五种角色：研究旧实现、比较新系统能力、设计状态模型和测试场景、执行前后端修改、运行定向测试并分析失败。但团队始终把握住一条边界——AI不做业务决策。
哪些行为必须与旧系统一致？哪些兼容边界可以放宽？异常场景下是静默回退还是明确报错？这些都由工程判断把握。AI的优势在于快速跨越前端、后端、配置、数据和测试，把分散的证据组织成完整链路，并持续执行修改和验证。
文档也在迁移过程中同步更新，重点不是记录“怎么用”，而是记录决策原因——为什么复用统一通知通道？为什么增加活跃租约机制？为什么基础设施异常不能当离线处理？把“为什么”写清楚，后续维护者才不会把关键机制误判为冗余设计。
结语
这场迁移最大的启示是：技术迁移不止于代码搬运。它需要重新确认用户体验、状态事实、安全边界和异常恢复。先还原行为，再设计状态；先明确边界，再执行修改；先建立证据，再宣布完成。只有这样，AI才能真正成为可靠的工程协作者，而精工智能技术团队也得以在一次次重构中，让系统更贴近用户的真实使用习惯，而不是被旧代码的惯性牵着走。
精工智能数字化工厂，制造业Online，持续在场，赋能企业高质量发展。
