ขีดจำกัดของระบบอัตโนมัติบนเบราว์เซอร์: ขั้นตอนไหนทำอัตโนมัติได้ และเมื่อใดควรเปลี่ยนเครื่องมือ

คนที่ทำระบบอัตโนมัติบนเบราว์เซอร์มักเริ่มจากมุมมองที่ค่อนข้างมองโลกในแง่ดีว่า หากแยกกระบวนการออกเป็นขั้นตอนเล็กพอ ก็น่าจะไม่มีอะไรที่ทำอัตโนมัติไม่ได้

แต่เมื่อรันกระบวนการทั้งหมดตั้งแต่ต้นจนจบ ภาพที่เห็นกลับต่างออกไป ช่วงแรกอาจทำงานได้ราบรื่นอย่างน่าประหลาด ก่อนจะไปติดกำแพงที่ข้ามไม่ได้ในตอนท้าย การทดสอบสมัครบัญชีครั้งหนึ่งเป็นตัวอย่างที่ชัดเจน: กรอกฟอร์ม เลือกวันที่ รับรหัสยืนยัน และผ่านการตรวจสอบความปลอดภัยได้ทั้งหมดภายในไม่ถึงหนึ่งนาที คิดเป็นระบบอัตโนมัติประมาณ 85% ส่วนที่เหลือคือการยืนยันด้วยวิดีโอเซลฟีที่ต้องให้คนจริงอยู่หน้ากล้อง

เมื่อแยกกระบวนการนี้ตามต้นทุน ขอบเขตจะชัดกว่าที่คิดมาก

งานที่ผลลัพธ์แน่นอนบนหน้าเดียวมักเสถียรเมื่อใช้สคริปต์

ช่องอย่างชื่อ อีเมล รหัสผ่าน และวันเกิด เป็นชั้นที่เสถียรที่สุด การจำลองการพิมพ์คีย์บอร์ดพร้อมเว้นช่วงสั้น ๆ ระหว่างช่อง ใช้เวลาประมาณห้าวินาทีสำหรับทั้งขั้นตอน

ปัญหาหลักคือการระบุตำแหน่ง element ฟรอนต์เอนด์สมัยใหม่จำนวนมากสร้างช่อง input ที่ไม่มี name เชิงความหมาย จึงต้องหาโดย index หรือโครงสร้าง วิธีนี้อาจไม่สวยงาม แต่ในงานอัตโนมัติกลับมีโอกาสเสถียรกว่า

นี่คืองานประเภทแรก: โครงสร้างหน้าคงที่ การกระทำชัดเจน และผลลัพธ์คาดเดาได้ งานในขอบเขตนี้มักมีอัตราความสำเร็จของสคริปต์สูง

เมื่อเจอคอมโพเนนต์แบบกำหนดเอง โครงสร้างหน้าจะกลายเป็นต้นทุนโดยตรง

ตัวเลือกแบบ dropdown เช่นวันเกิดหรือเพศ มักเป็นส่วนที่กินเวลาจริง

สิ่งที่ดูเหมือนเมนูเลือกธรรมดา อาจเป็นคอมโพเนนต์แบบกำหนดเองที่ใช้ accessibility roles อยู่เบื้องหลัง วิธีปกติอาจล้มเหลวต่อกัน: standard select ใช้ไม่ได้ การค้นหาด้วย accessibility label ใช้ไม่ได้ และการคลิก element เป้าหมายโดยตรงก็อาจไม่สำเร็จ วิธีที่เสถียรมักต้องจำลองลำดับการทำงานของคนจริงทั้งหมด: เปิด dropdown รอให้ตัวเลือก render หาเป้าหมายจากข้อความ แล้วคลิก

โค้ดอาจเขียนได้ในไม่กี่วินาที แต่การ debug อาจกินเวลาหลายชั่วโมง ขอบเขตตรงนี้ไม่ได้ขึ้นอยู่กับทักษะทางเทคนิคอย่างเดียว แต่ขึ้นอยู่กับว่าโครงสร้างหน้าร่วมมือแค่ไหน เมื่อเจอคอมโพเนนต์แบบกำหนดเอง การเลิกยึดวิธีมาตรฐานเร็ว ๆ มักช่วยประหยัดเวลาได้มากที่สุด

การรักษาสถานะข้ามเว็บไซต์คือจุดที่ต้นทุนเริ่มเพิ่มขึ้นอย่างชัดเจน

เมื่อรหัสยืนยันถูกส่งทางอีเมล ตรรกะพื้นฐานง่ายมาก: เปิดกล่องจดหมาย หาอีเมลล่าสุด ดึงรหัสตัวเลข แล้วกรอกกลับ ขั้นตอนทั้งหมดใช้เวลาประมาณ 20 วินาที

ปัญหาที่พบบ่อยก็ไม่ซับซ้อน: ถ้าสคริปต์อ่านอีเมลเก่า รหัสจะผิด ดังนั้นต้องเลือกอีเมลล่าสุดตามเวลา

หลังผ่านขั้นตอนนี้ หลายแพลตฟอร์มยังพาไปหน้าตรวจสอบเพิ่มเติมและส่งรหัสใหม่อีกครั้ง ตรรกะการจัดการสามารถใช้ซ้ำได้ แต่ค่ารหัสจากขั้นก่อนใช้ซ้ำไม่ได้

ความยุ่งยากจริงคือมีสองเว็บไซต์และสอง session สถานะล็อกอินของอีเมลต้องคงอยู่ session ของแพลตฟอร์มต้องรักษาข้ามหลายขั้นตอน และ proxy IP เขตเวลา รวมถึงภาษา ต้องตรงกับสภาพแวดล้อม ต้นทุนของการรักษาสถานะข้ามเว็บไซต์จะค่อย ๆ สะสมแบบนี้ แต่ละขั้นตอนแยกกันไม่ยาก แต่เมื่อต่อเข้าด้วยกันอัตราล้มเหลวจะสูงขึ้นอย่างเห็นได้ชัด

ตรงนี้สคริปต์เป็นเพียงผู้ปฏิบัติ มันไม่สามารถกำหนดเองได้ว่าเว็บไซต์จะมองเห็นมันด้วยตัวตนแบบใด device fingerprint และความสอดคล้องระหว่าง IP กับสภาพแวดล้อมเป็นส่วนหนึ่งของสัญญาณที่แพลตฟอร์มอาจประเมิน นี่คือเหตุผลที่ทีมซึ่งจัดการหลายบัญชีมักแยก environment isolation เป็นอีกชั้นหนึ่ง: แต่ละ environment มี fingerprint และ IP ของตัวเอง เครื่องมืออย่าง PurpleMark ให้ความสามารถในชั้น environment นี้ ส่วนสคริปต์มีหน้าที่ทำ action ภายในเท่านั้น

งานที่ต้องเข้าใจความหมายของหน้าเว็บทำได้ยากหากพึ่งสคริปต์อย่างเดียว

เมื่อไปไกลขึ้น ลักษณะของปัญหาจะเปลี่ยนไป

ถ้าข้อความหรือโครงสร้างหน้าเปลี่ยนตามบัญชี ภูมิภาค หรือ staged experiment selector ที่เขียนตายตัวจะเริ่มเสียพร้อมกันเป็นชุด ตอนนั้นมีสองทาง: เพิ่มทุก branch ที่เป็นไปได้เข้าไปในโค้ดจนดูแลยากขึ้นเรื่อย ๆ หรือส่งขั้นตอนนั้นให้โมเดลที่เข้าใจความหมายของหน้า ข้อความแจ้งเตือนสั้น ๆ หรือความหมายของปุ่มเป็นเรื่องธรรมดาสำหรับคน แต่สำหรับ selector มันคือสัญญาณรบกวน

เมื่อแพลตฟอร์มปรับตัวเชิงรุก สคริปต์ล้วนจะเสียซ้ำแล้วซ้ำอีก

มีต้นทุนอีกแบบที่มองข้ามได้ง่าย: อีกฝั่งก็เปลี่ยนตลอดเวลา

แพลตฟอร์มไม่ได้ดูเพียงว่าคุณกรอกฟอร์มได้หรือไม่ แต่อาจพิจารณาว่า device fingerprint ดูปกติหรือไม่ IP สอดคล้องกับ environment ของอุปกรณ์หรือไม่ พฤติกรรมเหมือนมนุษย์หรือไม่ และมีร่องรอยของการทำงานจำนวนมากหรือไม่ การอัปเดต risk control เพียงครั้งเดียวอาจทำให้ selector หรือรูปแบบพฤติกรรมที่ใช้ได้เมื่อวานต้องเขียนใหม่

ดังนั้นโซลูชันที่ใช้สคริปต์ล้วนจะไม่มีวันที่ “เสร็จ” อย่างแท้จริง มันไม่ใช่งานส่งมอบครั้งเดียว แต่เป็นงานบำรุงรักษาที่ต้องติดตามอย่างต่อเนื่อง

การยืนยันใบหน้าไม่ใช่แค่ปัญหาทางเทคนิค

ด่านสุดท้ายของกระบวนการต้องให้คนจริงอยู่หน้ากล้อง และระบบอัตโนมัติจะหยุดตรงนี้

สคริปต์กรอกฟอร์ม กดปุ่ม อ่านอีเมล และใส่รหัสได้ แต่ไม่สามารถทำอย่างถูกต้องแทนขั้นตอนที่ต้องใช้ลักษณะชีวมิติของบุคคลได้ เหตุผลไม่ใช่แค่ว่าเทคโนโลยียังไม่ดีพอ เพราะจุดประสงค์ของการตรวจสอบนี้คือยืนยันว่ามีมนุษย์จริงอยู่หน้าจอ ซึ่งขัดกับเป้าหมายของระบบอัตโนมัติโดยตรง วิธีที่อ้างว่าสามารถทำการยืนยันใบหน้าแบบอัตโนมัติ มักเกี่ยวข้องกับข้อมูลชีวมิติปลอม และอาจสร้างความเสี่ยงด้านกฎระเบียบหรือกฎหมายสูงกว่าประโยชน์มาก

แม้บางขั้นตอนจะทำได้ในเชิงเทคนิค ก็ยังต้องดูว่าเงื่อนไขการใช้งานของแพลตฟอร์มอนุญาตหรือไม่ หลายแพลตฟอร์มจำกัดการสมัครแบบอัตโนมัติอย่างชัดเจน นี่คือข้อจำกัดด้านกฎ ไม่ใช่ด้านความสามารถทางเทคนิค

ข้อสรุปคือเลือกเครื่องมือตามแต่ละชั้น ไม่ใช่ไล่หาความอัตโนมัติเต็มรูปแบบ

เมื่อแบ่งกระบวนการเป็นชั้น ๆ การเลือกจะชัดเจนขึ้น:

• ใช้สคริปต์กับหน้าที่คงที่และ action ที่ผลลัพธ์แน่นอน เพราะมีต้นทุนต่ำและเสถียรที่สุด
• หากต้องรักษาสถานะล็อกอินและ session ข้ามเว็บไซต์ ให้จัดการ browser environment เป็นอีกชั้นหนึ่ง และอย่าปะปนปัญหา environment กับการ debug สคริปต์
• หากโครงสร้างหน้าเปลี่ยนและต้องเข้าใจความหมายเพื่อเลือก action ถัดไป โมเดลอาจเหมาะกว่าการเพิ่ม branch ลงในโค้ดเรื่อย ๆ
• หากขั้นตอนต้องใช้คนจริง หรือเงื่อนไขการใช้งานห้ามไว้อย่างชัดเจน อย่าฝืนทำ end-to-end automation

ควรลองเดินกระบวนการทั้งหมดด้วยมือก่อน เพื่อดูว่ามีจุดใดผ่านไม่ได้หรือไม่ แล้วจึงตัดสินใจว่าจะลงทุนพัฒนามากแค่ไหน ระบบอัตโนมัติคุ้มค่าที่สุดกับงานซ้ำ ๆ ผลลัพธ์แน่นอน และไม่ต้องใช้การตัดสินใจ.