Foundation Models 不可用怎麼辦？2026 排查指南

Apple 將 SystemLanguageModel.availability 表達為 available 或帶有原因的 unavailable 兩種結果；本週建議先記錄這個狀態，再依原因分流，而不是把「AI 無法使用」直接判定為框架故障。Apple 的 availability 狀態定義也指出，availability 可用不代表後續生成請求必定成功，生成階段仍須另行處理錯誤。

本文適合正在為 iOS App 接入 Apple Foundation Models、遇到模型不可用的獨立開發者。
維護 macOS App、需要兼容不同系統版本與模型狀態的開發者，也可用這套排查分支。
負責測試或發布驗收的小型團隊，則可用文末檢查清單確認降級路徑。

最後更新於 2026 年 11 月 1 日；狀態與錯誤處理依據 Apple Foundation Models 使用指南、availability 與錯誤類型文件核對。

先分清楚兩種症狀：availability 已回報不可用，或 availability 顯示可用、但模型會話與生成呼叫失敗。兩者需要不同證據；只記錄一條「模型不可用」訊息，無法讓開發者判斷是裝置條件、使用者設定、模型資產，還是 App 程式碼造成。

排查前要記錄哪些資料？至少保留系統版本、裝置型號、使用者是否啟用 Apple Intelligence、availability 的完整狀態與觸發操作；若失敗發生在生成階段，再附上錯誤類型、可重現輸入及呼叫位置。這些資訊讓測試人員可以重現同一條路徑，也避免把不同問題混成一次「AI 失敗」。

Foundation Models 使用指南建議檢查模型可用性，並為不可用情況準備替代方案。實作時應將可用性檢查和實際生成呼叫視為兩個檢查點：前者描述檢查當下的模型狀態，後者仍可能回報生成錯誤。

當狀態指出 deviceNotEligible，應按「目前裝置不符合使用條件」處理，而非推斷使用者只是漏做設定。Apple 說明模型可用性取決於裝置及 Apple Intelligence 支援條件；實際裝置範圍應以Apple Intelligence 裝置與系統要求的現行資訊為準，不要把舊測試結果當成所有目標裝置都適用的結論。

Foundation Models 顯示 deviceNotEligible 時怎麼處理？將生成式功能設計成可選能力，讓使用者仍能完成不依賴模型的核心工作。不要要求使用者反覆重啟、重新安裝 App 或等待模型下載，除非另外取得證據證明這些動作與目前的錯誤有關。

也要把裝置資格與 App 的最低部署版本分開核對：部署目標符合要求，只能說明 App 可在相應系統範圍內安裝或執行，不能代替對實際裝置資格的判斷。前者是 App 的相容性設定，後者是模型在目前環境中的 availability。

若狀態反映 Apple Intelligence 未啟用，應將它視為設定分支，而不是裝置不支援。介面可以說明開啟系統功能後可使用相關生成能力，但設定必須由使用者自行決定；App 不應暗示能代替使用者在 App 內開啟系統功能。Apple 的生成式 AI 設計指南可作為設計選擇、告知與替代體驗的參考。

Apple Intelligence 已開啟，但模型仍不可用怎麼辦？不要只依賴使用者的設定回報。重新讀取 availability，檢查目前裝置與系統條件，並確認失敗是在可用性檢查還是生成呼叫發生；保留實際狀態後，再依它指向的原因處理。

modelNotReady 和生成階段的資產錯誤並非同一狀態。Apple 對 modelNotReady 的說明將它列為 availability 的不可用原因；這表示檢查時模型尚未就緒，應允許合適的等待或稍後重試，而不是無限輪詢，或把每次畫面重新整理都變成新的生成請求。

模型顯示 modelNotReady 時能否重試？可以設計有限度、由使用者理解的稍後重試，但介面要保留略過或改用替代功能的選項。若狀態持續未變，就提示目前功能暫不可用，而不是令使用者停留在載入畫面。

生成呼叫階段則要讀取實際錯誤，而非沿用 availability 的處理結果。Apple 文件分別記載了新式 assetsUnavailable 錯誤，以及舊式會話生成錯誤中的資產不可用情況。兩者應依目標系統版本及專案實際使用的 API 核對，不能假設所有部署環境都會回報相同錯誤型別。

Foundation Models 執行時出現 assetsUnavailable 怎麼處理？先保存錯誤與當時的請求情境，依目前部署版本的 API 文件辨認錯誤，再提供稍後重試或不依賴模型的替代路徑。Apple 對生成錯誤類型及 Xcode 遷移的說明也提醒，錯誤處理要對照 API 版本；不要因 availability 曾顯示可用，就省略生成階段的錯誤處理。

把狀態分支放進測試案例，而不是只在正常情況下執行一次生成。尤其要分別確認不可用提示是否準確、略過後能否完成核心流程，以及重試失敗後是否能離開等待狀態。使用 Xcode 27 檢視專案時，也要按目標部署版本核對 API 是否可用及錯誤處理方式；單憑建置成功，無法證明目標裝置上的模型功能可執行。

可勾選的發布前檢查清單：

• [ ] 記錄系統版本、裝置、Apple Intelligence 設定、availability 狀態與觸發操作。
• [ ] 分開驗證 deviceNotEligible、Apple Intelligence 未啟用與 modelNotReady，不把它們合併成同一個錯誤提示。
• [ ] 分開測試 availability 不可用與生成呼叫失敗，並保存各自的錯誤類型。
• [ ] 確認等待與重試不會無限循環，使用者也能改用替代功能或略過。
• [ ] 在實際支援的目標裝置上驗收模型執行；記錄裝置與系統條件，避免將模擬器結果當成實機證據。
• [ ] 按目標部署版本核對 Xcode 27 專案使用的 API 與錯誤處理。

遠端 Mac 可用於檢查專案結構、執行建置及複核程式碼路徑，但這些工作不能證明受支援 iPhone 上的 Foundation Models 已完成執行驗收。沒有可核驗的目標裝置測試紀錄，就應將實機模型驗收標示為尚未完成，而不是以模擬器或建置成功代替。

如果目前流程只靠模擬器和一台個人 Mac，常見限制是無法覆蓋不同目標裝置、建置環境不一定持續可用，也容易把建置結果誤當成實機模型證據。需要可遠端使用的 macOS 建置環境時，JEXCLOUD 的 Mac 遠端使用入口可作為方案評估起點；若程式分支與建置環境需要先分開查證，也可考慮遠端 Mac 方案。租用 Mac 能處理 macOS 專屬工具鏈與程式碼複核，不能代替實際支援裝置的執行驗收；若工作長期穩定且負載密集，自購設備可能更合適，而需要短期建置或測試環境時，租用 JEXCLOUD 則可避免先為專用 Mac 承擔購置與維護成本。