我们之前已经拿 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`依赖。

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

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

全屏截图已经没有错位了，移动到某个窗口，自动用虚线框选中也 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 排除覆盖层自身，主窗口恢复可选。

结果：

✅ 主窗口可选。

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

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

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

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

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

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

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

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

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

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

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

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

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