AI से बनी ऐप को कैसे डीबग करें: एक व्यावहारिक तरीका
AI से बनी ऐप को डीबग करने के लिए, पहले बग को जानबूझकर दोबारा पैदा करें, फिर सबूत इकट्ठा करें — ठीक कदम, एरर संदेश, और ब्राउज़र कंसोल व नेटवर्क टैब में क्या दिखता है — और उसे AI को “मैंने X किया, Y की उम्मीद थी, Z मिला” के रूप में दें। अगर कोई फ़िक्स चीज़ें और बिगाड़ दे, तो फ़िक्स पर फ़िक्स चढ़ाने के बजाय आखिरी काम करने वाले संस्करण पर लौट जाएं। इनमें से कोई भी काम अच्छे से करने के लिए आपको कोड पढ़ने की ज़रूरत नहीं है।
यह गाइड पूरे लूप को कवर करती है, जिसमें गैर-डेवलपर्स के लिए ब्राउज़र डेवलपर टूल्स का एक त्वरित परिचय भी है।
डीबगिंग का लूप
हर बग फ़िक्स, चाहे उसे कोई व्यक्ति करे या AI, इसी लूप का पालन करता है:
- दोबारा पैदा करें — बग को भरोसेमंद तरीके से होने दें।
- देखें — एरर संदेश और ऐप क्या कर रही थी, यह इकट्ठा करें।
- समझाएं — AI को सटीक कदम, अपेक्षित परिणाम और असली परिणाम दें।
- ठीक करें — AI को एक चीज़ बदलने दें।
- सत्यापित करें — वही सटीक कदम दोहराएं और पुष्टि करें कि बग ठीक हुआ, और आसपास कुछ नहीं टूटा।
- ज़रूरत हो तो रोलबैक करें — अगर स्थिति बिगड़ी, तो वापस लें और बेहतर जानकारी के साथ फिर कोशिश करें।
AI से बनी ऐप पर ज़्यादातर समय इसलिए बर्बाद होता है क्योंकि लोग चरण 1, 2 और 5 छोड़ देते हैं: “यह टूटा है” कह देना, बिना टेस्ट किए बदलाव स्वीकार कर लेना, और फिर एक टूटे हुए पर दूसरा फ़िक्स मांगना।
चरण 1: बग को दोबारा पैदा करें
ऐसा बग जिसे आप मांगने पर ट्रिगर कर सकें, वह आधा ठीक हो चुका है। वह सबसे छोटा कदमों का सेट ढूंढें जो उसे पैदा करता है।
खुद से पूछें:
- क्या यह हर बार होता है? अगर कभी-कभी होता है, तो जब होता है तो क्या अलग होता है — कोई खास रिकॉर्ड, धीमा कनेक्शन, लॉग आउट होना?
- क्या यह हर उपयोगकर्ता के साथ होता है? किसी अलग अकाउंट से लॉग इन करें। कई बग सिर्फ नए उपयोगकर्ताओं के लिए दिखते हैं जिनके पास कोई डेटा नहीं है, या किसी अलग भूमिका वाले उपयोगकर्ता के लिए।
- क्या यह हर डिवाइस पर होता है? फ़ोन-चौड़ाई वाली स्क्रीन और एक अलग ब्राउज़र आज़माएं।
- क्या यह किसी खास बदलाव के बाद शुरू हुआ? अगर कल तक काम कर रहा था, तो पिछले कुछ बदलाव मुख्य संदिग्ध हैं।
कदम एक छोटी क्रमांकित सूची में लिखें। बाद में आप उसे प्रॉम्प्ट में चिपकाएंगे।
चरण 2: एरर संदेश पढ़ें
एरर संदेश डरावने लगते हैं, लेकिन आपको उनके सिर्फ कुछ हिस्सों की ज़रूरत है।
| संदेश का हिस्सा | यह क्या बताता है | उदाहरण |
|---|---|---|
| प्रकार | समस्या का तरीका | TypeError, 404 Not Found, 500 Internal Server Error |
| संदेश | ठीक वह चीज़ जो विफल हुई | Cannot read properties of undefined (reading 'name') |
| फ़ाइल और लाइन | कोड में कहां | BookingList.tsx:42 |
आपको इसे समझने की ज़रूरत नहीं; आपको इसे ठीक-ठीक कॉपी करना है। “Cannot read properties of undefined (reading 'name')” AI को बताता है कि कोड को कुछ डेटा (शायद कोई बुकिंग या उपयोगकर्ता) की उम्मीद थी जो वहां नहीं था। “कोई undefined एरर” जैसा पैराफ़्रेज़ वह जानकारी खो देता है।
कुछ आम, मोटे तौर पर अनुवादित:
undefined/nullएरर — कोड को डेटा की उम्मीद थी जो आया नहीं। अक्सर लोडिंग स्थिति या खाली सूची, जिसे कोड ने नहीं संभाला।404 Not Found— पेज या API पता मौजूद नहीं है। अक्सर किसी रूट में टाइपो, या ऐसे पेज का लिंक जिसका नाम बदला गया।401 Unauthorized/403 Forbidden— अनुरोध लॉग इन नहीं था, या उपयोगकर्ता को वह करने की अनुमति नहीं है।500 Internal Server Error— सर्वर-साइड कोड क्रैश हुआ। असली कारण सर्वर लॉग में है, ब्राउज़र में नहीं।CORSएरर — ब्राउज़र ने किसी दूसरे डोमेन पर अनुरोध को रोका। आमतौर पर सर्वर-साइड की कॉन्फ़िगरेशन समस्या।
चरण 3: ब्राउज़र डेवलपर टूल्स इस्तेमाल करें
हर डेस्कटॉप ब्राउज़र में बिल्ट-इन डेवलपर टूल्स (“devtools”) होते हैं। वे दिखाते हैं कि पेज पर्दे के पीछे क्या कर रहा है। Chrome, Edge और Firefox में, पेज पर कहीं भी राइट-क्लिक करें और Inspect चुनें, या F12 दबाएं (Mac पर Cmd+Option+I)। Safari में, पहले Safari की सेटिंग्स में Develop मेन्यू चालू करें।
आपको सिर्फ तीन टैब चाहिए।
Console
Console टैब पेज के कोड से एरर और संदेश दिखाता है। एरर लाल में दिखते हैं। अगर बटन दबाने पर कुछ नहीं होता, तो कंसोल अक्सर उसी पल एक लाल एरर दिखाएगा जब आप क्लिक करते हैं। एरर का पूरा टेक्स्ट कॉपी करें (ज़्यादातर ब्राउज़रों में उस पर राइट-क्लिक करके कॉपी का विकल्प मिलता है)।
Network
Network टैब हर अनुरोध दिखाता है जो पेज करता है — डेटा लोड करना, फ़ॉर्म सहेजना, लॉग इन करना। उसे खोलें, फिर वे कदम दोहराएं जो बग पैदा करते हैं।
- लाल पंक्तियां या 400 या उससे ऊपर का स्टेटस देखें।
- विफल पंक्ति पर क्लिक करके उसका Response देखें। सर्वर एरर में अक्सर वहां एक संदेश होता है जो स्क्रीन पर किसी भी चीज़ से ज़्यादा उपयोगी होता है।
- अनुरोध का URL और स्टेटस कोड नोट करें — “/api/bookings पर POST 500 लौटा” AI को देने के लिए एक बहुत उपयोगी वाक्य है।
अगर बग में पेज रीलोड या रीडायरेक्ट शामिल है, तो Preserve log चिह्नित करें, ताकि अनुरोध गायब न हों।
Elements
Elements (या Inspector) टैब पेज की संरचना और स्टाइल दिखाता है। लेआउट बग के लिए यह सबसे उपयोगी है: किसी तत्व पर होवर करें और उसका आकार व स्पेसिंग हाइलाइट होती है। यहां कुछ भी संपादित करने की ज़रूरत नहीं; इतना कहना काफ़ी है कि “मोबाइल पर फ़ुटर 2,000 पिक्सल चौड़ा है और पेज को बगल में धकेल रहा है”।
चरण 4: सर्वर लॉग देखें
कुछ बग सर्वर पर होते हैं, जहां ब्राउज़र उन्हें नहीं देख सकता। नेटवर्क टैब में 500 एरर इसका क्लासिक संकेत है। सर्वर लॉग — जब आपका बैकएंड चलता है तब उसका टेक्स्ट आउटपुट — में आमतौर पर स्टैक ट्रेस (उन फ़ंक्शनों की सूची जो विफल होने के समय चल रहे थे) के साथ असली एरर होता है।
वे कहां मिलते हैं, यह आपके टूल पर निर्भर करता है। ज़्यादातर AI ऐप बिल्डरों में आप प्रोजेक्ट के लिए टर्मिनल या लॉग व्यू खोल सकते हैं, या सीधे AI से पूछ सकते हैं: “पिछले अनुरोध की एरर के लिए सर्वर लॉग देखो और बताओ क्या विफल हुआ।”
चरण 5: AI को बग समझाएं
जो आपने इकट्ठा किया है उसे इस आकार में रखें:
बुकिंग पेज पर, सदस्य के रूप में लॉग इन करके: मैंने कल की 9:00 क्लास पर Cancel दबाया। अपेक्षित: बुकिंग गायब हो जाती है और क्लास में एक और खाली जगह दिखती है। असली: स्क्रीन पर कुछ नहीं बदलता। कंसोल में
BookingCard.tsx:31परTypeError: Cannot read properties of undefined (reading 'id')दिखता है, और नेटवर्क टैब मेंDELETE /api/bookings/123500 लौटा। कारण ढूंढो, ठीक करो, और जांचो कि कैंसल करना एक बुकिंग वाले और कई बुकिंग वाले सदस्य दोनों के लिए काम करता है।
हर हिस्सा क्यों मायने रखता है:
- कहां और किस रूप में बात को एक स्क्रीन और एक भूमिका तक सीमित करती है।
- सटीक कदम AI को बग दोबारा पैदा करने देते हैं।
- अपेक्षित बनाम असली तय करता है कि “ठीक” का मतलब क्या है।
- एरर टेक्स्ट और विफल अनुरोध सीधे कारण की ओर इशारा करते हैं।
- “जांचो कि…” AI से सिर्फ बदलाव नहीं, सत्यापन भी मांगता है।
अगर AI दो बार फ़िक्स करने की कोशिश कर चुका है और विफल रहा है, तो कुछ भी बदलने से पहले उसे समझाने को कहें:
अभी कोड मत बदलो। तुम्हें लगता है यह किस वजह से है, और उसके पक्ष में क्या सबूत है?
गलत सिद्धांत लिखे जाने पर आसानी से पकड़ में आ जाता है, और उसे सुधारना गलत फ़िक्स से कहीं सस्ता है।
चरण 6: सत्यापित करें, फिर आसपास जांचें
जब AI कहे कि यह ठीक हो गया, तो चरण 1 के सटीक कदम दोहराएं। फिर उसके आसपास की चीज़ें जांचें:
- एक अलग उपयोगकर्ता भूमिका के लिए वही क्रिया
- बिना डेटा के वही क्रिया, और बहुत सारे डेटा के साथ
- वे पेज जो उस कंपोनेंट को साझा करते हैं जिसे आपने ठीक किया
- फ़ोन-चौड़ाई वाली स्क्रीन, अगर फ़िक्स ने लेआउट छुआ हो
AI के बदलाव कभी-कभी एक रास्ता ठीक करते हैं और चुपचाप दूसरा तोड़ देते हैं। अभी दो मिनट की जांच बाद में एक उलझन भरे घंटे को बचाती है।
चरण 7: ढेर लगाने के बजाय रोलबैक करें
अगर कोई फ़िक्स स्थिति बिगाड़ दे, या आप तीन दौर से बिना प्रगति के हों, तो वापस जाएं। आखिरी काम करने वाले संस्करण पर रोलबैक करना और बेहतर सबूत के साथ दोबारा समझाना, तीन गलत फ़िक्सों पर चौथा फ़िक्स मांगने से लगभग हमेशा बेहतर है। हर विफल प्रयास कोड पीछे छोड़ जाता है, और वह कोड अगले प्रयास को उलझा देता है।
अच्छी आदतें जो रोलबैक को आसान बनाती हैं:
- हर बदलाव के बाद टेस्ट करें, ताकि पता रहे कि कौन सा बदलाव चीज़ें तोड़ रहा है।
- बदलाव छोटे रखें — हर संदेश में एक फ़ीचर या एक फ़िक्स।
- कुछ जोखिम भरा शुरू करने से पहले आखिरी अच्छा संस्करण नोट करें।
- अगर कोड Git में है, तो काम करने वाले संस्करण कमिट करें ताकि उन पर लौटा जा सके।
AI से बनी ऐप में आम बग पैटर्न
| लक्षण | संभावित कारण | क्या मांगें |
|---|---|---|
| प्रीव्यू में काम करता है, प्रकाशित होने पर टूटता है | लाइव ऐप पर सीक्रेट या एनवायरनमेंट वेरिएबल नहीं है, या बदलाव दोबारा प्रकाशित नहीं हुआ | “जांचो कि ऐप के इस्तेमाल किए गए हर एनवायरनमेंट वेरिएबल प्रकाशित ऐप के लिए सेट हैं” |
| रीफ़्रेश के बाद डेटा गायब हो जाता है | सिर्फ पेज की मेमोरी में सहेजा गया, डेटाबेस में नहीं | “[डेटा] को डेटाबेस में सहेजो ताकि रीफ़्रेश के बाद भी बना रहे” |
| पेज खाली है | रेंडर के दौरान क्रैश | कंसोल एरर कॉपी करें |
| आपके लिए काम करता है, नए उपयोगकर्ताओं के लिए नहीं | कोड ऐसे डेटा की उम्मीद करता है जो नए अकाउंट में नहीं होता | “संभालो कि उपयोगकर्ता के पास अभी कोई [रिकॉर्ड] नहीं है” |
| उपयोगकर्ता एक-दूसरे का डेटा देख सकते हैं | सर्वर पर अनुमति जांच नहीं है | हमारी सिक्योरिटी चेकलिस्ट देखें |
| फ़ोन पर लेआउट टूटा | निश्चित चौड़ाइयां या ऐसी सामग्री जो रैप नहीं होती | स्क्रीनशॉट और स्क्रीन की चौड़ाई |
| लॉगिन काम करता है, फिर रीलोड पर लॉग आउट हो जाता है | सेशन स्टोर नहीं हो रहा या कुकी सेटिंग्स गलत हैं | “पेज रीफ़्रेश के बाद भी उपयोगकर्ताओं को लॉग इन रखो” |
जब समस्या बग न हो
कुछ “बग” असल में AI का वही बनाना है जो उसे बताया गया था, और विवरण अस्पष्ट था। अगर जो फ़िक्स आप मांग रहे हैं वह असल में व्यवहार में बदलाव है, तो साफ़ कहें: “इसे ऐसा बदलो कि…”। अगर आप खुद अनिश्चित हैं कि सही व्यवहार है क्या, तो पहले वह तय करें। AI ऐप बिल्डरों के लिए प्रॉम्प्ट लिखने पर हमारी गाइड, नियमों को साफ़ बताने का तरीका कवर करती है। और अगर आप किसी ऐप को असली उपयोगकर्ताओं के लिए तैयार कर रहे हैं, तो AI प्रोटोटाइप को प्रोडक्शन तक कैसे ले जाएं लॉन्च से पहले की जांचें बताती है।
Mythex में डीबगिंग
Mythex में लूप के हर चरण के लिए टूल हैं:
- Preview बग दोबारा पैदा करने के लिए, फ़ोन-आकार के फ़्रेम सहित।
/testएजेंट को आपके लाइव प्रीव्यू में एक उपयोगकर्ता की तरह क्लिक करवाता है और टूटे फ़्लो की रिपोर्ट करता है।/fixएजेंट को खास तौर पर टूटी चीज़ों की ओर ले जाता है।- Plan मोड में एजेंट कुछ भी संपादित करने से पहले जांच करके समझा सकता है।
- Code → terminal आपकी ऐप के सर्वर लॉग दिखाता है।
- किसी भी जवाब पर Revert to this point प्रोजेक्ट को उस चेकपॉइंट पर वापस ले जाता है।
अगर प्रकाशन विफल होता है, तो प्रकाशन डायलॉग आमतौर पर Fix with AI विकल्प देता है, जो बिल्ड आउटपुट या ऐप के लॉग पढ़ता है। डॉक्स में Debug your app और Publish troubleshooting देखें।
सवाल
जब मेरी ऐप में बग हो, तो AI को क्या बताना चाहिए?
तीन बातें: आपने ठीक-ठीक कौन से कदम उठाए, आपको क्या होने की उम्मीद थी, और असल में क्या हुआ, जिसमें किसी भी एरर संदेश का ठीक-ठीक टेक्स्ट शामिल हो। AI को कारण ढूंढने के लिए आमतौर पर इतना काफ़ी होता है।
ब्राउज़र कंसोल कैसे खोलूं?
Chrome, Edge या Firefox में पेज पर राइट-क्लिक करें और Inspect चुनें, फिर Console टैब खोलें। कीबोर्ड शॉर्टकट F12 है, या Mac पर Cmd+Option+I। Safari में पहले Settings में Develop मेन्यू चालू करना होगा।
AI बार-बार एक ही बग ठीक करने में विफल हो रहा है। मुझे क्या करना चाहिए?
फ़िक्स पर फ़िक्स लगाना बंद करें। आखिरी काम करने वाले संस्करण पर रोलबैक करें, फिर बग को ज़्यादा विवरण के साथ दोबारा समझाएं — ठीक एरर, विफल नेटवर्क अनुरोध, या स्क्रीनशॉट। कोड बदलने से पहले AI से कारण समझाने को कहना भी मदद करता है।
ऐप प्रीव्यू में चलती है, लेकिन प्रकाशित करने के बाद क्यों नहीं चलती?
आम कारण हैं: लाइव ऐप के लिए कभी सेट न किए गए सीक्रेट या एनवायरनमेंट वेरिएबल, लाइव वर्शन से जुड़ा न हुआ डेटाबेस, या ऐसे बदलाव जो दोबारा प्रकाशित नहीं हुए। कोड देखने से पहले इन्हें जांचें।