आपका पहला अच्छा प्रॉम्प्ट

प्रॉम्प्ट किसी उत्पाद-निर्णय की जगह नहीं लेता: वह उसे दिखाई देने लायक़ बनाता है ताकि कोई दूसरा व्यक्ति या कृत्रिम बुद्धिमत्ता (AI) उस पर काम कर सके। OpenAI और Google दोनों की सुझाई गई विधि साफ़ निर्देश, प्रासंगिक संदर्भ, ढाँचा देने वाले उदाहरण और समीक्षा के चक्कर से शुरू होती है। यहाँ आप यही विधि एक कार्य-निर्माण फ़ॉर्म पर लागू करेंगे।

उदाहरण जानबूझकर छोटा है। फ़ॉर्म को शीर्षक, ज़िम्मेदार व्यक्ति, समय-सीमा और प्राथमिकता चाहिए; उसे अधूरा डेटा अस्वीकार करना है और सहेजने की पुष्टि देनी है। यह दायरा देखने देता है कि हर निर्देश किसी ठोस व्यवहार को बदलता है या नहीं।

विचार को जाँचने योग्य काम में बदलें

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

माँग को एक क्रिया और एक दिखने वाले नतीजे के साथ लिखें। जैसे: «शीर्षक, ज़िम्मेदार व्यक्ति, समय-सीमा और प्राथमिकता वाला कार्य दर्ज करने का फ़ॉर्म बनाओ; भेजने पर कार्य को सूची में जोड़ो»। इस वाक्य को अभी संदर्भ और जाँच चाहिए, पर यह AI को अपने आप डैशबोर्ड, कैलेंडर या अनुमति-प्रणाली गढ़ने से रोक देता है।

अगर आप इस माँग के चारों ओर का पूरा चक्र समझना चाहते हैं, तो देखें वाइब कोडिंग क्या है। प्रॉम्प्ट एक चक्कर शुरू करता है; समीक्षा, जाँच और बदलाव स्वीकार करने का फ़ैसला आपका ही रहता है।

केवल वही संदर्भ दें जो समाधान बदलता है

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

इस कार्य-फ़ॉर्म के लिए संदर्भ कह सकता है कि ऐप में पहले से एक सूची और एक बटन घटक है, टेक्स्ट हिंदी में हैं और स्थिति मेमोरी में रहती है। परियोजना का पूरा इतिहास बताने की ज़रूरत नहीं। वही जानकारी दें जो लागू करने का तरीक़ा या जाँचने का तरीक़ा बदल दे।

जब आप स्टैक नहीं जानते, तो सीधे यह कह दें। पहले एक छोटा प्रस्ताव और उसके परिणाम माँगें, और बदलाव की अनुमति देने से पहले उसे मंज़ूर करें। यह ठहराव किसी आकस्मिक तकनीकी चुनाव को मुश्किल से हटने वाली निर्भरता बनने से रोकता है।

कोड माँगने से पहले नतीजा बताएँ

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

जब नतीजे का रूप मायने रखता हो, तब एक ठोस उदाहरण मदद करता है। एक सही कार्य लिखें, जैसे «डेमो तैयार करना, ज़िम्मेदार Ana, समय-सीमा 20 जुलाई, प्राथमिकता उच्च», और एक ग़लत इनपुट जिसमें शीर्षक ख़ाली हो। इससे मॉडल के पास सही स्थिति का एक ढाँचा और त्रुटि का दूसरा ढाँचा होता है।

उदाहरण को नियम की जगह इस्तेमाल न करें। अगर आप केवल एक सही तारीख़ दिखाएँगे, तो AI मिलती-जुलती कोई भी पंक्ति स्वीकार कर सकता है। यह भी बताएँ कि तारीख़ वास्तविक होनी चाहिए और आज से पहले की नहीं।

दिखने वाले स्वीकृति मानक तय करें

स्वीकृति मानक «तैयार लगता है» को एक दोहराने योग्य समीक्षा में बदल देते हैं। इस फ़ॉर्म के लिए हर मानक इंटरफ़ेस में या किसी जाँच से परखा जा सकना चाहिए। «सहज हो» जैसे वाक्य टालें, क्योंकि वे नहीं बताते कि कौन-सा व्यवहार बदलना है।

आप नीचे दिए नतीजे तय कर सकते हैं। हर एक एक दिखने वाली जाँच से मेल खाता है:

1. शीर्षक, ज़िम्मेदार व्यक्ति और तारीख़ अनिवार्य हैं।
2. बीती हुई तारीख़ पर फ़ील्ड के पास संदेश दिखता है और कार्य नहीं सहेजा जाता।
3. सही सबमिशन से केवल एक कार्य, अपने सभी मानों के साथ, जुड़ता है।
4. फ़ॉर्म तभी ख़ाली होता है जब सहेजना सफल रहा हो।
5. कीबोर्ड से नेविगेशन फ़ील्ड, विकल्प और बटन तक तार्किक क्रम में पहुँचता है।

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

ठोस फ़ीडबैक से नतीजा सुधारें

साफ़ प्रॉम्प्ट के बावजूद पहला संस्करण विफल हो सकता है। समस्या दोहराएँ और तीन बातों के साथ जवाब दें: आपने क्या किया, क्या हुआ और आप क्या चाहते थे। फ़ॉर्म के लिए: «मैंने तारीख़ में कल चुना, सबमिशन स्वीकार हो गया, जबकि मुझे फ़ील्ड के पास त्रुटि की उम्मीद थी»।

एक ऐसी जाँच जोड़ें जो दोबारा वही ख़ामी न आने दे। बीती और आने वाली—दोनों तारीख़ें कवर करने, मौजूदा जाँचें चलाने और नतीजा दिखाने को कहें। यह तरीक़ा फ़ीडबैक को प्रमाण में बदलता है और ऐसे दिखावटी सुधार से बचाता है जो तर्क को वैसा ही छोड़ दे।

असंबंधित सुधारों को एक साथ न मिलाएँ। अगर आप रंग भी बदलना चाहते हैं और लेबल भी जोड़ना, तो वे अलग चक्करों के लिए रखें। तब आप हर नतीजे को किसी निर्देश से जोड़ सकेंगे और केवल ज़रूरी हिस्सा वापस ले सकेंगे।

प्रॉम्प्ट की सीमाएँ पहचानें

विस्तृत प्रॉम्प्ट भी सही समाधान की गारंटी नहीं देता। मॉडल कोई समय-क्षेत्र मान सकता है, रिपॉज़िटरी की कोई परंपरा अनदेखी कर सकता है, कोई API गढ़ सकता है, या ऐसी जाँच लिख सकता है जो केवल अपने ही कोड की पुष्टि करे। कोड पढ़ें और असली प्रवाह चलाएँ।

संवेदनशील डेटा को और सावधानी चाहिए। «संदर्भ देने» के लिए क्रेडेंशियल, निजी डेटा या गोपनीय सामग्री न चिपकाएँ। अगर काम को बाहरी पहुँच या न पलटने वाली कार्रवाइयाँ चाहिए, तो न्यूनतम अनुमतियाँ और मानवीय स्वीकृति तय करें; AI एजेंट गाइड यही अनुबंध समझाती है।

काम छोटे टुकड़ों में बाँटने और ठोस फ़ीडबैक देने का सुझाव एक व्यावहारिक नियम है, सार्वभौमिक क़ानून नहीं। एक समन्वित माइग्रेशन को बड़ी योजना चाहिए, जबकि एक स्थानीय सुधार छोटी माँग में समा जाता है। गहराई को जोखिम के अनुसार रखें और नतीजा जाँचने का एक स्वतंत्र रास्ता हमेशा बनाए रखें।

भेजने से पहले प्रॉम्प्ट दोबारा देखें

इस सूची को काम का प्रवेश-द्वार मानें। हर बिंदु आपकी माँग के किसी वाक्य या दिखने वाले मानक से मेल खाना चाहिए।

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

अगर कोई बिंदु पूरा न हो, तो दायरा बढ़ाने से पहले प्रॉम्प्ट सुधारें। इस कार्य-फ़ॉर्म में अंतिम लक्ष्य बहुत सारा कोड पाना नहीं है: लक्ष्य है एक सही कार्य बना पाना, एक ग़लत कार्य अस्वीकार कर पाना और दोनों व्यवहार दिखा पाना।