اگر امروز از عاملهای کدنویس برای توابع کوچک استفاده میکنید، احتمالاً متوجه شدهاید که آنها بهجای ۱۵ خط کد، یک پلتفرم کامل به شما تحویل میدهند. این «مهندسی مفرط» (Over-engineering) باعث میشود زمان صرفشده برای اصلاح کد از زمانِ خودِ کدنویسی بیشتر شود.
به گزارش وبسایت dev.to در ۹ جولای ۲۰۲۶، یک توسعهدهنده مستند کرده است که درخواست سادهاش برای «خودکارسازی ارسال ایمیل»، با پیشنهادی شامل سه سطح اتوماسیون، چهار کانال ارتباطی و سه آستانه ریسک پاسخ داده شده است. این رفتار نتیجهای از یک ناهماهنگی سیستمی در آموزش است؛ مدلهای زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — بهگونهای آموزش دیدهاند که «کامل بودن» پاسخ را به «کوتاه بودن» ترجیح دهند. به همین دلیل، مدل یک درخواست ساده را شبیه به یک کارگاه معماری سطح بالا میبیند.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، تمایل مدلها به ارائه پاسخهای جامع، گاهی منجر به ایجاد پیچیدگیهای غیرضروری میشود که سطح حمله را افزایش میدهد.
بر اساس مستندات این گزارش، توسعهدهنده مذکور برای رسیدن به نتیجه مطلوب، سه چرخه بازبینی را طی کرد:
- مرحله اول: درخواست سادهسازی؛ اما مدل همچنان چهار لایه اضافی و یک دوره گرمکردن سه هفتهای را پیشنهاد داد.
- مرحله دوم: تعیین ضربالاجل یکروزه؛ مدل در پاسخ، یک داشبورد لحظهای و منطق تلاش مجدد نمایی اضافه کرد.
- مرحله سوم: پرسش درباره علت پیچیدگی؛ مدل در نهایت اعتراف کرد که دچار مهندسی مفرط شده است.
خروجی نهایی یک تابع تمیز در TypeScript بود که تنها سه شرط را بررسی میکرد. طبق گزارش dev.to، ۹۰ دقیقه زمان صرف بازنویسی درخواستها و ۶ ساعت صرف کدنویسی شد؛ یعنی هزینه گفتگو از هزینه تولید کد پیشی گرفت.
این الگو نشان میدهد مدلها در حالت «پلتفرم» (Platform Mode) عمل میکنند. وقتی درخواستی شبیه به سوالات معماری به نظر برسد، مدل بهطور پیشفرض به دنبال حداکثر جامعیت میرود. اگر برای یک کار ساده بیش از سه بار نیاز به اصلاح پرامپت داشته باشید، بهرهوری شما در آن روز کاری عملاً از بین میرود. این چالش در مدیریت خروجیها، اهمیت انتخاب استراتژی صحیح تعامل با مدل را دوچندان میکند؛ موضوعی که در بررسی جامع روشهای استقرار AI و مقایسه پرامپتینگ با RAG به تفصیل به آن پرداختهایم تا بهینه ترین مسیر برای کسب نتایج دقیق مشخص شود.
برای عبور از این تله، باید ذهنیت «مشاور» را در مدل ممنوع کنید. تغییر رویکرد از «چگونه این کار را انجام دهم» به «نسخه مینیمال را در X خط بده»، مانع از لغزش مدل به سمت طراحیهای سازمانی پیچیده میشود.
گام بعدی شما
- در ابتدای پرامپت خود این محدودیت سخت را قرار دهید: «نسخه مینیمال را در ۱۵ خط پیشنهاد بده. بدون ماتریس. بدون فازبندی. توسعهها را در ادامه و جداگانه بیاور».
- از مدل بخواهید قبل از کدنویسی، ابتدا «سادهترین مسیر ممکن» را توصیف کند.
- اگر مدل وارد چرخه پیچیدگی شد، بلافاصله گفتگو را قطع کرده و با یک محدودیت عددی (تعداد خط) درخواست را تکرار کنید.
اما تأثیر این محدودیتها بر کیفیت نهایی کد در بلندمدت هنوز ابهام دارد — به بررسی ما دربارهی معیارهای Pass@k برای سنجش صحت کدها مراجعه کنید.
گفتگو