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 指南。