AI से बने ऐप को बिना तोड़े कैसे सुधारें

AI से बने ऐप को बिना तोड़े सुधारने के लिए, हर prompt में एक ही चीज़ बदलें, प्रीव्यू में उसे जाँचें, और आगे बढ़ने से पहले एक चेकपॉइंट सेव करें। आप जो दिख रहा है उसे बताएं, जो आपको लगता है कि कोड कर रहा है उसे नहीं, बड़े बदलावों को बनाने से पहले उनकी योजना बनाएं, और जब कोई बदलाव गलत हो जाए, तो AI से अपनी ही गलती ठीक करवाने के बजाय आखिरी ठीक वर्शन पर लौट जाएं।

ऐप का पहला वर्शन अक्सर मिनटों में तैयार हो जाता है। असली मुश्किल पचासवें बदलाव में आती है, जब हर नया prompt कुछ ऐसा तोड़ने का जोखिम लेता है जो पहले से काम कर रहा था। यह गाइड वही लूप है जो उस स्थिति से बचाता है।

सुधार का लूप

1. एक बदलाव चुनें। एक फ़ीचर, एक बग, एक पेज।
2. उसे वर्णित करें कि यूज़र क्या देखता और करता है।
3. बड़े बदलावों के लिए पहले योजना बनाएं। योजना माँगें, उसे पढ़ें, फिर बनवाएं।
4. प्रीव्यू में नतीजा जाँचें — बदलाव और उसके आसपास के फ़्लो।
5. सेव करें एक चेकपॉइंट या commit।
6. दोहराएं।

हर कदम बदलावों को छोटा और पलटने योग्य रखने के लिए है।

चरण 1: एक छोटी सूची रखें

prompt देने से पहले लिखें कि आप क्या बदलना चाहते हैं, महत्व के क्रम में। इससे आप एक ही मैसेज में दस इच्छाओं का पैराग्राफ़ नहीं भेजेंगे, और बीच में आए विचारों को "अभी नहीं" कह पाएंगे।

अगर बदलाव बड़ा है, तो उसे तोड़ें। "टीम अकाउंट जोड़ें" बन जाता है: टीम बनाना, एक सदस्य को आमंत्रित करना, टीमों के बीच बदलना, डेटा को मौजूदा टीम तक सीमित करना। हर एक का अपना prompt होता है। यूज़र स्टोरी कैसे लिखें इसके लिए एक अच्छा तरीका है।

चरण 2: जो आप देखते हैं वह बताएं

AI आपकी स्क्रीन नहीं देख सकता, जब तक आप उसे न बताएं। खास चीज़ों की ओर इशारा करें, और बताएं कि क्या होना चाहिए:

मोबाइल पर प्राइसिंग पेज पर, Pro कार्ड का बटन दाहिने किनारे से कटा हुआ है। डेस्कटॉप लेआउट वैसा ही रखें; 640px से कम स्क्रीन पर कार्ड को एक के नीचे एक लगाएं और बटन पूरी चौड़ाई के रखें।

इसकी तुलना "प्राइसिंग पेज मोबाइल पर खराब लगता है" से करें। पहला एक बार में किया और जाँचा जा सकता है; दूसरा ऐसे रीडिज़ाइन को न्योता देता है जो आपने माँगा ही नहीं था।

स्क्रीनशॉट मदद करते हैं। अगर आपका बिल्डर इमेज स्वीकार करता है, तो एक जोड़ें और समस्या पर गोला बनाएं।

चरण 3: बड़े बदलावों से पहले योजना बनाएं

किसी भी ऐसे बदलाव के लिए जो ऐप के कई हिस्सों को छूता है — नया डेटा मॉडल, पेमेंट, यूज़र रोल — कोड बदलने से पहले योजना माँगें:

अभी कोड न बदलें। मैं चाहता हूँ कि यूज़र टीमों से जुड़े हों और केवल अपनी टीम के प्रोजेक्ट देखें। बदलाव की योजना बताएं: कौन-सी टेबल, पेज और API रूट बदलेंगे, मौजूदा यूज़र के डेटा का क्या होगा, और किस क्रम में बनाएंगे।

योजना पढ़ें। अगर वह गलत है, तो योजना सुधारना बनाए गए बदलाव को वापस करने से कहीं सस्ता है।

चरण 4: बताएं कि क्या नहीं बदलना चाहिए

AI उन चीज़ों को भी "ठीक" करने लगते हैं जो आपने माँगी ही नहीं थीं। जो काम कर रहा है उसकी रक्षा करें:

ऑर्डर टेबल में एक तारीख फ़िल्टर जोड़ें। टेबल के कॉलम, स्टाइल या एक्सपोर्ट बटन को न बदलें।

जो नियम हर जगह लागू होते हैं — ब्रांड के रंग, बोलने का लहजा, "बिना पुष्टि के कभी डेटा न हटाएं" — उन्हें प्रोजेक्ट नोट्स या knowledge सेटिंग में रखें, जिसे AI हर बार पढ़ता है, बार-बार दोहराने के बजाय।

चरण 5: सिर्फ़ बदलाव नहीं, उसके आसपास भी जाँचें

हर prompt के बाद जाँचें:

• बदलाव ख़ुद। क्या वह वही करता है जो आपने माँगा, डेस्कटॉप और फ़ोन दोनों पर?
• उसके पड़ोसी। उसी पेज की चीज़ें, और वे फ़्लो जो उसी डेटा का इस्तेमाल करते हैं।
• मुख्य रास्ता। साइन अप, लॉग इन, मुख्य कार्य, पेमेंट। हर बड़े बदलाव के बाद तीस सेकंड की जाँच ज़्यादातर टूटन को जल्दी पकड़ लेती है।

अगर कुछ ठीक नहीं लगता, तो उसे सटीक तरीके से रिपोर्ट करें — देखें अच्छी बग रिपोर्ट कैसे लिखें।

चरण 6: ढेर लगाने के बजाय रोलबैक करें

जब कोई बदलाव कुछ तोड़ दे और पहला सुधार काम न करे, तो रुक जाएं। हर अतिरिक्त "सुधार" एक टूटी हुई स्थिति पर बनता है, और समस्याएं बढ़ती जाती हैं।

इसके बजाय:

1. आखिरी ठीक वर्शन पर लौटें (चेकपॉइंट या Git commit)।
2. पता करें कि prompt में क्या अस्पष्ट था।
3. छोटे या साफ़ अनुरोध के साथ दोबारा कोशिश करें।

वह बदलाव ड्राफ़्ट सेव होने को तोड़ रहा था। मैंने रोलबैक कर दिया है। इस बार: सिर्फ़ हेडर में टेक्स्ट के रूप में ऑटोसेव इंडिकेटर जोड़ें। ड्राफ़्ट सेव होने का तरीका न बदलें।

चरण 7: जानें कि दोबारा बनाना कब सही है

शुरू से दोबारा बनाने में बहुत-सा काम किया हुआ विवरण फेंक दिया जाता है। यह तभी उचित है जब:

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

दोबारा बनाते समय सूची बनाएं कि क्या रखना है: नाम, रंग, कॉपी, वे हिस्से जो यूज़र को पसंद थे।

उदाहरण prompts

आगे बढ़ने से पहले बताएं कि ऐप अभी कैसे काम करता है: पेज, वह डेटा जो वह स्टोर करता है, और जो आपको नाज़ुक लगता है।

मैं आवर्ती बुकिंग जोड़ना चाहता हूँ। सबसे छोटा संस्करण क्या होगा जो उपयोगी हो? इसे तीन अलग बदलावों के रूप में सुझाएं, जिन्हें हम एक-एक करके कर सकें।

पिछले तीन बदलावों की समीक्षा करें और देखें कि किसी ने चेकआउट फ़्लो तो नहीं तोड़ा। अभी संपादन न करें।

आम गलतियाँ

• एक prompt में दस अनुरोध। कुछ पूरे होते हैं, कुछ आधे, और आप बता नहीं पाते कि कौन-सा।
• अस्पष्ट फ़ीडबैक। "यह टूटा है" या "इसे बेहतर बनाओ" अनुमान लगवाता है।
• आसपास की जाँच न करना। एक साझा कंपोनेंट में बदलाव तीन और पेज तोड़ देता है।
• सुधारों पर सुधार। किसी बग में चार prompts गहरे जा चुके हों, तो रोलबैक करें।
• हर बार संदर्भ दोहराना बजाय इसके कि स्थायी नियम प्रोजेक्ट नोट्स में रहें।
• अटकने पर दोबारा बनाना। "शुरू से करते हैं" वाले ज़्यादातर पल असल में "दो कदम पीछे लौटें" होते हैं।

चेकलिस्ट

• हर prompt में एक लक्ष्य।
• मैं बताता हूँ कि क्या दिख रहा है और क्या होना चाहिए।
• बड़े बदलावों को कोड से पहले योजना मिलती है।
• मैं बताता हूँ कि क्या नहीं बदलना चाहिए।
• हर बदलाव के बाद मैं उसे, उसके पड़ोसियों को और मुख्य रास्ते को जाँचता हूँ।
• जो बदलाव काम करता है, उसके बाद चेकपॉइंट या commit सेव करता हूँ।
• जब कोई सुधार विफल हो, तो मैं सुधारों पर सुधार चढ़ाने के बजाय रोलबैक करता हूँ।
• स्थायी नियम प्रोजेक्ट नोट्स में रहते हैं, जिन्हें AI हर बार पढ़ता है।

Mythex पर सुधार

Mythex इसी लूप के आसपास बना है:

• Plan, Build और Ask मोड। Plan संपादन से पहले तरीके पर चर्चा करता है; Ask कोड बदले बिना जवाब देता है; Build बदलाव करता है। देखें Chat।
• चेकपॉइंट। हर सफल टर्न के बाद Mythex एक git चेकपॉइंट सेव करता है; Revert to this point उस पर लौटा देता है। आप किसी पुराने संदेश को संपादित करके Discard & resend से उसी बिंदु से अलग prompt आज़मा सकते हैं। देखें बिना दोबारा बनाए सुधारें।
• Knowledge। प्रोजेक्ट सेटिंग्स → Knowledge में वे स्थायी नोट्स रहते हैं जिन्हें एजेंट हर मैसेज पर मानता है।
• /test बड़े बदलाव के बाद एजेंट से प्रीव्यू में यूज़र की तरह क्लिक करवाता है।

छोटे अनुरोधों में क्रेडिट भी कम लगते हैं। prompts लिखने के बारे में AI ऐप बिल्डर के लिए prompts कैसे लिखें देखें; जब कुछ टूट जाए, तो AI से बने ऐप को डीबग कैसे करें पढ़ें।

सवाल