تصور کنید برنامه‌نویسی باشید که ایده‌ای را در یک پرامپت می‌نویسد و ۱۰ دقیقه بعد، یک اپلیکیشن تست‌شده و آماده‌ی اجرا روی سیستمش می‌بیند. این رویای «تک‌کلیک برای ساخت اپلیکیشن» اکنون با مدل ۴ میلیاردی Mano-AFK به واقعیت نزدیک‌تر شده است.
طبق گزارش Mininglamp، این چارچوب می‌تواند دستورات متنی را مستقیماً به اپلیکیشن‌های مستقر تبدیل کند و در انجام وظایف تست مرورگر بدون دخالت انسان، به صحت ۵۸ درصدی دست یابد. این دستاورد در حالی رخ می‌دهد که توسعه‌دهندگان به دنبال عبور از مرحله‌ی ساده‌ی «تولید کد» و رسیدن به «خودمختاری کامل چرخه تولید» هستند. این رویکرد در واقع گامی است به سوی ساخت سیستم‌عامل‌های هوش مصنوعی در SaaS که به جای پرامپت‌های تک‌مرحله‌ای، بر مدیریت کل چرخه عملیاتی تمرکز دارند.
شکاف میان نوشتن یک پرامپت و عرضه محصول همچنان عمیق است؛ چراکه تولید کد توسط مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — تنها نیمی از راه است و نیمی دیگر، تست و استقرار بدون نظارت انسان است. همان‌طور که در تحلیل قبلی ما درباره‌ی تبدیل شدن مک‌های اپل به نیروگاه‌های هوش مصنوعی اشاره کردیم، Mano-AFK از حافظه یکپارچه تراشه‌های سری M برای اجرای مدل‌های بینایی-زبانی (VLA) به‌صورت محلی استفاده می‌کند تا تأخیر و هزینه‌ی مدل‌های ابری را در تکراری‌ترین بخش‌های حلقه توسعه حذف کند.
خط لوله‌ی خودمختار
به نقل از مستندات این پروژه، Mano-AFK در یک زنجیره چندمرحله‌ای عمل می‌کند. ابتدا پرامپت را به یک سند جامع نیازمندی‌های محصول (PRD) تبدیل کرده، سپس کد را تولید و به‌صورت محلی مستقر می‌کند. پس از آن، یک مجموعه تست سه‌لایه فعال می‌شود:
- بررسی‌های Lint: اسکن برای خطاهای نوشتاری و استایل کد.
- تست‌های API: اعتبارسنجی عملکرد نقاط اتصال (Endpoints).
- تست‌های E2E مرورگر: اعتبارسنجی کامل تجربه کاربری از ابتدا تا انتها.
اگر هر مرحله‌ای شکست بخورد، سیستم وارد «حلقه اصلاح» می‌شود؛ خطا را می‌خواند، بستر را تحلیل می‌کند و کد را وصله می‌زند تا تست‌ها دوباره اجرا شوند. برای تضمین کیفیت، یک عامل (Agent) — شبیه به بازرسی سخت‌گیر در خط تولید — محصول نهایی را برای یافتن موارد خاص (Edge Cases) که مجموعه تست از آن‌ها غافل شده است، بازبینی می‌کند.
عملکرد محلی و بنچمارک‌ها
کاربران می‌توانند بین مدل ابری Claude CUA یا مدل محلی ۴ میلیاردی VLA انتخاب کنند. مدل محلی به‌طور خاص برای اجرا روی سخت‌افزار اپل سیلیکون طراحی شده است. بر اساس گزارش منتشر شده، مدل محلی با استفاده از کوانتایزیشن (Quantization) W8A16 به صحت ۵۸.۰٪ در محک CUA رسید.
وقتی سرعت از طریق Cider SDK و با استفاده از کوانتایزیشن W8A8 بهینه شد، صحت به ۵۴.۰٪ کاهش یافت اما سرعت پیش‌پُرکردن (Prefill) به حدود ۱,۴۵۳ توکن (Token) — تکه‌های کوچکی از متن شبیه برش‌های کیک — در ثانیه رسید. این افت ۴ درصدی، موازنه‌ای است که به توسعه‌دهنده اجازه می‌دهد بسته به مقیاس پروژه، بین دقت بالا یا سرعت تکرار سریع، یکی را انتخاب کند.
باید توجه داشت که تفاوت مهمی بین مدل‌ها وجود دارد. پروژه مادر یعنی Mano-P دارای یک مدل ۷۲ میلیاردی است که با کسب امتیاز ۵۸.۲٪ در OSWorld، رتبه اول را در میان مدل‌های تخصصی به دست آورد. با این حال، آن مدل ۷۲ میلیاردی متن‌باز نیست و مدل ۴ میلیاردی همان چیزی است که کاربران در واقعیت به‌صورت محلی اجرا می‌کنند.
نقاط قوت و دستاوردها
تولید PRD به‌طور شگفت‌انگیزی قدرتمند است. برای پرامپتی مثل «یک ردیاب زمان پروژه با داشبوردهای تیمی بساز»، عامل مستندی کاربردی تولید کرد که پروژه را به ویژگی‌های مجزا تقسیم می‌کرد، نقاط اتصال API را تعریف می‌نمود و مدل‌های داده را برنامه‌ریزی می‌کرد؛ کاری که طبق ادعای تیم سازنده، برای یک برنامه‌نویس جونیور معمولاً چند ساعت زمان می‌برد.
حلقه اصلاح نیز در رفع باگ‌های «محلی» بسیار مؤثر است. این سیستم توانست حدود ۷۰٪ از مسائل مربوط به خطاهای سینتکس، ایمپورت‌های فراموش‌شده، تعریف‌های نادرست مسیر (Route) و نام‌های اشتباه متغیرها را بدون دخالت انسان شناسایی و وصله بزند.
مرحله بازبینی خصمانه نیز ارزش غیرمنتظره‌ای ایجاد کرد. در یک مورد، این عامل نبودِ اعتبارسنجی ورودی در یک فیلد عددی فرم را شناسایی کرد؛ جزئیات کوچکی که در جریان‌های کاری دستی اغلب نادیده گرفته شده و به محیط عملیاتی (Production) راه می‌یابند.
نقاط شکست و محدودیت‌ها
تست‌های E2E همچنان گلوگاه اصلی هستند. مدل ۴ میلیاردی اغلب در مواجهه با رابط‌های کاربری پویا شکست می‌خورد؛ مواردی مانند المان‌هایی با نشانگرهای بارگذاری (Loading Spinners)، انیمیشن‌ها یا اجزایی که پس از رندر شدن تغییر موقعیت می‌دهند. چون مدل بر پایه بینایی است و به‌طور لغوی به صفحه «نگاه» می‌کند، هر تغییر در چیدمان بین لحظه اسکرین‌شات و لحظه اقدام، باعث می‌شود عامل روی هدف اشتباه کلیک کند. برای مقابله با این چالش‌های بصری، برخی رویکردها مانند استفاده از JSON به جای کد پیشنهاد شده‌اند تا ریسک خطاهای رابط کاربری کاهش یابد.
جریان‌های متوالی پیچیده نیز باعث خطا می‌شوند. در حالی که یک مسیر ساده «ساخت حساب، ورود، مشاهده داشبورد» جواب می‌دهد، یک فرآیند هفت‌مرحله‌ای — مانند ساخت حساب، ورود، ایجاد پروژه، افزودن سه تسک، تخصیص یکی از آن‌ها به عضو تیم و در نهایت خروجی گرفتن از گزارش — اغلب در گام هفتم به رفتارهای بی‌معنی منجر می‌شود.
اصلاحات ساختاری در برابر اصلاحات موضعی
این حلقه اصلاح جادویی نیست. سیستم در وصله زدن علائم عالی است اما در بازنگری معماری شکست می‌خورد. برای باگ‌های مستقیم و ساده مثل وابستگی‌های فراموش‌شده یا تنظیمات اشتباه پورت، حلقه اصلاح بی‌نقص عمل می‌کند.
اما اگر طراحی اولیه معیوب باشد — مثلاً انتخاب یک ساختار داده اشتباه یا ایجاد یک Race Condition در جریان‌های Async — حلقه اصلاح صرفاً علائم را ماسک می‌کند. در یک مورد مشاهده شده، عامل ۶ بار تلاش کرد تا یک نقص بنیادی در طراحی را اصلاح کند، اما هر بار فقط وصله‌های سطحی زد تا اینکه در نهایت فرآیند به‌صورت دستی متوقف شد. این موضوع یادآور خطاهای فنی رایجی است که اپلیکیشن‌های ساخته‌شده با هوش مصنوعی را در محیط عملیاتی با شکست مواجه می‌کند.
یادگیری بلندمدت و مرز خودمختاری
Mano-AFK از لایه‌ای برای ماندگاری داده‌ها در فایل‌های rules.md و preferences.md استفاده می‌کند. این فایل‌ها در پروژه‌های مختلف باقی می‌مانند. پس از اجرای حدود ۵ پروژه، عامل به‌طور خودکار شروع به پذیرش قراردادهای خاص تیم (مانند ساختارهای Tailwind CSS یا فرمت‌های خاص پاسخ API) کرد، بدون اینکه نیاز باشد صراحتاً در پرامپت به آن‌ها اشاره شود.
پس از اجرای بیش از ۳۰ پروژه، تیم سازنده به یک «نقطه بهینه» رسید. اپلیکیشن‌های ساده CRUD، صفحات فرود (Landing Pages) و ابزارهای داخلی که در آن‌ها «مسیر خوش‌بینانه» (Happy Path) اولویت دارد، در بیشتر مواقع بدون دخالت انسان کار می‌کنند.
اما نرخ موفقیت به‌شدت افت می‌کند زمانی که موارد زیر اضافه شوند:
- مدیریت وضعیت (State Management) پیچیده
- ویژگی‌های آنی (Real-time)
- جریان‌های احراز هویت شخص ثالث (Third-party Auth)
- معماری‌های توزیع‌شده
در واقع، شما می‌توانید پروژه را توصیف کنید، ۱۰ دقیقه دور شوید و در ۶۰٪ مواقع با چیزی برگردید که کار می‌کند. برای ۴۰٪ باقی‌مانده، سیستم یک نقطه شروع محکم با تست‌های از پیش نوشته شده ارائه می‌دهد.
برای تست این سیستم، به یک مک M4 با ۳۲ گیگابایت رم نیاز است و کدها تحت لایسنس Apache 2.0 در گیت‌هاب سازمان Mano-P در دسترس است. این تغییر نشان می‌دهد که در حالی که «اپلیکیشن‌های تک‌کلیکی» برای ابزارهای ساده ممکن است، سیستم‌های پیچیده همچنان به یک معمار انسانی نیاز دارند. ارزش کار اکنون از «نوشتن کد» به «حسابرسی انتخاب‌های معماری عامل» تغییر کرده است.
گام بعدی شما
- اگر کاربر مک M4 هستید، ابزار را از طریق Homebrew با دستور
brew install Mininglamp-AI/tap/mano-afkنصب کنید. - برای پروژه‌های کوچک (Internal Tools)، سعی کنید ابتدا PRD را توسط مدل تولید کرده و سپس اجازه دهید چرخه تست را اجرا کند.
- روی نقاط شکست مدل در UIهای پویا نظارت کنید تا متوجه شوید کجا باید دخالت انسانی را جایگزین کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو