توسعه نرمافزار و هوش مصنوعی
پرامپتنویسی برای برنامهنویسان؛ از درخواست مبهم تا پاسخ قابل استفاده
برای گرفتن پاسخ بهتر از یک دستیار هوش مصنوعی لازم نیست متن پیچیدهای بنویسید. کافی است مسئله، زمینه فنی، محدودیتها و شکل خروجی را روشن کنید. این راهنما نشان میدهد چطور همین چهار بخش را برای تولید کد، رفع اشکال، نوشتن تست و مستندسازی به کار ببرید.
چرا درخواستهای کوتاه معمولاً پاسخ مبهم میگیرند؟
فرض کنید در میانه توسعه یک صفحه اندروید هستید و فقط مینویسید: «برای RecyclerView کمکم کن.» مدل نمیداند داده از کجا میآید، از View Binding استفاده میکنید یا Compose، تغییرات فهرست چطور محاسبه میشود و دقیقاً کدام بخش برایتان مسئله است. در نبود این اطلاعات، طبیعی است که پاسخ به یک توضیح عمومی تبدیل شود.
پرامپت در کار برنامهنویسی بیشتر از آنکه «سؤال» باشد، صورت مسئله است. همانطور که یک تیکت ناقص باعث رفتوبرگشت تیم میشود، درخواست مبهم هم مدل را وادار میکند جاهای خالی را حدس بزند. بعضی حدسها درستاند و بعضی با معماری، نسخه کتابخانه یا نیاز محصول شما سازگار نیستند.
فرمول چهار بخشی برای یک پرامپت فنی
برای بیشتر کارهای روزمره میتوانید از این ترتیب استفاده کنید: هدف + زمینه + محدودیتها + قالب خروجی. نقش دادن به مدل گاهی لحن و زاویه پاسخ را تنظیم میکند، اما جای اطلاعات فنی را نمیگیرد.
بگویید چه نتیجهای میخواهید؛ مثلاً کاهش تکرار کد، پیدا کردن علت خطا یا نوشتن تست برای یک رفتار مشخص.
زبان، فریمورک، نسخههای مهم، معماری، ورودی و بخشی از کد مرتبط را اضافه کنید.
کتابخانه مجاز، سطح سازگاری، ملاحظات امنیتی، کارایی و مواردی را که نباید تغییر کنند مشخص کنید.
تعیین کنید فقط کد میخواهید، توضیح کوتاه لازم است، خروجی باید diff باشد یا همراه تست ارائه شود.
زمینه را مثل توضیح یک Pull Request بنویسید
در بازبینی کد فقط چند خط تغییر را نمیبینیم؛ نامگذاری، قراردادهای پروژه، جریان داده و اثر تغییر بر بخشهای دیگر را هم میسنجیم. برای دستیار هوش مصنوعی نیز باید همان بخش از زمینه را فراهم کنید که بر پاسخ اثر دارد، نه کل مخزن را.
- نسخه زبان، فریمورک یا کتابخانهای را که رفتار پاسخ به آن وابسته است ذکر کنید.
- خطا و stack trace را کامل بفرستید، اما بخش تکراری و نامرتبط را حذف کنید.
- رفتار مورد انتظار و رفتار فعلی را جدا از هم توضیح دهید.
- کد حداقلی بازتولیدپذیر ارائه کنید؛ نه تصویری از کد و نه کل پروژه.
- قراردادهای داخلی مانند الگوی مدیریت خطا یا نامگذاری را صریح بنویسید.
طبق راهنمای رسمی GitHub برای پرامپتنویسی در Copilot، ارائه مثال، شکستن کار پیچیده به چند مرحله، حذف ابهام و مشخص کردن کد مرتبط از راههای اصلی بهبود پاسخ است. تاریخچه گفتوگو نیز بخشی از زمینه محسوب میشود؛ بنابراین برای یک مسئله کاملاً جدید، گفتوگوی تازه معمولاً انتخاب تمیزتری است.
چهار مثال کاربردی برای کار روزانه
| کار | درخواست ضعیف | درخواست قابل بررسی |
|---|---|---|
| بازنویسی کد | این تابع را بهتر کن. | این تابع suspend در کاتلین روی ترد UI کار مسدودکننده انجام میدهد. بدون تغییر امضای عمومی، آن را با coroutine بازنویسی کن و دلیل هر تغییر را در سه نکته توضیح بده. |
| تولید ساختار | یک state بساز. | برای صفحه دریافت مقاله در Kotlin یک sealed interface با حالتهای Loading، Success، Empty و Error بساز. داده Success از نوع List<Article> باشد و فقط کد را برگردان. |
| نوشتن تست | برای این کد تست بنویس. | برای ViewModel زیر با JUnit و Mockito تست واحد بنویس. سه رفتار موفقیت، خطای مخزن و فهرست خالی را پوشش بده و نام تستها از الگوی given_when_then پیروی کند. |
| مستندسازی | این تابع را توضیح بده. | برای این تابع یک docstring کوتاه بنویس که ورودی، خروجی، خطاهای قابل انتظار و اثر جانبی را توضیح دهد. پیادهسازی را تکرار نکن. |
خروجی مورد انتظار را میتوان با یک نمونه ورودی و خروجی نیز روشن کرد. این کار مخصوصاً برای تبدیل داده، عبارتهای منظم، قالب تاریخ و APIها مؤثر است؛ چون فضای حدس زدن را کوچک میکند.
برای رفع اشکال، فقط پیام خطا کافی نیست
پیام خطا سرنخ است، نه کل پرونده. یک پرامپت رفع اشکال خوب باید نشان دهد خطا در چه محیطی رخ داده، چه چیزی انتظار داشتید، چه اتفاقی افتاده و چه راههایی را امتحان کردهاید. بهتر است از مدل بخواهید ابتدا چند فرضیه اولویتبندیشده ارائه کند و سپس برای هر فرضیه یک روش آزمون پیشنهاد دهد.
این ساختار مدل را از پریدن مستقیم به یک راهحل تصادفی بازمیدارد. اگر پاسخ چند فایل را تغییر میدهد، هر تغییر را جدا اجرا و تست کنید تا منشأ رگرسیون گم نشود.
پاسخ اول، شروع گفتوگو است
گاهی بهترین کار این نیست که پرامپت اولیه را طولانیتر کنید. یک پاسخ اولیه بگیرید و بعد پرسش دقیقتری مطرح کنید: «چرا این وابستگی را اضافه کردی؟»، «نسخه بدون تغییر schema چیست؟» یا «این راهحل در بار همزمان چه نقطه ضعفی دارد؟» این رفتوبرگشت شبیه برنامهنویسی دونفره است، با این تفاوت که مسئولیت سنجش پاسخ کاملاً با شماست.
برای تغییرهای بزرگ، کار را به واحدهای کوچک تقسیم کنید: ابتدا قرارداد و تستها، سپس پیادهسازی، بعد بررسی امنیت و در پایان مستندات. راهنمای طراحی وب با هوش مصنوعی همین رویکرد مرحلهای را برای ساخت و بازبینی یک صفحه وب توضیح میدهد.
کد تولیدشده را مثل کد یک همکار بازبینی کنید
دستیار هوش مصنوعی میتواند API قدیمی پیشنهاد دهد، کتابخانهای با مجوز نامناسب اضافه کند یا کدی تولید کند که فقط مسیر موفق را پوشش میدهد. راهنمای بهترین روشهای GitHub Copilot نیز تأکید میکند که ابزار جای تخصص توسعهدهنده را نمیگیرد و کد پیشنهادی باید اعتبارسنجی شود.
- تستهای موجود و تستهای جدید را اجرا کنید و فقط به توضیح مدل اعتماد نکنید.
- ورودی نامعتبر، مقدار null، زمانبندی، همزمانی و خطاهای شبکه را بررسی کنید.
- وابستگیهای تازه، مجوزها و نسخه پیشنهادی را در مستندات رسمی کنترل کنید.
- برای احراز هویت، پرداخت، رمزنگاری و مجوز دسترسی بازبینی انسانی مستقل داشته باشید.
- تغییر نهایی را با قراردادهای پروژه، هزینه اجرا و قابلیت نگهداری بسنجید.
یک الگوی مشترک برای تیم بسازید
اگر چند نفر در تیم از ابزارهای هوش مصنوعی استفاده میکنند، توافق روی یک قالب کوتاه کیفیت کار را یکدستتر میکند. میتوانید نسخه زیر را در مستندات پروژه نگه دارید و برای هر زبان یا سرویس چند نمونه واقعی به آن اضافه کنید.
برای کارهای رابط کاربری، مقاله آموزش پرامپتنویسی برای طراحی رابط کاربری کمک میکند مخاطب، حالتها، واکنشگرایی و محدودیتهای بصری را نیز وارد درخواست کنید. نمونههای ساختهشده با پرامپتهای مختلف هم در گالری ThinkFlow در دسترساند.
پرسشهای متداول
بهترین ساختار پرامپت برای دریافت کد چیست؟
هدف، زمینه فنی، محدودیتها و قالب خروجی را مشخص کنید. ورودی و رفتار مورد انتظار را بنویسید و از مدل بخواهید تست یا توضیح تصمیمهای مهم را نیز ارائه کند. برای کارهای حساس، درخواست threat model یا چکلیست امنیتی میتواند مفید باشد، اما جای بازبینی متخصص را نمیگیرد.
برای رفع اشکال چه اطلاعاتی را در پرامپت قرار دهیم؟
متن کامل خطا، بخش حداقلی کد، نسخه زبان و کتابخانهها، رفتار مورد انتظار، رفتار واقعی و راههایی را که قبلاً امتحان کردهاید ارائه کنید. اطلاعات محرمانه را پیش از ارسال حذف کنید.
آیا میتوان کد تولیدشده با هوش مصنوعی را مستقیم وارد پروژه کرد؟
خیر. کد را مانند پیشنهاد یک همکار بررسی کنید: تستها را اجرا کنید، امنیت و کارایی را بسنجید و سازگاری آن را با معماری و مجوزهای پروژه تأیید کنید.
منابع و روش تدوین
نسخه اولیه این مقاله از نوشته Writing Prompts Like a Pro: How Developers Can Actually Get Useful Answers from AI اثر فرنی کریستین، منتشرشده در ۳۰ ژوئیه ۲۰۲۵ در Medium الهام گرفته است. تیم هوش عمیق متن را به فارسی طبیعی بازنویسی کرده، ساختار چهار بخشی، مثال FastAPI، الگوی تیمی، معیارهای بازبینی و نکات امنیتی را به آن افزوده و توصیهها را با مستندات رسمی GitHub تطبیق داده است. تاریخ دسترسی به منابع: ۱۳ مرداد ۱۴۰۵.
- مقاله اصلی فرنی کریستین در Medium
- راهنمای رسمی مهندسی پرامپت برای GitHub Copilot Chat
- بهترین روشهای استفاده از GitHub Copilot
مطالب مرتبط
یک درخواست روشن بنویسید و نتیجه را ببینید
هدف صفحه، مخاطب، اجزای ضروری و محدودیتهای طراحی را در چند خط مشخص کنید. ThinkFlow از همین توضیح برای ساخت نسخه قابلپیشنمایش استفاده میکند و میتوانید نتیجه را مرحلهبهمرحله اصلاح کنید.