Tại sao tính năng tự động sửa lỗi UI bằng AI thất bại và giải pháp tối ưu

@Lonely__MH
TIẾNG TRUNG13 thg 9, 2026
185K
241
36
58
483

TL;DR

Tác giả phân tích nguyên nhân khiến việc tự động sửa lỗi giao diện người dùng (UI) bằng AI thường dẫn đến suy giảm chất lượng, đồng thời đề xuất quy trình làm việc bao gồm so sánh hình ảnh trực quan (visual diffs), chẩn đoán có cấu trúc và lưu giữ các phiên bản tốt nhất trong lịch sử để ổn định kết quả.

Bài viết này ghi lại một số vấn đề mà tôi gặp phải gần đây khi sử dụng AI để tái tạo trang web. Sau đó, tôi đã xây dựng một quy trình làm việc để giải quyết các vấn đề này và sắp xếp toàn bộ quá trình để mọi người tham khảo.

Có lẽ bạn cũng từng trải qua điều tương tự.

Đôi khi bạn đưa cho AI một ảnh chụp màn hình và yêu cầu nó xây dựng trang web dựa trên đó. Phiên bản đầu tiên trông có vẻ khá ổn, nhưng khi nhìn kỹ hơn, có điều gì đó không đúng: thẻ hơi rộng hơn, phông chữ nhỏ hơn, bóng đổ sai—chỉ là những vấn đề nhỏ.

Sau đó, bạn phải mô tả bằng lời những gì cần điều chỉnh và cách thực hiện. Việc lặp đi lặp qua nhiều vòng tốn khá nhiều thời gian.

Vì vậy, tôi nghĩ đến việc liên kết chuỗi các bước: kết xuất, chụp màn hình, so sánh và sửa đổi thành một quy trình làm việc, để mô hình tự kiểm tra và tự sửa lỗi. Cách tiếp cận này nghe có vẻ hợp lý.

Nhưng trong thực tế, mọi thứ không diễn ra như kế hoạch. Đôi khi sau khi sửa ở vòng hai, vòng ba lại hoàn tác các thay đổi; kết quả dao động, và trang web thậm chí có thể trở nên tệ hơn qua mỗi lần lặp.

Hãy đi thẳng vào vấn đề.

Làm thế nào để nó tự sửa lỗi

Quy trình không phức tạp:

text
1Ảnh chụp mục tiêu ──▶ Mô hình viết HTML ──▶ Trình duyệt kết xuất ảnh chụp 1:1 ──▶ Tạo sự khác biệt từng pixel
2
3Giữ phiên bản tốt nhất ◀── Kết xuất lại ◀── Mô hình chẩn đoán rồi sửa mã ◀── Ảnh gốc + Đã kết xuất + Khác biệt

Sự khác biệt (Diff) không tự sửa trang cho mô hình. Nó chỉ biến "nó trông chưa đúng lắm" thành một bản đồ trực quan về các sai lệch cụ thể, sau đó được cung cấp lại cho mô hình để quyết định các bước tiếp theo.

Để ngăn mô hình phỏng đoán mù quáng dựa trên sự khác biệt, trước mỗi lần sửa đổi, tôi yêu cầu nó trả lời ba câu hỏi:

  1. Vấn đề lớn nhất nằm ở đâu?
  2. Yếu tố hoặc thuộc tính CSS nào có khả năng gây ra nó?
  3. Nó dự định sửa chữa như thế nào?

Chỉ sau khi trả lời xong, chúng ta mới đụng vào mã nguồn.

Cho bài kiểm tra này, tôi đã sử dụng Ling-3.0-flash-VL và chọn hai thẻ để demo đơn giản: một thẻ màu vàng với nền sáng, viền đen dày và bóng đổ cứng; thẻ còn lại là thẻ giá SaaS tối màu với nút chuyển sắc, thẻ tag và danh sách tính năng.

Tôi nghĩ các thẻ là lựa chọn hoàn hảo. Không quá nhiều yếu tố, nhưng chiều rộng, khoảng trắng, hướng của nút và bóng đổ—nếu bất kỳ cái nào bị lệch, nó sẽ lập tức dễ nhận thấy.

Chạy lần đầu

Hãy bắt đầu với thẻ màu vàng.

Sau phiên bản đầu tiên, kết quả tổng thể thực ra khá tốt.

Cấu trúc, bảng màu, nội dung văn bản và vị trí nút hầu hết đều được tái tạo chính xác. Nếu không so sánh cạnh nhau với bản gốc, bạn có thể nghĩ rằng nó đủ gần.

Nhưng khi đặt cùng nhau, những khác biệt tinh tế lộ ra: thẻ hơi lớn hơn, độ đậm của phông chữ khác nhau, và kích thước khoảng trắng/nút không được căn chỉnh hoàn hảo.

Sau đó, tôi đưa ảnh gốc, kết quả vòng một và sự khác biệt trở lại cho Ling, yêu cầu nó xác định các vấn đề chi tiết này.

Từ chẩn đoán, nó không chỉ nói "không đủ giống". Nó xác định chính xác các vấn đề như kích thước thẻ, phông chữ và nút, sau đó sửa đổi CSS tương ứng.

Lonely - inline image

So sánh ba vòng của thẻ màu vàng: Vòng 2 cải thiện, Vòng 3 thụt lùi, vì vậy chúng ta giữ Vòng 2 làm phiên bản tốt nhất trong lịch sử.

Tuy nhiên, một vòng đầu tiên tốt không đảm bảo sự cải thiện liên tục.

Video này nắm bắt vấn đề: Vòng 2 gần với bản gốc hơn, nhưng Vòng 3 lại trượt nhẹ trở lại. May mắn thay, quy trình làm việc không mặc định lấy vòng cuối cùng làm đáp án mà giữ lại phiên bản tốt nhất trong lịch sử từ Vòng 2.

Vì vậy, việc cung cấp sự khác biệt trở lại không có nghĩa là mô hình đột nhiên thông minh hơn. Nó có thể phát hiện nhiều vấn đề chi tiết và ánh xạ các đánh giá sang CSS cụ thể, nhưng đôi khi nó vẫn bị nhầm lẫn.

Để biết chi tiết về cách quy trình làm việc chạy, hãy xem video quay màn hình bên dưới.

Lonely - inline image

Demo đầy đủ của thẻ giá tối màu: chọn tài nguyên, tạo ban đầu, so sánh thanh trượt, sau đó chạy hai vòng tự chữa lành.

Các thay đổi ở đây không quá kịch liệt vì vòng đầu tiên đã khá gần. Các vòng tiếp theo tiếp tục cải thiện, tập trung vào kích thước thẻ, góc bo tròn, nút và hiệu ứng chuyển sắc.

So sánh cả hai bản ghi cho thấy các xu hướng khác nhau:

Lonely - inline image

Thẻ màu vàng cải thiện đến Vòng 2 nhưng thụt lùi ở Vòng 3; thẻ tối màu cho thấy những cải thiện nhỏ ổn định qua cả ba vòng. Mặc dù hai bản ghi không chứng minh các quy tắc thống kê, chúng cho thấy cùng một quy trình làm việc không luôn mang lại kết quả tốt hơn qua mỗi vòng.

Các vấn đề rõ ràng thường được sửa trong một hoặc hai vòng đầu tiên. Các lần lặp lại sau đó liên quan đến việc tinh chỉnh kích thước phông chữ, góc bo tròn và độ lệch bóng đổ, nơi việc sửa một thứ thường làm hỏng thứ khác. Do đó, tôi lưu phiên bản tốt nhất trong lịch sử thay vì giả định rằng vòng cuối cùng là đáp án.

Nó thực sự có thể làm gì?

Từ những kết quả này, phiên bản đầu tiên là chuẩn Screenshot-to-Code (Chụp màn hình sang Mã). Điều thú vị là sau khi xem kết quả đã kết xuất, nó có thể xác định chính xác các vấn đề xuống các phần tử và thuộc tính CSS cụ thể thay vì chỉ nói "làm cho nó giống hơn".

Ngay cả khi không tự động sửa, bước chẩn đoán này đóng vai trò như một danh sách kiểm tra hữu ích.

Nhiều vấn đề trực quan không gây ra lỗi. Nếu mô hình có thể xem trang đã kết xuất thực tế của trình duyệt, nó có cơ hội tiếp tục tự sửa lỗi.

Một điểm thực tế khác: quy trình làm việc này yêu cầu gọi mô hình lặp đi lặp lại, vì vậy tốc độ rất quan trọng. Thời gian tạo HTML toàn trang duy nhất mà tôi ghi lại mất khoảng 7 giây. Dữ liệu công khai cho thấy Ling-3.0-flash-VL có tổng cộng 124B tham số, kích hoạt 5.5B mỗi lần suy luận, với các khả năng bổ sung về hiểu biết thị giác và Visual Agent.

Con số 7 giây dựa trên giao diện và cài đặt cụ thể của tôi. Tôi chưa thực hiện so sánh ngang hàng và sẽ không suy ra tốc độ/chi phí chỉ từ các tham số được kích hoạt.

Những cạm bẫy nằm ở đâu?

Việc ngốn thời gian thực sự không phải là kết nối mô hình mà là làm cho phản hồi chính xác. Ban đầu, tôi nghĩ rằng sự dao động có nghĩa là mô hình không ổn định. Sau khi kiểm tra từng sự khác biệt, tôi nhận ra một phần vấn đề nằm ở vòng phản hồi của tôi.

1. Cạm bẫy đầu tiên: Kích thước

Nếu ảnh mục tiêu được thu phóng và trình duyệt chụp màn hình ở kích thước khác, các hình ảnh không bao giờ khớp ngay từ đầu. Ngay cả khi có đáp án đúng, sự khác biệt vẫn cho thấy các sai lệch lớn.

Đối với sự khác biệt pixel, việc lệch vài pixel trên toàn cục tạo ra các vùng lỗi khổng lồ.

2. Cạm bẫy thứ hai: Hoạt ảnh

Một lần, mô hình thêm hiệu ứng fade-in vào danh sách tính năng. Chụp màn hình giữa chừng hoạt ảnh khiến nội dung trở nên trong suốt.

Sau khi loại bỏ các hoạt ảnh, trang web trông bình thường về mặt trực quan, nhưng điểm số so sánh tự động lại tệ hơn.

Lý do: Nội dung trong suốt để lộ nền, khiến thuật toán pixel nghĩ rằng nó "trông giống hơn".

3. Cạm bẫy thứ ba: Quản lý phiên bản

Nếu một vòng làm hỏng thiết kế, việc tiếp tục vá lên trên mã xấu sẽ chồng chất lỗi. Giống như xây dựng trên một nền móng méo mó—càng cố gắng, nó càng trở nên lộn xộn.

Nói ngắn gọn, Sự khác biệt (Diff) là một công cụ, không phải là thẩm phán.

Nếu phản hồi sai, mô hình sẽ không phát hiện ra. Nó sẽ chăm chỉ sửa chữa theo hướng sai dựa trên đầu vào bị lỗi.

Kết luận

Tôi đã chắt lọc các quy tắc thành ba điểm:

  1. Sử dụng kích thước chính xác cho ảnh gốc và ảnh chụp màn hình trình duyệt; không thu phóng thứ cấp.
  2. Cố định khung nhìn (viewport), phông chữ, trạng thái hoạt ảnh và thời điểm chụp màn hình.
  3. Tiếp tục từ phiên bản tốt nhất trong lịch sử ở mỗi vòng; đừng vá mã đã bị giảm chất lượng.

Mã chạy được chỉ là bước đầu tiên. Các vấn đề không gây ra lỗi nhưng trông sai thực sự có thể được kiểm tra bởi các mô hình thị giác. Tuy nhiên, nhìn thấy sai lệch không đảm bảo các sửa chữa đúng đắn mỗi lần.

Vì vậy, tôi không còn giả định rằng nhiều vòng hơn đồng nghĩa với kết quả tốt hơn. Sửa các vấn đề rõ ràng trước, dừng lại khi cải thiện đạt đỉnh—that's sufficient for me.

Mô hình là mã nguồn mở và miễn phí trong 2 tuần. Để tự chạy nó, hãy sử dụng các liên kết này 👇🏻:

Ps: Bài viết này được đọc khẩu và trau chuốt bởi AI, vì vậy nó có linh hồn ✌🏻

Lưu một chạm

Đọc sâu bài viết viral bằng AI trong YouMind

Lưu nguồn, đặt câu hỏi tập trung, tóm tắt lập luận và biến một bài viết viral thành các ghi chú có thể tái sử dụng trong một không gian làm việc AI duy nhất.

Khám phá YouMind
Dành cho nhà sáng tạo

Biến Markdown của bạn thành bài viết 𝕏 gọn gàng

Khi bạn đăng bài viết dài của riêng mình, việc định dạng hình ảnh, bảng và khối mã cho 𝕏 rất mệt mỏi. YouMind biến cả bản nháp Markdown thành một bài viết 𝕏 gọn gàng, sẵn sàng để đăng.

Thử Markdown sang 𝕏

Thêm pattern để giải mã

Bài viết viral gần đây

Khám phá thêm bài viết viral