我们之前已经拿 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 截图。
分析：
markdown
1. 错位根因：覆盖层用 `set_position + set_size(PhysicalSize)` 手动摆放，Windows 下与显示器物理矩形存在 DPI 取整/隐形边框偏差。
2. 识别失效根因：`collect_windows` 在覆盖层显示**之后**枚举，置顶全屏的覆盖层自身位于 z 序最顶，hover 永远先命中自己；且 xcap 矩形含 DWM 隐形边框（约 8px 偏移）。处理：
markdown
- 覆盖层改 `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 牛逼，这篇文章，就当是给大家降降温吧！
这个不是一个测试题目，而是一个实实在在的问题，不解决，功能就有缺陷，解决了，就可以安心搞其它功能了。