谷歌为 AI 编程提供跨浏览器实践指南

AI 写前端代码，难点之一是选错实现路线：浏览器已有的能力，仍然绕一层依赖；控件能显示，却缺少语义和交互细节。Google 发布的 Modern Web Guidance（MWG）1.0，想把这些判断提前放进 AI 编程过程。

它提供面向浏览器能力的指南，也公开比较有无指南时的代码质量。原文最有价值的结论是：明确的工程指导能改善特定检查的通过率，但生产性能、无障碍和搜索效果，仍要分别验证。

MWG 要改变的是 AI 选方案的习惯

MWG 最初是 Chrome I/O 上的预览项目。进入 1.0 后，它从预览转为有正式治理机制的项目。按 v1.0.0 发布说明，项目包含 203 份用例指南，覆盖约 250 项 Web 平台特性。

这些指南希望让 AI 编程代理优先考虑浏览器内置能力，减少不必要的库、自定义补丁和过时写法。它关注的不只是代码能否运行，还包括实现方式是否合适。

这对前端开发很实际。同一个交互需求，AI 可以引入依赖、手写控件，也可以采用原生能力。几种方案在演示页面里可能差不多，维护成本、键盘操作、渲染行为却可能不同。MWG 的作用，是在生成代码之前给代理补充选择依据。

原文给出的安装命令如下，用于安装这套指导材料：

npx modern-web-guidance@latest install

要注意 @latest：它指向安装时的最新版本，不能据此认定安装结果始终对应 v1.0.0。原文没有展开不同编程代理的接入方式，也没有说明安装后如何确认指南已被采用。

跨浏览器协作是另一个变化。参与维护的团队包括 Chrome、Microsoft Edge、Mozilla Firefox 和 MDN。项目设有 6 个所有者席位，Chrome、Edge、Mozilla 各占 1 席，另有 2 席保留给独立 Web 专家。

这里有个信息缺口：原文列出的归属只覆盖 5 席，没有解释第 6 席；已公布的治理信息也没有列出 Apple 席位。因此，可以确认它扩展了参与范围，但不能据此推导所有浏览器厂商都已参与，或每条建议都适用于目标用户的浏览器版本。

88% 对 56%，究竟证明了什么

MWG 的公开评估比单纯发布一套指南更有说服力。

项目描述了每晚自动运行的质量检查：让代理分别在有指导和无指导的条件下完成任务，再通过 Playwright 在真实浏览器中，对 DOM、样式和源码进行检查。判断依据是一组标准化要求。

原文引用的早期公开仪表盘快照显示，最近夜间运行中，每个代理约有 199 至 215 个任务；有指导的输出通过约 88% 的检查，无指导的输出约为 56%。

差距相当明显，但要读准分母。

88% 是所选检查的通过率，不是生产页面的整体合格率。

这组结果支持一个有限而有用的判断：对于 MWG 选择的任务和检查要求，显式提供浏览器相关指南，有助于代理产出更符合要求的代码。它不能证明所有网站都能获得同等提升，也不能证明页面访问量会增加。

这些数字来自项目的公开评估，并非文章作者自己完成的独立实验。原文也没有列出模型版本、任务分布、重复运行的波动，或哪些检查贡献了最多改善。缺少这些细节，我们还不能判断收益主要来自某些特性，还是普遍覆盖各种前端任务。

无障碍也有同样的边界。评估覆盖部分检查，并不是完整的 Web Content Accessibility Guidelines（WCAG）审计。自动检查能发现一批明确问题，但通过检查之后，实际操作是否顺畅，仍需要结合具体页面验证。

页面质量能影响体验，但别直接换算成 SEO 收益

原文花了不少篇幅讨论搜索可见性，不过它明确承认：没有公开文档证明采用 MWG 是 Google 排名因素，也没有证据表明它能直接提高排名。

它与搜索的关系，主要来自实现质量。

比如 Largest Contentful Paint（LCP）描述主要内容出现的速度，Interaction to Next Paint（INP）描述页面对用户交互的响应情况。合理的实现选择可以为这些体验指标创造更好的条件，但安装指南本身不会自动改善指标。

类似地，减少多余的客户端依赖，可能降低页面复杂度；语义清晰的结构和可访问的控件，可以减少用户操作障碍，也便于团队维护。这些都是值得追求的工程结果，却不能直接换算成抓取效率、排名或流量。

原文没有给出 MWG 对上述搜索结果的生产测量。正确的验证对象应当是自己的网站：改动之后，代表性页面的体验指标如何，关键流程是否受影响，搜索相关数据有没有变化。

另外，面向已有代码库扩展审计，以及与 Chrome DevTools 集成开展浏览器内测试，都是发布说明中的计划。不能把它们当作 1.0 已经交付的功能。

我的判断

我认可 MWG 把指导前移到生成阶段的思路。团队如果希望 AI 优先采用平台能力，仅在代码评审时提出要求，往往已经需要返工。提前提供明确依据，再检查结果，是更完整的工作流程。

不过，「原生优先」仍然要服从兼容范围和业务需求。已有组件库可能积累了交互规范、设计约束和维护经验；某项原生能力即使可用，也未必足以覆盖项目需求。MWG 适合成为选型依据，替换依赖之前仍要逐项比较。

与团队自己的编码规范相比，它提供了更广的平台知识和公开评估；团队规范则更贴近实际业务。两者可以结合，原文没有给出它与其他规范方案的对照数据，无法判断谁更有效。

最后，文章末尾推荐注册 GEO Search Leads，属于产品推广。前面的通过率数据没有验证该产品的价值，也没有建立 MWG 与 GEO 效果之间的因果关系。这部分不应被当作技术结论。

能拿来做什么

• 在下一次让 AI 生成或重构前端交互时，接入 MWG，并要求代理解释采用原生能力的依据、兼容条件和替代方案。评审时核对这些判断，别只看页面截图。
• 选取项目中有代表性的页面模板，在改动前后记录 LCP、INP 和无障碍问题，并保留测试条件。用项目数据判断收益，避免把公开通过率当成本地结果。
• 用 Playwright 覆盖关键用户流程，并在用户实际使用的浏览器和设备上验证。业务逻辑、语义标记、埋点、同意机制及搜索相关技术改动，继续保留人工审核。
• 在团队接入文档中记录实际安装版本和使用方式，并把现有功能与后续计划分开。对旧代码审计和 Chrome DevTools 集成的需求，先确认功能是否已经交付。