如果你做过 Web 端 AI 功能，大概率踩过同一个坑：用户只是想总结一段文字、给评论纠错、从页面里问几个问题，你却要把内容发到云端 LLM，承担 token 成本、排队延迟、隐私合规和数据出境解释。
所以我看到 Hacker News 上 The Prompt API 这条讨论冲到两百多分时，第一反应不是“浏览器终于也有 AI 了”，而是：这东西如果真能稳定落地，会改变一类低风险 AI 功能的默认架构。
Chrome 的官方文档把 Prompt API 描述得很直接：网页或 Chrome Extension 可以把自然语言请求发给浏览器内置的 Gemini Nano。换成人话说，就是以前你在前端调用 fetch('/api/ask')，后端再转发给 OpenAI、Gemini 或自建 vLLM；现在有些场景可以直接在浏览器里问本地模型。
这听起来很香，但我不建议现在就把它当成“云端 LLM 替代品”。它更像一块新的系统拼图：适合放在用户设备边缘，处理轻量、局部、对隐私敏感、失败代价不高的任务。
它真正解决的不是“更聪明”，而是“更靠近数据”
Prompt API 背后的标准化工作在 Web Machine Learning Community Group 的 prompt-api 仓库 里。这个 Explainer 说得很清楚：今天 Web 开发者要用语言模型，通常只有两条路：调用云端 API，或者自己把模型用 WASM/WebGPU 之类的方式塞进浏览器。前者简单但有隐私和成本问题，后者灵活但工程负担很重。
浏览器内置模型想走第三条路：模型由浏览器或操作系统提供，Web 应用只拿到一个标准 API。
说白了就是：模型不属于你，运行环境也不完全属于你，但调用入口变简单了。
这件事的工程价值不在于 Gemini Nano 一定比你后端的大模型强。恰恰相反，它大概率不会更强。它的价值在于位置：模型离用户输入、页面 DOM、临时草稿、聊天记录更近。很多数据本来就停留在浏览器里，如果只是做摘要、标签、轻量问答、辅助改写，非要绕一圈云端并不总是合理。
Chrome 的 built-in AI 入门文档 也强调了这个方向：内置 AI 让 Web 应用在不部署、不管理自有模型的情况下完成 AI 任务。这个表述很克制，它没有承诺“最强模型”，而是在强调部署和管理成本。
我觉得这才是正确打开方式。
但生产环境最先撞上的，是可用性而不是 API 语法
Prompt API 的代码示例并不复杂。Chrome 文档里建议先用 LanguageModel.availability() 判断模型是否可用，再调用 LanguageModel.create() 创建 session；如果模型需要下载，还要监听下载进度并明确告知用户。
技术上这是一个异步初始化问题。
人话翻译：你不能假设用户打开网页时模型已经躺在那里等你。它可能不可用，可能正在下载，可能因为硬件不满足条件而永远不可用。
这和我们熟悉的云端 LLM 调用完全不同。云端 API 的主要失败模式是网络、限流、账单、服务端报错；浏览器本地模型的失败模式多了一层“用户设备差异”。Chrome 的 Get started with built-in AI 写得很具体：使用 Gemini Nano 相关 API 需要桌面 Chrome，移动端暂不支持；设备还要满足存储、GPU/CPU、VRAM 或内存等条件。文档提到模型所在 Chrome profile 卷需要至少 22GB 可用空间，GPU 路线需要超过 4GB VRAM，CPU 路线需要 16GB RAM 和至少 4 个 CPU 核心。
这组门槛对开发机不算高，对真实用户群就很现实了。
所以如果你的产品经理问“能不能直接用 Prompt API 做全站 AI 总结功能”，我的回答会比较保守：可以做渐进增强，不能做唯一依赖。你要准备三层降级：
- 浏览器本地模型可用：直接本地处理；
- 本地不可用但用户允许云端处理：走后端 LLM；
- 两者都不可用：展示普通搜索、规则摘要或关闭功能入口。
没有这层降级，Prompt API 带来的不是成本优化，而是一堆看起来随机的用户投诉。
隐私优势是真的，但别把它神化
本地 LLM 最容易被宣传成“隐私安全”。这个说法有一半对。
对的是：敏感文本不必离开用户设备。比如用户正在编辑一封邮件、整理客服聊天记录、给内部文档做摘要，如果任务可以在浏览器内完成，后端就不需要接触原文。对企业合规来说，这一点很有吸引力。
但另一半问题也不能忽略：Prompt API 仍然是一个网页可调用的能力。只要网页能拿到用户输入，它就可能构造提示词、读取模型输出、把结果再发回服务器。也就是说，本地执行降低的是“模型服务商和中间链路”风险，不会自动消灭“应用本身滥用数据”的风险。
这和我之前写 Agent Armor 安全框架 时的判断很像：AI 能力越靠近用户工作流，越不能只看模型能力，还要看权限边界、审计、用户确认和降级策略。浏览器内置 AI 也是一样。它不是隐私银弹，只是把一部分风险从云端调用迁移到了前端权限治理。
如果你要在生产里使用，我建议至少做三件事：
- 明确告诉用户哪些内容会被本地模型处理，哪些内容可能上传云端；
- 对所有云端降级路径做单独授权，而不是静默 fallback；
- 不要把本地模型输出直接写入高风险状态，比如自动提交表单、自动修改数据库、自动发送消息。
最后一点尤其重要。浏览器 AI 很适合“建议”，不适合“无确认执行”。
它适合哪些场景？我会从低风险辅助功能开始
从 Chrome 的 Built-in AI APIs 页面看，Google 并不只推一个通用 Prompt API，还把 Summarizer、Writer、Rewriter、Translator、Language Detector、Proofreader 等能力拆成更窄的 API。这个方向我反而更认可。
通用 Prompt API 很灵活，但灵活意味着不可预测。窄 API 的好处是产品语义更明确，浏览器和规范制定者也更容易约束输入输出。
我会优先考虑这些场景：
- 页面内摘要：对长文、评论串、客服记录做“先看概要”；
- 本地分类和标签：给用户自己的笔记、收藏、邮件草稿打标签；
- 写作辅助：改写、润色、语气调整，但保留用户确认；
- 站内轻量问答：只基于当前页面或当前文档回答问题；
- 隐私敏感预处理：先在本地抽取结构化信息，再决定是否上传。
反过来，我不建议现在用它做这些事：
- 需要稳定推理能力的复杂 Agent；
- 需要严格一致输出格式的核心业务流程；
- 跨用户一致体验要求很高的 SaaS 核心功能；
- 需要引用最新知识或大量私有知识库的 RAG。
这里可以类比 RAG 里的重排问题。我在 RAG 系统中 Bi-Encoder 与 Cross-Encoder 的工程对决 里提过，工程系统经常不是选“最先进模型”，而是把不同模型放到合适的位置。Prompt API 也是这个逻辑：它适合做离用户最近的第一层智能，而不是替代整个后端 AI 架构。
标准化会比模型本身更关键
Prompt API 最值得关注的地方，其实不是 Chrome 现在接了 Gemini Nano，而是它出现在 W3C Web Machine Learning 社区的标准化讨论里。GitHub 仓库 README 明确提到，Chrome、Microsoft Edge 和 Web Machine Learning Community Group 都在探索让 Web 开发者直接 prompt 浏览器或操作系统提供的语言模型。
这句话的信息量很大。
如果最后只有 Chrome 支持，那它更像 Chrome 独占能力，适合 Extension 或实验性 Web 功能。如果 Edge、Safari、Firefox 或操作系统层 API 也逐步靠近同一抽象，那浏览器内置模型就可能变成新的 Web 平台能力。历史上很多能力都是这样来的：先是某个浏览器的实验 API，然后经过权限、兼容性和安全模型反复打磨，最后才进入开发者默认工具箱。
当然，这里仍然有几个硬问题没解决：
- 不同浏览器背后的模型能力差异怎么暴露？
- 开发者能不能知道上下文窗口、语言支持、模态支持？
- 本地模型更新后，线上功能行为变化如何回归测试？
- 企业管理员是否能禁用或管控这类 API？
- prompt 注入和页面内容污染如何防？
这些问题不解决，Prompt API 就很难承载高风险生产流程。
但这不妨碍它先从低风险场景切进去。Web 平台很多能力都是这样长大的。
我的结论：把它当“边缘 AI 层”，不要当“后端替代品”
如果只问“Chrome Prompt API 能不能用于生产环境”，我的答案是：可以用于生产环境里的渐进增强功能，但不适合作为核心 AI 后端的唯一依赖。
它最适合的位置，是浏览器侧的边缘 AI 层：
- 先做本地摘要、分类、改写、草稿辅助；
- 对隐私敏感内容尽量不上传；
- 对失败可接受的功能做体验增强；
- 对复杂推理、企业知识库、审计和一致性要求高的任务，仍然交给后端。
这不是一个“本地模型打败云端模型”的故事。更准确地说，是 Web AI 架构开始分层：浏览器负责近场、低延迟、隐私友好的轻任务；后端负责强模型、统一策略、知识库和审计。
我不确定 Prompt API 最终会以现在的形态稳定下来，尤其是浏览器兼容性和企业管控这两块还有很长的路。但它提出的问题已经很明确：不是所有 AI 请求都应该离开用户设备。
这句话，可能会成为未来几年 Web AI 架构设计里越来越重要的默认前提。