سیستم چهارخطی برای حذف توهم و خطاهای عامل‌های هوش مصنوعی

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

به گزارش وب‌سایت dev.to در ۹ سپتامبر ۲۰۲۶، یک توسعه‌دهنده چارچوبی ساختاریافته را معرفی کرده است که پرامپت‌های طولانی و پراکنده را با مجموعه‌ای از محدودیت‌های سخت جایگزین می‌کند. در واقع، این رویکرد به جای گفتگو با مدل، با آن مانند یک سند مشخصات فنی برخورد می‌کند. این رویکرد ساختاریافته شباهت زیادی به گردش‌کارهای مبتنی بر Markdown دارد که از فرسودگی ذهنی برنامه‌نویسان می‌کاهد.

بسیاری از کاربران با هوش مصنوعی زاینده (Generative AI) — شبیه به دستیاری که هر چه بگویید انجام می‌دهد اما گاهی منظور شما را اشتباه می‌فهمد — به صورت محاوره‌ای صحبت می‌کنند. این کار باعث می‌شود مدل مجبور شود درباره مخاطب یا معیار موفقیت حدس بزند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی مهندسی پرامپت اشاره کردیم، حذف حدس‌زنی مدل، کلید رسیدن به خروجی دقیق است.

این چارچوب از چهار کلید اصلی تشکیل شده است:

• WHO (کی): تعریف مخاطب هدف (مثلاً: «برنامه‌نویس ارشد بک‌اند که با استک احراز هویت ما آشناست»). این کار مانع از تولید کدهای بیش از حد ساده یا پیچیده می‌شود.
• DONE (چه زمانی تمام است): یک جمله واحد که خط پایان را تعریف می‌کند. اگر هدف در یک جمله نمی‌گنجد، یعنی شما در واقع دو وظیفه مجزا دارید.
• NEVER (هرگز): فهرستی از محدودیت‌های سخت بر اساس شکست‌های قبلی (مثلاً: «به فایل‌های Migration دست نزن» یا «کتابخانه جدید اضافه نکن»). این رویکرد برای جلوگیری از پیچیدگی‌های غیرضروری مشابه فلسفه کدنویسی حداقلی در Ponytail است که مانع از مهندسی بیش از حد (Over-engineering) می‌شود.
• NEXT (بعدی): یادداشتی برای کاربر انسانی تا بداند بعد از اجرای تسک، گام بعدی چیست تا زمینه (Context) در وقفه‌های کاری گم نشود.

طبق اعلام نویسنده، این تغییر در گردش کار، فرآیند عیب‌یابی را دگرگون می‌کند. وقتی یک عامل (Agent) — مثل کارمندی که می‌تواند ابزارها را به طور مستقل اجرا کند — شکست می‌خورد، دیگر نیازی به تغییرات تصادفی در پرامپت نیست؛ بلکه کافی است خروجی را با این چهار خط مقایسه کنید تا نقطه دقیق خطا پیدا شود. این دقت در مدیریت تسک‌ها به طور مستقیم با جلوگیری از پوسیدگی زمینه (Context Decay) مرتبط است تا بازدهی عامل‌های کدنویسی افزایش یابد.

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

گام بعدی شما

• سه مورد از آخرین پرامپت‌های شکست‌خورده خود را بررسی کنید و ببینید کدام یک از این چهار خط (WHO, DONE, NEVER, NEXT) در آن‌ها غایب بود.
• برای تسک‌های پیچیده، ابتدا بخش NEVER را بر اساس تجربه دفعات قبل بنویسید.
• سعی کنید تعریف DONE را به یک جمله کوتاه محدود کنید تا ابهام در هدف از بین برود.

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