[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f12251EGiloQvnZsTAPnpMBjRzGBBjWKoOyikTxQQ6Xo":3},{"item":4,"related":51},{"id":5,"type":6,"title":7,"slug":8,"summary":9,"body":10,"coverUrl":11,"productScreenshots":12,"productLinks":13,"authorName":14,"authorUrl":15,"authorSubject":16,"category":17,"tags":22,"sourceLabel":39,"sourceName":40,"sourceUrl":41,"status":42,"seoTitle":43,"seoDescription":44,"canonicalUrl":45,"isFeatured":46,"sno":47,"sortOrder":48,"publishedAt":49,"updatedAt":50,"createdAt":50},"5c48f6e2-585c-425d-a16c-4fddbe52b592","article","浏览器自带 AI API：网页如何本地完成翻译、摘要和改写？","browser-built-in-ai-apis-explained","Chrome Built-in AI 把部分模型能力放进浏览器，由网页调用翻译、语言检测、摘要、写作和改写 API。本文解释本地推理的优势与限制、模型下载和兼容性问题，以及更现实的本地与云端混合架构。","过去，网页里的 AI 功能通常意味着：把用户输入上传到服务器，服务器调用模型，再把结果返回浏览器。浏览器只是一个界面。\n\nChrome 的 Built-in AI 走的是另一条路：浏览器自己管理一部分模型和推理能力，网页通过标准化 JavaScript API 请求翻译、摘要、改写或提示任务。这样一来，网页不必为每一次简单文本处理都建立云端模型调用。\n\n## 先给结论：Built-in AI 是浏览器托管的能力层\n\nChrome 官方文档把 Built-in AI 定义为由浏览器提供和管理的基础模型与专家模型能力。当前文档列出了 Translator、Language Detector、Summarizer、Writer、Rewriter、Proofreader 和 Prompt 等不同方向的 API，但它们的可用状态并不相同，有的已经进入稳定版本，有的仍处于 origin trial 或早期预览。[Chrome Built-in AI 文档](https:\u002F\u002Fdeveloper.chrome.com\u002Fdocs\u002Fai\u002Fbuilt-in)\n\n这意味着开发者面对的不是“有没有一个 AI API”这么简单，而是三个问题：\n\n1. 当前浏览器是否支持这个 API？\n2. 当前设备是否满足模型运行要求？\n3. 这次任务适合本地模型，还是应该交给云端模型？\n\n## 一组 API，解决的是不同的小问题\n\n把这些 API 统称为“浏览器里的 ChatGPT”容易误解。它们更像一组可以嵌入网页体验的能力组件：\n\n| API | 更适合做什么 | 不应默认它做什么 |\n| --- | --- | --- |\n| Language Detector | 判断用户输入的语言 | 不等于高质量翻译 |\n| Translator | 将一段文本翻译成目标语言 | 不等于专业领域审校 |\n| Summarizer | 将长文本压缩成摘要、要点或段落 | 不等于事实核验 |\n| Writer | 根据任务生成一段新文本 | 不等于自主完成业务流程 |\n| Rewriter | 调整长度、语气或表达方式 | 不等于理解全部业务上下文 |\n| Prompt | 处理更开放的文本和多模态任务 | 不等于稳定的结构化后端接口 |\n\n例如，客服网站可以先用 Language Detector 判断用户语言，再用 Translator 把问题转成内部工作语言；文章网站可以用 Summarizer 生成“先读摘要”，而不是把整篇文章发送到服务器。\n\n## 本地推理为什么有吸引力\n\n当任务主要是文本改写、短摘要或语言检测时，本地推理有三个明显优势：\n\n- **响应更短**：输入不必先穿过网络到达远端服务。\n- **边际成本更低**：简单操作不必按请求数持续产生云端模型费用。\n- **数据更少出网**：草稿、评论或内部文本可以优先在设备上处理。\n\n但“本地”不等于“永远可用”。浏览器可能需要先下载模型，设备可能没有足够内存或计算能力，模型也可能因为版本、地区或浏览器状态而不可用。Chrome 文档特别强调了模型下载、缓存、更新、清理和用户提示等产品问题。[模型管理与使用建议](https:\u002F\u002Fdeveloper.chrome.com\u002Fdocs\u002Fai\u002Fbuilt-in#best-practices)\n\n因此，网页不能把本地 AI 当成一个无条件存在的后端。更稳妥的做法是把它当成一种能力探测结果：能本地完成，就本地完成；不能完成，就降级到普通功能或经过授权的云端服务。\n\n## 一个更现实的混合架构\n\n适合生产环境的架构通常不是“本地取代云端”，而是按照任务风险和复杂度分层：\n\n```mermaid\nflowchart TD\n    A[用户输入] --> B{本地 API 可用?}\n    B -->|否| C[普通界面或云端回退]\n    B -->|是| D{任务是否适合本地模型?}\n    D -->|摘要\u002F翻译\u002F改写| E[浏览器本地推理]\n    D -->|复杂推理\u002F敏感业务决策| F[服务端模型或人工处理]\n    E --> G[结果展示与用户确认]\n    F --> G\n```\n\n举例来说，商品评价的语法润色可以放在本地；退款资格判断则不应该只交给浏览器里的小模型，因为它可能涉及订单状态、规则版本和审计记录。\n\n## API 设计要关注会话和上下文\n\n开放式 Prompt API 最容易遇到的问题是上下文会不断增长。网页如果把整个历史对话每次都重复发送，本地模型也会变慢、占用更多内存。Chrome 的实践文档给出了会话管理和“摘要压缩上下文”的思路：当历史过长时，先用 Summarizer 把旧内容压缩，再开启一个新会话。[Session compacting 指南](https:\u002F\u002Fdeveloper.chrome.com\u002Fdocs\u002Fai\u002Fbuilt-in#session-compacting)\n\n这说明 Built-in AI 不是一行 API 调用就结束。开发者仍然需要设计：\n\n- 模型第一次下载时显示什么状态；\n- 用户切换设备或清理缓存后如何降级；\n- 结果如何标记为机器生成；\n- 失败、超时和模型不可用时怎么恢复；\n- 哪些结果必须让用户确认后才能写回业务数据。\n\n## 不要把“本地”误写成“绝对隐私”\n\n文本不上传服务器，确实减少了一个数据暴露面，但网页仍然可以记录输入、结果和交互日志。模型生成的内容也可能出错、偏见或泄露用户主动输入的秘密。\n\n因此，隐私设计至少要分三层：\n\n1. 浏览器是否把原文发送到远端；\n2. 网页自己的 JavaScript 是否保存或上传原文；\n3. 生成结果是否会被写入账户、数据库或分析系统。\n\n只有三层都说清楚，用户才能真正知道“本地 AI”保护了什么。\n\n一句话总结：**Built-in AI 把模型能力放进了浏览器，但产品责任仍然留在网页开发者手里。**\n\n## 来源\n\n- [Chrome for Developers：Built-in AI](https:\u002F\u002Fdeveloper.chrome.com\u002Fdocs\u002Fai\u002Fbuilt-in)\n- [Chrome Built-in AI APIs 状态说明](https:\u002F\u002Fdeveloper.chrome.com\u002Fdocs\u002Fai\u002Fbuilt-in-apis)","\u002Fuploads\u002F2026-09-08\u002Fff6756e6-ef33-4d7a-bb3b-2b3d2394c8f5.jpg",[],[],"Foundit","https:\u002F\u002Ffoundit.cn","foundit-ai-editorial",{"id":18,"name":19,"slug":20,"description":21},"6179d3b6-dc34-4483-9ded-3cd9f1b37a47","科普","abbreviation","介绍各领域新兴概念",[23,27,31,35],{"id":24,"name":25,"slug":26},"88d2bc27-0e0f-468a-b907-2991cb97b87b","人工智能","ai",{"id":28,"name":29,"slug":30},"7da20200-5815-42a5-851a-bc8c1db554cb","应用","app",{"id":32,"name":33,"slug":34},"82f427f8-6275-4cbb-bcac-cf1948488006","网页应用","web-app",{"id":36,"name":37,"slug":38},"8d35e42e-9f5b-4dd9-b30f-dc2c53d06096","硬件","hardware","Chrome Built-in AI 官方文档","Chrome for Developers：Built-in AI","https:\u002F\u002Fdeveloper.chrome.com\u002Fdocs\u002Fai\u002Fbuilt-in","published","Chrome Built-in AI：浏览器内置 AI API 如何工作","介绍 Chrome 浏览器内置的翻译、摘要、改写和 Prompt API，分析本地 AI 的隐私、延迟、兼容性和云端回退策略。",null,false,47,0,"2026-09-08T00:00:00.000Z","2026-09-08T03:19:16.095Z",[52,61,69],{"id":53,"type":6,"title":54,"slug":55,"summary":56,"coverUrl":57,"authorName":14,"sno":58,"publishedAt":59,"createdAt":60},"894ac568-3ef4-4514-a4c7-fe92c5a63b46","AG-UI：为什么 Agent 需要一套面向前端的交互协议？","ag-ui-agent-frontend-interaction-protocol","AG-UI 是面向 Agent 与用户界面的事件驱动协议。本文解释它如何统一流式输出、工具反馈、状态同步和人工介入，并比较它与 MCP、A2A 及 SSE、WebSocket 的分工。","\u002Fuploads\u002F2026-09-12\u002F0c1b85e6-bfeb-4730-b1e8-a80b366ed413.jpg",56,"2026-09-12T00:00:00.000Z","2026-09-12T03:56:46.137Z",{"id":62,"type":6,"title":63,"slug":64,"summary":65,"coverUrl":66,"authorName":14,"sno":67,"publishedAt":49,"createdAt":68},"71cf5ad9-a09c-4394-9d76-5f39fea0e4ef","WebNN：浏览器怎样把神经网络交给 NPU 和 GPU？","webnn-neural-network-inference-browser","WebGPU 提供通用 GPU 计算，WebNN 则试图让网页用统一方式描述神经网络，并交给浏览器和操作系统选择 CPU、GPU 或 NPU 后端。本文解释 WebNN 的计算图、硬件加速、隐私边界和渐进增强策略。","\u002Fuploads\u002F2026-09-08\u002F9bf93122-c216-4dd8-9381-11db89b7d08f.jpg",59,"2026-09-08T03:19:17.431Z",{"id":70,"type":6,"title":71,"slug":72,"summary":73,"coverUrl":74,"authorName":14,"sno":75,"publishedAt":59,"createdAt":76},"4d5ad0ab-081e-433f-8aad-a951df4188f9","为什么同一张图片换个格式就小很多","webp-image-compression-explained","图片压缩并不是简单删除像素，而是利用相邻区域的规律减少需要保存的数据。本文解释 WebP 的有损与无损压缩，以及不同图片格式的适用场景。","\u002Fuploads\u002F2026-09-12\u002Fa39cdc32-db5e-4659-805f-74df02adcbeb.jpg",55,"2026-09-12T04:45:46.282Z"]