آموزش v0 by Vercel؛ ساخت اپ Full-Stack از Prompt تا Pull Request
راهنمای عملی ساخت اپ Full-Stack با v0؛ از تعریف نیاز و طراحی رابط تا اتصال Database، حفاظت از Environment Variable، GitHub Branch، Pull Request، Preview و انتشار روی Vercel.
v0 ابزار ساخت نرم‌افزار با زبان طبیعی از Vercel است. می‌توانید یک رابط، صفحه فرود یا اپ Full-Stack را توصیف کنید و کد قابل اجرا بگیرید. تفاوت مهم v0 با یک مولد تصویر رابط این است که پروژه می‌تواند به Database، API Route، Environment Variable، GitHub و Deployment واقعی متصل شود.
با این حال خروجی قابل کلیک به‌معنای محصول آماده Production نیست. در این آموزش یک داشبورد پشتیبانی مشتری می‌سازیم و مسیر را از Brief تا Pull Request جلو می‌بریم. تمرکز روی تصمیم‌هایی است که AI نباید به‌جای تیم حدس بزند: مالکیت داده، مجوزها، Secret، Branch و معیار پذیرش.
v0 by Vercel چیست؟
طبق مستندات رسمی، v0 یک Pair Programmer است که ایده را از زبان طبیعی به UI و کد تبدیل می‌کند. پروژه ایجادشده به یک Project در Vercel متصل می‌شود و می‌تواند از Deployment، Environment Variable و Integrationهای همان پلتفرم استفاده کند. v0 برای اپ‌های Full-Stack به‌طور پیش‌فرض از Next.js استفاده می‌کند، زیرا Server Component، Server Action و Route Handler را کنار رابط قرار می‌دهد.
| قابلیت | کاربرد | کنترل تیم |
|---|---|---|
| Prompt to UI | ساخت سریع Layout و Component | Design System و Accessibility |
| Full-Stack | Route، Action و منطق سرور | Validation و Authorization |
| Database | اتصال به Supabase، Neon یا Upstash | Schema، Migration و Backup |
| GitHub | Branch، Commit و Pull Request | Review و Protection Rule |
| Preview | بازبینی هر تغییر پیش از Merge | داده آزمایشی و دسترسی محدود |
| Deploy | انتشار روی Vercel | Secret، Domain و Monitoring |
اگر مفهوم ساخت نرم‌افزار با گفتگو برایتان جدید است، راهنمای وایب کدینگ امن مرز Prototype و Production را توضیح می‌دهد. برای مقایسه یک Workflow مشابه نیز راهنمای ساخت MVP امن با Lovable را ببینید.
پروژه نمونه: داشبورد پشتیبانی مشتری
اپ نمونه چهار Entity دارد: User، Customer، Ticket و Reply. مشتری Ticket ثبت می‌کند؛ Agent فقط Ticketهای تخصیص‌یافته را می‌بیند؛ Manager همه Ticketهای تیم و گزارش زمان پاسخ را مشاهده می‌کند. نسخه اول پرداخت، پیامک و AI Agent ندارد.
قبل از ورود به v0، Acceptance Criteria را بنویسید. کاربر باید بتواند وارد شود، Ticket بسازد، پاسخ‌ها را ببیند و فقط به داده خودش دسترسی داشته باشد. Agent باید Ticket را Assign و وضعیت را تغییر دهد. Manager باید گزارش کلی ببیند. این معیارها Prompt را کوتاه‌تر و Review را دقیق‌تر می‌کنند.
نقش و مجوز را پیش از صفحه تعریف کنید
| عملیات | Customer | Agent | Manager |
|---|---|---|---|
| دیدن Ticket خود | بله | در صورت تخصیص | بله |
| دیدن همه Ticketها | خیر | خیر | بله |
| ثبت Reply | روی Ticket خود | روی Ticket تخصیص‌یافته | بله |
| تغییر مسئول | خیر | خیر | بله |
| مدیریت کاربر | خیر | خیر | بله |
این جدول را داخل Prompt بیاورید. عبارت کلی «Authentication امن اضافه کن» کافی نیست. Authentication فقط هویت را مشخص می‌کند؛ Authorization تعیین می‌کند آن هویت به کدام رکورد و عملیات دسترسی دارد.
مدل داده را کوچک نگه دارید
برای Ticket فیلدهای Subject، Description، Status، Priority، CustomerId، AssigneeId و CreatedAt کافی‌اند. Reply نیز TicketId، AuthorId، Body و CreatedAt دارد. حذف قطعی را در MVP غیرفعال کنید و وضعیت Archived یا Closed داشته باشید تا سابقه پشتیبانی از بین نرود.
Prompt اول را مثل Brief محصول بنویسید
Prompt اولیه باید هدف، کاربر، نقش، صفحه، مدل داده، محدودیت و معیار پذیرش را مشخص کند. ظاهر را توصیف کنید، اما اجازه ندهید بحث رنگ جای امنیت و جریان کار را بگیرد.
یک داشبورد پشتیبانی فارسی و RTL با Next.js بساز. نقش‌های Customer، Agent و Manager و Entityهای Customer، Ticket و Reply را در نظر بگیر. مشتری فقط Ticket و Replyهای خودش را ببیند؛ Agent فقط Ticketهای تخصیص‌یافته را مدیریت کند؛ Manager همه تیم را ببیند و مسئول Ticket را تغییر دهد. ابتدا فقط UI با داده Mock بساز و صفحات Login، فهرست Ticket، جزئیات Ticket و Dashboard مدیر را ارائه کن. حالت Loading، Empty، Error و Permission Denied را هم طراحی کن. قبل از افزودن Database یا Authentication، Plan و فرض‌ها را نمایش بده.
با Mock Data شروع کنید. این کار اجازه می‌دهد Navigation، RTL، فرم و حالت‌های مختلف را بدون درگیر شدن با Schema واقعی بررسی کنید. پس از تأیید جریان، لایه داده را در یک مرحله جدا اضافه کنید.
Workflow مرحله‌ای Full-Stack
مستندات v0 توسعه افزایشی را پیشنهاد می‌کند: ابتدا UI، بعد Data Layer، سپس Authentication و CRUD و در پایان بهینه‌سازی. ترکیب همه این موارد در یک Prompt، خطای پنهان و اصلاح پرهزینه ایجاد می‌کند.
- Layout و Componentها را با داده Mock بسازید.
- Schema و Relationshipها را تعریف و فقط یک Database متصل کنید.
- Authentication را اضافه و Session را آزمایش کنید.
- Authorization سطح رکورد را در Server اعمال کنید.
- CRUD اصلی Ticket و Reply را تکمیل کنید.
- Validation سمت Client و Server را اضافه کنید.
- Log، Error State و Rate Limit را بررسی کنید.
- کد را به Branch متصل و Pull Request باز کنید.
برای هر مرحله یک Chat یا Branch قابل بازگشت داشته باشید. اگر تغییر معماری است، ابتدا از v0 بخواهید Plan، فایل‌های درگیر و ریسک‌ها را توضیح دهد. تولید کد بدون برنامه، مسئولیت Review را حذف نمی‌کند.
انتخاب Database و طراحی دسترسی
v0 از Integrationهای پایگاه داده مانند Supabase، Neon و Upstash پشتیبانی می‌کند. انتخاب را بر اساس نوع داده، Query، Transaction، Backup و مهارت تیم انجام دهید. برای Ticket و Reply یک Database رابطهای معمولاً مدل طبیعی‌تری دارد؛ Cache یا Queue مسئله‌ای جداست.
| نیاز | گزینه متداول | پرسش پیش از اتصال |
|---|---|---|
| داده رابطهای و گزارش | PostgreSQL مانند Neon یا Supabase | Migration و Backup چگونه انجام می‌شود؟ |
| Cache و Rate Limit | Upstash | TTL و رفتار هنگام قطعی چیست؟ |
| فایل و Attachment | Blob Storage | نوع فایل و دسترسی URL چگونه کنترل می‌شود؟ |
| Prototype رابط | Mock Data | چه زمانی باید داده واقعی جایگزین شود؟ |
هر Query باید مالک رکورد یا نقش را در Server بررسی کند. فیلترکردن لیست در Browser امنیت نیست؛ کاربر می‌تواند Request مستقیم بسازد. برای Attachment نوع MIME، اندازه، نام فایل و مجوز دانلود را کنترل کنید.
Environment Variable و Secret
در Next.js فقط متغیرهایی که عمداً با پیشوند NEXT_PUBLIC_ تعریف می‌شوند برای کد Browser در دسترس‌اند. API Key خصوصی، Database URL و Token سرویس نباید این پیشوند را داشته باشند یا داخل Component سمت Client استفاده شوند.
- Secret را در تنظیمات Environment پروژه نگه دارید.
- برای Development، Preview و Production مقدار جدا داشته باشید.
- کلید را داخل Prompt، Screenshot، Git یا Log قرار ندهید.
- دسترسی Secret را به کمترین اعضای لازم محدود کنید.
- در صورت افشا، کلید را فوراً Rotate کنید؛ حذف Commit کافی نیست.
- فراخوانی حساس را در Route Handler یا Server Action انجام دهید.
v0 درباره استفاده خطرناک از متغیر عمومی هشدار می‌دهد، اما مسئولیت نهایی با تیم است. Bundle ساخته‌شده و Network tab را بررسی کنید تا Secret در JavaScript یا پاسخ API دیده نشود.
GitHub، Branch و Pull Request
در Workflow جدید Git، هر Chat می‌تواند Branch جدا داشته باشد و تغییر هر پیام Commit شود. v0 مستقیم به main Push نمی‌کند و نتیجه برای Merge به Pull Request می‌رود. پس از اتصال Repository، GitHub منبع اصلی کد است؛ حذف Repository می‌تواند بازیابی پروژه را مختل کند.
- Repository را در Organization درست و به‌صورت Private بسازید.
- Protection Rule و Review اجباری را روی Branch اصلی فعال کنید.
- نام Branch را به Feature یا Ticket مرتبط کنید.
- Diff هر Commit تولیدشده را بخوانید.
- Test و Build را در CI اجرا کنید.
- Preview Deployment را با داده غیرحساس بازبینی کنید.
- فقط پس از تأیید، PR را Merge کنید.
Review باید تغییر Schema، Permission، Dependency، Environment و Routeهای جدید را پوشش دهد. یک UI زیبا می‌تواند هم‌زمان Authorization ناقص یا Dependency آسیب‌پذیر داشته باشد.
چک‌لیست Review کد تولیدشده
| حوزه | سؤال Review | معیار رد |
|---|---|---|
| Input | سمت Server اعتبارسنجی می‌شود؟ | اعتماد کامل به Client |
| Authorization | مالکیت هر رکورد بررسی می‌شود؟ | فقط مخفی کردن Button |
| Secret | در Server Environment است؟ | NEXT_PUBLIC یا Hard-code |
| Error | پیام امن و قابل فهم است؟ | Stack Trace عمومی |
| Database | Migration و Index مشخص‌اند؟ | تغییر مستقیم و بدون Backup |
| Dependency | واقعاً لازم و معتبر است؟ | Package ناشناخته یا بلااستفاده |
Preview را مانند Production آزمایش کنید
Preview برای بازبینی بسیار مفید است، اما ممکن است تنظیمات و داده متفاوتی داشته باشد. سه حساب آزمایشی برای Customer، Agent و Manager بسازید و URL مستقیم رکورد دیگران را امتحان کنید. سناریوی موفق تنها بخشی از Test است.
- فرم خالی، متن بسیار بلند و فایل نامعتبر
- Session منقضی و کاربر بدون نقش
- شناسه Ticket متعلق به کاربر دیگر
- Database کند یا موقتاً قطع
- دو ویرایش هم‌زمان روی یک Ticket
- صفحه موبایل، Keyboard و Screen Reader
- عدم وجود Secret در HTML و Network Response
داده Preview را مصنوعی نگه دارید. اطلاعات واقعی مشتری، Token یا فایل محرمانه را وارد محیطی نکنید که سیاست دسترسی آن هنوز تأیید نشده است.
Deploy امن روی Vercel
Deploy از v0 یک Deployment در Vercel ایجاد می‌کند. پیش از انتشار دامنه اصلی، Environmentهای Production، اتصال Database، Migration و Health Check را تأیید کنید. دسترسی Preview و Production را یکسان فرض نکنید.
- Build را بدون خطای بحرانی اجرا کنید.
- متغیرهای Production را جدا و محدود تنظیم کنید.
- Migration را روی Backup یا Staging آزمایش کنید.
- Domain و Redirect و SSL را کنترل کنید.
- Smoke Test ورود، ساخت Ticket و پاسخ را اجرا کنید.
- Log، Error Rate، Latency و هزینه را پایش کنید.
- یک Rollback Point سالم نگه دارید.
اشتباه‌های رایج
- یک Prompt برای کل محصول: دامنه تغییر بزرگ و Review مبهم می‌شود.
- اتصال زودهنگام داده واقعی: خطای Permission به Incident تبدیل می‌شود.
- استفاده از NEXT_PUBLIC برای Secret: مقدار وارد Bundle مرورگر می‌شود.
- Merge فقط بر اساس ظاهر Preview: کد، Schema و دسترسی بررسی نمی‌شوند.
- حذف Repository: پس از اتصال GitHub، منبع اصلی کد ممکن است از بین برود.
- اعتماد به ادعای Production-ready: Test و Monitoring همچنان ضروری‌اند.
جمع‌بندی
v0 می‌تواند مسیر Wireframe تا اپ Full-Stack و Pull Request را کوتاه کند. بهترین نتیجه زمانی حاصل می‌شود که UI، Data، Authentication و انتشار را مرحله‌ای بسازید و هر تغییر در Branch مستقل Review شود.
برای اپ پشتیبانی، امنیت یعنی Authorization سمت Server، Secret غیرعمومی، داده آزمایشی، PR اجباری و تست با نقش‌های متفاوت. سرعت AI ارزشمند است، اما معیار انتشار باید همان استاندارد مهندسی نرم‌افزار باقی بماند.
امروز فقط UI داشبورد پشتیبانی را با Mock Data بسازید؛ سپس ماتریس سه‌نقشی دسترسی را به Prompt اضافه کنید و پیش از اتصال Database، Plan تولیدشده را بازبینی کنید.