截至 2026 年 9 月 10 日，Apple 已確認 macOS 27 是面向 Intel-only macOS 軟體提供通用 Rosetta 支援的最後一個主要版本。不要把「macOS 27 仍可能執行 Rosetta」當成延後遷移的理由：你現在應立即盤點 CI 的 x86_64 依賴，建立原生 arm64 節點與臨時相容節點的雙軌驗證，等所有生產任務取得原生運行證據後，再升級及收縮相容池。相關支援邊界以 Apple 的 Rosetta 公告 為準。
這篇適合管理 Apple Silicon Mac 構建機、需要判斷哪些節點能升級 macOS 27 的 IT 負責人。
如果你負責 CI/CD、工具鏈、年度採購或發布連續性，下面的資產表、驗收清單和容量矩陣可直接用於立項與審批。
01 先分清楚三個容易混淆的相容邊界
企業已經採購 Apple Silicon，不代表 CI 已經完成 arm64 遷移。真正需要檢查的是每個任務實際啟動的執行檔與子程序，而不是 Mac 的處理器名稱。
| 邊界 | 代表什麼 | 對企業 CI 的判斷 |
|---|---|---|
| Intel Mac 硬體 | 使用 Intel 處理器的舊 Mac | 這是硬體生命週期問題，不等同於 Apple Silicon 上的 Rosetta 依賴 |
| Apple Silicon + Intel-only macOS 軟體 | arm64 主機透過 Rosetta 執行 x86_64 應用程式 | 目前可能仍能執行，但應列入遷移與退出清單 |
| Linux VM 中的 Intel 二進位檔 | 虛擬機內的 Linux 二進位翻譯 | 不應直接當成 macOS Rosetta 行為；Apple 對 Linux VM 的說明另有界定 |
Rosetta 是 Apple Silicon macOS 上的翻譯環境，不是把整台主機變成 Intel Mac。Apple Rosetta 技術文件說明了這個執行邊界；而 Linux VM 的 Intel 二進位檔則應依照Apple 的 Linux VM 文件另外驗證。
截至目前，macOS 27.0 RC 已於 2026 年 9 月 9 日發布，但面向公眾的正式版本尚未發布；macOS 26.4 及之後版本可能顯示遷移提醒。正式升級前，仍要重新核對 macOS 27 Release Notes，不能根據預覽版或媒體轉述推測 macOS 28 的行為。
02 IT 負責人：先建立可追溯的 x86_64 資產表
盤點範圍不能只包括 Xcode 或主要 CI Agent。Rosetta 依賴往往藏在安裝器、包管理器路徑、外掛與前後置指令碼內。建議將每項發現都連到一個實際 CI 任務，避免產生只有名稱、沒有證據的清單。
第一項：登記會被執行的資產
至少應檢查以下位置：
- CI Agent、Runner 與節點啟動服務
- Shell、Python、Ruby 等指令碼所呼叫的外部執行檔
- 套件管理器及其安裝目錄
- LaunchAgent、守護程序與背景服務
- Xcode 外掛、建置外掛與自研載入器
- 動態函式庫、封裝前後置指令碼
- 內部工具、發行工具及簽署輔助程式
每一列至少保留架構、呼叫任務、負責人、替代版本、生產影響、驗證證據與退出日期。若資產只在開發者互動式工作階段出現，也不能直接視為 CI 安全；你必須在無人值守節點重現一次。
第二項：用最小命令確認架構
在 Apple Silicon 節點上，可以先對可疑執行檔使用：
file /path/to/tool
lipo -info /path/to/tool
file 可協助判斷檔案是否為 arm64、x86_64 或 Universal Binary；lipo -info 可確認 Universal Binary 是否真的包含所需切片。對已經運行的程序，還要查看其程序架構與父子程序關係。不要只看安裝路徑，因為同一套工具可能同時存在原生與 Intel 版本。
注意：顯示 Universal Binary 不等於整條流水線已經原生化。你仍要確認實際被 CI 啟動的切片、外掛與動態函式庫，並把命令輸出、提交版本和任務識別碼一併保存。
03 平台團隊：以替換、重編譯和隔離處理工具鏈
工具遷移的判斷順序應固定，否則團隊容易把短期繞行方案誤當成長期架構。
| 處理方式 | 適用條件 | 完成證據 | 否決條件 |
|---|---|---|---|
| 直接替換原生 arm64 版本 | 供應商已有相同功能的原生版本 | 真實專案完成測試、封存與發布 | 只在互動式終端成功，CI 無法重現 |
| 重編譯為 arm64 或 Universal Binary | 你能取得原始碼與建置流程 | 兩種架構切片均通過簽署及發布驗證 | 相依函式庫或外掛仍只有 x86_64 |
| 暫時隔離到相容池 | 閉源工具無法即時替換 | 有負責人、風險、使用任務和退出日期 | 新任務繼續依賴，或必須降低系統安全設定 |
| 移除或改寫流程 | 工具不再是必要路徑 | 產物、測試結果與發布紀錄一致 | 沒有替代的回滾方案 |
自研元件可依Apple Silicon 遷移文件安排重編譯；若要產生同時包含 arm64 和 x86_64 的 Universal Binary，則應依Apple 的 Universal Binary 指南檢查建置與簽署流程。
「安裝完成」不是遷移完成。每一項替換都應用真實專案跑完測試、封存、簽署、公證和發布。若工具透過腳本再啟動一個 x86_64 子程序，主工具即使是 arm64，也不能算完全脫離 Rosetta。
04 CI 平台團隊：用原生池與相容池做雙軌驗收
原生池和相容池必須使用節點標籤、佇列或獨立 Runner 群組分開。不要讓兩種架構共用未驗證的快取、環境變數、臨時檔案或簽署憑證。否則一次成功的重跑，可能只是吃到了另一個架構留下的產物。
建議按下列順序執行雙跑：
- 選取代表性 Pull Request、完整測試、封存與發布任務。
- 在原生 arm64 節點與相容節點各自執行相同提交。
- 比對測試結果、產物雜湊、簽署狀態和發布結果。
- 記錄失敗類型：工具找不到、外掛載入失敗、權限錯誤、Keychain 鎖定或服務未啟動。
- 重新啟動節點後，在無互動式登入的條件下重跑關鍵任務。
- 將差異連回資產表，指定修復負責人與退出條件。
Xcode 版本本身也要獨立核對。請參照 Xcode 27 Release Notes檢查建置工具、SDK、簽署與已知限制，不要把「同一台 Mac 能開啟 Xcode」當作 CI 通過。
雙軌驗收矩陣
| 驗收面向 | 原生 arm64 節點 | 暫時相容節點 | 放行條件 |
|---|---|---|---|
| 編譯與測試 | 使用原生工具鏈完成 | 記錄仍需 Rosetta 的任務 | 代表性任務結果與產物可解釋 |
| 封存與簽署 | 驗證 Keychain、簽署與公證 | 不得以降低安全設定繞過 | 產物雜湊與審批紀錄完整 |
| 外掛與動態函式庫 | 確認載入的實際架構 | 登記每個例外元件 | 沒有未登記的 x86_64 子程序 |
| 重啟與恢復 | 無互動式登入仍能執行 | 僅承接已登記任務 | 恢復步驟可重現 |
| 快取與環境 | 與相容池隔離 | 不向原生池回寫未驗證快取 | 兩池互不污染 |
05 安全與發布負責人：把「能跑」改成「可無人值守地跑」
Rosetta 依賴最容易在發布階段暴露。某個工具可以在工程師登入後執行，不代表 LaunchAgent、守護程序或 CI 服務帳號也能執行。你需要特別驗證以下邊界：
- Keychain 在服務帳號下能否取得必要憑證。
- 程式簽署與公證是否同時通過。
- 內部外掛是否載入正確架構。
- 守護程序重啟後是否自動恢復。
- 節點重新開機後，CI Agent 是否能重新註冊。
- Universal Binary 的兩個架構切片是否都能通過發布檢查。
- 是否有人為了相容性而關閉系統安全控制。
任何必須降低安全設定才能繼續運行的元件，都應進入阻斷或限期退出清單。驗收證據至少包括產物雜湊、架構檢查輸出、CI 記錄、簽署結果、重啟紀錄與審批人。
06 FAQ：把五個高風險問題放進遷移決策
macOS 27 還能執行 Intel 應用程式嗎？
可以，但這是有限期的支援邊界，不是長期承諾。Apple 已確認 macOS 27 是通用 Rosetta 支援 Intel-only macOS 應用程式的最後一個主要版本。你可以把 macOS 27 當作最後遷移窗口，而不是新的基線；正式升級前，應以 macOS 27 Release Notes再次核對。
怎樣檢查 Mac CI 是否依賴 Rosetta 2？
從任務實際呼叫的檔案開始，不要只檢查主應用程式。對可疑工具使用 file 和 lipo -info，再追蹤包管理器、LaunchAgent、外掛、動態函式庫和子程序。最後要在乾淨節點與服務帳號下重跑，將命令輸出及 CI 記錄存入資產表。
x86_64 建置工具怎樣遷移到 arm64？
優先採用供應商的 arm64 原生版本；沒有原生版本時，再評估重編譯為 arm64 或 Universal Binary。遷移後必須跑真實專案的測試、封存、簽署、公證和發布。若閉源元件仍無法替換，就放入隔離相容池，並設定明確退出日期。
企業是否需要保留 macOS 27 相容節點？
遷移期間可以保留，但相容節點只能承接已登記的例外任務。它不應接收新的永久依賴，也不應與原生節點共用快取或未驗證環境。當所有高價值生產任務取得原生證據後，按剩餘任務數量和發布風險逐步減少相容容量。
Rosetta 停止支援會令哪些 CI 指令碼失敗？
常見風險包括包管理器、腳本呼叫的子程序、安裝前後置指令碼、外掛載入器、動態函式庫與背景服務。發布流程中的 Keychain、簽署、公證和重啟恢復也可能失敗。企業應用任務級雙跑找出實際失敗點，而不是只測試一個主建置命令。
07 采购與容量負責人：用任務量而不是開發者人數估算節點
遷移容量不能按「有多少位開發者」直接換算。你需要先整理以下變數：
- 待遷移的生產任務數量與優先級。
- 原生 arm64 節點在實際工作負載下的有效產能。
- 相容池的退出日期與剩餘例外任務。
- 發布高峰的併發需求。
- 節點故障時所需的恢復與備援能力。
- 雙跑期間新增的佇列壓力與保留容量。
如果現有 Apple Silicon 節點無法同時承擔雙跑，不要直接把所有任務切回相容池。你可以比較新增實體採購、短期雲端 Mac 租賃或混合節點池，但成本與穩定性要以你的任務記錄和供應商條件核算，不能預設某一種方案必然更便宜。
| 決策情況 | 優先方案 | 需要先取得的證據 |
|---|---|---|
| 原生節點已有餘裕，例外任務少 | 直接建立隔離相容池並加速替換 | 雙跑結果、快取隔離與恢復紀錄 |
| 雙跑期間佇列明顯增加 | 增加 Apple Silicon 節點或短期租用遠端 Mac | 真實任務併發、發布峰值與驗收週期 |
| 工具鏈仍有閉源依賴 | 保留有限相容容量 | 例外負責人、退出日期與安全審批 |
| 需要先驗證 macOS 27 升級 | 建立隔離的遠端 Apple Silicon 試驗節點 | 任務、簽署、Keychain、重啟後恢復證據 |
| 任務長期穩定且需要實體介面 | 評估自購或託管硬體 | 硬體維護、備援、折舊與機房責任 |
你可以先參考 Mac 構建節點的遠端配置入口建立隔離 PoC，再依任務併發與保留週期比較遠端 Mac 租賃方案。若團隊需要跨地區安排節點，應另外確認連線品質、頻寬、存取權限和資料留存要求。
08 你的企業遷移檢查清單
IT 與資產責任
- [ ] 已列出所有 Apple Silicon CI 節點及目前系統版本。
- [ ] 已掃描 CI Agent、套件管理器、外掛、動態函式庫與背景服務。
- [ ] 每個 x86_64 資產都有任務、負責人、替代方案和退出日期。
- [ ] 已區分 Intel Mac 硬體、Intel-only 應用程式、Rosetta 程序與 Linux VM 二進位檔。
- [ ] 已保存
file、lipo、程序架構和系統報告結果。
工具鏈與 CI 責任
- [ ] 原生 arm64、相容節點使用不同標籤或佇列。
- [ ] 兩個節點池沒有共用未驗證快取和臨時產物。
- [ ] 代表性測試、封存、發布任務已完成雙跑。
- [ ] 已比對產物雜湊、簽署、公證和測試結果。
- [ ] 相容池沒有接收新的永久依賴。
安全與採購責任
- [ ] Keychain、外掛、守護程序和無人值守恢復已驗證。
- [ ] Universal Binary 的架構切片均通過發布檢查。
- [ ] 沒有以降低系統安全設定掩蓋遷移問題。
- [ ] 容量模型使用任務量、併發、峰值和備援需求，而非開發者人數。
- [ ] 已完成自購、短期租用及混合節點池的條件式比較。
09 先用隔離節點取得證據，再決定長期資產
如果你目前依賴固定的 Intel Mac 或單一自建打包機，主要問題不只是 Rosetta：舊硬體會限制 macOS 升級，單節點故障會中斷發布，採購又會提前鎖定容量；若改用未隔離的共用雲端環境，則可能遇到權限、快取污染、頻寬與資料留存責任不清。
更穩妥的做法，是先在 CALMVPS 建立一組隔離的 Apple Silicon 遠端 Mac 試驗節點，用真實 CI 任務驗證 arm64 工具鏈、簽署、Keychain 和重啟恢復。當任務證據完整後，你再決定哪些容量值得長期採購、哪些適合按需租用，以及相容節點應在何時退出。若你只是需要短期雙跑、macOS 27 升級驗證或發布高峰的額外容量，這種租賃方式通常比為遷移過渡期一次購買整批硬體更容易控制承諾範圍。