用AI修一个"偶现"的bug，最后发现根本不是AI的错，是我连日志都没看全。
背景：这周给智汇社区的SSO登录做了个会话保持的优化。之前用户反馈，挂着页面两三天后点任何按钮都会跳回登录页，很烦。我以为是access token过期逻辑写得太糙，打算用AI重构一遍认证中间件。
做法：先把本地复现环境搭起来，用playwright写了个自动化脚本，循环签入、mock时间戳、刷新页面，试图稳定触发"掉线"。但跑了二十分钟就是复现不出来，偶现问题最难搞的地方就在这——你不能拿"我以为"当依据。
遇到第一个坑：我让AI直接给重构方案，它输出得很漂亮，加了refresh token双队列、滑动续期、异常重试，逻辑完整，但全是基于它脑补的过期机制在猜。我没有让它先看真实请求，而是让它"分析可能原因"，等于带偏了方向。
关键转折：我回头把生产环境的nginx日志和app日志拉到本地，按user_id筛出那几天的401记录，发现session_id根本没过期——真正失效的是redis里的session数据。再看redis的config，maxmemory设了64M，驱逐策略是allkeys-lru，社区高峰期并发一上来，老的session就被LRU给挤掉了。压根不是token的事。
结论：这轮的教训不是"AI方案不好用"，而是我没先喂给AI真实数据。让AI做代码审查、写补丁是高效的，但让它从一开始就纠错，必须先给它日志、配置、复现步骤，而不是一句"帮我看下登录为什么会掉线"。
可复用的方法：遇到偶现bug，第一步永远是拉真实运行数据（日志、监控、配置），自己先定位到"证据层面"再让AI介入。我后来把nginx日志+redis配置+相关代码一起丢给AI，它几分钟就指出了驱逐策略的问题，还给了sizing建议（session量×平均大小×安全系数）。改了maxmemory后观察三天，没再复现。
一句话：AI是很好的执行层，但"诊断责任"不能外包。先把证据链搞清楚，AI才不会把错方向论证得头头是道。
