Kimi K3 修Bug:越修越多！

K3在多个前端项目中表现优异，甚至能重构万行代码，但今天我们将测试它修复一个真实Bug的能力。此前，K3曾协助完成多项前端测试，并通过迭代将不佳结果提升至理想水平，然而这次的挑战似乎让它遭遇了滑铁卢。

整体来说，K3的过往表现令人满意，但这次测试的核心是让它修复一个实际存在的Bug。

我前段时间开发了一款名为JImage的图片生成与编辑软件，其中包含一个模仿QQ截图的功能，但遗留了一个截图错位的Bug。

这个Bug有一定复杂度，Opus 4.8之前未能修复，后来由Fable 5解决。我将未修改前的代码提取出来，让Kimi K3尝试修复。

K3起初表现良好，但修复Bug时引入了三个小问题。我要求它继续修复，但问题越改越乱，最终失控。

下面展示完整过程。

核心需求

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

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

我可以用上图演示：黄色框代表整个屏幕，红色框是截图软件选中的全屏区域。显然，选中区域与实际屏幕存在明显错位。本次重点就是解决这个问题，让红色框与黄色框重叠。

这个问题看似简单，但由于DPI、边框、阴影、自定义主题窗口、圆角等因素，AI难以简单判断边缘，因此具有一定难度。这已不单是前端页面问题，而是与操作系统和窗口机制密切相关。

清楚问题后，我们开始往下看。

轮次1：启动开发环境

我使用的技术方案支持热更新，为方便观察，我先让K3启动开发环境。

需求：启动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：全屏实线框+取消时桌面抖动

上述三个小问题包括：全屏预选状态无标识，我要求显示虚线框；无法选中软件自身；按Esc取消时窗口抖动。

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

需求：

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

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

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

处理：

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

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

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

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

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

就像我问他：“你为什么不能考个100分呢？”他特意给我考了个99分！

这理解能力有点过分了。

起初我没发现，以为它改好了，后来才知问题仍在。

除了上述问题，它还引入了另一个问题：按下截图快捷键后，突然出现一个1/4屏幕的透明层。

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

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

我要求它分析这个透明层问题。

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

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

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

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

它似乎没有承认自己不知道，分析得头头是道，我也觉得有道理。但实际上问题并未解决，且持续了约三轮对话才最终修复。

解决后又引入了一堆新问题，甚至把最初要改的错位问题重新引发，且更严重。

轮次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次，10个问题就差100次，且这些可能相互关联，最终差距难以估算。

都在说K3厉害，这篇文章就当给大家降降温。

这并非测试，而是必须解决的实际问题——修复它，功能才能完善；否则，将一直存在缺陷。