डेवलपर्स के लिए Grok

Grok एक बेहतरीन रबर डक की तरह है जो जवाब भी देता है। grok.online पर यह बिल्कुल मुफ़्त है और इसके लिए किसी अकाउंट की ज़रूरत नहीं है: Grok 4.20 तुरंत पूछे जाने वाले सवालों के लिए तेज़ है, Grok 4.3 Thinking जवाब देने से पहले सोच-विचार करता है और बग्स ठीक करने के लिए बेहतर विकल्प है, और Grok 4.7, जो सबसे नया मॉडल है, सबसे कठिन समस्याओं के लिए आपके दैनिक 30 मैसेजेस में से 10 के साथ उपलब्ध है। तीनों मॉडल स्क्रीनशॉट पढ़ सकते हैं। यहाँ इसके सात उपयोग दिए गए हैं, हर एक के साथ एक प्रॉम्प्ट है जिसे आप चैट में खोलकर अपनी ज़रूरत के अनुसार बदल सकते हैं।

समस्याएँ ढूँढें और ठीक करें

डीबगिंग का ज़्यादातर समय यह समझने में जाता है कि असल में हो क्या रहा है। ये प्रॉम्प्ट्स उस प्रक्रिया को तेज़ बनाते हैं।

स्टैक ट्रेस को समझें

अपने शब्दों में लिखने के बजाय पूरा एरर और वे लाइन्स पेस्ट करें जिनकी ओर वह इशारा करता है। कोई भी समाधान पाने से पहले आसान शब्दों में उसका कारण पूछें, ताकि आप खुद समझ सकें।

मैं [framework] के साथ [भाषा और वर्शन] का उपयोग कर रहा हूँ। यहाँ पूरा एरर और स्टैक ट्रेस है: [एरर पेस्ट करें]। यहाँ वह कोड है जिसकी ओर यह इशारा करता है: [कोड पेस्ट करें]। आसान शब्दों में समझाएँ कि क्या और क्यों गलत हुआ, सबसे संभावित कारण पहले बताएं, और फिर इसे ठीक करने वाला सबसे छोटा बदलाव दिखाएं।

इसे चैट में खोलें। Code Assistant यही काम एक ही पैनल में करता है।

किसी और के लिखे कोड का मैप समझें

बिना कमेंट्स वाली फाइल पर काम करना हर डेवलपर के सफ़र का हिस्सा है। कुछ भी बदलने से पहले, एक गाइडेड टूर मांगें जो जोखिम भरे हिस्सों की जानकारी दे।

मुझे अभी यह [भाषा] फ़ाइल मिली है और मुझे [फ़ीचर] को बदलना है। मुझे इसका एक संक्षिप्त टूर दें: यह फ़ाइल किस लिए है, मुख्य फ़ंक्शन उनके चलने के क्रम में क्या हैं, किन ग्लोबल स्टेट या साइड इफ़ेक्ट्स पर ध्यान देना चाहिए, और बदलाव करने के लिए सबसे सुरक्षित जगह कौन सी है: [कोड पेस्ट करें]

टूर प्राप्त करें, और फिर किसी भी ऐसे फ़ंक्शन के बारे में पूछें जो अभी भी अजीब लग रहा हो।

थिंकिंग मॉडल के साथ लॉजिक बग्स ढूँढें

जब कुछ भी क्रैश न हो रहा हो लेकिन आउटपुट गलत आ रहा हो, तो आपको ध्यान से कोड को ट्रेस करने की ज़रूरत होती है। Grok 4.3 Thinking जवाब देने से पहले कोड को गहराई से समझता है, जो ऑफ-बाय-वन एरर और गलत कंडीशन्स के लिए बिल्कुल सही है।

इस [भाषा] फ़ंक्शन को [अपेक्षित व्यवहार] करना चाहिए, लेकिन [इनपुट] इनपुट के लिए यह [अपेक्षित आउटपुट] के बजाय [वास्तविक आउटपुट] देता है। उस इनपुट के साथ निष्पादन को स्टेप-बाय-स्टेप ट्रेस करें, हर स्टेप पर मुख्य वेरिएबल्स के मान दिखाएं, और उस सटीक लाइन की ओर इशारा करें जहाँ गलती हो रही है: [फ़ंक्शन पेस्ट करें]

Grok 4.3 Thinking के साथ इसे ट्रेस करें।

स्क्रीनशॉट से बिगड़े हुए लेआउट को ठीक करें

पेज जैसा अभी दिख रहा है उसका एक स्क्रीनशॉट अटैच करें, संबंधित HTML और CSS पेस्ट करें, और बताएं कि इसे कैसा दिखना चाहिए।

मैंने एक पेज का स्क्रीनशॉट अटैच किया है जहाँ [समस्या का वर्णन करें, उदा. छोटी स्क्रीन पर साइडबार कंटेंट के ऊपर आ जाता है]। उस हिस्से के लिए HTML और CSS यहाँ है: [कोड पेस्ट करें]। समझाएँ कि इसका क्या कारण है और कम से कम बदलाव करते हुए मुझे सही CSS दें।

यह प्रॉम्प्ट खोलें और अपना स्क्रीनशॉट अटैच करें।

जोखिम भरे रीफ़ैक्टर की योजना बनाएं

किसी बड़े मॉड्यूल को सुलझाना ही वह जगह है जहाँ सबसे नया मॉडल अपने सीमित दैनिक मैसेजेस में सबसे ज़्यादा काम आता है। पूरा दोबारा लिखने के बजाय एक योजना मांगें।

नीचे एक [भाषा] मॉड्यूल है जिसे बदलना अब कठिन हो गया है: [कोड पेस्ट करें]। इसे अभी दोबारा न लिखें। इसकी ज़िम्मेदारियाँ, छिपी हुई डिपेंडेंसीज़ और छोटे स्टेप्स में एक रीफ़ैक्टरिंग योजना बताएं जहाँ हर स्टेप के बाद भी कोड काम करता रहे। बताएं कि पहले स्टेप से पहले मुझे कौन से टेस्ट जोड़ने चाहिए।

Grok 4.7 के साथ इसकी योजना बनाएं, और फिर एक-एक करके स्टेप्स Grok 4.20 को भेजें।

कोड के इर्द-गिर्द का ज़रूरी काम पूरा करें

डेडलाइन नज़दीक आने पर टेस्ट्स, क्वेरीज़, रिव्यू और दस्तावेज़ ही वे हिस्से होते हैं जो अक्सर छूट जाते हैं।

उन एज केसेस के लिए टेस्ट लिखें जिन्हें आपने छोड़ दिया था

पहले केसेस की लिस्ट मांगें और बाद में टेस्ट कोड। असली वैल्यू उस लिस्ट में ही है।

यहाँ एक [भाषा] फ़ंक्शन है: [फ़ंक्शन पेस्ट करें]। पहले उन एज केसेस की लिस्ट बनाएं जिनका टेस्ट करना ज़रूरी है, जैसे कि खाली इनपुट, बाउंड्रीज़ और अमान्य प्रकार, हर एक के कारण के साथ एक लाइन में। फिर [टेस्ट फ़्रेमवर्क] का उपयोग करके स्पष्ट नामों के साथ प्रति केस एक टेस्ट लिखें।

टेस्ट्स जनरेट करें, उन्हें चलाएं, और उन टेस्ट्स को रखें जो सही कारणों से फ़ेल होते हैं।

एक सख्त सीनियर डेवलपर की तरह कोड रिव्यू पाएं

Grok खुशी-खुशी एक ऐसे रिव्यूअर की भूमिका निभाएगा जिसने हर बग को दो बार देखा है। सख्त होना ठीक है, लेकिन अस्पष्ट होना नहीं, इसलिए लाइन रेफ़रेंस ज़रूर मांगें।

एक सख्त लेकिन निष्पक्ष सीनियर इंजीनियर की तरह इस diff का रिव्यू करें। बग्स, अस्पष्ट नाम, छूटी हुई एरर हैंडलिंग और ऐसी कोई भी चीज़ बताएं जो छह महीने बाद समस्या बने, हर एक के लिए लाइन रेफ़रेंस और सुझाया गया समाधान दें। समस्याओं को गंभीरता के आधार पर क्रमबद्ध करें और केवल स्टाइल से जुड़ी छोटी-मोटी बातों को छोड़ दें: [diff पेस्ट करें]

अपनी टीम के देखने से पहले रिव्यू का अनुरोध करें।

स्कीमा को SQL और README में बदलें

टेबल डेफिनिशन और अपना सवाल आसान शब्दों में दें, और क्वेरी के साथ एक संक्षिप्त विवरण मांगें।

[डेटाबेस, उदा. PostgreSQL] के लिए मेरी टेबल डेफिनिशन्स यहाँ हैं: [स्कीमा पेस्ट करें]। एक ऐसी क्वेरी लिखें जो [आपको जो चाहिए उसे आसान शब्दों में लिखें] लौटाए। प्रत्येक जॉइन और फ़िल्टर को एक लाइन में समझाएँ, और बताएं कि जब टेबल्स में लाखों पंक्तियाँ होंगी तो कौन सा इंडेक्स इसे तेज़ कर सकता है।

क्वेरी लिखें, और फिर एक README सेक्शन मांगें जो इन टेबल्स को डॉक्यूमेंट करे।

किन बातों से बचें

• सीक्रेट्स पेस्ट करना। API कीज़, पासवर्ड, टोकन और ग्राहकों का डेटा किसी भी चैट में नहीं होना चाहिए। उनकी जगह प्लेसहोल्डर्स का इस्तेमाल करें।
• लाइब्रेरी की बारीकियों पर आँख मूंदकर भरोसा करना। मॉडल्स की जानकारी एक निश्चित समय तक ही सीमित होती है और उनके पास इंटरनेट एक्सेस नहीं होता, इसलिए कोई फ़ंक्शन या विकल्प पुराना या मनगढ़ंत हो सकता है। आधिकारिक दस्तावेज़ ज़रूर देखें।
• बिना टेस्ट किए कोड इस्तेमाल करना। जो कोड पढ़ने में सही लगे, वह भी फ़ेल हो सकता है। उसे चलाएं, टेस्ट करें और रिव्यू करें।
• पूरी रिपॉजिटरी भेजना। बहुत लंबे मैसेजेस को छोटा कर दिया जाता है। सिर्फ़ वही फ़ंक्शन भेजें जो ज़रूरी है।

संबंधित पेज

• कोडिंग प्रॉम्प्ट्स में बीस और शुरुआती बिंदु।
• Grok के साथ कोडिंग के लिए हमारी गाइड और रीज़निंग मॉडल्स पर एक व्याख्या।
• अपना खुद का ऐप बना रहे हैं? Grok API के बारे में पढ़ें।