تصور کنید می‌خواهید ابزاری بسازید که نه تنها کد می‌نویسد، بلکه آن را اجرا کرده و نتیجه را همان لحظه به کاربر نشان می‌دهد. چالش اصلی در ساخت کلونی از سرویس Lovable، نه در انتخاب مدل زبانی، بلکه در مدیریت زیرساخت مورد نیاز برای اجرا، بیلد و پیش‌نمایش کدهای ناشناخته در زمان واقعی است.
برای اینکه یک مدل بتواند فایل‌ها را بنویسد، وابستگی‌ها را نصب کند، بیلدها را بررسی کند و یک سرور پیش‌نمایش را اجرا کند، به یک فضای کاری اختصاصی برای هر پروژه مشتری نیاز دارد. با برون‌سپاری این اجرا به سندباکس‌های Lizard (Lizard Sandboxes)، یک توسعه‌دهنده اکنون می‌تواند در کمتر از ۸ ساعت یک MVP کاربردی برای ساخت اپلیکیشن‌های هوش مصنوعی عرضه کند. این رویکرد مشابه راهکاری است که پلتفرم Plimsoll برای ایجاد محیط‌های ایزوله جهت اجرای امن کدهای پایتون در عامل‌های Trigger.dev به کار گرفته است.
همان‌طور که در تحلیل قبلی ما درباره‌ی استفاده‌ی Lizard از میکرو-ماشین‌های مجازی Firecracker برای قدرت بخشیدن به عامل‌های هوش مصنوعی قابل بازگشت (resumable) اشاره کردیم، این پیاده‌سازی عملی نشان می‌دهد چگونه می‌توان بدون مدیریت یک ناوگان سرور، از یک پرامپت به یک URL پیش‌نمایش HTTPS زنده رسید. در این مدل، بک‌اند شما از طریق SDK لایزرد (Lizard SDK) فضای کاری را می‌سازد، فایل‌ها را ارسال می‌کند، دستورات را اجرا کرده و یک لینک پیش‌نمایش خصوصی بازمی‌گرداند. برای توسعه‌دهنده‌ای که با React و Node.js آشناست، سد ورود به بازار SaaSهای تولید نرم‌افزار اکنون اساساً به مسئله ارکستراسیون APIها تبدیل شده است، نه پیچیدگی‌های DevOps. این تغییر در پارادایم مدیریت زیرساخت، یادآور ترکیب Burrowbox و Vercel برای پایدارسازی گردش‌کار عامل‌های هوش مصنوعی است که بر حذف پیچیدگی‌های عملیاتی تأکید دارد.
گردش‌کار اجرا
به نقل از یک راهنمای فنی منتشر شده در ۱۵ اکتبر ۲۰۲۶، این فرآیند بر Lizard SDK (v0.1.69) برای ایجاد فضاهای کاری ایزوله متکی است. در یک تست عملیاتی (smoke test) که در همان تاریخ در منطقه us-east-1 انجام شد، سیستم تقریباً ۲۲ ثانیه زمان برد تا از لحظه ایجاد سندباکس به یک پیش‌نمایش فعال برسد. این بازه زمانی شامل نصب Node.js و npm، آپلود یک قالب اولیه (starter template)، نصب وابستگی‌ها و بیلد نهایی اپلیکیشن بود.
برای تضمین امنیت و پایداری، این گردش‌کار از سندباکس‌های کوچک Firecracker استفاده می‌کند. این محیط‌ها برای هر پروژه یک هسته (Kernel) اختصاصی فراهم می‌کنند تا تضمین شود کدهای تولیدشده از میزبان و سایر کاربران کاملاً ایزوله هستند. این راهنما بر یک بررسی سخت‌گیرانه در زمان اجرا (runtime check) تأکید می‌کند تا تایید شود محیط واقعاً Firecracker است و سپس اسکریپت‌های بیلد اجرا شوند. نتایج تست ۱۵ اکتبر قابلیت‌های کلیدی زیر را تایید کرد:
- نصب وابستگی‌ها: نصب پکیج‌ها و بیلد اپلیکیشن React با موفقیت انجام شد.
- دسترسی به پیش‌نمایش: باز شدن لینک HTTPS خصوصی در مرورگر تایید شد.
- تعاملی بودن: فیلتر کردن اعضای نمونه با استفاده از یک دکمه React به درستی کار کرد.
- امنیت: درخواست پیش‌نمایش بدون توکن دسترسی، به درستی خطای HTTP 401 بازگرداند.
- تکرار: تغییر فایل‌های منبع، بیلد مجدد و ریلود پیش‌نمایش با موفقیت انجام شد.
- پایداری: ذخیره منبع ویرایش‌شده و بیلد مجدد آن در یک سندباکس جدید تایید شد.
جزئیات پیاده‌سازی فنی
برای ساخت این MVP، بک‌اند باید کنترل کامل محیط را در دست داشته باشد. بک‌اند شما مالک اتصال به مدل، کلید API لایزرد و نگاشت بین کاربران و پروژه‌ها است. کد تولیدشده نیازی به کلید API لایزرد یا کلید ارائه‌دهنده مدل شما ندارد. مسیر جریان داده به این صورت است: پرامپت کاربر $\rightarrow$ بک‌اند (احراز هویت، دسترسی به پروژه، فراخوانی مدل) $\rightarrow$ SDK لایزرد $\rightarrow$ سندباکس (فایل‌های منبع، وابستگی‌ها، بیلد، پیش‌نمایش) $\rightarrow$ بازگشت URL پیش‌نمایش خصوصی به مالک پروژه.
زیرساخت و ابزارها
- قالب‌های اولیه: سیستم از یک قالب React و Vite معتبر با یک lockfile ثابت استفاده می‌کند تا از شکست بیلد به دلیل تغییرات ناگهانی در نسخه‌های وابستگی‌ها (dependency drift) جلوگیری شود. استک تست شده شامل React 19.2.0، Vite 7.1.12، TypeScript 5.9.3 و Python 3.11.16 بود. توسعه‌دهندگان باید وابستگی‌های قالب خود را به‌روز نگه دارند و پس از هر به‌روزرسانی، سیستم را مجدداً تست کنند.
- خروجی ساختاریافته: مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — موظف است رشته‌های ساختاریافته برای
appTsxوappCssبرگرداند. بک‌اند هر دو رشته را اعتبارسنجی کرده، یک محدودیت برای اندازه پاسخ تعیین می‌کند و آن‌ها را در مسیرهای ثابتsrc/App.tsxوsrc/App.cssمی‌نویسد. همچنین بک‌اند کنترل فایل‌های پکیج، lockfile و اسکریپت‌های بیلد را بر عهده دارد و به مدل اطلاع می‌دهد که قالب اولیه از چه importهایی پشتیبانی می‌کند. - فرآیند بیلد: SDK دستورات
npm ciوnpm run buildرا در داخل سندباکس اجرا می‌کند. اگر بیلد با شکست مواجه شود، سیستم خروجی خطای مربوطه را بازگردانده و تا دو بار تلاش برای اصلاح کد را مجاز می‌داند، پیش از آنکه خطا را به کاربر نهایی نشان دهد. - مکانیزم پیش‌نمایش: یک سرور HTTP پایتونی برای سرو کردن پوشه
distروی پورت ۳۰۰۰ از طریق دستورnohup python -m http.server 3000 --bind 0.0.0.0 --directory dist > /tmp/preview.log 2>&1 < /dev/null &استفاده می‌شود. این خروجی سپس از طریق یک URL خصوصی HTTPS همراه با یک توکن دسترسی نمایش داده می‌شود. این توکن دسترسی به پورت‌های باز را فراهم می‌کند و باید به عنوان یک اعتبارنامه (credential) مدیریت شود و در لاگ‌های عمومی یا ابزارهای تحلیل داده قرار نگیرد. - تنظیم محیط: هدف، سندباکس‌های Linux x64 است. سیستم Node.js 22.23.3 را از nodejs.org دانلود کرده و پیش از اجرای بیلد، checksum آرشیو را برای تایید اصالت بررسی می‌کند. این مرحله تنظیمات باید پیش از تحویل فضای کاری به کدهای تولیدشده اجرا شود.
یکپارچه‌سازی SDK
توسعه‌دهندگان برای پیاده‌سازی این سیستم، SDK را از طریق npm install @lizard-build/[email protected] نصب می‌کنند. یک کلید برای پروژه خاص با استفاده از دستور lizard keys create lovable-builder --project YOUR_PROJECT_ID --json ساخته می‌شود. متغیرهای LIZARD_API_KEY و LIZARD_PROJECT_ID باید در محیط بک‌اند تنظیم شوند، زیرا SDK به‌طور خودکار فایل‌های .env یا لاگین‌های CLI را بارگذاری نمی‌کند.
مدیریت چرخه حیات
برای پایین نگه داشتن هزینه‌ها، پایداری داده‌ها خارج از سندباکس مدیریت می‌شود. در حالی که Lizard قابلیت Persistent Volumes (که در هر لحظه به یک سندباکس متصل می‌شوند) را ارائه می‌دهد، مسیر پیشنهادی برای MVP، ذخیره بسته‌های منبع در Managed Object Storage (باکت‌های خصوصی) و رکوردهای پروژه در Managed Postgres است. این سرویس‌های بک‌اند به‌طور مجزا از فضای کاری پیش‌نمایش اجرا می‌شوند. وقتی کاربر به یک سندباکس منقضی‌شده بازمی‌گردد، بک‌اند منبع ذخیره‌شده و قالب اولیه را در یک سندباکس جدید بازیابی کرده و اپلیکیشن را مجدداً بیلد می‌کند. از آنجا که فضای ذخیره‌سازی روی یک نود قرار دارد، توصیه می‌شود یک کپی خارجی از فایل‌های ارزشمند نگه دارید.
بهینگی هزینه محرک اصلی این معماری است. سندباکس‌های کوچک (۲ vCPU، ۴ گیگابایت رم، ۵ گیگابایت دیسک محلی) ساعتی ۰.۰۱۶۲ دلار هزینه دارند که به‌صورت ثانیه‌ای محاسبه می‌شود. برای یک جلسه ۱۰ دقیقه‌ای، هزینه پردازشی هر کاربر حدود ۰.۰۰۲۷ دلار است. برای ۱,۰۰۰ جلسه، هزینه کل ۲.۷۰ دلار و برای ۱۰,۰۰۰ جلسه، ۲۷.۰۰ دلار خواهد بود.
پلن Lizard Pro با ۱۹ دلار در ماه ارائه می‌شود که ۱۹ دلار اعتبار مصرفی شامل آن است و مصرف بیش از آن به‌صورت pay-as-you-go محاسبه می‌شود. یک دوره آزمایشی هفت‌روزه شامل ۵ دلار اعتبار است و نیاز به ثبت کارت دارد. برای جلوگیری از هزینه‌های خارج از کنترل، راهنما پیشنهاد می‌کند محدودیت زمانی ۱۰ دقیقه‌ای برای کل عمر سندباکس و یک سیاست جلسه غیرفعال (idle-session) اعمال شود که پس از پایان جلسه، دستور sandbox.kill() را فراخوانی کند. نکته مهم این است که اجرای دستورات، مهلت زمانی (deadline) سندباکس را تمدید نمی‌کند.
امنیت و ایزولاسیون
از آنجا که یک سندباکس می‌تواند درخواست‌های شبکه ارسال کند، هر رازی که داخل آن قرار گیرد ممکن است توسط کد تولیدشده به بیرون فرستاده شود. بنابراین، اعتبارنامه‌های دیتابیس تولیدی و کلیدهای پلتفرم باید خارج از فضای کاری بمانند. همچنین پیش‌نمایش‌ها باید در یک Origin مرورگر مجزا از اپلیکیشن اصلی سرو شوند. برای یک MVP، باز کردن پیش‌نمایش خصوصی در یک تب جدید ساده‌ترین روش یکپارچه‌سازی است؛ اگر در آینده قصد جاسازی از طریق iframes را دارید، توسعه‌دهندگان باید مجوزها را بررسی و پیام‌ها را اعتبارسنجی کنند.
برنامه ساخت یک‌روزه
جدول زمانی ۸ ساعته پیشنهادی برای توسعه‌دهنده‌ای که از قبل یک استارتر وب با سیستم احراز هویت دارد، به این صورت است:
۱. ساعت اول: ایجاد صفحه پروژه، ورودی پرامپت و بررسی‌های مالکیت.
۲. ساعت ۲ و ۳: پیاده‌سازی اعتبارسنجی پاسخ مدل، ایجاد سندباکس، نوشتن فایل‌ها و اجرای بیلد.
۳. ساعت ۴: فعال‌سازی پیش‌نمایش خصوصی و نمایش خطاهای بیلد به کاربر.
۴. ساعت ۵: افزودن پشتیبانی برای ویرایش‌های بعدی و نسخه‌های ذخیره‌شده پروژه.
۵. ساعت ۶: تنظیم انقضای جلسه، محدودیت تلاش مجدد و سهمیه‌های هر کاربر.
۶. ساعت ۷: انجام تست‌های چند-حسابی برای اطمینان از ایزولاسیون سخت‌گیرانه. تغییر یک Project ID نباید اجازه دهد یک حساب، فایل‌ها، لاگ‌ها یا URL پیش‌نمایش حساب دیگر را بخواند.
۷. ساعت ۸: استقرار ابزار ساخت برای یک گروه کوچک از کاربران تست.
استراتژی اولین انتشار
نسخه اول را کوچک نگه دارید. با یک قالب React و Vite شروع کنید و اجازه دهید کاربران داشبوردهای ساده، صفحات فرود یا ابزارهای داخلی با داده‌های نمونه بسازند. اولین انتشار به احراز هویت، لیست پروژه‌ها، یک جعبه چت، خروجی بیلد و یک پیش‌نمایش فعال نیاز دارد.
یک درخواست مناسب برای تست اولیه این است: «یک داشبورد برای یک باشگاه کوچک بساز. درآمد ماهانه، اعضای فعال و کلاس‌های آینده را با داده‌های نمونه نشان دهد.» پس از اینکه پیش‌نمایش کار کرد، یک درخواست تکمیلی برای افزودن یا تغییر یک فیلتر عضویت ارسال کنید تا حلقه تکرار (iteration loop) تست شود. این کار توانایی اتصال مجدد به یک سندباکس از طریق lizard.connect(sandboxId)، خواندن فایل‌های تایید شده و اعمال تغییرات را تایید می‌کند.
این تغییر در زیرساخت باعث می‌شود «خندق رقابتی» ابزارهای ساخت اپلیکیشن از «توانایی اجرای کد» به «کیفیت قالب‌های اولیه» و «استواری حلقه‌های اصلاح خطا» منتقل شود. برای توسعه‌دهندگان، این بدان معناست که هزینه آزمایش یک SaaS تولید کد از هزاران دلار هزینه سرور به چند سنت هزینه مصرفی در هر ثانیه کاهش یافته است. ریسک اکنون از شکست زیرساخت به توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — تغییر کرده که با استراتژی وابستگی‌های ثابت قابل مدیریت است.
گام بعدی شما
- بررسی مستندات SDK لایزرد برای پیاده‌سازی یک محیط ایزوله در پروژه فعلی خود.
- طراحی یک قالب (Starter Template) بهینه برای کاهش زمان بیلد در اپلیکیشن‌های تولیدشده.
- تست محدودیت‌های شبکه در سندباکس‌ها برای جلوگیری از نشت داده‌های حساس.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو