فائدہ:
- ان لائن تکمیل کے ساتھ کام کی قسم کو درست کرنے کے لیے چیٹ موڈ کا نقشہ بنانے کی اہلیت
- طاقتور پروڈکشن پرامپٹس لکھنے کی صلاحیت جس میں ان پٹ/آؤٹ پٹ کنٹریکٹس، ایج کیسز اور اسٹائل کی رکاوٹیں شامل ہیں
- ضم ہونے سے پہلے تیار کردہ کوڈ اور کسی بھی نئے مجوزہ انحصار کی توثیق کرنے کی اہلیت
ایک ڈویلپر کا AI کے ساتھ رابطہ کا پہلا نقطہ اکثر خود بخود مکمل ہوتا ہے - ایک ایسی خصوصیت جو آپ کے ٹائپ کرتے وقت اگلی لائن تجویز کرتی ہے - یا چیٹ ونڈو میں "اس فنکشن کو ٹائپ کریں" کہتی ہے۔ وہ دونوں ایک ہی انجن کا استعمال کرتے ہیں لیکن مختلف شعبوں کی ضرورت ہوتی ہے۔ اس یونٹ میں، ہم کوڈ جنریشن کو بے ترتیب "اسے لکھیں" سے ایک انجینئرنگ مرحلہ میں تبدیل کرتے ہیں جس کا آؤٹ پٹ قابل قیاس اور قابل تصدیق ہے۔
مقصد یہ ہے کہ AI کو ایک ایسے ٹول سے تبدیل کیا جائے جو آپ کی ٹائپنگ مشین کو ایک ایسے اپرنٹیس میں تبدیل کرتا ہے جو آپ کی سیٹ کردہ رکاوٹوں کے اندر کام کرتا ہے۔ ایک اچھی رہنمائی کرنے والا اپرنٹس وقت بچاتا ہے۔ ایک غیر رہنمائی اپرنٹیس ایک گندگی پیدا کرتا ہے جسے آپ کو بعد میں صاف کرنا پڑتا ہے۔
استعمال کے دو طریقے: ان لائن تکمیل اور چیٹ
جب آپ اپنے ایڈیٹر میں ٹائپ کرتے ہیں تو ان لائن تکمیل عمل میں آتی ہے۔ آپ فنکشن کا دستخط یا کمنٹ لائن ٹائپ کرتے ہیں اور یہ باقی تجویز کرتا ہے۔ یہ رفتار کے لیے بہت اچھا ہے، لیکن اس کا ایک تنگ سیاق و سباق ہے: یہ صرف فوری علاقے میں کوڈ دیکھتا ہے۔ یہی وجہ ہے کہ جب آپ تبصرہ میں اپنا ارادہ واضح طور پر لکھتے ہیں تو یہ بہترین کام کرتا ہے۔ مثال کے طور پر، صارف کا ای میل //تصدیق کریں، اگر غلط تبصرہ نیچے دی گئی تجویز کو نمایاں طور پر بہتر بناتا ہے تو ValidationError پھینک دیں۔
چیٹ موڈ بڑے اور منظم کاموں کے لیے ہے: "اس کلاس میں صفحہ بندی شامل کریں"، "اس سروس کا ایک انٹرفیس نکالیں"۔ یہاں آپ کو کردار، سیاق و سباق اور فارمیٹ دینے کی عیش و آرام ہے۔ عام اصول ہے: چھوٹے اور بہتے ہوئے کاموں کی تکمیل، ان کاموں کے لیے گفتگو جن کے لیے سوچ اور ساخت کی ضرورت ہوتی ہے۔
مشورہ: "ٹیب" کے ساتھ تکمیل کی تجویز کو آنکھ بند کر کے قبول نہ کریں۔ ایک سیکنڈ کے لیے تجویز کردہ لائن پڑھیں؛ ایک غلط متغیر نام یا ایک الٹی حالت عام طور پر یہاں سے لیک ہوتی ہے۔
نیت کو کوڈ میں ترجمہ کرنے کے اقدامات
- معاہدے کی وضاحت کریں۔ فنکشن کا ان پٹ، آؤٹ پٹ اور ایرر برتاؤ کیا ہے؟ جیسے "ای میل حاصل کریں، اگر درست ہو تو نارمل کریں، اگر غلط ہو تو غلطی پھینک دیں۔"
- رکاوٹیں بیان کریں۔ بیرونی انحصار استعمال نہیں کرتے؟ ایک مخصوص طرز گائیڈ؟ کیا کارکردگی کی کوئی حد ہے؟
- ایک مثال دیں۔ ایک ان پٹ–آؤٹ پٹ جوڑا (“ali@x.com → valid, ali@ → error”) ماڈل کے ارادے کی سمجھ کو پیشین گوئی سے درستگی کی طرف لے جاتا ہے۔
- چھوٹے ٹکڑے مانگیں۔ ایک کام، ایک ذمہ داری۔ پھر اگلے ایک پر جائیں.
- تیار کردہ کوڈ کو پڑھیں اور چلائیں۔ مرتب کرنا + ایک فوری دستی کوشش سب سے سستا یقین دہانی کا مرحلہ ہے۔
تین چھوٹے کیسز
کیس 1 - تبصرے سے چلنے والی پیداوار درستگی کو بڑھاتی ہے۔ ایک ڈویلپر نے پہلے خالی باڈی کے ساتھ ڈیٹ پارسنگ فنکشن کی درخواست کی اور 3 راؤنڈز میں صحیح نتیجہ حاصل کیا۔ دوسری کوشش میں، جب میں نے فنکشن کو 4 لائن کے تبصرے (قبول شدہ فارمیٹس، ٹائم زون رول، ایرر کنڈیشن) کے ساتھ ڈیفائن کیا اور اس کی درخواست کی تو پہلے راؤنڈ میں کام کرنے والا کوڈ آ گیا۔ ایک ہی ماڈل، ایک ہی دن؛ فرق صرف نیت کی وضاحت کا تھا۔
کیس 2 - ورژن کی وضاحت نہ کرنا مہنگا ہے۔ ایک ٹیم نے Node.js کے لیے تیار کردہ کوڈ میں fs.promises کی جگہ لیجیسی کال بیک پر مبنی API کے ساتھ جدوجہد کی۔ جب لائن "Use Node 20, ESM, async/await" کو پرامپٹ میں شامل کیا گیا تو پروڈکشن نے پہلی بار اس پروجیکٹ کی پیروی کی۔ اصلاح پر گزارے گئے 12 منٹ کی اوسط دوبارہ ترتیب دی گئی۔
کیس 3 - بوائلر پلیٹ کوڈ میں حقیقی فائدہ۔ ایک مائیکرو سروس کے لیے 6 نئے ڈی ٹی او (ڈیٹا ٹرانسفر آبجیکٹ — ایک سادہ ڈیٹا کلاس جو تہوں کے درمیان ڈیٹا لے جاتی ہے) اور ان کی توثیق کے قواعد کی ضرورت ہوتی ہے۔ جو تقریباً 90 منٹ کا دستی کام ہوا کرتا تھا اسے AI کے ذریعہ تیار اور جائزہ لینے پر کم کر کے 35 منٹ کر دیا گیا تھا۔ چونکہ کوڈ کی تکرار زیادہ ہے اور پیٹرن واضح ہے، AI نے یہاں اپنے سب سے زیادہ موثر علاقے میں کام کیا۔
چار کاپی ایبل ٹیمپلیٹس
معاہدہ پر مبنی فنکشن جنریشن:
کردار: آپ ایک محنتی {{language}} ڈویلپر ہیں۔ فنکشن کنٹریکٹ:- نام: {{name}}- ان پٹ: {{قسم اور ان کے معنی}}- آؤٹ پٹ: {{قسم اور معنی}}- خرابی کی حیثیت: {{what is thrown/returned when}} رکاوٹیں: {{no external dependencys/input/style}}-{1}}> {{output_1}}- {{entry_2}} -> {{error_2}}پہلے دستخط + مختصر منصوبہ دیں، پھر کوڈ۔ تحریری ٹیسٹ، صرف فنکشن۔
موجودہ طرز سے ملنے کے لیے (کوڈ بیس کے مطابق ڈھالنا):
ذیل میں ہمارے پروجیکٹ کا ایک مثالی فنکشن ہے۔ یہاں نام، غلطی سے نمٹنے اور تبصرہ کرنے کا انداز سیکھیں۔ اسی طرز کے ساتھ {{new_task}} کے لیے فنکشن لکھیں۔ مثال: {{current_code}}
کنکال سے بھرنے تک (سٹب → نفاذ):
کمنٹس میں TODOs کے مطابق ذیل میں فنکشن سکیلیٹن کو پُر کریں۔ دستخط اور واپسی کی قسم کو تبدیل کریں۔ کوئی مددگار فنکشن نہ بنائیں جو موجود نہ ہو۔ اگر ضروری ہو تو مجھے بتائیں کہ "اس مددگار کی ضرورت ہے"۔ {{skelet_kod}}
متبادل ایپ کا موازنہ:
{{task}} کے لیے 2 مختلف نفاذات دیں: (a) پڑھنے کی اہلیت کو ترجیح دینا، (b) کارکردگی کو ترجیح دینا۔ ہر ایک کے نیچے 1 جملہ "جب افضل ہے" لکھیں۔
کمزور فوری / مضبوط اشارہ
کمزور: "مجھے ایک ای میل تصدیقی فنکشن لکھیں۔"
مضبوط: "TypeScript 5، معیاری لائبریری صرف۔ isValidEmail(input: string): boolean لکھیں۔ خالی جگہوں کو تراشیں، اسے غیر حساس بنائیں، a@b.co درست ہے، a@، @b.co، خالی سٹرنگ غلط ہے۔ اگر آپ ریجیکس استعمال کرنے جا رہے ہیں، تو زیادہ پیچیدہ تبصرے شامل نہ کریں۔"
طاقتور ورژن؛ زبان، ورژن، دستخط، کنارے کے کیسز، اور طرز کی رکاوٹ لوٹاتا ہے۔ اس طرح، تیار کردہ کوڈ کام کرتا ہے اور آپ کے پروجیکٹ میں فٹ بیٹھتا ہے۔
نقطہ نظر
کب استعمال کرنا ہے۔
توجہ
ان لائن تکمیل
بہاؤ میں چھوٹے داخل
اس تجویز کو پڑھے بغیر قبول نہ کریں۔
چیٹ میں معاہدہ پر مبنی پیداوار
نیا فنکشن/کلاس
مثال اور ایج کیس دیں۔
سٹائل نمونے کی طرف سے پیداوار
موجودہ کوڈ میں شامل کرنا
موجودہ نمونہ کوڈ منتخب کریں۔
کنکال بھرنا
دستخط فکسڈ، باڈی خالی
دستخط تبدیل کرنا
کوڈ کی نقل اور انحصار کا جال
AI اکثر اپنے کام کو آسان بنانے کے لیے ایک نئی لائبریری کی سفارش کرتا ہے۔ بعض اوقات یہ درست ہوتا ہے، بعض اوقات یہ آپ کے پروجیکٹ میں غیر ضروری انحصار کا اضافہ کرتا ہے یا ایسا پیکیج تجویز کرتا ہے جو موجود نہیں ہے (ایک فریب)۔ اصول: آپ ہر نئے انحصار کی تصدیق کرتے ہیں۔ اس بات کی تصدیق کیے بغیر اسے پروجیکٹ میں شامل نہ کریں کہ پیکیج اصل میں موجود ہے، برقرار ہے، اور اس کے پاس مناسب لائسنس ہے۔ زیادہ تر وقت پراجیکٹ میں پہلے سے موجود مددگار نئے پیکیج سے بہتر ہوتا ہے۔
احتیاط: AI کی طرف سے تجویز کردہ درآمدی لائنوں کا جائزہ لیں۔ ایک غیر موجود پیکج کا نام (جو جعلی پیکجوں سے بھی مشابہت رکھتا ہے جسے "ٹائپو اسکواٹنگ" کہا جاتا ہے) دونوں تالیف کو توڑ دیتا ہے اور سیکیورٹی کا خطرہ لاحق ہوتا ہے۔
عام غلطیاں
- ماڈل کے ذریعہ طے شدہ دستخط ہونا۔ اگر آپ ان پٹ/آؤٹ پٹ کی اقسام کو ٹھیک نہیں کرتے ہیں، تو ہر پروڈکشن کے ساتھ ایک مختلف دستخط آتا ہے اور انضمام مشکل ہو جاتا ہے۔
- ایج کیسز کا ذکر نہ کرنا۔ خالی ان پٹ، کالعدم، منفی نمبر، بہت بڑی قدر — اگر آپ ان کی وضاحت نہیں کرتے ہیں، تو ماڈل کناروں کو چھوڑتے ہوئے "خوشی کا راستہ" لکھتا ہے۔
- تجویز کو جانچے بغیر یکجا کرنا۔ کوڈ جو کام کرتا ہے اس کا مطلب یہ نہیں ہے کہ یہ کام کرتا ہے۔
- غیر ضروری انحصار کو قبول کرنا۔ ون لائنر کے لیے پوری لائبریری شامل کرنے سے تکنیکی قرض پیدا ہوتا ہے۔
- انداز میں تضاد۔ پراجیکٹ کے باقی حصوں سے مختلف نام اور غلطی کو سنبھالنا کوڈ کی بنیاد کو پیچیدہ بنا دیتا ہے۔
خلاصہ میں
جب آپ ارادے کو واضح معاہدے میں ترجمہ کرتے ہیں تو کوڈ جنریشن طاقتور ہوتی ہے۔ چھوٹے، دھارے میں آنے والے کاموں اور گفتگو میں ڈھانچہ قائم کرنے والے کاموں کے لیے ان لائن تکمیل کا استعمال کریں۔ آپ ان پٹ/آؤٹ پٹ کی اقسام، ایج کیسز، ورژن، اور اسٹائل بتاتے ہیں۔ ماڈل کی ایک مثال دیں؛ ہر نئے انحصار کی تصدیق کریں؛ اور تیار کردہ ہر ٹکڑے کو چلائیں اور پڑھیں۔ AI فارمولک، دہرائے جانے والے کوڈ میں بہترین ادائیگی کرتا ہے — اسے وہیں چلائیں، آپ کی مقرر کردہ حدود کے اندر۔
درخواست کا کام
اپنے پروجیکٹ سے ایک حقیقی چھوٹا فنکشن منتخب کریں جو آپ کو لکھنے کی ضرورت ہے۔ پہلے اسے "معاہدے پر مبنی فنکشن جنریشن" ٹیمپلیٹ کے ساتھ AI پر پرنٹ کریں، جس میں ان پٹ/آؤٹ پٹ کی قسمیں، دو کنارے کے کیسز، اور اسٹائل کی رکاوٹ شامل ہے۔ تیار کردہ کوڈ کو مرتب کریں اور اسے دو مختلف ان پٹ کے ساتھ آزمائیں۔ پھر اسی فنکشن سے دوبارہ پوچھیں، اس بار بغیر کسی سیاق و سباق کے "مجھے یہ لکھیں"، اور دو آؤٹ پٹ لائن کا بذریعہ لائن موازنہ کریں: کون سے کنارے کے کیسز چھوٹ گئے، کتنی تصحیح کی ضرورت تھی؟
چیک لسٹ
- میں جانتا ہوں کہ ان لائن تکمیل کے ساتھ چیٹ موڈ کہاں استعمال کرنا ہے۔
- میں فنکشن جنریشن میں ان پٹ/آؤٹ پٹ کنٹریکٹ اور ایج کیسز کا تعین کرتا ہوں۔
- میں نے پرامپٹ میں زبان اور ورژن کی معلومات شامل کرنے کی عادت بنا لی ہے۔
- میں ہر تیار شدہ ٹکڑے کو جمع کرنے سے پہلے مرتب کرتا ہوں اور جانچتا ہوں۔
- میں ہر نئے انحصار کی تصدیق کرتا ہوں جو AI تجویز کرتا ہے اس کے وجود اور ضرورت کی تصدیق کرتا ہوں۔
- میں چیک کرتا ہوں کہ تیار کردہ کوڈ پروجیکٹ کے انداز سے میل کھاتا ہے۔