एआई कुछ ही सेकंड में लैंडिंग पेज जेनरेट कर सकता है।
वह हिस्सा अब प्रभावशाली नहीं है।
कठिन हिस्सा तब शुरू होता है जब आप एक अलग प्रश्न पूछते हैं:
क्या AI वास्तव में उस पृष्ठ को समझ सकता है जिसे आप संपादित कर रहे हैं?
क्या यह दस्तावेज़ के बाकी हिस्सों को तोड़े बिना एक अनुभाग को संशोधित कर सकता है? क्या यह आपके चर को संरक्षित कर सकता है? क्या यह अपने लेआउट को नष्ट किए बिना किसी मौजूदा पृष्ठ का अनुवाद कर सकता है? क्या यह एक नया अनुभाग उत्पन्न कर सकता है जो संपादक के अंदर एक मूल घटक की तरह व्यवहार करता है?
ये वे समस्याएं हैं जिनका सामना हमें GJSDocs के निर्माण के दौरान करना पड़ा, जो एक AI-संचालित विज़ुअल दस्तावेज़ संपादक है जो एक GrapesJS-आधारित संपादन अनुभव के आसपास बनाया गया है।
इस लेख में, हम एआई-संचालित विज़ुअल एडिटर के पीछे की वास्तुकला के बारे में जानेंगे, क्या काम किया, क्या नहीं किया, और हमने इसे उत्पादन के लिए बनाने के लिए क्या सबक सीखा।
एआई जेनरेटर और एआई संपादक के बीच अंतर
दो अलग-अलग उत्पाद हैं जिन्हें अक्सर "एआई पेज बिल्डर" कहा जाता है।
पहला इस तरह दिखता है:
Prompt ↓ AI ↓ HTML ↓ Preview आप दर्ज करें:
"एक आधुनिक SaaS लैंडिंग पृष्ठ बनाएं।
मॉडल HTML और CSS उत्पन्न करता है।
यह एक डेमो में प्रभावशाली दिखता है।
लेकिन आगे क्या होता है?
आप मूल्य निर्धारण अनुभाग बदलना चाहते हैं।
आप नायक का अनुवाद करना चाहते हैं।
आप सीटीए को बदलना चाहते हैं।
आप रिक्ति परिवर्तित करना चाहते हैं.
आप अपने CRM से कनेक्ट {customer.name} करना चाहते हैं.
अब आप पृष्ठ को मैन्युअल रूप से संपादित करने के लिए वापस आ गए हैं।
दूसरा दृष्टिकोण बहुत अधिक दिलचस्प है:
यहां एआई विज़ुअल एडिटर की जगह नहीं लेता है।
एआई संपादक को नियंत्रित करने का एक और तरीका बन जाता है।
यह अंतर GJSDocs का निर्माण करते समय हमारे द्वारा किए गए सबसे महत्वपूर्ण वास्तुशिल्प निर्णयों में से एक बन गया।
हमने GrapesJS क्यों चुना
जब आप स्क्रैच से एक विज़ुअल एडिटर बनाते हैं, तो कैनवास केवल शुरुआत होती है।
आप की जरूरत है:
घटक प्रबंधन;
खींचें और छोड़ें;
संग्रह;
शैलियों;
उत्तरदायी व्यवहार;
पूर्ववत करें/फिर से करें;
ब्लॉक;
क्रमबद्धता;
भंडार;
कीबोर्ड इंटरैक्शन;
प्लगइन्स;
आदेश;
परिसंपत्ति प्रबंधन;
और सब कुछ एक साथ काम करने का एक तरीका।
यह सब स्वयं बनाना महंगा है।
GrapesJS आपको संपादन इंजन देता है जबकि आपको इसके चारों ओर अपना उत्पाद अनुभव बनाने की अनुमति देता है।
यह ठीक उसी तरह की वास्तुकला है जिसे हम GJSDocs के लिए चाहते थे।
महत्वपूर्ण बात यह है कि GrapesJS यह जानने की आवश्यकता नहीं है कि एआई मौजूद है।
आपका एप्लिकेशन ऑर्केस्ट्रेशन परत बन जाता है।
यह अलगाव अत्यंत उपयोगी है।
संपादक दृश्य स्थिति का प्रबंधन करता है।
आपका एप्लिकेशन व्यावसायिक तर्क का प्रबंधन करता है।
एआई परत प्राकृतिक भाषा को संरचित संचालन में अनुवाद करती है।
एआई-संचालित GrapesJS संपादक की वास्तुकला
हमारी वास्तुकला को पांच परतों में सरल बनाया जा सकता है।
1. संपादक
GrapesJS कैनवास में वास्तविक दस्तावेज़ होता है.
2. संदर्भ
हम एआई को यह समझने के लिए आवश्यक जानकारी एकत्र करते हैं कि उपयोगकर्ता वर्तमान में क्या संपादित कर रहा है।
3. एआई प्रदाता
अनुरोध किसी LLM जैसे OpenAI, Gemini या Claude को भेजा जा सकता है.
4. संरचित आउटपुट
मॉडल मनमाने ढंग से HTML के बजाय एक पूर्वानुमानित संरचना लौटाता है।
5. संपादक एडाप्टर
एप्लिकेशन उस संरचना को GrapesJS घटकों में परिवर्तित करता है।
पूरा प्रवाह इस तरह दिखता है:
कॉन्टेक्स्ट बिल्डर सबसे महत्वपूर्ण टुकड़ों में से एक है।
संदर्भ के बिना, एआई अनुमान लगा रहा है।
संदर्भ के साथ, एआई संपादन कर रहा है।
चरण 1: एआई को संपादक संदर्भ तक पहुंच प्रदान करें
एक सामान्य गलती मॉडल को केवल उपयोगकर्ता का संकेत भेजना है।
उदाहरण के लिए:
Translate this section to Spanish. एआई को पता नहीं है कि "इस खंड" का क्या अर्थ है।
इसके बजाय, हम वैचारिक रूप से कुछ ऐसा भेज सकते हैं:
{ instruction: "Translate this section to Spanish", scope: "selection", document: { title: "Sales Proposal", page: 2 }, selection: { type: "section", html: "...", text: "...", components: [...] }, variables: [ "client.name", "company.name", "proposal.total" ] } अब मॉडल का एक सार्थक संदर्भ है।
यह जानता है:
उपयोगकर्ता ने क्या चुना;
यह किस पृष्ठ का है;
दस्तावेज़ किस बारे में है;
कौन से चर मौजूद हैं;
और उपयोगकर्ता ने किस ऑपरेशन का अनुरोध किया।
इससे बहुत फर्क पड़ता है।
चरण 2: AI से यादृच्छिक HTML वापस करने के लिए न कहें
यह एक और महत्वपूर्ण सबक था।
सबसे आसान कार्यान्वयन है:
Prompt → AI → HTML string लेकिन यह समस्याएं पैदा करता है।
जेनरेट किए गए HTML में ये शामिल हो सकते हैं:
अमान्य संरचना;
अप्रत्याशित सीएसएस;
अनावश्यक रैपर;
शैलियाँ जो मौजूदा दस्तावेज़ के साथ संघर्ष करती हैं;
लिपियों;
असमर्थित तत्व;
या ऐसी सामग्री जिसे बाद में आसानी से संपादित नहीं किया जा सकता है।
एक बेहतर वास्तुकला है:
उदाहरण के लिए:
{ "type": "section", "layout": "three-column", "heading": "Choose your plan", "columns": [ { "title": "Starter", "price": "{pricing.starter}" }, { "title": "Pro", "price": "{pricing.pro}", "featured": true }, { "title": "Business", "price": "{pricing.business}" } ] } आपका एप्लिकेशन तब तय करता है कि यह संरचना वास्तविक संपादक घटकों के लिए कैसे मैप करती है।
इससे आपको बहुत अधिक नियंत्रण मिलता है।
चरण 3: एआई को केवल सामग्री ही नहीं, बल्कि घटक उत्पन्न करने दें
एक बार एआई आउटपुट संरचित हो जाने के बाद, हम इसे कॉपी राइटिंग से कहीं अधिक के लिए उपयोग कर सकते हैं।
उदाहरण के लिए, कोई उपयोगकर्ता पूछ सकता है:
स्टार्टर, प्रो और व्यावसायिक योजनाओं के साथ तीन-कॉलम मूल्य निर्धारण अनुभाग बनाएं। प्रो को हाइलाइट किया गया विकल्प बनाएं।
एआई उस अनुभाग का एक संरचित प्रतिनिधित्व वापस कर सकता है।
आपका संपादक एडाप्टर इसे इसमें परिवर्तित करता है:
अब उत्पन्न परिणाम केवल HTML का एक टुकड़ा नहीं है।
यह एक वास्तविक संपादन योग्य दस्तावेज़ संरचना है।
यह एक बहुत अधिक शक्तिशाली मॉडल है।
चरण 4: एआई स्कोप का परिचय दें
GJSDocs में हमारे द्वारा लागू किए गए सबसे अच्छे UX सुधारों में से एक AI संचालन को गुंजाइश देने की अनुमति देना था।
एक विशाल "एआई जेनरेट" बटन के बजाय, इस बारे में सोचें:
संग्रह
केवल वही संशोधित करें जो उपयोगकर्ता ने चुना है।
Selection → AI → Selection कर्तन
एक संपूर्ण अनुभाग को संशोधित करें।
Section → AI → Updated Section पृष्ठ
वर्तमान पृष्ठ को रूपांतरित करें।
Page → AI → Updated Page दस्तावेज़
पूरे दस्तावेज़ को रूपांतरित करें।
Document → AI → Updated Document यह एक छोटे से विवरण की तरह लगता है।
यह नहीं है।
यह एआई से बदलाव करने के लिए कहने के उपयोगकर्ता के डर को नाटकीय रूप से कम कर देता है।
अगर मैं एक पैराग्राफ का चयन करता हूं और पूछता हूं:
"इसे और अधिक पेशेवर बनाएं।
मुझे उम्मीद नहीं है कि एआई मेरे पूरे दस्तावेज़ को फिर से डिज़ाइन करेगा।
स्कोप एक प्राकृतिक सुरक्षा सीमा बनाता है।
चरण 5: एआई को चर को समझना चाहिए
यह विशेष रूप से महत्वपूर्ण हो जाता है जब आपका संपादक केवल एक वेबसाइट बिल्डर नहीं होता है।
एक व्यावसायिक दस्तावेज़ पर विचार करें जिसमें शामिल हैं:
Dear {client.name}, Thank you for choosing {company.name}. Your total is {invoice.total}. एक AI सिस्टम जो HTML को आँख बंद करके फिर से लिखता है, गलती से उन चरों को बदल सकता है या हटा सकता है।
यह एक स्वचालन मंच में अस्वीकार्य है।
GJSDocs चर को एक अलग परत के रूप में मानता है।
एक टेम्पलेट में शामिल हो सकते हैं:
{client.name} {client.email} {company.name} {invoice.total} एआई उन चरों के आसपास सामग्री उत्पन्न कर सकता है जबकि चर प्रणाली बाद में उन्हें हल करने के लिए जिम्मेदार रहती है।
यह एक उपयोगी अलगाव बनाता है:
यह आर्किटेक्चर एक ही टेम्पलेट को सैकड़ों वैयक्तिकृत दस्तावेज़ उत्पन्न करने की अनुमति देता है।
चरण 6: AI को वास्तविक डेटा से कनेक्ट करें
चर के बाद अगला चरण बाहरी डेटा है।
एक पेज बिल्डर तब काफी अधिक उपयोगी हो जाता है जब जेनरेट की गई सामग्री वास्तविक व्यावसायिक डेटा के साथ काम कर सकती है।
उदाहरण के लिए:
GJSDocs Airtable, HubSpot और Google शीट्स जैसे एकीकरण के साथ-साथ कस्टम REST API स्रोतों का समर्थन करता है।
इसका मतलब है कि संपादक अब केवल एक डिज़ाइन टूल नहीं है।
यह एक डेटा-संचालित जनरेशन सिस्टम बन जाता है।
कल्पना कीजिए कि एक बिक्री टीम एक बार एक प्रस्ताव टेम्पलेट बना रही है।
टेम्पलेट में शामिल हैं:
{client.name} {client.company} {project.name} {project.price} एप्लिकेशन ग्राहक के डेटा को पुनर्प्राप्त करता है।
एआई उपयुक्त अनुभाग उत्पन्न या फिर से लिख सकता है।
टेम्पलेट प्रस्तुत किया गया है।
अंतिम दस्तावेज़ निर्यात किया जाता है।
यह एक पारंपरिक पेज बिल्डर से बहुत अलग उत्पाद है।
चरण 7: एकाधिक एआई प्रदाता
हमने यह भी सीखा कि एआई को अनावश्यक रूप से एक प्रदाता के साथ नहीं जोड़ा जाना चाहिए।
अलग-अलग मॉडल अलग-अलग चीजों में अच्छे होते हैं।
कुछ उपयोगकर्ता OpenAI पसंद करते हैं।
अन्य मिथुन पसंद करते हैं।
अन्य लोग क्लाउड चाहते हैं।
इस कारण से, एप्लिकेशन को आदर्श रूप से प्रदाता अमूर्तता को उजागर करना चाहिए:
const ai = createAIProvider({ provider: "openai", apiKey: process.env.OPENAI_API_KEY }); अवधारणात्मक रूप से:
संपादक को इस बात की परवाह नहीं करनी चाहिए कि किस मॉडल ने प्रतिक्रिया उत्पन्न की है।
इसे केवल अनुबंध की परवाह करनी चाहिए:
Input → Structured Output इससे सिस्टम को विकसित करना बहुत आसान हो जाता है।
GJSDocs वर्तमान में AI-संचालित दस्तावेज़ निर्माण और परिवर्तन के लिए Gemini, OpenAI और Claude का समर्थन करता है।
चरण 8: एआई को मौजूदा सामग्री को संपादित करने में सक्षम होना चाहिए
एक नया पेज बनाना उपयोगी है।
किसी मौजूदा पृष्ठ को संपादित करना यकीनन अधिक मूल्यवान है।
एक पैराग्राफ चुनने और पूछने की कल्पना करें:
इसे छोटा करें।
या:
इस पृष्ठ का फ्रेंच में अनुवाद करें।
या:
अधिक उद्यम दर्शकों के लिए इस प्रस्ताव को फिर से लिखें।
या:
इस अनुभाग को तुलना तालिका से बदलें।
ये मूल रूप से संपादन संचालन हैं।
एआई वर्कफ़्लो बन जाता है:
यह इस बात के बहुत करीब है कि मनुष्य वास्तव में दृश्य संपादकों का उपयोग कैसे करते हैं।
चरण 9: एआई को कभी भी असीमित नियंत्रण न दें
एक एआई-संचालित संपादक को मॉडल द्वारा लौटाए जाने वाले हर चीज को आँख बंद करके निष्पादित नहीं करना चाहिए।
यह विशेष रूप से महत्वपूर्ण है जब उत्पन्न परिणाम प्रभावित कर सकता है:
एचटीएमएल;
सीएसएस;
JavaScript;
बाहरी यूआरएल;
प्रपत्र;
एम्बेड;
एपीआई कॉल;
या उपयोगकर्ता डेटा।
हम एआई आउटपुट को अविश्वसनीय इनपुट के रूप में मानने की सलाह देते हैं।
इसे मान्य करें।
इसे सैनिटाइज करें।
सीमित करें कि कौन से घटक उत्पन्न किए जा सकते हैं।
मनमाने ढंग से JavaScript की अनुमति न दें जब तक कि कोई बहुत अच्छा कारण न हो।
और जब भी संभव हो, समर्थित घटक प्रकारों की श्वेतसूची का उपयोग करें।
उदाहरण के लिए:
const allowedComponents = [ "section", "container", "heading", "text", "image", "button", "columns", "table" ]; यदि मॉडल अनुमत स्कीमा के बाहर कुछ लौटाता है, तो इसे अस्वीकार करें या रूपांतरित करें।
एलएलएम को सुझाव देना चाहिए।
आपका आवेदन नियंत्रण में रहना चाहिए।
एआई पेज बिल्डर आर्किटेक्चर जिसकी हम अनुशंसा करते हैं
सब कुछ एक साथ रखना:
इस वास्तुकला का एक बड़ा फायदा है:
हर परत की एक स्पष्ट जिम्मेदारी होती है।
हम क्या नहीं करेंगे
एआई-संचालित संपादक बनाने के बाद, कुछ ऐसे दृष्टिकोण हैं जिनसे हम बचेंगे।
1. प्रत्येक अनुरोध के लिए एक संपूर्ण पृष्ठ उत्पन्न न करें
यदि उपयोगकर्ता आपसे शीर्षक बदलने के लिए कहता है, तो पूरे दस्तावेज़ को पुन: उत्पन्न न करें।
छोटे कार्यों को छोटे बदलाव करने चाहिए।
2. केवल कच्चे HTML पर निर्भर न रहें
HTML एक आउटपुट स्वरूप है।
यह जरूरी नहीं कि आपका आंतरिक AI प्रोटोकॉल हो।
संरचित डेटा आपको अधिक नियंत्रण देता है।
3. एआई स्थिति को उपयोगकर्ता से न छिपाएं
उपयोगकर्ताओं को पता होना चाहिए कि एआई क्या बदलने वाला है।
अच्छे UX में शामिल हो सकते हैं:
पूर्वसमीक्षा;
अंतर;
पूर्ववत करें;
पुन: उत्पन्न करना;
स्वीकार करें/अस्वीकार करें;
चयन का दायरा।
4. एआई को एकमात्र इंटरफ़ेस न बनने दें
कुछ उपयोगकर्ता टाइप करना चाहते हैं:
"बटन को नीला बनाओ।
अन्य लोग रंग बीनने वाले पर क्लिक करना चाहते हैं।
एक अच्छे विज़ुअल एडिटर को दोनों का समर्थन करना चाहिए।
एआई और पारंपरिक यूआई को एक दूसरे के पूरक होने चाहिए।
यूएक्स हमें सबसे महत्वपूर्ण लगा
सबसे दिलचस्प सबक तकनीकी नहीं था।
यह यूएक्स था।
एआई सबसे अच्छा काम करता है जब यह प्रासंगिक होता है।
संपादक के बगल में एक विशाल चैटबॉट रखने के बजाय, एआई क्रियाएं वहां रखें जहां उपयोगकर्ता पहले से ही काम कर रहा है।
उदाहरण के लिए:
अब एआई संपादक का हिस्सा लगता है।
एक अलग उत्पाद नहीं।
यह अंतर अनुभव को और अधिक स्वाभाविक बनाता है।
पहला संस्करण बनाना
आपको पहले दिन पूरे सिस्टम का निर्माण करने की आवश्यकता नहीं है।
एक अच्छे एमवीपी में केवल तीन एआई ऑपरेशन हो सकते हैं:
1. उत्पन्न करें
Prompt → New Section 2. फिर से लिखें
Selected Content → Improved Content 3. अनुवाद करें
Selected Content → Translated Content फिर जोड़ें:
पूर्ण-पृष्ठ पीढ़ी
शैली संशोधन
लेआउट जनरेशन
परिवर्तनीय निष्कर्षण
डेटा-जागरूक पीढ़ी
एआई टेम्पलेट्स
एआई वर्कफ़्लो
महत्वपूर्ण बात यह है कि वास्तुकला को शुरू से ही सही ढंग से स्थापित करना है।
पेज बिल्डर से एआई एप्लिकेशन प्लेटफॉर्म तक
यहीं पर चीजें वास्तव में दिलचस्प हो जाती हैं।
एक बार जब आपका AI संपादक के घटक वृक्ष को समझ लेता है, तो यह पृष्ठ उत्पन्न करने के अलावा और भी बहुत कुछ कर सकता है।
यह एक ऑर्केस्ट्रेशन परत बन सकता है।
उदाहरण के लिए:
"Create a proposal for Acme Corp." अंततः ट्रिगर हो सकता है:
उस समय, आप अब केवल एक पेज बिल्डर का निर्माण नहीं कर रहे हैं।
आप एक एआई-नेटिव कंटेंट एप्लिकेशन बना रहे हैं।
हम मानते हैं कि दृश्य संपादक इसी दिशा में जा रहे हैं।
हमने GJSDocs का निर्माण क्या सीखा
GJSDocs के निर्माण ने AI संपादक के बारे में हमारा दृष्टिकोण बदल दिया।
सबसे पहले, यह सोचने के लिए आकर्षक है:
"हमें बस एक एलएलएम को संपादक से जोड़ने की जरूरत है।
वास्तव में, मॉडल सिस्टम का केवल एक हिस्सा है।
कठिन समस्याएं हैं:
प्रसंग;
सुव्यवस्थित करना;
सत्यापन;
संपादक राज्य;
चर;
डाटा;
अनुमतियाँ;
प्रयोगकर्ता का अनुभव;
और पूर्वानुमानित परिवर्तन।
एआई मॉडल खुफिया परत है।
संपादक वह वातावरण है जिसमें वह खुफिया काम करता है।
यही कारण है कि GrapesJS इस प्रकार के उत्पाद के लिए इतनी दिलचस्प नींव है।
यह आपके एप्लिकेशन को एआई, डेटा, बिजनेस लॉजिक और यूएक्स बनाने के लिए मुफ्त छोड़ते हुए विज़ुअल एडिटिंग इंजन प्रदान करता है।
अंतिम वास्तुकला
यदि हम आज एक नया एआई-संचालित GrapesJS प्रोजेक्ट शुरू कर रहे थे, तो हमारा बेसलाइन आर्किटेक्चर कुछ इस तरह दिखेगा:
सटीक स्टैक बदल सकता है।
सिद्धांत नहीं है।
संपादक, एआई और व्यावसायिक तर्क को अलग-अलग परतों के रूप में रखें।
भविष्य एआई बनाम विज़ुअल एडिटर नहीं है
हमें नहीं लगता कि एआई विज़ुअल एडिटर्स की जगह लेगा।
हमें लगता है कि इसके विपरीत होगा।
विज़ुअल एडिटर AI को कुछ अविश्वसनीय रूप से मूल्यवान देते हैं:
अंदर काम करने के लिए एक संरचित वातावरण।
और एआई दृश्य संपादकों को कुछ ऐसा देता है जिसकी उनके पास ऐतिहासिक रूप से कमी है:
जटिल संरचनाओं में हेरफेर करने के लिए एक प्राकृतिक-भाषा इंटरफ़ेस।
भविष्य का पेज बिल्डर कम दिख सकता है:
खींचें → छोड़ें → कॉन्फ़िगर करें → दोहराएं
और अधिक पसंद है:
"मेरे लिए B2B SaaS कंपनी के लिए एक मूल्य निर्धारण पृष्ठ बनाएं।
फिर:
"प्रो योजना को और अधिक प्रमुख बनाएं।
फिर:
"इसे जर्मन में अनुवाद करें।
फिर:
"कीमतों को हमारे एपीआई से कनेक्ट करें।
फिर:
"इसे पहले मोबाइल-बनाएं।
अंत में:
"इसे प्रकाशित करें।
उपयोगकर्ता नियंत्रण में रहता है।
दृश्य संपादक सत्य का स्रोत बना हुआ है।
एआई बस यह व्यक्त करने का सबसे तेज़ तरीका बन जाता है कि उपयोगकर्ता क्या चाहता है।
यही वह मॉडल है जिसे हम GJSDocs के साथ बना रहे हैं।
अंतिम टेकअवे
यदि आप एक SaaS उत्पाद बना रहे हैं जिसे 2026 में एक विज़ुअल एडिटर की आवश्यकता है, तो AI को ऐड-ऑन चैटबॉट के रूप में न सोचें।
इसे अपने संपादक के लिए एक नई इंटरैक्शन परत के रूप में सोचें।
GrapesJS से शुरू करें।
एक मजबूत संदर्भ परत बनाएं।
संरचित AI आउटपुट का उपयोग करें।
चर और डेटा को जेनरेट की गई सामग्री से अलग रखें।
सब कुछ मान्य करें।
उपयोगकर्ताओं को गुंजाइश और नियंत्रण दें।
और सबसे महत्वपूर्ण बात:
AI को संपादक की जगह न लें। AI को संपादक को समझाएं।
यहीं पर एक एआई-संचालित पेज बिल्डर वास्तव में शक्तिशाली हो जाता है।