夜雨聆风"让 Adobe Lightroom CC 在 Linux 上跑起来。"
这句话如果放在五年前，任何一个 Linux 桌面用户听到都会会心一笑——然后告诉你别想了。Adobe 从来不为 Linux 开发桌面产品，这已经成了一个被接受的事实，就像冬天会下雪一样自然。
但有个东西不接受这个事实。
2026年5月16日，一个名为 sander110419 的开发者让 Claude Opus 4.7（通过 Claude Code 命令行工具）接受了一个挑战：让 Lightroom CC 在 Linux 上运行。不是通过虚拟机，不是通过双系统，而是直接通过 Wine——那个让 Windows 程序在 Linux 上运行的神奇兼容层。
结果？不到一天时间，Claude Opus 成功了。
而且不仅成功了——它把自己整个调试过程的每一步都记录了下来，写了一个 1750 行的 build history 文档，生成了安装脚本，甚至用截图验证了修复工具的正确性。然后自己在 GitHub 上创建了仓库、写了 README、发布了完整的可复现方案。
这个仓库的每一行代码、每一个补丁、每一个文档——都是 Claude Opus 4.7 自主完成的。
故事的起点并不浪漫。Claude 的第一个尝试——用 2018 年的旧版 Adobe 安装包——直接被一个神秘的 "error code 72" 怼了回来。翻日志发现，安装包是八年前的旧版本，Adobe 的 CDN 已经不再提供它所期望的清单格式了。
一个简单的诊断：老的引导安装器已经过期。方案：下载最新的 Creative Cloud 安装包。
用户 sander 从 Adobe 官网下载了 339MB 的 ACCCx6_9_1_1.zip，解压到 installers/ 目录。Claude 开始了第二次尝试。
白屏——DXVK 的第一个人工制品
新的安装包启动了，比老的好——至少过程推进了。但安装界面显示了一张空白的白色窗口。
不是崩溃，不是报错。就是……白。
Wine 日志里满是:
err: DxgiFactory::CreateSwapChainForComposition: Not implemented成百上千行。
问题是 Adobe Creative Cloud 桌面应用是基于 Electron/WebView2 构建的。WebView2 使用 D3D11 渲染，而 WebView2 在启动时需要调用的 CreateSwapChainForComposition API，在 Wine 里根本没有实现，在 DXVK 2.7.1 里也是一个空存根。
如果是一个人类开发者，到这里可能就要开始搜索 StackOverflow 了。但 Claude 做了另一件事——它直接去读了 DXVK 的源码。
在 src/dxgi/dxgi_factory.cpp 里，它发现了一个隐藏配置项：
dxgi.enableDummyCompositionSwapchain = True这个开关可以让 DXVK 创建一个人工的虚拟 swap chain，让调用者以为一切正常、继续执行。
Claude 写入了 wineprefix/dxvk.conf，重新启动。
日志里的 Not implemented 错误瞬间降到了 零。三行新日志出现：
DxgiFactory::CreateSwapChainForComposition: Creating dummy swap chain安装窗口出现了 Adobe 的 Logo、英雄图、邮箱输入框、"Sign in" 按钮——真正的安装界面终于渲染出来了。
登录即崩溃——一个不存在的 API 引发的连锁灾难
用户 sander 登录了 Adobe 账户。Creative Cloud 加载了个人资料，开始刷新应用列表——然后崩了。
不是一般的崩。是一个三连环的崩塌：
1. Adobe 的 "抱歉，发生错误 / Creative Cloud 遇到问题需要关闭" 2. Wine "关于 'Creative Cloud Helper' 的错误报告" 3. Wine "程序错误" —— node.exe挂了
Creative Cloud 桌面端明明已经完整安装了——只是在运行后崩溃。
Claude 开始分析安装日志。在过滤掉 DXVK、RoGet、预加载等噪声后，一行关键日志浮出水面：
wine: Call from 00006FFFFFC58AD8 to unimplemented function KERNEL32.dll.SetThreadpoolTimerEx, abortingSetThreadpoolTimerEx——Windows 8+ 的一个线程池 API，Wine 11.8 staging 没有实现它。而且 Claude 去验证了 Wine 的上游 master 分支——同样没有实现。对应的 kernelbase.spec 规范文件里，这行被注释掉了：
# @ stub SetThreadpoolTimerEx这意味着在官方 Wine 里这甚至不是一个存根——它根本不存在。
问题来了：是谁在调用这个不存在的函数？
Strings 命令揭开谜底
Claude 对 Wine Prefix 目录下所有 Adobe 的 .dll、.exe 和 .node 文件跑了 strings，搜索引用 SetThreadpoolTimerEx 的文件。
结果只有一个：AdobeGrowthSDK.dll（以及它的 Node.js 版本 growthsdk.node）。
这是一个 Adobe 的 A/B 测试/实验框架——对核心功能完全非必需。
Claude 将三个文件重命名为 .disabled：
• AdobeGrowthSDK.dll→AdobeGrowthSDK.dll.disabled• 另一个同名文件 → .disabled• growthsdk.node→growthsdk.node.disabled
重启 Creative Cloud。
成功。 完整的 CC 界面出现了，应用目录刷新了，没有崩溃，没有 SetThreadpoolTimerEx 错误。
Adobe 的遥测日志确认了：
• signinState = SIGNED_IN_STATE• signinErrorState = IMS_ERROR_NONE• 应用目录成功刷新
用户点击了 "Install" 按钮，Lightroom CC 9.3.1 顺利安装。
又一个经典的 Linux 问题——大小写
Lightroom 安装好了，但启动就失败。
Claude 日志揭示了一个极其经典的 Linux 问题：文件名大小写。
Lightroom 的导入表引用了 agkernel.dll、crclient.dll、vulcanmessage5.dll，但 Adobe 实际安装的文件是 AgKernel.dll、CRClient.dll、VulcanMessage5.dll。
Windows 不关心大小写。Linux 关心。Wine 的 PE 加载器在 Linux 上是大小写敏感的。所以——文件"找不到"。
解决方案简单但繁琐：为 Lightroom 目录下的每一个 DLL 和 EXE 创建小写符号链接。
Claude 写了一个脚本自动完成了这件事。然后是第二个缺失 DLL 的问题——NDFAPI.DLL、wkscli.dll 和其他几个 Wine 11.8 不提供但 Lightroom 静态导入的库。
解决方案：创建最小的存根 DLL，只导出需要的函数但不实现——够用就行。
色彩管理的深渊——Direct2D 的 CLSID 迷宫
这可能是整个项目中最精妙的技术坑。
Lightroom CC 严重依赖 Direct2D 进行图像渲染。具体来说，它在编辑照片时需要调用 Direct2D 的颜色管理效果（CLSID_D2D1ColorManagement）。
但 Wine 的 d2d1.dll 没有注册这个效果。
Claude 做了一件事：它对 Lightroom 目录下所有二进制文件进行了一次 D2D 内置效果 CLSID 扫描，找出 Lightroom 实际使用了哪些 Direct2D 效果。输出文件 lr-d2d-effects.txt 包含了扫描结果。
然后，它基于 Wine 的 d2d1.dll 源码，打了一个补丁——注册了 CLSID_D2D1ColorManagement 内置效果。编译了一个修补版的 d2d1.dll。
Lightroom 的编辑面板终于渲染出了颜色——但还没完。
修复工具——最后的 Boss 战
Lightroom CC 的 "Remove / Heal"（移除/修复）工具一直崩溃。这个工具允许用户在照片上涂抹、去除瑕疵——是摄影师日常使用最频繁的功能之一。
Claude 开始新一轮的故障诊断。它做了以下几件事：
1. 对比导出表——将 Wine 内置的 mfplat.dll、Proton 的版本和 Adobe 自带的版本的导出函数做了逐一对比2. 定位缺失函数——发现 Adobe 自带的 mfplat.dll缺少MFCreateSampleCopierMFT，而 Wine 的 Media Foundation 流处理器的延迟加载需要这个函数3. 直接二进制补丁——Claude 写了一个 patch_mfplat.py脚本，给mfplat.dll追加了一个新的 PE 节区，包含所有原始导出函数外加转发到mf.MFCreateSampleCopierMFT的转发器
然后就是验证。Claude 写了一个自动化验证流程：
• 用 ImageMagick 的 import命令截屏• 用 Pillow 库进行像素级检测，定位 UI 元素 • 用 xdotool驱动鼠标点击 Remove 工具• 观察是否出现修复工具弹窗，还是出现了 Crash Dump
前几次点击总是偏了几个像素——图标坐标检测在几次迭代中都有 off-by-one 偏差。Claude 重新截图、重新运行检测器、调整坐标、再重试——完全自主。
然后它发现了一个更隐蔽的问题：修补了 wineprefix/system32/mfplat.dll，但 Lightroom 根本没加载这个修补版本。因为 Adobe 自带的 mfplat.dll 在 Lightroom 安装目录里，而 Windows DLL 搜索顺序优先使用应用目录的版本。
Claude 将修补后的 DLL 复制到了 Adobe 的安装目录，重新启动 Lightroom，再次点击 Remove 工具流程。
截图确认："Remove the way you want" —— 修复工具弹窗出现了。"Try it now" —— 画笔 UI 加载了。笔触注册成功。"Remove" 按钮应用修复——没有崩溃。
不仅仅是成功——是完整的、可复现的方案
最终结果不是一个破解包。它是一个完整的项目：
• 一个全自动安装脚本 scripts/setup.sh• 步步有回滚说明的 GUIDE.md（每个补丁解释了解决了什么 Wine 的缺陷、如何回滚）• 每一步 Wine 的应用户、每一次截图都在 screenshots/目录里存档• KNOWN_ISSUES.md诚实记录了还有哪些缺陷• 1750 行的 history_methodology.md—— 整个调试旅程的完整历史
每一个修补过的 DLL 的 MD5 都记录在文档里，确保二进制是完全可验证的。
这意味着什么？
这个故事最重要的不是 "Lightroom 在 Linux 上能跑了"——虽然这本身就很酷。
真正让人不安（或者说兴奋）的是这个事实：整个项目是 AI 自主完成的。
从分析崩溃日志、阅读 Wine 源码、在 PE 二进制文件中定位缺失函数、编写二进制补丁、到通过截屏进行视觉验证——Claude Opus 4.7 展示了 AI 作为软件工程师的完整工作流：
• 🎯 目标设定：由人类（"让 Lightroom 在 Linux 上运行"） • 🔍 诊断：阅读日志、对比导出表、strings 扫描——AI 自主完成 • 🧪 验证：截屏 + 像素检测 + 鼠标驱动——AI 编写测试流程并反复迭代 • 📝 文档：把每一步的思维过程和决策完整记录下来——AI 写的比很多人类工程师还详细 • 📦 发布：GitHub 仓库、README、安装脚本——AI 一手包办
"Vibecoding" 这个词最近在开发者社区很火。但这个项目展示了真正的下一级别——AI 不只是写代码，而是作为一个完整的软件工程师在运作：调试、逆向工程、补丁、验证、发布。
那个让 Linux 用户头疼了十几年的"Adobe 不支持 Linux"问题，被一个 AI 花了一天时间解决了。
也许我们真的不应该再问"这个能在 Linux 上跑吗"。
我们应该问："AI 能不能让它跑起来？"
参考链接：
• GitHub: sander110419/lightroom-cc-on-linux[1] • PhialsBasement/wine-adobe-installers[2] • Claude Code[3]
引用链接
[1] GitHub: sander110419/lightroom-cc-on-linux: https://github.com/sander110419/lightroom-cc-on-linux[2] PhialsBasement/wine-adobe-installers: https://github.com/PhialsBasement/wine-adobe-installers[3] Claude Code: https://claude.com/claude-code
