一个老牌模拟器项目里，AI 最近没有写炫目的新功能。

它钻进了更脏、更难、更不讨好的地方：Power Macintosh 和 Pippin 的旧硬件兼容性泥潭。

这事最有意思的点也在这里。Claude Code、GPT/Codex 确实帮 MAME 开发者连续挖出了一串老 bug，涉及 PowerPC、6522 VIA、PCI Mac 硬件、FPU、SANE 浮点库。但它们没有“接管 MAME”。真正把线索变成修复的人，还是资深维护者。

这比“AI 会不会替代程序员”那套口水仗更有价值。它给了一个更现实的答案：AI 已经能放大专家的调试能力，但还不能替专家承担判断、维护和责任。

这轮进展：不是完整支持，是把机器从黑箱里拽出来

MAME 的 Power Macintosh 模拟长期难推进，不是因为没人愿意做。

难点很具体：PowerPC、模拟 680x0、编译后的 FORTH、旧 Mac 总线、固件路径、驱动细节，全混在一起。一个标志位不对，机器就可能沉默。

这次 AI 参与的工作也很具体：生成 Lua 启动脚本，改 MAME 打日志，分析固件和内存映射，追踪子程序，提出可能的 bug 线索。

结果不是“Power Macintosh 和 Pippin 已经完整可用”。目前只能说，几个关键启动阶段被推进了。

对象关键问题目前推进到哪里
Pippin6522 VIA 与 Cuda 68HC05 通信异常，另有 PowerPC 与 PCI Mac 支持问题能播放启动声，显示 P!P P!N logo，鼠标可移动
Power Macintosh 7200PowerPC 601 模拟中的两个 bug点亮主屏，进入启动找盘界面，后来补上闪烁问号
Power Macintosh 6100System 7.5.x 使用原生 PowerPC SCSI Manager，暴露原子 load/store 模拟错误System 7.5.3/7.5.5 可启动到 Finder
Graphing CalculatorFPU 指令没有更新状态标志，影响 Apple SANE 浮点库2D 自演示恢复；后续 3D 也因 601 对齐异常修复而可工作

这些不是普通网页应用里的“按钮没响应”。

模拟器里的 bug 常常没有清晰报错。你看到的可能只是黑屏、卡住、没声音、找不到磁盘。真正的问题藏在 CPU 异常、总线时序、浮点状态、驱动调用链里。

AI 在这里有用，因为它能快速扫大面积材料。日志、二进制、固件片段、内存结构，它都能帮你先过一遍。GPT/Codex 和 Claude 还能给出一些初始逆向判断，比如识别某个结构像 QuickDraw GrafPort。

但关键词是“初始”。不是定案。

真正的分水岭：专家加 AI，而不是 vibe code

我更在意的是这个细节：AI 找到了很多 bug，但大多数修复由开发者自己写。

少数一行改动，也会被维护者按项目风格和命名重新整理。这个动作很小，却很说明问题。

AI 擅长扩大搜索半径。尤其在模拟器、固件逆向、老硬件调试这种领域，它像一台不知疲倦的日志筛选机。它能把可疑路径先翻出来，把人从重复搜索里解放一部分。

“工欲善其事，必先利其器。”这句话放在这里很准。AI 是利器，但不是主心骨。

原作者也说得很清楚：AI 会追着理论上可能、实际不太可能的问题跑偏。他多次打断它。更要命的是，维护者几乎总是对的。

这不是贬低 AI。恰恰相反，这是 AI 编程工具目前最扎实的用法。

问题不在它会不会写代码，而在它能不能进一个有经验的人类闭环。没有闭环，AI 的勤奋会变成噪声。它越能生成，越可能把维护者拖进审稿地狱。

对两类人影响最直接。

人群该怎么调整
模拟器、逆向、底层开发者可以把 AI 接进日志、固件分析、测试脚本和假设生成环节，但不要把最终判断外包
开源维护者需要更早声明提交标准：能解释、能复现、能维护，才有资格进代码库

这也是很多“AI 写代码”宣传里缺的一环。

商业演示喜欢展示从提示词到功能上线。开源维护者面对的是另一种现实：代码会留下来，bug 会传染，没人理解的补丁会在几年后变成债。

MAME 这种项目尤其怕这个。

一个 CPU 标志位、一个原子指令、一个 FPU 状态更新，今天影响 PowerMac 6100 能不能进 Finder，明天可能影响别的机器、别的系统、别的驱动。维护者不能只看“这次跑通了”。他还得问：为什么跑通？会不会破坏别处？以后谁看得懂？

所以 MAME 不欢迎无法理解和维护的 vibe code，这一点并不保守。

这是一种工程卫生。

接下来该看什么：不是 AI 多会写，而是人怎么验

这轮故事不该被读成“Claude 修好了旧 Mac”。更准确的说法是：资深维护者把 AI 接进调试闭环，让多年没照亮的角落露出了裂缝。

这已经很重要。

但接下来真正该看的，不是模型还能不能多猜几个 bug。要看三个更硬的变量。

一是修复能不能稳定进入主线，而不是停在实验性推进。

二是这些修复会不会带来回归问题。老硬件模拟常有连锁反应，改对一台机器，不等于没伤到另一台。

三是开源项目会怎样处理 AI 辅助提交。MAME 目前没有正式 AI policy，但现实压力已经来了：维护者需要区分“AI 帮你找到线索”和“AI 替你写了一段你也不懂的代码”。

这条线必须画清楚。

扯远一点，早期显微镜没有替医生治病，但它改变了医生能看见什么。AI 编程工具现在更像这个阶段。它把肉眼看不清的路径放大，却不能替人判断病灶。

放回 MAME 这件事，结论很朴素：AI 能帮专家更快走到问题边上，但最后那一刀，还得懂系统的人下。

模型看着更强，产品宣传反而常常更虚。只有落到专家闭环里，AI 编程才有重量。

开头那个反常点也就回来了：AI 在这次 MAME 调试里最有价值的地方，不是写了多少代码，而是让人更快看见旧机器为什么不醒。