加载失败
这篇文章讨论的是 Google 在 Chrome 里给 Gemini（Google 的聊天式 AI）加入的 Skills：把常用 prompt 封装成一键动作，用来处理网页内容、表单、邮件和 Google Drive（Google 的云盘）里的资料。评论里有人把它类比成 bookmarklets（浏览器书签脚本）和 Chrome Extension（Chrome 扩展），也有人联想到 Claude Code（Anthropic 的编程助手）接上 Chrome MCP（让模型读取浏览器上下文的接口）。支持者主要看重它能把重复的回复、摘要、旅行导入、Git 流程等自动化；反对者则担心权限过大、prompt injection（提示词注入）和网站流量被 AI 中介层截走。整场讨论也延伸到 LLM 训练后为什么总显得更像“助手”而不是“机器”，以及 Google 为什么会把这种入口直接放进浏览器里。
很多人把这看成把反复复制粘贴的 prompt 直接变成按钮，最适合处理固定格式的琐碎任务。评论里举了写 alt text、把旅行/航班确认导入 TripIt、加到 calendar/Google Keep、处理表单、生成客服/营销回复、以及 commit/push 流程等例子。对这些人来说，浏览器内置的一键动作比手工复制 prompt、单独装扩展或重新写一遍都更省事。也有人觉得这能鼓励更多工具作者把自己常用的工作流封装成可复用技能。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
有一类评论是在吐槽模型总爱装成 helpful assistant，而用户明明想要的是冷冰冰、少废话、别加表情和幽默的输出。有人讲了把模型叫作机器后，它反而强调自己是 Claude、拒绝按命令办事的例子，说明对话式 AI 的语气和服从边界经常和用户预期冲突。另一些评论把这种现象归因于 post-training 和 human preference 数据，认为这不是所谓 emergent property，而是训练阶段刻意塑造出来的。也有人想在 prompt 里直接去掉阿谀奉承，强调自己更想要的是 system prompt 里明确的行为约束。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
最强烈的担忧是权限模型太粗糙：大家希望只给某个 Google Drive 文档集合只读权限，而不是一开就把所有数据的读写权限都交出去。评论还指出，这类功能如果能对网页内容下指令，就天然接近 prompt injection 风险，恶意网页或误点可能把 Gemini 引到错误动作上，尤其一旦它接入 Gmail 之类敏感服务就更危险。还有人担心第三方 Skills 或复制粘贴会让它变成另一个可扩散的攻击面，所以觉得功能太早、太冒险。即便有人觉得有用，很多人也明确表示会先继续用 Claude Code、Chrome MCP 或更保守的方案。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
不少人对 Google 的动机非常警惕，觉得这类公告本质上是在把用户更深地拉进 Gemini 和 Chrome 生态。一个常见推测是，这会带来更多数据、更多广告展示，以及把更重度用户推向 Google AI Plus 之类订阅。另一层批评是，浏览器和 AI 正在替代网站原本的交互入口，让内容创作者更难把用户留在自己的页面里，最终变成平台吃掉网页。因此，大家看到的不只是一个工具，而是 Google 对开放 web 流量和变现方式的进一步重构，也有人因此转向更依赖 local models。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
另一派把它理解成浏览器原生的 automation 层，类似 bookmarklets 或把脚本塞进 Chrome 的 AI 集成里。理由是很多网站已经没有 API，或者故意对 robots 不友好，导致跨站搬运信息、做自动化任务越来越难。有人甚至举例说过去能工作的脚本到 2026 可能已经失效，所以把这种能力放进主流浏览器反而能帮助打通数据孤岛。反对者当然马上指出，这会带来不可靠和资源浪费，但支持者认为这是对抗碎片化 web 的现实办法。
system prompt: LLM 的高优先级指令，用来设定角色、语气、边界和行为规则。
prompt injection: 攻击者把隐藏指令塞进网页或输入中，诱导模型执行意料外的动作。
permission model: 权限控制机制，决定模型或工具能读什么、写什么、以及访问范围有多细。
UBI（Universal Basic Income）: 全民基本收入；讨论里被当作 AI 大规模替代工作后的潜在补偿方案。