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

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

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

تصاویر این مقاله از HTMLهای نمونهٔ ارسالی، پس از اصلاح متن و منطق محاسبه، در یک قاب نمایشی روشن شبیه فضای کار کُندا تهیه شده‌اند. گفتگوهای داخل قاب بازسازی آموزشی‌اند؛ این تصاویر گزارش اجرای موتور کُندا نیستند. محاسبات خود نمونهٔ محلی در ۸ آبان ۱۴۰۵ بررسی شده‌اند. همهٔ نرخ‌ها ساختگی‌اند؛ قیمت بازار یا تعرفهٔ کُندا نیستند.

این ابزار به درد چه کسب‌وکاری می‌خورد؟

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

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

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

قبل از طراحی فرم، فرمول را چطور بنویسیم؟

تا وقتی خودت نتوانی یک مثال را روی کاغذ حساب کنی، درخواست «یک محاسبه‌گر دقیق بساز» کافی نیست. برای نمونهٔ این مقاله پنج تصمیم می‌گیریم:

فرمول در دو مرحله خواناتر است:

جمع خدمات = هزینهٔ پایه + (تعداد صفحه × هزینهٔ هر صفحه) + پیگیری اختیاری
برآورد = جمع خدمات × ضریب فوری

ضریب فوری در حالت عادی ۱ و در حالت انتخاب‌شده ۱٫۲ است. ترتیب مهم است: در این مثال، افزایش ۲۰درصدی روی جمع خدمات، شامل پیگیری اعمال می‌شود. اگر در کار تو فقط دستمزد طراحی مشمول افزایش است، فرمول را همان‌جا تغییر بده؛ رابط زیبا این ابهام را حل نمی‌کند.

برای سه صفحه همراه پیگیری، جمع خدمات ۴ میلیون تومان می‌شود. با انتخاب حالت فوری، ۸۰۰ هزار تومان اضافه می‌شود و برآورد به ۴٬۸۰۰٬۰۰۰ تومان می‌رسد. «فوری» در این نمونه صرفاً یک قاعدهٔ قیمت است؛ وعدهٔ تحویل در یک روز مشخص نیست.

چه پرامپتی به ابزار سازنده بدهیم؟

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

این درخواست، محدودهٔ نسخهٔ اول را نگه می‌دارد:

یک ماشین‌حساب فارسی و راست‌به‌چپ برای برآورد خدمات طراحی صفحات معرفی بساز. نرخ‌ها ساختگی و آموزشی‌اند: پایه ۲٬۰۰۰٬۰۰۰ تومان، هر صفحه ۵۰۰٬۰۰۰، پیگیری اختیاری ۵۰۰٬۰۰۰. تعداد صفحه فقط عدد صحیح ۱ تا ۱۰ باشد. فوری بودن اختیاری، جمع این سه بخش را در ۱٫۲ ضرب کند. ریز هزینه و موارد خارج از محاسبه را نشان بده. ورودی خالی یا نامعتبر، پیام مشخص و بدون مبلغ قدیمی داشته باشد. تبدیل تومان به ریال فقط نمایش را ۱۰ برابر کند. پرداخت، ذخیره‌سازی و پیش‌فاکتور رسمی نداریم. روی گوشی هم خوانا باشد.

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

فرم خوب چه چیزی را به مشتری نشان می‌دهد؟

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

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

متن زیر مبلغ بهتر است کوتاه و مشخص باشد: «این برآورد با انتخاب‌های فعلی محاسبه شده؛ شرح کار و مبلغ نهایی پیش از شروع تأیید می‌شود.» سپس موارد خارج از محاسبه را نام ببر. عبارت کلی «هزینه‌ها ممکن است تغییر کنند» به‌اندازهٔ یک فهرست روشن به تصمیم مشتری کمک نمی‌کند.

پنج مثالی که جوابشان باید از قبل معلوم باشد

جواب مورد انتظار را مستقل از ابزار حساب کن؛ بعد همان ورودی را در فرم بزن. در بررسی محلی این مقاله، پنج حالت زیر در رابط وارد شدند و خروجی هر پنج حالت با انتظار برابر بود:

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

با ورودی اشتباه و تفاوت تومان و ریال چه کنیم؟

اگر مشتری تعداد صفحه را پاک کند، صفر بزند یا ۱٫۵ وارد کند، خروجی قبلی نباید همچنان مثل برآورد معتبر دیده شود. در نمونه، ورودی خالی و صفر را در رابط بررسی کردیم: مبلغ مخفی شد و پیام «تعداد صفحه را با یک عدد صحیح بین ۱ تا ۱۰ وارد کن» نمایش داده شد. منطق محاسبه نیز صفر، منفی، اعشار، بیش از ۱۰ و عدد نامعتبر را رد کرد.

برای فیلد عددی، محدودیت‌های min، max و step مفیدند، اما بررسی سمت مرورگر جای اعتبارسنجی سرور را نمی‌گیرد. اگر بعدها درخواست را ذخیره یا برای پرداخت ارسال می‌کنی، سرور باید ورودی و مبلغ را دوباره با قواعد معتبر خودش محاسبه کند. مرجع فیلد عددی MDN همین مرز اعتبارسنجی مرورگر را توضیح می‌دهد.

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

روی گوشی چه چیزی را بررسی کنیم؟

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

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

برآورد چه زمانی به پیشنهاد نهایی تبدیل می‌شود؟

ماشین‌حساب سؤال اول مشتری را پاسخ می‌دهد، اما هنوز دربارهٔ جزئیات کار توافق نکرده‌اید. پیش از شروع، تعداد و نوع خروجی، مسئول تهیهٔ محتوا، دفعات اصلاح، زمان‌بندی و موارد خارج از محدوده را روشن کنید. مبلغ تأییدشده را همراه همین شرح کار ثبت کن؛ یک عدد تنها، سابقهٔ قابل فهمی از توافق نمی‌سازد.

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

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

قدم بعدی: ماشین‌حساب کوچک خودت را بساز

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

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