แก้ไขข้อผิดพลาดของการปรับแต่ง UI ด้วย AI ด้วยเวิร์กโฟลว์นี้

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

คุณก็น่าจะเคยเจอประสบการณ์แบบนี้เช่นกัน

บางครั้งคุณส่งภาพหน้าจอให้ AI แล้วขอให้มันสร้างหน้าเว็บตามนั้น เวอร์ชันแรกดูเผินๆ ก็โอเค แต่พอสังเกตดีๆ จะรู้สึกว่ามีบางอย่างผิดเพี้ยนไป: การ์ดกว้างเกินไปเล็กน้อย ฟอนต์เล็กกว่า เงาไม่ตรงจุด—ล้วนเป็นเรื่องเล็กๆ น้อยๆ

จากนั้นคุณก็ต้องอธิบายด้วยคำพูดว่าต้องปรับอะไรบ้างและอย่างไร การวนแก้ทีละรอบกินเวลาพอสมควร

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

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

เข้าประเด็นกันเลยดีกว่า

ทำอย่างไรให้มันแก้ไขตัวเองได้

กระบวนการไม่ได้ซับซ้อน:

text

1Target Screenshot ──▶ Model writes HTML ──▶ Browser renders 1:1 screenshot ──▶ Pixel-by-pixel diff generation
2                                                         │
3Keep Best History ◀── Re-render ◀── Model diagnoses then edits code ◀── Original + Rendered + Diff

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

เพื่อป้องกันไม่ให้โมเดลเดาสุ่มโดยอาศัยเพียง Diff ก่อนการแก้ไขแต่ละครั้ง ผมกำหนดให้มันตอบคำถามสามข้อ:

ปัญหาที่ใหญ่ที่สุดอยู่ที่ไหน?
องค์ประกอบหรือคุณสมบัติ CSS ใดที่น่าจะเป็นสาเหตุ?
วางแผนจะแก้ไขอย่างไร?

เราจะเริ่มแตะโค้ดก็ต่อเมื่อตอบคำถามเหล่านี้เรียบร้อยแล้ว

สำหรับการทดสอบนี้ ผมใช้ Ling-3.0-flash-VL และเลือกการ์ดสองใบสำหรับสาธิตแบบง่ายๆ: ใบหนึ่งเป็นการ์ดสีเหลืองพื้นหลังสว่าง ขอบดำหนา และมีเงาแข็ง อีกใบเป็นการ์ดราคา SaaS โทนเข้มที่มีปุ่มไล่ระดับสี ป้ายกำกับ (tags) และรายการฟีเจอร์

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

รันครั้งแรก

เริ่มจากการ์ดสีเหลืองกันก่อน

หลังจากเวอร์ชันแรก ผลลัพธ์โดยรวมถือว่าค่อนข้างดีเลย

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

แต่เมื่อนำมาวางเคียงกัน ความแตกต่างเล็กน้อยก็ปรากฏให้เห็น: การ์ดมีขนาดใหญ่กว่าเล็กน้อย น้ำหนักฟอนต์ต่างกัน และความห่าง/ขนาดปุ่มยังไม่ตรงเป๊ะ

จากนั้นผมนำภาพต้นฉบับ ผลลัพธ์รอบแรก และ Diff ป้อนกลับเข้าไปยัง Ling เพื่อให้มันระบุปัญหาเชิงรายละเอียดเหล่านี้

จากการวินิจฉัย มันไม่ได้แค่บอกว่า "ยังไม่ค่อยเหมือนพอ" แต่มันชี้จุดปัญหาเช่น ขนาดการ์ด ฟอนต์ และปุ่ม แล้วทำการแก้ไข CSS ที่เกี่ยวข้อง

เปรียบเทียบสามรอบของการ์ดสีเหลือง: รอบสองดีขึ้น แต่รอบสามถอยหลัง ดังนั้นเราจึงเลือกรอบสองเป็นค่าที่ดีที่สุดทางประวัติศาสตร์ (historical best)

อย่างไรก็ตาม การเริ่มต้นที่ดีไม่ได้การันตีว่าการพัฒนาจะต่อเนื่องเสมอไป

วิดีโอนี้จับภาพปัญหาที่เกิดขึ้น: รอบสองใกล้เคียงต้นฉบับมากขึ้น แต่รอบสามกลับแย่ลงเล็กน้อย โชคดีที่เวิร์กโฟลว์ไม่ได้ยึดรอบสุดท้ายเป็นคำตอบโดยอัตโนมัติ แต่เก็บรักษาค่าที่ดีที่สุดจากรอบสองไว้

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

สำหรับรายละเอียดวิธีการทำงานของเวิร์กโฟลว์ ดูบันทึกหน้าจอด้านล่าง

สาธิตเต็มรูปแบบของการ์ดราคาสีเข้ม: เลือกสินทรัพย์ สร้างเวอร์ชันแรก เปรียบเทียบด้วยแถบเลื่อน จากนั้นรันสองรอบของการแก้ไขตัวเอง (self-healing)

การเปลี่ยนแปลงที่นี่ไม่ได้ drastis มากนัก เพราะรอบแรกใกล้เคียงอยู่แล้ว รอบต่อๆ ไปยังคงปรับปรุงอย่างต่อเนื่อง โดยมุ่งเน้นไปที่ขนาดการ์ด มุมโค้ง ปุ่ม และการไล่ระดับสี

เมื่อเปรียบเทียบทั้งสองบันทึก จะเห็นแนวโน้มที่แตกต่างกัน:

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

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

มันทำอะไรได้บ้างจริงๆ?

จากผลลัพธ์เหล่านี้ เวอร์ชันแรกคือการแปลงภาพหน้าจอเป็นโค้ด (Screenshot-to-Code) แบบมาตรฐาน สิ่งที่น่าสนใจคือ หลังจากเห็นผลลัพธ์ที่เรนเดอร์ออกมาแล้ว มันสามารถระบุปัญหาไปยังองค์ประกอบและคุณสมบัติ CSS เฉพาะเจาะจงได้ แทนที่จะพูดแค่ว่า "ทำให้เหมือนมากขึ้น"

แม้ไม่มีระบบแก้ไขอัตโนมัติ ขั้นตอนการวินิจฉัยนี้ก็ทำหน้าที่เป็นเช็กลิสต์ที่มีประโยชน์

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

อีกประเด็นที่เป็นรูปธรรม: เวิร์กโฟลว์นี้ต้องการเรียกใช้โมเดลซ้ำๆ ดังนั้นความเร็วจึงสำคัญ การสร้าง HTML หน้าเต็มของผมใช้เวลาประมาณ 7 วินาที ข้อมูลสาธารณะระบุว่า Ling-3.0-flash-VL มีพารามิเตอร์รวม 124B โดยกระตุ้นใช้งาน (activate) 5.5B ต่อการอนุมาน พร้อมเพิ่มความสามารถในการเข้าใจภาพและ Visual Agent

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

กับดักอยู่ที่ไหน?

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

1. กับดักแรก: ขนาด

ถ้าภาพเป้าหมายถูกย่อ/ขยาย และเบราว์เซอร์ถ่ายภาพหน้าจอในขนาดที่ต่างกัน ภาพจะไม่ตรงกันตั้งแต่แรก แม้จะได้คำตอบที่ถูกต้อง Diff ก็ยังแสดงความคลาดเคลื่อนมหาศาล

สำหรับการเปรียบเทียบแบบ pixel-diff การคลาดเคลื่อนเพียงไม่กี่พิกเซลในระดับ global สามารถสร้างโซนความผิดพลาดขนาดใหญ่ได้

2. กับดักที่สอง: แอนิเมชัน

ครั้งหนึ่ง โมเดลเพิ่มเอฟเฟกต์ fade-in ให้กับรายการฟีเจอร์ การถ่ายภาพหน้าจอกลางแอนิเมชันทำให้เนื้อหาโปร่งใส

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

เหตุผล: เนื้อหาที่โปร่งใสเผยให้เห็นพื้นหลัง ทำให้อัลกอริทึม pixel คิดว่ามัน "ดูคล้ายกันมากขึ้น"

3. กับดักที่สาม: เวอร์ชัน

ถ้ารอบหนึ่งทำลายดีไซน์ การพยายามแปะซ่อมบนโค้ดที่เสียหายไปแล้วจะสะสมข้อผิดพลาด เหมือนกับการสร้างบ้านบนฐานรากที่เอียง ยิ่งพยายามมากเท่าไหร่ ยิ่งยุ่งเหยิงเท่านั้น

สรุปสั้นๆ คือ Diff เป็นเครื่องมือ ไม่ใช่ผู้ตัดสิน

ถ้า feedback ผิด โมเดลก็จะไม่รู้ทัน มันจะขยันแก้ไขไปในทิศทางที่ผิดโดยอาศัยข้อมูลนำเข้าที่บกพร่อง

บทสรุป

ผมกลั่นกรองกฎออกมาเป็นสามข้อ:

ใช้มิติขนาดเดียวกันสำหรับภาพต้นฉบับและภาพหน้าจอจากเบราว์เซอร์ ห้ามย่อ/ขยายซ้ำ
กำหนด viewport, ฟอนต์, สถานะแอนิเมชัน และจังหวะเวลาในการถ่ายภาพหน้าจอให้คงที่
ดำเนินการต่อจากเวอร์ชันที่ดีที่สุดทางประวัติศาสตร์ในแต่ละรอบ อย่าแปะซ่อมโค้ดที่เสื่อมสภาพ

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

ดังนั้น ผมจึงไม่สมมติอีกต่อไปว่ายิ่งวนรอบมากยิ่งได้ผลดี แก้ไขปัญหาที่ชัดเจนก่อน หยุดเมื่อการพัฒนาถึงจุดอิ่มตัว นั่นเพียงพอสำหรับผมแล้ว

โมเดลนี้เป็น open-source และใช้ฟรีเป็นเวลา 2 สัปดาห์ หากต้องการรันด้วยตัวเอง ใช้ลิงก์เหล่านี้ 👇🏻: