اگر قصد دارید یک ابزار هوش مصنوعی را برای موبایل عرضه کنید، باید بدانید که سختترین بخش کار، کدنویسی نیست؛ بلکه اصطکاکهای موجود در اکوسیستم توزیع است. در ماه اوت، سازنده PromptSpend — کسی که ۱۵ سال سابقه مدیریت عملیات و سود و زیان (P&L) داشت و پیش از این برنامهنویس اپلیکیشن نبود — جزئیات تبدیل ماشینحساب متنباز هزینههای LLM خود را از یک ابزار وب به اپلیکیشنهای زنده iOS و اندروید شرح داد.
برای مدیران کسبوکاری که در حال استقرار هوش مصنوعی هستند، بزرگترین ترس «شوک صورتحساب» (Bill Shock) است که معمولاً بلافاصله پس از عرضه یک ویژگی جدید رخ میدهد. PromptSpend این مشکل را حل میکند. کاربران میتوانند گفتگوهای نمونه و نماینده از ترافیک خود را در این ابزار قرار دهند تا هزینه اجرای آنها را در ۸۰ مدل مختلف از ۱۲ ارائهدهنده مختلف محاسبه کنند. این ابزار در واقع یک حفاظ (Guardrail) مالی است تا پیش از ارسال حتی یک توکن (Token) — که مثل برشهای کوچک یک کیک طولانی است و مدلها متن را تکهتکه میخورند — به محیط عملیاتی، هزینهها پیشبینی شود. این رویکرد در راستای تبدیل ایدههای اولیه به ابزارهای تجاری است، مشابه آنچه در شش گام مهندسی برای تبدیل دموهای RAG به محصولات عملیاتی بررسی کردیم تا ریسکهای عملیاتی کاهش یابد.
سازوکار فنی و دقت دادهها
این ابزار به یک پرسش مشخص پاسخ میدهد: «اجرای این مورد چقدر هزینه دارد؟». کاربران میتوانند سطح ترافیک خود را انتخاب کنند تا هزینههای پیشبینیشده را برای هر گفتگو، روز، ماه و سال مشاهده کنند. اپلیکیشن از همان کاتالوگی استفاده میکند که در سایت promptspend.com موجود است و قیمتها هر روز صبح بازبینی میشوند. هر قیمت نمایش داده شده، شامل منبع استخراج داده و تاریخی است که آخرین بار تأیید شده است.
توسعهدهنده برای حفظ دقت، یک تصمیم معماری حیاتی گرفت: اپلیکیشن هیچ جدول قیمت داخلی (Internal Price Table) ندارد. منطق او این بود که یک جدول bundled در روز ساخت درست است، اما هر روز پس از آن بهطور نامحسوسی غلط میشود. بنابراین، اپلیکیشن در لحظه اجرا، کاتالوگ زنده را فراخوانی میکند. اگر این فراخوانی شکست بخورد، برنامه برای ۲۴ ساعت از نسخه ذخیرهشده (Cache) استفاده کرده و یک هشدار قابل مشاهده نمایش میدهد؛ پس از گذشت ۲۴ ساعت، برنامه از محاسبه امتناع میکند تا از ارائه دادههای «با اعتماد اما غلط» جلوگیری کند.
حریم خصوصی نیز از طریق پردازش روی دستگاه (On-device processing) مدیریت میشود. شمارش توکنها بهصورت محلی روی گوشی انجام میشود و این یعنی هیچ دادهای از کسبوکار کاربر آپلود یا ذخیره نمیشود. این اپلیکیشن هیچ سیستم حساب کاربری، SDK تبلیغاتی یا شناسههای تحلیلی (Analytics Identifiers) ندارد. خروجیهای قابل اشتراک — مانند خلاصهها، مقایسه چهار مدل، فایلهای CSV و رسیدها — تنها بر اساس تعداد توکنها و هزینهها ساخته میشوند و هرگز از متن اصلی کاربر استفاده نمیکنند.
چالشهای QA و سختافزار
این برنامه با استفاده از Expo و React Native ساخته شده است. موتور محاسبه هزینهها در یک بسته (Package) مشترک استخراج شده است تا اطمینان حاصل شود که اپلیکیشن وب، API، سرور MCP و اپلیکیشنهای موبایل همگی از محاسبات ریاضی یکسانی استفاده میکنند. از آنجایی که توسعهدهنده از سطح رایگان Expo استفاده میکرد که تعداد بیلدهای iOS در ماه را محدود میکند، هر بیلد باید کاملاً آماده انتشار میبود و این امر او را مجبور به دستهبندی منضبط اصلاحات کرد.
با وجود اینکه تستهای خودکار تماماً «سبز» بودند، اما تست روی دستگاههای واقعی (از جمله یک آیفون، آیپد و یک گوشی Galaxy A15 ارزانقیمت به قیمت ۱۰۳ دلار) خطاهای بحرانی را آشکار کرد:
- خطاهای مسیریابی (Routing): یک مسیریاب مبتنی بر فایل، بهاشتباه صفحه Estimate را بهعنوان ریشه (Root) تنظیم کرده بود که باعث میشد تب Home نادیده گرفته شود. راه حل این بود که صفحه Estimate به مسیر (Route) اختصاصی خود منتقل شود و ریشه به یک Redirect تبدیل گردد.
- تبهای شبح در اندروید: یک فایل کمکی Layout در پوشه routes باعث شده بود مسیریاب اندروید یک تب ششمِ ناشناخته را ثبت کند. برای رفع این مشکل، فایل جابهجا شد و یک بررسی در زمان Release اضافه شد تا اگر دوباره این اتفاق افتاد، بیلد شکست بخورد.
- ناهماهنگی در راهنمای کاربر (Tour): کادرهای هایلایت در تور راهنمای کاربر در اندروید در جای اشتباه قرار میگرفتند. پس از سه دور تلاش ناموفق برای اصلاح مختصات، توسعهدهنده روش را تغییر داد تا هر عنصر هایلایتشده، خط دور (Outline) خود را بهصورت مستقل رسم کند.
- برش رابط کاربری (UI Clipping): در صفحههای کوچک اندروید، برخی عناصر در لبه راست بریده میشدند. این مشکل با یک اصلاح کلی در Layout حل شد، نه با وصلههای جداگانه برای هر صفحه.
دیوار بوروکراسی
به نقل از سازنده پروژه، زمان صرفشده برای کاغذبازیها و امور اداری بیشتر از زمان کدنویسی بود. تبدیل حساب کاربری شخصی به سازمانی در اپل باعث شد فرآیند بیلدها در طول مهاجرت متوقف شود. به همین ترتیب، گوگل پلی برای تایید هویت سازمانی، شماره D-U-N-S، بررسیهای شناسایی سازمان و تایید وبسایت را الزامی کرده است.
برای حسابهای شخصی توسعهدهنده که بعد از نوامبر ۲۰۲۳ ایجاد شدهاند، گوگل یک تست بسته (Closed Test) با حداقل ۱۲ تستر داوطلب برای ۱۴ روز متوالی را پیش از دسترسی به محیط Production اجباری کرده است. از آنجایی که حسابهای سازمانی از این قانون مستثنی هستند، توسعهدهنده حساب خود را به سازمانی تبدیل کرد تا از این تأخیر در تست اجتناب کند.
این تجربه ثابت میکند که برای توسعهدهندگان مستقل AI در عصر مدرن، «مایل آخر» توزیع، یک مانع رگولاتوری و اداری است. نوشتن یک Wrapper کاربردی برای مدلهای زبانی اکنون تافه و ساده شده است؛ اما توانایی عبور از مراحل تایید سازمانی در اپاستور، گلوگاه واقعی است.
گام بعدی شما
- اگر برای موبایل برنامهریزی میکنید، برای ثبت D-U-N-S و تایید هویت هفتهها زمان در نظر بگیرید، نه روزها.
- هرگز به تستهای شبیهساز اعتماد نکنید؛ یک گوشی اندرویدی ارزانقیمت تنها راه اثبات صحت Layout شماست.
- برای کاهش ریسک، ابتدا نسخه وب را عرضه کنید و سپس وارد مارکتهای موبایل شوید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو