Kimi K3 修 Bug 实测：从惊艳到翻车

一开始真的很惊艳

在 JImage 截图应用的 Bug 修复实测中，Kimi K3 的开局表现堪称亮眼。面对一个截图偏移的 Bug，K3 准确地定位了问题的根因——坐标计算中某个偏移量的传参顺序错误——并且一次修改就解决了核心问题。生成的代码质量不错，改动范围精准，没有引入额外的问题。这个阶段的表现足以让任何开发者点头：新的 AI 编程工具确实有两把刷子。

然而当测试中发现了 3 个由 K3 的修改引入的小问题后，事情开始急转直下。这 3 个问题本身并不严重——一个边界条件处理不当、一个样式微调、一个日志级别不合适——正常预期是一两轮就能收敛。但 K3 陷入了经典的”修复死循环”：修复问题 A 时引入了问题 B，修复问题 B 时又把问题 C 放大，回头处理问题 C 时，最初那个已经修好的截图偏移 Bug 又回来了，而且比原来更严重。

1/4 透明窗口：三回合的死亡螺旋

最令人沮丧的是那个”1/4 透明窗口”的问题。K3 花了整整 3 个回合在这个问题上打转——每次修改都声称解决了透明度问题，但实际上窗口要么完全透明看不见，要么完全遮挡了底层内容。到了第三轮，K3 干脆放弃了之前的正确修改，把截图偏移的核心逻辑重新写回了错误版本。此时上下文已经膨胀到约 140K tokens，不仅推理质量下降，token 成本也在持续攀升。

这个案例暴露了一个被 AI 编程工具营销话术掩盖的真相：单次调用的价格便宜不等于总体成本低。如果一个模型每次调用只要 $0.01，但需要 10 次重试才能修好一个 Bug，总成本是 $0.10；另一个模型每次调用 $0.05，但一次就修好，总成本是 $0.05。用 token 成本除以解决的问题数量，才是真正的性价比指标。K3 在这个测试中的”每解决一个问题的 token 成本”远高于预期。

Claude Opus 的 2 轮对比：稳定性的价值

同样的 Bug，Claude Opus 用 2 轮就完成了修复——第一轮解决核心问题，第二轮处理边缘情况，没有引入新的 Bug，没有死循环。这个对比不是说 Opus 在所有场景下都比 K3 好，而是揭示了一个重要的评估维度：修复的稳定性。在真实的开发场景中，开发者最怕的不是 AI 一次修不好，而是 AI 修了三次后代码变得更糟、自己不得不花更多时间去理解 AI 到底改了什么。

这个实测最终指向一个结论：在选择 AI 编程工具时，不能只看 Benchmark 分数或单次调用价格。真正重要的是”端到端的问题解决效率”——从提出问题到获得可工作代码，中间需要多少轮交互、消耗多少 tokens、引入多少新的问题。K3 在某些方面确实展现了令人印象深刻的推理能力，但在需要持续稳定输出的长链条任务上，它还需要更多打磨。