docs: remove vendor-specific webskills framing

2026-06-14 14:54:05 +08:00
14 changed files with 148 additions and 505 deletions
@@ -32,7 +32,7 @@
 Demo 只做科普对比，不做现场代码改造。
-建议任务设定为：在一个后台系统里完成“创建订单管理模块”，包括创建词条、创建菜单、绑定角色权限。
+建议任务设定为：在一个电商页面里完成“搜索商品、加入购物车、进入结算”这一类常见流程。
 对比讲法：
@@ -44,7 +44,7 @@ Demo 只做科普对比，不做现场代码改造。
 ### 4. 核心概念：WebMCP 是什么
-WebMCP 可以理解为“网页给 AI Agent 暴露的一组工具说明书”。
+WebMCP 可以理解为“网页给 AI Agent 暴露的一组工具清单和接口描述”。
 一个工具通常包含：
@@ -56,25 +56,7 @@ WebMCP 可以理解为“网页给 AI Agent 暴露的一组工具说明书”。
 可以用 `document.modelContext.registerTool` 作为概念示例。需要强调：WebMCP 仍是实验性方向，适合作为渐进增强，不应该假设所有浏览器都已经稳定支持。
-### 5. 核心概念：任务流程说明
+### 5. Chrome 新特性快闪
 WebMCP 解决“能调用什么工具”。复杂任务还需要一层任务流程说明，解决“应该按什么步骤走”。
 这里不要把这层流程能力包装成官方浏览器标准或 WebMCP 同级概念。更稳妥的表述是：在应用实践中，可以把复杂任务沉淀成 skill、recipe、runbook 或任务说明，让 Agent 先理解流程，再按步骤调用页面暴露的工具。
 例如用户说“帮我申请价保”，这不是一个单工具任务。它可能需要：
 1. 去订单页查订单
 2. 拿到订单号
 3. 跳到价保页
 4. 填申请单
 5. 最后让用户确认提交
 任务流程说明的角色就是告诉 Agent 这些流程规则。可以用一句话总结：
 > WebMCP 是工具箱，任务流程说明是操作手册。
 ### 6. Chrome 新特性快闪
 这一部分只做快速展示，不展开细节：
@@ -87,7 +69,7 @@ WebMCP 解决“能调用什么工具”。复杂任务还需要一层任务流
 这一章服务于主线：Chrome 正在让 Web 同时面向人、开发者工具和 AI Agent 进化。
-### 7. 收束：开发者现在该记住什么
+### 6. 收束：开发者现在该记住什么
 - Web 页面未来不只是给人看的，也会被 Agent 使用。
 - 语义化、可访问性、清晰的业务函数边界会变得更重要。
@@ -1,45 +0,0 @@
 # 现在怎么落地：先做 Agent 友好，不赌单一 API
 <div class="grid grid-cols-2 gap-8 mt-8">
 <div class="card-green">
 <div class="font-semibold mb-3">现在就值得做</div>
 <div class="space-y-2 text-sm">
 - 补语义化 HTML 与可访问性
 - 梳理核心业务动作边界
 - 把复杂流程沉淀成任务说明
 - 在内部系统试验 WebMCP / SDK
 - 给高风险动作加确认和审计
 </div>
 </div>
 <div class="card-red">
 <div class="font-semibold mb-3">暂时不要这样做</div>
 <div class="space-y-2 text-sm">
 - 把实验 API 当生产强依赖
 - 假设 Safari / Firefox 已支持
 - 让 Agent 自动执行不可逆操作
 - 用工具调用绕过权限系统
 - 忽略降级和人工接管路径
 </div>
 </div>
 </div>
 <!--
 这一页讲落地策略。
 因为 WebMCP 和部分内置 AI 能力仍然在实验阶段，所以我们不能把这场分享讲成“明天所有项目都要接这个 API”。这样讲既不准确，也不负责任。更稳妥的落地策略是：先做 Agent 友好，不赌单一 API。
 现在就值得做的事情有几类。第一，补语义化 HTML 和可访问性，因为这本来就是现代 Web 的基本功，也能让 Agent 更容易理解页面。第二，梳理核心业务动作边界，比如创建、查询、提交、审批、导出，这些动作未来都有可能成为可调用能力。第三，把复杂流程写成任务说明或操作手册，让 Agent 知道什么顺序是安全的。第四，在内部后台、Electron 或受控环境里试验 WebMCP 或相关 SDK。第五，对高风险动作加确认、权限和审计。
 同时，暂时不要做的事情也要说清楚。不要把实验 API 当成生产强依赖，不要假设 Safari、Firefox 或各种 WebView 都已经支持，不要让 Agent 自动执行不可逆操作，不要用工具调用绕过原有权限系统，也不要忽略降级和人工接管路径。
 如果我们把这件事放到工程管理里，可以这样落地：先选一个低风险、内部可控的场景，比如后台里的查询、草稿生成、菜单创建、报表筛选；先暴露只读或低风险工具；然后加日志、加确认、加灰度；最后再考虑是否扩展到更高风险流程。
 这页的核心是帮团队把兴奋感转成工程判断：方向要跟，边界要稳。越是自动化，越不能牺牲安全和可回退性。
 -->
@@ -1,56 +0,0 @@
 # Chrome 新特性快闪：三条线一起推进
 <div class="grid grid-cols-3 gap-5 mt-8">
 <div class="card-green">
 <div class="font-semibold mb-3">Agent 交互</div>
 <div class="space-y-2 text-sm">
 - WebMCP
 - 可复用任务能力
 - Prompt API / Built-in AI
 </div>
 </div>
 <div class="card-blue">
 <div class="font-semibold mb-3">开发者工具</div>
 <div class="space-y-2 text-sm">
 - Modern Web Guidance
 - DevTools for agents
 - Baseline
 </div>
 </div>
 <div class="card-amber">
 <div class="font-semibold mb-3">体验升级</div>
 <div class="space-y-2 text-sm">
 - HTML in Canvas
 - View Transitions
 - Navigation API
 </div>
 </div>
 </div>
 <div class="mt-8 text-2xl font-bold">
 主线不是“Chrome 又加了几个 API”，而是 Web 的使用者和开发方式都在变。
 </div>
 <!--
 这一页把 Chrome 新特性做一次快闪归类，帮助大家从一堆名字里抓住结构。
 第一条线是 Agent 交互。WebMCP、可复用任务能力、Prompt API 或 Built-in AI 这些方向，都在回答同一个问题：当 AI 进入浏览器和页面之后，网页怎么参与这种新交互。这里要注意，不要把“可复用任务能力”包装成 WebMCP 标准的一部分，它更像产品层或工具层对任务流程的组织方式。
 第二条线是开发者工具。Modern Web Guidance 和 DevTools for agents 不是给终端用户看的，而是给开发者和编码 Agent 用的。它们要解决的问题是：模型知识会滞后，页面运行时很复杂，Agent 不能只靠静态代码猜测现代 Web 应该怎么写、怎么调试。
 第三条线是体验升级。HTML in Canvas、View Transitions、Navigation API 这些能力，仍然是传统 Web 平台演进的一部分。它们让 Web 页面可以做出更自然、更连续、更沉浸的体验，也让 Web 应用更接近用户对原生应用的期待。
 所以这不是几个孤立 API，而是 Chrome 在同时推动三件事：Agent 能用 Web，开发者能更好地构建 Web，用户能获得更自然的 Web 体验。
 下面我们先看开发者工具这条线的第一个例子：Modern Web Guidance。
 -->
@@ -1,39 +1,21 @@
-# 开发者现在该记住什么？
+# 收尾：建立团队的 Chrome 更新雷达
 <div class="mt-8 space-y-4 text-sm">
-<div class="p-4 rounded-lg bg-emerald-500/8 border border-emerald-500/25">
+<div class="p-4 rounded-lg bg-white/5 border border-white/10">
-Web 页面未来不只是给人看的，也会被 Agent 理解、调用和操作。
+Chrome 更新不是新闻流，而是 Web 产品能力池。
 </div>
-<div class="p-4 rounded-lg bg-blue-500/8 border border-blue-500/25">
+<div class="p-4 rounded-lg bg-white/5 border border-white/10">
-语义化、可访问性、清晰的业务函数边界，会变成新的工程基础设施。
+真正的价值是筛选、验证、降级和沉淀，而不是追逐每一个新 API。
 </div>
-<div class="p-4 rounded-lg bg-amber-500/8 border border-amber-500/25">
+<div class="p-4 rounded-lg bg-white/5 border border-white/10">
-WebMCP 的方向是从“AI 猜 UI”走向“网页主动提供能力”。
+建议形成固定节奏：每月扫描一次，季度做一次 demo day，成熟能力进入技术方案模板。
 </div>
 <div class="p-4 rounded-lg bg-red-500/8 border border-red-500/25">
 越自动化，越需要权限、确认、审计和渐进增强。
 </div>
 </div>
 <!--
-最后这一页做收束。
+最后强调：浏览器能力变化很快，团队需要的是可持续的更新机制。把 Chrome 新能力当作产品和工程共同评估的素材，而不是纯前端知识点。
 今天我们讲了很多名字：WebMCP、任务流程说明、Modern Web Guidance、DevTools for agents、HTML in Canvas、View Transitions、Navigation API、Baseline。但我希望大家真正带走的不是这些名词，而是一条主线。
 第一，Web 页面未来不只是给人看的，也会被 Agent 理解、调用和操作。所以我们写页面时，不只要考虑用户能不能看懂，也要考虑页面能力能不能被结构化描述，能不能被安全调用。
 第二，语义化、可访问性和清晰的业务函数边界，会变成新的工程基础设施。过去这些能力更多被看作体验优化或规范要求，接下来它们会直接影响 Agent 能不能可靠理解和操作我们的应用。
 第三，WebMCP 代表的方向，是从“AI 猜 UI”走向“网页主动提供能力”。这会让复杂业务系统里的 AI 操作更快、更准、更可控。但它不是魔法，也不是马上覆盖所有浏览器的稳定能力，所以我们要用渐进增强的方式看待它。
 第四，越自动化，越需要边界。权限、确认、审计、降级和人工接管，不是上线前补一补的细节，而是设计阶段就要考虑的安全基础。尤其是财务、审批、删除、提交这类动作，必须让用户保留最终控制权。
 所以最后给开发者一句话：不要只问“Chrome 新增了什么 API”，而要问“我的网站准备好被 Agent 使用了吗？”如果这个问题能进入团队的技术设计和代码评审，这场分享就有价值了。
 谢谢大家。
 -->
@@ -1,42 +1,33 @@
-# 任务流程说明：工具箱之外，还要操作手册
+# 模拟展示 4：团队落地清单
-<div class="mt-8">
+<div class="grid grid-cols-2 gap-8 mt-8">
 ```mermaid {scale: 0.72}
 flowchart LR
    A[用户目标] --> B[识别任务类型]
    B --> C[读取流程说明]
    C --> D[打开必要页面]
    D --> E[调用工具]
    E --> F[关键动作交给用户确认]
 ```
 </div>
 <div class="grid grid-cols-2 gap-6 mt-7">
 <div class="card-blue">
 <div class="font-semibold mb-2">WebMCP</div>
 <div class="text-sm op-70">解决“有哪些工具可以调用”。</div>
 </div>
 <div class="card-green">
-<div class="font-semibold mb-2">任务流程说明</div>
+<div class="font-semibold mb-3">本周可做</div>
-<div class="text-sm op-70">解决“复杂任务应该按什么流程走”。</div>
+<div class="space-y-2 text-sm">
 - 建一个 Chrome 更新跟踪文档
 - 选 1 个 DevTools 工作流做内部演示
 - 为 1 个新能力写最小 demo
 - 标注生产可用与仅实验的边界
 </div>
 </div>
 <div class="card-red">
 <div class="font-semibold mb-3">不要直接做</div>
 <div class="space-y-2 text-sm">
 - 只因 Chrome 支持就上线
 - 忽略 Safari / Firefox 用户
 - 把实验能力写进核心链路
 - 跳过权限与隐私评估
 </div>
 </div>
 </div>
 <!--
-这一页讲任务流程说明。这里我会先特别说明：这不是 WebMCP 同级的官方浏览器概念，也不是一个标准 API 名称。它更像我们在应用实践里需要补上的流程层能力。
+这一页把分享从“知道了”落到“接下来做什么”。建议最后留一个简单清单，让团队每月复盘一次 Chrome 更新，并把值得试验的能力进入工程 backlog。
 WebMCP 解决的是“有哪些工具可以调用”。但真实任务往往不是一个工具就能完成。比如用户说：“帮我申请价保。”这句话背后可能包含很多步骤：先去订单页查订单，确认订单是否符合规则，拿到订单号，再跳到价保页，填写申请信息，最后还要停下来让用户确认提交。
 如果只给 Agent 一堆工具，它仍然可能不知道流程顺序。它可能先调了不该先调的工具，也可能过早提交，或者漏掉关键确认步骤。所以在应用实践里，我们通常还需要一层流程说明，可以叫 recipe、runbook、task flow，或者就叫操作手册。它的作用是告诉 Agent：遇到这类用户目标时，应该按什么顺序推进，每一步调用什么能力，哪一步必须停下来交给用户确认。
 所以可以用一句话总结：WebMCP 是工具箱，任务流程说明是操作手册。工具箱让 Agent 有能力做事，操作手册让 Agent 知道怎样安全、稳定、按业务规则完成一件事。
 这也是为什么未来前端不只要写 UI 组件，还要沉淀任务语义、页面能力和流程规则。我们写的不是随便贴给模型看的提示词，而是应用自身的可操作结构。这个结构越清晰，Agent 越不需要猜，风险也越容易被控制。
 到这里，Agent 交互这条线就讲完了。接下来我们把视角拉宽，看 Chrome 这次还有哪些和开发工具、用户体验相关的新方向。
 -->
@@ -1,52 +1,32 @@
-# WebMCP 的两种接入方式
+# 模拟展示 2：DevTools 排查链路
-<div class="grid grid-cols-2 gap-6 mt-7">
+<div class="mt-8">
-<div class="card-blue">
+```mermaid {scale: 0.82}
-<div class="font-semibold mb-3">声明式：增强表单语义</div>
+flowchart LR
-
+    A[用户反馈卡顿] --> B[Performance 录制]
-```html
+    B --> C[定位长任务]
-<form tool-description="提交酒店筛选条件">
+    C --> D[Network 查资源瀑布]
-  <input
+    D --> E[Coverage 查无效代码]
-    name="city"
+    E --> F[形成优化清单]
    tool-parameter-description="目的地城市" />
 </form>
 ```
-<div class="text-xs op-65 mt-3">适合已有 HTML 表单和渐进增强。</div>
+</div>
 <div class="grid grid-cols-2 gap-6 mt-8">
 <div class="card">
 <div class="font-semibold mb-2">演示素材</div>
 <div class="text-sm text-gray-400">准备一个加载慢、交互卡顿、资源偏大的页面作为示例。</div>
 </div>
 <div class="card-green">
-<div class="font-semibold mb-3">命令式：注册业务工具</div>
+<div class="font-semibold mb-2">观众收获</div>
-
+<div class="text-sm text-gray-400">把 DevTools 从“会打开”变成“按链路定位问题”。</div>
 ```ts
 document.modelContext.registerTool({
  name: 'create_order_menu',
  description: '创建订单管理菜单',
  inputSchema,
  execute: createOrderMenu,
 })
 ```
 <div class="text-xs op-65 mt-3">适合复杂业务动作和后台系统。</div>
 </div>
 </div>
 <div class="mt-7 card-amber text-sm">
 WebMCP 仍属于实验性方向，实际接入要做能力检测、渐进增强和人工确认。
 </div>
 <!--
-这一页讲 WebMCP 怎么接入。
+这一页用于现场演示细节。建议讲一个真实或模拟页面，从 Performance 开始抓主线程问题，再用 Network 和 Coverage 找资源问题，最后输出可执行的优化清单。
 从公开资料和演示里可以看到，WebMCP 的接入大体可以分成两个方向。第一种是声明式接入，也就是在已有 HTML 表单上补充工具描述和参数描述。这样 Agent 不只是看到一个 input，而是知道这个 input 对应什么业务含义。例如这个字段不是普通文本框，而是“目的地城市”；这个表单不是普通表单，而是“提交酒店筛选条件”。
 第二种是命令式接入，也就是通过 JavaScript 注册工具。工具里会包含 name、description、input schema 和 execute 函数。Agent 根据用户意图选择工具，传入结构化参数，然后页面执行我们已经定义好的业务逻辑。对复杂应用来说，这个方式更像是把现有业务函数安全地暴露给 Agent。
 对高级前端来说，这个区别很关键。声明式方式适合增强已有表单，成本低，和语义化 HTML 的方向一致；命令式方式适合后台系统、复杂流程、跨页面业务，因为它可以复用已有的 service、store、接口封装和权限判断。也就是说，我们不一定要重写一套 AI 专用逻辑，而是把原有能力以更清晰的 schema 暴露出来。
 但这里一定要提醒大家：WebMCP 仍然是实验性和快速演进中的方向，不能把它当成所有浏览器都稳定支持的能力。真正落地时，第一要做 feature detection，也就是先判断环境是否支持；第二要做渐进增强，不支持时仍然回到正常 UI 流程；第三，高风险动作必须有人类确认，不能让 Agent 自动越过权限、审计和确认边界。
 讲到这里，我们已经有工具了。但真实任务往往不是一个工具就能完成，所以下一页要补一个实践层问题：复杂任务需要流程说明。
 -->
@@ -1,48 +1,38 @@
-# WebMCP：网页给 Agent 的工具说明书
+# 模拟展示 3：Web 平台能力评估卡
 <div class="grid grid-cols-2 gap-8 mt-8">
 <div class="card-blue">
-<div class="font-semibold mb-3">一个工具通常描述什么？</div>
+<div class="font-semibold mb-3">能力示例</div>
 <div class="space-y-2 text-sm">
- 名字：工具叫什么
+- CSS 新布局与交互能力
- 描述：什么时候应该调用
+- View Transitions
- 参数：需要哪些输入
+- File System / Clipboard / Share APIs
- 执行：调用后做什么业务逻辑
+- PWA 安装与离线体验
- 返回：成功、失败和结果信息
+- 本地 AI 与浏览器内置能力探索
 </div>
 </div>
-<div class="card-green">
+<div class="card">
-<div class="font-semibold mb-3">它改变了什么？</div>
+<div class="font-semibold mb-3">评估维度</div>
-<div class="space-y-2 text-sm">
+<div class="space-y-2 text-sm text-gray-300">
- UI 改版不等于能力失效
+- 用户价值：解决什么真实问题？
- Agent 不再猜按钮位置
+- 兼容性：Chrome-only 还是跨浏览器？
- 业务边界由开发者定义
+- 降级方案：不可用时如何处理？
- 权限、确认、审计可以前置设计
+- 风险：权限、隐私、性能、安全
 </div>
 </div>
 </div>
-<div class="mt-8 text-2xl font-bold">
+<div class="mt-8 card-amber text-sm">
-从“AI 操作页面”升级为“页面向 AI 暴露能力”。
+推荐输出格式：能力名称 / Chrome 支持状态 / 业务场景 / Demo 链接 / 风险 / 下一步。
 </div>
 <!--
-这一页解释 WebMCP 的核心概念。
+这里可以把每个新 API 都变成一张评估卡。不要只问“能不能用”，而是问“能解决什么问题、什么时候可上线、不能用时怎么降级”。
 最简单的理解方式是：WebMCP 是网页给 AI Agent 的工具说明书。过去网页把最终渲染出来的 UI 给用户看，Agent 如果要操作，只能从这个 UI 反推背后的意图。WebMCP 的方向则是反过来：网页主动告诉 Agent，我有哪些可调用能力，每个能力叫什么，适合什么时候用，需要什么参数，执行后会返回什么结果。
 举几个例子会更好理解。一个电商页面可以暴露 add_to_cart 工具，参数是商品 ID、尺码和数量；一个后台系统可以暴露 create_menu 工具，参数是菜单名称、父级菜单、路由和权限标识；一个文档应用可以暴露 summarize_selection 工具，参数是当前选区和摘要长度。Agent 不需要猜按钮在哪里，它只需要判断用户意图和哪个工具匹配。
 这对前端开发者很重要。因为以前我们经常担心 AI 乱点页面：点错按钮、误删数据、跳过校验。但如果能力是我们主动暴露出去的，业务边界就能回到开发者手里。哪些动作可以给 Agent 调，哪些动作必须用户确认，哪些动作需要审计，哪些工具只在特定页面或特定权限下出现，这些都可以在设计阶段明确。
 所以 WebMCP 不是“让 AI 更会点按钮”。它真正代表的是一个更大的变化：网页从 UI 自动化，走向能力自动化。Agent 不再只是模仿人点页面，而是通过结构化工具参与业务流程。
 下一页我们看它大概怎么接入：一种偏声明式，一种偏命令式。
 -->
@@ -1,49 +1,44 @@
-# 同一个任务，三种完成方式
+# 模拟展示 1：快速扫一版 Chrome 更新
-<div class="grid grid-cols-3 gap-5 mt-7">
+<div class="grid grid-cols-3 gap-5 mt-8">
 <div class="card-blue">
 <div class="font-semibold mb-3">信息源</div>
 <div class="space-y-2 text-sm">
 - Chrome Developers Blog
 - ChromeStatus
 - DevTools Release Notes
 - MDN Baseline
 <div class="card">
 <div class="text-sm font-semibold text-blue-500 mb-2">方式 1</div>
 <div class="text-xl font-bold mb-2">看截图</div>
 <div class="text-sm op-70">逐屏识别、逐步点击、逐项填表。</div>
 <div class="mt-5 text-3xl font-bold">分钟级</div>
 <div class="text-xs op-60 mt-1">案例中 token 可到几十万级</div>
 </div>
 <div class="card-amber">
 <div class="text-sm font-semibold text-amber-500 mb-2">方式 2</div>
 <div class="text-xl font-bold mb-2">读结构</div>
 <div class="text-sm op-70">读取 DOM / 可访问性树，再定位控件。</div>
 <div class="mt-5 text-3xl font-bold">更快但脆</div>
 <div class="text-xs op-60 mt-1">复杂交互下仍可能点错或漏选</div>
 </div>
 <div class="card-green">
-<div class="text-sm font-semibold text-emerald-500 mb-2">方式 3</div>
+<div class="font-semibold mb-3">筛选标准</div>
-<div class="text-xl font-bold mb-2">调工具</div>
+<div class="space-y-2 text-sm">
-<div class="text-sm op-70">调用页面暴露的业务工具。</div>
+
-<div class="mt-5 text-3xl font-bold">秒级</div>
+- 是否默认启用
-<div class="text-xs op-60 mt-1">案例中约 30-40 秒、约 1.7 万 token</div>
+- 是否跨浏览器可用
-</div>
+- 是否影响现有代码
 - 是否带来明显产品收益
 </div>
 </div>
 <div class="card-amber">
 <div class="font-semibold mb-3">输出物</div>
 <div class="space-y-2 text-sm">
 - 3 个可试验能力
 - 2 个需要关注的变更
 - 1 个团队落地建议
 </div>
 </div>
 <div class="mt-7 card-blue text-sm">
 案例任务：后台系统内完成“创建订单管理模块”，包括词条、菜单、角色权限绑定。数据来自仓库原始实战材料，作为特定案例结果，不代表所有场景通用值。
 </div>
 <!--
-这一页用一个具体任务，把刚才三类方案的差异讲得更直观一些。
+这一页可以模拟现场打开 release notes。重点不是最新版本号，而是演示方法：先看默认启用与兼容性，再看是否影响我们现有业务，最后只挑少数真正需要行动的条目。
 我们假设有一个后台管理系统，任务是创建一个“订单管理模块”。听起来很简单，但拆开看其实有好几步：先创建词条，再创建菜单，再把菜单绑定到角色权限里。对熟悉系统的人来说，这可能就是几分钟的常规操作；但对 AI 来说，这里面包含多个页面、多个表单、树形结构、权限勾选、搜索和确认动作。
 如果用视觉识别，AI 需要一屏一屏截图。它要先看到菜单在哪里，再判断哪个是新增按钮，再识别表单字段，再填值，再点提交。这个过程有点像让一个人隔着截图远程操作电脑，能做，但非常绕。仓库里的实战材料里，这类方案可以完成任务，但过程是分钟级，token 消耗可以到几十万级。
 如果用 DOM 或可访问性树识别，它会更快一点，因为它不只是看图，而是读结构。但这并不等于稳定。复杂组件里有很多状态，页面结构也会随着权限和交互变化。实战材料里就提到过，结构识别方案在复杂菜单和权限操作里，仍然可能点错、漏选，甚至把不该删的东西删掉。
 如果用 WebMCP 思路，页面直接暴露“创建词条”“创建菜单”“绑定角色权限”这些工具。AI 不需要知道按钮在左边还是右边，不需要知道菜单有没有展开，它只需要根据用户目标选择正确的工具，传入参数，然后拿到执行结果。实战材料里，同类任务可以压到几十秒，token 也会明显下降。
 这里我要特别说明一下：页面上的数字不是行业通用基准，也不是说所有场景都会有完全相同的提升。它只是一个具体案例。但它说明了一个趋势：越复杂、越业务化、越高风险的系统，越不应该让 AI 在界面里猜；我们越应该把能力封装好，让 Agent 调用明确的能力。
 接下来，我们就进入核心概念：WebMCP 到底是什么。
 -->
@@ -1,49 +0,0 @@
 # DevTools for agents：让 Agent 看见真实浏览器
 <div class="grid grid-cols-2 gap-8 mt-8">
 <div class="card-blue">
 <div class="font-semibold mb-3">人类调试时看什么？</div>
 <div class="space-y-2 text-sm">
 - Console 错误
 - Network 请求
 - Performance 录制
 - Lighthouse 结果
 - Memory / Heap snapshot
 </div>
 </div>
 <div class="card-green">
 <div class="font-semibold mb-3">Agent 也应该看什么？</div>
 <div class="space-y-2 text-sm">
 - 页面真实渲染状态
 - 运行时错误和警告
 - 资源瀑布与接口失败
 - 性能瓶颈和内存线索
 - 扩展和多窗口调试上下文
 </div>
 </div>
 </div>
 <div class="mt-8 text-2xl font-bold">
 只把代码发给 Agent 不够，它还需要理解代码在浏览器里怎么运行。
 </div>
 <!--
 这一页讲 DevTools for agents。
 人类开发者调试 Web，不会只看源码。我们会打开 Console 看报错，打开 Network 看请求和瀑布图，打开 Performance 看主线程和长任务，打开 Lighthouse 看性能、可访问性和最佳实践，必要时还会看 Memory 和 Heap snapshot。
 但很多编码 Agent 只拿到代码上下文，它并不知道页面真实运行时发生了什么。代码看起来没问题，不代表页面真的渲染正确；接口写对了，不代表请求真的成功；组件逻辑合理，不代表交互不卡；构建通过，也不代表用户在浏览器里看到的是正确页面。
 DevTools for agents 的方向，就是把这些浏览器调试能力开放给 Agent，让它不只是“读代码”，还可以“看运行现场”。换句话说，Agent 不应该只基于文件做推理，它也应该能结合 Console、Network、Performance 和页面状态来判断问题。
 这会改变我们和 Agent 的协作方式。过去我们可能只是把错误栈贴给 AI，让它猜哪里错了；未来更合理的方式是让它连接真实浏览器环境，看到当前页面、当前请求、当前报错和当前性能瓶颈，再提出修改建议。
 举个例子，如果页面白屏，Agent 不应该只搜索代码里的 mounted 或 useEffect；它应该先看 Console 有没有运行时异常，再看 Network 有没有资源 404 或接口 500，再看页面是否真的挂载了根节点。这样调试会更接近一个高级前端真实排查问题的路径。
 -->
@@ -1,47 +0,0 @@
 # Modern Web Guidance：给编码 Agent 补现代 Web 知识
 <div class="grid grid-cols-2 gap-8 mt-8">
 <div class="card-red">
 <div class="font-semibold mb-3">问题</div>
 <div class="space-y-2 text-sm">
 - 浏览器能力每几周更新
 - 模型训练知识经常滞后
 - AI 容易写旧方案或复杂 polyfill
 - 兼容性和降级策略容易漏掉
 </div>
 </div>
 <div class="card-green">
 <div class="font-semibold mb-3">解法</div>
 <div class="space-y-2 text-sm">
 - 把现代 Web 指南装进 AI 工具
 - 查询 Baseline 和最佳实践
 - 给出 gotchas 与 fallbacks
 - 让 Agent 写“今天的 Web”
 </div>
 </div>
 </div>
 <div class="mt-8 card-blue text-sm">
 可以把它类比成：以前 Browserslist / Autoprefixer 帮构建工具查兼容性；现在 Modern Web Guidance 帮编码 Agent 查现代 Web 知识。
 </div>
 <!--
 这一页讲 Modern Web Guidance。
 我们现在用 AI 写前端代码，经常遇到一个矛盾：Chrome 和 Web 平台更新很快，但大模型的训练数据可能停留在过去。也就是说，我们在 2026 年问一个编码 Agent 写现代 Web，它可能仍然拿几年前的经验回答。结果就是，它会写旧语法、引入不必要的库，或者不知道某个现代 CSS 和 Web API 已经可以用了。
 Modern Web Guidance 的目标，就是把 Chrome 团队和社区维护的现代 Web 指南，作为技能包或知识包提供给编码 Agent。它不是替你写业务逻辑，也不是一个 UI 库；它更像一个本地的现代 Web 知识补丁。当 Agent 准备写代码时，它可以把现代 Web 的能力、兼容性、避坑点和降级方案注入上下文。
 可以用一个前端熟悉的类比来理解。以前 Browserslist 和 Autoprefixer 帮打包工具查目标浏览器，决定要不要加前缀、要不要转译。那时写代码的是人，构建工具负责查兼容性。现在写代码的人里多了 AI Agent，所以也需要一个机制帮 Agent 查现代 Web 知识，避免它用过时方案解决今天已经有原生能力的问题。
 举一个具体场景：你让 Agent 写一个弹出菜单，它可能会直接引入一个复杂的定位库，或者写一堆监听 scroll 和 resize 的坐标计算。如果它能检索到现代平台指南，就可能优先考虑 Popover API、Anchor Positioning，以及必要的 fallback。这样产出的不是“能跑的旧方案”，而是更接近今天平台能力的方案。
 所以这条线的价值不是炫技，而是工程治理：让团队里的 AI 代码产出更接近现代平台，而不是把历史包袱继续复制到新项目里。
 -->
@@ -1,39 +1,33 @@
-# 为什么 AI 操作网页会不可靠？
+# 分享大纲
-<div class="grid grid-cols-3 gap-5 mt-8">
+<div class="grid grid-cols-2 gap-6 mt-8">
-<div class="card-blue">
+<div class="card p-5">
-<div class="font-semibold mb-3">视觉识别</div>
+<div class="text-blue-400 text-sm font-semibold mb-2">01</div>
-<div class="text-sm op-75 mb-4">AI 看截图，猜按钮和输入框在哪里。</div>
+<div class="text-xl font-bold mb-2">Chrome 更新怎么看</div>
-<div class="text-xs op-65">通用性强，但慢、贵、受 UI 变化影响。</div>
+<div class="text-sm text-gray-400">Release Notes · ChromeStatus · Baseline · Origin Trials</div>
 </div>
-<div class="card-amber">
+<div class="card-green p-5">
-<div class="font-semibold mb-3">DOM / 可访问性树</div>
+<div class="text-emerald-400 text-sm font-semibold mb-2">02</div>
-<div class="text-sm op-75 mb-4">AI 读取结构，寻找元素再点击。</div>
+<div class="text-xl font-bold mb-2">Web 平台新能力</div>
-<div class="text-xs op-65">比视觉结构化，但复杂组件和隐藏状态仍会干扰。</div>
+<div class="text-sm text-gray-400">CSS · Web APIs · PWA · Media · AI-adjacent APIs</div>
 </div>
-<div class="card-green">
+<div class="card-amber p-5">
-<div class="font-semibold mb-3">WebMCP 工具调用</div>
+<div class="text-amber-400 text-sm font-semibold mb-2">03</div>
-<div class="text-sm op-75 mb-4">网页主动暴露工具，AI 调用明确能力。</div>
+<div class="text-xl font-bold mb-2">DevTools 工作流</div>
-<div class="text-xs op-65">把“猜 UI”变成“调业务能力”。</div>
+<div class="text-sm text-gray-400">Performance · Network · CSS Overview · Recorder</div>
 </div>
 <div class="card-red p-5">
 <div class="text-red-400 text-sm font-semibold mb-2">04</div>
 <div class="text-xl font-bold mb-2">落地与风险</div>
 <div class="text-sm text-gray-400">兼容性 · 安全边界 · 灰度策略 · 团队清单</div>
 </div>
 <div class="mt-8 text-2xl font-bold">
 AI 擅长结构化信息，不擅长在复杂 UI 里猜下一步。
 </div>
 <!--
-这一页开始讲问题：为什么 AI 操作网页经常不可靠？
+建议讲法：先讲信息入口，再讲能力分类，最后讲如何落地。这样听众不会只记住几个孤立 API，而是学会建立自己的 Chrome 更新雷达。
 现在让 AI 操作网页，大概有三类方案。第一类是视觉识别。它的方式很直观：AI 不断看截图，判断按钮在哪里、输入框在哪里、下一步应该点哪里。这种方式最大的好处是通用，不需要你改页面，任何网站理论上都能试一试。但它的代价也很明显：慢，贵，token 消耗大，而且 UI 一变，模型就可能误判。
 第二类是 DOM 或可访问性树识别。它比纯视觉更进一步，不只是看图，而是读取页面结构，找按钮、表单、菜单和文本。这当然更结构化，也更接近前端工程。但真实业务系统里有大量复杂组件：弹窗、抽屉、虚拟滚动、级联选择、树形权限、隐藏状态、动态权限。结构一复杂，Agent 仍然可能找错元素、点错按钮，甚至误删数据。
 第三类就是我们今天重点看的 WebMCP 思路。它不是继续让 AI 猜页面，而是让网页主动告诉 AI：我这里有哪些工具，每个工具适合什么场景，需要什么参数，调用之后会执行什么业务逻辑。这样，AI 做的事情就从“在 UI 上摸索”变成“调用明确的业务能力”。
 所以这页的结论很简单：AI 擅长结构化信息，不擅长在复杂 UI 里猜下一步。只要我们让它继续猜，就会慢、贵、脆弱；如果我们把网页能力结构化地交给它，它才有机会变得稳定、可控。
 -->
@@ -1,45 +1,33 @@
-# 一个变化：网页不只给人用了
+# 这次分享解决什么问题？
 <div class="grid grid-cols-2 gap-8 mt-8">
 <div class="card-blue">
-<div class="font-semibold mb-3">过去的 Web</div>
+<div class="font-semibold mb-3">听众能获得</div>
 <div class="space-y-2 text-sm">
- 用户看页面
+- Chrome 近期值得关注的新能力地图
- 用户理解信息
+- 哪些能力已经适合进入生产评估
- 用户点击控件
+- 如何用 DevTools 更快定位性能与兼容性问题
- 用户完成流程
+- 如何把浏览器更新转成团队行动项
 </div>
 </div>
-<div class="card-green">
+<div class="card">
-<div class="font-semibold mb-3">Agentic Web</div>
+<div class="font-semibold mb-3">不展开做什么</div>
-<div class="space-y-2 text-sm">
+<div class="space-y-2 text-sm text-gray-300">
- Agent 理解页面意图
+- 不逐条朗读全部 release notes
- Agent 拆解多步任务
+- 不做浏览器内核源码分析
- Agent 调用网页能力
+- 不承诺所有实验能力都可直接上线
- 用户确认关键动作
+- 不替代真实项目的兼容性验证
 </div>
 </div>
 </div>
 <div class="mt-8 card-amber text-sm">
 核心判断：今天的网页“能被 AI 操作”，但还没有真正“为 Agent 优化”。
 </div>
 <!--
-这一页我们先建立背景。
+这一页是分享定位。Chrome 更新频率很高，真正有价值的不是把每个版本的新字段都念一遍，而是帮助团队快速判断：哪些变化影响我们现在的产品，哪些能力值得试验，哪些 DevTools 工作流可以马上提高排查效率。
 过去我们做 Web，默认使用者是人。所以我们会关注视觉层面的体验：页面好不好看，信息层级清不清楚，按钮是不是容易点，表单是不是容易填，错误提示是不是能让用户理解。也就是说，用户通过“看”来理解页面，再通过“点”和“输入”来完成操作。
 但在 Agentic Web 里，使用者不只有人。用户可能不会亲自打开每个页面、阅读每个字段、点击每个按钮，而是直接说一句：“帮我找一个会议附近的酒店，把预算和评分筛选好，再给我几个候选方案。”这时候，真正要进入网页、理解信息、执行步骤的，就变成了 Agent。
 这并不是说网页以后不需要 UI 了，也不是说 Web 要从“给人用”变成“不给人用”。更准确的说法是，Web 会多出一层使用方式。上层仍然是人类看到的界面，下层则需要有 Agent 能理解、能调用、能安全执行的能力结构。
 所以这页的核心判断是：今天很多网页已经“能被 AI 操作”，因为 AI 可以看截图、读 DOM、模拟点击；但它们还没有真正“为 Agent 优化”。接下来几页，我们就看为什么这件事会成为问题。
 -->
@@ -1,38 +0,0 @@
 # 体验侧的新能力：让 Web 更像应用，也更可组合
 <div class="grid grid-cols-3 gap-5 mt-8">
 <div class="card-green">
 <div class="font-semibold mb-3">HTML in Canvas</div>
 <div class="text-sm op-70">把真实 DOM 内容放进 Canvas / 3D 场景，保留选择、翻译和可访问性等 Web 能力。</div>
 </div>
 <div class="card-blue">
 <div class="font-semibold mb-3">View Transitions</div>
 <div class="text-sm op-70">用更少的 JavaScript 做页面状态切换，让 Web 应用的过渡更自然。</div>
 </div>
 <div class="card-amber">
 <div class="font-semibold mb-3">Navigation API</div>
 <div class="text-sm op-70">用统一事件管理前进、后退和应用导航，为 SPA 和跨页转场打基础。</div>
 </div>
 </div>
 <div class="mt-8 card-blue text-sm">
 这些能力服务同一个目标：把 Web 的开放性、可访问性和应用体验放到同一条轨道上。
 </div>
 <!--
 这一页讲体验侧的新能力。
 Chrome 原文里有一个很有画面感的 demo：在一个 3D 房间里嵌入浏览器内容，同时还能选择文本、翻译内容、查找 WebGPU。这个 demo 背后对应的是 HTML in Canvas 这个方向。它想解决的问题是：当我们进入 Canvas、游戏、3D 或沉浸式场景时，不应该牺牲 DOM 的文本能力、可访问性和 Web 语义。
 View Transitions 解决的是另一个常见问题：Web 应用切换状态时，经常感觉像“突然换了一页”。以前我们要写很多动画逻辑，或者引入动画库，才能让列表到详情、页面到页面的切换更自然。现在平台开始提供更原生的转场能力，帮助改善感知性能和连续性。
 Navigation API 则解决导航管理问题。传统 History API 在复杂应用里会显得比较分散，前进、后退、页面切换和应用状态管理经常需要我们自己拼很多逻辑。Navigation API 的方向，是把这些导航事件统一起来。它和 View Transitions 配合之后，Web 应用会更像一个完整应用，而不是一堆页面拼接。
 这一页不需要深入 API 细节。我们只要让听众理解：Chrome 不只在做 AI，也在继续补 Web 的应用体验能力。Agentic Web 是新方向，但 Web 作为应用平台本身，也还在继续变强。
 讲完能力，我们最后要回到团队落地：这些东西今天应该怎么跟，哪些可以做，哪些不能急。
 -->
@@ -3,8 +3,8 @@ theme: penguin
 colorSchema: light
 title: What's New in Chrome
 info: |
-  ## What's New in Chrome
+  ## Chrome 新特性分享
-  面向 Agentic Web / WebMCP 的 Chrome 新特性分享
+  面向前端、产品与技术团队的浏览器能力更新速览
 transition: slide-left
 mdc: true
 drawings:
@@ -17,19 +17,9 @@ layout: intro
 # What's New in Chrome
-Web 正在进入 Agentic 时代
+Web 平台能力、DevTools 工作流与产品落地机会
-<div class="pt-4 text-sm op-60">WebMCP · Task Flows · Modern Web Guidance · DevTools for agents · Baseline</div>
+<div class="pt-4 text-sm op-60">分享项目模板 · 首页 · 大纲 · 模拟展示详情页</div>
 <!--
 大家好，今天这场分享的主题是 What's New in Chrome，但我不会把它讲成一串 release notes，也不会逐条念 Chrome 又新增了哪些 API。
 我想先给大家一个更大的判断：Web 正在进入 Agentic 时代。以前我们默认网页是给人用的，人打开页面，阅读内容，理解按钮和表单，然后一步一步点击完成任务。但现在，AI Agent 也开始成为网页的一类使用者。它不是像人一样慢慢看页面，而是要理解页面意图，拆解用户任务，调用能力，甚至跨多个页面完成一组流程。
 所以今天我们从开发者视角看一个问题：Chrome 最近这些方向，到底在帮 Web 发生什么变化？我会把它分成三条线。第一条线，是让网站更容易被 Agent 理解和调用，核心代表是 WebMCP。第二条线，是让开发工具和编码 Agent 更懂现代 Web，代表是 Modern Web Guidance 和 DevTools for agents。第三条线，是继续提升 Web 自身的体验，比如 HTML in Canvas、View Transitions、Navigation API 和 Baseline。
 这场分享结束以后，我希望大家带走的不是某个单点 API，而是一个问题意识：我们现在写的网页，未来不仅要被人看懂，也要被 Agent 安全、稳定、结构化地使用。
 -->
 ---
 src: ./pages/overview.md
@@ -40,41 +30,27 @@ src: ./pages/outline.md
 ---
 ---
-src: ./pages/demo/release-scan.md
+layout: new-section
 ---
 # 模拟展示：从 Chrome Release Notes 到团队落地
 ---
-src: ./pages/demo/platform-api.md
+src: ./pages/demo/release-scan.md
 ---
 ---
 src: ./pages/demo/devtools-workflow.md
 ---
 ---
 src: ./pages/demo/platform-api.md
 ---
 ---
 src: ./pages/demo/adoption-plan.md
 ---
 ---
 src: ./pages/chrome-flash.md
 ---
 ---
 src: ./pages/modern-web-guidance.md
 ---
 ---
 src: ./pages/devtools-agents.md
 ---
 ---
 src: ./pages/platform-shifts.md
 ---
 ---
 src: ./pages/adoption-now.md
 ---
 ---
 src: ./pages/closing.md
 ---