AI เข้าใจหน้าจอ Android อย่างไร: UI tree ภาพหน้าจอ สถานะสด และการยืนยัน

เลือก UI tree ภาพหน้าจอ หรือทั้งสองตามคำถามจริง

คำตอบที่ใช้งานได้จริงคือเลือกหลักฐานตามคำถาม ไม่ใช่เลือกจากความรู้สึกว่า AI ควรเห็นทุกอย่าง ถ้าคำถามคือปุ่มไหนกดได้ ช่องไหนต้องกรอก รายการใดถูกเลือก หรือสถานะเปิดปิดเป็นอย่างไร ให้เริ่มจาก UI tree หรือข้อมูลเชิงความหมายที่ Android เปิดเผยผ่านระบบ Accessibility เพราะข้อมูลชนิดนี้มักบอกชื่อ control, state, hierarchy, bounds และ action ที่ระบบรองรับได้ชัดกว่าการเดาจากภาพ

ถ้าคำถามอยู่ในพิกเซล เช่น กราฟ แผนที่ รูปสินค้า canvas สีเตือน ไอคอนที่ไม่มีชื่อ หรือ layout ที่ความสัมพันธ์บนหน้าจอสำคัญกว่า text ให้ใช้ screenshot พร้อมเหตุผลที่ชัดเจน ภาพหน้าจอช่วยให้ AI เข้าใจสิ่งที่ผู้ใช้เห็น แต่ภาพไม่ได้บอกเสมอว่าปุ่มนั้นมี action อะไร หรือผู้ใช้อนุญาตให้ทำงานใดต่อจากภาพนั้นแล้ว

บางงานต้องใช้ทั้งสองแบบ เช่น UI tree บอกว่ามีปุ่มยืนยัน แต่ screenshot ช่วยตรวจว่าปุ่มนั้นอยู่ใต้รายการใด หรือภาพเห็นสถานะสีที่ UI tree ไม่อธิบาย ในกรณีนี้ควรจับคู่หลักฐานก่อนเสนอการกระทำ ถ้าหลักฐานขัดกัน เช่น tree บอกปุ่ม enabled แต่ภาพเห็นปุ่มเทา หรือภาพเห็นปุ่มแต่ไม่มี action ที่ระบบรองรับ ควรหยุดและขอให้ผู้ใช้ยืนยัน

ใน FoneClaw เราแยกการอ่านหน้าจอออกจากการลงมือ งานที่มีผลจริงต้องผ่านสิทธิ์ การอนุมัติ และผลลัพธ์ที่ตรวจได้ หากต้องการเข้าใจชั้นงานตั้งแต่เจตนาไปจนถึงผลลัพธ์ คู่มือ AI agent ควบคุมโทรศัพท์ Android: จากเจตนา สู่ข้อเสนอ การยืนยัน และผลลัพธ์ที่ตรวจได้ จะช่วยวางภาพรวมก่อนลงรายละเอียดเรื่องหลักฐานหน้าจอในบทความนี้

ใช้สถานะ Accessibility สดกับปุ่มและช่องที่มองเห็น

เมื่อ AI เข้าใจหน้าจอ Android ผ่าน UI tree สิ่งที่สำคัญที่สุดคือความสดของสถานะ เอกสาร AccessibilityService ของ Android อธิบายว่า accessibility service สามารถรับเนื้อหาหน้าต่างที่ระบบเปิดเผยและโต้ตอบผ่าน API ที่รองรับได้ แต่หน้าจอ Android เปลี่ยนได้ตลอดหลังจากอ่านข้อมูลแล้ว ดังนั้นการกระทำที่ปลอดภัยต้องอิงสถานะล่าสุด ไม่ใช้ node เก่าที่อาจไม่ตรงกับหน้าจอปัจจุบัน

ข้อมูลเชิงความหมายเหมาะกับงานที่ต้องเลือก control ชัดเจน เช่น เปิดเมนู แตะปุ่ม กรอกช่อง หรืออ่านสถานะที่แอประบุไว้ ถ้า node มีป้ายกำกับที่เข้าใจได้ มีสถานะ enabled หรือ checked ที่ตรงกับคำขอ และอยู่ในหน้าต่างที่ผู้ใช้เห็นอยู่ FoneClaw สามารถใช้ข้อมูลนั้นเพื่อเสนอขั้นตอนถัดไปในงานที่รองรับได้โดยไม่ต้องจับภาพหน้าจอเพิ่มเติม

อย่างไรก็ตาม UI tree ไม่รับประกันว่าทุกแอปจะเปิดเผยความหมายครบถ้วน บางแอปวาดหน้าจอเองด้วย canvas บางหน้ามี WebView หรือ overlay บัง control บางปุ่มมีชื่อซ้ำกัน เช่น ตกลง หลายตำแหน่ง และบาง state เปลี่ยนหลัง animation หรือ keyboard เปิดขึ้นมา ถ้า label คลุมเครือหรือมีเป้าหมายซ้ำ การกดต่อจากข้อมูลนั้นอาจกลายเป็นการเดา

ขั้นตรวจที่ผู้อ่านใช้ได้คือถามสามข้อก่อนลงมือ: หน้าจอที่อ่านอยู่ใช่หน้าจอที่ผู้ใช้เห็นหรือไม่ control มีชื่อและสถานะพอแยกจากตัวอื่นหรือไม่ และ action ที่จะทำอยู่ในเส้นทางที่รองรับหรือไม่ ถ้าคำตอบข้อใดไม่ชัด ให้รีเฟรชสถานะ ขอผู้ใช้เลือกเป้าหมายเอง หรือใช้ screenshot เฉพาะเมื่อภาพช่วยแยกความหมายได้จริง

ใช้ภาพหน้าจอสำหรับข้อเท็จจริงเชิงภาพและต้องได้รับอนุมัติ

Screenshot เป็นหลักฐานภาพของหน้าจอ ณ เวลาหนึ่ง มันมีประโยชน์เมื่อคำถามไม่ได้อยู่ใน semantics ที่แอปเปิดเผย เช่น กราฟขึ้นหรือลง แผนที่แสดงตำแหน่งไหน รูปใดถูกเลือก ปุ่มไอคอนอยู่ใต้การ์ดใด หรือสีเตือนแปลว่ารายการไหนต้องตรวจ ภาพช่วยให้ AI มองเห็นบริบทที่ UI tree อาจไม่บอก

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

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

บริบทอุตสาหกรรมกำลังให้ความสำคัญกับ real-time visual context มากขึ้น เช่น Google อธิบายความสามารถด้านบริบทภาพแบบสดใน ประกาศ Gemini Live แต่ในบทความนี้เราใช้เป็นตัวอย่างแนวโน้มเท่านั้น ไม่ได้สื่อว่า FoneClaw ผสานกับ Gemini หรือมีความสามารถเหมือนกัน หลักการของเราคือภาพช่วยตอบคำถามเชิงภาพ แต่การลงมือยังต้องผ่านขอบเขตผลิตภัณฑ์และการยืนยันของผู้ใช้

ลงมือผ่านเส้นทางที่รองรับแล้วตรวจสถานะใหม่

หลังจากเลือกหลักฐานได้แล้ว ขั้นตอนถัดไปคือดูว่ามีเส้นทางลงมือที่รองรับหรือไม่ FoneClaw เป็น Android phone-agent runtime สำหรับงานที่รองรับพร้อม governed tools และผลลัพธ์ที่ผู้ใช้ตรวจได้ ดังนั้นการกระทำที่มีผลจริงควรผ่านเครื่องมือที่ออกแบบมาสำหรับงานนั้น ไม่ใช่ใช้ screenshot เป็น fallback เพื่อเล็งพิกัดและกดแทนทุกกรณี

ลำดับที่ปลอดภัยคืออ่านสถานะสด ระบุเป้าหมาย เสนอสิ่งที่จะทำ ขออนุมัติเมื่อมีผลต่อข้อมูลหรือสถานะเครื่อง แล้วจึงลงมือผ่านเส้นทางที่รองรับ หลังจากนั้นต้องอ่านสถานะใหม่อีกครั้ง การส่ง gesture หรือเปิด flow ได้ไม่ได้แปลว่างานสำเร็จเสมอไป แอปอาจเปิด dialog เพิ่ม permission อาจยังไม่พร้อม หรือหน้าจออาจเปลี่ยนไปก่อน action เสร็จ

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

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

หยุดอย่างปลอดภัยเมื่อป้าย สถานะ หรือสิทธิ์ไม่พอ

safe failure เป็นส่วนหนึ่งของ Android AI agent ที่น่าเชื่อถือ ถ้าป้ายกำกับไม่ชัด มีหลายปุ่มชื่อเดียวกัน ภาพกับ UI tree ขัดกัน permission ยังไม่พร้อม หรือ action ที่ต้องการอยู่นอกขอบเขตที่รองรับ FoneClaw ควรหยุดและอธิบายเหตุผล ไม่ควรทำเหมือนว่างานสำเร็จหรือกดต่อจากความมั่นใจที่ตรวจไม่ได้

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

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

ถ้ากรณีของคุณเกี่ยวกับการใช้ภาพเดิมต่อเนื่องหรือการวิเคราะห์ภาพซ้ำ บทความ บริบทภาพ AI บน Android: ใช้ภาพเดิมต่อเนื่องและวิเคราะห์ซ้ำอย่างไร จะช่วยแยกว่าควรใช้ภาพเดิมเมื่อใด และเมื่อใดต้องจับสถานะใหม่ก่อนตัดสินใจ

แยกการเข้าใจภาพออกจากอำนาจลงมือบน Android

ความเข้าใจหน้าจอและอำนาจลงมือเป็นคนละชั้นกัน ชั้นแรกคือหลักฐาน เช่น UI tree หรือ screenshot ชั้นที่สองคือการตีความ เช่น ปุ่มไหนเกี่ยวกับคำขอ หรือภาพใดเป็นสถานะที่ต้องสนใจ ชั้นที่สามคือ authority ได้แก่ permission, supported tool, confirmation และการตรวจผลหลังทำงาน การข้ามจากชั้นแรกไปชั้นสามทันทีคือจุดที่ทำให้ automation เสี่ยง

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

หลักปฏิบัติที่จำง่ายคือใช้หลักฐานให้น้อยพอ อ่านสถานะสดก่อน action ใช้ screenshot เมื่อพิกเซลตอบคำถามจริง ขออนุมัติเมื่องานมีผล และหยุดเมื่อหลักฐานหรือสิทธิ์ไม่พอ วิธีนี้ทำให้ AI ช่วยเข้าใจหน้าจอ Android ได้ดีขึ้นโดยไม่เปลี่ยนการเห็นหน้าจอให้กลายเป็นการควบคุมที่ผู้ใช้ไม่ได้อนุมัติ