تصور کنید مسئولیت یک پروژه حیاتی را پذیرفتهاید که مستنداتی ندارد و برنامهنویسانش سالهاست بازنشسته شدهاند؛ حالا کدها تنها شاهدِ زندهی منطقِ آن تیم هستند. در ۲۶ ژوئن ۲۰۲۶، راهنمایی در پلتفرم dev.to منتشر شد که نشان میدهد چطور توسعهدهندگان میتوانند با مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن، مثل کسی که میداند چطور از یک مشاور باتجربه بهترین جواب را بگیرد — کتابخانههای قدیمی را رمزگشایی کرده و معماری گمشدهی سیستم را بازیابی کنند.
کار با کدهای قدیمی یا همان Legacy Code، اغلب شبیه باستانشناسی است. شما احتمالاً با فریمورکهای منسوخ مواجه میشوید و باید در میان کدهایی مسیر خود را پیدا کنید که مستندات آنها هرگز نوشته نشده یا گم شده است. ممکن است خود را در موقعیتی بیابید که باید پروژهای بسیار مهم را نگهداری کنید، در حالی که تیم قبلی مدتهاست بازنشسته شدهاند. در این موارد، احتمالاً با کتابخانههایی روبرو میشوید که متعلق به دورانی هستند که حتی والدین شما با هم آشنا میشدند و همین موضوع درک کد را دشوار میکند. طبق گزارش dev.to، این محیطها ریسک بالای توهم (Hallucination) — حالتی که مدل با اطمینان چیزی میگوید که اصلاً وجود ندارد، شبیه دوستی که خاطرهای را اشتباه تعریف میکند — را ایجاد میکنند، به خصوص اگر پرامپتها بیش از حد مبهم باشند. برای حل این مشکل، این راهنما پیشنهاد میکند که از درخواستهای ساده به سمت «محدودیتهای زبانی ساختاری» حرکت کنید که فرآیند استدلال هوش مصنوعی را هدایت میکنند.
همانطور که در تحلیلهای پیشین ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، دقت خروجی مدل به شدت به کیفیت بستر متن وابسته است. این ضربالمثل قدیمی که «کد، خودِ مستندات است» اغلب درست است، اما تنها به شرطی که توسعهدهنده بتواند آن را تفسیر کند. وقتی مستندات وجود ندارد، استفاده از ابزارهای هوش مصنوعی به گزینهای اصلی برای درک این موضوع تبدیل میشود که پروژه اصلاً چگونه ایجاد و نگهداری شده است. این چالشها یادآور آن است که چرا تکیه صرف بر شهود در کدنویسی هوش مصنوعی میتواند منجر به شکست در مراحل نهایی پروژه شود. استفاده از تکنیکهای مهندسی پرامپت که از مقالات علمی استخراج شدهاند، به توسعهدهندگان کمک میکند تا محیطهای پیچیده را بهتر پیمایش کنند. این روشها بهویژه زمانی که با ابزارهای مبتنی بر خط فرمان (CLI) استفاده شوند، بسیار مؤثرتر هستند و اجازه میدهند تا این ابزارها بهطور یکپارچه با جریان کاری توسعه ادغام شوند.
بر اساس مستندات این آموزش در dev.to، پنج استراتژی کلیدی برای بهینهسازی بهرهوری هوش مصنوعی در سیستمهای میراثی وجود دارد:
پرامپتنویسی بدون نمونه (Zero-shot Prompting): این روش یعنی ارسال درخواستی برای اجرای یک وظیفه بدون ارائه هیچگونه اطلاعات اضافی یا مثالهای عملی در ورودی.
- مثال: درخواست از مدل برای ترجمه یک فایل
string.xmlکه حاوی رشتههای متنی رایج است، از انگلیسی به اسپانیایی. - کاربرد در کدهای قدیمی: شما میتوانید از هوش مصنوعی بخواهید فایلها و دایرکتوریهای پروژه را بررسی کند تا لیستی از نسخهی فعلی Node مورد استفاده و کتابخانههای مرتبط با آن را ارائه دهد.
- ریسک: اینها سادهترین پرامپتها برای ایجاد هستند، اما نتایج آنها به دلیل نبود محدودیتهای مشخص، میتواند پیشبینیناپذیر باشد.
- مثال: درخواست از مدل برای ترجمه یک فایل
پرامپتنویسی با چند نمونه (Few-shot Prompting): در این روش، پرامپت شامل یک یا چند جفت «ورودی و خروجی» مطلوب است که به مدل اجازه میدهد خروجی مورد نظر برای مقدار بعدی را استنتاج یا تقلید کند.
- مثال: ارائه مجموعهای از محدودیتها برای یک تقویم. اگر مدل بداند که شما پنجشنبه و جمعه شبهای این هفته و هفته آینده، و همچنین سهشنبه و چهارشنبه شبها برای سه هفته آینده (از دو هفته دیگر) مشغول هستید، میتواند روزی برای جلسه در چهار هفته آینده پیشنهاد دهد که با این محدودیتها تداخل نداشته باشد.
- ریسک: چون این پرامپتها طولانیتر و پیچیدهتر هستند، توسعهدهندگان باید حتماً پاسخ را بازبینی کنند، زیرا احتمال دارد مدل نتیجهی مطلوب را به اشتباه استنتاج کند.
زنجیره تفکر (Chain-of-Thought یا CoT): استفاده از مهارتهای زبانی مدل برای رسیدن به یک پاسخ صحیح از طریق هدایت آن توسط یک سری سؤالات منطقی؛ شبیه وقتی که به کودکی در انجام تکالیف مدرسه کمک میکنید تا گامبهگام پیش برود.
- مکانیسم: بهجای پرسیدنِ سادهی «چرا سیستم لاگین خراب است؟»، توسعهدهنده هوش مصنوعی را گامبهگام هدایت میکند.
- جریان کاری (Workflow): اول، متد احراز هویت (مثلاً OAuth 2.0) شناسایی شود. دوم، URLهای مربوط به سرور مجوز (Authorization) و سرور منابع (Resource) شناسایی شوند. سوم، تعیین شود که آیا سرور مجوز اعتبارنامهها را رد میکند یا سرور کاربر توکن معتبر را نمیپذیرد. در نهایت، کد برای یافتن دلایل احتمالی رد درخواست، مانند فرمتبندی اشتباه، تحلیل شود.
پرامپتنویسی دستوری (Instruction Prompting): تکنیکی که در آن کاربر توالی صریحی از مراحلی را ارائه میدهد که مدل «باید» دنبال کند. این کار مدل را در منطقهای پیچیده یا وظایف ریاضی هدایت میکند تا از بروز اشتباهات جلوگیری شود.
- کاربرد در خطاهای Build: این راهنما یک توالی سختگیرانه چهار مرحلهای را پیشنهاد میکند:
۱. بررسی کد پروژه برای یافتن فایلهای پیکربندی گمشده (مانند فایلهای .git، تنظیمات maven، gradle یا npm).
۲. بررسی نسخهی کد زبانها یا فریمورکهای اصلی (مانند ورژن JDK، ورژن Spring یا ورژن Angular).
۳. اسکن فایلها برای یافتن خطاهای سینتکسی مانند ایمپورتهای گمشده، فراخوانی اشتباه متدها یا نبود سمیکولونها.
۴. ایجاد یک خلاصهی جامع از تمام مشکلات یافت شده که به صورت خوانا و ساده ارائه شود.
- کاربرد در خطاهای Build: این راهنما یک توالی سختگیرانه چهار مرحلهای را پیشنهاد میکند:
پرامپتنویسی نقش-محور (Role Prompting): تخصیص یک شخصیت یا پرسونای خاص برای فیلتر کردن کیفیت خروجی و حذف پاسخهای احتمالی نادرست.
- حالت خبره (Expert Mode): دستور دادن به مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — برای اینکه به عنوان یک «مهندس نرمافزار ارشد با تخصص فولاستک» عمل کند. این کار تضمین میکند که پاسخها شبیه به مهندسی سطح بالا باشند، نه پیشنهاداتی در سطح یک برنامهنویس جونیور.
- حالت متخاصم (Adversarial Mode): واگذار کردن یک نقش متخاصم به هوش مصنوعی تا به توسعهدهنده کمک کند شکافها یا اشتباهات موجود در خط فکرم خود را شناسایی کند.
این رویکرد، نقش برنامهنویس را از یک کدنویس ساده به یک «ارکستراتور استدلال» تغییر میدهد. با اجرای زنجیره تفکر و پرامپتنویسی دستوری، مهندس مدل را مجبور میکند پیش از پیشنهاد هرگونه تغییر در کد، پیشفرضهای خود را بازبینی و تایید کند.
برای شما به این معناست که سدِ ورود به «کدهای اسپاگتی» بهشدت پایین میآید. بهجای هفتهها ردیابی دستی وابستگیها، میتوانید با استفاده از Claude CLI یا Gemini CLI معماری پروژه را در کسری از زمان نقشهبرداری کنید.
این تکنیکها بهطور مشخص ریسک وارد کردن باگهای جدید به سیستمهای قدیمی و شکننده را کاهش میدهند، زیرا مدل را ملزم میکنند پیش از پیشنهاد هر اصلاحیه، تحلیل خود را توضیح دهد.
شما میتوانید از همین امروز با اعمال توالی «پرامپتنویسی دستوری» روی سختترین خطای Build پروژهتان شروع کنید تا ببینید آیا یک رویکرد ساختاریافته میتواند پیکربندی گمشده را آشکار کند یا خیر.
گام بعدی شما
- امروز توالی «پرامپتنویسی دستوری» را روی سختترین خطای Build پروژهتان امتحان کنید تا ببینید آیا پیکربندی گمشدهای پیدا میشود یا خیر.
- برای تحلیلهای عمیقتر، نقش «مهندس ارشد» را در پرامپتهای خود ترکیب کنید تا خروجیهای جونیور حذف شوند.
- مدلهای CLI را برای دسترسی سریعتر به درخت فایلها در کنار مدلهای چت امتحان کنید.
اما داستان سختافزاری اجرای این مدلهای استدلالی روی سیستمهای محلی حتی شگفتانگیزتر است — به تحلیل ما دربارهی کوانتش وزنها مراجعه کنید.
گفتگو