AI ایپ بلڈرز کے لیے پرامپٹس کیسے لکھیں (پہلے اور بعد کی مثالوں کے ساتھ)
AI ایپ بلڈر کے لیے اچھا پرامپٹ پروڈکٹ بیان کرتا ہے، کوڈ نہیں: کون اسے استعمال کرتا ہے، وہ مرحلہ وار کیا کرتے ہیں، کون سا ڈیٹا رکھا جاتا ہے، اور کسے کیا دیکھنے کی اجازت ہے۔ پہلا ورژن بن جانے کے بعد ہر پیغام میں ایک مخصوص تبدیلی مانگیں، بتائیں کہ کیا برقرار رہنا چاہیے، اور مسائل کو “میں نے X کیا، Y کی توقع تھی، Z ہوا” کے انداز میں بیان کریں۔ یہ تین عادتیں زیادہ تر مایوس کن نتائج ٹھیک کر دیتی ہیں۔
اس گائیڈ کے باقی حصے ان پیٹرنز کی تفصیل دکھاتے ہیں، پہلے اور بعد کی مثالوں کے ساتھ جنہیں آپ اپنے مطابق ڈھال سکتے ہیں۔
AI ایپ بلڈر سے بات کرنا عام AI چیٹ سے مختلف کیوں ہے
جب آپ کسی چیٹ اسسٹنٹ سے سوال پوچھتے ہیں تو مبہم پرامپٹ کا مبہم جواب ملتا ہے اور آپ آگے بڑھ جاتے ہیں۔ جب آپ AI ایپ بلڈر کو پرامپٹ دیتے ہیں تو جواب ایک چلتا ہوا پروگرام ہوتا ہے۔ آپ کے بیان میں ہر خلا اندازے سے بھرا جاتا ہے، اور وہ اندازے کوڈ، ڈیٹابیس ٹیبلز اور اسکرینز بن جاتے ہیں جنہیں آپ کو برداشت کرنا یا واپس کرنا پڑتا ہے۔
اس لیے پرامپٹ کا مقصد ہوشیار لگنا نہیں ہے۔ اس کا مقصد یہ ہے کہ اہم فیصلے کم سے کم اتفاق پر چھوڑے جائیں۔ اس کے لیے آپ کو تکنیکی الفاظ کی ضرورت نہیں۔ آپ کو ان چیزوں کے بارے میں مخصوص ہونا ہے جو صرف آپ جانتے ہیں: آپ کے صارفین، آپ کا ورک فلو اور آپ کے اصول۔
پہلے پرامپٹ میں کیا شامل کریں
کچھ بھی لکھنے سے پہلے ان سوالوں کے جواب دیں۔ ہر ایک وہ خلا بند کرتا ہے جسے AI ورنہ اندازے سے بھرتا۔
| کیا شامل کریں | کیوں اہم ہے | مثال |
|---|---|---|
| پروڈکٹ ایک جملے میں | ہر بعد کے فیصلے کا دائرہ طے کرتا ہے | “دو کرسیوں والی ایک نائی کی دکان کے لیے بکنگ سائٹ” |
| اسے کون استعمال کرتا ہے | اسکرینز اور لہجہ طے کرتا ہے | “فون پر آنے والے گاہک، اور لیپ ٹاپ پر مالک” |
| مرکزی فلو، مرحلہ وار | وہ چیز جس کا سب سے پہلے کام کرنا لازم ہے | “سروس چنیں، وقت چنیں، نام اور فون لکھیں، تصدیق حاصل کریں” |
| وہ ڈیٹا جو یہ رکھتی ہے | ڈیٹابیس کا ڈیزائن بنتا ہے | “سروسز، بکنگز، گاہک” |
| کون کیا دیکھ یا بدل سکتا ہے | لاگ ان اور اجازتیں طے کرتا ہے | “صرف مالک تمام بکنگز دیکھ سکتا ہے” |
| انداز اور احساس، مختصراً | عام ڈیفالٹ انداز سے بچاتا ہے | “گہرا، سادہ، بڑے بٹن” |
| ابھی کیا چھوڑنا ہے | پہلے ورژن کو چھوٹا رکھتا ہے | “ابھی ادائیگیاں یا جائزے نہیں” |
آخری قطار کو کم اہمیت دی جاتی ہے۔ آپ جو نہیں چاہتے وہ بتانا AI کو بلاگ، قیمتوں کا صفحہ اور نیوز لیٹر سائن اپ شامل کرنے سے روکتا ہے جو آپ نے کبھی مانگا ہی نہیں تھا۔
پہلے اور بعد کی مثال: پہلا پرامپٹ
پہلے:
میرے جم کے لیے ایک ایپ بناؤ۔
بلڈر کو سب کچھ اندازے سے طے کرنا پڑے گا: ممبرز یا عملہ؟ کلاسز یا ذاتی ٹریننگ؟ ادائیگیاں؟ آپ کو ایسی چیز ملے گی جو جم کی ویب سائٹ جیسی لگے گی اور وہ کچھ نہیں کرے گی جس کی آپ کو ضرورت ہے۔
بعد میں:
ایک چھوٹے یوگا اسٹوڈیو کے لیے کلاس بکنگ ایپ بناؤ۔ ممبرز اس ہفتے کی کلاسز دیکھیں (نام، ٹیچر، وقت، باقی جگہیں)، ایک جگہ بک کریں، اور دو گھنٹے پہلے تک منسوخ کر سکیں۔ ممبرز ای میل اور پاس ورڈ سے سائن اپ کریں۔ اسٹوڈیو کا مالک لاگ ان ہو کر کلاسز شامل کرے، دیکھے کہ کون بک ہے، اور حاضری لگائے۔ کلاسز، ممبرز اور بکنگز ڈیٹابیس میں محفوظ کریں۔ پرسکون، ہلکا ڈیزائن جو فونز پر اچھا لگے۔ ابھی کوئی ادائیگی نہیں۔
دوسرا ورژن پھر بھی مختصر ہے۔ یہ بس اوپر کی ٹیبل کے سوالوں کے جواب دیتا ہے۔
رویہ بیان کریں، عمل نہیں
اکثر آپ کو بہتر نتیجہ اس وقت ملتا ہے جب آپ یہ بیان کریں کہ کیا ہونا چاہیے، بجائے اس کے کہ اسے کیسے بنایا جائے۔
پہلے:
بکنگز لانے کے لیے ایک useEffect اور ترمیم کے لیے ایک modal کمپوننٹ شامل کرو۔
بعد میں:
جب مالک کسی بکنگ پر کلک کرے تو ایک پینل کھولیں جہاں وہ وقت بدل سکے یا اسے منسوخ کر سکے۔ تبدیلیاں فہرست میں فوراً ظاہر ہوں۔
پہلا پرامپٹ AI کو ایک خاص تکنیک میں جکڑ دیتا ہے جو شاید اس ایپ کے ڈھانچے سے میل نہ کھائے۔ دوسرا اسے نتیجہ بتاتا ہے اور اسے اپنے لکھے ہوئے کوڈ کے لیے درست طریقہ چننے دیتا ہے۔ اگر آپ ڈویلپر ہیں اور آپ کی واضح ترجیح ہے تو اسے بیان کریں، مگر ساتھ میں نتیجہ بھی بتائیں۔
اصولوں کے بارے میں مخصوص رہیں
کاروباری اصول وہ جگہ ہیں جہاں AI سے بنی ایپس اکثر غلط ہو جاتی ہیں، کیونکہ وہ آپ کے لیے واضح ہیں اور AI کے لیے پوشیدہ۔ انہیں کھول کر لکھیں۔
- حدیں: “ایک ممبر زیادہ سے زیادہ تین آئندہ بکنگز رکھ سکتا ہے۔”
- وقت: “منسوخی کلاس شروع ہونے سے دو گھنٹے پہلے بند ہو جاتی ہے۔”
- ایج کیسز: “اگر کلاس بھری ہو تو Book کے بجائے ویٹ لسٹ کا بٹن دکھائیں۔”
- اجازتیں: “ٹیچرز اپنی کلاسز کی حاضری دیکھ سکتے ہیں، دوسرے ٹیچرز کی نہیں۔”
ان میں سے ہر ایک ایک جملہ ہے۔ کوئی بھی چھوڑ دیا جائے تو ایپ یا تو وہ اصول نافذ نہیں کرے گی یا اپنا ہی ایک ورژن گھڑ لے گی۔
پہلے ورژن کے بعد: ایک پیغام میں ایک تبدیلی
جب کوئی چیز پریویو میں چل رہی ہو تو پوری پروڈکٹ بیان کرنے کے بجائے چھوٹی، جانچی جا سکنے والی تبدیلیاں مانگنا شروع کریں۔
پہلے:
ڈیزائن ٹھیک نہیں ہے، بکنگ ٹھیک کام نہیں کرتی اور مجھے کیلنڈر ویو اور ای میلز چاہئیں۔
بعد میں (چار الگ پیغامات کے طور پر):
۱. جب میں کلاس کی آخری جگہ بک کرتا ہوں تو کلاس اب بھی “1 spot left” دکھاتی ہے۔ اسے “Full” دکھانا چاہیے اور Book کا بٹن چھپانا چاہیے۔ ۲. شیڈول صفحے پر ایک ہفتہ وار کیلنڈر ویو شامل کریں، ہر دن کے لیے ایک کالم۔ موجودہ لسٹ ویو بطور آپشن رکھیں۔ ۳. فونز پر کلاس کارڈز کو زیادہ کمپیکٹ بنائیں: چھوٹا پیڈنگ، ٹیچر کا نام وقت کے ساتھ ایک ہی لائن میں۔ ۴. بکنگ کرنے پر ممبر کو تصدیقی ای میل بھیجیں۔
یہ کیوں کام کرتا ہے:
- ہر تبدیلی اتنی چھوٹی ہے کہ AI اسے ایک پاس میں درست کر سکے۔
- آپ آگے بڑھنے سے پہلے ہر ایک کو جانچ سکتے ہیں۔
- اگر ایک خراب ہو جائے تو آپ صرف وہ ایک قدم واپس کر سکتے ہیں، باقی سب کھوئے بغیر۔
بتائیں کہ کیا برقرار رکھنا ہے
جب آپ کسی ایسی چیز میں تبدیلی مانگیں جو پہلے سے کام کر رہی ہو تو AI کو بتائیں کہ کیا نہیں بدلنا چاہیے۔ رگریشنز (وہ چیزیں جو پہلے کام کرتی تھیں اور تدوین کے بعد ٹوٹ گئیں) روکنے کا یہ سب سے آسان طریقہ ہے۔
ہوم پیج کے ہیرو حصے کو بڑی سرخی اور دائیں طرف ایک تصویر کے ساتھ دوبارہ ڈیزائن کریں۔ نیویگیشن، رنگ اور ہیرو کے نیچے سب کچھ بالکل ویسا ہی رکھیں۔
یہی ڈیٹا پر بھی لاگو ہوتا ہے: “ممبرز میں فون نمبر کا فیلڈ شامل کرو۔ کوئی موجودہ فیلڈ حذف یا تبدیل نہ کرو۔”
اسکرین شاٹس اور درست متن استعمال کریں
“اوپر والی چیز” جیسے الفاظ مبہم ہوتے ہیں۔ زیادہ تر AI ایپ بلڈرز تصاویر قبول کرتے ہیں، اور ایک مختصر نوٹ کے ساتھ اسکرین شاٹ ایک پیراگراف کی وضاحت سے تیز ہوتا ہے۔
- ایک اسکرین شاٹ لگائیں اور لکھیں “سرخ دائرے والا بٹن فونز پر مینو کے اوپر آ جاتا ہے”۔
- کسی بھی ایرر میسج کا متن جوں کا توں پیسٹ کریں، اس کا خلاصہ نہیں۔
- آن اسکرین لیبلز کو درست طور پر لکھیں: “Settings صفحے پر Save changes بٹن”۔
بگز کے لیے یہ شکل استعمال کریں:
بکنگز کے صفحے پر، میں نے کل کی ایک بکنگ کے لیے Cancel پر کلک کیا۔ میری توقع تھی کہ وہ میری فہرست سے غائب ہو جائے گی۔ اس کے بجائے کچھ نہیں ہوا اور ریفریش کے بعد بھی بکنگ موجود ہے۔ اسے ٹھیک کریں اور تصدیق کریں کہ منسوخی کام کرتی ہے۔
ہماری گائیڈ AI سے بنائی گئی ایپ کو کیسے ڈیبگ کریں اس پر مزید گہرائی سے بات کرتی ہے۔
بڑی تبدیلیوں کے لیے پہلے منصوبہ
ایسی کسی بھی چیز کے لیے جو ایپ کے بہت سے حصوں کو چھوئے — ایسی ایپ میں صارف اکاؤنٹس شامل کرنا جس میں پہلے کوئی نہ تھا، ادائیگیاں شامل کرنا، یا ڈیٹا کے ڈھانچے کو بدلنا — کوئی بھی کوڈ بدلنے سے پہلے منصوبہ مانگیں۔
کچھ بھی بدلنے سے پہلے وضاحت کریں کہ آپ ٹیم اکاؤنٹس کیسے شامل کریں گے: کون سی نئی ٹیبلز، کون سے صفحات بدلیں گے، اور موجودہ صارفین کے ساتھ کیا ہوگا۔ ابھی کوڈ میں ترمیم نہ کریں۔
منصوبہ پڑھیں۔ اگر وہ کسی بات کو غلط سمجھے تو ایک پیراگراف کی درستگی مکمل فیچر کی درستگی سے کہیں سستی پڑتی ہے۔ بہت سے بلڈرز میں اس کے لیے ایک مخصوص موڈ ہوتا ہے؛ Mythex پر یہ Plan موڈ ہے، جو Build اور Ask کے ساتھ ہے۔
کس چیز سے بچیں
| بچیں | کیوں | اس کے بجائے |
|---|---|---|
| “اسے بہتر بنائیں” / “اسے نمایاں کریں” | کوئی ہدف نہیں، اس لیے AI بے ترتیب چیزیں بدلتا ہے | تبدیلی کا نام لیں: “سیکشنز کے درمیان زیادہ خالی جگہ، بڑی سرخیاں” |
| دس فیچرز والا ایک بڑا پرامپٹ | غلطیاں جمع ہوتی ہیں؛ جانچنا مشکل | ہر پیغام میں ایک فیچر |
| چیٹ میں API کیز پیسٹ کرنا | کیز چیٹ کی ہسٹری میں جا پہنچتی ہیں | بلڈر کے سیکرٹس یا ماحولیاتی سیٹنگز استعمال کریں |
| خراب نتیجے سے بحث کرنا | ہر اصلاح غلطی پر ایک اور تہہ چڑھاتی ہے | واپس جائیں، پھر دوبارہ لکھیں |
| ایسے کوڈ کی وضاحت کرنا جو آپ نہیں سمجھتے | ایک کمزور فٹ پر لاک کر دیتا ہے | وہ رویہ بیان کریں جو آپ چاہتے ہیں |
| “انٹرپرائز گریڈ سیکیورٹی” مانگنا | اس کا کوئی مخصوص مطلب نہیں | اصل اصول لکھیں: کون کیا دیکھ سکتا ہے |
API کیز کے بارے میں: اگر آپ کو ادائیگی یا ای میل سروس چاہیے تو اس کی کیز پرامپٹ کے بجائے پروجیکٹ کے سیکرٹس میں رکھیں۔ اگر یہ نیا ہے تو ماحولیاتی متغیرات اور سیکرٹس کیا ہوتے ہیں دیکھیں۔
دوبارہ استعمال کے قابل پرامپٹ ٹیمپلیٹس
بریکٹ والے حصوں کو بدل کر انہیں ڈھال لیں۔
نئی ایپ:
ایک [ایپ کی قسم] [کس کے لیے] بناؤ۔ وہ [مرکزی فلو، مرحلہ وار]۔ [دوسری قسم کا صارف] [کیا کرنے] کے لیے لاگ ان ہوتا ہے۔ [ڈیٹا] ڈیٹابیس میں محفوظ کرو۔ [انداز اور احساس]۔ [بعد کے لیے چھوڑی گئی چیزیں] شامل نہ کرو۔
نیا فیچر:
[صفحے] پر [فیچر] شامل کرو۔ جب [صارف] [عمل] کرے تو [کیا ہونا چاہیے]۔ صرف [کون] [یہ کام] کر سکتا ہے۔ [موجودہ چیزیں] جیسی ہیں ویسی رکھو۔
ڈیزائن کی تبدیلی:
[صفحے] پر [مخصوص عنصر] کو [مخصوص تبدیلی] میں بدلو۔ [جو برقرار رکھنا ہے] کو ویسا ہی رکھو۔ فون کی چوڑائی کی اسکرین پر جانچو کہ درست نظر آتا ہے۔
بگ:
[صفحے] پر میں نے [اقدامات]۔ میری توقع [متوقع نتیجہ] تھی۔ اس کے بجائے [اصل نتیجہ، ایرر کا درست متن شامل کر کے]۔ اسے ٹھیک کرو اور فلو کی تصدیق کرو۔
تبدیلی کے بغیر سوال:
کوئی کوڈ نہ بدلو۔ بتاؤ کہ ایپ کا [حصہ] کیسے کام کرتا ہے اور [ڈیٹا] کہاں محفوظ ہوتا ہے۔
ایک لمبی تفصیل لکھنا
بڑے پروجیکٹس کے لیے بہتر ہو سکتا ہے کہ پہلے ایک صفحے کی بریف لکھیں اور اسے اپنے ابتدائی پرامپٹ کے طور پر چسپاں کریں: صارفین، مرکزی فلوز، ڈیٹا، اصول اور وہ کیا دائرے سے باہر ہے۔ آپ AI سے اس کا ڈرافٹ بنوا بھی سکتے ہیں — AI سے پروڈکٹ ریکوائرمنٹ ڈاکیومنٹ کیسے لکھیں میں اس کا طریقہ ہے۔ بس پہلی بلڈ درخواست کو مرکزی فلو تک محدود رکھیں اور باقی کو مرحلہ وار شامل کریں۔
Mythex میں پرامپٹنگ
اوپر کی ہر بات Mythex میں کام کرتی ہے۔ کچھ مخصوص باتیں جو مددگار ہیں:
- Build، Plan اور Ask موڈز۔ بڑی یا خطرناک تبدیلیوں کے لیے Plan استعمال کریں، اور جب آپ بغیر تدوین کے وضاحت چاہیں تو Ask۔
- چیک پوائنٹس۔ ہر کامیاب تبدیلی کے بعد Mythex ایک چیک پوائنٹ محفوظ کرتا ہے، اور کسی جواب پر Revert to this point پروجیکٹ کو اس مقام پر واپس لے جاتا ہے۔ آپ کوئی پرانا پیغام بھی ترمیم کر کے دوبارہ بھیج سکتے ہیں تاکہ اس مقام سے ایک مختلف پرامپٹ آزمائیں۔
- سیکرٹس کارڈ۔ جب ایجنٹ کو API کی درکار ہو تو وہ چیٹ میں ایک کارڈ کے ذریعے پوچھتا ہے، تاکہ قدر آپ کے پیغام میں لکھنے کے بجائے پروجیکٹ کے سیکرٹ کے طور پر محفوظ ہو۔
- تصاویر۔ اسکرین شاٹس یا موک اپس لگائیں اور ایجنٹ انہیں دیکھے گا۔
ڈاکس میں مؤثر پرامپٹس پر ایک مختصر صفحہ ہے، اور دوبارہ بنائے بغیر بہتری پر ایک اور۔ اگر آپ شروع سے بنا رہے ہیں تو AI سے ایپ کیسے بنائیں ایک مکمل پروجیکٹ کے ذریعے رہنمائی کرتی ہے، اور AI سے اچھی نظر آنے والی ایپ کیسے ڈیزائن کریں بصری نکھار کے پرامپٹس بتاتی ہے۔
سوالات
AI ایپ بلڈر کے لیے پرامپٹ کتنا لمبا ہونا چاہیے؟
پہلے ورژن کے لیے چار سے آٹھ جملوں کا ایک مختصر پیراگراف عموماً کافی ہوتا ہے: ایپ کون استعمال کرتا ہے، مرکزی فلو کیا ہے، کون سا ڈیٹا رکھا جاتا ہے اور کون کیا دیکھ سکتا ہے۔ اس کے بعد ایسے چھوٹے پرامپٹس بہتر کام کرتے ہیں جو ایک وقت میں ایک تبدیلی مانگیں، بجائے لمبے پرامپٹس کے۔
کیا مجھے AI کو بتانا چاہیے کہ کون سا فریم ورک یا زبان استعمال کرے؟
صرف تب بتائیں جب کوئی وجہ ہو، جیسے کوئی ڈویلپر جو بعد میں کوڈ سنبھالے گا، یا کوئی سروس جو صرف ایک اسٹیک کے ساتھ کام کرتی ہو۔ ورنہ پروڈکٹ بیان کریں اور بلڈر کو معقول ڈیفالٹس چننے دیں۔
AI وہ چیزیں کیوں بدلتا رہتا ہے جو میں نے بدلنے کو نہیں کہا تھا؟
عموماً اس لیے کہ پرامپٹ وسیع تھا (“اسے بہتر بنائیں”) یا اس نے یہ نہیں بتایا کہ کیا برقرار رکھنا ہے۔ جو چیز بدلنی ہے اس کا نام لیں، بتائیں کہ کیا وہی رہے، اور ہر پیغام میں ایک ہی تبدیلی مانگیں۔
خراب نتیجے کو مزید پرامپٹس سے ٹھیک کرنا بہتر ہے یا نئے سرے سے شروع کرنا؟
اگر آخری تبدیلی نے چیزیں بدتر کر دیں تو اس سے پہلے کے ورژن پر واپس جائیں اور دوبارہ لکھیں، بجائے اوپر مزید اصلاحات چڑھانے کے۔ نیا پروجیکٹ صرف تب شروع کریں جب خیال ہی بدل گیا ہو۔