कोडिंग के लिए ChatGPT को प्रॉम्प्ट कैसे करें

कोडिंग के लिए ChatGPT को प्रॉम्प्ट करते समय केवल वह कोड न बताएँ जो आपको वापस चाहिए, बल्कि इंजीनियरिंग निर्णय भी बताएँ। उसे प्रासंगिक कोड या रिपॉज़िटरी संदर्भ, सुरक्षित रखने वाला व्यवहार, स्पष्ट परिणाम और नतीजा सत्यापित करने का तरीका दें।

छोटी यूटिलिटी के लिए “ऐसा फ़ंक्शन लिखें जो X करे” पर्याप्त हो सकता है। लेकिन जब बदलाव उपयोगकर्ता व्यवहार, साझा अनुबंध या उत्पादन प्रणाली को छूता हो, तब यह पर्याप्त नहीं है।

कोड माँगने से पहले चार बातें बताएँ:

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

अगर आप लंबे समय तक चलने वाला ChatGPT वर्कस्पेस इस्तेमाल करते हैं, तो आर्किटेक्चर नोट्स, आवश्यकताएँ और प्रासंगिक फ़ाइलें एक साथ रखें। ChatGPT Projects चैट, संदर्भ फ़ाइलों और परियोजना-विशिष्ट निर्देशों को व्यवस्थित कर सकता है; स्रोत सामग्री अपलोड करने से पहले अपनी मौजूदा योजना और वर्कस्पेस नियंत्रण जाँचें।

इससे बचें:

फ़ाइल अपलोडर कॉम्पोनेंट बनाएँ।

यह स्वामित्व, त्रुटि प्रबंधन, फ़ाइल सीमाएँ, एक्सेसिबिलिटी या आसपास के UI अनुबंध को परिभाषित नहीं करता।

इसके बजाय सीमित अनुरोध इस्तेमाल करें:

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

परिणाम: उपयोगकर्ता 5 MB से छोटी एक PNG या JPEG चुन सके, चुना हुआ
फ़ाइलनाम देख सके, सबमिट करने से पहले उसे हटा सके, और अमान्य फ़ाइलों के लिए
मौजूदा स्थानीयकृत त्रुटि संदेश पाए।

सीमाएँ: नई state library न जोड़ें, upload endpoint न बनाएँ, और मौजूदा
submit handler को फ़ॉर्म state का एकमात्र स्वामी बनाए रखें।

बदली गई फ़ाइलों का सबसे छोटा समूह लौटाएँ, हर बदलाव समझाएँ, और अमान्य प्रकार,
आकार सीमा, हटाने और सफल चयन के टेस्ट शामिल करें।

अनुरोध कॉम्पोनेंट को छोटा बनाता है क्योंकि वह अनावश्यक आर्किटेक्चर को बाहर कर देता है।

डीबगिंग के लिए पैच माँगने से पहले परिकल्पना और पुनरुत्पादन पथ माँगें:

लक्षण: API retry सफल होने के बाद भी save बटन अक्षम रहता है।

अपेक्षित व्यवहार: सफल retry के बाद बटन उपलब्ध हो जाता है।
देखा गया व्यवहार: response data दिखाई देता है, लेकिन बटन अक्षम ही रहता है।

प्रासंगिक संदर्भ: बटन isPending और form.isDirty पर निर्भर है। यह समस्या
mutation hook में retries जोड़ने के बाद शुरू हुई।

पहले सबसे संभावित state transitions और हर एक की पुष्टि के लिए आवश्यक साक्ष्य
सूचीबद्ध करें। फिर सबसे छोटा समाधान और regression test प्रस्तावित करें।

यह “अक्षम बटन ठीक करें” से अधिक सुरक्षित है क्योंकि यह ChatGPT से पुराने state बग को validation या UI rendering समस्या से अलग पहचानने को कहता है।

रिफ़ैक्टर अनुरोधों में अधिक मजबूत संरक्षण खंड चाहिए:

डुप्लिकेट plan rendering logic हटाने के लिए pricing card सूची का रिफ़ैक्टर करें।

सुरक्षित रखें: public props, analytics event names, checkout destinations, keyboard
behavior, loading states, और मौजूदा mobile layout।

दायरा: बदलाव को pricing feature और उसके सीधे संबंधित tests तक सीमित रखें।
जब तक मौजूदा primitive साझा व्यवहार व्यक्त न कर सके, design-system abstraction
न जोड़ें।

स्वीकृति मानदंड: Snapshot या interaction tests हर plan state को कवर करें, और
rendered links तथा event payloads अपरिवर्तित रहें।

संपादन से पहले डुप्लिकेशन और वे छिपे व्यवहार पहचानें जिन्हें दोनों कार्ड अभी
अलग-अलग तरह से लागू करते हैं।

“व्यवहार सुरक्षित रखें” वाक्यांश अकेले पर्याप्त नहीं है। उस व्यवहार का नाम बताएँ जो महत्वपूर्ण है।

बिना अनुबंध के “इस कॉम्पोनेंट के टेस्ट” न माँगें। परिदृश्यों के नाम बताएँ:

मौजूदा test stack का उपयोग करके password-reset form के टेस्ट लिखें।

कवर करें:
1. अमान्य email स्थानीयकृत validation message दिखाता है;
2. submit normalized email को एक बार भेजता है;
3. network error दर्ज किया गया मान बनाए रखता है और मौजूदा error state दिखाता है;
4. सफल response यह बताए कि पुष्टि हो गई है, लेकिन यह प्रकट न करे कि
   कोई account मौजूद है।

implementation details को mock न करें। accessible roles और labels को प्राथमिकता दें।

यह सहायक को बताता है कि उपयोगकर्ता को क्या कर पाना चाहिए और कौन-सा गोपनीयता व्यवहार प्रभावित नहीं हो सकता।

व्याख्या प्रॉम्प्ट में सारांश नहीं, साक्ष्य की श्रृंखला माँगनी चाहिए:

बताएँ कि इस रिपॉज़िटरी में authentication state billing screen तक कैसे पहुँचती है।

provider से route guard और checkout call तक का पथ ट्रेस करें। शामिल फ़ाइलों और
exported symbols के नाम बताएँ। पुष्टि किए गए व्यवहार को धारणाओं से अलग रखें,
और अगर कोई भाग अस्पष्ट हो तो आगे क्या जाँचेंगे, यह सूचीबद्ध करें।

यह प्रारूप किसी गायब निर्भरता या गढ़े हुए संबंध को पहचानना आसान बनाता है।

जब आप उस प्रश्न का जवाब देने वाला सबसे संकरा संदर्भ देते हैं, तब ChatGPT अधिक भरोसेमंद होता है:

• विफल टेस्ट और उसके द्वारा चलाया गया कोड;
• कॉम्पोनेंट और उसकी स्थिति का स्वामी हुक;
• संवेदनशील मान हटाकर बनाया गया अनुरोध/प्रतिक्रिया उदाहरण;
• बदलाव को सीमित करने वाले परियोजना नियम;
• ऐसी फ़ाइलों की छोटी सूची जो जानबूझकर दायरे से बाहर हैं।

ऐसे secrets, production access tokens, ग्राहक डेटा या निजी लॉग अपलोड न करें जिन्हें साझा करने की अनुमति नहीं है। उन मानों को यथार्थवादी redactions से बदलें और तर्क करने के लिए आवश्यक व्यवहार बनाए रखें।

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

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