Chrome 148 里有一个对 Web 开发者很重要的变化：Prompt API 正式进入稳定版 Chrome，普通网页可以直接调用浏览器内置的 Gemini Nano。
它的核心是把本地模型能力放进浏览器平台。浏览器负责管理模型，网页通过标准化的 Web API 发 prompt，推理在用户设备上完成。
AI 能力开始变成浏览器平台的一部分，而不只是某个后端服务。
这件事挺有意思。过去要给网页加 AI 功能，通常要准备后端、API Key、模型供应商、费用控制、隐私说明、限流策略。Prompt API 把其中一部分复杂度挪到了浏览器里。开发者不用部署模型，用户的数据也不一定要离开本机。
当然，它也不是万能替代品。Gemini Nano 是本地小模型，适合轻量任务，不适合拿来做复杂推理、长文档分析或者真正的 agent 系统。但对很多“刚好需要一点 AI”的网页工具来说，它已经够用了。
Prompt API 是什么
Prompt API 是 Chrome Built-in AI APIs 里最通用的一个接口。
它不像 Summarizer、Translator、Language Detector 那样只面向某个固定任务，而是让开发者直接向浏览器提供的语言模型发送自然语言请求。在 Chrome 里，这个模型就是 Gemini Nano。
官方文档里的入口对象是 LanguageModel。典型流程是：
- 检查当前设备和模型是否可用
- 创建一个模型会话
- 调用
prompt()或promptStreaming() - 用完后销毁 session
最简单的代码大概是这样：
const availability = await LanguageModel.availability({
expectedInputs: [{ type: "text", languages: ["en"] }],
expectedOutputs: [{ type: "text", languages: ["en"] }],
});
if (availability !== "unavailable") {
const session = await LanguageModel.create();
const result = await session.prompt("Write a short caption for a photo of a lake.");
console.log(result);
session.destroy();
}如果结果比较长，可以用流式输出：
const session = await LanguageModel.create();
const stream = session.promptStreaming("Explain Prompt API in simple terms.");
for await (const chunk of stream) {
console.log(chunk);
}
session.destroy();这套 API 的形状和云端 LLM API 有点像，但运行位置不一样。它不是请求 OpenAI、Gemini API 或 Claude API，而是请求浏览器本地模型。
它的意义在哪里
我觉得 Prompt API 最重要的意义不是“Chrome 也能跑 AI 了”，而是它改变了网页工具的成本结构。
第一是隐私。
很多轻量任务其实没必要上传到服务器。比如生成图片 alt text、给用户输入做分类、整理一段短文本、从当前页面抽取结构化信息。这些内容可能包含私密信息，也可能只是用户不想上传。Prompt API 让这些任务有机会留在本地完成。
第二是成本。
云端模型按量计费，调用越多成本越高。对个人项目、小工具、浏览器扩展来说，这经常是一个心理门槛。Prompt API 没有每次请求的 token 账单，模型由浏览器管理。只要任务适合本地模型，开发者就不用为每个用户动作单独付费。
第三是延迟和离线能力。
模型下载完成以后，后续调用不需要网络请求。对短任务来说，省掉一次服务端往返会让体验更直接。Chrome 文档也明确说明，初次下载模型需要网络，之后使用模型时不会把数据发送给 Google 或第三方。
第四是 Web 平台边界变了。
以前浏览器主要提供渲染、存储、网络、设备访问能力。现在它开始提供模型推理能力。以后很多应用可能会变成“本地 AI 优先，云端 AI 兜底”的结构：能在浏览器里做的就本地做，超出本地模型能力的再走服务器。
本地 AI 不一定更强，但它把很多小功能变得更便宜、更私密、更容易分发。
它能做什么
Chrome 148 的初始实现已经不只是文本 prompt。
Prompt API 支持文本、图片和音频输入，输出目前是文本。也就是说，它可以用在这些场景里：
- 根据用户输入生成简短文案
- 对短文本做分类、摘要或信息抽取
- 给图片生成说明、标题、alt text
- 做简单视觉搜索或图片内容判断
- 分析音频输入，例如转写或识别声音事件
- 从多模态材料里提取结构化信息
图片输入尤其有用。
以前做“看图生成描述”这类功能，基本绕不开云端视觉模型。现在网页可以直接把 Blob、HTMLImageElement、HTMLCanvasElement、ImageBitmap 这类对象交给本地模型处理。
官方示例里的会话配置大概是这样：
const session = await LanguageModel.create({
expectedInputs: [
{ type: "text", languages: ["en"] },
{ type: "image" },
],
expectedOutputs: [{ type: "text", languages: ["en"] }],
});
const imageBlob = fileInput.files[0];
const description = await session.prompt([
{
role: "user",
content: [
{ type: "text", value: "Describe this image in a short filename-friendly phrase." },
{ type: "image", value: imageBlob },
],
},
]);还有一个很实用的能力是结构化输出。
Prompt API 支持通过 responseConstraint 传 JSON Schema，让模型输出更接近可直接解析的数据。比如你想让它只返回一个对象，而不是一段 Markdown：
const schema = {
type: "object",
properties: {
filename: { type: "string" },
confidence: { type: "number" },
},
required: ["filename", "confidence"],
additionalProperties: false,
};
const result = await session.prompt("Generate a filename for this image.", {
responseConstraint: schema,
});
const data = JSON.parse(result);做产品功能时，这比“请只输出 JSON”可靠得多。
版本和硬件要求
这里要分清几个版本。
Chrome 138 开始，Prompt API 已经可以在 Chrome Extensions 里使用。Chrome 148 开始，它面向普通网页稳定发布。现在是 2026 年 7 月 2 日，Chrome Stable 已经更新到 150，但如果你只是判断网页是否能用 Prompt API，核心版本线仍然是 Chrome 148+。
除了浏览器版本，还要满足设备条件。按 Chrome 官方文档，Prompt API、Summarizer、Writer、Rewriter、Proofreader 这类依赖 Gemini Nano 的 API 需要：
- Windows 10 或 11、macOS 13+、Linux，或 Chromebook Plus 上的 ChromeOS
- Chrome for Android、iOS 以及非 Chromebook Plus 的 ChromeOS 目前不支持这类 Gemini Nano API
- Chrome profile 所在磁盘卷至少 22 GB 可用空间
- GPU 或 CPU 满足其一：GPU 显存大于 4 GB，或 CPU 环境有 16 GB 以上内存且至少 4 个 CPU 核心
- 初次下载模型需要不限流量或非按量计费网络
还有几个细节容易踩坑。
模型不是 Chrome 安装包的一部分。API 在浏览器里，但 Gemini Nano 会在某个 origin 首次使用时单独下载。磁盘空间如果低于阈值，模型也可能被 Chrome 清理掉，后面满足条件后再重新下载。
所以产品里不能只判断 window.LanguageModel 是否存在。你还要处理 availability() 返回的状态，必要时显示下载进度。
const availability = await LanguageModel.availability(options);
if (availability === "unavailable") {
// 当前环境不支持
}
const session = await LanguageModel.create({
monitor(m) {
m.addEventListener("downloadprogress", (event) => {
console.log(`Downloaded ${Math.round(event.loaded * 100)}%`);
});
},
});网页还要注意权限边界。Prompt API 默认只对顶层窗口和同源 iframe 可用，跨源 iframe 需要用 Permission Policy 显式授权。它目前也不能在 Web Workers 里使用。
开发时应该怎么设计
我不建议把 Prompt API 当成“云端大模型的廉价替身”。
更合适的思路是渐进增强。
先判断浏览器是否支持，再判断模型是否可用。如果可用，就走本地推理；如果不可用，就给出降级路径。这个降级路径可以是关闭 AI 功能，也可以是让用户手动填写，也可以是走你自己的云端模型。
大概结构像这样：
async function canUsePromptApi(options) {
if (!("LanguageModel" in window)) {
return false;
}
const availability = await LanguageModel.availability(options);
return availability !== "unavailable";
}其次，要把任务收窄。
本地模型最适合短输入、明确任务、可验证输出。比如“把这张图片生成一个短文件名”“从这段评论里提取评分”“把这段说明压缩到 80 字以内”。不要一上来就让它读完整文档、跨多个页面做复杂推理。
再其次，要保留人工确认。
Prompt API 只是换了运行位置，生成式 AI 的不确定性并没有消失。它仍然可能看错图片、分类错误、漏掉关键信息。涉及文件修改、发布内容、用户数据变更时，最好让 AI 先生成草稿，再让用户确认。
本地运行解决的是隐私和成本，不自动解决正确性。
一个实际项目：AI Image Renamer
我最近做的 AI Image Renamer 就是一个用到 Prompt API image input 的小项目。
它的目标很简单：给本地图片批量改名。
很多图片文件夹里都是 IMG_2048.jpeg、DSC_1182.png、Screenshot_2026-06-28.png 这种名字。文件能打开，但文件名没有任何可搜索价值。AI Image Renamer 会让用户选择本地文件夹，然后用 Chrome built-in AI 分析图片内容，生成更容易识别的文件名，比如 sunlit-mountain-lake.jpeg。
这个项目刻意做成本地优先：
- 不需要账号
- 不上传图片
- 不需要外部模型 API Key
- 通过 File System Access API 访问本地文件夹
- 通过 Prompt API image input 分析图片
- 用户审核、编辑或跳过后，才批量应用改名
我觉得它正好体现了 Prompt API 的适用边界。
图片改名是一个典型的轻量 AI 任务：输入小，输出短，结果容易人工检查。它不需要强到能理解复杂世界，也不需要长上下文，只要能把图片里的主要内容提炼成一个稳定、可搜索的短文件名。
同时，它又很适合本地处理。照片、截图、设计稿里经常有私人信息。为了改文件名就上传整批图片，这件事本身不太舒服。Prompt API 让这个工作流可以留在浏览器和本机文件系统里完成。
当然，项目也必须接受浏览器能力的限制。AI Image Renamer 当前要求 Chrome 148+，并且需要设备支持 Prompt API image input、File System Access API 和文件改名能力。如果环境不满足，就只能提示用户当前浏览器不支持，而不是假装可以工作。
项目地址：
总结
Prompt API 不是让网页突然拥有最强 AI 能力。
它真正有价值的地方，是把一类轻量、私密、频繁的小 AI 任务放进了浏览器本地。对开发者来说，少了模型部署和按量调用成本；对用户来说，很多数据不必离开设备；对 Web 平台来说，AI 推理开始从应用层能力变成平台能力。
但用它时要保持克制。
先做能力检测，再处理模型下载；先选短任务，再谈复杂功能；先让 AI 起草，再让用户确认。Prompt API 最舒服的用法，不是替代所有云端模型，而是把那些本来就应该在本地完成的小工具做得更轻。
参考资料：