更引人注目的是,这个项目的大量调试和兼容性研究据称由 Anthropic 的 Claude Opus 4.7(通过 Claude Code AI代理)完成。AI代理分析崩溃日志、探索Wine行为,并逐步构建出可以运行Lightroom的配置。
这个方案并不是让Lightroom“原生支持”Linux,而是使用 Wine 这一兼容层运行 Windows 版本的软件。Wine会把Windows API调用转换为Linux系统调用,从而让很多Windows应用能够在Linux系统上启动。
项目最终形成了一套可复现环境,包括:
根据项目描述,AI代理不断读取程序崩溃日志、尝试配置调整并反复测试,直到Lightroom能够在Wine环境中启动并运行。
目前可运行的组合主要是:
需要注意,这里指的是 基于云同步的Lightroom CC桌面版,而不是Lightroom Classic或其他Adobe创意软件。
项目报告称,大部分核心功能已经可以运行,例如:
不过整体仍处于实验阶段,一些问题仍然存在,例如:
由于依赖Wine兼容层和非官方补丁,不同Linux发行版、驱动或硬件配置可能会出现不同的稳定性表现。
该项目在公开仓库中提供了完整的可复现配置。整体流程大致包括:
仓库文档指出,为了让程序成功启动,需要解决若干“非直观”的兼容问题,例如依赖库处理和启动流程修复。
此前Linux用户如果想使用Lightroom,通常只能通过 Adobe提供的网页版Lightroom。
而这个方案的关键区别在于:
相比浏览器版本,这意味着更接近完整的桌面体验,例如本地文件集成和完整UI。
这项工作的意义不仅在于“Lightroom终于能在Linux跑起来”。更重要的是 解决问题的方式。
根据项目描述,开发者主要设定目标并提供资源,而 AI编码代理负责大量调查和调试工作:
这展示了AI开发工具的一种新用途:帮助解决 复杂的软件兼容问题——尤其是涉及专有软件、缺乏文档依赖和复杂调试过程的场景。
如果类似流程变得普遍,AI编码代理可能会越来越多地参与到以下工作中:
对于依赖专业创意软件的Linux用户来说,这可能显著降低在非官方平台上运行这些工具的技术门槛。
尽管项目引发了社区关注,但仍有几个重要限制:
因此,目前更合理的定位是:一个实验性的社区方案,同时也是AI辅助软件兼容研究的早期案例。