ساخت اولین اپ با هوش مصنوعی؛ از ایده تا سفارش واقعی

اول یک مسیر واقعی را انتخاب کن

برای شروع ساخت اپ با هوش مصنوعی، لازم نیست یک سوپراپ تعریف کنی. یک کار کوچک انتخاب کن که از ابتدا تا انتها قابل انجام باشد. مثال این راهنما یک کافهٔ فرضی است: مشتری منو را می‌بیند، نوشیدنی انتخاب می‌کند، سفارش را ثبت می‌کند و شمارهٔ پیگیری می‌گیرد. این مثال آموزشی است و گزارش درآمد یا نتیجهٔ یک مشتری واقعی نیست. هدف، ساختن چیزی است که بتوانی با دست امتحانش کنی، نه جمع‌کردن قابلیت‌هایی که فقط در صفحهٔ اول زیبا به نظر می‌رسند.

در نسخهٔ اول، پرداخت را آزمایشی نگه دار و مدیریت چند شعبه، باشگاه مشتریان و پیشنهاد هوشمند را کنار بگذار. این حذف‌ها شکست نیستند؛ به تو کمک می‌کنند بفهمی آیا مسیر سفارش قابل استفاده است یا نه. اگر هنوز نمی‌توانی در یک جمله بگویی کاربر چه کاری را تمام می‌کند، قبل از بازکردن ابزار کدنویسی، چارچوب تبدیل ایده به PRD را مرور کن. خروجی این مرحله باید یک مسئله، یک نوع کاربر و یک پایان قابل مشاهده باشد.

خواسته را به قرارداد قابل آزمون تبدیل کن

«یک اپ مدرن و حرفه‌ای بساز» ورودی کافی نیست. ایجنت نمی‌داند حرفه‌ای برای تو یعنی چه، موجودی از کجا می‌آید و اگر سفارش ثبت نشد چه باید نشان دهد. فایل PRD همراه این مقاله را بردار و بخش‌های کاربر، جریان اصلی، خارج از دامنه و معیار پذیرش را با مثال خودت پر کن. جملهٔ خوب این است: مشتری بدون ورود منو را می‌بیند، اما برای ثبت سفارش باید اطلاعات لازم را وارد کند؛ اگر محصول ناموجود شد، سرور سفارش آن محصول را نمی‌پذیرد و سبد باقی می‌ماند.

برای هر قابلیت، حالت موفق و حالت خطا بنویس. در انتخاب محصول، افزایش تعداد و حذف‌کردن را جداگانه ببین. در ثبت سفارش، دوبار لمس دکمه و قطع اینترنت را هم مشخص کن. در پنل کافه، تعریف کن چه کسی اجازهٔ دیدن سفارش‌ها را دارد. همین جزئیات جلوی بخشی از بازنویسی‌ها را می‌گیرد، چون ایجنت مجبور نیست رفتار مهم محصول را از روی ظاهر صفحه حدس بزند. معیار پذیرش را با رفتار کاربر بنویس، نه با اسم یک فایل یا تابع در کد.

کمترین ابزار لازم را انتخاب کن

این پروژه به رابط کاربری، بخش سرور و محل ماندگار ذخیرهٔ سفارش نیاز دارد. لازم نیست از روز اول چند سرویس متفاوت برای هرکدام انتخاب کنی. ابزار مناسب، ابزاری است که بتوانی کدش را نگه داری، لاگش را بخوانی و نسخهٔ جدیدش را منتشر کنی. قبل از انتخاب، یک آزمایش کوچک انجام بده: آیا محیط اجرا می‌تواند به دیتابیس و سرویس‌های موردنیاز تو وصل شود؟ داشتن یک صفحهٔ آنلاین، پاسخ این سؤال را نمی‌دهد؛ یک عملیات ذخیره و خواندن را روی همان محیط امتحان کن.

اگر ابزارهای مختلف برایت مبهم‌اند، از راهنمای انتخاب ابزار AI کمک بگیر. برای این تمرین، نام برند ابزار اهمیت کمتری از روشن‌بودن قرارداد دارد. ایجنت باید بداند کجا اجازهٔ تغییر دارد، چه چیزی باید تست شود و چه وقت کار تمام است. کلید سرویس و رمز دیتابیس را در مرورگر، فایل عمومی یا توضیح مسئله قرار نده. برای نمونه‌سازی از دادهٔ ساختگی استفاده کن و دسترسی محیط آزمایشی را از حساب‌های واقعی جدا نگه دار.

مرحلهٔ اول: منوی خواندنی و سبد قابل پیش‌بینی

اول فقط منو و سبد را بساز. برای شروع چند محصول ساختگی با نام، شناسه، قیمت و وضعیت موجودی کافی است. مشتری باید بتواند محصول را اضافه کند، تعداد را تغییر دهد و جمع را ببیند. از ایجنت بخواه روی صفحهٔ کوچک هم جریان کامل را بررسی کند؛ فقط اسکرین‌شات دسکتاپ کافی نیست. این مرحله هنوز سفارش واقعی نمی‌سازد، اما به تو فرصت می‌دهد متن‌ها، اندازهٔ دکمه‌ها و تفاوت حالت خالی و پر را قبل از اضافه‌شدن سرور اصلاح کنی.

• اگر تعداد یک محصول به صفر رسید، از سبد حذف شود و جمع دوباره حساب شود.
• محصول ناموجود دکمهٔ قابل‌استفاده برای افزودن نداشته باشد و دلیل آن به زبان روشن نوشته شود.
• بارگذاری ناموفق منو، پیام قابل‌فهم و امکان تلاش دوباره داشته باشد؛ صفحهٔ سفید معیار پایان نیست.

مرحلهٔ دوم: سفارش را واقعاً در سرور ذخیره کن

اکنون دکمهٔ ثبت سفارش باید به سرور برسد و یک رکورد ماندگار بسازد. مرورگر شناسهٔ محصول و تعداد را می‌فرستد؛ سرور قیمت معتبر و موجودی را از دادهٔ خودش می‌خواند. قیمت ارسالی مرورگر قابل اعتماد نیست، حتی اگر رابط تو هیچ راه آشکاری برای تغییر آن نداشته باشد. در پاسخ موفق، شناسهٔ سفارش نمایش بده. اگر صفحه بسته و دوباره باز شد، سفارش نباید از سیستم کافه ناپدید شود. ذخیره در حافظهٔ مرورگر جای دیتابیس سفارش را نمی‌گیرد.

یک شناسهٔ درخواست برای ثبت سفارش در نظر بگیر تا تکرار همان درخواست، دو سفارش نسازد. این رفتار را با دوبار لمس دکمه و تلاش مجدد بعد از قطع اینترنت امتحان کن. دکمهٔ غیرفعال فقط به تجربهٔ کاربری کمک می‌کند و محافظت اصلی باید در سرور باشد. از ایجنت بخواه توضیح دهد کدام تست یا بررسی ثابت می‌کند داده ذخیره شده و تکرار درخواست بی‌اثر است. اگر فقط پیام موفقیت ساخته ولی ذخیره‌سازی ندارد، این مرحله هنوز کامل نشده است.

مرحلهٔ سوم: مدیریت سفارش و پرداخت را جدا اضافه کن

پنل کافه باید سفارش ثبت‌شده را نشان دهد و تغییر وضعیت مشخصی مثل «در حال آماده‌سازی» داشته باشد. برای بررسی مجوز، فقط منوی پنل را پنهان نکن؛ درخواست سرور را با کاربر بدون دسترسی هم آزمایش کن. کاربر عادی نباید با تغییر آدرس بتواند سفارش بقیه را بخواند. ابتدا این جریان را با پرداخت آزمایشی کامل کن. وقتی ثبت سفارش و مجوزها پایدار شد، اتصال پرداخت واقعی را به‌عنوان مرحله‌ای جدا با داده و تنظیمات محیط خودش انجام بده.

پایان صفحهٔ درگاه، اثبات پرداخت نیست. بخش سرور باید وضعیت تراکنش را از سرویس پرداخت بررسی کند و نتیجه را با سفارش مرتبط سازد. این قسمت حالت‌های دیررس و تکراری دارد؛ برای جزئیات، چک‌لیست ساخت پرداخت قابل اتکا را بخوان. وعدهٔ پایان پروژه را به «دکمهٔ پرداخت باز شد» محدود نکن. معیار درست این است که سفارش فقط پس از تأیید معتبر، یک بار پرداخت‌شده شود و کاربر راهی برای دیدن نتیجهٔ نامعلوم داشته باشد.

هر مرحله را تحویل بگیر، بعد سراغ بعدی برو

در هر تحویل، سه چیز بخواه: چه رفتار قابل مشاهده‌ای اضافه شد، چطور بررسی شد و چه محدودیتی باقی مانده است. لازم نیست برای فهم این گزارش برنامه‌نویس حرفه‌ای باشی. خودت با گوشی مسیر را اجرا کن و از ایجنت بخواه حالت خطا را هم نشان دهد. تغییرات هر مرحله را در یک نسخهٔ قابل بازگشت نگه دار. وقتی صفحهٔ سفارش درست کار می‌کند، هم‌زمان طراحی کل سایت و مدل دیتابیس را عوض نکن؛ تشخیص علت خرابی بعدی دشوار می‌شود.

قبل از دادن لینک به کاربران، راهنمای انتشار اولین اپ را اجرا کن. نسخهٔ منتشرشده را با همان سناریوهایی امتحان کن که محلی تست کردی. یک نفر دیگر که فایل توضیح پروژه را ندیده، باید بتواند بدون راهنمایی تو سفارش بسازد. سؤال‌های او را ثبت کن؛ همین‌ها ورودی نسخهٔ بعد هستند. اگر هنوز مرحله‌ای دستی است، آن را در محصول و برنامهٔ کاری روشن نگه دار. هدف نسخهٔ اول، یک جریان کوچک و قابل اتکا است که بتوان آن را با بازخورد واقعی بهتر کرد.