Khi bạn tự động hóa bất cứ thứ gì trên màn hình, bạn phải nói cho phần mềm biết *chỗ nào* để thao tác. Có hai cách: click một tọa độ X/Y cố định, hoặc nhắm đúng phần tử theo selector của nó. Lựa chọn tưởng nhỏ, nhưng lại là lý do lớn nhất khiến một workflow hoặc chạy êm hàng tháng hoặc hỏng ngay sáng hôm sau. Bài này giải thích click phần tử web theo selector khác với click theo tọa độ ra sao, và khi nào dùng cái nào.
Bạn sẽ thấy mỗi cách hoạt động thế nào bên dưới, một bảng so sánh từng điểm, ưu nhược của cả hai, và một quy tắc đơn giản để chọn. Nếu bạn từng có một automation "hôm qua còn chạy" mà hôm nay tự dưng trượt, gần như luôn là vì lý do này.
Vấn đề gốc: nói cho automation biết *chỗ nào* để thao tác
Con người tìm một nút bằng cách đọc màn hình. Automation không "nhìn" được như vậy — nó cần một địa chỉ. Một tọa độ nói 'click ở pixel 640, 320.' Một selector nói 'click phần tử tên submit-button.' Cùng một ý định, độ tin cậy khác hẳn, vì màn hình thì dịch chuyển còn danh tính phần tử thường thì không.
Khoảng cách đó là toàn bộ câu chuyện. Một tọa độ là canh bạc rằng ngày mai màn hình trông y hệt lúc bạn bắt điểm. Một selector là mô tả về chính cái vật đó, mà trình duyệt định vị lại mỗi lần chạy dù nó đang nằm đâu. Hầu hết "automation chập chờn" thật ra là một tọa độ đặt vào một màn hình sau đó đã đổi.
Click theo tọa độ hoạt động thế nào
Click tọa độ ghi lại một vị trí pixel và click ở đó. Trong RunMacro bạn bắt điểm bằng Click Chuột và phím F2. Nó phổ quát — chạy trên mọi thứ nhìn thấy được, kể cả hình ảnh, game và ứng dụng không có cấu trúc truy cập được. Nhưng nó mong manh: đổi kích thước cửa sổ, độ phân giải, vị trí cuộn, tỉ lệ hiển thị, hay bố cục là mục tiêu không còn nằm dưới những pixel đó nữa. Cú click rơi vào khoảng trống hoặc sai control.
Bạn có thể làm click tọa độ vững hơn nhiều bằng cách tìm mục tiêu bằng hình ảnh trước. Tìm hình ảnh định vị một bức ảnh đã biết trên màn hình rồi click tương đối theo nó, còn Tìm màu hoặc OCR xác nhận trạng thái trước khi thao tác. Điều đó biến một cú "click mấy pixel này" mù quáng thành "tìm cái này, rồi click nó" — gần nhất mà một cách dựa trên màn hình đạt tới cách hành xử của selector.
Smart HTML (theo selector) hoạt động thế nào
Trên trang web, Smart HTML nhắm một phần tử theo selector thay vì theo vị trí. Nó hỏi trang lấy phần tử khớp với một selector rồi thao tác trên nó dù nó đang nằm đâu. Bạn không phải tự viết selector — công cụ chọn phần tử bắt nó khi bạn click mục tiêu một lần. Kết hợp với Chờ phần tử và IF phần tử, nó chờ được nội dung tải xong và rẽ nhánh khi thiếu thứ gì đó, còn Kiểm chứng xác minh một giá trị đúng như mong đợi trước khi workflow đi tiếp. Trang có thể dịch chuyển mà workflow vẫn tìm ra mục tiêu.
Vì Smart HTML điều khiển Chrome qua giao thức DevTools, nó cũng đọc trang sống đã render — nên chạy được trên các site mà nội dung chỉ xuất hiện sau khi JavaScript chạy, và làm tất cả những điều đó mà không di chuyển chuột vật lý của bạn.
Smart HTML với click tọa độ, từng điểm
• Ổn định khi bố cục đổi: Smart HTML vẫn chạy; tọa độ vỡ ngay khi mục tiêu dịch chuyển.
• Chạy trên đích không phải web: tọa độ chạy mọi nơi trên màn hình; Smart HTML chỉ cho trang web.
• Xử lý nội dung nạp động: Smart HTML chờ được phần tử và kiểm tra có tồn tại không; tọa độ bắn mù theo giờ.
• Công dựng: tọa độ bắt nhanh; selector tốn một chút để nhận diện nhưng hoàn vốn qua nhiều tháng.
• Chạy trong nền: Smart HTML điều khiển Chrome nền qua CDP không cần con trỏ thật; click tọa độ dùng chuột vật lý, nên máy bận trong lúc chạy.
• Xác minh thành công: Smart HTML kiểm chứng được trên trạng thái trang thật; một cú click tọa độ chỉ biết nó đã bắn, không biết có ăn hay không.
Điều gì làm một selector bền
Không phải selector nào cũng vững như nhau. Một selector neo vào thứ có ý nghĩa — một id ổn định, một tên trường, một nhãn nhìn thấy được — sống sót qua một lần thiết kế lại. Một selector bám vào tên class băm tự sinh mà site tạo lại mỗi lần deploy sẽ vỡ chắc chắn y như một tọa độ. Khi bạn chọn một phần tử, hãy ưu tiên cái tay cầm ổn định hơn cái mong manh, và nếu một lần thiết kế lại nặng có dịch chuyển mọi thứ, hãy chọn lại phần tử bị ảnh hưởng thay vì vật lộn với selector cũ. Thói quen nhỏ này là khác biệt giữa một automation "đặt rồi quên" và một cái phải vá vài tuần một lần.
Khi nào tọa độ vẫn là lựa chọn đúng
Selector chỉ tồn tại cho nội dung web. Với mọi thứ khác, click theo tọa độ — thường kết hợp nhận diện hình ảnh — không phải phương án chống cháy, mà là công cụ đúng:
• Ứng dụng desktop không có cấu trúc truy cập được, kể cả phần mềm nghiệp vụ cũ.
• Game và giao diện canvas vẽ lên một mặt phẳng duy nhất không có phần tử địa chỉ hóa được.
• Remote desktop và máy ảo, nơi phía bên kia chỉ là pixel với máy cục bộ.
• Nội dung ảnh hoặc PDF khi mục tiêu là một bức ảnh, không phải một phần tử.
Trong các trường hợp này, hãy dựa vào Tìm hình ảnh để định vị mục tiêu trước khi click, nhờ vậy workflow chịu được dịch chuyển nhỏ thay vì tin vào một pixel thô.
Khi nào dùng cái nào
Quy tắc đơn giản: nếu là trang web, dùng Smart HTML; nếu không, dùng tọa độ. Với website, biểu mẫu, dashboard và cổng thông tin, selector cho bạn độ bền và khả năng chạy nền. Với phần mềm desktop, game, hay đích dựa trên hình ảnh không có cấu trúc để bắt, click tọa độ — thường kết hợp nhận diện hình ảnh — là công cụ đúng. Nhiều workflow thực tế trộn cả hai: phần trình duyệt theo selector, phần desktop theo hình ảnh và tọa độ, trong cùng một file.
Ví dụ thực tế
Hình dung một workflow đăng nhập vào một dashboard web và click 'Export'. Với tọa độ, nó chạy được tới khi site thêm một banner đẩy mọi thứ xuống 60 pixel — giờ nó click nhầm chỗ. Với Smart HTML, nó nhắm phần tử Export theo selector, nên banner chẳng ảnh hưởng và cú click luôn trúng. Đổi mục tiêu sang một ứng dụng desktop cũ không có cấu trúc web thì bài toán lật ngược: ở đó, một cú click tọa độ neo theo hình ảnh mới là lựa chọn đáng tin, vì chẳng có phần tử nào để chọn.
Gỡ lỗi khi 'hôm qua còn chạy'
Khi một workflow tọa độ tự dưng trượt, nguyên nhân gần như luôn là một thay đổi môi trường: cửa sổ dịch chỗ, độ phân giải hay tỉ lệ hiển thị đổi, trang cuộn, hoặc một banner mới xô lệch bố cục. Bắt lại điểm, hoặc tốt hơn, chuyển bước đó sang một selector hay một mỏ neo hình ảnh để nó không còn phụ thuộc vào hình học chính xác nữa. Khi một *selector* thôi khớp, cái tay cầm ổn định của phần tử nhiều khả năng đã đổi trong một lần thiết kế lại — hãy chọn lại và ưu tiên một mỏ neo bền hơn.
Câu hỏi thường gặp
Smart HTML có luôn tốt hơn tọa độ không?
Chỉ với trang web. Với ứng dụng desktop, game, hay thứ gì không có cấu trúc web, tọa độ hoặc so khớp hình ảnh mới là hướng đi.
Có cần biết CSS để dùng Smart HTML không?
Không. RunMacro bắt selector cho bạn khi bạn chọn phần tử, nên bạn không phải tự viết.
Trộn cả hai trong một workflow được không?
Được. Dùng Smart HTML cho phần web và bước tọa độ hoặc hình ảnh cho phần desktop trong cùng một workflow.
Sao automation dựa trên tọa độ của tôi tự dưng hỏng?
Thường là một thay đổi về kích thước cửa sổ, độ phân giải, tỉ lệ hiển thị, cuộn hay bố cục đã dịch mục tiêu. Đây đúng là sự mong manh mà selector tránh được.
Smart HTML khác nhận diện hình ảnh thế nào?
Smart HTML đọc cấu trúc của trang và chỉ cho web. Nhận diện hình ảnh so khớp cái được vẽ trên màn hình và chạy mọi nơi, kể cả ứng dụng desktop — đó là cách vững hơn để click tọa độ ngoài web.
Smart HTML có chạy trên trang nạp bằng JavaScript không?
Có. Nó đọc DOM đã render trong Chrome thật, nên thấy nội dung xuất hiện sau khi script chạy — thêm một Chờ phần tử để nội dung đó có mặt trước khi thao tác.
Kết luận
Click tọa độ phổ quát nhưng giòn; Smart HTML chỉ cho web nhưng bền và thân thiện với chạy nền. Hãy khớp công cụ với mục tiêu: selector cho web, tọa độ (kèm nhận diện hình ảnh) cho mọi thứ khác. Chọn đúng điều đó và các automation của bạn thôi tự dưng hỏng qua đêm.
Tìm hiểu cách tiện ích Chrome và giải pháp tự động hóa web tận dụng selector thông minh. Để cho selector vào việc, hãy xem cách trích xuất dữ liệu từ website hoặc tự động điền Google Form chạy nền. Muốn bức tranh lớn hơn? So sánh tự động hóa desktop với trình duyệt, rồi tải RunMacro để thử cả hai.
