上个月月底的事。我们那个对账模块有个偶发超时，一个月冒一两次，没规律，查了几轮都没定位到。看日志得靠 traceId 把一次请求的所有行串起来，问题是日志平台上筛出来是一坨，多线程打的，时间顺序是乱的。我原来手动 grep 再肉眼排，一次十几分钟，排到第三次我就烦了。
所以我让 AI 写了个脚本，输入 traceId，把日志文件里相关的行按时间排好输出。给它看了两行样例日志，字段我挨个解释了一遍——我按做测试的习惯，先把输入边界交底：时间字段的格式是什么样、traceId 可能重复出现在不同机器上、日志里有些行是多行堆栈没有前缀。
我当时预期是：要么跑不通，要么跑通了但边界漏一堆。这是我第一反应，找茬嘛。
结果第一把就跑通了。
不光跑通。它还顺手做了两件我没提的事。一个是把 ctx 那个字段截断了，说日志里它特别长，不截断输出没法看。另一个是它按 traceId 分组之后，每组首尾各留了三行上下文，说超时这种问题，答案经常不在这条 traceId 里，在前一条。这个我确实没想到，但它说的对——我们上次那个超时，最后是在前一个请求的日志末尾找到的线索。
到这一步我的心情是有点复杂的，就是那种，你准备了一肚子边界要跟它掰扯，结果人家先把两件事做了（不知道这么说清不清楚，反正就是有点被打脸的感觉）。
但是。
我按老习惯造脏数据跑了几组，时间字段这块出问题了。我们日志里有一类行是不带时间戳的，异步打出来的还是格式不对，这个我到现在也没深究。AI 的写法是先 sort_values 再按 traceId 取最后一条。pandas 里 NaT 排序是扔到最后的，所以那批没时间戳的行，反而变成了每组"最新状态"。输出里最新那条的时间是空的。
我第一次跑的时候没看出来，看输出最后一行时间戳空的，以为是自己 grep 的范围漏了，回头又翻了半小时平台，才对上是脚本的问题。
气是有一点，但我也没法全赖它——我交底的时候说了时间字段长什么样，但没说可能为空。不过反过来讲，它既然知道给我们日志加截断、加上下文，这个兜底不做，还是有点说不过去。这个度我也说不好在哪儿。
改起来倒是不难，把没有时间戳的行单独拆出来，标成"时间未知"放最后。改完我拿真实的 traceId 复跑了一遍，跟手排的结果对上了。
脚本我现在丢在 ~/tools 底下，用到就调一下。后面要不要加个 traceId 批量入参还没想好，一次查一个其实也够用。先这样吧，想到再补。