News

Turn your best AI prompts into one-click tools in Chrome

原文链接：https://blog.google/products-and-platforms/products/chrome/skills-in-chrome/ 来源：Google Chrome Blog 作者：Hafsah Ismail 发布日期：2026-04-14

速查卡

项目	内容
一句话总结	Google 把 Gemini in Chrome 的常用 prompt 升级成可保存、可复用、可跨标签页运行的一键 Skills，开始把 AI 能力固化为浏览器级工作流原语。
大白话版	以前你每到一个网页都得重新输一遍 prompt，现在可以把它存成快捷技能，一点就跑，还能同时作用在多个标签页。
核心要点	Skills 保存与复用、跨标签页运行、官方技能库、可编辑 remix、敏感动作需确认、桌面端 English-US 先行发布
价值评级	A — 这是浏览器入口层 AI 产品化的重要一步。
适用场景	高频网页分析、比价、长文扫描、轻量 agent workflow、浏览器内 AI 生产力工具

文章背景

这篇 Google 官方博文本身不长，但它背后的产品信号很大。

过去一年，AI 浏览器插件和网页 Copilot 最大的问题不是“模型能不能回答”，而是工作流没法沉淀。用户每次都重新描述任务，模型每次都重新猜上下文，最后形成不了稳定习惯。Google 这次上的 Skills，本质上是在把 prompt 从一次性聊天，升级成一个可调用、可编辑、可复用的小型工作流单元。

更关键的是，这件事发生在 Chrome 里，而不是独立 AI app 里。谁控制浏览器入口，谁就更接近控制用户的高频信息流、比较行为、文档阅读和轻操作场景。这就是为什么我把它看成 A 级，而不是简单的“小功能更新”。

完整内容还原

原文信息量不算大，但每一段都对应一个很清晰的产品决策。

一、Google 先定义问题：重复性 AI 任务太笨重

文章开头先给出一个典型场景，用户想在不同菜谱页面上反复问“怎么把这道菜改成 vegan”。过去每到一个新页面，都要重新输入同样的 prompt。

Google 的切口很聪明，它没有把 Skills 包装成“强 agent”或“自动化革命”，而是从重复输入同一个 prompt 很烦这个日常痛点切入。这个 framing 非常产品化，因为它降低了用户理解门槛，也避开了浏览器 agent 目前最敏感的“自动乱点按钮”恐惧。

二、核心能力 1：把 prompt 直接保存成 Skill

原文明确说，用户在 chat history 里写出一个以后还会复用的 prompt 时，可以直接把它保存成 Skill。

这件事看似普通，实际上做了两层抽象：

prompt 不再只是对话记录，而是可复用资产。
保存动作直接发生在已有对话历史中，减少额外配置成本。

这比很多 AI 工具要求用户单独进入“模板管理器”更自然，因为用户往往是在用的时候才发现“这句 prompt 我下次还想再用”。

三、核心能力 2：Skill 可以在当前页和多标签页运行

Google 明确写到，用户在 Gemini in Chrome 里输入斜杠 / 或点击 +，就能选中已保存 Skill，并让它运行在当前浏览页面，以及你选中的其他 tabs 上。

这是一句非常重要的话，因为它说明 Skills 不是普通 prompt snippet，而是具备：

页面上下文注入
多 tab 任务视野
单次调用多源比较

这直接把应用场景拉开了：

购物：多页面规格对比
长文档处理：跨多个资料页提炼共同信息
研究辅助：多个来源横向扫描

也就是说，Skills 的真正野心不是“把 prompt 存起来”，而是把网页上下文里的重复任务抽象成浏览器原语。

四、核心能力 3：Google 自带 Skills library

原文还说，Google 同时推出了一套 ready-to-use 的 Skills library。

官方举的例子包括：

拆解正在浏览商品的成分
在多个选项之间按预算和收礼人兴趣做礼物筛选

这一步很重要，因为它意味着 Google 不想只做一个空壳模板系统，而是想自己定义一批“标准 AI 浏览器动作”。这会带来三层效果：

用户不必从零开始写 prompt。
Google 能观察哪些 workflow 最常用，从而继续收敛产品方向。
生态入口控制权在 Google 手里，未来完全可以扩展成 marketplace 或团队共享库。

五、核心能力 4：用户可 remix 和编辑

Google 没把官方 Skills 当封闭功能，而是允许用户把感兴趣的 Skill 添加为 saved Skill，再进一步编辑 prompt。

这看似只是可定制性，实际上很关键。因为 AI workflow 的价值经常不是来自“一个完美模板”，而是来自“一个 70 分模板 + 用户按自己习惯调成 90 分”。

这种设计延续了 prompt engineering 的基本现实，最佳实践不是一次性写死，而是在真实场景里不断修 prompt。Google 如果不给编辑能力，Skills 很快就会沦为鸡肋 demo。

六、核心能力 5：敏感动作必须确认

原文在“Stay in control”部分写得很清楚，Skills 继承 Gemini in Chrome 的 safeguards。尤其是：

某些操作会要求确认
例子包括加日历事件、发送邮件
同时继承 Chrome 的 layered protections、automated red-teaming 和 auto-update

这段非常短，但信息密度很高。它说明 Google 已经预见 Skills 会从“分析页面”逐步跨到“半执行型动作”。一旦涉及 calendar、email 这类 side-effect，浏览器 AI 就不能只靠 prompt 好用，还必须把确认、权限、更新机制一起打包。

从产品层面看，这是一种很典型的 agent 渐进策略：

第一步先做分析型 Skills
第二步允许少量高价值动作
第三步用 confirmation 把风险压住

核心技术洞察

1. Prompt 正在被产品化成工作流对象

过去 prompt 是临时自然语言，现在 Google 把它变成可保存、可复用、可调用的对象。这是 AI 产品从“会聊天”走向“能积累”的关键一步。

2. 浏览器是最天然的 AI agent 运行时

浏览器天生拥有：

用户当前任务上下文
多标签页信息
表单、文档、商品、网页的统一界面

把 Skills 放在 Chrome 里，比放在独立聊天框里更接近真实工作流。

3. 安全设计在一开始就被并入产品骨架

Google 没等到出事后再补，而是从第一版就把 confirmation、red-teaming、auto-update 写进描述。这说明它把 Skills 当成带潜在执行力的产品线，而不只是“快捷模板”。

实践指南

🟢 立即可用

高频多页面比较任务
- 做什么：把“帮我比较这几个商品的核心规格与取舍”存成 Skill。
- 为什么：这种任务最适合多标签页上下文。
- 注意：要控制输出格式，否则不同页面抽取维度可能不一致。
长文档信息扫描
- 做什么：把“给出 5 条关键结论 + 风险点 + 待确认数据”做成固定 Skill。
- 为什么：重复读 PDF / 长文场景很高频。
- 注意：如果页面结构变化大，抽取结果可能不稳定。
电商 / 成分 / 预算筛选
- 做什么：在多个商品页上运行同一套约束 prompt。
- 为什么：这是消费者最容易体会到价值的场景。
- 注意：如果页面信息不全，结论会受源站质量限制。

🟡 需要适配

团队共享工作流
- 目前原文没提团队级 Skill sharing。
- 如果没有组织层共享，Skills 更像个人 productivity 资产，而不是团队 SOP。
企业策略控制
- 原文没提 RBAC、审计、管理后台。
- 对企业来说，这决定它能不能从个人功能升级为组织工具。

🔴 注意事项

Skill 不是 agent plan。 它更像带上下文的 prompt macro，还不是完整多步自治代理。
多标签页上下文容易放大幻觉。 如果多个页面冲突或噪声大，模型可能生成看似合理但其实混淆的信息。
敏感动作确认只是底线，不是万能保障。 一旦 Skill 设计得含糊，用户可能仍会机械确认。

横向对比

话题	本文观点/能力	Anthropic Routines / Skills 方向	Microsoft / Google Workspace 助手
核心单位	浏览器内 Skill	开发或 agent 流程模板	文档/会议/办公助手
运行上下文	当前页 + 多标签页	项目目录 / 工具链 / 会话	Office / Workspace 文档栈
用户入口	Chrome	CLI / agent 产品	SaaS 生产力套件
主要价值	高频网页工作流复用	专业任务流程复用	办公内容生成与协作
风险点	浏览器权限与误操作	自动化执行风险	企业数据权限与合规

批判性分析

局限性

这篇文章没说的，比说的更值得盯。

没有团队共享与版本管理。 如果 Skill 只能个人保存，它更像个人效率工具，不是组织级 workflow system。
没有可观测性描述。 企业要知道 Skill 调了什么、对哪些页面生效、失败率怎样，目前原文没给。
没有能力边界。 文中只展示“分析与比较”，但没有明确说 Skills 能否进行多步操作、条件判断、外部系统调用。

适用边界

最适合的，是高频、结构相似、对网页上下文强依赖的任务，比如比价、摘要、资料扫描。

不太适合的，是需要高精度事务执行、复杂状态管理或强审计要求的流程。那些场景里，单靠 prompt 包装成 Skill 还不够。

潜在风险

Prompt drift：网页结构一变，原来好用的 Skill 可能 silently degrade。
过度信任浏览器 AI：用户可能把“可复用”误以为“稳定可靠”。
入口层锁定：一旦用户习惯在 Chrome 里沉淀 Skills，Google 就不再只是提供模型，而是在占领 workflow layer。

独立观察

这条更新和最近 Anthropic 的 Routines、Claude Code 社区热点是同一条暗线，行业在把 prompt 工程升级成工作流工程。
Chrome 是最有资格做这件事的平台之一，因为它已经天然拥有页面、标签页、账户同步、权限系统和更新通道。
真正值得警惕的是，这类功能一旦做顺了，用户会逐渐不再“打开 AI app”，而是在完成任务的入口处直接调用 AI。这会重排整条产品分发链。

如果说过去两年 AI 产品拼的是“谁回答得更像人”，那从 Chrome Skills 开始，新的比赛会更像是，谁能把高频 AI 动作嵌进用户已经离不开的工作界面里。 Google 这一步，就是在抢那个位置。