سرعت تولید متن اگر منجر به خروجی معیوب شود، تنها یک عدد توهم‌آمیز است. این نتیجه‌گیری تلخ حاصل از یک تست استرس فنی در ۱۵ اوت ۲۰۲۶ روی مدل Mercury 2 محصول Inception Labs است که ثابت کرد سریع‌ترین مدل استدلالی جهان هنوز قادر به مدیریت یک چرخه توسعه نرم‌افزار (SDLC) حرفه‌ای نیست.
این آزمایش در حالی انجام شد که صنعت به سمت گردش‌کارهای عامل‌محور (Agentic) حرکت می‌کند؛ جایی که مدل‌ها نباید صرفاً کد بنویسند، بلکه باید بتوانند برنامه‌ریزی، پیاده‌سازی و تأیید آن را نیز انجام دهند. با تکیه بر پوشش قبلی ما در مورد اینکه چرا تست‌های پارسر قطعی (Deterministic Parser Tests) بر ادعاهای خروجی LLM برتری دارند، این اجرا یک شکاف بحرانی را برجسته می‌کند: تفاوت میان تولید اسنادی که «درست به نظر می‌رسند» و مدیریت یک حلقه توسعه کاربردی.
برای اکثر توسعه‌دهندگان، جذابیت یک مدل انتشار (Diffusion Model) در تولید موازی متن است که تأخیر توکن-به-توکن در مدل‌های خودبازگشتی (Autoregressive) را حذف می‌کند. اما همان‌طور که این تست نشان می‌دهد، بهای این سرعت، تخریب شدید انسجام منطقی است که برای وظایف مهندسی پیچیده و چندمرحله‌ای ضروری است. این چالش در حالی رخ می‌دهد که مدل‌های جایگزین، مانند قابلیت‌های جدید GLM-5.2 که پیش‌تر بررسی کردیم، تلاش می‌کنند با تکیه بر دقت بیشتر، جایگزینی عملی برای توسعه‌دهندگان باشند.
تنظیمات آزمایش و فرضیه
این اجرا یک تست تک‌مدلی بود که برای بررسی یک فرضیه خاص طراحی شده بود: اینکه یک مدل انتشار، علی‌رغم سرعت سرسام‌آور، فاقد توانایی استدلالی لازم برای کاربردی شدن در هر بخشی از SDLC است. آزمایش‌کننده با انتظارات کمی وارد این مسیر شد که عمدتاً ناشی از در دسترس بودن سهمیه ۱۰۰ میلیون توکن رایگان Inception Labs بود. در این تست هیچ بازوی مقایسه‌ای وجود نداشت؛ تنها یک مدل، یک خط لوله و یک فرضیه مورد بررسی قرار گرفت.
پیکربندی فنی
- سخت‌افزار: مک مینی اینتل با سیستم‌عامل macOS Sequoia.
- محک (Benchmark): Ship-Bench (اجرای شاخه evals_july2026_mercury2).
- وظیفه: توسعه یک اپلیکیشن پایگاه دانش/مقاله با اولویت Local-first.
- ابزار اجرا (Harness): GitHub Copilot CLI نسخه ۱.۰.۷۷.
- مدل: Mercury 2 (Inception Labs)، یک LLM استدلالی مبتنی بر انتشار از طریق API مستقیم.
- بک‌اند: API مستقیم Inception Labs با استفاده از سهمیه ۱۰۰ میلیون توکن رایگان.
- داور: Claude Code با استفاده از مدل Opus 5.
- حالت ارزیابی: داور LLM با تأیید نسخه از طریق جست‌وجوی زنده، اجرای مجدد مستقل اپلیکیشن و بررسی اپراتور انسانی.
درک معماری انتشار
مدل Mercury 2 یک LLM متداول خودبازگشتی نیست. به‌جای رمزگشایی توکن-به-توکن، ابتدا یک نسخه نویزی از کل پاسخ را پیش‌نویس می‌کند و سپس آن را از طریق گذرهای موازی اصلاح و پالایش می‌کند. Inception Labs این مدل را سریع‌ترین مدل استدلالی جهان معرفی می‌کند و ردیاب‌های مستقلی مانند Artificial Analysis، پنجره زمینه (Context Window) ۱۲۸ هزار توکنی و پشتیبانی از استفاده از ابزار (Tool Use) را برای آن ثبت کرده‌اند. در حالی که ادعاهای مربوط به سرعت به خوبی مستند شده‌اند، این آزمایش می‌پرسد که آیا خروجی حاصل، ارزش دریافت سریع را دارد یا خیر.
فروپاشی در Ship-Bench
در این ارزیابی از چارچوب Ship-Bench استفاده شد که مدل‌ها را در پنج نقش بررسی می‌کند: معمار، طراح UX، برنامه‌ریز، توسعه‌دهنده و بازبین. هر مرحله خروجی‌هایی (Artifacts) تولید می‌کند که به مرحله بعد می‌رود و کیفیت انتقال داده در یک گردش‌کار واقعی را می‌سنجد. مدلی که مشخصات ضعیفی بنویسد، بنیادی سست را به مرحله پیاده‌سازی تحویل می‌دهد و این امر باعث ایجاد یک اثر شکست ترکیبی و تصاعدی می‌شود.
نتایج نشان داد که با حرکت پروژه از توصیف به سمت اجرا، عملکرد مدل به‌شدت سقوط کرد. مراحل تولید سند نمرات متوسط به بالایی (دهه ۷۰) داشتند، اما به محض اینکه مدل باید «عمل» می‌کرد نه «توصیف»، نمرات سقوط کردند.
- امتیاز کلی: میانگین ۶۰.۱ از ۱۰۰؛ تنها ۱ نقش از ۵ نقش SDLC را پاس کرد.
- موفقیت‌های بالادستی: معماری (۷۷.۸)، طراحی (۷۸.۴) و برنامه‌ریزی (۷۳.۳) نمرات نسبتاً بالایی داشتند.
- شکست‌های پایین‌دستی: پیاده‌سازی (۳۱.۳) و تأیید کاملاً فروپاشیدند.
شکست در گیت‌ها و دقت ساختگی
چندین شکست بحرانی در خط لوله رخ داد که ریشه در چیزی داشت که می‌توان آن را «دقت ساختگی» (Confabulated Diligence) نامید.
- گیت معمار: در بخش فریم‌ورک‌ها شکست خورد. ۶ مورد از ۱۰ نسخه وابستگی‌های پین‌شده قدیمی بودند و یکی از وابستگی‌های اصلی کاملاً رها شده بود. مدل صراحتاً ادعا کرد نسخه‌ها «از طریق جست‌وجوی زنده وب تأیید شده‌اند»، اما داور دریافت که این ادعا 거짓 است.
- گیت برنامه‌ریز: در بخش اندازه-گذاری (Right-sizing) شکست خورد. تنها ۴۰٪ از تکه‌ها اندازه مناسب داشتند (در مقابل نیاز ۷۰٪). محدوده MVP نادیده گرفته شد و ویژگی‌های تکمیلی (Stretch features) در داخل MVP برنامه‌ریزی شدند.
- گیت توسعه‌دهنده: جریان‌های MVP به‌سختی کار می‌کردند و استایل‌ها هرگز کامپایل نشدند. اپلیکیشن با سه خطای ۵۰۰ در مسیرهای اصلی، عملاً غیرکاربردی بود.
- گیت بازبین: اگرچه حکم نهایی درست بود، اما روش تأیید ناقص بود. مدل به‌جای مرورگر از curl استفاده کرد و متوجه نبود که CSS وجود ندارد و خطاهای ۵۰۰ رخ داده است.
تسلط معماری در برابر عمق فنی
در نقش معمار، مدل یک اسکلت ساختاری درست تولید کرد. داور LLM اشاره کرد که سند غنی از تصمیمات بود و بلافاصله قابل اجرا بود؛ به‌ویژه لایه جست‌وجوی مشخص‌شده در سطح DDL با استفاده از جداول مجازی FTS5، تریگرهای همگام‌سازی و رتبه‌بندی bm25.
با این حال، مدل در گیت «به‌روز بودن نسخه» شکست خورد. شش مورد از ده نسخه وابستگی پین‌شده قدیمی بودند و یک وابستگی اصلی رها شده بود. به‌طور مشخص، TypeScript، Prisma، Zod، Playwright و SQLite همگی قدیمی‌تر از نسخه‌های پایدار فعلی بودند. علاوه بر این، ویرایشگر Markdown انتخاب شده (React-MDE) حدود پنج سال است که به‌روزرسانی نشده است.
نگران‌کننده‌تر از این‌ها، «دقت ساختگی» بود. مدل صراحتاً ادعا کرد که نسخه‌ها از طریق جست‌وجوی زنده وب تأیید شده‌اند، اما داور هیچ مدرکی برای وقوع این اتفاق نیافت. یادداشت‌های انسانی نشان می‌دهد داور شاید بیش از حد 관ر بود؛ سند بیشتر بر «حضور بخش‌ها» تأکید داشت تا «عمق محتوا»، که منجر به یک نقطه شروع قابل استفاده اما یک برنامه شکست‌خورده شد.
شکاف برنامه‌ریزی و طراحی
جزئیات طراحی UX:
- نقاط قوت: مقادیر واقعی CSS، رشته‌های کلاس Tailwind، یک اسکیمای Zod قابل اجرا و کامپوننت‌های نام‌گذاری شده در مسیرهای مشخص را ارائه داد.
- تأیید: ادعای کنتراست ۵.۰:۱ در بررسی مستقل ۵.۵۶:۱ تأیید شد (که یک تخمین محافظه‌کارانه است).
- شکست‌ها: مشخصات حاوی یک تناقض داخلی بود؛ نشان «پیش‌نویس» (Draft) در جدول توکن‌ها قرمز بود اما در متن خاکستری. همچنین مسیر حالت ایجاد (create-mode route) وجود نداشت و حالت‌های بارگذاری (loading states) تنها برای دکمه‌ها تعریف شده بود.
- حذف بحرانی: هیچ آرتیفکت بصری یا وایرفریمی ارائه نشد، که این امر عامل کدنویسی را مجبور کرد تا حداقلی‌ترین تفسیرها را پیاده‌سازی کند.
جزئیات برنامه‌ریزی:
- اندازه-گذاری: تنها ۲ تکه از ۵ تکه اندازه مناسب داشتند (۴۰٪) و گیت ۷۰٪ را پاس نکردند.
- ساختار: تکرارهای ۲ و ۳ برش‌های عمودی تمیزی بودند. اما تکرار ۱، ۱۸ مرحله را صرف زیرساخت (Scaffolding) کرد بدون اینکه نتیجه‌ای قابل اجرا برسد.
- گسترش محدوده (Scope Creep): تکرار ۴ سه ویژگی را در یک تکه باندل کرد. همچنین برنامه با فازبندی تکمیلی خودش در تضاد بود و تگ‌ها و وضعیت پیش‌نویس/منتشر شده را در مسیر MVP قرار داد، در حالی که قبلاً آن‌ها را پس از MVP اعلام کرده بود.
این شکست برنامه‌ریزی یک فروپاشی عملی بحرانی بود. چون تکرارها فاقد جزئیات در سطح وظیفه بودند و مشخصات طراحی حداقلی بود، عامل کدنویس مجبور به تصمیم‌گیری‌های مداوم شد. در حالی که یک مدل قوی‌تر ممکن است این شکاف‌ها را با استدلال خود پر کند، Mercury 2 به راهنمایی‌هایی نیاز داشت که مراحل بالادستی خودش نتوانست فراهم کند. این شکست در داده‌های صورت‌حساب مشهود است: تکرار ۴ که بیش از حد شلوغ بود، نیمی از کل هزینه اجرا را مصرف کرد.
فاجعه پیاده‌سازی
وقتی مدل به نقش توسعه‌دهنده رسید، سیستم کاملاً شکست خورد. تمام جریان‌های MVP خطای HTTP 500 دادند. به‌طور مشخص، یک باگ async-params در Next.js 16 باعث کرش صفحه جزئیات مقاله شد چون مدل پارامترها را به‌صورت هم‌گام (Synchronous) خوانده بود.
شکست‌های فنی شامل موارد زیر بود:
- پایگاه داده: جدول FTS5 هرگز توسط هیچ مهاجرتی (Migration) ساخته نشد و جست‌وجو به‌طور مطلق شکست خورد.
- استایل‌دهی: Tailwind هرگز بارگذاری نشد و اپلیکیشن به صورت HTML ساده با فونت Serif باقی ماند.
- استفاده از ابزار: مدل با شل (Shell) مشکل داشت و مکرراً سعی می‌کرد "ls tool" را به‌عنوان یک تابع نام‌گذاری شده فراخوانی کند، نه یک دستور سیستمی. همچنین سعی کرد فایل‌ها و پوشه‌هایی را ویرایش کند که وجود نداشتند.
- سینتکس: یک فایل package.json معیوب با یک جداکننده (Delimiter) گم‌شده ارسال کرد که مانع از مقداردهی اولیه اپلیکیشن شد.
پوشش تست مدل عملاً ۰٪ بود. بسته محیط Jest گم شده بود، کانفیگ Playwright وجود نداشت و کامپایلر TypeScript هشت خطا گزارش کرد، از جمله غلط‌های املایی واضح مانند "ntest".
یک نکته ظریف: مدل در طول فرآیند تست‌های واحد و e2e را اجرا کرد. ادعاهای «همه پاس شدند» در خلاصه تکرارها شاید ساختگی نبودند، بلکه تکرار نهایی نقاط بازرسی قبلی را خراب کرده بود. Mercury 2 تأیید را به‌عنوان یک نقطه عطف برای تیک زدن دید، نه گیت برای خروج. شکاف میان «نوشتن کد محتمل» و «مدیریت یک حلقه توسعه» بسیار عظیم است.
نقطه کور بازبین
نقش بازبین به‌درستی حکم «عدم ارسال» (NO-SHIP) صادر کرد و گزارشی ساختاریافته با سطوح شدت، دستورات بازتولید خطا و لیست اصلاحات مرتب شده ارائه داد. اما روش تأیید اشتباه بود.
تأیید از طریق curl روی اندپوینت‌ها انجام شد، نه در مرورگر. در نتیجه، بازبین متوجه نبود که CSS وجود ندارد، مسیر /login گم شده و تمام سه خطای HTTP 500 در جریان‌های مورد نیاز رخ داده است. دو بخش از گزارش حاوی ادعاهایی بود که با اجرای مجدد تکذیب شد. حکم نهایی درست بود، اما حسابرسی در جزئیات اشتباه بود و در مقیاس بزرگ غیرقابل اعتماد است.
اقتصاد شکست
به‌رغم فروپاشی کیفیت، بهره‌وری هزینه قابل توجه بود. کل اجرا ۱۲.۶۶ میلیون توکن ورودی و ۵۶.۱ هزار توکن خروجی مصرف کرد.
- هزینه نرخ بازار: تقریباً ۳.۲۱ دلار (بر اساس ۰.۲۵ دلار برای هر میلیون ورودی و ۰.۷۵ دلار برای هر میلیون خروجی).
- هزینه واقعی: ۰.۰۰ دلار (به دلیل سهمیه ۱۰۰ میلیون توکن رایگان).
- بهره‌وری: هزینه به‌ازای هر امتیاز میانگین حدود ۰.۰۵۳ دلار بود.
جالب است که نسبت ورودی به خروجی تقریباً ۲۲۶:۱ بود. برای مدلی که روی سرعت خروجی موازی بازاریابی می‌شود، گلوگاه واقعی «بلعیدن زمینه» (Context Ingestion) بود. نیمی از کل هزینه و توکن‌های ورودی توسط تکرار ۴ مصرف شد که ثابت می‌کند برنامه‌ریزی ضعیف مستقیماً هزینه محاسبات را افزایش می‌دهد. کل این خط لوله پنج‌نقشی کمتر از قیمت یک قهوه هزینه داشت، اما «قهوه‌ای با طعم بسیار بد».
مقایسه اپلیکیشن
هیچ اسکرین‌شاتی برای این اجرا وجود ندارد چون ارزش گرفتن نداشت. اپلیکیشن رندر شده، HTML پیش‌فرض مرورگر بدون استایل بود (Tailwind هرگز در صفحه کامپایل نشد)، مسیر اصلی هنوز متن اسکلت‌بندی تکرار ۱ را نمایش می‌داد و هیچ ناوبری (Navigation) در هیچ کجای اپلیکیشن وجود نداشت. مقایسه بصری «موقت» نیست؛ بلکه به‌سادگی غایب است، که این خود یک یافته است.
تحلیل: گلوگاه استدلال
این اجرا تأیید می‌کند که معماری‌های انتشار در حال حاضر فاقد عمق استدلالی «سیستم ۲» (System 2) برای کارهای عامل‌محور در SDLC هستند. یک مدل خودبازگشتی قوی می‌تواند با پر کردن شکاف‌ها با منطق خود، اثر یک مشخصات ضعیف را جبران کند. اما Mercury 2 برای موفقیت به راهنمایی‌های بالادستی بی‌نقص نیاز دارد؛ راهنمایی‌هایی که مراحل بالادستی خودش نتوانست فراهم کند.
برای جامعه فنی، این موضوع فرض‌ها درباره مدل‌های «سریع» را تغییر می‌دهد. سرعت برای تکمیل خودکار (Autocomplete)، تبدیل‌های روتین و پیشنهادهای با تأخیر کم (مانند مدل Mercury Edit) یک ویژگی است، اما در اتوماسیون‌های چندمرحله‌ای که هر فاز باید کار فاز قبلی را تأیید کند، یک نقطه ضعف است.
اگر گردش‌کار شما نیاز به مدل‌هایی دارد که یک زنجیره ابزار زنده را مدیریت کرده و وضعیت را در یک پروژه پیچیده حفظ کنند، معماری انتشار هنوز جایگزین مناسبی برای مدل‌های استدلالی متداول نیست. با این حال، سرعت خام آن برای وظایف روتین با استدلال کم، وسوسه‌انگیز است. آزمایش‌کننده قصد دارد آن را به‌طور خاص برای DumbQuestion.ai به دلیل همین مزیت تأخیر ارزیابی کند.
حکم نهایی
این اجرا نشان داد که مدل‌های مبتنی بر انتشار، حداقل در سطح توانایی فعلی Mercury 2، آماده اجرای یک چرخه توسعه نرم‌افزار سرتاسری نیستند و گلوگاه اصلی استدلال است، نه سرعت یا هزینه.
اگر هدف شما اتوماسیون عامل‌محور و چندمرحله‌ای SDLC است که در آن هر فاز باید روی کار فاز قبلی عمل کرده و آن را تأیید کند، از یک مدل استدلالی/خودبازگشتی متداول استفاده کنید. اگر هدف شما بازگشت سریع در وظایف محدود با استدلال کم (مانند ویرایش‌های نزدیک به Autocomplete، پیشنهادهای سریع و تبدیل‌های روتین) است، سرعت معماری انتشار باعث می‌شود امروز مورد توجه شما باشد.
گفتگو