Kimi K3 修Bug 越修越多

之前拿 K3 测过不少前端项目，也试过基于不太理想的结果反复迭代，最终效果还不错。甚至让它重构过一万行的单文件代码。整体来说，表现都还不错。

但今天这个项目，似乎翻车了。这次测试的核心，是让它修改一个真实的 Bug。

前段时间开发了一个图片生成和编辑软件，叫 JImage。软件里有个模仿 QQ 截图的功能，遗留了一个截图错位的 Bug。这个 Bug 有点难度，之前 Opus 4.8 改了一轮没改出来，后来是让 Fable 5 搞定的。于是把修改前的代码提取出来，直接让 Kimi K3 来改一次。

刚开始还挺顺利，但改完 Bug 时引入了 3 个小问题。接着让它帮忙修复，结果越改越乱，最后兜不住了。下面来看完整过程。

核心需求

截图功能存在两个明显问题：覆盖层与桌面错位、悬停自动选中窗口无效。要求分析实现方式并重构，做到「准确、完整、丝滑，接近 QQ 截图」。

这里最难最关键的就是修复错位问题。

可以用上面的图片演示一下：

比如黄色框就是整个屏幕，红色框就是截图软件选中的全屏。很明显，选中的区域和实际的屏幕区域有一个明显的错位。这次重点就是解决这个问题，让红色框跟黄色框重叠就可以了。

这个问题看起来很简单，但由于 DPI、边框、阴影、自定义主题窗口、圆角这些因素的影响，导致 AI 无法简单判断边缘，所以出现了一点点难度。这已经不单单是一个前端页面的问题了，而是和操作系统、窗口机制息息相关。

说清楚了，就可以往下看了。

轮次 1：启动开发环境

测试的技术方案支持热更新，为了方便观察，先让模型启动开发环境。

需求：启动 JImage 的 dev。

处理：后台运行 pnpm tauri:dev。

结果：启动成功，全程作为后续改动的热重载环境。

这一步没有难度，轻松搞定。

轮次 2：错位 + 窗口识别

启动之后，进入正题，解决两个核心问题。

需求：修复错位与窗口自动识别，接近 QQ 截图。

分析：

错位根因：覆盖层用 set_position+set_size(PhysicalSize) 手动摆放，Windows 下与显示器物理矩形存在 DPI 取整或隐形边框偏差。识别失效根因：collect_windows 在覆盖层显示之后枚举，置顶全屏的覆盖层自身位于 z 序最顶，hover 永远先命中自己；且 xcap 矩形含 DWM 隐形边框（约 8px 偏移）。

处理：

覆盖层改 set_fullscreen(true)（后被证明不可靠，见轮次 5）。窗口枚举改 Win32 EnumWindows + DWMWA_EXTENDED_FRAME_BOUNDS（可见框架，QQ 同款），过滤不可见或 cloaked 或工具窗口，按进程排除自己；枚举时序移到覆盖层显示之前。前端：物理到 CSS 换算改用 devicePixelRatio；canvas 后备缓冲按截图物理尺寸分配；mousemove 改 requestAnimationFrame 合帧。Cargo.toml 新增 windows 依赖。

结果：编译通过。为后续轮次打下基础，但全屏方案埋了新问题。

这一轮整体表现不错。原因分析和处理，说得头头是道，结果确实有明显改善。

全屏截图已经没有错位了，移动到某个窗口，自动用虚线框选中也 OK 了。这个时候已经开始感叹了，K3 果然有点东西，能一次定位和修改这两个点，确实很厉害。

但是，发现了 3 个小问题，所以再让模型优化一下。

轮次 3：全屏实线框 + 取消时桌面抖动

上面说的三个小问题，主要就是全屏预选状态下没有任何标识，要求它显示一个虚线框。另一个问题是无法选中它自己。还有一个问题：当点击选中某个区域，按 Esc 取消，窗口会抖动。

这一轮主要让它解决这三个问题。

需求：

①确认软件自身窗口是否排除；

②未悬停窗口时（默认全屏）应显示全屏实线框；

③Esc 取消时桌面会抖一下。

处理：

①已按 PID 排除（后被轮次 7 改为主窗口可选）。

②hover 全屏时补画 2px 实线框（内缩 1px）。

③退出顺序从「先退全屏再隐藏」改为「先隐藏再退全屏」。

结果：实线框补上；抖动有所缓解（根子在轮次 4 进一步处理）。

这一轮整体解决得还可以，但有一步会错了意。问它为什么不能选中自己，而它却理解成了要排除自己。

就像问它：「你为什么不能考个 100 分呢？」它特意考了个 99 分。

这理解能力，有点过分了。

刚开始，都没看明白，以为它改掉了，后来才发现这个问题还在。

除了解决上面几个问题之外，它突然引入了另一个问题。当按下截图快捷键之后，突然出现了一个 1/4 屏幕的透明层。

这个不影响使用，但视觉上有影响，必须修复。

轮次 4-6：1/4 半透明层

让它分析了这个透明层的问题。

需求：准备截图时左上角出现一个半透明小窗。

分析：预热窗口是停在屏幕外的 200×200 小窗，激活时「显示到全屏」过渡瞬间小窗闪现在左上角。

处理：预热窗口直接按主显示器尺寸创建并隐藏在主屏原位；取消时只 hide() 不退出全屏，覆盖层常驻全屏状态。

结果：编译通过，但该方案依赖 set_fullscreen，问题未根除（见轮次 5）。

它好像也没说自己不知道，说得头头是道，听起来也挺有道理。但实际上，它并没有解决这个问题。而且这个问题持续了大概 3 轮对话才最终解决。

解决之后呢，又突然引入了一堆新问题。把最初要改的这个问题又给整出来了，而且更严重。

轮次 7：边框问题再现

这一次出现了一大堆问题。最早是让它解决截图框和全屏框的错位问题。现在又出现了截图框比全屏框小的问题。只有顶部那条线是对齐的，左边、右边、下边都出现了空位。

更离谱的是，窗口自动选择的选择框也出现了问题。很明显是大小和位置都不匹配了。

这就很难受了，到这一步，感觉它已经脑子不太好使了。但还是想试着让它改一下。

需求：

①覆盖层边缘出现圆角，全屏框包不满桌面；

②窗口虚线框与软件边缘错位；

③JImage 主窗口无法选中。

分析：

①Win11 DWM 默认给所有顶层窗口削圆角，四角露出桌面。

②DWMWA_EXTENDED_FRAME_BOUNDS 取径失败时回退 GetWindowRect（含 8px 隐形边框）会错位。

③此前按 PID 排除了整个进程。

处理：

①覆盖层设 DWMWA_WINDOW_CORNER_PREFERENCE = DONOTROUND。

②加逐窗口日志（标题、矩形、取径）+ 前端打印 CSS 矩形与 dpr，用于定位。

③改为只按 HWND 排除覆盖层自身，主窗口恢复可选。

结果：

主窗口可选。

未解决：全屏选择时上下仍有空隙；窗口预选框偏移，下方和右侧有空隙。

从处理记录中可以看到，关于第②点，它是加了一个日志进行定位。也就是说，以它当前的认知和理解能力，已经无法直接定位这个问题了，必须要通过日志来定位。

经验表明，一旦到这个地步，后面解决这个问题就有点麻烦了。除了麻烦之外，重点是会消耗大量大量的 Token，这些 Token 本来都是不应该产生的。

鉴于这种情况，不太想浪费时间了，所以让它停，先让它记录一下之前改的那些内容。让它记录完内容之后，再死马当活马医，让它继续修这个 Bug。果不其然，它一直在某个陷阱里反复地徘徊，浪费 Token。

看了一下它的上下文，大概才用了 14 万，按理说就这点东西，应该不会出现降智。那么可能遇到的只是它的盲区了。

因为这个代码本来就是 AI 写的，然后 AI 兜不住了，这个时候就会很无助。反复地跟它磨，是有可能走出这个困境的，但会消耗巨多的 Token 和时间。

同样的问题，Claude 是两轮解决的。一轮解决一个问题，没有反复。

所以辩证地看，Claude 家的模型可能才是真的性价比模型。

平时都在比说一次调用 Token 要多少钱，但现实中，关键点是：解决一个问题要多少钱。

那 Opus 可能一次就解决了，而另外一个模型很便宜，但它需要 10 次才能解决。那最终算下来，Opus 更有性价比。

如果要 10 次才能解决，消耗的不光是 Token，还有时间和精力。如果每个问题都是差 10 次，那 10 个问题就差 100 次了。而这 10 个问题可能相互独立的，也可能是相互关联的。最终的差距就很难估算了。

都在说 K3 牛逼，这篇文章，就当是给大家降降温吧。

这不是一个测试题目，而是一个实实在在的问题，不解决，功能就有缺陷，解决了，就可以安心搞其它功能了。