Ngày xuất bản: 10 tháng 11 năm 2026
Policybazaar là một trong những nền tảng bảo hiểm hàng đầu của Ấn Độ, với hơn 97 triệu khách hàng đã đăng ký. Khoảng 80% khách hàng của công ty truy cập vào trang web mỗi tháng. Công ty mẹ của Paisabazaar là PB Fintech gần đây đã ra mắt Pensionbazaar, một nền tảng lập kế hoạch hưu trí toàn diện, là một thương hiệu thuộc Paisabazaar Marketing & Consulting Private Limited.
Cả hai nhóm đều đã sử dụng tác nhân lập trình. Các tác nhân này viết mã nhanh chóng nhưng không thể thấy mã đó hoạt động như thế nào trong trình duyệt. Các tác nhân thường sử dụng các mẫu web lỗi thời và không có cách nào để kiểm tra xem màn hình có hiển thị chính xác hay không, vì vậy, các kỹ sư vẫn phải xác minh mọi thứ theo cách thủ công.
Để giải quyết vấn đề này, cả hai công ty đã kết hợp hai công cụ vào quy trình làm việc dựa trên tác nhân: Modern Web Guidance để hướng dẫn các mô hình về tiêu chuẩn web hiện đại và Chrome DevTools cho tác nhân để cung cấp cho các tác nhân đó một trình duyệt không có giao diện người dùng, hoạt động trực tiếp để kiểm tra và xác minh công việc của họ.
Sau đây là tác động:
92%
Giảm bớt công sức kiểm tra thủ công trên khoảng 30 trang đích của Policybazaar
>90%
Thời gian phát triển và thử nghiệm các trang mới của Pensionbazaar nhanh hơn, từ khoảng 4 ngày xuống còn vài giờ
>90%
Giảm số lỗi giao diện người dùng trên các màn hình mới của Pensionbazaar
Thách thức: Viết mã nhanh, xác minh chậm
Policybazaar và Pensionbazaar gặp phải hai điểm tắc nghẽn khác nhau mà quy trình lập trình AI tiêu chuẩn không thể tối ưu hoá ở cấp độ phát hành chính thức.
Pensionbazaar: Màn hình mới có chu kỳ đảm bảo chất lượng dài
Pensionbazaar cần hàng chục màn hình mới, phức tạp, chẳng hạn như công cụ tính Điểm tự do hưu trí nhiều bước, thông tin dự đoán chi phí đầu tư có thể tuỳ chỉnh và báo cáo đề xuất tự động. Nhóm đã xây dựng các thành phần này bằng tác nhân lập trình và máy chủ MCP của Figma, nhưng có hai vấn đề khiến chu kỳ đảm bảo chất lượng (QA) kéo dài.
Đầu tiên, các nhân viên hỗ trợ đã lập trình mà không có thông tin rõ ràng. Mô hình cơ sở có thể tạo mã, nhưng không thể xem giao diện được kết xuất, so sánh kiểu được tính toán với thông số thiết kế, phát hiện sự thay đổi bố cục hoặc đọc thác nước mạng. Vì vậy, các vấn đề liên quan như giao diện người dùng bị cắt và bố cục bị dịch chuyển đã được chuyển đến quy trình QA thủ công.
Thứ hai, mã được tạo đã lỗi thời. Do không biết về nền tảng web hiện đại, các tác nhân đã quay lại sử dụng các giải pháp tạm thời đã lỗi thời, viết các phương thức JavaScript nặng thay vì sử dụng phần tử <dialog> tích hợp sẵn, thêm các polyfill không cần thiết và bỏ qua các gợi ý về hiệu suất như fetchpriority.
Policybazaar: 30 trang đích và một quy trình kiểm tra thủ công
Nhóm bảo hiểm nhân thọ của Policybazaar vận hành khoảng 30 trang đích cho nhiều sản phẩm bảo hiểm khác nhau và mỗi trang có thể có các biến thể cho nhiều chiến dịch tiếp thị khác nhau. Cùng nhau, họ đón nhận 200.000 đến 300.000 khách truy cập mỗi ngày và mỗi trang đều được cập nhật thiết kế và logic kinh doanh hằng tháng. Nhóm phải duy trì điểm số Core Web Vitals ở mức cao và đảm bảo mọi biến thể đều dễ truy cập và hiển thị chính xác trên mọi kích thước màn hình.
Trước khi tự động hoá, một kỹ sư đã kiểm tra từng trang theo cách thủ công:
- Chạy PageSpeed Insights để thu thập dữ liệu người dùng thực tế.
- Đánh giá điểm số và đề xuất của Core Web Vitals.
- Kiểm tra bản dựng phát triển hoặc đã ra mắt để thử nghiệm, chẩn đoán các vấn đề đằng sau điểm số và áp dụng các bản sửa lỗi mã xử lý ứng dụng.
Quy trình này chậm, lặp đi lặp lại và không thể mở rộng. Điều này khiến chúng tôi bỏ lỡ các cơ hội tối ưu hoá, phạm vi kiểm tra không nhất quán, không phát hiện được sự sụt giảm hiệu suất và chậm trễ trong việc phát hành.
Trước khi thay đổi quy trình làm việc, các nhóm đã đặt ra 3 mục tiêu: cắt giảm hơn 80% thời gian nhà phát triển dành cho việc kiểm tra hiệu suất trong khi vẫn đảm bảo phạm vi kiểm tra liên tục, rút ngắn thời gian hoàn thành quy trình đảm bảo chất lượng (QA) bằng các báo cáo đã xác minh và giảm số lỗi giao diện người dùng phát sinh do màn hình không khớp với khung lưới.
Giải pháp: Vòng lặp mã để xác minh
Pensionbazaar đã thu hẹp khoảng cách giữa việc viết mã và kiểm tra mã. Tác nhân viết mã, khởi động một phiên bản trình duyệt sạch, kiểm tra trang theo phương thức lập trình để đảm bảo tính tương đồng về hình ảnh, lỗi bố cục, lỗi bảng điều khiển và hiệu suất, đồng thời khắc phục các vấn đề mà tác nhân tìm thấy mà không cần con người can thiệp nhiều. Tác nhân của họ lấy thiết kế từ Figma MCP để có thể so sánh trang được kết xuất với ý định của nhà thiết kế.
Video sau đây minh hoạ vòng lặp này trong thực tế. Tác nhân đọc các thiết kế Figma cho một màn hình mới, triển khai màn hình đó, sau đó sử dụng Chrome DevTools cho tác nhân để kiểm tra trang được kết xuất và khắc phục những điểm khác biệt mà tác nhân tìm thấy.
Bước 1: Cung cấp kiến thức cho tác nhân về các tiêu chuẩn web hiện đại
Nhóm Pensionbazaar muốn mã được tạo tuân theo các phương pháp hay nhất về web hiện đại, sử dụng các tính năng hiện tại của nền tảng và vẫn hoạt động trên các trình duyệt cũ. Việc kiểm tra thủ công rất tẻ nhạt và các nhân viên hỗ trợ không phải lúc nào cũng nắm được thông tin mới nhất về nền tảng. Modern Web Guidance giải quyết vấn đề này. Đây là một kỹ năng của tác nhân, do các chuyên gia web của Chrome và cộng đồng web viết và duy trì, bao gồm hơn 200 trường hợp sử dụng. Công cụ này hướng các tác nhân đến các API nền tảng web hiện đại, cũng như các phương pháp hay nhất về hiệu suất và khả năng hỗ trợ tiếp cận phù hợp với mục tiêu Baseline của bạn. Nếu bạn không đặt mục tiêu, thì mục tiêu mặc định sẽ là Baseline Widely Available (Baseline được cung cấp rộng rãi).
Sau khi lấy bối cảnh từ các tệp Figma, tác nhân sẽ sử dụng Modern Web Guidance khi viết mã. Đối với Pensionbazaar, điều này đã thay đổi mã theo ba cách:
- Các phần tử gốc đã thay thế các giải pháp JavaScript. Tác nhân đã sử dụng phần tử
<dialog>tích hợp sẵn và Popover API cho các phương thức chi tiết của gói, đồng thời sử dụng CSS Grid và Flexbox cho thẻ tóm tắt tài chính. - Tác nhân đã thêm các gợi ý về hiệu suất mà các mô hình cơ sở thường bỏ qua.
Các kỹ thuật này bao gồm
fetchpriority="high"trên hình ảnh LCP chính,loading="lazy"trên thẻ gói bên dưới màn hình đầu tiên và ngân sách thực thi dựa trên thời gian vớischeduler.yield()để bảo vệ Lượt tương tác đến nội dung hiển thị tiếp theo (INP). - Các tính năng hiện đại không làm hỏng trình duyệt cũ. Pensionbazaar hỗ trợ các phiên bản trình duyệt cũ hơn, được xác định trong Browserslist. Tác nhân đã sử dụng các tính năng như lớp giả CSS
:user-invalidvàautoComplete="one-time-code"trên trường mật khẩu một lần (OTP). Các trình duyệt cũ sẽ bỏ qua các tính năng này và chức năng cốt lõi vẫn hoạt động.
Các mô hình cơ sở không khác biệt nhiều. Về hiệu suất, nhóm nhận thấy các mô hình này phù hợp khoảng 70% với các phương pháp hay nhất. Báo cáo của chính tác nhân này liệt kê 12 quy tắc Hướng dẫn về web hiện đại đã lấp đầy khoảng trống còn lại. Bốn ví dụ:
| Khu vực | Khoảng cách giữa các mô hình cơ sở | Quy tắc Modern Web Guidance |
|---|---|---|
| Đang tải hình ảnh | Tạo ra các tổ hợp mâu thuẫn, chẳng hạn như ghép nối fetchpriority="high" với loading="lazy". |
Nghiêm cấm việc kết hợp các hình ảnh này và giới hạn số lượng hình ảnh có mức độ ưu tiên cao ở mức một hoặc hai hình ảnh trên mỗi trang. |
| Độ ổn định của bố cục | Đã đề xuất content-visibility: auto để cải thiện hiệu suất, nhưng bỏ qua contain-intrinsic-size. |
Yêu cầu ghép nối hai thuộc tính để ngăn chặn sự thay đổi bố cục nghiêm trọng khi nội dung hiển thị. |
| Nhường luồng chính | Sử dụng scheduler.yield() theo cách chung chung mà không có mẫu thời hạn. |
Thực thi thời hạn nghiêm ngặt dựa trên thời gian (performance.now() + 50) để bảo vệ chỉ số Lượt tương tác đến nội dung hiển thị tiếp theo (INP). |
| Lưu vào bộ nhớ đệm bằng trình chạy dịch vụ | Không tính đến các lượt gửi biểu mẫu ngoại tuyến. | Cảnh báo cho tác nhân rằng Service Worker không thể lưu các yêu cầu GET không phải GET vào bộ nhớ đệm theo cách gốc. |
Đối với Pensionbazaar, ưu tiên của chúng tôi là xây dựng mã chất lượng ngay từ ngày đầu tiên để tránh nợ kỹ thuật sau này. Modern Web Guidance đã hướng dẫn tác nhân lập trình của chúng tôi áp dụng các tiêu chuẩn web hiện đại và các phương pháp hay nhất về hiệu suất, đồng thời tôn trọng các mục tiêu cụ thể về khả năng tương thích với trình duyệt. Điều này giúp quá trình xem xét mã giao diện người dùng của chúng tôi trở nên dễ dàng và nhanh chóng hơn đáng kể, từ đó cải thiện thời gian hoàn thành quá trình phát triển.
Aman Soni, Giám đốc kỹ thuật, Policybazaar
Bước 2: Cung cấp trình duyệt cho tác nhân
Chrome DevTools cho tác nhân là một bộ công cụ, bao gồm một máy chủ MCP, một CLI và các kỹ năng của tác nhân, giúp các tác nhân lập trình có quyền truy cập theo thời gian thực vào dữ liệu gỡ lỗi thời gian chạy, chẳng hạn như nhật ký bảng điều khiển, lưu lượng truy cập mạng, cây hỗ trợ tiếp cận và các chức năng khác của DevTools.
Nhóm đã cài đặt Chrome DevTools cho tác nhân dưới dạng một trình bổ trợ trong tác nhân lập trình của họ, Claude Code:
# 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
Nhóm muốn mọi thử nghiệm đều chạy trong một phiên bản trình duyệt sạch, vì vậy, các tiện ích Chrome đã cài đặt không thể ảnh hưởng đến kết quả và dữ liệu cá nhân hoặc dữ liệu nhạy cảm không thể bị rò rỉ. Để có được thông tin đó, hãy thêm
--isolated vào mảng args
trong cấu hình máy chủ MCP:
{
"args": ["-y", "chrome-devtools-mcp@latest", "--isolated"]
}
Nếu các kiểm thử của bạn cần một phiên trình duyệt đã đăng nhập hiện có, hãy sử dụng --autoConnect.
Bước 3: Để tác nhân kiểm tra và sửa lỗi trong công việc của chính mình
Nhóm kỹ thuật liệt kê các bước kiểm tra trong phần hướng dẫn của nhân viên hỗ trợ, dưới dạng câu lệnh hoặc kỹ năng của nhân viên hỗ trợ. Nhìn chung, tác nhân sẽ làm những việc sau:
- Kiểm tra cây DOM và CSS được tính toán, sau đó so sánh với thiết kế Figma.
- Đổi kích thước trang thành khung nhìn dành cho thiết bị di động để kiểm tra khả năng thích ứng.
- Ghi lại dấu vết hiệu suất để tìm khung hoạt hoạ cần nhiều thời gian (LoAF) do tập lệnh, tài nguyên chặn hiển thị và các vấn đề về hiệu suất gây ra.
- Viết lại mã để khắc phục các lỗi thiết kế không khớp, vấn đề về hiệu suất và ngoại lệ trong bảng điều khiển trước khi kỹ sư xem xét.
Bảng sau đây cho biết những công cụ nào của Chrome DevTools cho tác nhân hỗ trợ từng quy trình kiểm tra:
| Séc | Công cụ |
|---|---|
| Kiểm thử khả năng thích ứng trên các khung nhìn | resize_page đổi kích thước cửa sổ của trang thành kích thước rõ ràng. emulate mô phỏng môi trường thiết bị cụ thể. take_screenshot ghi lại kết quả. |
| So sánh DOM và CSS được tính toán với thiết kế Figma | take_snapshot trả về ảnh chụp nhanh văn bản của trang dựa trên cây hỗ trợ tiếp cận. get_css_styles đọc các quy tắc CSS được áp dụng. evaluate_script chạy một hàm JavaScript bên trong trang. |
| Tìm LoAF, tài nguyên chặn hiển thị và các vấn đề về Core Web Vitals | click và drag mô phỏng các lượt tương tác. performance_start_trace và performance_stop_trace ghi lại dấu vết hiệu suất. performance_analyze_insight trả về thông tin chẩn đoán chi tiết cho thông tin chi tiết trong dấu vết. list_network_requests và get_network_request cho thấy hoạt động mạng. lighthouse_audit kiểm tra các khía cạnh không liên quan đến hiệu suất như SEO và khả năng hỗ trợ tiếp cận. |
Khi tìm thấy vấn đề, chẳng hạn như văn bản bị cắt trên màn hình nhỏ, ngắt dòng linh hoạt bị hỏng hoặc hình ảnh chưa được tối ưu hoá gây ra sự thay đổi bố cục, tác nhân sẽ chạy một vòng lặp sửa lỗi ngắn:
- Chrome DevTools cho tác nhân ghi lại chính xác lỗi.
- Tác nhân phân tích dữ liệu và viết lại CSS hoặc JavaScript có vấn đề.
- Nhân viên hỗ trợ tải lại trang để xác nhận rằng vấn đề đã được khắc phục.
Trên một màn hình, tác nhân đã kết xuất trang và nhận thấy bố cục, khoảng cách và dải chuyển màu của tiêu đề không khớp với thiết kế. Công cụ này đã khắc phục .scss tệp có liên quan. Công cụ này cũng tương tác với trang, chẳng hạn như mở rộng các thành phần accordion để kiểm tra
xem trạng thái mở của các thành phần này có khớp với thiết kế hay không.
Bước 4: Giao báo cáo đã xác minh cho bộ phận QA
Khi quá trình xác minh hoàn tất, tác nhân sẽ cung cấp mã sẵn sàng cho môi trường thực tế cùng với báo cáo kiểm tra cho nhóm QA. Báo cáo này bao gồm:
- Bản so sánh trực quan với thiết kế Figma làm nổi bật sự khác biệt về pixel, được tạo từ ảnh chụp màn hình, ảnh chụp nhanh DOM và kiểu được tính toán.
- Ảnh chụp màn hình của trang được kết xuất ở nhiều kích thước màn hình.
- Core Web Vitals và thông tin chẩn đoán hiệu suất từ
performance_start_tracevàperformance_analyze_insight, chẳng hạn như Speed Index và Tổng thời gian chặn (TBT). - Điểm Lighthouse về SEO, các phương pháp hay nhất và khả năng hỗ trợ tiếp cận từ
lighthouse_audit. - Kiểm tra xem các hoạt động tương tác có đạt hay không, chẳng hạn như thu gọn hàng và nút bật/tắt, cùng với lỗi bảng điều khiển và thay đổi trạng thái ứng dụng, chẳng hạn như chỉnh sửa hàng, xoá hàng và trạng thái trống.
Áp dụng cùng một phương pháp cho 30 trang chiến dịch
Trên nền tảng chính, Policybazaar đã thay thế các lần chạy PageSpeed Insights thủ công bằng các quy trình kiểm tra chạy qua Chrome DevTools cho tác nhân trong Kiro. Trước khi trang chiến dịch hoạt động, một kỹ sư sẽ kích hoạt quy trình kiểm tra đối với URL thử nghiệm cho thiết bị di động và máy tính. Tác nhân chạy quy trình kiểm tra hiệu suất và Lighthouse, còn Chrome DevTools cho tác nhân sẽ tự động lấy dữ liệu thực tế từ Báo cáo trải nghiệm người dùng trên Chrome (CrUX) cùng với dữ liệu thử nghiệm. Điều này đã thay thế hoàn toàn bước PageSpeed Insights.
Sau đó, tác nhân sẽ báo cáo điểm hiệu suất, các điểm tắc nghẽn mà tác nhân tìm thấy và danh sách các điểm cải tiến được ưu tiên để kỹ sư khắc phục. Trong một lần kiểm tra bản phát hành trước, công cụ này đã gắn cờ các lệnh gọi API không quan trọng được kích hoạt liên tiếp trong quá trình tải trang và cạnh tranh với công việc kết xuất quan trọng. Nhóm đã khắc phục vấn đề trước khi trang được phát hành.
Giờ đây, tác nhân này hoàn tất 12 quy trình kiểm tra hiệu suất trong thời gian mà một kỹ sư cần để hoàn tất một quy trình. Tức là giảm 92% công sức thủ công.
Hiệu suất web là yếu tố quan trọng để chúng tôi duy trì trải nghiệm tốt cho người dùng, nhưng việc kiểm tra, đánh giá thác nước và dấu vết theo cách thủ công trên hàng chục trang đích là một công việc tẻ nhạt và là một điểm tắc nghẽn lớn. Chrome DevTools cho tác nhân đã thay đổi quy trình này và giảm 92% thời gian kiểm tra hiệu suất của các kỹ sư, giúp họ có thời gian tập trung vào các nhiệm vụ phức tạp hơn.
Aman Soni, Giám đốc kỹ thuật, Policybazaar
Tác động
Modern Web Guidance và Chrome DevTools cho tác nhân đã biến quy trình kiểm thử giao diện người dùng tại Policybazaar và Pensionbazaar từ một quy trình thủ công, mang tính ứng phó thành một quy trình tự động, chủ động. Bảng sau đây so sánh quy trình làm việc trước và sau khi thay đổi:
| Khu vực | Trước đây: xem xét thủ công và mô hình cơ sở | Sau: Modern Web Guidance và Chrome DevTools cho tác nhân |
|---|---|---|
| Nỗ lực kiểm tra hiệu suất (Policybazaar) | Một kỹ sư đã chạy PageSpeed Insights, xem xét Core Web Vitals và áp dụng các bản sửa lỗi theo cách thủ công cho từng trang trong số khoảng 30 trang đích. | Giảm 92% công sức thủ công. Tác nhân hoàn thành 12 quy trình kiểm tra trong thời gian mà một kỹ sư cần để hoàn thành một quy trình. |
| Phạm vi kiểm tra (Policybazaar) | Phạm vi kiểm tra giữa các biến thể chiến dịch không nhất quán. | Phạm vi kiểm thử hiệu suất 100% cho các trang chiến dịch. |
| Thời gian xử lý màn hình mới (Pensionbazaar) | Vài ngày kể từ khi nhập mã đến khi màn hình xác minh xuất hiện. | Vài giờ, nhanh hơn 90%. |
| Lỗi về tính tương đồng trong thiết kế (Pensionbazaar) | Giao diện người dùng bị cắt bớt và thay đổi bố cục đã được QA thủ công. | Số lỗi giao diện người dùng giảm hơn 90%. |
Mức giảm 92% này đã vượt mục tiêu của nhóm là hơn 80%. Các lỗi hồi quy trên trang đích sẽ được phát hiện trước khi đến giai đoạn thử nghiệm hoặc đảm bảo chất lượng (QA). Trên Pensionbazaar, mã đến đã được kiểm tra bằng ảnh chụp màn hình cho một số khung nhìn, giúp giảm bớt sự qua lại giữa thiết kế, kỹ thuật và QA.
Những điểm chính cần ghi nhớ dành cho nhóm của bạn
- Xây dựng tác nhân dựa trên hướng dẫn chính thức. Hướng dẫn được tuyển chọn như Modern Web Guidance giúp các tác nhân tránh xa các mẫu lỗi thời và giữ cho mã của bạn nằm trong Mục tiêu cơ sở.
- Đừng để tác nhân đánh dấu một nhiệm vụ giao diện người dùng là hoàn tất cho đến khi tác nhân đó kiểm tra trang được kết xuất. Chrome DevTools cho tác nhân cho phép tác nhân kiểm tra bố cục, khung nhìn và dấu vết hiệu suất trong một trình duyệt thực tế.
- Đưa ra tiêu chí thoát rõ ràng cho vòng lặp. Đặt giới hạn bước và điều kiện đạt/không đạt rõ ràng để tác nhân không lặp lại và lãng phí mã thông báo.
- Bắt đầu với các trang có tần suất truy cập cao và dựa trên mẫu. Quy trình làm việc khép kín mang lại hiệu quả cao nhất khi tốc độ xử lý là yếu tố quan trọng.
- Chạy quy trình kiểm tra trong một trình duyệt sạch. Sử dụng
--isolatedđể các tiện ích và dữ liệu đã lưu vào bộ nhớ đệm không ảnh hưởng đến kết quả hoặc làm lộ dữ liệu cá nhân.