حل مستقیم مسائل در برابر نمایش عملکرد در عامل‌های هوش مصنوعی

تصور کنید برنامه‌نویسی هستید که هر بار برای تغییر یک خط کد، باید ده صفحه فرم اجازه پر کند و ساختار پوشه‌ها را تایید کند. این دقیقاً همان اتفاقی است که حفاظ‌ها (Guardrails) — شبیه به نرده‌های ایمنی در کنار جاده که اجازه نمی‌دهند ماشین از مسیر خارج شود — با عامل‌های هوش مصنوعی می‌کنند.

به گزارش وب‌سایت dev.to در ۳۱ اوت ۲۰۲۶، یک توسعه‌دهنده در آزمایشی نشان داد که حذف پرامپت‌های سیستمی سخت‌گیرانه، مدل را از حالت «گزارش‌دهیِ تردید» خارج کرده و به سمت حل واقعی مشکلات معماری سوق می‌دهد. بسیاری از برنامه‌نویسان با پرامپت سیستمی (System Prompt) — دستورالعمل‌های بنیادینی که رفتار کلی مدل را تعیین می‌کنند — مانند یک قرارداد حقوقی برخورد می‌کنند. آن‌ها مدل را مجبور می‌کنند خروجی‌ها را دقیقاً در قالب JSON ارائه دهد، اختراع فایل‌های خیالی را ممنوع می‌کنند و برای هر دستور اجازه می‌گیرند. این رویکرد یک «قفس» ایجاد می‌کند که در آن مدل بیشتر از آنکه کد بنویسد، وقتش را صرف تایید ساختار فایل‌ها می‌کند.

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

سرعت عامل‌های بدون محدودیت

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

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

حل هدف به‌جای اجرای دستور

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

در یک مورد خاص، نویسنده بارها از هوش مصنوعی خواست تا مسیر تلاش مجدد (retry path) در یک سیستم پرداخت را وصله کند. تحت پرامپت‌های سخت‌گیرانه، مدل سه وصله تولید کرد که هر کدام از قبلی هوشمندانه‌تر بود اما هیچ‌کدام ریشه مشکل را حل نمی‌کردند.

اما بدون محدودیت‌ها، مدل رویکرد متفاوتی گرفت:

• مسیر مشکل‌ساز را به‌طور کامل حذف کرد.
• منطق تلاش مجدد را به Worker صف منتقل کرد.
• به‌جای درمان علامت، نقص معماری را حل کرد.

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

هزینه آزادی

حذف نرده‌ها باعث می‌شود شکست‌ها «بلندتر» و واضح‌تر شوند. جریان‌های کاری محدود، شکست را در قالب فرمت پنهان می‌کنند؛ چون خروجی شبیه یک برنامه حرفه‌ای است، مغز انسان آن را به عنوان یک برنامه پذیرفته است. اما خروجی بدون محدودیت، شبیه کسی است که بیش از حد به خود اعتماد دارد و ممکن است به‌راحتی فایلی به نام utils2.ts را اختراع کند.

این رفتار برای «تمام‌شده به نظر رسیدن» بهینه شده است، نه لزوماً «درست بودن». نویسنده به چند حالت شکست خاص اشاره کرد:

• اختراع زمینه: مدل ممکن است فرض کند یک فلگ بلااستفاده است، یک تست ناپایدار (flaky) است و باید نادیده گرفته شود، یا یک API از قبل فیلد خاصی را برمی‌گرداند.
• اصلاحات سطحی: یک بار مدل پیام خطا را بازنویسی کرد تا حرفه‌ای‌تر به نظر برسد، در حالی که خودِ باگ را دست‌نخورده باقی گذاشت.
• نادیده گرفتن سیستم: مدل ممکن است قانون محلی را رعایت کند اما قراردادهای ضمنی درباره پول، مناطق زمانی، تلاش‌های مجدد، Idempotency یا مجوزها را فراموش کند.

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

تغییر مهارت از پرامپت‌نویسی به «سلیقه»

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

• اشتباهات ارزان: نام‌گذاری بد متغیرها یا توابع کمکی که بیش از حد انتزاعی شده‌اند.
• اشتباهات گران: مهاجرت‌های اشتباه پایگاه‌داده، تغییر در میان‌افزار احراز هویت یا تغییر شکل APIهای عمومی.

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

حفاظ جدید: زمینه

بدون قانون، مدل آزاد نمی‌شود، بلکه «گرسنه» می‌شود. ممکن است فایل‌های تکراری را بخواند، تصمیمات ۱۲ مرحله قبل را فراموش کند و بحث‌های بسته شده را دوباره باز کند. نویسنده دریافت که یک «یادداشت کاری» (Working Note) کوتاه — یک یادداشت چسبان از آنچه درست است، آنچه در جریان است، آنچه رد شده و آنچه خارج از محدوده است — بسیار موثرتر از یک قانون اساسی پیچیده است.

علاوه بر این، او دیگر با چت مانند یک حافظه برخورد نمی‌کند. رشته‌های طولانی دچار انحراف می‌شوند و برنامه‌های رها شده را نیمه‌زنده نگه می‌دارند. شروع رشته‌های جدید با دستورالعمل‌های کوتاه و فایل‌های به‌روز، همواره بهتر از ادامه دادن گفتگوهای قدیمی بود.

کاربرد عملی در محصولات

این تنش در طراحی محصول نیز وجود دارد. نویسنده این رویکرد را در HelpByExperts (سامانه تطبیق متخصصان برای توصیه‌های حرفه‌ای) به کار گرفته است. هوش مصنوعی می‌تواند یک سوال را در چند ثانیه مسیریابی کند، اما نمی‌تواند حرف آخر را درباره یک بند اجاره، نقص سیم‌کشی یا ماشینی که بوت نمی‌شود بزند.

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

پشته نهایی

نویسنده تمام حفاظ‌ها را دور نریخت، بلکه آن‌ها را با نسخه‌ای سبک‌تر جایگزین کرد. او متوجه شد برای هر کاری از یک جلیقه ایمنی یکسان استفاده می‌کرد، چه برای یک تحقیق سریع (spike) و چه برای یک اصلاح فوری (hotfix).

قوانین غیرقابل مذاکره باقی‌مانده عبارت‌اند از:
۱. ممنوعیت مطلق دسترسی به اسرار (secrets)، محیط‌های عملیاتی و force-push.
۲. تست‌های اجباری برای هر کدی که منجر به ضرر مالی یا مسدود شدن کاربران شود.
۳. خواندن دستی تغییرات (diffs) به‌جای تکیه بر خلاصه‌های هوش مصنوعی.
۴. تعیین محدوده پیش‌فرض به‌صورت گلوله‌ای قبل از شروع ویرایش. اگر عامل بخواهد محدوده را گسترش دهد، باید صراحتاً در یک جمله درخواست کند تا انسان بتواند آن را رد کند.

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

گام بعدی شما

• در پروژه‌های بعدی، سعی کنید پرامپت‌های سیستمی را به حداقل برسانید و به‌جای دستور دادن به «نحوه فکر کردن»، روی «خروجی نهایی» تمرکز کنید.
• یک «یادداشت کاری» (Working Note) کوتاه برای هر تسک ایجاد کنید و در هر رشته چت جدید، آن را به مدل بدهید.
• بررسی‌های انسانی خود را از حالت یکنواخت خارج کنید؛ روی نقاط حساس (امنیت و دیتابیس) سخت‌گیر باشید و روی موارد ظاهری سخت‌گیری را رها کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.