یه بار پرامپت خوب نوشتید، جواب عالی گرفتید؛ فردا همان سرویس با همان پرامپت شروع به توهم‌زنی می‌کند. فرق کجاست؟ تقریباً همیشه در چیزی است که کنار پرامپت‌تان به مدل رسیده: سندی که RAG آورده، تاریخچه‌ای که انباشته شده، خروجی ابزاری که برگشته. پرامپت‌نویسی فقط هنر نوشتن یک لایه است؛ هنر اصلی این است که کل چیزی که مدل در هر لحظه می‌بیند را با طراحی بسازید. به این کار می‌گویند مهندسی زمینه یا Context Engineering — و در محصولات واقعی، تفاوت بین یک دموی تماشایی و یک سرویس قابل‌اعتماد معمولاً همین‌جاست.
مهندسی زمینه چیست؟
اول یک تفکیک: پرامپت چیزی است که شما تایپ می‌کنید؛ زمینه کل چیزی است که مدل در پنجره‌ی زمینه می‌بیند — دستور سیستم، پیام کاربر، اسناد بازیابی‌شده، تعریف ابزارها، تاریخچه‌ی گفتگو و همه‌ی چیزهای دیگری که بین آن‌ها درج می‌شود. مدل زبانی حافظه‌ی پایدار ندارد؛ هر درخواست، این زمینه از نو ساخته می‌شود و مدل فقط با همان متن کار می‌کند. پس کیفیت پاسخ، تابع کیفیت کل این بسته است — نه فقط جمله‌ی آخر شما.
مهندسی زمینه یعنی همین طراحی: تصمیم‌گیری آگاهانه درباره‌ی اینکه در هر درخواست، چه چیزی، با چه شکلی و در چه ترتیبی جلوی مدل برود — و مهم‌تر، چه چیزی حذف شود. اگر تکنیک‌های پرامپت را نوشتن متن خوب بدانیم، مهندسی زمینه طراحی «میز کار» مدل است.
لایه‌های زمینه
یک درخواست واقعی در یک محصول معمولاً این لایه‌ها را دارد — و هر لایه قواعد خودش را:
دستور سیستم: قرارداد ثابت سرویس؛ هویت، قواعد، محدودیت‌ها. کوتاه، صریح و بدون تناقض — چون بالای همه‌چیز می‌نشیند. جزئیات را در مطلب پرامپت سیستمی خوانده‌اید. پیام کاربر: درخواست فعلی؛ بهتر است تمیز و بدون داده‌ی خام بهم‌ریخته باشد. داده‌ی بازیابی‌شده: خروجی RAG — اسناد، نتایج جستجو، رکوردهای دیتابیس. اینجا مهندسی واقعی اتفاق می‌افتد: هر سند باید برچسب منبع داشته باشد، جداکننده واضح باشد و فقط مرتبط‌ترین‌ها بیایند. پایه‌ی این کار را در RAG چیست می‌بینید.
تعریف ابزارها: اسکیمای توابعی که مدل می‌تواند صدا بزند — هر ابزار اضافه یعنی توکن و یعنی شاخه‌ی تصمیم بیشتر؛ شکل خوب تعریف ابزار مستقیم روی کیفیت فراخوانی تابع اثر می‌گذارد. تاریخچه‌ی گفتگو: با هر پیام رشد می‌کند و اگر مدیریت نشود، پنجره را می‌خورد. قالب خروجی: اگر برنامه‌ی شما جواب را می‌خواند، شکل خروجی هم بخشی از زمینه است — از خروجی ساختاریافته استفاده کنید تا قرارداد صریح باشد.
مهندسی زمینه یعنی برنامه‌نویسی با «حالت»: به‌جای کد، تصمیم می‌گیرید در هر لحظه دقیقاً چه چیزی جلوی چشم مدل باشد — و چه چیزی اصلاً نباشد.
بودجه‌ی پنجره‌ی زمینه
پنجره‌ی زمینه سقف توکن دارد — و حتی زیر سقف، فضای مفید محدود است. دو واقعیت را باید در طراحی حساب کنید: اول اینکه توکن‌ها هزینه‌اند و پردازش زمینه‌ی بزرگ هم کندتر است؛ دوم پدیده‌ی معروف «گم‌شدن در میانه» — مدل‌ها به اول و آخر زمینه دقت بیشتری می‌دهند تا وسطش. پس قرارداد خوب این است: مهم‌ترین چیزها ابتدا و انتهای زمینه، داده‌های حجیم در وسط با برچسب‌گذاری واضح، و دستور نهایی در انتهای پیام.
برای گفتگوهای طولانی دو الگو رایج است: خلاصه‌سازی تاریخچه — پیام‌های قدیمی را با خود مدل خلاصه می‌کنید و خلاصه را جای متن اصلی می‌گذارید — و برش با حفظ لنگرها: تصمیم‌ها و قراردادهای مهم گفتگو را به‌صورت فشرده نگه می‌دارید و بقیه را می‌اندازید. برای دانش بیرونی هم به‌جای بارگذاری کل سند، بازیابی هدفمند با پایگاه داده برداری. حساب توکن و هزینه‌ی این تصمیم‌ها را در راهنمای هزینه‌ی API ببینید.
اشتباه‌های رایج
چهار خطای پرتکرار که همه‌ی ما مرتکب می‌شویم: ریختن همه‌چیز — اگر مدل با ۵۰ سند بازیابی‌شده تنها بماند، خودش را گم می‌کند؛ انتخاب سخت‌گیرانه‌تر بهتر از فراوانی است. دستورهای متناقض — وقتی دستور سیستم و داده‌ی درج‌شده هر دو «حکم» می‌دهند، مدل وسط را می‌گیرد؛ مرز روشن بگذارید: داده اعلام می‌کند، دستور تصمیم می‌گیرد. اعتماد به داده‌ی غیرقابل‌اعتماد — هر متنی که از بیرون می‌آید می‌تواند خودش را دستور جا بزند؛ این حفره را جداگانه در تزریق پرامپت بررسی می‌کنیم. و تاریخچه‌ی بی‌پایان — که هم هزینه و هم افت کیفیت می‌آورد.
جمع‌بندی
مهندسی زمینه یعنی دیدنِ ورودی مدل به‌عنوان یک بسته‌ی مهندسی‌شده، نه یک جعبه‌سیاه که پرامپت می‌ریزیم توش: دستور سیستم قرارداد است، داده‌ی بازیابی‌شده با برچسب و مرز می‌آید، ابزارها کم و دقیق تعریف می‌شوند، تاریخچه مدیریت می‌شود و شکل خروجی صریح است. پرامپت خوب یک جمله‌ی خوب است؛ زمینه‌ی خوب یک سیستم است. برای شروع، سرویس خودتان را باز کنید و بپرسید: «در این درخواست، مدل دقیقاً چه می‌بیند؟» — جواب صادقانه‌ی همین سؤال، نقشه‌ی بهبود شماست. چارچوب کامل‌تر انتخاب ابزار و مدل را در راهنمای انتخاب مدل ببینید و برای تست روی کار واقعی، یک حساب بسازید.