macOS Tahoe 26 科研軟體相容性測試：2026 驗收清單

先定義科研軟體驗收的通過條件

啟動成功只表示安裝入口和最基本的執行路徑可用，不能證明完整科研工作流程已經相容。驗收時應把狀態拆成四層：

• 可安裝：安裝器、套件管理器或壓縮檔可以完成部署。
• 可執行：圖形介面、命令列工具、背景工作和重啟後服務可以運作。
• 結果正確：固定輸入資料產生的輸出、日誌和關鍵統計值符合預期。
• 穩定可重現：在相同版本、依賴和命令下，其他成員能重新得到可接受的結果。

測試開始前，先建立一份最小驗收包，至少包含：

1. 固定的樣例資料與檔案雜湊值。
2. 原有 Linux 或 Windows 環境的參考輸出。
3. 預期輸出檔、日誌格式與必要的隨機種子。
4. 失敗判定條件，例如缺少檔案、插件無法載入或結果欄位消失。
5. macOS Tahoe 26 的完整版本號，以及科研軟體和依賴的精確版本。

不要只記錄「最新版」。Apple 的發布說明本身也會按 macOS 小版本列出 API 變更、已知問題和修正內容，因此系統版本與科研軟體版本必須分開記錄。macOS Tahoe 26 發布說明

Apple Silicon 與二進位檔案證據

如何判斷科研軟體是否原生支援 Apple Silicon

驗收重點不是只看主程式，而是把主程式、命令列工具、動態函式庫、插件和外部執行檔逐一取證。可在終端機執行：

uname -m
file /Applications/ResearchTool.app/Contents/MacOS/ResearchTool
file "$(which research-cli)"

典型輸出可能是：

arm64
... Mach-O 64-bit executable arm64
... Mach-O 64-bit executable x86_64

若工具輸出 arm64，代表該檔案具備 Apple Silicon 原生切片；若輸出 x86_64，則需要在 Apple Silicon 上透過 Rosetta 執行；若顯示 universal，仍要確認實際啟動的是哪個切片。Apple 的通用二進位文件指出，通用二進位可同時包含 arm64 和 x86_64，系統在 Apple Silicon 上通常優先執行原生切片。建立通用 macOS 二進位檔

Rosetta 不是「所有 Intel 依賴都會自動解決」的保證。它可以轉譯一般 x86_64 指令，但不能轉譯核心擴充功能、用於虛擬化 x86_64 平台的虛擬機器程式，也不支援 AVX512 指令執行。Rosetta 轉譯環境說明

因此，驗收記錄應明確寫出：

• 主程式是否原生執行。
• 命令列工具是否仍依賴 Rosetta。
• 動態函式庫和插件是否與目前程序架構一致。
• 是否出現 mach-o file, but is an incompatible architecture、連結失敗或插件消失。
• 同一流程在原生和 Rosetta 模式下是否都能完成。

若程式由多個元件組成，主程式是 arm64 並不代表整個科研工作流已原生化。常見的隱性問題是插件、編譯器、數值函式庫或外部命令仍停留在 x86_64。

系統版本、權限與依賴邊界

Apple 已公布 macOS Tahoe 26 的支援機型，但「Mac 可以安裝 Tahoe 26」與「某科研軟體已獲官方支援」是兩個不同結論。macOS Tahoe 26 支援機型清單

安裝與首次啟動應按以下順序記錄：

1. 記下完整 macOS 版本、處理器架構與主機名稱。
2. 記錄安裝器類型，是 .pkg、.dmg、App Store 應用程式還是命令列部署。
3. 執行首次啟動，觀察檔案、資料夾、麥克風、相機或輔助使用權限提示。
4. 分別測試圖形介面啟動、命令列呼叫、背景任務和重啟後狀態。
5. 保存系統安全機制攔截時的原始提示，不要只寫「權限問題」。
6. 對每一項外部依賴記錄來源、版本與架構，並保存鎖定檔案。

如果必須使用解除隔離、允許系統擴充功能或其他安全例外，驗收報告應同時寫明官方依據、適用版本與撤銷方法。沒有官方文件支持的繞過方式，不應列入正式交付流程。

計算結果與跨平台復現

科研軟體跨平台結果不一致的排查順序

先不要急著把差異歸因於 Apple Silicon。應按由容易驗證到難以驗證的順序排查：

• 輸入資料是否完全相同，包含編碼、排序、換行格式與缺失值處理。
• 軟體版本、插件版本與外部函式庫是否一致。
• 執行命令、工作目錄、環境變數和隨機種子是否一致。
• 編譯器、數值函式庫及執行緒設定是否不同。
• 輸出是否只是浮點捨入差異，還是已改變分類、峰值、顯著性或其他科研結論。
• 日誌是否在錯誤發生前已出現警告、回退到替代演算法或跳過某個步驟。

跨平台驗收不應在缺乏軟體官方依據時擅自套用一個通用誤差門檻。對部分數值分析而言，細微浮點差異可能正常；對基因型判定、訊號峰值或模型分類而言，微小差異也可能影響後續結論。應使用該科研軟體或研究方法本身定義的判定規則。

最少保留以下復核證據：

sw_vers
uname -m
python3 --version
R --version
printenv | sort
shasum -a 256 sample-input.dat

命令輸出、依賴鎖定檔、完整執行命令與輸出檔雜湊值，應與參考環境一併保存。這比單純截取成功畫面更能支援日後的科研軟體驗收。

圖形互動、檔案傳輸與遠端限制

遠端環境的驗收不能只確認應用程式視窗能否開啟。實際科研流程還要測試：

• 終端機工作是否能在圖形連線中斷後繼續。
• 剪貼簿能否傳遞命令和少量結果。
• 大型輸入與輸出檔案能否可靠上傳、下載及校驗。
• VNC 或網頁控制台斷線後，是否能重新查看正在執行的工作。
• 圖形介面中的縮放、拖曳、快捷鍵和檔案選擇器是否正常。
• 背景任務是否依賴登入中的使用者工作階段。

自動化 macOS 測試可以檢查建置、單元測試、命令列流程和部分整合測試，但不能等同於真實 Mac 的完整驗收。官方託管 runner 也會按架構提供不同執行環境，某些社群動作可能未完全適配 arm64；這類限制應以當期文件為準。macOS runner 架構與限制

音訊介面、USB 儀器、序列埠、特殊顯示器、硬體加速和實驗室設備則要另外標註。遠端 Mac 可以驗證軟體本身的啟動、檔案和計算流程，但不一定能等價模擬現場儀器的驅動程式、低延遲連線或實體按鍵。

長時間任務與穩定性證據

穩定性驗收至少要同時包含短任務和代表性長任務。短任務用來快速發現啟動、依賴與輸入問題；長任務則觀察：

• 程式是否中途崩潰。
• 記憶體使用量是否持續增加。
• 休眠、鎖定或網路斷線後工作是否中止。
• 日誌是否完整寫入。
• 任務完成後輸出檔是否可讀且雜湊值一致。
• 重新連線後能否查看狀態，而不是只能重新開始。

如果任務依賴終端機工作階段，可使用 tmux 或其他符合課題組規範的工作管理方式；如果由背景服務執行，則應保存服務狀態與日誌。官方自託管 runner 文件也建議從服務狀態、連線情況和工作日誌分開排查執行問題。macOS 自託管 runner 監控文件

放行決策與本週執行分支

驗收完成後，不要只寫「通過」或「失敗」，可使用以下決策條件：

• 若主程式、命令列工具、函式庫和插件均通過架構檢查，依賴可重現，核心結果與參考環境一致，且斷線後任務可恢復，則選「通過」。
• 若只有 Rosetta 或特定權限例外仍存在，但結果、日誌和穩定性已證實符合研究要求，則選「附條件通過」，並記下限制、負責人和重新驗證觸發條件。
• 若核心插件無法載入、結果改變且無法解釋、長任務會中止，或必要儀器無法連線，則選「暫不通過」，回退到現有 Linux/Windows 環境、保留舊系統，或等待依賴更新。
• 若實驗室沒有真實 Mac，則先用自動化流程篩查安裝與命令列問題，再啟用具完整權限的遠端 Mac 完成圖形、架構、結果和斷線復測。

本週最有效的動作不是先升級全部設備，而是建立一份可重複的驗收記錄：

測試日期：
macOS 完整版本：
Mac 處理器與架構：
科研軟體版本：
依賴與插件版本：
輸入資料雜湊：
參考環境與輸出：
Apple Silicon / Rosetta 狀態：
權限與安全提示原文：
圖形、終端與檔案傳輸結果：
斷線後任務狀態：
同條件復測結果：
最終結論：通過 / 附條件通過 / 暫不通過
限制與下次複核條件：

若需要先規劃測試矩陣，可參考 遠端科研運算環境的訂購方案；若課題組重點是長時間任務，則應把斷線恢復和日誌保存列為獨立驗收項目，而不是附帶測試。

對實驗室而言，繼續使用既有 Windows 或 Linux 主機的優點是資料和儀器通常已經整合，但常見缺點也很明確：沒有 macOS 專屬執行環境、架構差異無法驗證，遠端自動化結果也可能掩蓋真實圖形互動問題。直接購買 Mac 則會增加一次性設備成本、維護責任與閒置風險。若只是需要在發布前完成一輪或數輪驗收，按測試週期租用具完整權限的遠端 Mac，通常更適合先驗證 Apple Silicon、依賴與結果一致性，再決定是否值得長期採購；可先查看 NodeMini 的遠端 Mac 使用入口，按實際測試週期安排環境。