Policybazaar 如何利用面向智能体的 Chrome 开发者工具和 Modern Web Guidance 将审核开销降低 92%，并将屏幕交付速度提高 90% 以上

Aman Soni

Swetha Gopalakrishnan

发布时间：2026 年 11 月 10 日

Policybazaar 是印度领先的保险平台之一，拥有超过 9, 700 万注册客户。大约 80% 的客户每月都会访问该网站。其母公司 PB Fintech 最近推出了 Pensionbazaar，这是一个端到端退休规划平台，是 Paisabazaar Marketing & Consulting Private Limited 旗下的品牌。

两个团队都已在使用编码智能体，这些智能体可以快速编写代码，但无法在浏览器中查看代码的运行效果。智能体经常会采用过时的网页模式，并且无法检查屏幕是否正确呈现，因此工程师仍然必须手动验证所有内容。

为了解决这个问题，两家公司在 Agentic Workflows 中结合使用了两个工具：Modern Web Guidance，用于向模型传授现代 Web 标准；面向智能体的 Chrome 开发者工具，用于为这些智能体提供一个实时、无头浏览器，以便检查和验证其工作。

具体影响如下：

挑战：代码编写快，验证慢

Policybazaar 和 Pensionbazaar 遇到了两个不同的瓶颈，标准的 AI 编码工作流无法在生产级别进行优化。

Pensionbazaar：新界面，QA 周期长

Pensionbazaar 需要数十个全新的复杂界面，例如多步骤的 Retirement Freedom Score 计算器、可自定义的投资费用预测以及自动生成的建议报告。该团队使用编码智能体和 Figma MCP 服务器构建了这些组件，但有两个问题导致 QA 周期过长。

首先，智能体是在“摸黑”编写代码。基础模型可以生成代码，但无法查看渲染后的界面、将计算出的样式与设计规范进行比较、检测布局偏移或读取网络瀑布图。因此，界面被剪裁和布局偏移等相关问题一直到手动 QA 阶段才被发现。

其次，生成的代码已经过时。由于不了解现代 Web 平台，这些智能体只能依赖过时的权宜解决方法，编写繁重的 JavaScript 模态框，而不是使用内置的 <dialog> 元素，添加不必要的 polyfill，并忽略 fetchpriority 等性能提示。

Policybazaar：30 个着陆页和一次人工审核

Policybazaar 的人寿保险团队为不同的保险产品运行大约 30 个着陆页，每个页面可以针对不同的营销活动进行调整。这些网站每天总共接待 20 万到 30 万名访客，每个网页每月都会进行设计和业务逻辑更新。该团队必须保持较高的 Core Web Vitals 分数，并确保每个变体都可访问，且在各种屏幕尺寸下都能正确呈现。

在实现自动化之前，工程师需要手动审核每个页面：

1. 运行 PageSpeed Insights 以收集真实用户数据。
2. 评估 Core Web Vitals 得分和建议。
3. 检查开发或预演 build，诊断得分背后的问题，并应用代码修复。

这个过程缓慢、重复，而且无法扩缩。这可能会导致错失优化机会、审核覆盖范围不一致、性能回归未被检测到以及发布延迟。

在更改工作流程之前，团队设定了三个目标：将开发者在性能审核上花费的时间减少 80% 以上，同时实现持续审核覆盖；通过经过验证的报告缩短 QA 周期；减少因屏幕与线框图不匹配而导致的界面 bug。

解决方案：代码到验证循环

Pensionbazaar 缩短了编写代码和检查代码之间的间隔。智能体编写代码，启动一个干净的浏览器实例，以编程方式审核页面，检查视觉一致性、布局损坏、控制台错误和性能，并在极少的人工干预下修复发现的问题。 他们的智能体从 Figma MCP 获取设计，以便将呈现的页面与设计师的意图进行比较。

以下视频展示了此循环的实际运行情况。智能体读取新界面的 Figma 设计，实现该界面，然后使用面向智能体的 Chrome 开发者工具检查渲染后的页面，并修复发现的差异。

第 1 步：让智能体遵循现代网络标准

Pensionbazaar 团队希望生成的代码遵循现代 Web 最佳实践，使用当前平台功能，并且仍可在旧版浏览器中运行。 手动检查非常繁琐，而且代理并不总是与平台保持同步。Modern Web Guidance解决了这个问题。它是一项智能体技能，由 Chrome 和 Web 社区的 Web 专家编写和维护，涵盖 200 多个应用场景。它会引导智能体使用现代 Web 平台 API，并遵循符合基准目标的性能和无障碍功能最佳实践。如果您未设置目标，则默认为基准广泛可用。

智能体从 Figma 文件中提取上下文后，会使用 Modern Web Guidance 编写代码。对于 Pensionbazaar 而言，这在三个方面改变了代码：

• 原生元素取代了 JavaScript 权宜解决方法。该代理使用内置的 <dialog> 元素和 Popover API 来显示方案详情模态框，并使用 CSS 网格和 Flexbox 来显示财务摘要卡片。
• 智能体添加了基础模型通常会忽略的性能提示。 其中包括在主 LCP 图片上使用 fetchpriority="high"，在首屏下方的方案卡片上使用 loading="lazy"，以及使用 scheduler.yield() 设定基于时间的执行预算，以保护 Interaction to Next Paint (INP)。
• 现代功能不会破坏旧版浏览器。Pensionbazaar 支持在 Browserslist 中定义的旧版浏览器。该代理在动态密码 (OTP) 字段中使用了 :user-invalid CSS 伪类和 autoComplete="one-time-code" 等功能。旧版浏览器会忽略这些功能，而核心功能会继续运行。

基础模型的效果也不错。在性能方面，团队发现它们与最佳实践的契合度约为 70%。该代理自己的报告列出了 12 条现代 Web 指南规则，这些规则弥补了剩余的差距。四个示例：

对于 Pensionbazaar，我们的首要任务是从第一天起就构建高质量的代码，以避免日后产生技术债务。Modern Web Guidance 引导我们的编程智能体采用现代 Web 标准和性能最佳实践，同时遵循我们特定的浏览器兼容性目标。这让我们的前端代码审核变得更加轻松快捷，最终缩短了开发周期。

Aman Soni，Policybazaar 工程经理

第 2 步：为智能体提供浏览器

面向智能体的 Chrome 开发者工具是一套工具，包括 MCP 服务器、CLI 和智能体技能，可让编码智能体实时访问运行时调试数据，例如控制台日志、网络流量、无障碍树和其他开发者工具功能。

该团队在编码智能体 Claude Code 中安装了面向智能体的 Chrome 开发者工具插件：

# Add the marketplace registry
/plugin marketplace add ChromeDevTools/chrome-devtools-mcp

# Install the plugin (MCP server and skills)
/plugin install chrome-devtools-mcp@chrome-devtools-plugins

该团队希望每项测试都在干净的浏览器实例中运行，这样已安装的 Chrome 扩展程序就不会影响结果，个人数据或敏感数据也不会泄露。为此，请在 MCP 服务器配置中将 --isolated 添加到 args 数组：

{
  "args": ["-y", "chrome-devtools-mcp@latest", "--isolated"]
}

如果您的测试需要现有的已登录浏览器会话，请改用 --autoConnect。

第 3 步：让智能体检查并修正自己的工作

工程团队在智能体的指令中列出这些检查，可以作为提示，也可以作为智能体技能。概括来讲，代理会执行以下操作：

• 检查 DOM 树和计算出的 CSS，并将其与 Figma 设计进行比较。
• 将页面大小调整为移动设备视口大小，以测试自适应性。
• 记录性能跟踪记录，以查找由脚本、渲染阻塞资源和其他性能问题导致的长动画帧 (LoAF)。
• 在工程师审核代码之前，重写代码以修复设计不匹配、性能问题和控制台异常。

下表显示了哪些面向智能体的 Chrome 开发者工具支持各项检查：

当智能体发现问题（例如小屏幕上的文字被截断、弹性换行损坏或未优化的图片导致布局偏移）时，它会运行一个简短的更正循环：

1. 面向智能体的 Chrome 开发者工具会捕获确切的错误。
2. 智能体分析数据并重写有问题的 CSS 或 JavaScript。
3. 客服人员重新加载页面以确认问题已解决。

在一个屏幕上，代理渲染了页面，发现标题布局、间距和渐变与设计不符。它修复了相关的 .scss 文件。它还与页面进行了互动，例如展开折叠面板以检查其打开状态是否与设计相符。

第 4 步：向 QA 提交经过验证的报告

验证完成后，智能体会向 QA 团队交付可用于生产用途的代码以及审核报告。该报告会显示以下数据：

• 与 Figma 设计进行视觉对比，突出显示像素差异，基于屏幕截图、DOM 快照和计算样式构建。
• 不同屏幕尺寸下呈现的网页的屏幕截图。
• 来自 performance_start_trace 和 performance_analyze_insight 的 Core Web Vitals 和性能诊断，例如 Speed Index 和总阻塞时间 (TBT)。
• lighthouse_audit的 SEO、最佳实践和无障碍功能 Lighthouse 得分。
• 针对交互（例如收起行和切换开关）以及控制台错误和应用状态更改（例如修改行、删除行和空状态）进行通过或失败检查。

将相同的方法应用于 30 个广告系列页面

在其主平台上，Policybazaar 不再手动运行 PageSpeed Insights，而是通过 Kiro 中面向智能体的 Chrome 开发者工具运行审核。在广告系列页面上线之前，工程师会针对移动设备和桌面设备的预演网址触发审核。该代理会运行性能和 Lighthouse 审核，而 Chrome 开发者工具代理会自动提取真实的 Chrome 用户体验报告 (CrUX) 现场数据以及实验室数据。这完全取代了 PageSpeed Insights 步骤

然后，智能体会报告性能得分、发现的瓶颈，以及按优先级排序的改进措施列表，供工程师进行修复。在一次预发布审核中，它标记了在网页加载期间接连触发并与关键渲染工作竞争的非关键 API 调用。团队在页面上线前解决了问题

现在，智能体完成 12 次性能审核所需的时间，与工程师完成一次审核所需的时间相同。这相当于减少了 92% 的人工工作量。

网站性能对于我们保持良好的用户体验至关重要，但手动审核、评估数十个着陆页的瀑布图和跟踪记录非常繁琐，也是一个主要瓶颈。Chrome 开发者工具 for Agents 改变了这一流程，将工程师的性能审核时间缩短了 92%，让他们有更多时间专注于更复杂的任务。

Aman Soni，Policybazaar 工程经理

影响

借助 Modern Web Guidance 和 Chrome 开发者工具，Policybazaar 和 Pensionbazaar 的前端测试从手动、被动的流程转变为自动化、主动的流程。下表比较了变更前后的工作流程：

92% 的降幅超出了团队设定的 80% 以上的目标。着陆页回归问题在进入预演或质量保证阶段之前就会被发现。在 Pensionbazaar，代码在交付时已经过审核，并附带多个视口的屏幕截图，这减少了设计、工程和 QA 之间的反复沟通。

团队核心收获

• 让智能体以权威指南为依据。Modern Web Guidance 等精选指南可让智能体远离过时的模式，并使您的代码符合基准目标。
• 在智能体检查渲染后的页面之前，不要让其将前端任务标记为已完成。借助面向智能体的 Chrome 开发者工具，智能体可以在真实浏览器中检查布局、视口和性能跟踪记录。
• 为循环提供明确的退出条件。设置步骤限制以及明确的通过和失败条件，以免智能体陷入循环并浪费 token。
• 从高频、模板驱动的页面开始。闭环工作流在周转速度至关重要的情况下最能发挥作用。
• 在干净的浏览器中运行审核。使用 --isolated，这样扩展程序和缓存数据就不会影响结果或泄露个人数据。

资源

• Modern Web Guidance
• Modern Web Guidance 源代码库
• 面向智能体的 Chrome 开发者工具文档
• GitHub 上的面向智能体的 Chrome 开发者工具