«جایگزینی دستورالعمل‌های انتزاعی»؛ راهکار جدید برای رسیدن به کد تولید-آماده

تصور کنید برنامه‌نویسی هستید که باید ۶۰۰ ابزار وب مختلف را در ۵ زبان مدیریت کند؛ جایی که یک اشتباه کوچک در فاصلهٔ بین‌عناصر (Padding)، کل رابط کاربری را به‌هم می‌ریزد. در این مقیاس، گلوگاه اصلی بهره‌وری عوامل هوش مصنوعی، «مشخصات انتزاعی» (Abstract Specifications) هستند. با جایگزین کردن این مشخصات با مراجع زنده در محیط تولید (Production)، این توسعه‌دهنده توانست از خروجی‌هایی با «کیفیت ۸۰ درصدی» — که نیازمند چندین دور اصلاح بود — به کدی منتقل شود که در اولین تلاش، اساساً در سطح کیفیت محیط تولید است.

طبق گزارشی که در ۲۶ ژوئیه ۲۰۲۶ در وب‌سایت dev.to منتشر شد، توسعه‌دهندگان با پدیده‌ای به نام «فرسودگی مستندات» (Spec Rot) روبرو هستند. در واقع مستندات طراحی از لحظهٔ نوشته شدن با واقعیت فاصله می‌گیرند؛ زیرا تصمیمات کوچک اجرایی در حین کدنویسی — مانند یک مقدار خاص برای Padding یا استثناهای مربوط به موارد خاص (Edge-cases) — به‌ندرت به متن دستورالعمل بازمی‌گردند. این چالش در واقع ادامه مسیر تلاش‌هایی است که در توسعهٔ مبتنی بر مشخصات برای حذف توهمات هوش مصنوعی در کدنویسی دنبال می‌شد. در نتیجه، کلود کد (Claude Code) برای پر کردن این شکاف‌ها به توهم (Hallucination) — شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — روی می‌آورد و هر بار پاسخی متفاوت و ناسازگار می‌دهد.

زمینه و معماری

برای حل این مشکل، نویسنده معماری مهارت‌ها را از پایه بازسازی کرد. در این ساختار جدید، فایل مهارت تنها به عنوان یک «پوشش نازک» (Thin Wrapper) عمل می‌کند، در حالی که محتوای اصلی و substantive در یک کاتالوگ استاندارد و مرجع قرار می‌گیرد. این سیستم به‌طور خاص برای مقیاس‌های تولید انبوه طراحی شده است؛ چرا که ایجاد چنین کاتالوگی برای یک پروژه تک‌مقاصد یا کوچک، ناکارآمد و غیربهینه خواهد بود. این رویکرد یادآور راهکارهای مدرنی است که ابزارهایی مانند Repospec برای مدیریت دسترسی عامل‌های AI به مخازن مجزا ارائه داده‌اند.

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

بر اساس مستندات این پروژه، نویسنده یک معماری «مرجع-محور» (Reference-driven) را پیاده‌سازی کرد که شامل سه تغییر کلیدی است:

۱. ساختار مبتنی بر مرجع

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

• یک درخت تصمیم با سه پرسش، الگوی پیاده‌سازی را انتخاب می‌کند. گزینه‌ها شامل Canvas 2D مستقیم، html2canvas، dom-to-image، یک کتابخانه اختصاصی یا SVG خالص است.
• عامل دو مرجع عملیاتی از کاتالوگ انتخاب می‌کند: یکی برای استفاده به عنوان پایه (Base) و دیگری برای مقایسه تغییرات (Diffing).
• ردیف‌های کاتالوگ، شماره خطوط دقیق کد را ثبت کرده‌اند و به‌طور مشخص شناسایی می‌کنند که هسته رندر (Render Core) و مدیریت‌کننده دانلود (Download Handler) در کجا قرار دارند.
• عامل کد مرجع پایه را به‌طور کامل کپی کرده و سپس آن را بر اساس ساختار داده‌ای ابزار جدید اصلاح می‌کند.

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

۲. تفکیک مهارت‌های ساخت و تعمیر

ساخت ابزار جدید و رفع باگ به دو مجموعه مهارت مجزا تقسیم شده‌اند، زیرا نیازهای آن‌ها بنیاداً متفاوت است:

• ساخت (جدید): نیازمند یک قالب کامل و یک چک‌لیست جامع برای تأیید نهایی است.
• تعمیر (موجود): توسط یک گزارش خطا یا پرچم اعتبارسنج (Validator flag) هدایت می‌شود و نیازمند یک اصلاح نقطه‌ای است که فقط محدود به محیط اطراف علامت‌ها و symptoms است.

ترکیب این دو باعث می‌شود عامل برای هر تغییر کوچک، مجبور شود «مالیاتِ نادیده گرفتن بخش‌های نامرتبط» را بپردازد. از آنجا که پنجره متنی (Context Window) عامل محدود است، این فشار مستقیماً کیفیت خروجی را کاهش می‌دهد. در سیستم جدید، بخش تعمیر به عنوان یک «کشتی مادر» (Mothership) عمل می‌کند و خطاها را به دسته‌های خاصی ارجاع می‌دهد: شکست در چیدمان (Layout)، دقت خروجی تصویر، کیفیت ترجمه، قراردادهای دکمه‌ها، فاصله بین توصیف و پیاده‌سازی، یا تعاملات کاربر.

۳. اجبار مکانیکی

در حالی که مهارت‌ها دستورالعمل‌های توصیه‌گر ارائه می‌دهند، نویسنده برای اعمال محدودیت‌های مطلق از «قلاب‌های زمان نوشتن» (Write-time hooks) استفاده می‌کند. باید توجه داشت که یک فایل «مهارت» صرفاً یک سند رویه‌ای است و هیچ قدرت اجرایی یا اجباری برای متوقف کردن کد ندارد.

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

این معماری هزینه کیفیت را به ابتدای مسیر منتقل می‌کند. توسعه‌دهنده اشاره می‌کند که ساخت اولین مرجع باکیفیت، هزینه‌بر است و نگهداری کاتالوگ — مانند به‌روزرسانی شماره خطوط هنگام بازنویسی کد — نیازمند تلاشی مستمر است. با این حال، برای کسانی که ابزارها را به‌صورت انبوه تولید می‌کنند، این سبک هزینه برای جلوگیری از زوال دستورالعمل‌های مکتوب ضروری است. این سیستم بین آوریل و ژوئن ۲۰۲۶ تأیید شده است.

این رویکرد فرضیه قدیمی را می‌شکند که «پرامپت بهتر یا مستندات دقیق‌تر منجر به کد بهتر می‌شود». در جریان‌های کاری عامل‌محور، معتبرترین مرجع (Ground Truth) نه آنچه به هوش مصنوعی می‌گوییم، بلکه کدی است که همین حالا در محیط تولید به‌درستی کار می‌کند.

گام بعدی شما

• فایل‌های مهارت (Skill files) فعلی خود را بررسی کنید و هر کجا دستورالعمل انتزاعی دارید، آن را با لینک مستقیم به یک اثر عملیاتی جایگزین کنید.
• مهارت‌های «ساخت» و «تعمیر» را در سیستم خود تفکیک کنید تا از اتلاف توکن‌های پنجره متنی جلوگیری شود.
• برای محدودیت‌های حیاتی کد، به جای پرامپت‌نویسی، از ابزارهای مکانیکی مانند Hook یا Linter استفاده کنید.

اما اثر این معماری بر هزینه‌های استنتاج در مقیاس میلیونی حتی تکان‌دهنده‌تر است — به تحلیل ما درباره‌ی بهینه‌سازی GPU مراجعه کنید.