Christian Schaller 記錄了 Windows 驅動程式透過 USB 傳送的內容，讓一台尚未受支援的底片掃描器在 Linux 下產生可辨識的掃描影像。他在10月15日的經驗文章中，描述如何用 Claude 協助分析擷取資料並開發 SANE 後端。首次掃描仍有品質問題；後來他回報，驅動程式已有大幅改善。這是一名開發者與一台掃描器的成果，不是經獨立重現、用來衡量 AI 寫驅動程式成功率的數據。
Schaller 隨後發布了hw-harness，這是一套採 MIT 授權的指令碼與文件，將他的方法通用化。他明確表示，掃描器和相機專案使用的是專門撰寫的程式碼，而不是目前形式的公開 harness。對能實際接觸未受支援 USB 裝置的 Linux 驅動程式開發者而言，實用任務比「讓 AI 反向工程」更具體：用正常運作的廠商驅動程式擷取一項操作，用 Linux 驅動程式擷取同一項操作，再調查第一個有意義的差異。
重大變化
- 有何改變： Schaller 整理出可重複的方法，讓正常運作的 Windows 裝置工作階段與 Linux 驅動程式的嘗試，都由同一個主機端 USB 記錄器觀察。他的掃描器成果說明比較為何可能有用，但仍只是單一回報案例。
- 為何重要： 驅動程式開發者可以把標記清楚的擷取紀錄交給 AI 程式助理，要求提出通訊協定解釋或小型探測程式。接受任何產生的程式碼前，開發者仍需要實體硬體、正常運作的參考操作，以及直接測試。
- 值得留意： 這個方法取決於能否觀察到相關裝置流量。對內建 MIPI 相機，公開的 harness 改用 Windows 裝置設定與 ACPI 檢查；套用 USB 擷取流程，會漏掉開發者需要的資訊。
擷取之前需要什麼
這份hw-harness README表示，專案是在 Fedora 上開發與測試的。文件要求 libvirt/KVM、執行廠商驅動程式的 Windows 客體、真正的 USB 直通、Linux 主機端的 usbmon 擷取，以及可供比較的 Linux 驅動程式或探測程式。Windows 11 Pro 可啟用 harness 以 RDP 為基礎的圖形介面控制。虛擬機器指南表示，Home 版客體仍可使用 SSH，但不能使用那些 RDP 控制。儲存庫列出了 Fedora 套件與群組權限；連接裝置前，應針對已簽出的版本執行 harness doctor，找出缺少的項目。
準備有使用許可的 Windows 安裝與廠商軟體、確切的裝置、可重複操作，以及封包擷取所需空間。預算應考慮虛擬機器、硬體存取、Windows 和自行選用的 AI 服務；儲存庫沒有提供固定的端到端成本。其指令碼採 MIT 授權，不代表授予 Windows 或廠商軟體授權。使用或散布蒐集內容前，請檢視自己的授權條款與適用的反向工程規則。
每個裝置使用獨立專案目錄。README 表示，harness init會建立設定檔，以及被版本控制忽略的 etc/ 和 captures/ 目錄。VM 名稱和 USB 廠商／產品 ID 應取自自己的裝置，不要照抄 README 範例。winctl auth、harness iso 和文件中的客體初始設定流程，可建立 Windows VM 的控制能力；擷取前，winctl status 應回報 ssh: ok。這是專案文件記載的設定，不是 BIG CHANGE 實際執行過的步驟。
在兩個系統上對照同一項操作
- 記錄基線與 Windows 參考。 請依照儲存庫的方法文件：先了解閒置時的流量樣貌。如果需要裝置的初始列舉過程，應在把 USB 裝置交給客體前啟動主機端擷取。在直通裝置上執行廠商 Windows 驅動程式，並標記一項短而明確的動作，例如指定解析度的掃描。
usbcap會擷取匯流排資料，並寫入一份.meta附帶檔案，記錄裝置、匯流排位址、持續時間和標籤。主機端擷取點位於 USB 直通之下，因此可以觀察客體的操作。 - 記錄 Linux 的對應操作。 把裝置交回主機，在相同設定與相同實體素材下，擷取 Linux 驅動程式執行同一項操作的資料。缺少對應 Linux 執行的參考擷取，無法確定哪個驅動動作出現差異。儲存庫的掃描器指令是作者環境的範例，不是所有裝置通用的指令。
- 比較並測試一項假設。 用 Wireshark 或方法文件中的
tshark篩選器閱讀兩份紀錄。檢查初始化傳輸、操作前後的寫入、狀態輪詢，以及大量傳輸的時間關係。每次只改一個設定，例如解析度，觀察哪項傳輸改變。要求 AI 助理指出可能的差異，並引用對應擷取檔與影格。接著進行有限的驅動程式修改或探測，再於實體硬體上重複同一項操作。模型回答中看似合理的解釋，不是成功的訊號。
直接產出是一對有標籤的擷取檔，以及第一個有意義差異的說明。成功修復，需要 Linux 裝置在開發者自己的檢查下，穩定執行預定操作並產生預期輸出。匹配幾個位元組或產生一張不完整影像，不能證明驅動程式的整體品質。Schaller 的文章指出，第一張可辨識影像仍需後續改善；他工作期間，上游 SANE 對該掃描器的支援也另行出現。
若紀錄難以比較，縮短操作，並確認裝置、設定和擷取層一致。方法文件建議以小型擷取回答單一問題，並擷取一次裝置連接過程。若直通或客體控制失敗，先使用 harness doctor、hostdev status 和VM 設定指南，再判斷空白紀錄是否代表驅動程式故障。保留原始擷取與筆記，讓提出的暫存器常數能追溯到觀察到的影格。
USB 擷取的邊界
內建 MIPI 相機不會向主機 USB 記錄器顯露同樣有用的流量。方法文件改以 winctl probe 檢查 Windows PnP 屬性、INF 檔案、登錄項目與 ACPI 表格，並透過 hwdbg 在 Linux 端檢查。Schaller 表示，曾對筆電相機採用這條不同路徑，修改核心與 libcamera；這些成果同樣來自他的自述。不能把相機成果當成 USB 流程在另一台裝置上成功的證據。
調查應聚焦於觀察到的裝置行為與宣告式設定。儲存庫的淨室開發指南排除反組譯廠商二進位檔，或把其程式碼複製到 Linux 驅動程式。指南也提醒，擷取內容可能包含裝置序號，而專案目錄內有 SSH 私密金鑰。交給 AI 服務或公開分享前，應檢查紀錄、裝置識別資訊與客體檔案；金鑰與原始擷取不要納入版本控制。公開指示建立的是一套可以嘗試的方法。BIG CHANGE 檢查了部落格與固定版本的儲存庫，但沒有執行 VM、擷取裝置資料，或驗證產生的驅動程式。
來源與延伸閱讀
- Christian Schaller 10月15日的經驗文章解釋他的掃描器與筆電工作、他認為 Claude 所扮演的角色，以及共用 harness 為何晚於專用指令碼才出現。掃描器成果是他的回報，本文沒有獨立重現。
- hw-harness 儲存庫介紹工具、Fedora 與 Windows 前置條件、設定範例，以及專案隱私警告。BIG CHANGE 查閱的是2026年10月14日的提交
093afc5c576c200f29b771d01624a327d0ff1806；儲存庫採 MIT 授權，該版本之後可能已有變動。 - 方法文件詳述基線、參考操作、Linux 比較與重複測試流程、擷取資料的妥善處理、USB 紀錄閱讀，以及匯流排對主機不可見時的替代路徑。
- Windows 參考 VM 設定涵蓋客體存取、USB 直通，以及 Windows Pro 與 Home 在 RDP 控制上的差異。應檢視自身安裝的授權條款。
- 淨室開發界線說明專案以觀察為基礎的做法、廠商二進位檔的界線，以及記錄常數來源的必要性。這是專案的工程指引，不是法律意見。
