iOS 27 全面導入裝置端 AI：Spotlight 與媒體

在 iOS 26 中，裝置端的大型語言模型存在於您的 App 內部。您開啟一個 LanguageModelSession、附上工具，模型便針對您交給它的任何脈絡進行推理¹。iOS 27 把同一個模型往上提升了一層。Apple 現在將它接入 Core Spotlight，讓 App 既有的搜尋索引成為模型的依據來源²；也接入 AVFoundation，讓裝置在播放期間轉錄並翻譯字幕，App 不必寫下任何一行推論程式碼³。這正是重點所在：裝置端模型正逐漸成為一項系統服務，而不只是 App 內部的 API。您直接從程式碼呼叫的那份智慧，如今也運行在搜尋之下、媒體之下，透過您早已使用的框架即可觸及。

本文以 WWDC26 兩場 session 為本，涵蓋其中兩個系統層面：透過 Core Spotlight 的 LLM 搜尋（session 246），以及 Apple AI 產生字幕並在螢幕上即時預覽樣式（session 256）。若您尚未接觸第一項背後的框架基礎，Foundation Models 裝置端 LLM 解說與 iOS 27 工具呼叫 一文可為您鋪好基礎。

TL;DR

• SpotlightSearchTool 採用 Foundation Models 的 Tool 協定，讓語言模型能直接搜尋您 App 的 Core Spotlight 索引，以產生具脈絡的回應。Apple 在 iOS、iPadOS、macOS 與 visionOS 上皆有提供²。
• 您大致用一行程式碼設定該工具、將它附加到 LanguageModelSession，模型便會自行產生查詢、對您的索引執行查詢，並針對結果進行推理²。
• 一個新的索引委派方法 searchableItems(forIdentifiers:) 讓您取回完整的 CSSearchableItem，使模型能看見精簡搜尋索引無法回傳的中介資料²。
• 指引設定檔（guidance profile）會為較小的模型限定工具的搜尋能力範圍；自訂的管線階段（pipeline stage）則讓索引代替模型執行運算（計數、平均、自訂評分）²。
• Apple AI 產生的字幕在播放期間即時、於本機運行，無需任何 App 程式碼。它涵蓋兩條路徑：從音訊進行語音轉錄，以及從既有字幕進行語言翻譯³。
• AVPlayerViewController 免費獲得產生的字幕與播放器內的全新樣式預覽；AVPlayerLayer 與 AVCaptionRenderer 則為自訂播放器介面公開了樣式預覽 API³。

哪些東西搬進了系統

iOS 26 的故事在您的行程中放入一個模型，並給了您 Tool 協定來擴充它¹。iOS 27 保留那個模型，並新增了兩個由系統代您取用它的場所。Core Spotlight 成為模型可查詢的檢索層，讓您本就會捐贈的搜尋索引化為有依據的脈絡。AVFoundation 成為轉錄與翻譯層，這意味著原始媒體從未隨附的語言也能有字幕。

這兩項功能乍看毫不相干，直到您注意到其共通的模式。在兩者之中，Apple 都擁有模型與粗重的工作，而您的 App 擁有內容與呈現的介面。您捐贈可搜尋的項目，模型負責撰寫查詢。您播放一段影片，裝置負責產生字幕。智慧是一項共享的系統能力，您的工作則從實作它，轉變為餵給它正確的內容，並把結果呈現得宜。

透過 Core Spotlight 的 LLM 搜尋

依 Apple 的設定，這是一個健行步道 App，它本就能瀏覽州立公園與步道，並讓使用者在每次健行後寫下個人筆記。開發者想就這些健行向模型提出開放式問題。一個空白的 LanguageModelSession 會以模型自身的世界知識作答，而那是錯誤的來源：答案應當來自 App 確實知道的健行紀錄。這個 App 已將每條步道索引進一個 Core Spotlight 搜尋索引，因此解法就是讓模型透過工具呼叫去觸及那個索引²。

這正是 SpotlightSearchTool 的作用。Apple 將它呈現為一個採用 Tool 協定的工具，讓語言模型直接搜尋您 App 在 Core Spotlight 中的內容以產生具脈絡的回應，在 iOS、iPadOS、macOS 與 visionOS 上皆可使用²。前提是您本就會完成的工作：以 Core Spotlight 捐贈可搜尋的內容，這正是 Apple 先前「Supporting semantic search with Core Spotlight」session 的主題²⁴。一旦您的項目完成捐贈，您匯入 CoreSpotlight 與 FoundationModels，Apple 表示該工具只需一行程式碼便能搜尋您的索引。您選擇一個模型，無論是 SystemLanguageModel，或是透過全新 Model Provider API 提供的模型，接著把一個 SpotlightSearchTool 實例加進您的 session²。

import CoreSpotlight
import FoundationModels

// Apple: "in one line of code, the tool is ready to search
// your app's Core Spotlight index."
let session = LanguageModelSession(tools: [SpotlightSearchTool()])

let response = try await session.respond(to: "What hikes have I gone on?")

在 iOS 27.0 上，當工作階段跑在 SystemLanguageModel 上時，這一行會失敗；下方採用步驟一節中 9 月 15 日的更新記錄了 Apple 的已知問題，以及解決它的聚焦式指引⁵。

軌跡，而非查詢

值得關注的細節在於：誰來撰寫搜尋。不是您。Apple 描述了像「What hikes have I gone on?」這類問題的軌跡：模型判定它需要 SpotlightSearchTool、自行產生查詢，Spotlight 執行該查詢並回傳結果集的描述，模型再針對該輸出進行推理以產出最終回應²。該 session 的結語把這項轉變說得明白：開發者不再撰寫搜尋查詢；他們提供內容，其餘交由智慧完成²。

一道缺口很早就浮現，而 Apple 對此直言不諱。Spotlight 索引中的某些中介資料，例如文字內容與 HTML，是以一種高度精簡的形式儲存，可供搜尋，卻無法以語言模型可讀的形式取回²。模型能找到正確的項目，卻無法讀取為這些項目捐贈的一切。解法就在您本就會實作、用以處理重新索引請求的索引委派之上。Apple 新增了一個方法，可依唯一識別碼取回完整的 CSSearchableItem，使模型能管理可能多達數百萬筆結果的回應，而無需全部載入²。

// On your CSSearchableIndex delegate.
func searchableItems(
    forIdentifiers identifiers: [String]
) async -> [CSSearchableItem] {
    // Return the complete item for each id. The callback is also the
    // place to attach metadata you would not donate for search but
    // want the model to reason over.
    identifiers.compactMap { fullItem(for: $0) }
}

Apple 明確地提出第二點：若您的 App 持有某些中介資料，捐贈來供搜尋並無意義，卻有助於模型推理，那麼這個委派回呼正是在該項目上設定那些額外屬性、供模型查看的地方²。

顯示結果

Apple 在兩種顯示模式之間劃出一條清晰的界線。session 回應是對結果集的精簡描述，正是助理型介面所要呈現的內容。至於清單式的顯示，結果本身可直接從 SpotlightSearchTool 取得，Apple 稱當結果集龐大時，這是存取可搜尋項目的最佳方式²。搜尋回覆以非同步序列的形式抵達，每一則都可能攜帶一批結果，直到工具呼叫完成為止。由於模型在產出最終答案前可能不只一次呼叫該工具，Apple 表示應使用每則回覆上的 queryToken 來決定 UI 何時該重新整理²。

針對您所選的模型進行客製

SpotlightSearchTool 公開了一套廣泛的能力，從針對文字的語意搜尋，到針對日期、人物與地點的結構化搜尋²。Apple 提供三個調節桿，讓這個介面貼合您所運行的模型。第一個是指引設定檔。把工具的整套能力交給一個小模型，會耗盡它本就不足的脈絡，因此 GuidanceProfile 會把指引限縮到 App 所需的範圍，細到模型應考量的中介資料屬性的確切清單，並在您建立工具時設定一個動態的指引層級²。Apple 對裝置端模型（其脈絡大小較為受限）的建議是：針對較簡單的搜尋能力給予聚焦的指引²。

第二個調節桿是參照解析。若 App 捐贈了人際關係，而使用者問起某條步道上的其他人，模型便需要知道「那個人」指的是誰。Apple 的解答是一個聯絡人解析器，它會回傳與使用者身分相關的聯絡資訊，工具再將其與索引中的中介資料比對²。

第三個調節桿是把搜尋轉化為運算的那一個。對於像「how many trails have I hiked this year, and for each month, how many miles on average?」這樣的複雜請求，Apple 表示模型可能捨棄簡單查詢，轉而採用一種管線搜尋，將索引查詢與針對結果集的運算結合在一起²。模型把問題拆成數個階段：搜尋已完成的健行、一個依月份建立表格的計數階段，再來一個針對計數求平均的階段²。管線階段為 Generable，因此模型會依提示按需產生一個階段，而 App 可註冊自己的自訂階段²。Apple 的範例是針對每個項目的筆記算出一個幸福分數，或許透過情感分析或五星評分，並以 Guide 屬性告訴模型應偏好哪些結果²。

// Apple's example: a Generable pipeline stage that scores items so the
// model reasons over the top-scoring results, not the raw set.
@Generable
struct HappinessScoredTrail {
    let item: CSSearchableItem
    @Guide(description: "Prefer higher scores; 5-star hikes rank highest.")
    let happinessScore: Double
}
// Register the stage on the tool's configuration.

Apple 在收尾時談的是驗證而非實作，指向 Evaluations 框架，用以衡量模型呼叫工具的成效，以及其回應的意義度，並以結果涵蓋率作為健行 App 的範例指標²。那套評估迴圈自成一個主題，將於 Apple Evaluations 框架 一文中說明。

產生的字幕，於裝置端

媒體層面從另一個角度展現了同樣的原則。Apple AI 產生的字幕在媒體播放時，於裝置上即時、於本機建立³。session 256 的切入點以無障礙為先：字幕對於失聰或聽力受損者、對於想跟上口說對白的人，以及對於任何在當下就是聽不到聲音的人,都至關重要。當內容隨附的語言並非觀眾所能理解時，裝置便能補上這道缺口³。

Apple 描述了兩條路徑。第一條是語音轉錄：來源音訊進入裝置端的語音轉文字模型，輸出字幕³。第二條是語言翻譯：既有字幕（在 Apple 的範例中為英文）進入裝置端的翻譯模型，產出另一種語言（例如義大利文）的字幕³。由內容創作者親手撰寫的編寫字幕，仍維持優先且不受更動；產生的字幕只會增添語言³。同樣的裝置端翻譯能力，也直接以 Translation 框架 的形式呈現給開發者。

對採用而言最關鍵的部分是：要開啟這項功能，您什麼也不必實作。Apple 表示產生的字幕在影片播放期間會自動可用³。它涵蓋 HTTP 即時串流（包含直播電視頻道）、隨選視訊、運動賽事這類直播活動，以及檔案式內容（例如隨 App 打包或已下載的媒體）³。專業內容與顧客自製內容（iPhone 相機拍攝、社群影片）皆符合資格³。

這份首發矩陣範圍狹窄，值得精確閱讀。自 iOS 與 macOS 27 起，可從英文音訊產生英文字幕，tvOS 與 visionOS 27 亦予支援³。在此之上，可在 iOS 與 macOS 上從英文字幕產生多種字幕語言³。也就是說，轉錄起初是橫跨四個平台的英文轉英文，而翻譯則在最大的兩個平台上從英文向外擴展。

您真正的工作落在哪裡

啟用產生的字幕不費分毫，因此您的心力應投注在選擇 UI 上。Apple 的指引很直接：在播放期間提供字幕選擇 UI³。三個選項，依 Apple 為您代勞的多寡由高至低排列：

• iOS 上的 AVPlayerViewController（以及 macOS 上的 AVPlayerView）已完整實作字幕選擇與播放器控制。您無需額外動作³。
• AVLegibleMediaOptionsMenuController 提供選擇控制項與相關行為，但不含播放器控制，適合您已有播放器 UI、僅需選單的情境³。
• 用於媒體選擇的自訂控制項，當您希望選單與 App 其餘部分風格一致時採用³。

在 Apple 的示範中，產生的選項帶有一個閃光符號與「Translated」字樣，讓使用者能將它們與編寫的軌道區分開來³。

樣式預覽

session 中的第二項功能是呈現。多年來，「設定」App 一直讓人們挑選並建立字幕樣式，但 Apple 的重點在於：在影片播放途中變更樣式並即時預覽，比起離開播放、到「設定」裡翻找，既更便利也更無障礙³。使用者在「設定」中定義的同一批樣式（包含自訂的）如今也會出現在播放器的樣式選單中，並附上每一種的預覽³。

AVPlayerViewController 直接實作了樣式預覽與播放器控制³。對於自訂播放器，AVPlayerLayer 公開了一個樣式預覽 API，而 AVCaptionRenderer 則可在您自行承擔算繪時提供預覽³。Apple 的 AVPlayerLayer 流程如下：每個系統樣式都帶有一個 profile ID，因此您依各自的 profile ID 取得所有樣式、以它們的名稱填入您的 UI，並在使用者選取某個樣式時呼叫預覽函式。新字幕會以所選樣式顯示，同時任何既有字幕都會自動隱藏，以免互相干擾。為文字參數傳入 nil 會顯示在地化的系統文字，而位置參數則會偏移預覽的位置，以避開您的控制項。每換一種新樣式就再次呼叫該函式，選擇完成時停止預覽（這會還原作用中的字幕），並為系統上的所有字幕設定所選的樣式³。

如何採用

對於 Spotlight 搜尋：

1. 先把您的內容捐贈給 Core Spotlight；工具搜尋的是索引，沒有捐贈就無物可搜²⁴。
2. 將 SpotlightSearchTool() 附加到 LanguageModelSession 並挑選您的模型，可選 SystemLanguageModel 或來自 Model Provider API 的模型²。 在 iOS 27.0 上搭配系統模型時，請改為帶聚焦式指引來建構該工具（見下方 9 月 15 日的更新）⁵。
3. 在您的索引委派上實作 searchableItems(forIdentifiers:)，以回傳完整項目，並附上精簡索引無法取回、僅供模型使用的中介資料²。
4. 對於助理檢視，顯示 session 回應；對於清單檢視，從工具讀取 CSSearchableItem 結果，並在每則回覆的 queryToken 上重新整理²。
5. 若您運行的是裝置端模型，請以 GuidanceProfile 限定能力範圍，並僅在某個請求需要對龐大集合進行計數或評分時，才動用管線階段²。

2026 年 9 月 15 日更新： 在 iOS 27.0 上，第 2 步需要加上限定。Apple 的正式版發行說明列出一個已知問題：「Creating a SpotlightSearchTool without a configuration and using it with a LanguageModelSession backed by the on-device system language model fails with an error reporting that the number of tokens provided exceeds the maximum allowed.」（不帶設定建立 SpotlightSearchTool，並用於由裝置端系統語言模型支撐的 LanguageModelSession，會因「提供的 token 數超過允許上限」的錯誤而失敗。）該工具的預設設定「is sized for models with large context windows」（依擁有大型脈絡視窗的模型來設定規模），Apple 的解法是使用聚焦式指引，即 .focused(.communications)、.focused(.calendar)、.focused(.documents)、.focused(.visualMedia) 或 .focused(.audio)，它「exposes a smaller set of search capabilities than the default configuration」（暴露的搜尋能力集合比預設設定小）。⁵ 因此，搭配 SystemLanguageModel 時請傳入指引；第 2 步中不帶參數的 SpotlightSearchTool() 適用於脈絡視窗更大的模型。正式版說明的完整解讀見iOS 27.0 發行說明文章。

對於產生的字幕：

1. 沒有任何開關需要開啟這項功能；它會在播放期間自動運行³。
2. 確保您的播放器透過 AVPlayerViewController、AVLegibleMediaOptionsMenuController 或您自己的控制項，公開字幕選擇 UI³。
3. 透過 AVPlayerViewController 免費加入樣式預覽，或把 AVPlayerLayer 的預覽 API 接進自訂播放器³。
4. 在承諾語言之前，先讀過支援矩陣：橫跨四個平台的英文轉英文轉錄，以及在 iOS 與 macOS 上以英文為來源的翻譯³。

FAQ

iOS 27 中的 SpotlightSearchTool 是什麼？

它是一個 Foundation Models 工具，採用 Tool 協定，讓語言模型能直接搜尋您 App 的 Core Spotlight 索引，並運用結果來產生回應。Apple 在 iOS、iPadOS、macOS 與 visionOS 上皆有提供。您把一個 SpotlightSearchTool 實例附加到 LanguageModelSession，模型便自行產生搜尋查詢，而非由您撰寫²。

我必須撰寫搜尋查詢嗎？

不必。Apple 的說法是，開發者不再撰寫搜尋查詢；他們提供內容，其餘交由模型完成。模型判定它需要該工具、產生一個查詢，Spotlight 執行查詢並回傳結果集的描述，模型再針對該輸出進行推理以產出答案²。

為什麼模型看不到我捐贈的所有中介資料？

某些 Spotlight 中介資料，例如文字內容與 HTML，是以高度精簡的形式儲存，可供搜尋，卻無法以可讀的方式取回。若要讓模型掌握全貌，請在您的索引委派上實作 searchableItems(forIdentifiers:) 以回傳完整的 CSSearchableItem，並利用該回呼附上任何僅供模型使用的額外屬性²。

我需要實作任何東西才能取得產生的字幕嗎？

不需要。Apple 表示產生的字幕在影片播放期間會自動可用，於裝置上即時、於本機建立。您的工作是選擇 UI，以及可有可無的播放器內樣式預覽，而非推論本身³。

產生的字幕在首發時支援哪些語言？

自 iOS 與 macOS 27 起，可從英文音訊產生英文字幕，tvOS 與 visionOS 27 亦同。另外，可在 iOS 與 macOS 上從英文字幕產生多種字幕語言。也就是說，轉錄是橫跨四個平台的英文轉英文，而翻譯則在 iOS 與 macOS 上從英文向外擴展³。

產生的字幕與 Spotlight 搜尋是否具隱私性？

兩者都在裝置上運行。產生的字幕在媒體播放時即時、於本機建立³，而 SpotlightSearchTool 則透過裝置端模型查詢您 App 本機的 Core Spotlight 索引¹²。Apple 提供系統實作，改變的是由誰維護它，而非它在何處運行。

完整的 Apple Ecosystem 系列：Foundation Models 裝置端 LLM 以及 SpotlightSearchTool 所採用的 Tool 協定；掌管模型呼叫此類工具有多積極的 iOS 27 工具呼叫控制；用於背景執行、同步與 Spotlight 的並行介面 iOS 27 中的 App Intents；以及談系統模型底層的 Core AI：在 Apple Silicon 上運行模型。樞紐在 Apple Ecosystem 系列。若需更廣泛的「iOS 結合 AI 代理」脈絡，請參閱 iOS Agent Development 指南。