一个游戏引擎的点击事件失效了。五个主流AI模型审查过代码，都说没问题。最后，作者自己动手修好了。

这是Limn Engine开发过程中的一个小插曲，也是一个关于"AI盲区"的真实案例。

打开网易新闻 查看精彩图片

藏在屏幕坐标里的Bug

Limn Engine是作者花了数月时间打造的游戏引擎。他在Chromebook、一台4GB内存的东芝笔记本、一台HP笔记本（背着姐姐用的），以及一台只有1GB内存的Tecno Pop 4上做了测试。引擎表现不错——低端硬件上能跑60帧，移动流畅，响应灵敏。

但有个问题：当摄像机移动时，点击事件就不工作了。

在测试一个带滚动地图的游戏时，作者发现，当摄像机位于(0,0)位置时，点击物体一切正常。但一旦摄像机跟随玩家移动，点击就失灵了。屏幕上明明显示着物体，却点不中。

五个AI都没看出问题

在此之前，作者已经把Limn Engine的完整代码库提交给五个主流AI模型——DeepSeek、ChatGPT、Claude、Gemini和Grok——进行评估和分析。它们都审查了代码，给出了反馈，帮助优化了引擎。

但没有一个注意到这个点击Bug。

五个模型都给Limn Engine打了88/100到94/100的评分，称赞了双渲染器系统、直观的API、完善的文档，以及delta time修复。但点击Bug，它们全都漏掉了。

它们都看了clicked()方法，说代码看起来没问题。它们没有考虑到：鼠标位置在屏幕空间，而组件位置在世界空间。

问题出在哪

当摄像机在(0,0)时，屏幕空间和世界空间是重合的。但当摄像机移动——比如移到(100,100)——两者的关系就变了。

修复前的代码里，鼠标事件监听器获取的是e.pageX和e.pageY，这是屏幕空间的坐标。而在clicked()方法中，计算旋转偏移时使用的display.x和display.y同样来自屏幕空间。

但组件的位置this.x和this.y，是世界空间的坐标。摄像机一移动，两个空间就分道扬镳，点击自然就失灵了。

为什么AI都没发现

作者问了五个AI模型，它们都漏掉了同一个关键问题：没有人问一句"等等，display.x到底是在屏幕空间还是世界空间？"

它们默认代码是正确的，因为它看起来就是标准的点击检测逻辑。但大多数引擎的标准点击检测，其实会自动处理这个坐标转换问题。

最终，作者自己动手修好了这个Bug。

这个故事值得每个依赖AI审查代码的开发者想一想：AI能帮你优化性能、完善文档、发现明显的错误，但有些"隐藏在日常逻辑里"的问题，可能还是得靠人眼去发现。