Prompt Engineering برای برنامه‌نویسان چیست؟

Prompt Engineering در فضای عمومی گاهی به جادوی جمله‌های فانتزی تقلیل داده می‌شود. برای برنامه‌نویس، پرامپت خوب یعنی مشخص کردن قید، ورودی، خروجی، مثال درست، و معیار قبول — دقیقاً همان چیزهایی که در تعریف Acceptance Criteria و Code Review هم به کار می‌آید.

راهنماهای رسمی هم همین روح را دارند. OpenAI پرامپت‌نویسی را نوشتن دستورالعمل مؤثر برای تولید سازگار با نیاز تعریف می‌کند و روی نقش پیام‌ها، نسخه‌گذاری پرامپت، و ارزیابی تأکید دارد. Anthropic روی وضوح، مثال، ساختار، و کار agentic تمرکز می‌کند. Google در استراتژی‌های Gemini روی دستور روشن، مثال few-shot، افزودن زمینه، و شکستن کار به اجزا تأکید دارد.

این مقاله پرامپت را برای کار روزمرهٔ کد ترجمه می‌کند: نه کپی تبلیغاتی، بلکه قرارداد کوتاه بین شما و مدل.

پاسخ کوتاه

Prompt Engineering برای برنامه‌نویسان یعنی طراحی دستور کار برای مدل با قیدهای صریح، مثال‌های کوچک، درخواست Diff قابل‌بازبینی، و اتصال به تست. هدف، متن زیبا نیست؛ خروجی است که بتوانید در Review رد یا قبول کنید. پرامپت بازاریابی («مثل یک نینجای کدنویسی رفتار کن») را با پرامپت مهندسی («فقط فایل X را تغییر بده، تست Y باید سبز بماند، خروجی را به‌صورت Diff بده») عوض کنید.

پرامپت خوب قرارداد کوتاه است؛ نه شعار.

چه چیزی پرامپت توسعه‌دهنده را متفاوت می‌کند؟

مخاطب مدل در IDE یا Agent، کد و مخزن است نه مشتری عمومی. بنابراین پرامپت باید به مسیر فایل، قرارداد API، نسخهٔ زبان، و تست اشاره کند. همچنین خروجی باید قابل ادغام باشد: وصلهٔ کوچک بهتر از بازنویسی کامل یک ماژول است.

برخلاف پرامپت تولید محتوا، اینجا اشتباه یعنی باگ، بدهی فنی، یا نشت Secret. پس قیدهای منفی مهم‌اند: چه چیزی را تغییر نده، چه چیزی را در پاسخ نیاور، و چه فرمان‌هایی مجاز نیستند.

چهار ستون پرامپت مهندسی

۱) قیدها (Constraints)

قید یعنی مرز کار: فایل‌های مجاز، سبک نام‌گذاری، نسخهٔ فریم‌ورک، ممنوعیت وابستگی جدید، و حفظ سازگاری عقب‌رو. OpenAI و Google هر دو روی دستور روشن و مشخص تأکید دارند؛ در کد این یعنی به‌جای «بهترش کن» بنویسید «پیچیدگی زمانی را کم کن بدون تغییر امضای تابع».

۲) مثال‌ها (Examples / few-shot)

یک نمونهٔ ورودی/خروجی کوتاه اغلب بهتر از یک پاراگراف توضیح انتزاعی است. Google صراحتاً few-shot را برای تنظیم قالب و الگو توصیه می‌کند. در کدنویسی، یک تست کوچک یا یک snippت قبل/بعد کافی است تا مدل الگوی تیم را بگیرد.

۳) Diff و محدودهٔ تغییر

از مدل بخواهید تغییر را به‌صورت Diff یا فهرست فایل‌های لمس‌شده بدهد و از بازنویسی بی‌دلیل خودداری کند. این کار Review را ممکن می‌کند و با عادت مقالهٔ ۰۹۸ هم‌راستاست: کد را مثل خروجی شخص ثالث ببینید.

۴) تست به‌عنوان معیار قبول

پرامپت را به تست وصل کنید: «این تست باید سبز بماند»، «برای حالت خطای Z یک تست اضافه کن». تست ضعیف که فقط پیاده‌سازی فعلی را قفل کند کافی نیست؛ بگویید رفتار مورد انتظار چیست.

الگوی پرامپت کوتاه برای کار روزمره

یک قالب عملی:

هدف: ...\nقیدها: فقط مسیرهای A/B؛ بدون وابستگی جدید؛ Python 3.11\nزمینه: فایل‌های ... و تست ...\nخروجی: Diff + توضیح ریسک در سه خط\nقبول: دستور تست ... باید سبز شود

مثال کوتاه در عمل

فرض کنید باید یک تابع اعتبارسنجی ایمیل را اصلاح کنید بدون شکستن فراخوان‌کننده‌ها. پرامپت ضعیف: «این تابع را بهتر کن». پرامپت بهتر: هدف رفع false negative برای دامنهٔ بین‌المللی، قید حفظ امضا، افزودن دو تست، و خروجی فقط Diff همان فایل و تست.

# bad\nImprove this email validator.\n\n# better\nGoal: fix false negatives for IDN emails.\nConstraints: keep function signature; Python 3.11; no new deps.\nTouch only: validators.py, test_validators.py\nDone when: pytest -q test_validators.py passes.\nOutput: unified diff only.

ضدالگوهای پرامپت در توسعه

• نقش‌بازی بدون قید («تو یک معمار ۱۰x هستی»).
• چسباندن Secret یا توکن در پرامپت.
• درخواست بازنویسی کل سرویس در یک پیام.
• قبول خروجی بدون خواندن Diff.
• تست نخواستن و فقط «اگر اجرا شد تمام است».

این ضدالگوها همان مسیر افت کیفیت مقالهٔ ۰۹۸ و نشت Secret مقالهٔ ۰۹۹ هستند؛ فقط از در پرامپت وارد می‌شوند.

پرامپت برای Agent در برابر پرامپت برای چت

وقتی با Coding Agent کار می‌کنید، پرامپت باید حلقه را هم هدایت کند: چه چیزی را جست‌وجو کند، چه چیزی را اجرا کند، و کجا توقف کند. مقالهٔ ۱۰۲ حلقه را توضیح می‌دهد؛ اینجا کافی است بگویید «اول برنامه بده و قبل از ویرایش گسترده صبر کن» یا «فقط تست واحد را اجرا کن».

برای چت توضیحی، پرامپت می‌تواند بازتر باشد. اشتباه رایج این است که پرامپت چت را عیناً به Agent بدهید و بعد از تغییرات وسیع غافلگیر شوید.

جدول تطبیق تکنیک و موقعیت

نسخه‌گذاری و تکرار

OpenAI توصیه می‌کند پرامپت‌ها را در کد نسخه‌گذاری کنید و با ارزیابی پایش کنید. ترجمهٔ تیمی: قالب‌های پرامپت پرتکرار را در Rules یا snippت تیمی نگه دارید، نه در حافظهٔ افراد. وقتی مدل یا ابزار عوض شد، همان قالب را دوباره بسنجید.

Anthropic روی وضوح و مثال و ساختار تأکید دارد؛ اگر پرامپت شما طولانی و متناقض است، اول آن را کوتاه و سازگار کنید قبل از اینکه مدل را مقصر بدانید.

چک‌لیست قبل از ارسال پرامپت

1. آیا هدف در یک جمله قابل اندازه‌گیری است؟
2. آیا قید فایل و وابستگی مشخص است؟
3. آیا Secret در متن نیست؟
4. آیا معیار تست یا پذیرش گفته شده؟
5. آیا خروجی Reviewپذیر خواسته شده؟

اگر یکی از این‌ها خالی است، احتمالاً بعداً وقت بیشتری در اصلاح خروجی می‌گذارید تا در نوشتن پرامپت.

پیوند با سری

۰۹۷ ابزارها را نقشه می‌کند، ۱۰۱ و ۱۰۲ Agent را تعریف و شرح می‌دهند، ۰۹۸ کیفیت را قفل می‌کند، ۱۰۴ تفویض کنترل‌شده را می‌گوید. پرامپت خوب حلقهٔ اتصال همهٔ این‌هاست.

پرامپت برای تولید تست

از مدل بخواهید ابتدا رفتار را فهرست کند، بعد تست بنویسد، و صریحاً بگوید کدام حالت‌ها را پوشش نداده است. این کار جلوی تست‌های نمایشی را می‌گیرد. مثال قید: «حداقل یک حالت خوش‌مسیر، یک ورودی نامعتبر، و یک خطای وابستگی خارجی».

پرامپت برای بازآرایی

بازآرایی بدون تست مثل جابه‌جایی مبل در تاریکی است. اول بگویید کدام تست‌ها باید سبز بمانند، کدام فایل‌ها خارج از محدودهاند، و آیا تغییر رفتار مجاز است یا نه. اگر رفتار باید ثابت بماند، همان را در خط اول پرامپت بنویسید.

پرامپت برای کار با کد ناآشنا

اول حالت Ask یا توضیح بخوانید: «این ماژول چه قراردادی با بیرون دارد؟ نقاط ورود کجاست؟» بعد از فهم، پرامپت تغییر را جدا بفرستید. قاطی کردن کشف و تغییر در یک پیام، Diffهای بزرگ و دشوار برای Review می‌سازد.

خطای رایج: پرامپت خیلی مؤدب و مبهم

ادب خوب است؛ ابهام نه. جمله‌هایی مثل «اگر ممکن است لطفاً کمی بهترش کن» مدل را به تغییرات سلیقه‌ای می‌کشاند. به‌جای آن معیار بدهید: زمان پاسخ، خوانایی، یا پوشش حالت خطا. راهنماهای رسمی روی وضوح و صراحت توافق دارند.

پرامپت‌های تیمی را در onboarding بگذارید

یک پوشهٔ کوتاه از قالب‌های پرامپت برای باگ، فیچر، بازآرایی و مستند، ورود نیروهای جدید را سریع‌تر می‌کند و کیفیت میانگین را بالا می‌برد. این قالب‌ها را ماهانه با نمونه‌های واقعی به‌روز کنید.

اندازه‌گیری اثر پرامپت

اگر بعد از تغییر قالب پرامپت، نرخ Accept بدون اصلاح کم شد یا زمان Review بالا رفت، قالب را برگردانید یا قیدها را سفت‌تر کنید. بدون اندازه‌گیری، سلیقه جای مهندسی را می‌گیرد.

پرامپت لایه‌ای: سیستم، پروژه، تسک

لایهٔ اول قواعد پایدار تیم است که در Rules یا فایل تنظیمات پروژه می‌ماند. لایهٔ دوم زمینهٔ مخزن و قرارداد ماژول است. لایهٔ سوم همان پیام تسک است. اگر همه چیز را فقط در پیام تسک بریزید، تکرار و تناقض زیاد می‌شود. راهنماهای فروشندگان هم بین دستورالعمل پایدار و ورودی لحظه‌ای تفکیک قائل می‌شوند.

برای تیم‌های چندنفره، لایهٔ اول را در onboarding آموزش دهید تا هر کس سبک پرامپت شخصی اختراع نکند. تفاوت سلیقه در توضیح آزاد است؛ تفاوت در قیدهای امنیتی و مسیرهای ممنوع نیست.

جمع‌بندی برای تصمیم

وقتی مدل «درست می‌گوید» اما Diff غلط است

متن روان مدل می‌تواند اعتماد کاذب بسازد. همیشه Diff را منبع حقیقت بدانید. از مدل بخواهید فهرست فایل‌های تغییر یافته و دلیل هر تغییر را جدا بنویسد؛ بعد همان را با واقعیت فایل‌ها چک کنید. اگر توضیح و Diff یکی نبود، نشست را متوقف و قیدها را بازنویسی کنید.

در کارهای امنیتی و پرداخت، حتی Diff تمیز هم کافی نیست؛ بازبینی متخصص و تست هدفمند لازم است. پرامپت خوب ریسک را کم می‌کند اما مسئولیت را منتقل نمی‌کند.

پرامپت برای کار با داده و مهاجرت

صریح بنویسید: آیا مهاجرت باید برگشت‌پذیر باشد، آیا دادهٔ موجود باید حفظ شود، و آیا اجرا روی محیط واقعی مجاز است یا فقط تولید اسکریپت. بدون این قیدها، مدل ممکن است اسکریپت مخرب یا غیرقابل برگشت پیشنهاد دهد. اتصال این بخش به مقالات محیط‌ها و دیپلوی سری مفید است.

تمرین سی‌دقیقه‌ای

یک باگ واقعی کوچک انتخاب کنید. ده دقیقه صرف نوشتن پرامپت با قالب هدف-قید-زمینه-خروجی-تست کنید. ده دقیقه به مدل بدهید. ده دقیقه Diff و تست را خودتان بررسی کنید. نتیجه را با یک پرامپت مبهم قبلی مقایسه کنید. بیشتر تیم‌ها می‌بینند زمان کل کمتر و کیفیت بالاتر می‌شود.

پرامپت را در کنار Definition of Done نگه دارید

اگر کارت بکهالگ معیار پذیرش دارد، همان را در پرامپت کپی کنید. این کار مقالهٔ ۰۶۴ و ۱۰۴ را به عمل روزمره وصل می‌کند. مدل نمی‌تواند معیار نانوشته را حدس بزند؛ اگر ننویسید، بهینه می‌کند برای چیزی که شبیه تمام شدن است.

در پایان به یاد بسپارید: پرامپت خوب جایگزین فهم شما از دامنه نمی‌شود. اگر خودتان نمی‌دانید Done چیست، مدل هم نمی‌داند. اول فکر، بعد پرامپت، بعد Review.

Prompt Engineering برای برنامه‌نویس یعنی مهندسی قید و معیار قبول، نه جادوی کلمات. با قالب هدف-قید-زمینه-خروجی-تست شروع کنید، مثال کوتاه بدهید، Diff بخواهید، و Secret را از متن دور نگه دارید.

جمع‌بندی نهایی عملی

سه جمله را روی میز کارتان بگذارید: قید بدون مثال ناکافی است، مثال بدون تست خطرناک است، تست بدون Review ناقص است. پرامپت مهندسی محل تلاقی این سه است. ابزارها عوض می‌شوند؛ این ترتیب عوض نمی‌شود.

برای شروع فردا: یک قالب پرامپت تیمی برای باگ و یک قالب برای فیچر کوچک بنویسید، در مخزن بگذارید، و در دو هفته نرخ اصلاح بعد از Accept را اندازه بگیرید. اگر عدد بهتر نشد، قالب را سخت‌گیرانه‌تر کنید نه اینکه مدل را عوض کنید.

یادداشت پایانی دربارهٔ صداقت منابع

تکنیک‌های این مقاله با راهنماهای رسمی OpenAI، Anthropic و Google هم‌راستا است: وضوح، مثال، زمینه، و تکرار مبتنی بر ارزیابی. جزئیات مدل‌ها عوض می‌شود؛ اصول پرامپت مهندسی برای توسعه پایدار می‌ماند. همیشه به صفحهٔ رسمی نسخهٔ مدل خودتان هم سر بزنید.

با همین اصول می‌توانید پرامپت را از یک حدس شخصی به یک دارایی تیمی تبدیل کنید و سرعت را بدون قربانی کردن Review نگه دارید.

اگر فقط یک عادت این هفته می‌سازید: هر پرامپت کدنویسی را قبل از ارسال با چک‌لیست پنج‌سؤالی بالا مرور کنید.

منابع و مراجع

• OpenAI — Prompt engineering — https://developers.openai.com/api/docs/guides/prompt-engineering
• Anthropic — Prompting best practices — https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/claude-4-best-practices
• Google AI — Prompt design strategies (Gemini API) — https://ai.google.dev/gemini-api/docs/prompting-strategies

پرامپت را مثل کد Review کنید؛ چون همان‌قدر روی کیفیت اثر می‌گذارد.