اگر ساعاتی را صرف دیباگ کردن کدهایی میکنید که در ظاهر درست بودند اما در محیط عملیاتی شکست خوردند، باید روش تعامل خود با مدلها را تغییر دهید. یک قالب پرامپت دوجانبه از شرکت QuackBuilds میتواند چرخه تولید کدهای توهمزده را متوقف کند.
بسیاری از برنامهنویسان با مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — مانند یک جعبه جادویی رفتار میکنند که باید فوراً پاسخ دهد. این رویکرد منجر به «دید تونلی» میشود؛ وضعیتی که مدل با عجله به سراغ پیادهسازی میرود و نقصهای معماری را نادیده میگیرد. برای حل این چالش، QuackBuilds در ۲۶ جولای ۲۰۲۶ چارچوب شناختی «ناظر و همدست» (Observer & Accomplice) را معرفی کرد. این رویکرد در واقع پاسخی به تغییرات سریع در بازار کار است؛ جایی که دیگر صرفاً توانایی پرامپتنویسی برای بقای شغلی برنامهنویسان کافی نیست و مهارتهای عملیاتی جدید جایگزین شدهاند.
بر اساس مستندات منتشرشده در dev.to، این مکانیزم بر پایه دو شخصیت (Persona) مجزا بنا شده است:
- ناظر (Observer): بر تحلیل استراتژیک سطح بالا و ارزیابی انتقادی تمرکز دارد. وظیفه این نقش، شناسایی گلوگاههای احتمالی و اطمینان از درست بودن مسیر کلی است.
- همدست (Accomplice): مسئول اجرای جزئیات است. این نقش بازخوردهای استراتژیک ناظر را به کدهای concrete یا راهکارهای گامبهگام تبدیل میکند.
همانطور که در تحلیل قبلی ما دربارهی زنجیره تفکر مدلهای استدلالی اشاره کردیم، جداسازی این دو نقش یک «بازبینی همتا» (Peer Review) مصنوعی در دل یک جلسه چت ایجاد میکند. به جای خروجی خطی، با یک حلقه مواجه میشوید که در آن ناظر طرح را نقد کرده و همدست خروجی را اصلاح میکند. این روش بهویژه در چرخههای مهندسی سریع که یک اشتباه در فرض اولیه معماری میتواند ساعتها زمان دیباگ تلف کند، حیاتی است. اتخاذ چنین متدهایی در واقع بخشی از موجی است که تعریف «کد خوب» را از منطق صرف برنامهنویسی به قابلیت نگهداری AI تغییر داده است.
به گزارش منابع فنی، این تغییر به معنای گذار از «پرامپت برای پاسخ» به «پرامپت برای فرآیند» است. نتیجه این کار، افزایش محسوس کیفیت خروجی و کاهش نرخ توهم (Hallucination) — زمانی که مدل با اطمینان چیزی میگوید که وجود ندارد، شبیه دوستی که خاطرهای را اشتباه تعریف میکند — در وظایف پیچیده توسعه است.
برای پیادهسازی این متد، کاربران باید جلسات خود را با تعریف دقیق این دو نقش در پرامپت سیستمی (System Prompt) آغاز کنند. پیشنهاد میشود تعداد تکرارهای لازم توسط ناظر پیش از شروع کدنویسی توسط همدست را رصد کنید تا پیچیدگی پروژه خود را بسنجید.
گام بعدی شما
- در پروژه بعدی خود، ابتدا نقش Observer را برای تحلیل معماری تعریف کنید و اجازه ندهید مدل کد بزند تا تأییدیه نهایی صادر شود.
- تفاوت کیفیت کد تولید شده با روشهای سنتی را در یک تسک پیچیده بسنجید.
- بررسی کنید که آیا این متد باعث کاهش تعداد توکنهای مصرفی در بازبینیهای طولانی میشود یا خیر.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو