Base44 چیست؟ آموزش ساخت CRM فارسی با هوش مصنوعی از Prompt تا انتشار
راهنمای عملی Base44 برای ساخت یک CRM فارسی بدون شروع از کد؛ از تعریف نقش‌ها و مدل داده تا Prompt مرحله‌ای، کنترل دسترسی، تست کاربران، اتصال GitHub و انتشار امن.
Base44 یک سازنده وب‌سایت و اپ مبتنی بر هوش مصنوعی است. به‌جای اینکه پروژه را با فایل‌های خالی شروع کنید، نیاز خود را با زبان طبیعی توضیح می‌دهید و ابزار رابط، داده، ورود کاربران، مجوزها و Hosting اولیه را آماده می‌کند. اما «ساخته شدن صفحه» با «آماده بودن محصول» یکی نیست.
در این آموزش یک CRM فارسی برای تیم فروش می‌سازیم؛ اپی که مشتری، پیگیری، مسئول پرونده و وضعیت معامله را نگه می‌دارد. هدف، یادگیری یک Workflow قابل تکرار است: ابتدا مسئله را محدود می‌کنیم، سپس مدل داده و نقش‌ها را می‌نویسیم، ساخت را مرحله‌ای پیش می‌بریم و پیش از انتشار با چند نوع کاربر آزمایش می‌کنیم.
Base44 چیست و چه چیزی می‌سازد؟
طبق مستندات رسمی، Base44 یک AI App Builder است که می‌تواند طراحی، پایگاه داده، ثبت‌نام، مجوز کاربران و Hosting را در یک محیط مدیریت کند. شما می‌توانید از Prompt ساده، Plan mode، Template یا Frame طراحی‌شده در Figma شروع کنید. بعد از ساخت اولیه نیز AI chat، ویرایش بصری و Code tab برای اصلاح برنامه در دسترس‌اند.
Base44 در سال ۲۰۲۵ توسط Wix خریداری شد. این موضوع به‌تنهایی تضمین کیفیت یا دوام هر پروژه نیست، اما نشان می‌دهد ابزار بخشی از موج جدی ساخت نرم‌افزار با زبان طبیعی است. اگر هنوز مرز نمونه‌سازی و Production را نمی‌شناسید، ابتدا راهنمای وایب کدینگ امن و قابل انتشار را بخوانید.
| بخش | کاربرد | کنترل ضروری |
|---|---|---|
| AI Chat | ساخت و تغییر ویژگی با توضیح طبیعی | درخواست کوچک و قابل بازبینی |
| Plan mode | شفاف‌کردن نیاز پیش از ساخت | ثبت نقش، جریان و محدودیت |
| Data | مدیریت Entity و رکوردها | مجوز سطح رکورد |
| Authentication | ورود و ثبت‌نام کاربران | آزمون نقش‌ها و Session |
| Code tab | مشاهده و ویرایش React/Vite | Review و Version Control |
| Publish | ارائه URL و دامنه سفارشی | Visibility، Billing و Smoke Test |
قبل از ساخت CRM، محدوده MVP را مشخص کنید
اشتباه رایج این است که در اولین Prompt هم‌زمان CRM، انبار، حسابداری، پیامک، هوش مصنوعی و فروشگاه درخواست شود. مدل مجبور می‌شود درباره جزئیات مهم حدس بزند و نتیجه ظاهراً کامل اما شکننده خواهد بود. MVP این آموزش فقط چهار کار اصلی دارد:
- ثبت مشتری با نام، شماره تماس، شرکت و منبع آشنایی
- ایجاد پیگیری با تاریخ، توضیح، مسئول و نتیجه
- تغییر وضعیت معامله بین جدید، مذاکره، برنده و ازدست‌رفته
- نمایش Dashboard خلاصه برای مدیر فروش
فعلاً ارسال پیامک، اتصال مالی، AI Agent و Import انبوه را کنار می‌گذاریم. این قابلیت‌ها پس از اثبات جریان اصلی اضافه می‌شوند. محدود کردن Scope هم Credit کمتری مصرف می‌کند و هم یافتن خطا را ساده‌تر می‌سازد.
نقش‌ها را پیش از صفحه‌ها تعریف کنید
برای CRM سه نقش کافی است: فروشنده، مدیر فروش و مدیر سیستم. فروشنده فقط مشتریان تخصیص‌یافته به خود را می‌بیند؛ مدیر فروش همه پرونده‌های تیم و گزارش‌ها را مشاهده می‌کند؛ مدیر سیستم کاربر و تنظیمات را مدیریت می‌کند. «کاربر واردشده» یک مجوز کامل نیست.
| عملیات | فروشنده | مدیر فروش | مدیر سیستم |
|---|---|---|---|
| دیدن مشتری خود | بله | بله | بله |
| دیدن همه مشتریان | خیر | بله | بله |
| تغییر مسئول پرونده | خیر | بله | بله |
| حذف قطعی رکورد | خیر | خیر | ترجیحاً غیرفعال‌سازی |
| مدیریت کاربران | خیر | خیر | بله |
مدل داده را کوچک و قابل فهم نگه دارید
برای شروع سه Entity بسازید: Customer، FollowUp و Deal. هر FollowUp باید به یک Customer و یک User متصل باشد. هر Deal نیز مشتری، مسئول، مبلغ اختیاری، مرحله و تاریخ آخرین تغییر را نگه دارد. شماره تماس را String بگیرید تا صفر ابتدای آن از بین نرود.
نام فنی Entity و Fieldها را لاتین و محتوای قابل نمایش را فارسی نگه دارید. این انتخاب Integration، GitHub و توسعه بعدی را ساده‌تر می‌کند. برای تاریخ، منطقه زمانی و تقویم نمایشی را جدا ببینید؛ مقدار پایگاه داده بهتر است استاندارد و مستقل از شکل فارسی رابط باشد.
اولین Prompt را چگونه بنویسیم؟
Prompt خوب فقط نام محصول نیست. مخاطب، نقش‌ها، Entityها، جریان اصلی، صفحات، زبان، قواعد دسترسی و معیار موفقیت را بیان می‌کند. نمونه زیر را به‌عنوان Brief بخوانید و با اطلاعات واقعی خودتان تطبیق دهید.
یک CRM فارسی و RTL برای تیم فروش پنج‌نفره بساز. سه نقش SalesRep، SalesManager و Admin داشته باشد. Entityهای Customer، FollowUp و Deal را ایجاد کن. فروشنده فقط مشتریان و پیگیری‌های تخصیص‌یافته به خودش را ببیند؛ مدیر فروش همه تیم را ببیند و Admin کاربران را مدیریت کند. صفحات Dashboard، مشتریان، جزئیات مشتری، پیگیری‌ها و معاملات را بساز. حذف رکورد با تأیید انجام شود و در نسخه اول به‌جای حذف قطعی، وضعیت Archived ثبت شود. ابتدا Plan و مدل داده را نشان بده و تا قبل از تأیید من ساخت را شروع نکن.
در Plan mode پاسخ پرسش‌های ابزار را کامل بدهید. Problem، Audience، Core Flow و Design Preference را مرور کنید. اگر ابزار فیلدی مانند OwnerId، CreatedAt یا Status را جا انداخت، قبل از Start Building اصلاح کنید. تغییر مدل داده پس از ورود اطلاعات واقعی هزینه و ریسک بیشتری دارد.
ساخت مرحله‌ای؛ هر Prompt فقط یک مسئولیت
بعد از ساخت اسکلت، تغییرها را به بسته‌های کوچک تقسیم کنید. Prompt اول مدل داده و نمونه رکورد، Prompt دوم Login و نقش‌ها، Prompt سوم صفحه فهرست و فیلتر و Prompt چهارم Dashboard را هدف بگیرد. بعد از هر مرحله Preview را آزمایش و نتیجه را ثبت کنید.
- مدل Entityها و Relationshipها را بسازید و با پنج رکورد آزمایشی بررسی کنید.
- Authentication و سه نقش را فعال کنید.
- دسترسی سطح رکورد را برای SalesRep محدود کنید.
- صفحه فهرست مشتریان را با Search، Filter و Pagination بسازید.
- فرم پیگیری را با Validation تاریخ و مسئول اضافه کنید.
- Dashboard را فقط از داده مجاز همان کاربر تغذیه کنید.
- حالت‌های Loading، Empty، Error و Permission Denied را طراحی کنید.
در AI Chat سه حالت مهم وجود دارد: حالت Default تغییر را فوراً اعمال می‌کند؛ Discuss برای فکر کردن بدون تغییر مناسب است؛ Edit روی اصلاح بصری یک Element تمرکز دارد. پیش از تغییر معماری یا داده از Discuss استفاده کنید تا ابتدا پیامدها و Plan روشن شوند.
رابط فارسی و RTL را درست پیاده کنید
فقط راست‌چین‌کردن متن کافی نیست. ترتیب Navigation، جای آیکن‌ها، جهت Breadcrumb، فرم شماره تلفن و نمایش تاریخ باید آزمایش شود. داده لاتین مانند Email، URL و کد پیگیری بهتر است در بخش خود LTR بماند تا خوانایی خراب نشود.
- جهت کلی صفحات فارسی را RTL تنظیم کنید.
- Label فارسی را واضح و کوتاه بنویسید.
- اعداد، تاریخ و مبلغ را با نیاز حسابداری تیم هماهنگ کنید.
- خطا را کنار Field مربوط و با متن عملی نمایش دهید.
- Table را در موبایل با Scroll افقی یا Card جایگزین کنید.
- Contrast، Focus و کار با Keyboard را بررسی کنید.
برای طراحی یک رابط منسجم می‌توانید از راهنمای طراحی رابط با Google Stitch ایده بگیرید، اما Design System نهایی را داخل خود پروژه مستند و ثابت کنید.
احراز هویت و مجوزها؛ مهم‌ترین بخش CRM
CRM شامل اطلاعات تماس و تاریخچه تعامل مشتری است. پنهان کردن دکمه در رابط، امنیت ایجاد نمی‌کند. Rule یا مجوز Backend باید تعیین کند چه کسی می‌تواند هر رکورد را بخواند یا تغییر دهد. از Base44 بخواهید سیاست دسترسی را توضیح دهد و سپس آن را با حساب‌های واقعی آزمایشی کنترل کنید.
| سناریو | انتظار | علامت شکست |
|---|---|---|
| کاربر مهمان URL مشتری را باز می‌کند | ورود یا خطای مجوز | نمایش هر بخش از اطلاعات |
| فروشنده شناسه مشتری همکار را حدس می‌زند | دسترسی رد شود | نمایش با URL مستقیم |
| فروشنده Role را در Request تغییر می‌دهد | Backend رد کند | اعتماد به مقدار Client |
| Session منقضی می‌شود | ورود دوباره و حفظ مسیر امن | خطای خام یا دسترسی ادامه‌دار |
| مدیر رکورد را Archive می‌کند | ثبت Actor و زمان | حذف بی‌ردپا |
اگر اپ به سرویس بیرونی متصل می‌شود، Token را داخل Prompt، کد Frontend یا Screenshot قرار ندهید. Connector و Secret باید حداقل دسترسی لازم را داشته باشند. برای طراحی اتصال Agent به داده سازمانی، راهنمای MCP Server و اتصال امن ابزارها را ببینید.
Data، Backup و قابلیت خروج
پیش از ورود اطلاعات واقعی، مسیر Export را آزمایش کنید. مستندات Base44 امکان مدیریت و Export داده از Dashboard را توضیح می‌دهد و Code tab نیز دسترسی به پروژه React/Vite و Integration با GitHub را فراهم می‌کند. این قابلیت‌ها را زمانی بررسی کنید که هنوز داده حساس ندارید.
یک Backup خوب فقط فایل دانلودشده نیست. باید بدانید Schema، Relationship، User Mapping، فایل‌ها و Secretها چگونه بازیابی می‌شوند. هر ماه یک Restore آزمایشی با داده غیرحساس انجام دهید. اگر Export بخشی از قابلیت‌ها را پوشش نمی‌دهد، محدودیت را در تصمیم خرید ثبت کنید.
- Repository را به حساب سازمانی متصل کنید، نه حساب شخصی موقت.
- Branch اصلی را با Review و Protection Rule محافظت کنید.
- فایل‌های Secret و Environment را از Commit خارج کنید.
- تغییرهای AI را مانند کد یک همکار Review کنید.
- نسخه قابل انتشار را با Tag یا Release مشخص کنید.
Credit و قیمت‌گذاری را چگونه کنترل کنیم؟
Base44 برای ساخت و تغییرهای AI از Credit استفاده می‌کند؛ Preview و تعامل با اپ لزوماً همان مصرف را ندارند. مقدار و امکانات Plan ممکن است تغییر کند، پس پیش از خرید صفحه Pricing روز را بررسی کنید. به‌جای تعداد پیام، هزینه یک Workflow کامل را اندازه بگیرید.
| رفتار پرهزینه | جایگزین بهتر | فایده |
|---|---|---|
| Prompt مبهم و بازنویسی مکرر | Plan mode و Acceptance Criteria | کاهش رفت‌وبرگشت |
| تغییر چند قابلیت با هم | یک مسئولیت در هر Prompt | تشخیص آسان خطا |
| اعمال فوری ایده خام | Discuss mode | بررسی بدون تغییر گسترده |
| بازطراحی کامل برای جزئیات | Edit mode روی Element | حفظ بخش‌های سالم |
| تست فقط در پایان | آزمون پس از هر مرحله | جلوگیری از زنجیره اصلاح |
تست پیش از Publish
در Preview با حساب مدیر وارد شدن کافی نیست. مستندات پیشنهاد می‌کند اپ را مانند کاربر نهایی، با Act as a user، نقش‌های آزمایشی، پنجره ناشناس و اندازه موبایل بررسی کنید. برای CRM حداقل یک حساب از هر نقش بسازید و داده مصنوعی استفاده کنید.
- ثبت‌نام، Login، Logout و بازیابی Session را تست کنید.
- ایجاد، ویرایش، Archive و Search مشتری را اجرا کنید.
- دسترسی مستقیم به URL رکورد غیرمجاز را امتحان کنید.
- فرم خالی، مقدار طولانی، شماره تکراری و تاریخ نامعتبر را وارد کنید.
- Dashboard را با صفر رکورد و هزار رکورد نمونه بررسی کنید.
- ظاهر موبایل، Keyboard و Screen Reader را کنترل کنید.
- Activity Monitor و خطاهای API را قبل از انتشار مرور کنید.
داده واقعی مشتری را برای Test وارد نکنید. نام، شماره و شرکت مصنوعی بسازید. اگر نیاز به تست Import دارید، یک فایل کوچک و ساختگی با همان ساختار واقعی تهیه کنید.
انتشار، Visibility و دامنه سفارشی
در مرحله Publish می‌توانید URL اپ را دریافت، دامنه سفارشی متصل و Visibility را تنظیم کنید. پیش‌فرض مناسب برای CRM عمومی نیست؛ اپ باید Invite-only یا محدود به کاربران مجاز باشد. قبل از تغییر Visibility، یک‌بار در پنجره ناشناس بررسی کنید که صفحه داخلی بدون Login دیده نمی‌شود.
DNS، دامنه، SSL، Redirect و Emailهای Login را پس از اتصال دامنه دوباره آزمایش کنید. مسئول هزینه، مالک Workspace و فرد پاسخ‌گو به Incident را مشخص کنید. اگر قابلیت مهمی وابسته به Plan بالاتر است، آن را پیش از وعده به مشتری فعال و آزمایش کنید.
چه زمانی Base44 انتخاب مناسبی نیست؟
اگر پروژه نیاز به Runtime بسیار سفارشی، استقرار کاملاً On-premise، Compliance سخت، کنترل ریز زیرساخت یا Library ناسازگار دارد، قبل از تعهد بلندمدت یک Proof of Concept بسازید. سرعت ساخت اولیه نباید محدودیت معماری را پنهان کند.
- نیاز قانونی برای محل دقیق نگهداری داده دارید.
- قرارداد خروج و Backup باید جزئیات سازمانی داشته باشد.
- پردازش حساس مالی یا پزشکی بدون ارزیابی امنیت مطرح است.
- تیم به Pipeline سفارشی و Environmentهای متعدد وابسته است.
- هزینه در مقیاس بزرگ هنوز اندازه‌گیری نشده است.
در این شرایط، Base44 می‌تواند برای Prototype مفید باشد، اما تصمیم Production باید پس از Threat Model، تست بار، بررسی دسترسی و برنامه خروج انجام شود.
جمع‌بندی
Base44 فاصله ایده تا اپ قابل کلیک را کوتاه می‌کند و برای CRM داخلی، Dashboard، فرم، Booking و MVP جذاب است. ارزش واقعی زمانی ایجاد می‌شود که Prompt به نیازمندی قابل‌آزمون تبدیل شود و AI نتواند درباره نقش، داده و امنیت آزادانه حدس بزند.
برای پروژه CRM این مسیر را حفظ کنید: Scope کوچک، نقش روشن، مدل داده ساده، Prompt مرحله‌ای، تست با سه نوع کاربر، Export و GitHub، سپس Publish محدود. هر تغییر تولیدشده را مانند کد انسانی Review کنید.
امروز نسخه آزمایشی CRM را فقط با سه Entity و سه نقش بسازید؛ پیش از Publish، دسترسی مستقیم یک فروشنده به پرونده همکارش را آزمایش و نتیجه را ثبت کنید.