AI ऐप बिल्डर के लिए prompt कैसे लिखें (पहले-बाद के उदाहरणों के साथ)

AI ऐप बिल्डर के लिए अच्छा prompt प्रोडक्ट का वर्णन करता है, कोड का नहीं: उसे कौन इस्तेमाल करता है, वह चरण-दर-चरण क्या करता है, वह कौन सा डेटा रखता है, और किसे क्या देखने-बदलने की इजाज़त है। पहला संस्करण बन जाने के बाद, हर संदेश में एक खास बदलाव माँगें, बताएँ कि क्या वैसा ही रहना चाहिए, और समस्याओं को “मैंने X किया, Y की उम्मीद थी, Z हुआ” के रूप में लिखें। ये तीन आदतें ज़्यादातर निराश करने वाले नतीजों को ठीक कर देती हैं।

इस गाइड के बाक़ी हिस्से में ये पैटर्न विस्तार से हैं, पहले-बाद के उदाहरणों के साथ जिन्हें आप अपने हिसाब से ढाल सकते हैं।

AI ऐप बिल्डर से बात करना चैट-AI से अलग क्यों है

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

तो prompt का लक्ष्य होशियार लगना नहीं है। लक्ष्य है कि महत्वपूर्ण फ़ैसले कम से कम संयोग पर छोड़े जाएँ। इसके लिए तकनीकी शब्दावली ज़रूरी नहीं है। ज़रूरत है उन चीज़ों के बारे में सटीक होने की जो सिर्फ़ आप जानते हैं: आपके यूज़र, आपका काम का तरीका और आपके नियम।

पहले prompt में क्या शामिल करें

कुछ लिखने से पहले ये सवाल जवाब दें। हर सवाल वह अंतर भरता है जिसे AI अन्यथा अनुमान से भरता।

आख़िरी पंक्ति को कम आँका जाता है। आप क्या नहीं चाहते, यह बताना AI को एक ब्लॉग, एक प्राइसिंग पेज और एक न्यूज़लेटर साइनअप जोड़ने से रोकता है जो आपने माँगे ही नहीं थे।

पहले prompt के पहले और बाद के उदाहरण

पहले:

मेरे जिम के लिए एक ऐप बनाओ।

बिल्डर को सब कुछ अंदाज़े से तय करना होगा: सदस्य या स्टाफ़? क्लास या पर्सनल ट्रेनिंग? पेमेंट? आपको एक ऐसी जिम वेबसाइट मिलेगी जो दिखती तो है, पर आपके काम का कुछ नहीं करती।

बाद में:

एक छोटे योगा स्टूडियो के लिए क्लास बुकिंग ऐप बनाओ। सदस्य इस हफ़्ते की क्लासें देखें (नाम, शिक्षक, समय, बची सीटें), एक सीट बुक करें, और दो घंटे पहले तक रद्द करें। सदस्य ईमेल और पासवर्ड से साइन अप करें। स्टूडियो का मालिक लॉगिन करके क्लास जोड़े, बुकिंग देखे और उपस्थिति दर्ज करे। क्लास, सदस्य और बुकिंग डेटाबेस में रखें। शांत, हल्का डिज़ाइन जो फ़ोन पर अच्छा दिखे। अभी कोई पेमेंट नहीं।

दूसरा संस्करण अब भी छोटा है। बस वह ऊपर की टेबल के सवालों के जवाब देता है।

व्यवहार का वर्णन करें, इम्प्लीमेंटेशन का नहीं

अक्सर आपको बेहतर नतीजे तब मिलते हैं जब आप बताते हैं कि क्या होना चाहिए, न कि उसे कैसे बनाना है।

पहले:

बुकिंग लाने के लिए एक useEffect जोड़ो और संपादन के लिए एक modal कंपोनेंट।

बाद में:

जब मालिक किसी बुकिंग पर क्लिक करे, तो एक पैनल खुले जहाँ वे समय बदल सकें या उसे रद्द कर सकें। बदलाव सूची में तुरंत दिखें।

पहला prompt AI को एक खास तकनीक में बाँध देता है जो शायद उस ऐप के ढाँचे में फ़िट न बैठे। दूसरा नतीजा बताता है और AI को छोड़ता है कि वह अपने लिखे कोड के हिसाब से सही तरीका चुने। अगर आप डेवलपर हैं और आपकी कोई मज़बूत पसंद है, तो ज़रूर बताएँ, पर उसके साथ नतीजा भी लिखें।

नियमों के बारे में सटीक रहें

बिज़नेस नियम वहीं सबसे ज़्यादा गलत होते हैं जहाँ AI से बने ऐप चूकते हैं, क्योंकि वे आपके लिए स्पष्ट हैं और AI के लिए अदृश्य। उन्हें साफ़ लिखें।

• सीमाएँ: “एक सदस्य के पास अधिकतम तीन भविष्य की बुकिंग हो सकती हैं।”
• समय: “क्लास शुरू होने से दो घंटे पहले रद्दीकरण बंद हो जाते हैं।”
• एज केस: “अगर क्लास भरी है, तो Book की जगह waitlist बटन दिखाएँ।”
• परमिशन: “शिक्षक अपनी क्लासों की उपस्थिति देख सकते हैं, दूसरे शिक्षकों की नहीं।”

इनमें से हर एक एक वाक्य है। इनमें से कोई भी छोड़ने का मतलब है कि ऐप या तो नियम लागू नहीं करेगा, या अपना ही कोई संस्करण गढ़ लेगा।

पहले संस्करण के बाद: हर संदेश में एक बदलाव

जब कोई चीज़ प्रिव्यू में चल रही हो, तब पूरे प्रोडक्ट का वर्णन करने से हटकर छोटे, जाँचने योग्य बदलाव माँगें।

पहले:

डिज़ाइन ठीक नहीं है, बुकिंग सही से काम नहीं कर रही और मुझे एक कैलेंडर व्यू और ईमेल चाहिए।

बाद में (चार अलग संदेश):

1. जब मैं किसी क्लास की आख़िरी सीट बुक करूँ, तो वह अब भी “1 spot left” दिखाती है। उसे “Full” दिखाना चाहिए और Book बटन छिपाना चाहिए।
2. शेड्यूल पेज पर एक साप्ताहिक कैलेंडर व्यू जोड़ो, हर दिन के लिए एक कॉलम। मौजूदा लिस्ट व्यू एक विकल्प के रूप में रखो।
3. फ़ोन पर क्लास कार्ड्स को और कॉम्पैक्ट करो: पैडिंग कम, और शिक्षक का नाम समय वाली लाइन पर ही।
4. बुकिंग होने पर सदस्य को पुष्टि का ईमेल भेजो।

यह तरीका क्यों काम करता है:

• हर बदलाव इतना छोटा है कि AI उसे एक ही बार में सही कर सके।
• आप आगे बढ़ने से पहले हर एक को टेस्ट कर सकते हैं।
• अगर एक गलत हो जाए, तो आप सिर्फ़ वह एक कदम वापस ले सकते हैं, बाक़ी को खोए बिना।

बताएँ क्या वैसा ही रहे

जब आप किसी ऐसी चीज़ में बदलाव माँगें जो पहले से काम कर रही है, तो बताएँ कि क्या नहीं बदलना चाहिए। किसी बदलाव से जो चीज़ें पहले चल रही थीं वे टूटें (जिसे regression कहते हैं), उसे रोकने का यह सबसे आसान तरीका है।

होम पेज के हीरो को बड़ी हेडलाइन और दाईं ओर फ़ोटो के साथ नया बनाओ। नेविगेशन, रंग और हीरो के नीचे की हर चीज़ बिल्कुल वैसी ही रखो।

यही डेटा पर भी लागू होता है: “मेंबर में एक फ़ोन नंबर फ़ील्ड जोड़ो। कोई मौजूदा फ़ील्ड न हटाओ या नाम न बदलो।”

स्क्रीनशॉट और सटीक टेक्स्ट इस्तेमाल करें

“ऊपर वाली चीज़” जैसे शब्द अस्पष्ट होते हैं। ज़्यादातर AI ऐप बिल्डर इमेज स्वीकार करते हैं, और स्क्रीनशॉट के साथ एक छोटा नोट एक पैराग्राफ़ के वर्णन से तेज़ होता है।

• स्क्रीनशॉट जोड़ें और लिखें “लाल घेरे वाला बटन फ़ोन पर मेनू से टकराता है”।
• किसी भी एरर मैसेज का सटीक टेक्स्ट चिपकाएँ, उसका सार न लिखें।
• स्क्रीन पर लिखे लेबल ठीक वैसे उद्धृत करें: “सेटिंग्स पेज पर Save changes बटन”।

खास तौर पर बग के लिए यह ढाँचा इस्तेमाल करें:

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

AI से बने ऐप को कैसे डीबग करें इस पर और गहराई से बात करती है।

बड़े बदलावों से पहले योजना बनाएँ

ऐसे किसी भी काम के लिए जो ऐप के कई हिस्सों को छूता है, जैसे ऐसे ऐप में यूज़र अकाउंट जोड़ना जिसमें पहले कोई नहीं था, पेमेंट जोड़ना, या डेटा की संरचना बदलना, कोई भी कोड बदलने से पहले योजना माँगें।

कुछ भी बदलने से पहले समझाओ कि टीम अकाउंट कैसे जोड़ोगे: कौन सी नई टेबल, कौन से पेज बदलेंगे, और मौजूदा यूज़र का क्या होगा। अभी कोड मत बदलो।

योजना पढ़ें। अगर वह किसी बात को गलत समझता है, तो एक पैराग्राफ़ सुधारना, पूरी बनी हुई सुविधा सुधारने से कहीं सस्ता है। कई बिल्डर्स में इसके लिए एक अलग मोड होता है; Mythex में यह Plan मोड है, जो Build और Ask के साथ आता है।

क्या टालें

API keys के बारे में: अगर आपको पेमेंट या ईमेल सेवा चाहिए, तो उसकी keys prompt में नहीं, प्रोजेक्ट की secrets में डालें। अगर यह नया है, तो environment variables और secrets क्या हैं देखें।

दोबारा इस्तेमाल होने वाले prompt टेम्पलेट

कोष्ठकों वाले हिस्सों को बदलकर इन्हें अपनाएँ।

नया ऐप:

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

नया फ़ीचर:

[पेज] में [फ़ीचर] जोड़ो। जब [यूज़र] [कार्य] करे, तो [क्या होना चाहिए]। सिर्फ़ [कौन] [यह] कर सके। [मौजूदा चीज़ें] जैसी हैं वैसी रखो।

डिज़ाइन बदलाव:

[पेज] पर [खास तत्व] को [खास बदलाव] में बदलो। [क्या वैसा रहे] वैसा ही रखो। जाँचो कि फ़ोन चौड़ाई वाली स्क्रीन पर सही दिखता है।

बग:

[पेज] पर मैंने [कदम] किए। मुझे [उम्मीद] थी। लेकिन [असल में क्या हुआ, और सटीक एरर टेक्स्ट]। इसे ठीक करो और फ़्लो चलने की जाँच करो।

बिना बदलाव वाला सवाल:

कोई कोड मत बदलो। समझाओ कि ऐप का [हिस्सा] कैसे काम करता है और [डेटा] कहाँ रखा जाता है।

लंबा स्पेक लिखना

बड़े प्रोजेक्ट्स के लिए पहले एक पेज की ब्रीफ़ लिखना मदद कर सकता है, और उसे अपने पहले prompt के रूप में चिपका सकते हैं: यूज़र, मुख्य फ़्लो, डेटा, नियम और जो दायरे से बाहर है। इसका ड्राफ़्ट बनाने में AI से मदद भी ले सकते हैं; AI से product requirements doc कैसे लिखें इसे समझाता है। बस पहला बिल्ड अनुरोध मुख्य फ़्लो तक रखें, और बाक़ी को एक-एक कदम करके जोड़ें।

Mythex में prompting

ऊपर का सब कुछ Mythex में काम करता है। कुछ खास बातें जो मदद करती हैं:

• Build, Plan और Ask मोड। बड़े या जोखिम भरे बदलावों के लिए Plan और बिना एडिट के समझाने के लिए Ask इस्तेमाल करें।
• Checkpoints। हर सफल बदलाव के बाद Mythex एक checkpoint सहेजता है, और किसी जवाब पर Revert to this point दबाने से प्रोजेक्ट वापस लौट जाता है। आप पिछला संदेश संपादित करके उसी बिंदु से अलग prompt भी आज़मा सकते हैं।
• Secrets कार्ड। जब एजेंट को API key चाहिए, तो वह चैट में एक कार्ड के ज़रिए पूछता है, ताकि वह मान आपके संदेश में लिखे जाने के बजाय प्रोजेक्ट secret के रूप में सहेजा जाए।
• इमेज। स्क्रीनशॉट या मॉकअप जोड़ें, और एजेंट उन्हें देखेगा।

डॉक्स में प्रभावी prompts और दोबारा बनाए बिना सुधार पर छोटे पेज हैं। अगर आप शून्य से शुरू कर रहे हैं, तो AI से ऐप कैसे बनाएं पूरा प्रोजेक्ट समझाता है, और AI से अच्छा दिखने वाला ऐप कैसे डिज़ाइन करें डिज़ाइन पॉलिश के prompts बताता है।

सवाल