一个浏览器插件的两个 bug,和一次 Kimi Code 无声退出的追查

2026-10-06 晚间会话(20:55–21:56)复盘。上午另有产线系统 upan-v1 灌面板三单收口(8256ce2 / 5fca670 / 816c160),非本会话工作,本篇不展开。

背景与目标

element-picker(元素拾取器)是自己写的 MV3 浏览器插件:圈选网页元素产出结构化 JSON,喂给 AI 改界面。9 月 29 日已上架 Edge 加载项(v1.1.2)。今晚本人在经营驾驶舱系统里实际使用,连续撞出两个 bug,外加一个计划外事件:Kimi Code 进程中途无声退出。

本期工作清单:

过程回顾

bug①:面板遮挡(20:56 报障 → 20:59 修复)

本人原话:"固定在页面的右上角,导致右上角的部分元素被覆盖,无法选取。"现象直给,零背景交代,直接定位到 picker.js 的面板定位 CSS。

修法:面板标题栏改可拖拽(mousedown/mousemove/mouseup 三件套,边界钳制防拖出视口),拖动期间暂停悬停高亮防误触。commit 1a1ca06,版本 1.1.3。

插曲:Kimi Code 退出了(20:58 发生,两轮排查)

修到一半,Kimi Code 进程消失了。本人重启后在新窗口输了 cls(想清屏),又取消退出,再 resume 原会话输"继续"接着干。事后本人问:"刚刚是什么 bug 导致,退出了 kimi code?"

第一轮排查(误判):翻到 20:58 那个 cls 会话,看到 lastTurnReason: "cancelled",就下了"不是 bug,是人为取消"的结论。

本人纠正:"这个是 Kimi Code 退出以后重启的 Kimi Code,我才输的 CLI。"——即退出发生在前,cls 窗口是重启产物。

第二轮排查(转正):查当前会话日志,发现 wire.jsonl 在 20:58:15 戛然而止——第 4 步 Edit 工具结果落盘后,turn 连 turn.ended 都没写下;kimi-code.log、Windows 事件日志、Defender 全部零记录;自动更新排除(2.1.1 自 9 月 25 日在用,全部检查 not-newer)。先按"根因未定位"记故障台账(09830a3,21:15)。

第三句指令升级:"这个故障已经发生好几次了,应该是 Kimi Code 自己的问题。"这句话把排查从单次事件归因切换成模式取证:全量扫描所有历史会话的 state.json + 日志尾行,发现同日 16:23 还有一起同签名猝死(thinking/.pachong_ws 会话,第 26 步 llm request 发出后永远没有响应记录)。两起共性完全一致:wire 戛然而止、无 turn.ended、四层日志零记录。

拿着这个签名去搜官方仓库,直接命中 MoonshotAI/kimi-code#3189(OPEN):Windows 上进程无日志硬崩溃,根因是 libuv 异步句柄断言(UV_HANDLE_CLOSING, src\win\async.c:76,fail-fast 直接中止进程,所以 JS 层来不及写任何日志),有用户确认 v2.1.1 仍复现。本人定性正确。导出 debug 包,台账更新归因(c3ea51c,21:35)。

bug②:弹窗内元素无法拾取(21:43 报障 → 21:52 修复)

本人贴来拾取 JSON:"这个弹出框里面的元素无法选取。"JSON 显示只能选中 el-dialog 外壳。按小工具直达车道,先 grep 经营驾驶舱源码,matrix/index.vue:167 一行现形:预览内容是 <iframe sandbox="allow-same-origin"> 渲染的。

根因是机制级的:iframe 内部事件不冒泡到父文档,而拾取器的监听只挂在顶层 document 上,iframe 里的元素对它是盲区。

修法:picker.js 重构为多文档挂载——样式/提示条/事件监听挂进每个同源 iframe 的文档,MutationObserver 兜住激活后动态插入的 iframe(正是 el-dialog 打开的场景),iframe 内跳转自动重挂;产出新增 frameSelector/frameUrl 字段标注元素所属 frame;退出时逐文档清理零残留。

实跑验证:playwright-core + 本机缓存 Chromium 搭自动化测试页(静态 iframe + 动态插入 iframe 两种形态),6 项全绿——顶层拾取回归、iframe 内拾取、frameSelector 标注、样式采集、动态 iframe、退出零残留。commit db82a12,版本 1.1.4。测试脚本用完即删(%TEMP%,不污染仓库)。

打包(21:56)

dist/element-picker-v1.1.4.zip(8 文件,与上架包结构一致,版本号核对),发布指南补"已上架后更新路径"一节。commit c519383。商店侧更新动作(合作伙伴中心传包)归本人手机/网页操作,待做。

关键踩坑

1. 排查类问题先锁定对象再找原因。第一轮把"重启后的 cls 窗口"当成了"退出的窗口",结论方向整个反了。教训:故障对象没确认前,一切归因都是空转。
2. iframe 是事件边界。父文档的 capture 监听也摸不到 iframe 内部事件,"监听挂 document 就全覆盖"是错觉。同源 iframe 要逐文档注入。
3. "无日志"本身就是日志签名。进程消失且四层日志零记录 = 原生层 fail-fast,这个签名可直接拿去匹配已知 issue,比盲猜终端宿主/杀毒高效得多。
4. 随做随 commit 是猝死保险。进程 20:58 死掉时,picker.js 的拖拽修复已落盘待提交,resume 后零损失跑完。只丢当轮,不丢工作。

做得好的地方

• 两条 bug 都走了"现象 → 源码定位 → 修复 → 实跑验证"闭环,bug② 带 6 项自动化断言,无新鲜证据不宣称完成的纪律执行到位;
• 故障台账当晚落两行(初判 → 归因更新),格式合规;
• 本人的三个输入质量都高:现象直给、结构化证据(拾取 JSON)、定性判断("已经发生好几次了")。

复盘与改进

• 本人侧:报"退出了/不工作了"类故障时带一句是哪个窗口/哪个会话,可省一轮误判(本轮误判烧掉约 4 个工具调用);
• AI 侧(CIO 自评):第一轮排查结论下早了——看到 cancelled 就收工,没先反问"退出的是哪个窗口"。排查类任务的纪律应为:先还原时间线、锁定故障对象,再谈归因(此条与 9-29 插件搜不到排查的"先还原时间线"教训同源,属再犯);
• 机制沉淀:kimi export 诊断包导出动作已验证可用,下次复发直接打包附 issue;#3189 跟踪修复版本,升级后回归观察(已入台账规则沉淀栏)。

成长评估

AI 自评失分点:第一轮排查把 cls 会话的 user_cancelled 当主结论输出,未先确认故障对象,被本人当场纠正——方向性误判,属"先还原时间线"纪律的再犯。

指令实证(本期案例库):

1. "这个故障已经发生好几次了,应该是 Kimi code 自己的问题。"→ AI 行为从单次归因切换为模式取证:全量扫描历史会话 state.json + 日志尾行,挖出同日 16:23 第二起同签名猝死,进而命中官方 #3189。结果证据:台账/故障台账.md 第 140 行、commit c3ea51c。
2. (贴拾取 JSON)"这个弹出框里面的元素无法选取。"→ 结构化证据让 AI 跳过"猜原因"环节,直接 grep 源码定位 iframe 根因(matrix/index.vue:167),修复一次到位零返工。结果证据:picker.js v1.1.4、commit db82a12、6 项 PASS 实跑输出。

素材点

• "无日志本身就是日志签名"——原生层 fail-fast 的排查套路,可出 S3 技术稿;
• iframe 事件边界与多文档注入方案,可出 S3 稿(插件开发者受众);
• "随做随 commit 是猝死保险"——今晚实证,可作人机协作纪律的引子;
• Kimi Code #3189 跟踪:修复版本发布后回归验证,可补一条结案素材。