用 AI 给没有 Linux 驱动的硬件写驱动：一个人几天做完过去几周的活

起因是一台底片扫描仪

Christian Schaller 整理母亲遗物时拿到一箱旧底片，买了一台 Plustek OpticFilm 8200i——买之前专门确认过它在 Linux 下有支持。结果这个型号的芯片组换成了 Genesys GL128（USB 07b3:1825），新芯片没有 Linux 驱动。他试过用 AI 写驱动，卡了很久，项目搁置了几个月。

转折点：让 AI 看着 Windows 干活

转机来自社区里的一次分享：开发者 Glorious Eggroll 用 AI 修好了鼠标驱动，做法是给 agent 一个完整的 Windows 环境去抓数据。Schaller 把这个思路搬到扫描仪上：在虚拟机里跑厂商的 Windows 驱动，把真实设备直通给虚拟机。几个小时后，他在 Linux 下完成了第一次扫描，画质还有瑕疵，但“能看出那是负片上的那张照片”。再过几天，驱动接近可用，连红外扫描也支持了。

故事的结尾有点好笑：他动手之后才发现，SANE 上游已经有人提交了这款扫描仪的代码。他对比了两个实现——解析细节一致，全分辨率下他的版本 34.6 秒、上游 54.4 秒，另外多一个红外除尘；单机单帧的一次测量，只能当参考数据。他把整套方法整理成通用工具 hw-harness 公开了出来。

这套方法其实只有四步

第一步，在 KVM 虚拟机里跑厂商的 Windows 驱动，把设备直通给虚拟机，录一次参考操作；第二步，在 Linux 宿主上用 usbmon 抓包——它位于直通层下面，虚拟机看不到它；第三步，在 Linux 下用自己的驱动做同样的操作，同样抓包；第四步，对比两份记录：同一个仪器抓的，可以直接比较，差异就是缺陷清单。

对没有总线可抓的设备，比如笔记本内置的 MIPI 摄像头，就换成 Windows 侧的信息检查：INF 文件、注册表、ACPI 表、设备属性。作者强调了一个边界——这套做法不复制任何代码，只是观察硬件行为、从 Windows 驱动里提取配置数据，新驱动里的每个常量都能追溯到某条记录。

另一个战果：把笔记本摄像头救回来

他把同一套 harness 用在 ThinkPad X1 Carbon Gen 14 的 MIPI 摄像头上（索尼 IMX471 传感器 + Intel IPU7）。Linux 下画面很暗、暗角重、偏黄绿。查出的问题相当具体：内核驱动里，裁剪选择在保存裁剪矩形之前就返回了错误，导致 libcamera 按全像素阵列处理；测试图寄存器的位宽声明错了；模拟增益上限设得太低，损失约 1.8 档灵敏度。libcamera 的软件 ISP 一侧则完全没有镜头阴影校正，四角暗了约 2.7 档；白平衡统计按传感器原生位深求和，却对着 8 位黑电平去比。

修复后在受控低光测试里，画面亮度从 31.1 升到 90.9，红绿比与蓝绿比从 0.890 / 0.672 变成 1.047 / 0.823，接近 USB 摄像头的参考值；低光下蓝色仍差约 17%，他归因于灰度世界白平衡。内核补丁与 libcamera 补丁都已提交。

他总结的三条经验，也适合交付团队

第一，参考抓包价值最大，它把“它不工作”变成一份具体的差异清单——AI 最擅长在这类枯燥活里出力：读几千行 USB 记录、发现重复序列里只有一个字节在变、写出验证假设的测试。第二，AI 干的是苦力，硬件得人守着，决定做什么和在真机验证都还是人的事。第三，真机是唯一的裁判。

对做交付的小团队，这里有个可以直接照抄的分工：把需要耐心和逐项对齐的重复劳动交给 AI（日志比对、抓包分析、常量交叉核对），把“做什么”和“验收”留在人这一侧。作者自己也说得很实在——他并没有深厚的固件功底，仍然把这件事推到了能用。