बेहतर AI प्रॉम्प्ट कैसे लिखें: वह छूटा हुआ संदर्भ जो AI सुझावों को वास्तव में उपयोगी बनाता है
दायरा, धारणाएँ, परिणाम, सीमाएँ और साक्ष्य—वे संदर्भ दें जो निर्णय बदलते हैं, ताकि बेहतर AI प्रॉम्प्ट लिख सकें।
बेहतर AI प्रॉम्प्ट ज़रूरी नहीं कि लंबे हों। उनमें वह संदर्भ होता है जिसकी सहायता से सहायक केवल संभावित बदलाव बनाने के बजाय सही निर्णय ले सके। इंजीनियरिंग कार्य में इसका मतलब आम तौर पर दायरा, धारणा, वांछित परिणाम, सीमाएँ और बदलाव के महत्व का कारण बताना होता है।
यही उस उत्तर का अंतर है जो केवल कंपाइल होता है और उस बदलाव का जो उत्पाद के लिए उपयोगी होता है।
अन्यथा सक्षम AI सुझाव क्यों विफल होते हैं
एक सहायक छोटे निर्देश से वैध कोड लिख सकता है, लेकिन छोटा निर्देश अक्सर उत्पाद संबंधी निर्णय छिपा देता है। “मोबाइल पर साइडबार हटाएँ” सहायक को बताता है कि क्या बदलना है। यह नहीं बताता कि डेस्कटॉप का व्यवहार जस का तस रहना चाहिए या नहीं, मौजूदा व्यवहार लोगों के लिए समस्या क्यों है, या सफलता को कैसे मापा जाए।
जब यह संदर्भ अनुपस्थित होता है, तो सहायक को अनुमान लगाना पड़ता है। वह तकनीकी रूप से सुघड़ बदलाव कर सकता है जो उपयोगी डेस्कटॉप वर्कफ़्लो हटा दे, असंबंधित लेआउट बदल दे, या समस्या के बजाय केवल उसके लक्षण को ठीक करे।
प्रॉम्प्ट को आदेश नहीं, एक संक्षिप्त इंजीनियरिंग ब्रीफ़ की तरह इस्तेमाल करें।
वह संदर्भ शामिल करें जो निर्णय बदलता है
इन छह जानकारी के हिस्सों से शुरू करें:
- दायरा: कौन-सी स्क्रीन, फ़ाइलें, फ़्लो या व्यवहार दायरे में हैं?
- समस्या: उत्पाद इस्तेमाल करने वाले व्यक्ति के लिए क्या कठिन, टूटा हुआ, धीमा या भ्रमित करने वाला है?
- धारणा: आपको क्या लगता है कि समस्या किस वजह से हो रही है?
- वांछित परिणाम: काम पूरा होने पर क्या सच होना चाहिए?
- सीमाएँ: क्या अपरिवर्तित रहना चाहिए और कौन-से तरीके स्वीकार्य नहीं हैं?
- साक्ष्य का अनुरोध: सहायक से धारणा पर सवाल उठाने और पहले क्या सत्यापित करेगा, यह समझाने को कहें।
एक पंक्ति के सवाल के लिए आपको हर बिंदु की ज़रूरत नहीं है। जब सहायक आपकी ओर से उत्पाद या आर्किटेक्चर का निर्णय ले सकता हो, तब इनकी ज़रूरत होती है।
उदाहरण: मोबाइल नेविगेशन ठीक करते समय डेस्कटॉप व्यवहार सुरक्षित रखें
यह एक कमज़ोर प्रॉम्प्ट है:
मोबाइल नेविगेशन को अधिक सुसंगत बनाएँ और साइडबार हटा दें।
यह कार्रवाई तो देता है, लेकिन निर्णय की सीमा नहीं। सहायक साइडबार हर जगह हटा सकता है क्योंकि उसे नहीं पता कि डेस्कटॉप उपयोगकर्ता उस पर निर्भर हैं।
यह एक बेहतर प्रॉम्प्ट है:
समस्या: डेस्कटॉप साइडबार को मोबाइल पर इस्तेमाल करना कठिन है क्योंकि वह
बहुत अधिक क्षैतिज जगह लेता है और पाठ सामग्री से प्रतिस्पर्धा करता है।
धारणा: मोबाइल-विशिष्ट नेविगेशन पैटर्न डेस्कटॉप वर्कफ़्लो बदले बिना
पाठों के बीच स्विच करना आसान बनाएगा।
परिणाम: छोटी स्क्रीन पर शिक्षार्थी संदर्भ खोए बिना पाठ बदल सकें और मौजूदा
अभ्यास पर लौट सकें। डेस्कटॉप उपयोगकर्ता मौजूदा साइडबार और कीबोर्ड वर्कफ़्लो रखें।
सीमाएँ: डेस्कटॉप साइडबार न हटाएँ। मौजूदा रूट व्यवहार, एक्सेसिबिलिटी लेबल,
और प्रगति स्थिति सुरक्षित रखें। चुने हुए पाठ के लिए दूसरा सत्य स्रोत न जोड़ें।
कार्यान्वयन से पहले मौजूदा नेविगेशन की स्वामित्व व्यवस्था जाँचें और यदि
छोटा लेआउट बदलाव समस्या हल कर सकता हो तो धारणा पर सवाल उठाएँ।
बेहतर प्रॉम्प्ट सहायक को जाँच करने की जगह देता है, लेकिन महत्वपूर्ण सीमाएँ स्पष्ट करता है: मोबाइल दायरा है, डेस्कटॉप व्यवहार सुरक्षित है, और स्थिति का एकल स्वामी अनिवार्य है।
उदाहरण: किसी कारण से विषय स्विचर को स्थानांतरित करें
स्थान बदलने के अनुरोध में भी यही समस्या हो सकती है:
विषय बटन को साइडबार में ले जाएँ और उसे वहाँ फिट करें।
यह निर्देश मौजूदा लेआउट को सजावट मानता है। यह नहीं समझाता कि विषय स्विचिंग को किसी दूसरी जगह क्यों होना चाहिए या स्थानांतरण के बाद उपयोगकर्ता उसे कैसे ढूँढेंगे।
इसके बजाय यह आज़माएँ:
समस्या: नेवबार में विषय स्विचर वैश्विक नेविगेशन से प्रतिस्पर्धा करता है,
लेकिन लोग मौजूदा कोर्स के पाठों की तुलना करते समय इसका उपयोग करते हैं।
वांछित परिणाम: विषय स्विचिंग को कोर्स नेविगेशन के पास रखें ताकि उसका
उद्देश्य स्पष्ट हो और पाठ ब्राउज़ करते समय वह आसानी से पहुँच में रहे।
सीमाएँ: वैश्विक नेवबार क्रियाएँ अपरिवर्तित रखें, नेविगेशन के दौरान चुना हुआ विषय
सुरक्षित रखें, और संकरी स्क्रीन पर विषय बदलने का साइडबार ही एकमात्र तरीका न बनाएँ।
पहले मौजूदा रूट और स्थिति मॉडल की जाँच करें। लेआउट बदलने से पहले बताएँ कि
साइडबार सही गंतव्य है या नहीं।
मूल बदलाव “अधिक विवरण” नहीं है। यह सफलता की बेहतर परिभाषा है।
सहायक से योजना पर सवाल उठाने को कहें
AI तब सबसे उपयोगी होता है जब वह पैच लिखने से पहले गलत आधार को इंगित कर सके। एक सीधा सवाल जोड़ें:
कौन-सा साक्ष्य इस धारणा को गलत साबित करेगा, और हमें पहले कौन-सा छोटा
बदलाव विचार में लेना चाहिए?
बग के लिए पुनरुत्पादन चरण और प्रतिस्पर्धी परिकल्पनाएँ माँगें। रिफ़ैक्टर के लिए पूछें कि कौन-सा व्यवहार प्रभावित हो सकता है। आर्किटेक्चर बदलाव के लिए पूछें कि कौन-सा मौजूदा स्वामी, सीमा या अनुबंध दोहराया जाएगा।
इससे काम “अभी कोड बनाएँ” से “पहले ठोस निर्णय लें, फिर लागू करें” में बदल जाता है।
दोबारा इस्तेमाल किया जा सकने वाला प्रॉम्प्ट टेम्पलेट
जब किसी कार्य को उत्पाद और तकनीकी संदर्भ चाहिए हो, तब यह टेम्पलेट इस्तेमाल करें:
कार्य: [एक वाक्य में बदलाव का वर्णन करें।]
समस्या: [कौन प्रभावित है और क्या गलत हो रहा है?]
दायरा: [दायरे में आने वाली फ़ाइलें, स्क्रीन, वर्कफ़्लो या उपप्रणाली।]
धारणा: [आपके अनुसार समस्या का कारण या सहायक समाधान।]
वांछित परिणाम: [उपयोगकर्ता और सिस्टम के लिए देखा जा सकने वाला परिणाम।]
सीमाएँ: [सुरक्षित रखने वाला व्यवहार, संगतता, प्रदर्शन, एक्सेसिबिलिटी,
सुरक्षा, रोलआउट और गैर-लक्ष्य।]
प्रासंगिक संदर्भ: [आर्किटेक्चर, डेटा फ़्लो, हालिया बदलाव, लॉग या उदाहरण।]
स्वीकृति मानदंड: [कैसे पता चलेगा कि काम पूरा है।]
सत्यापन: [चलाए जाने वाले टेस्ट, मैन्युअल जाँच या माप।]
कोड बदलने से पहले प्रासंगिक क्षेत्र जाँचें। यदि साक्ष्य अधिक सुरक्षित या छोटे
समाधान की ओर इशारा करता हो, तो धारणा पर सवाल उठाएँ।
टेम्पलेट समीक्षा को भी आसान बनाता है: टीम का सदस्य इच्छित परिणाम देख सकता है और तय कर सकता है कि प्रस्तावित कार्यान्वयन उसे पूरा करता है या नहीं।
संदर्भ दें, पूरा रिपॉज़िटरी डंप नहीं
प्रासंगिक संदर्भ चुनिंदा होता है। कोई विफल टेस्ट, त्रुटि संदेश, मौजूदा कॉम्पोनेंट सीमा, अनुरोध पेलोड या छोटा उपयोगकर्ता सफ़र शामिल करें। हज़ारों असंबंधित पंक्तियाँ चिपकाकर यह उम्मीद न करें कि सहायक महत्वपूर्ण हिस्सा ढूँढ लेगा।
केंद्रित कोडिंग वर्कफ़्लो के लिए कोडिंग के लिए ChatGPT को प्रॉम्प्ट कैसे करें देखें। कार्यान्वयन, डीबगिंग और समीक्षा कार्यों के लिए दोबारा उपयोग होने वाले पैटर्न के लिए डेवलपर्स के लिए प्रॉम्प्ट इंजीनियरिंग पढ़ें।
अपने कार्य के लिए अगली गाइड चुनें
जब रिपॉज़िटरी संदर्भ प्रॉम्प्ट बदलता हो, तब टूल-विशिष्ट गाइड का उपयोग करें: Cursor AI को प्रॉम्प्ट करना, GitHub Copilot को प्रॉम्प्ट करने की सर्वोत्तम प्रथाएँ या Claude Code से बेहतर परिणाम पाना।
जब आपको तुरंत ढालने योग्य शब्दावली चाहिए, तब कार्य-विशिष्ट गाइड का उपयोग करें: सॉफ़्टवेयर इंजीनियरों के लिए प्रॉम्प्ट इंजीनियरिंग के उदाहरण, कोड रिफ़ैक्टरिंग के प्रॉम्प्ट टेम्पलेट या प्रोडक्शन समस्याओं को डीबग करने के प्रॉम्प्ट टेम्पलेट।
जब जोखिम syntax नहीं, प्रक्रिया हो, तब निर्णय गाइड का उपयोग करें: AI कोडिंग सहायक की गलतियाँ और उनसे कैसे बचें और वरिष्ठ डेवलपर AI का अलग ढंग से उपयोग कैसे करते हैं।
प्रॉम्प्ट गुणवत्ता को इंजीनियरिंग अभ्यास बनाएँ
जो आदतें AI प्रॉम्प्ट को उपयोगी बनाती हैं, वे टिकट, पुल रिक्वेस्ट और घटना नोट्स को भी स्पष्ट बनाती हैं: समस्या समझाएँ, परिणाम परिभाषित करें, महत्वपूर्ण व्यवहार बचाए रखें और परिणाम सत्यापित करें।
जब किसी कार्य में शेल कमांड या टर्मिनल आउटपुट शामिल हो, तो सहायक से उसे बदलने को कहने से पहले व्यवहार को ठोस बनाएँ। ब्राउज़र में कमांड-लाइन वर्कफ़्लो का अभ्यास करें, ताकि आप उस इनपुट, आउटपुट और विफलता मोड को पहचान सकें जिसे कार्यान्वयन को संभालना है।
संदर्भ
ये दस्तावेज़ लिंक इस लेख में उपयोग किए गए कमांड के लिए आधिकारिक विवरण प्रदान करते हैं।