夜雨聆风
又可以卸载一堆插件了,Chrome集成Skill了
这两年大家总在讨论 AI 产品的下一步。有人盯着模型榜单，有人盯着 Agent，还有人盯着更长的上下文。
但 Google 这次在 Chrome 上做的事，方向很不一样。
它没有继续往浏览器里塞一个更花哨的聊天框，而是把用户反复使用的 prompt，直接做成了可以随时调用的 Skill。看上去像个小功能，实际上是在重写浏览器和 AI 的关系。
说得更直白一点：浏览器开始不只是展示网页，而是要接管网页上的一部分工作流了。
这次发布了什么
Google 在 Chrome 里推出了一个新能力，叫 Skills in Chrome。
它的核心逻辑很简单：当你在 Chrome 里的 Gemini 中写出一个很好用、以后还会重复使用的 prompt，你可以直接从聊天历史里把它保存成一个 Skill 。下次再遇到类似任务，不需要重新组织语言，也不需要去翻旧对话，直接在 Gemini 里输入 /，或者点一下 +，就能把这个 Skill 调出来。
更关键的是，这个 Skill 不是只对当前输入框生效。
它可以直接运行在你正在浏览的页面上，也可以结合你手动选中的多个标签页一起工作。也就是说，它调用的不是抽象的文本上下文，而是浏览器当前真实存在的页面上下文。
Google 同时还上线了一套现成可用的 Skill 库。用户可以直接把这些模板保存到自己的技能库里，也可以继续改 prompt，把它们调整成更适合自己习惯的版本。
这一步的产品含义很清楚：Google 想把用户最常用的 AI 操作，从一次次临时输入，升级成浏览器里的复用能力。
为什么这不是提示词收藏夹
很多人第一眼会觉得，这不就是“保存提示词”吗？
表面上看很像，底层逻辑完全不是一回事。
提示词收藏夹，本质上只是一个静态仓库。你把一段文本存进去，等下次需要的时候再翻出来复制、粘贴、微调。它能解决的是“别忘了这段话”，但解决不了“这件事怎么更顺手地完成”。
Chrome Skills 处理的是后一个问题。
它把 prompt 从一段需要手动搬运的文本，变成了一个带触发入口的动作模块。你不再需要每次都重复说“帮我把这篇菜谱改成纯素版本”“帮我比较这几个页面里的产品差异”“帮我提炼这份长文档的重点”。你只需要触发对应 Skill，浏览器就会把当前页面或者多个标签页一起交给它处理。
这意味着 prompt 的产品形态变了。
过去的 prompt，更像聊天时临时写下的一段说明。现在的 prompt，开始变成一种轻量工作流资产：
- 1. 可以保存。
- 2. 可以反复调用。
- 3. 可以在真实页面上下文里运行。
- 4. 可以继续修改，慢慢迭代成更适合自己的版本。
这和“收藏一段好用的话术”不是一个量级。
它更接近于把用户的高频操作，做成浏览器里的微型自动化能力。
真实使用场景
Google 官方给的几个例子都不复杂，但都很典型，因为它们正好卡在“重复、琐碎、需要上下文”的交界处。
1. 看菜谱时，直接生成纯素替代方案
以前看到一篇菜谱，想把里面的鸡蛋、黄油、牛奶替换成纯素做法，通常要经历几个步骤：复制原文，打开 AI 工具，粘贴内容，再补一句“帮我改成 vegan 版本”。
现在如果这个需求已经被保存成 Skill，你只要在页面上直接调用它，浏览器就能基于当前内容完成改写。
省下来的不是几秒钟输入时间，而是一次完整的任务切换。
2. 打开多个商品页，直接做横向对比
真正让人头疼的，不是单个商品页的信息太多，而是同类商品分散在多个标签页里。参数、价格、优惠、配送时效、评价重点，全都得自己来回切。
如果浏览器已经有一个“多标签页商品对比” Skill，这件事的流程就会变得很顺：你选中几页商品页，触发 Skill，让它统一抓关键字段，最后给出并排对比结果。
这里最关键的不是总结能力，而是多标签页上下文。
这类任务放在普通聊天框里，其实并不顺手，因为聊天工具天然不知道你当前开了哪几个页面。浏览器知道，这就是它的天然优势。
3. 面对长文档时，先抽重点再决定要不要细读
很多人每天会遇到大量低价值密度但不得不看的内容：方案文档、行业报告、产品更新说明、长篇 FAQ 。
这种内容最消耗时间的，不是理解，而是判断“值不值得往下看”。
如果你能直接在当前页面上调用“快速扫描重点” Skill，先得到结构化摘要、核心结论和几个最值得看的段落，阅读决策会快很多。
这会让浏览器里的信息处理路径发生变化：先由 AI 做一次压缩，再决定要不要投入完整注意力。
这对浏览器和 AI 产品意味着什么
这次更新真正有意思的地方，不在于它解决了某一个孤立场景，而在于它透露了浏览器接下来的角色变化。
过去很长一段时间，浏览器更像一个网页容器。
你用它打开页面、切换标签、搜索信息、填写表单，但真正的“处理动作”大多发生在别处。你要总结内容，就切到 AI 聊天工具；你要整理资料，就切到文档工具；你要做比较分析，就再开一个标签页慢慢搬。
Chrome Skills 在尝试做的，是把这些原本分散在外部工具里的轻处理动作，重新拉回浏览器内部。
这会带来三个层面的变化。
1. 浏览器从内容入口，变成工作流入口
以前浏览器只是“信息到达”的地方，现在它开始变成“任务启动”的地方。
你不是先想“我要打开哪个 AI 工具”，而是在当前页面上直接发起一个动作。这个动作可能是总结、比较、提炼、改写，也可能是下一步更复杂的自动化处理。
一旦这个入口成立，浏览器的价值就会从“访问互联网”升级成“调度互联网内容”。
2. Prompt 从会话文本，变成产品能力
AI 产品这两年的一个典型问题是：很多能力其实都埋在 prompt 里，但 prompt 太脆弱，太依赖用户记忆，也太依赖每次重新组织语言。
Google 这次做的，本质上是在把 prompt 产品化。
它不再是一段你临时敲出来的说明，而是一个可以沉淀、复用、修改、触发的能力模块。对用户来说，这会带来更强的可重复性；对产品来说，这意味着 AI 终于可以从“每次重来”的会话模式，往“持续积累”的工作流模式走。
3. 上下文不再只来自聊天记录，而来自浏览环境
普通 AI 聊天产品的上下文，主要来自你输入了什么、上传了什么、刚才说过什么。
浏览器的上下文更原生。
它天然知道你在看什么页面、同时打开了哪些标签、选中了哪些内容、任务发生在什么网页结构里。这种上下文不是用户额外补充的，而是操作过程本身自带的。
谁能把这一层上下文利用好，谁就更接近真正好用的 AI 工作流产品。
国内产品可以学什么
如果把这次更新只理解成“Chrome 新增了几个 AI 捷径”，那就低估它了。
对国内做浏览器、 AI 助手、搜索、办公工具的人来说，这里面至少有几个很值得抄作业的方向。
1. 不要只做聊天入口，要做任务入口
很多 AI 产品现在默认的交互起点还是输入框。用户先打开产品，再想清楚问题，再把需求翻译成 prompt 。
这条路径没错，但很重。
更轻的方式是：让用户先做事，在做事过程中再调用 AI 。
当 AI 的入口嵌进页面、文件、标签页、表单、搜索结果时，用户的感知会从“我去用一下 AI”，变成“这件事本来就该这么做”。这两者的留存和使用频率，通常不是一个级别。
2. Prompt 不能只被保存，必须能被迭代
很多产品已经在做提示词模板库，但问题也很明显：它们更像素材市场，不像工作流系统。
用户看着很热闹，真正长期留下来的模板并不多。原因很简单，能长期复用的 prompt，往往不是别人现成写好的，而是你在反复使用中慢慢修出来的。
Google 这次把“从聊天历史里保存”“后续继续改 prompt”这两件事连到了一起，这一点很重要。
真正有价值的不是模板数量，而是用户有没有机会把一个好用的动作逐步打磨成自己的系统资产。
3. 上下文感知会成为体验分水岭
浏览器、文档工具、表格工具、协同平台，其实都掌握着自己的上下文。
问题不在于有没有模型，而在于这些上下文有没有被接进模型调用链路。
一个只会回答问题的 AI，很容易同质化；一个能理解“你正在处理什么任务”的 AI，体验会完全不同。
接下来谁能在产品里把页面上下文、文件上下文、任务上下文、历史操作上下文接起来，谁就更容易做出真正有黏性的 AI 功能。
最后看一眼这件事的真正方向
Chrome Skills 看起来只是给浏览器加了一个小能力，实际上它指向的是更大的变化。
浏览器不再只是网页展示层，而是在慢慢变成一个 AI 调度层。
用户每天最常见的信息入口，本来就在浏览器里；如果 AI 能在这里被更顺滑地调用、保存、复用、迭代，那么很多以前必须切换到外部工具才能完成的操作，都会重新回流到浏览器内部。
这才是这次更新最值得关注的地方。
Google 不是单纯想让你少打一段 prompt，而是想把 prompt 这件事本身，做成浏览器里的基础设施。