AI UI ऑटो-करेक्शन क्यों विफल होता है और इसका अंतिम समाधान

@Lonely__MH
चीनी13 सित॰ 2026
185K
241
36
58
483

TL;DR

लेखक ने यह अन्वेषण किया है कि AI-संचालित UI ऑटो-करेक्शन अक्सर गुणवत्ता में गिरावट का कारण क्यों बनता है, और स्थिर परिणामों के लिए विज़ुअल डिफ़्स, संरचित निदान और ऐतिहासिक सर्वश्रेष्ठ संस्करणों को सुरक्षित रखने वाले एक वर्कफ़्लो का प्रस्ताव रखा है।

यह लेख उन कुछ चुनौतियों (pitfalls) को दर्ज करता है जिनका सामना मैंने हाल ही में AI का उपयोग करके पेज बनाने के दौरान किया। बाद में, मैंने इन समस्याओं को हल करने के लिए एक वर्कफ़्लो बनाया और पूरे प्रक्रिया को संदर्भ के लिए व्यवस्थित किया।

आपने भी शायद यह अनुभव किया होगा।

कभी-कभी आप AI को एक स्क्रीनशॉट देते हैं और उससे उस पर आधारित पेज बनाने को कहते हैं। पहला संस्करण लगभग सही दिखता है, लेकिन ध्यान से देखने पर कुछ चीज़ें अलग महसूस होती हैं: कार्ड थोड़े चौड़े होते हैं, फ़ॉन्ट छोटे होते हैं, छाया (shadows) गलत होती हैं—बस मामूली मुद्दे।

फिर आपको verbally समझाना पड़ता है कि क्या बदलना है और कैसे। कई राउंड में इटरेशन (iteration) करने में काफ़ी समय लग जाता है।

इसलिए मैंने सोचा कि रेंडरिंग, स्क्रीनशॉट, तुलना और संशोधन को एक वर्कफ़्लो में जोड़ा जाए, जिससे मॉडल खुद चेक करके ठीक कर सके। यह दृष्टिकोण तार्किक लग रहा था।

लेकिन व्यावहारिक रूप से, चीज़ें योजना के अनुसार नहीं चलीं। कभी-कभी दूसरे राउंड की मरम्मत के बाद, तीसरा राउंड बदलावों को वापस ले लेता; परिणाम उतार-चढ़ाव वाले रहते, और हर इटरेशन के साथ पेज और खराब हो सकता था।

सीधे मुद्दे पर आते हैं।

इसे स्व-सुधारक (Self-Correct) कैसे बनाएं

प्रक्रिया जटिल नहीं है:

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 मॉडल के लिए पेज को ठीक नहीं करता। यह बस "यह सही नहीं दिख रहा" को विशिष्ट विचलनों (deviations) के एक दृश्य मानचित्र में बदल देता है, जिसे फिर मॉडल को अगले कदम तय करने के लिए वापस दिया जाता है।

मॉडल को Diff के आधार पर अंधेरे में अनुमान लगाने से रोकने के लिए, हर संशोधन से पहले, मैं इसे तीन सवालों के जवाब देने के लिए बाध्य करता हूँ:

  1. सबसे बड़ी समस्या कहाँ है?
  2. किस एलिमेंट या CSS property ने इसका कारण बना हो सकता है?
  3. इसे ठीक करने की योजना क्या है?

जवाब देने के बाद ही हम कोड में छेड़छाड़ करते हैं।

इस परीक्षण के लिए, मैंने Ling-3.0-flash-VL का उपयोग किया और एक सरल डेमो के लिए दो कार्ड चुने: एक पीला कार्ड जिसमें चमकीली पृष्ठभूमि, मोटी काली सीमा और कठोर छाया थी; दूसरा एक गहरा SaaS मूल्य निर्धारण कार्ड जिसमें ग्रेडिएंट बटन, टैग और विशेषता सूचियाँ थीं।

मुझे लगता है कि कार्ड एकदम सही हैं। बहुत अधिक एलिमेंट नहीं, लेकिन चौड़ाई, व्हाइटस्पेस, बटन की दिशा और छायाएँ—अगर कोई एक भी चीज़ गलत है, तो यह तुरंत नज़र आ जाती है।

पहली बार चलाना

आइए पीले कार्ड से शुरू करें।

पहले संस्करण के बाद, समग्र परिणाम वास्तव में काफ़ी अच्छा था।

संरचना, रंग योजना, कॉपी और बटन की स्थिति अधिकांशतः प्रतिकृत हो गई थी। अगर आप मूल के साथ साइड-बाय-साइड तुलना न करें, तो आप सोच सकते हैं कि यह पर्याप्त निकट है।

लेकिन जब उन्हें साथ रखा जाता है, तो सूक्ष्म अंतर सामने आते हैं: कार्ड थोड़ा बड़ा है, फ़ॉन्ट वेट अलग हैं, और व्हाइटस्पेस/बटन का आकार पूरी तरह संरेखित नहीं है।

फिर मैंने मूल छवि, पहले राउंड का परिणाम और Diff को Ling को वापस दिया, और उससे इन विस्तार समस्याओं की पहचान करने के लिए कहा।

निदान से पता चलता है कि यह सिर्फ "पर्याप्त समान नहीं" नहीं कहता। यह कार्ड के आकार, फ़ॉन्ट और बटन जैसी समस्याओं को सटीक रूप से चिह्नित करता है, फिर संबंधित CSS को संशोधित करता है।

Lonely - inline image

पीले कार्ड की तीन-राउंड तुलना: राउंड 2 में सुधार हुआ, राउंड 3 में गिरावट आई, इसलिए हमने राउंड 2 को ऐतिहासिक सर्वश्रेष्ठ के रूप में रखा।

हालाँकि, एक अच्छा पहला राउंड लगातार सुधार की गारंटी नहीं देता।

यह वीडियो इस मुद्दे को कैप्चर करता है: राउंड 2 मूल के अधिक निकट था, लेकिन राउंड 3 थोड़ा पीछे चला गया। सौभाग्य से, वर्कफ़्लो ने अंतिम राउंड को उत्तर के रूप में डिफ़ॉल्ट नहीं लिया, बल्कि राउंड 2 के ऐतिहासिक सर्वश्रेष्ठ को सुरक्षित रखा।

तो Diff को वापस फीड करना इस बात का मतलब नहीं है कि मॉडल अचानक स्मार्ट हो गया। यह कई विस्तार समस्याओं को देख सकता है और निर्णयों को विशिष्ट CSS से जोड़ सकता है, लेकिन यह अभी भी कभी-कभी भ्रमित हो जाता है।

वर्कफ़्लो कैसे चलता है, इसके विवरण के लिए नीचे स्क्रीन रिकॉर्डिंग देखें।

Lonely - inline image

गहरे मूल्य निर्धारण कार्ड का पूर्ण डेमो: एसेट्स का चयन, प्रारंभिक जनरेशन, स्लाइडर तुलना, फिर दो स्व-मरम्मत (self-healing) राउंड चलाना।

यहाँ बदलाव नाटकीय नहीं थे क्योंकि पहला राउंड पहले से ही निकट था। बाद के राउंड में निरंतर सुधार होता रहा, जिसमें कार्ड का आकार, गोलाकार कोने (rounded corners), बटन और ग्रेडिएंट्स पर ध्यान केंद्रित किया गया।

दोनों रिकॉर्डिंग की तुलना करने पर अलग-अलग रुझान दिखाई देते हैं:

Lonely - inline image

पीला कार्ड राउंड 2 तक सुधरा लेकिन राउंड 3 में गिरावट आई; गहरे कार्ड ने तीनों राउंड में स्थिर छोटे सुधार दिखाए। हालाँकि दो रिकॉर्डिंग सांख्यिकीय नियमों को साबित नहीं करतीं, वे यह दर्शाती हैं कि एक ही वर्कफ़्लो हर राउंड में बेहतर परिणाम नहीं देता।

स्पष्ट समस्याएँ आमतौर पर पहले एक या दो राउंड में ठीक हो जाती हैं। बाद के इटरेशन में फ़ॉन्ट आकार, गोलाकार कोने और छाया ऑफसेट में सूक्ष्म समायोजन शामिल होते हैं, जहाँ एक चीज़ को ठीक करने पर अक्सर दूसरी टूट जाती है। इसलिए, मैं ऐतिहासिक सर्वश्रेष्ठ को सहेजता हूँ, यह मानने के बजाय कि अंतिम राउंड ही उत्तर है।

यह वास्तव में क्या कर सकता है?

इन परिणामों से, पहला संस्करण मानक Screenshot-to-Code है। दिलचस्प बात यह है कि रेंडर किए गए आउटपुट को देखने के बाद, यह समस्याओं को विशिष्ट एलिमेंट्स और CSS properties तक सटीक रूप से चिह्नित कर सकता है, बजाय सिर्फ "इसे अधिक समान बनाओ" कहने के।

भले ही स्वचालित मरम्मत न हो, यह निदान चरण एक उपयोगी चेकलिस्ट के रूप में कार्य करता है।

कई दृश्य समस्याएँ त्रुटियाँ (errors) ट्रिगर नहीं करतीं। यदि मॉडल ब्राउज़र के वास्तविक रेंडर किए गए पेज को देख सकता है, तो उसे खुद को ठीक करने का मौका मिलता है।

एक अन्य व्यावहारिक बिंदु: इस वर्कफ़्लो के लिए बार-बार मॉडल कॉल की आवश्यकता होती है, इसलिए गति महत्वपूर्ण है। मेरी रिकॉर्ड की गई एकल पूर्ण-पेज HTML जनरेशन में लगभग 7 सेकंड लगे। सार्वजनिक डेटा दिखाता है कि Ling-3.0-flash-VL में कुल 124B पैरामीटर हैं, प्रति इन्फरेंस 5.5B सक्रिय होते हैं, साथ ही दृश्य समझ और Visual Agent क्षमताएँ जोड़ी गई हैं।

7 सेकंड का आंकड़ा मेरे विशिष्ट इंटरफ़ेस और सेटिंग्स पर आधारित है। मैंने क्षैतिज तुलनाएँ नहीं की हैं और न ही केवल सक्रिय पैरामीटर से गति/लागत व्युत्पन्न करूँगा।

चुनौतियाँ (Pitfalls) कहाँ हैं?

वास्तविक समय की खपत मॉडल को जोड़ने में नहीं, बल्कि सटीक फीडबैक प्राप्त करने में हुई। शुरुआत में, मैंने सोचा कि उतार-चढ़ाव का मतलब मॉडल अस्थिरता है। Diffs को एक-एक करके जांचने के बाद, मुझे एहसास हुआ कि समस्या का एक हिस्सा मेरे फीडबैक लूप में था।

1. पहली चुनौती: आकार (Size)

यदि लक्ष्य छवि को स्केल किया गया था और ब्राउज़र को एक अलग आकार पर स्क्रीनशॉट लिया गया था, तो छवियाँ शुरू से ही संरेखित नहीं होती थीं। सही उत्तर होने पर भी, Diff में बड़े असंगत दिखाई देते थे।

पिक्सेल diffs के लिए, वैश्विक स्तर पर कुछ पिक्सेल का अंतर बड़ी मात्रा में त्रुटि क्षेत्र बनाता है।

2. दूसरी चुनौती: एनिमेशन (Animation)

एक बार, मॉडल ने विशेषता सूचियों में fade-in प्रभाव जोड़े। एनिमेशन के बीच में लिए गए स्क्रीनशॉट ने सामग्री को पारदर्शी छोड़ दिया।

एनिमेशन हटाने के बाद, पेज दृश्य रूप से सामान्य दिखता था, लेकिन स्वचालित तुलना स्कोर खराब हो गए।

कारण: पारदर्शी सामग्री ने पृष्ठभूमि को प्रकट किया, जिससे पिक्सेल एल्गोरिदम ने सोचा कि यह "अधिक समान दिखता है"।

3. तीसरी चुनौती: वर्जनिंग (Versioning)

यदि किसी राउंड में डिज़ाइन टूट गया, तो खराब कोड के ऊपर पैच जारी रखने से त्रुटियाँ जमा हो जाती हैं। जैसे टेढ़ी नींव पर इमारत बनाना—जितनी मेहनत करें, उतना ही अव्यवस्था बढ़ती है।

संक्षेप में, Diff एक उपकरण है, न्यायाधीश नहीं।

यदि फीडबैक गलत है, तो मॉडल उसे नहीं पकड़ पाएगा। यह दोषपूर्ण इनपुट के आधार पर गलत दिशा में ईमानदारी से सुधार करने का प्रयास करेगा।

निष्कर्ष

मैंने नियमों को तीन बिंदुओं में संक्षेपित किया:

  1. मूल और ब्राउज़र स्क्रीनशॉट के लिए समान आयामों का उपयोग करें; कोई द्वितीयक स्केलिंग नहीं।
  2. व्यूपोर्ट, फ़ॉन्ट, एनिमेशन स्थितियों और स्क्रीनशॉट टाइमिंग को स्थिर करें।
  3. हर राउंड में ऐतिहासिक सर्वश्रेष्ठ संस्करण से जारी रखें; गिरावट वाले कोड पर पैच न लगाएं।

कार्यशील कोड केवल पहला कदम है। समस्याएँ जो त्रुटि नहीं देतीं लेकिन गलत दिखती हैं, वास्तव में दृश्य मॉडल द्वारा जांची जा सकती हैं। हालाँकि, विचलन देखना हर बार सही सुधार की गारंटी नहीं देता।

इसलिए मैं अब यह नहीं मानता कि अधिक राउंड का मतलब बेहतर परिणाम है। स्पष्ट समस्याओं को पहले ठीक करें, जब सुधार प्लेटो (plateau) पर पहुँच जाए तो रुक जाएँ—मेरे लिए यह पर्याप्त है।

मॉडल ओपन-सोर्स है और 2 सप्ताह के लिए निःशुल्क है। इसे स्वयं चलाने के लिए, इन लिंक का उपयोग करें 👇🏻:

Ps: यह लेख AI द्वारा सुनाया और परिष्कृत किया गया है, इसलिए इसमें आत्मा है ✌🏻

एक क्लिक में सहेजें

YouMind में वायरल लेखों की AI गहन पढ़ाई

स्रोत सहेजें, केंद्रित सवाल पूछें, तर्क का सारांश बनाएँ और एक वायरल लेख को एक ही AI वर्कस्पेस में दोबारा इस्तेमाल करने लायक नोट्स में बदलें।

YouMind देखें
क्रिएटर्स के लिए

अपने Markdown को एक साफ़-सुथरे 𝕏 आर्टिकल में बदलें

जब आप अपना लंबा कंटेंट पब्लिश करते हैं, तो इमेज, टेबल और कोड ब्लॉक को 𝕏 के लिए फ़ॉर्मेट करना मुश्किल होता है। YouMind पूरे Markdown ड्राफ़्ट को एक साफ़-सुथरे, पोस्ट के लिए तैयार 𝕏 आर्टिकल में बदल देता है।

Markdown से 𝕏 आज़माएँ

समझने के लिए और पैटर्न

हाल के वायरल लेख

और वायरल लेख देखें