چگونه با وایب کدینگ اپلیکیشن بسازیم: از ایده تا اپلیکیشن منتشرشده
برای ساختن یک اپلیکیشن با وایب کدینگ، یک توصیف یکصفحهای از نسخهی اول بنویسید، آن را بهعنوان پرامپت اول به یک اپساز هوش مصنوعی بدهید، و سپس اپلیکیشن را در قدمهای کوچک و آزموده رشد دهید: داده، ورود، جریان اصلی کار، صیقلدادن، یک بررسی امنیتی و در نهایت انتشار. این راهنما یک پروژهی نمونه را در همهی مراحل دنبال میکند: یک اپلیکیشن رزرو کلاس برای یک استودیوی کوچک یوگا، با پرامپتهایی که در هر مرحله استفاده شدهاند.
اگر تاکنون چیزی به این روش نساختهاید، آموزش وایب کدینگ برای مبتدیان از یک نقطهی کوچکتر شروع میکند. برای مروری کلیتر که به وایب کدینگ محدود نیست، نحوهی ساختن اپلیکیشن با هوش مصنوعی را ببینید.
پروژه
یک صاحب استودیو یوگا به اسم سارا را تصور کنید که هفتهای هشت کلاس دارد. رزروها از طریق واتساپ میآیند؛ او برای هر کلاس یک فهرست کاغذی نگه میدارد و اغلب بیش از ظرفیت رزرو میگیرد. او میخواهد:
- دانشجوها جدول کلاسهای هفته را ببینند و یک جا رزرو کنند.
- هر کلاس یک ظرفیت داشته باشد.
- برای هر کلاس فهرستی داشته باشد که در ورودی بتواند چک کند.
- دانشجوها تا دو ساعت قبل بتوانند لغو کنند.
همین کل نسخهی اول است. بدون پرداخت، بدون اشتراک عضویت، بدون فروشگاه اپلیکیشن. اینها بعداً میآیند، یا هرگز.
گام ۱: یک مشخصات یکصفحهای بنویسید
پیش از باز کردن هر ابزاری، نسخهی اول را با کلمات ساده بنویسید. ده دقیقهی اینجا ساعتها رفتوبرگشت بعدی را ذخیره میکند. یک شکل مفید:
- چه کسی استفاده میکند: دانشجوها (رزرو و لغو)، سارا (مدیریت کلاسها و دیدن فهرستها).
- صفحهها: جدول کلاسها، جزئیات کلاس، رزروهای من، کلاسهای مدیریت، فهرست کلاسهای مدیریت.
- داده: کلاسها (نام، مربی، زمان شروع، مدت، ظرفیت)، رزروها (دانشجو، کلاس، وضعیت)، دانشجوها (نام، ایمیل، تلفن).
- قواعد: کلاس پر رزرو نشود؛ هر دانشجو در هر کلاس فقط یک رزرو داشته باشد؛ لغو تا دو ساعت قبل؛ فقط سارا صفحات مدیریت را ببیند.
- در نسخهی ۱ نیست: پرداخت، بستهی کلاس، لیست انتظار، یادآوری.
فهرست «در نسخهی ۱ نیست» مهمترین بخش است. این همان چیزی است که نگه میدارد ساخت به پایان برسد. نوشتن سند الزامات محصول با هوش مصنوعی برای یک مشخصات کاملتر را پوشش میدهد.
گام ۲: ابزاری انتخاب کنید که کل چرخه را پوشش دهد
برای اپلیکیشنی با پایگاه داده، ورود و نشانی عمومی، از یک اپساز هوش مصنوعی استفاده کنید که کد را اجرا میکند، پایگاه داده وصل میکند و منتشر میکند، نه یک دستیار گفتگو که فایلها را تحویل میدهد. مقایسهی ابزارهای وایب کدینگ گزینهها را فهرست میکند. ما در اینجا از Mythex استفاده میکنیم، چون هر مرحله را در یک جا پوشش میدهد: گفتگو، پیشنمایش زنده، پایگاه داده و ذخیرهسازی فایل واقعی، و انتشار با یک کلیک.
گام ۳: پرامپت اول
مشخصات را در یک پاراگراف بیاورید. کل سند را با همهی جزئیات یکجا نچسبانید؛ هستهی کار را بدهید و بقیه را در مراحل بعدی اضافه کنید.
یک اپلیکیشن رزرو کلاس برای استودیوی یوگای من بساز. دانشجوها با نام، ایمیل و تلفن ثبتنام میکنند، جدول کلاسهای این هفته را میبینند و جای یک کلاس را رزرو میکنند. هر کلاس نام، مربی، زمان شروع، مدت و ظرفیت دارد؛ کلاس پر «Full» نشان داده شود و نتوان آن را رزرو کرد. دانشجوها رزروهایشان را میبینند و میتوانند تا دو ساعت پیش از کلاس لغو کنند. من مدیر هستم: میتوانم کلاسها را اضافه و ویرایش کنم و فهرست کسانی که برای هر کلاس رزرو کردهاند را ببینم. طراحی آرام و ساده که روی گوشی هم خوب کار کند.
اگر مطمئن نیستید که ابزار درست فهمیده، از یک برنامهی اول بخواهید. در Mythex، حالت Plan صفحهها و داده را پیش از نوشتن کد شرح میدهد و شما آن را تأیید میکنید.
گام ۴: حلقهی اصلی را کار بیندازید
حلقهی اصلی تنها چیزی است که اپلیکیشن برای آن وجود دارد: یک دانشجو کلاسی را رزرو میکند و سارا آن را میبیند. فقط همان را آزمایش کنید:
- بهعنوان دانشجو ثبتنام کنید و یک کلاس را رزرو کنید.
- نمای مدیریت را باز کنید. آیا رزرو آنجاست؟
- همان کلاس را دوباره رزرو کنید. باید رد شود.
- ظرفیت یک کلاس را ۲ بگذارید، با دو حساب دانشجو آن را رزرو کنید و سومی را امتحان کنید.
در این مرحله معمولاً دو مشکل پیدا میشود. جدول، زمانها را بر اساس منطقهی زمانی سرور نشان میدهد، نه استودیو. و بررسی «پر بودن» فقط در صفحه انجام میشود، پس یک دابلکلیک سریع دو رزرو میسازد.
همهی زمانهای کلاس را در منطقهی زمانی استودیو، [Asia/Dubai]، نشان بده، صرفنظر از تنظیم دستگاه بازدیدکننده.
ظرفیت و رزروهای تکراری را هنگام ساخت رزرو روی سرور بررسی کن، نه فقط در صفحه. اگر دو درخواست همزمان برای آخرین جای خالی رسید، فقط یکی باید موفق شود.
پیش از افزودن هر چیز دیگری، حلقهی اصلی را درست کنید. بقیهی کارها به آن وابستهاند.
گام ۵: قواعد باقیمانده را یکییکی اضافه کنید
حالا قواعد مشخصات را یکییکی جلو بروید:
دانشجوها میتوانند تا دو ساعت پیش از شروع کلاس، رزرو خود را لغو کنند. بعد از آن، دکمهی لغو را پنهان کن و لغو را روی سرور با یک پیام واضح رد کن.
فقط حساب من میتواند صفحات مدیریت را باز کند. این را برای هر عمل مدیریتی روی سرور بررسی کن، نه فقط با پنهان کردن منو.
بعد از هر کدام، آزمایش کنید و فقط وقتی کار کرد به بعدی بروید. اگر تغییری چیزی را خراب کرد، به آخرین نقطهی ذخیرهی درست برگردید و با یک درخواست واضحتر دوباره امتحان کنید، بهجای اینکه اصلاحها را روی هم انباشته کنید.
گام ۶: چیزهایی را صیقل دهید که کاربران واقعی میبینند
کاربران واقعی جزئیات کوچک را میبینند. یک فهرست کوتاه برای اپلیکیشن سارا:
- حالت خالی: «هنوز کلاسی برای این هفته نیست» بهجای صفحهی خالی.
- تأیید: «برای Vinyasa، سهشنبه ساعت ۱۸ رزرو شد» بعد از رزرو.
- چیدمان موبایل: دکمههای بزرگ، و جدول قابل خواندن روی صفحهی ۳۷۵ پیکسلی.
- جای خالی باقیمانده: «۳ جای خالی» روی هر کارت کلاس، تا دانشجوها زودتر رزرو کنند.
روی هر کارت کلاس، جای خالی را نشان بده، مثلاً «۳ از ۱۲ باقیمانده». بعد از رزرو، تأییدی با نام کلاس، روز و ساعت و یک دکمه به «رزروهای من» نشان بده.
گام ۷: مثل یک غریبه آزمایش کنید
پیش از اینکه کس دیگری آن را استفاده کند، نیم ساعت وقت بگذارید و سعی کنید آن را خراب کنید:
| آزمایش | باید چه اتفاقی بیفتد |
|---|---|
| رزرو با دو حساب در دو پنجرهی مرورگر برای آخرین جای خالی | یکی موفق شود، دیگری «پر» ببیند |
| تغییر شناسهی رزرو در نوار نشانی هنگام ورود بهعنوان دانشجو | «پیدا نشد»، هرگز رزرو شخص دیگری |
| باز کردن نشانی مدیریت بهعنوان دانشجو | رد شود |
| ثبتنام با ایمیلی که قبلاً استفاده شده | پیام واضح |
| استفاده روی گوشی با اینترنت موبایل | همهچیز خوانا و قابل لمس باشد |
میتوانید از هوش مصنوعی هم بخواهید حالتهای مرزی را بررسی کند:
ده کاری را فهرست کن که یک دانشجوی واقعی ممکن است انجام دهد و رزرو یا لغو را خراب کند، هر کدام را آزمایش کن و آنچه را که شکست میخورد اصلاح کن. بگو چه تغییری دادی.
گام ۸: یک بررسی امنیتی
این اپلیکیشن نام، ایمیل و شمارهی تلفن را ذخیره میکند، پس یک بررسی امنیتی کوتاه ارزش دارد. پرسشهای اصلی:
- آیا یک دانشجو میتواند رزروها یا اطلاعات تماس دانشجوی دیگری را ببیند؟
- آیا کلید یا رمز عبوری در کدی هست که در مرورگر اجرا میشود؟
- آیا فرم ثبتنام در برابر رباتها محافظت شده است؟
- آیا نسخهی پشتیبان از داده وجود دارد؟
صفحهی ما دربارهی آیا وایب کدینگ امن است هر بررسی را توضیح میدهد و پرامپتهایی برای آنها ارائه میکند، و فهرست بررسی امنیت برای اپلیکیشنهای ساختهشده با هوش مصنوعی نسخهی کامل آن است.
گام ۹: انتشار
وقتی حلقهی اصلی، قواعد و بررسیها درست کار کردند، منتشر کنید. در Mythex این یک کلیک است و اپلیکیشن یک نشانی عمومی میگیرد که پایگاه داده و میزبانیاش از قبل آماده است. در Pro میتوانید دامنهی خودتان را وصل کنید، مثلاً book.sarasyoga.com؛ نحوهی وصل کردن دامنهی سفارشی را ببینید.
پیش از فرستادن لینک، یک بار دیگر نسخهی منتشرشده را بررسی کنید. یک کلاس را از گوشی خودتان رزرو کنید. نسخهی تولیدی و پیشنمایش باید یکسان رفتار کنند، اما آن را تأیید کنید.
گام ۱۰: اولین کاربران و نسخهی بعدی
لینک را اول به پنج دانشجوی منظم بدهید، نه همهی آنها. از آنها بخواهید رزرو کلاس بعدیشان را از طریق آن انجام دهند و بگویند چه چیزی گیجکننده بود. سپس سه موردی که بیشتر از همه گفتهاند را برطرف کنید.
بعد از چند هفته استفادهی واقعی، فهرست نسخهی ۲ برای اپلیکیشنی مثل این تقریباً خودبهخود نوشته میشود: لیست انتظار برای کلاسهای پر، یادآوری ایمیلی شب قبل از کلاس، و بستههای کلاس که بهصورت آنلاین پرداخت میشوند. هر کدام همان روند را میگیرند: در چند خط مشخص کنید، پرامپت بدهید، آزمایش کنید، منتشر کنید. برای افزودن پرداخت، نحوهی افزودن پرداخت به اپلیکیشن را ببینید. برای معرفی اپلیکیشن و جذب اولین کاربران، نحوهی راهاندازی اپلیکیشن و جذب اولین کاربران.
تبدیل به اپلیکیشن موبایل
بسیاری از استودیوها میخواهند یک آیکون روی گوشی دانشجوهایشان باشد. در Mythex Pro، اپلیکیشن منتشرشده میتواند به یک اپلیکیشن اندروید (فایلی که در Google Play بارگذاری میکنید) و یک اپلیکیشن آیفون که با کلید App Store Connect خودتان به TestFlight فرستاده میشود، تبدیل شود، بدون مک. اپلیکیشن موبایل، اپلیکیشن وب منتشرشده را باز میکند، پس هر بار که بهروزرسانی منتشر کنید، اپلیکیشن موبایل هم آن را دارد.
نتیجه
خود ساخت بخش کوتاه کار بود. آنچه اپلیکیشن را قابل استفاده کرد، فهرست «در نسخهی ۱ نیست» در مشخصات بود، آزمایش جریان اصلی پیش از هر چیز دیگر، قواعد سمت سرور برای ظرفیت و دسترسی، و پنج کاربر واقعی پیش از پنجاه کاربر. این همان چیزی است که وایب کدینگ وقتی اپلیکیشن باید برای دیگران کار کند به نظر میرسد.
آمادهاید خودتان را امتحان کنید؟ مشخصات یکصفحهایتان را بنویسید، سپس پاراگراف اول را در اپساز هوش مصنوعی بچسبانید. اگر میخواهید نوعهای بیشتری از اپلیکیشن و پرامپتهای پشت آنها را ببینید، نمونههای وایب کدینگ را بخوانید.
پرسشها
ساختن یک اپلیکیشن با وایب کدینگ چقدر طول میکشد؟
یک نسخهی اول متمرکز با چند صفحه، یک پایگاه داده و ورود معمولاً یک روز یا یک آخر هفته زمان میبرد. آزمایش، رفع حالتهای مرزی و یک بررسی امنیتی اغلب به اندازهی ساخت اولیه طول میکشند، پس برای هر دو برنامهریزی کنید.
آیا میتوانم یک اپلیکیشن وایبکدشده را در App Store یا Google Play منتشر کنم؟
بسیاری از سازندهها فقط اپلیکیشن وب میسازند. در Mythex Pro، یک اپلیکیشن منتشرشده میتواند به یک فایل اپلیکیشن اندروید تبدیل شود که خودتان در Google Play بارگذاری میکنید، و یک اپلیکیشن آیفون که با کلید App Store Connect خودتان به TestFlight فرستاده میشود، بدون نیاز به مک. بررسی و ارسال به فروشگاه با خود شماست.
آیا در هیچ مرحلهای به برنامهنویس نیاز دارم؟
برای ساختن و منتشر کردن یک اپلیکیشن کاری لازم نیست. ارزش دارد پیش از کار با پرداخت، دادهی سلامت یا کاربران زیاد، یک برنامهنویس کد را بررسی کند. ابزارهایی که اجازهی خروجی گرفتن از کد یا همگامسازی با GitHub را میدهند، این بررسی را آسان میکنند.
ساختن یک اپلیکیشن با وایب کدینگ چقدر هزینه دارد؟
میتوانید یک اپلیکیشن کوچک را روی سطح رایگان بسازید و منتشر کنید. Mythex Free بدون نیاز به کارت است و انتشار را شامل میشود؛ Pro ماهانه ۲۵ دلار است و ویرایش کد، خروجی گرفتن، GitHub، دامنهی سفارشی و اپلیکیشن موبایل را اضافه میکند. سرویسهای بیرونی مانند ایمیل یا ارائهدهندگان پرداخت جداگانه صورتحساب میشوند.
سختترین بخش ساختن یک اپلیکیشن با وایب کدینگ چیست؟
ساخت اولیه نیست. بخشهای سخت، تصمیمگیری دربارهی چیزهایی است که نسخهی اول کنار میگذارد، آزمایش موقعیتهایی که یک کاربر واقعی به آنها میرسد، و اطمینان از اینکه هر کاربر فقط به دادهی خودش دسترسی دارد. یک مشخصات نوشتهشدهی کوتاه به هر سه کمک میکند.