Kimi K3最新版本修复Bug越修越多现象引发用户热议

此前使用 K3 测试过多项前端项目，即便初始结果不尽如人意，经过反复迭代后最终效果依然不错。甚至曾让它重构过万行级别的单文件代码，整体表现令人满意。

然而，今天这个项目却遭遇了挫折。本次测试的核心任务，是让 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 截图。

分析：

1.错位根因：覆盖层用`set_position+set_size(PhysicalSize)`手动摆放，Windows下与显示器物理矩形存在DPI取整/隐形边框偏差。2.识别失效根因：`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`依赖。

结果：编译通过，为后续轮次奠定了基础，但全屏方案埋下了新的隐患。

这一轮整体表现尚可！原因分析与处理方案条理清晰，实际效果也确实有明显改善。

全屏截图已无错位，移动到某个窗口时，自动用虚线框选中的功能也正常工作了。此时不禁感叹，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 轮对话才最终得以解决。

解决之后，又突然引入了一堆新问题，甚至把最初要修复的 Bug 又给弄了出来，而且情况更严重。

轮次 7：边框错位问题复发

这一次出现了一大堆问题。最初要求修复的是截图框与全屏框的错位，现在又出现了截图框比全屏框小的问题。只有顶部线条对齐，左边、右边、下边都出现了空位。

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

这让人非常头疼，到这一步，感觉模型已经有些混乱了。但还是想尝试让它再修改一下。

需求：

①覆盖层边缘出现圆角，导致全屏框无法包满桌面；

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

③JImage 主窗口无法被选中。

分析：

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

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

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

处理：

①覆盖层设 DWMWA_WINDOW_CORNER_PREFERENCE = DONOTROUND 以取消圆角。

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

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

结果：

✅ 主窗口可选。

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

从处理记录可以看出，针对第 2 点，它添加了日志进行定位。也就是说，以它当前的认知和理解能力，已经无法直接定位问题，必须借助日志。

经验表明，一旦到了这个地步，后续解决这个问题就会变得非常棘手。除了麻烦之外，关键是会消耗大量 Token，而这些 Token 本不应该产生。

鉴于这种情况，不愿再浪费时间，于是让它暂停，先记录之前修改的内容。记录完成后，又抱着死马当活马医的心态让它继续修复 Bug。果不其然，它一直在某个陷阱里反复徘徊，浪费 Token。

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

因为这段代码本身就是 AI 生成的，如今 AI 却无法掌控，此时会感到非常无助。反复与它沟通，是有可能走出困境的，但会消耗巨额 Token 和时间。

同样的问题，Claude 仅用两轮就解决了！一轮解决一个问题，没有反复。

因此，辩证地看，Claude 家的模型或许才是真正具有性价比的模型。

平时大家总在比较一次调用 Token 的价格，但在现实中，关键点在于：解决一个问题需要花费多少钱。

那么，Opus 可能一次就解决了，而另一个模型虽然便宜，却需要 10 次才能解决。最终算下来，Opus 反而更具性价比。

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

大家都在说 K3 很强，这篇文章就当是给大家降降温吧！

这并非一个测试题目，而是一个实实在在的问题。不解决，功能就有缺陷；解决了，就能安心开发其他功能了。