Chrome Built-in AI

• Gemini Nano 在浏览器中的端侧部署方式与 API 家族（Prompt、Summarizer、Translator、Rewriter、Language Detector）
• 模型能力与上下文长度、token 上限等有限性
• 与云端大模型在能力、延迟、隐私上的差异

Chrome Built-in AI 将 Gemini Nano 这一小型端侧 LLM 通过 Chrome 内置的各类 API 暴露给 Web 开发者。核心 API 族包括 Prompt API（window.ai.languageModel）用于自由文本生成与对话、Summarizer API 用于摘要、Translator API 用于翻译、Rewriter API 用于改写、Language Detector API 用于语言检测，它们多通过异步的 capabilities()/availability() 探测设备支持情况。这些 API 在本地运行，无需联网即可推理，数据不出设备，隐私与离线能力是其核心价值。

答案限制与边界： 受限于端侧模型体积与算力，Gemini Nano 的上下文长度、maxTokens 上限与推理速度都远小于云端大模型，复杂推理与长文本生成能力有限；模型能力随浏览器版本分发，版本与行为不一致，需通过 availability() 检测并设计降级策略；部分 API 仍在实验阶段（origin trial），需要权限策略（Permissions Policy）约束，且首用需下载模型，占用 StorageManager 配额。

本题考察对 Chrome 内置 AI 能力全景的把握。回答应既说明 API 家族（体现知识广度），又强调端侧模型在上下文、token、速度、版本一致性上的硬限制，同时点出隐私与离线优势，体现"能力与限制"的辩证视角。

• Writer API 与 Rewriter API 职责与输入输出的本质区别
• 二者可选参数（tone、length、format 等）的含义与组合
• 写作辅助产品中按需选择与降级策略

Writer API 用于"从无到有"生成文本，即给定主题、要点或约束生成全新的内容；Rewriter API 用于"从有到优"改写已有文本，在给定文本基础上调整语气（tone，如 more-formal/more-casual）、长度（length，如 shorter/longer）与格式（format）。两者都支持通过 capabilities() 查询可用参数子集，因为不同设备实现的模型能力可能不同。

取舍策略： 在写作辅助场景中，二者常组合使用：先用 Writer 生成初稿，再用 Rewriter 按目标受众润色。工程上应优先查询 capabilities() 拿到设备支持的参数集合，再决定是否启用高级参数；对不支持 tone/length 的设备降级为默认输出，甚至回退到 Prompt API 或云端能力，避免因参数不可用而报错。

核心是区分"生成"与"改写"两类语义：Writer 面向无输入生成，Rewriter 面向既有文本变换。答题需结合 capabilities() 探测与参数组合，体现端侧模型能力差异下的工程取舍，而非只罗列 API 名称。

• 模型首次下载时机、存储与复用（StorageManager 配额）
• 离线推理对隐私与数据安全的提升
• 下载失败、离线不可用时的降级与体验

端侧 AI 模型在首次调用相关 API 时由浏览器下载到本地存储，并通过 StorageManager 的配额管理占用空间；下载完成后模型可复用，后续推理在设备本地完成，无需联网，因此数据（提示词、输入内容）不出设备，隐私性显著优于云端推理。这也带来离线可用与低延迟的收益。

权衡与边界： 模型下载本身需要网络与存储空间，且首次冷启动有等待；若设备存储不足或下载失败，需向用户提示并降级到云端 API 或提示不可用。工程上应展示下载进度、支持断点续传，并在离线场景下明确告知"端侧可用、云端不可用"的能力差异，避免功能失效造成困惑。

本题考察"下载—存储—复用—隐私"的完整链路。应从模型下载时机与配额管理切入，突出端侧推理的隐私与离线优势，再指出存储与冷启动的代价及降级策略，体现对体验与隐私的双重考量。

• 模型输出不可信，渲染前必须 sanitize（DOMPurify 等）
• 提示注入（prompt injection）的原理与防御
• 输出上下文隔离与 CSP 等纵深防御

模型输出本质上是不可信数据，尤其当它被当作 HTML 渲染时，必须经过 sanitize 处理，否则模型可能输出

本题要点是"模型输出不可信"。答题应覆盖渲染面（sanitize + CSP）与生成面（提示注入防御）两条线，说明即使端侧模型本意无害，也可能被注入诱导，因此必须把输出当作不可信数据处理并做纵深防御。

• availability() 返回的可用性取值（unavailable/downloadable/downloading/available）与语义
• capabilities() 返回的模型能力（topK、maxTokens、token 计数等）查询
• 基于探测结果的分级降级设计

window.ai.languageModel 提供 availability() 与 capabilities() 两个探测接口。availability() 返回模型是否可用：unavailable 表示当前设备不可用、downloadable 表示需要先下载、downloading 表示正在下载、available 表示可直接使用；capabilities() 返回能力对象，包含 defaultTopK、maxTopK、defaultTemperature、maxTemperature 以及评估模型规模的 size() 等，帮助开发者了解模型支持的参数范围；token 计数由会话的 countPromptTokens() 提供。

降级策略： 工程上应先调用 availability() 判断状态：unavailable 时回退到云端 API 或禁用功能；downloadable/downloading 时展示下载进度或引导下载；available 时直接使用。同时用 capabilities() 校验参数是否在支持范围内，超限时钳制到默认值，避免异常。基于 token 计数（countPromptTokens()）实现输入长度预估与截断，保证在 maxTokens 内完成生成。

本题考察端侧模型探测的标准流程。应区分 availability()（可用性状态机）与 capabilities()（能力参数）两个接口，并据此设计"不可用—下载—可用"的完整降级链，体现端侧模型不确定性与工程健壮性的结合。

• expectedInputLanguages 期望输入语言与 capabilities() 探测
• type 参数（keypoints/tweet 等）对摘要形态的影响
• 流式 summarize() 逐块返回与进度展示

Summarizer API 用于生成输入文本的摘要。expectedInputLanguages 声明期望处理的输入语言，可通过 capabilities() 查询模型实际支持的语言集合，避免传入不支持的 locale 导致报错；type 参数控制摘要形态，如 keypoints 生成要点式列表、tweet 生成适合推文的短摘要，此外还有 format（markdown/plain-text）与 length（short/medium/long）等参数，均需在 capabilities() 探测后使用。

流式落地： summarize() 默认返回完整摘要，还支持流式版本（如 summarizeStreaming()），逐块返回摘要片段，便于在长文本场景下实现"边生成边展示"的流式体验，降低首屏等待。工程落地应：先探测模型与语言可用性，再按业务选择 type；对不支持流式的设备降级为一次性 summarize()；长文本注意输入长度与 token 预算，必要时分段。

答题应体现"探测—参数选择—流式体验"的完整链路。重点讲清 expectedInputLanguages 与语言匹配、type 对摘要形态的影响，以及流式 summarize() 在长文本下提升体验与降级处理，展现对端侧 API 的工程理解。

• tone 与 length 参数的含义及能力探测
• 润色场景下用户可感知的控制粒度
• 参数不可用时的降级与体验设计

Rewriter API 的 tone 参数控制改写语气，如 more-formal（更正式）、more-casual（更随意），length 控制篇幅（如 shorter/longer），format 控制格式（如 markdown/plain-text）。这些参数为润色场景提供了用户可感知的"风格与篇幅"控制维度，使产品能提供"正式/口语化、精简/丰富"等选项。

UX 设计： 由于不同设备支持参数不同，应先通过 capabilities() 探测可用子集，据此动态渲染可用的润色选项（不可用的参数置灰或隐藏），避免用户选择后报错。选择后调用 rewrite() 改写，并展示改写结果与原文对比；对不支持参数的设备，提供"默认润色"降级选项，或回退到 Prompt API 以自然语言指定风格，保证能力降级时体验仍连贯。

本题考查"能力参数 + 用户体验"的结合。既要说明 tone/length 的语义，更要强调基于 capabilities() 动态渲染选项、降级与对比展示等 UX 设计，体现端侧能力差异下的产品化思维。

• detect() 语言检测与 translate() 翻译的职责划分
• 端侧离线翻译的低延迟与隐私优势
• 语言对支持、可用性探测与降级

Translator API 提供 detect() 与 translate() 两个核心能力。detect() 用于检测输入文本的语言（返回置信度与语言标签），translate() 用于把文本从源语言翻译成目标语言，两者结合可构建"自动检测语言并翻译"的完整流程。由于翻译在端侧完成，无需网络往返，延迟低，且原文不出设备，契合本地化工程对隐私与响应速度的要求。

工程落地： 使用前应通过 capabilities() 探测设备支持的语言对（可用语言可由模型下载决定），对不支持的组合需下载对应语言模型或降级到云端；translate() 生成后也可用 detect() 校验翻译后语言符合预期。对长文本注意输入长度与 token 预算，必要时分段翻译并拼接。整体方案天然支持离线场景，适合邮件、评论、文档等本地化翻译。

本题要点是"detect 检测 + translate 翻译"的组合构成离线低延迟方案。应强调端侧翻译的隐私与延迟优势，并落到语言对探测、下载与降级这些工程细节，体现对本地化落地场景的理解。

• 模型按需下载机制与首次使用触发
• 模型存储位置与 StorageManager 配额管理
• 配额占用对存储空间与隐私的权衡

端侧模型通常采用"按需下载"策略：用户首次调用相关 API 时，浏览器才下载对应模型，避免安装时即占用大量空间。模型存储受浏览器存储配额机制（StorageManager）管理，可复用、可清理。这既能满足离线推理需求，又通过配额机制避免模型无限占用用户磁盘空间。

隐私影响： 模型下载与存储在本地，不涉及上传用户数据；但模型体积可达数百 MB 至 GB 级，占用配额会挤占其他站点缓存空间，开发者应在下载前告知用户并展示占用与进度，必要时提供清理入口。配额紧张时浏览器可能清除模型，导致下次使用需重新下载，因此需在 availability() 中识别 downloading 状态并做恢复下载，避免静默失效。

本题应讲清"按需下载 + 配额管理"两条线。先说明模型在首次使用时下载、由 StorageManager 管理，再分析配额占用对空间与隐私的权衡影响，以及被清理后的恢复策略，体现对端侧存储生态的认识。

• system prompt 注入的威胁模型与防御
• 敏感输入（如支付、个人信息）的边界控制
• abort() 取消生成与超时控制的工程实现

若用户输入被直接拼入 system prompt，攻击者可通过输入内容注入指令，诱导模型忽略系统约束、输出敏感内容或执行不当行为。防御上应：将用户输入与系统指令隔离，以结构化数据而非直接拼接的方式传入；对输入做长度与内容校验；对模型输出做白名单与敏感词校验，必要时人工二次确认。

敏感输入边界： 对支付、个人信息等敏感场景，应限制上下文中的敏感数据量，最小化原则减少暴露；对生成任务设置超时与 abort() 取消机制，用户可主动中断过长或越界的生成，后端也需有超时兜底。结合 abort() 与 URL 级权限（Permissions Policy）与站点隔离，明确哪些页面可调用端侧模型，形成纵深边界。

本题双线考察安全与工程。回答一方面要讲清 system prompt 注入的威胁与隔离防御，另一方面要结合敏感输入说明 abort() 取消、超时、权限策略等边界控制，体现"安全 + 健壮性"并重的工程思维。

• 端侧 AI 在 iframe/Worker 中的可用性限制
• Permissions Policy 对 AI 能力访问的授权控制
• 跨域 iframe 与权限隔离的工程实践

Built-in AI 的可用性受上下文与权限约束：跨域 iframe 默认不能直接调用，需通过 Permissions Policy 显式授权；部分 AI API 在 Worker 或特定环境中的可用性也受实现限制，需做能力探测。权限策略（Permissions Policy）允许站点通过 allow 属性控制哪些 iframe 可以使用端侧 AI 能力，实现按需授权与最小权限。

控制策略： 使用 Permissions Policy 时，可在顶层设置是否允许，并在 iframe 的 allow 属性中声明具体 AI 能力（如 self、'self'、指定 origin），限制第三方嵌入内容调用端侧模型，防止恶意 iframe 滥用本地模型或诱导用户。工程上应结合 availability() 探测实际可用性，对不可用的上下文提供降级或明确提示，避免在不支持的 iframe/Worker 中静默失败。

本题考察权限模型与上下文适配。应说明 iframe/Worker 的可用性差异与 Permissions Policy 的授权机制，并落到"最小权限 + 能力探测 + 降级"的工程实践，体现对端侧能力安全边界的理解。

• detect() 返回的置信度与候选语言含义
• 混合语言文本的置信度分布特性
• 阈值选取与误判/漏判的平衡

Language Detector API 的 detect() 对输入文本返回一个或多个候选语言及其置信度（confidence），反映模型对各语言归属的把握。对纯语言文本，置信度通常集中且高；对混合语言文本或短文本，置信度会分散在多个候选语言间，且整体可信度下降，难以给出单一确定结论。

阈值策略： 工程上应综合分析置信度分布而非只看最高分：设定阈值（如最高置信度需超过某个临界值）才判定为"确定"，否则标记为"不确定/需人工确认"或交由其他流程处理；对短文本、混合文本适当降低门槛或提高不确定性提示，避免误判。可结合文本长度与语言对的先验知识调整阈值，并通过抽样评估误判率来校准阈值。

本题考察对概率输出的工程化运用。答题应说明置信度分布在混合文本下的特性，并落到阈值选取与误判/漏判平衡的具体策略，体现把模型输出转化为可靠业务判断的能力。

• Android 与桌面端模型分发的差异（AGC/Play Services 分发）
• 不同平台模型能力与可用性的差异来源
• 跨平台降级检测与一致体验

Chrome Built-in AI 在不同平台上的模型分发与能力存在差异：Android 端可能通过 Google Play Services 或 AGC（App Linking/Accessory）等机制分发模型，桌面端则与浏览器版本绑定，两者在模型版本、能力子集、下载时机上可能不同，导致同一功能在不同平台表现不一致。

降级检测： 由于平台差异不可控，工程上必须通过 availability()/capabilities() 在运行时探测各平台的实际可用性与能力，据此动态调整功能：能力不足时降级为简化参数、云端 API 或禁用高级功能。同时要区分"模型正在下载"与"不可用"等状态，给出统一的下载引导与降级提示，保证跨平台体验一致且不因某平台缺模型而报错。

本题考察跨平台端侧模型的不确定性。答题应说明 Android（AGC/Play Services）与桌面端在分发与能力上的差异，并强调以运行时探测 + 降级策略应对平台差异，实现一致体验。

• maxTokens 与 context 窗口对长文档的限制
• 输入截断、分段与摘要聚合策略
• 精确性与成本/速度的权衡

端侧模型受上下文窗口与 maxTokens 限制，长文档整体输入会超出窗口导致截断或失败。工程上需先通过 size() 等 token 计数方法估算输入长度，超出预算时采用截断、分段（map-reduce）策略：把长文档切分为可容纳的片段分别摘要，再对片段摘要做二次聚合，得到完整文档摘要。

取舍： 截断会丢失上下文、降低摘要质量，分段聚合能覆盖全文但增加多次调用与延迟。实际取舍需结合文档长度、目标精度与响应速度：对关键文档采用分段聚合保证覆盖，对超高文本可用滑动窗口或分层摘要；严格控制 maxTokens 上限避免生成被截断，必要时放弃部分细节以换取速度与成本。应始终在输入前校验长度，避免静默截断造成错误结果。

本题考察 token 预算下的长文本处理。答题应说明窗口/ maxTokens 限制，重点讲分段—聚合的 map-reduce 思路与精度、速度权衡，体现对端侧模型资源约束的工程取舍。

• 端侧与云端的互补优势（离线/隐私 vs 能力/成本）
• 混合架构的调度与降级策略
• 成本与体验的平衡

混合架构将端侧 Built-in AI 与云端大模型 API 结合：端侧提供离线、隐私、低延迟的兜底能力，云端提供更强模型、更丰富参数与更高质量输出。工程上通过 availability()/capabilities() 探测端侧可用性，作为路由依据：端侧可用时优先端侧，能力不足或需高质量结果时路由到云端。

平衡与成本： 云端调用按 token 计费，成本高；端侧免费但能力有限。设计上应把高频、低复杂度、隐私敏感任务交给端侧（离线兜底、省成本），把低频、复杂、高质量任务交给云端；同时设计降级链（端侧→云端→提示不可用），并对云端调用做缓存、配额与并发控制，在体验与成本间取得平衡。离线场景下端侧兜底保证核心功能可用。

本题考察端云协同的架构思维。答题应说明端侧与云端的互补优势，并给出"优先级路由 + 降级链 + 成本控制"的混合架构，突出离线兜底与成本之间的工程权衡。

• 端侧模型版本随浏览器分发、不同步的挑战
• 模型行为不一致对功能与测试的影响
• 版本感知与降级、兼容处理

端侧模型随浏览器版本更新，不同浏览器、不同设备安装的模型版本可能不同，导致同一代码在不同环境产生不同输出。这种版本不一致带来功能表现、质量与测试的稳定性挑战，也影响模型行为的一致性（如语气、格式、能力边界）。

应对： 工程上应做"版本感知"：通过 capability/版本信息探测模型能力，不依赖具体版本号而依赖能力面；对关键输出做归一化与校验，减少版本差异；建立跨版本回归测试基线，覆盖不同模型版本；对高风险差异降级到云端或保守参数。同时把模型更新纳入发布节奏，避免用户端模型突然变化影响体验。

本题考察端侧模型版本管理的工程现实。答题应指出版本随浏览器分发、不同步的挑战，并给出能力探测、归一化、回归测试与降级等版本感知应对，体现端侧 AI 特有的一致性难题。

• 下载中断与断点续传的处理
• 失败重试与网络策略
• 用户可见下载进度与状态展示

端侧模型体积较大，下载可能因网络中断、切网、存储不足而失败，需支持断点续传与失败重试：记录已下载进度，中断后从断点继续，避免重新全量下载；对瞬时失败做指数退避重试，并监听网络状态变化（online/offline）决定是否恢复。结合 availability() 返回的 downloading 状态识别下载中。

工程落地： 应提供用户可见的下载进度（进度条、已下载/总量、速度），并支持暂停/继续与取消；下载完成后做完整性校验（如 hash 校验）确保模型可用；配额不足或存储被清理时，提示重新下载并恢复。整体要处理好"下载中—下载完成—冷启动推理"的状态机，避免用户误以为功能失效。

本题考察端侧模型下载的健壮性工程。答题应覆盖断点续传、失败重试、网络策略与用户可见状态展示，并落到完整性校验与存储处理的细节，体现对下载可靠性的完整考量。