AI ऐप बिल्डर के लिए प्रॉम्प्ट कैसे लिखें (पहले/बाद के उदाहरणों के साथ)
दो लोगों को एक घंटे तक एक ही AI ऐप बिल्डर इस्तेमाल करते देखिए। एक के पास चलता हुआ ऐप है; दूसरे के पास एक गड़बड़झाला और यह राय कि "AI कोडिंग ओवरहाइप्ड है।" टूल एक ही था। प्रॉम्प्ट नहीं।
ऐप बिल्डर को प्रॉम्प्ट करना चैटबॉट को प्रॉम्प्ट करने से अलग हुनर है। आप सवाल नहीं पूछ रहे — आप एक ऐसे एजेंट को वर्क ऑर्डर दे रहे हैं जो आपके कहे और अनकहे, दोनों के आधार पर दर्जनों फैसले लेगा। यहां वह है जो सच में काम करता है, हर जगह पहले/बाद के उदाहरणों के साथ।
पहला प्रॉम्प्ट: फैसले आगे रखिए, इम्प्लीमेंटेशन छोड़िए
आपका शुरुआती प्रॉम्प्ट प्रोजेक्ट की नींव रखता है। आप जो भी खाली जगह छोड़ते हैं, एजेंट उसे अंदाज़े से भरता है, और अच्छे एजेंट समझदारी से अंदाज़ा लगाते हैं, फिर भी हर अंदाज़ा आपके इरादे से मेल खाने का सिक्का-उछाल है।
पहले:
मेरे लिए एक फ़िटनेस ऐप बनाओ।
बाद में:
वेटलिफ़्टर्स के लिए एक वर्कआउट ट्रैकर बनाओ। डेटा: वर्कआउट की एक तारीख होती है; हर वर्कआउट में एक्सरसाइज़ के नाम, सेट, रेप और वज़न वाली एंट्रीज़ होती हैं। स्क्रीनें: (1) क्विक एंट्री वाला आज का लॉग, (2) हफ़्ते के हिसाब से ग्रुप की हुई हिस्ट्री, (3) हर एक्सरसाइज़ का प्रोग्रेस चार्ट। एक यूज़र, लॉगिन की ज़रूरत नहीं। डार्क, मिनिमल डिज़ाइन।
"बाद" वाला वर्ज़न ऑडियंस, डेटा मॉडल, स्क्रीनें, ऑथ का दायरा और विज़ुअल दिशा तय कर देता है — वे पांच फैसले जिन्हें बाद में बदलना महंगा पड़ता है। ध्यान दीजिए इसमें क्या नहीं है: कोई टेक स्टैक नहीं, कोई डेटाबेस का चुनाव नहीं, कोई कंपोनेंट लाइब्रेरी नहीं। एक अच्छा प्लेटफ़ॉर्म ये फैसले प्रॉम्प्ट से बेहतर लेता है, और अधकचरे टेक्निकल शब्दों से ब्रीफ़ को भर देना सीधा नुकसान करता है ("MongoDB इस्तेमाल करो" — जब प्लेटफ़ॉर्म Postgres के इर्द-गिर्द बना है — सिर्फ रगड़ पैदा करता है)।
एक ढांचा जो लगातार काम करता है:
- यह क्या है, एक वाक्य में, ऑडियंस के साथ।
- डेटा, सादी संज्ञाओं और फ़ील्ड के रूप में।
- स्क्रीनें, नंबर देकर।
- साफ़ बहिष्करण — "लॉगिन नहीं", "पेमेंट नहीं"। बहिष्करण उस स्कोप को रोकते हैं जिसे एजेंट वरना मददगार बनने के चक्कर में खुद ईजाद कर लेता।
इटरेशन प्रॉम्प्ट: एक बदलाव, एक जगह से बंधा हुआ
पहले बिल्ड के बाद आपके प्रॉम्प्ट का किरदार बदल जाता है: आर्किटेक्चर से सर्जरी। दो नियम ज़्यादातर काम कर देते हैं।
एक मैसेज में एक बदलाव। एक साथ ठूंसी गई रिक्वेस्ट इकाई के तौर पर फेल होती हैं — पांच में से एक बदलाव गलत बैठे, तो आप बाकी चार को बचाते हुए दोबारा प्रॉम्प्ट कर रहे होते हैं।
हर बदलाव को एक जगह से बांधिए।
पहले:
तारीखें गलत दिख रही हैं।
बाद में:
हिस्ट्री पेज पर हफ़्ते के हेडर "Week 32" दिखाते हैं। इसकी जगह डेट रेंज दिखाओ, जैसे "Aug 4 – Aug 10"।
स्क्रीन का नाम लीजिए, गलत टेक्स्ट को कोट कीजिए, सही टेक्स्ट बता दीजिए। एजेंट खोजबीन की बजाय ठीक उसी जगह पहुंचता है — कम गलत अंदाज़े, कम क्रेडिट।
नतीजे बताइए, इम्प्लीमेंटेशन नहीं
आपका मन करेगा डेवलपर की तरह बात करने का। अगर आप डेवलपर नहीं हैं, तो इस लालच से बचिए।
पहले:
एक useEffect जोड़ो जो माउंट पर रीफ़ेच करे और लिस्ट रेंडरिंग को memoize करो।
बाद में:
खर्च जोड़ने के बाद जब मैं डैशबोर्ड पर लौटता हूं, तो रीफ़्रेश करने तक टोटल पुराना नंबर दिखाता है। उसे मौजूदा होना चाहिए।
पहला वर्ज़न एजेंट को आपकी डायग्नोसिस से बांध देता है, जो गलत हो सकती है। दूसरा उसे असली दोष देता है — वह चीज़ जिसके बारे में आप पक्के हैं — और वजह उसे खोजने देता है। लक्षण एक यूज़र के आत्मविश्वास से बताइए; डायग्नोसिस उस चीज़ पर छोड़िए जो कोड पढ़ सकती है।
रेफ़रेंस इस्तेमाल कीजिए — वे विशेषणों को हरा देते हैं
"मॉडर्न और क्लीन" का कोई मतलब नहीं; 2010 के बाद के हर डिज़ाइन ने यही दावा किया है। रेफ़रेंस कई गुना ज़्यादा जानकारी ले जाते हैं:
प्राइसिंग सेक्शन को Linear के प्राइसिंग पेज जैसा महसूस कराओ: खूब वाइटस्पेस, पतले बॉर्डर, एक एक्सेंट रंग।
और भी बेहतर — एक स्क्रीनशॉट अटैच कीजिए: किसी पसंदीदा ऐप का, हाथ के स्केच का, या उसी टूटे हुए लेआउट का जिसकी आप बात कर रहे हैं। इमेज अटैचमेंट लेने वाले प्लेटफ़ॉर्म (Massvai लेता है) विज़ुअल अस्पष्टता को गद्य के मुकाबले तस्वीर से कहीं तेज़ सुलझाते हैं। एक-लाइन कैप्शन के साथ बग का स्क्रीनशॉट — इससे ज़्यादा कीमती प्रॉम्प्ट फ़ॉर्मैट कोई नहीं है।
जब गड़बड़ हो जाए: गड्ढा खोदना बंद कीजिए
प्रॉम्प्टिंग की सबसे महंगी गलती कोई खराब प्रॉम्प्ट नहीं है — यह है किसी बुनियादी तौर पर गलत दिशा को पैच करने की लगातार चौथी कोशिश।
एक ही फ़िक्स की दो कोशिशें नाकाम रहें, तो रणनीति बदलिए:
- रोलबैक कीजिए। गड़बड़ से पहले का चेकपॉइंट रीस्टोर कीजिए (Massvai हर जनरेशन का स्नैपशॉट रखता है) और अलग विवरण के साथ दोबारा शुरुआत कीजिए। पीछे लौटना हार जैसा लगता है; आमतौर पर यही आगे बढ़ने का सबसे तेज़ रास्ता है।
- ज़ूम आउट कीजिए। फ़िक्स को दोबारा बताने की बजाय लक्ष्य बताइए: "फ़िल्टर ड्रॉपडाउन के बारे में पिछले निर्देश भूल जाओ। मैं यूज़र्स को असल में यह करने देना चाहता हूं: …" एजेंट जमा होते पैच-निर्देशों की तुलना में ताज़ा लक्ष्यों को बेहतर संभालते हैं।
एक चीट शीट
| स्थिति | करें | न करें |
|---|---|---|
| प्रोजेक्ट शुरू करते समय | ऑडियंस + डेटा + स्क्रीनें + बहिष्करण | "मेरे लिए X का ऐप बना दो" |
| बदलाव मांगते समय | एक बदलाव, एक स्क्रीन से बंधा | एक मैसेज में पांच बदलाव |
| बग रिपोर्ट करते समय | लक्षण, जगह, अपेक्षित व्यवहार | कोड-स्तर की वजह का आपका अंदाज़ा |
| डिज़ाइन दिशा | रेफ़रेंस ऐप और स्क्रीनशॉट | विशेषणों की खिचड़ी |
| 2 कोशिशों के बाद अटकने पर | रोलबैक, लक्ष्य दोबारा बताएं | पांचवीं बार "फिर से कोशिश करो" |
इसमें कुछ भी अनोखा नहीं है। यह वही स्पष्टता है जो आप किसी इंसानी कॉन्ट्रैक्टर को देते — बस यह कॉन्ट्रैक्टर ध्यान से पढ़ता है, डिटेल से कभी नहीं चिढ़ता, और सेकंडों में काम शुरू कर देता है। उसे इस लायक ब्रीफ़ दीजिए।
