از نیاز تا MVP : ساخت اکستنشن تبدیل گفتار به متن فارسی برای پشتیبانی باسلام

گاهی بهترین ابزارها از دل یک نیاز خیلی ساده شروع می‌شن.
در تیم پشتیبانی باسلام، اپراتورها مدام باید متن‌های طولانی تایپ می‌کردن — از پاسخ به تیکت‌ها گرفته تا گفتگو با فروشنده‌ها.
برای سرعت دادن به کار، ایده‌ی ساده‌ای مطرح شد:

«کاش می‌شد با صدا حرف بزنیم و متن خودش نوشته بشه.»

در ظاهر ساده بود، ولی وقتی خواستم از اکستنشن‌های آماده‌ی تبدیل گفتار به متن استفاده کنم، متوجه شدم تقریباً هیچ‌کدوم برای زبان فارسی قابل اتکا نیستن:

یا فقط بخشی از واژه‌ها رو درست تشخیص می‌دادن،
یا دکمه‌های عجیبی داشتن که تجربه‌ی کاربری رو خراب می‌کرد،
یا اجازه‌ی سفارشی‌سازی نمی‌دادن.

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

چرا اکستنشن کروم؟

به‌عنوان یک Backend Engineer اولین چیزی که بهش فکر می‌کنی API و سرویسه.
ولی من دنبال یک MVP سریع بودم.
نمی‌خواستم پروداکت یا فرانت پنل پشتیبانی باسلام رو درگیر کنم.
پس اکستنشن بهترین گزینه بود چون:

کاملاً ایزوله است.
در هر صفحه‌ای که خواستی می‌تونه inject بشه.
بدون نیاز به deploy یا backend جدید، کار می‌کنه.

فقط کافیه کاربر اکستنشن رو نصب کنه و مجوز میکروفن بده.

چطور ساختمش؟

برای پیاده‌سازی تبدیل گفتار به متن، از مدل‌های Gemini گوگل استفاده کردم.
مدل پایه‌ای که انتخاب کردم، gemini-2.5-flash-lite بود — چون رایگان، سریع، و برای MVP کاملاً کافی بود.
ولی یه تصمیم مهم گرفتم که باعث شد پروژه از نظر مقیاس‌پذیری خیلی ساده‌تر بشه:

به‌جای اینکه من سمت سرور API Key گوگل رو مدیریت کنم، توپ رو انداختم تو زمین کاربر!

یعنی هر کاربر باید توکن شخصی گوگل AI خودش رو توی تنظیمات اکستنشن وارد کنه.
به این ترتیب:

نیازی به backend برای مدیریت توکن‌ها نداشتیم،
محدودیت‌های نرخ درخواست (quota) بین کاربران تقسیم می‌شد،
و حریم خصوصی بهتر حفظ می‌شد چون صدا مستقیم از مرورگر خودش به گوگل ارسال می‌شد.

این تصمیم ساده، عملاً باعث شد اکستنشن بدون سرور هم قابل استفاده باشه — فقط با نصب و وارد کردن API Key.

طراحی رفتار اکستنشن

در ابتدا هدف این بود که برای تمام فیلدهای متنی (input و textarea) در هر صفحه،
کنار فیلد یک دکمه‌ی میکروفن ظاهر بشه.
ولی در عمل دیدم برای همه‌ی سایت‌ها این رفتار منطقی نیست.
مثلاً توی بعضی صفحات نوشتاری یا فرم‌های حساس (مثل فیلد پسورد یا سرچ)،
نباید دکمه ظاهر بشه.

برای همین دو نوع فیلتر اضافه کردم:

فیلتر دامنه (Domain Filter):
فقط روی سایت‌هایی که کاربر در تنظیمات مشخص می‌کنه فعال بشه،
مثلاً فقط روی basalam.com یا support.basalam.com
فیلتر فیلد (Selector Filter):
فقط روی عناصر خاص مثل textarea یا فیلدهایی با کلاس‌های مشخص
(مثلاً .chat-input یا [data-voice-enabled]) دکمه اضافه بشه.

تجربه‌ی شخصی

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

لینک پروژه : github