در یک نگاه: MAKAN Translate با هدف کمک به دوستی شکل گرفت که می‌خواست با زیرنویس ترجمه‌شده یک دوره Udemy، لینوکس یاد بگیرد. تولید بصری برنامه، عامل‌های کدنویس، مدل‌های تجاری و محلی و روش‌های گوناگون آزمایش را امتحان کردم. یک دوره فشرده حدوداً ده‌روزه به پروژه‌ای قابل‌توجه انجامید، نه به مترجمی بی‌نقص. درس اصلی این نبود که چگونه یک پرامپت جادویی بنویسم؛ بلکه این بود که چگونه کار را به بخش‌های قابل راستی‌آزمایی تقسیم کنم و محدودیت‌های AI را بشناسم.
چکیده
برنامه‌نویسی با کمک هوش مصنوعی می‌تواند رابط کاربری و کد اجرایی را با سرعت تولید کند، اما ساخت نرم‌افزار قابل نگهداری به پژوهش امکان‌سنجی، یکپارچه‌سازی اجزا، ارزیابی مدل، آزمون رگرسیون و کنترل دامنه پروژه نیاز دارد. این مطالعه موردی تجربه‌محور به توسعه MAKAN Translate می‌پردازد؛ مترجمی رایگان و چندموتوره که از محدودیت‌های ترجمه زیرنویس هنگام یادگیری لینوکس با یک دوست آغاز شد. گزارش، چهار رویکرد توسعه با Google AI Studio، ChatGPT/Codex، Claude Code و Antigravity را بازسازی می‌کند؛ تقسیم وظایف میان پژوهش، بازبینی، کدنویسی و آزمایش دستی را توضیح می‌دهد؛ و مشکلات پردازش اسناد فارسی، تشخیص گفتار، سازگاری مدل‌ها و بومی‌سازی بازی‌ها را بررسی می‌کند. این متن بر خاطرات توسعه‌دهنده و مستندات عمومی پروژه استوار است، نه بر آزمایش کنترل‌شده برای مقایسه ابزارهای AI. یافته کیفی اصلی آن است که تقسیم کار به وظایف کوچک و اعتبارسنجی نتایج، در تجربه من از پرامپت‌های طولانی‌تر یا انتخاب یک دستیار کدنویسی خاص مؤثرتر بود.
واژگان کلیدی: توسعه نرم‌افزار به کمک هوش مصنوعی؛ همکاری انسان و AI؛ توسعه تدریجی؛ راستی‌آزمایی نرم‌افزار؛ ترجمه ماشینی چندزبانه؛ فارسی؛ مدل‌های زبانی محلی؛ متن‌باز.
——————————————————————————————
۱. مسئله از دوستی شروع شد که می‌خواست لینوکس یاد بگیرد
MAKAN Translate با طرح تجاری آغاز نشد؛ با یک دوست شروع شد.
ما با یک دوره Udemy در حال یادگیری لینوکس بودیم. من آموزش انگلیسی را می‌فهمیدم، اما دوستم با زبان مشکل داشت. او می‌خواست همراه ما درس بخواند. راه‌حل در نگاه اول ساده به نظر می‌رسید: زیرنویس‌ها را ترجمه کنیم تا به‌جای درگیر شدن با زبان، بر مفاهیم فنی تمرکز کند.
به سراغ دستیارهای عمومی هوش مصنوعی رفتم. آن‌ها می‌توانستند متن کوتاهی را ترجمه کنند و گاهی نتیجه هم خوب بود. اما یک دوره آموزشی فقط یک پاراگراف نیست؛ فایل‌های زیرنویس فراوان و اصطلاحات تکرارشونده دارد. ترجمه دو یا سه فایل گاهی سهمیه رایگانم را تمام می‌کرد و مجبور می‌شدم تا زمان باز شدن دوباره دسترسی صبر کنم. کیفیت نیز در زبان‌های مختلف یکسان نبود. ابزاری می‌خواستم که بتواند یک کار واقعی را تا پایان انجام دهد.
همین ناامیدی در ترجمه اسناد PDF، به‌ویژه با زبان فارسی، تکرار شد. سرویس‌های موجود همیشه محتوا و قالب‌بندی را درست حفظ نمی‌کردند و محدودیت استفاده نیز پابرجا بود. ادعا نمی‌کنم مترجم PDF خودم این مسئله را به‌طور کامل حل کرده است؛ بخشی از مشکلات هنوز وجود دارند.
پیش‌تر نرم‌افزارهایی ازجمله Epsilon Download Manager ساخته بودم و در حال یادگیری هوش مصنوعی بودم. از خودم پرسیدم: آیا می‌توانم مترجمی رایگان بسازم که به‌جای وابستگی به یک سرویس محدود، چند موتور ترجمه را در اختیار کاربر بگذارد؟
نسخه نخست بسیار ساده بود: رابطی متصل به API ترجمه. این نمونه نشان می‌داد درخواست ترجمه از داخل برنامه ممکن است، اما محدودیت‌ها و خطاهای API را نیز به ارث می‌برد. آن روزها موفق شدن یک فراخوانی API را با قابل‌اعتماد بودن یک برنامه اشتباه گرفته بودم.
۲. چهار رویکرد توسعه و دلیل اینکه هیچ‌کدام معجزه نبودند
تلاش نخست: رابطی زیبا، بدون محصول کامل
اولین آزمایش جدی من با Google AI Studio بود. وعده تبدیل ایده به برنامه جذاب بود. خروجی در نگاه اول چشمگیر به نظر می‌رسید: صفحه‌ها و کنترل‌ها و چیدمان در زمانی کوتاه پدیدار می‌شدند. ولی وقتی می‌خواستم واقعاً از قابلیت‌ها استفاده کنم، بخش زیادی ناقص یا نامطمئن بود. در پروژه‌های دیگر نیز تجربه مشابهی داشتم. ظاهر محصول زودتر از عملکرد واقعی آن آماده شده بود.
رابط کاربری قانع‌کننده، نشانه موفقیت در تولید طرح است؛ نه اثبات کارکرد نرم‌افزار.
تلاش دوم: کد قابل اجرا و چرخه پایان‌ناپذیر اصلاح
بعد به ChatGPT و Codex روی آوردم. نخستین برنامه اجرایی واقعاً مرا شگفت‌زده کرد. برخلاف یک ماکت، بخشی از کد کار می‌کرد. اما با بیشتر شدن درخواست‌ها، فاصله میان «AI می‌گوید قابلیت را ساخته» و «قابلیت مطابق نیاز من کار می‌کند» بیشتر شد.
خطا را گزارش می‌دادم، توضیح و اصلاح دریافت می‌کردم و با مشکل دیگری مواجه می‌شدم. سهمیه توکن‌هایم به پایان رسید، بی‌آنکه به نتیجه مورد انتظار رسیده باشم. مسئله این نبود که Codex توانایی کدنویسی ندارد؛ مسئله این بود که از یک سیستم خواسته بودم یک چشم‌انداز بزرگ را درک، طراحی، پیاده‌سازی و در نهایت خودش ارزیابی کند.
تلاش سوم: دستیار قوی‌تر، هزینه را حذف نکرد
سپس Claude Code را با اعتباری تبلیغاتی در حدود ۱۰۰ دلار آزمایش کردم. بنا بر خاطرم، این اعتبار تقریباً طی نیم‌روز مصرف شد و برنامه هنوز فاصله زیادی تا آماده شدن داشت. این مشاهده مربوط به شیوه کار خودم است، نه معیار علمی برای هزینه یا کارایی Claude Code در همه شرایط.
فهمیدم تعداد توکن‌های مصرف‌شده، حجم فعالیت ابزار و خطوط کد تولیدی، لزوماً معادل ارزش واقعی تحویل‌داده‌شده نیستند.
تلاش چهارم: توانایی خوب در تولید کد، درک نامطمئن هدف
سیستم سهمیه‌بندی Antigravity برای جلسات طولانی‌تر، از نظر من کاربردی‌تر بود. کد فراوانی تولید می‌کرد، اما گاهی ساعت‌ها چیزی می‌ساخت که با خواسته اصلی من متفاوت بود. پس از اصلاح‌های مکرر پیشرفت کردم، ولی میزان پیشرفت مفید کمتر از حجمی بود که کدها نشان می‌دادند.
سرانجام جست‌وجو برای یافتن یک AI همه‌فن‌حریف را متوقف کردم و روش کار را تغییر دادم.
۳. نقطه عطف: تقسیم مسئولیت‌ها
از ChatGPT برای پژوهش، توضیح و مقایسه راهکارها استفاده کردم؛ از Perplexity هر زمان سهمیه رایگانش اجازه می‌داد؛ از Claude به‌عنوان راهنمای فنی و بازبین اشکال‌ها؛ و از Antigravity بیشتر برای پیاده‌سازی کد. تصمیم‌های محصول، استفاده واقعی و تأیید نهایی نتایج بر عهده خودم بود.
این یک چارچوب رسمی «چندعاملی» نبود، بلکه تقسیم کاری عملی با مدیریت انسان بود. چنین روشی احتمال اینکه نویسنده کد تنها داور کار خودش باشد را کاهش داد و مرا مجبور کرد پیش از پیاده‌سازی دقیق‌تر توضیح دهم که هر قابلیت باید چه کاری انجام دهد.
روند کارم به این صورت درآمد:
- به‌جای سفارش یک محصول کامل، یک مسئله مشخص کاربر را تعریف کنم.
- مدل‌ها، کتابخانه‌ها، سخت‌افزار، محدودیت استفاده و سازگاری را بررسی کنم.
- قابلیتی کوچک با نتیجه قابل مشاهده مشخص کنم.
- همان قابلیت را با کمترین تغییر در کد سالم پیاده کنم.
- در سناریوی واقعی آزمایش کنم، خطاها را بازتولید کنم و در صورت امکان آزمون رگرسیون اضافه کنم.
- تنها پس از رسیدن به عملکرد قابل قبول، آن بخش را گسترش دهم.
این روش به اصول شناخته‌شده مهندسی نرم‌افزار، مانند تجزیه مسئله و توسعه تدریجی، نزدیک است. کشف شخصی من این بود که وقتی مدل می‌تواند سریع‌تر از توان من برای اعتبارسنجی کد تولید کند، این اصول تا چه اندازه مهم می‌شوند.
نخستین موفقیت‌های جدی در ترجمه متن و افزونه مرورگر به دست آمد. نه فوری بودند و نه بدون خطا؛ ولی پس از اصلاح‌های پی‌درپی، در عمل کار می‌کردند و پایه‌ای برای توسعه پروژه بزرگ‌تر فراهم کردند.
۴. ترجمه یک مسئله فنی واحد نیست
برنامه به‌تدریج چند جریان کاری متفاوت را کنار هم آورد. مترجم متن، پردازشگر زیرنویس، تشخیص‌دهنده گفتار، مبدل سند و افزونه مرورگر ممکن است مدل زبانی مشترکی داشته باشند، اما نیازهای مهندسی آن‌ها یکسان نیست.
زیرنویس: حفظ چیزی فراتر از کلمات
فایل‌های زیرنویس متن و ساختار زمانی دارند. برای فایل‌های .srt و .vtt باید از حذف بی‌صدای خطوط، تغییر زمان‌بندی و تخریب قالب خروجی جلوگیری کرد. زیرنویس‌های آموزش فنی یک نیاز دیگر نیز دارند: فرمان‌های لینوکس، مسیر فایل‌ها، گزینه‌های دستور و اصطلاحات تخصصی نباید هنگام ترجمه توضیحات تغییر نادرست پیدا کنند.
ترجمه روان الزاماً ترجمه وفادار نیست. آزمایشی که فقط غیرخالی بودن خروجی را بررسی می‌کند، ثابت نمی‌کند که دستور فنی درست منتقل شده است.
فارسی: پشتیبانی اعلام‌شده در برابر کیفیت کاربردی
یافتن مدل‌هایی که واقعاً با فارسی مناسب کار کنند از سخت‌ترین مراحل پژوهش بود. ممکن بود یک مدل در صفحه معرفی خود نام فارسی را داشته باشد، اما نصب آن خطا بدهد، اجرای محلی‌اش گران باشد یا خروجی ضعیفی تولید کند. مدل‌های زیادی دانلود و آزمایش کردم و با خطا، ناسازگاری و نتایج ناامیدکننده روبه‌رو شدم.
NLLB-200 متا گزینه‌ای چندزبانه و امیدوارکننده بود. مدل‌های عمومی Gemma و Qwen را نیز بررسی کردم. بعدتر TranslateGemma در آزمایش‌های غیررسمی من عملکرد جالبی داشت. این تجربه یک رتبه‌بندی کنترل‌شده نیست: مجموعه داده ثابت عمومی، داوری انسانی کور، تنظیمات اجرای یکسان و تحلیل آماری برای مقایسه مدل‌ها نداشتم.
TranslateGemma در ژانویه ۲۰۲۶ با اندازه‌های 4B، 12B و 27B و پشتیبانی اعلام‌شده از ۵۵ زبان معرفی شد [۲]. پژوهش NLLB-200 دامنه زبان‌های گسترده‌تری را دنبال می‌کرد [۱]. هیچ‌کدام به‌تنهایی ثابت نمی‌کنند که کدام مدل برای زیرنویس فارسیِ مورد استفاده من بهترین است؛ این موضوع به آزمایش اختصاصی نیاز دارد.
صوت: تشخیص گفتار و ترجمه، دو منبع خطای جداگانه‌اند
با ورود به ترجمه رسانه، تشخیص گفتار به مسئله تحقیقاتی دیگری تبدیل شد. در آزمایش‌های من، خانواده Whisper کاربردی‌ترین گزینه‌ای بود که در نهایت انتخاب کردم و large-v3 برای نیازهایم بهترین نتیجه را داد. این گفته به معنای انحصاری بودن Whisper یا برتری قطعی آن در همه شرایط نیست؛ کیفیت مدل‌ها با زبان و سخت‌افزار تغییر می‌کند [۳].
یک جریان کاری معمول ممکن است در استخراج صوت، تشخیص گفتار، بخش‌بندی، ترجمه، هم‌ترازی زمان یا خروجی گرفتن شکست بخورد. خطا در مراحل ابتدایی به مراحل بعدی منتقل می‌شود. بنابراین قابلیت ترجمه رسانه صرفاً افزودن یک دکمه جدید نیست.
اسناد: PDF فارسی همچنان مسئله‌ای حل‌نشده است
PDF از آزاردهنده‌ترین بخش‌های توسعه بود و هنوز هم هست. گاهی مشکل پیش از آغاز ترجمه و در استخراج متن رخ می‌دهد. ترتیب متن، کدگذاری فونت، جدول‌ها و ترکیب متن راست‌به‌چپ و چپ‌به‌راست کار را دشوار می‌کنند. فایل‌های اسکن‌شده نیز پیش از ترجمه به OCR نیاز دارند. بازسازی یک سند خوانا پس از ترجمه، با ترجمه یک پاراگراف تفاوت دارد.
چندین بار برای رفع مشکلات تلاش کردم، اما هنوز ادعا نمی‌کنم همه مسائل حل شده‌اند. صفحه عمومی محصول هشدار می‌دهد که بعضی PDFهای فارسی با فونت‌های نامعمول متن نامناسب استخراج می‌کنند و PDFهای اسکن‌شده بدون OCR پشتیبانی نمی‌شوند [۴]. این واقعیت را نباید پنهان کرد؛ بخشی از گزارش صادقانه مهندسی است.
۵. پروژه جانبی‌ای که به من یاد داد متوقف شوم: ترجمه بازی
در کنار MAKAN Translate، آزمایش‌هایی برای ترجمه رسانه و بازی آغاز کردم. کار ترجمه رسانه را سرانجام در پروژه اصلی ادغام کردم، ولی مترجم بازی به درسی درباره مدیریت دامنه پروژه تبدیل شد.
دو رویکرد کاملاً متفاوت را بررسی کردم.
رویکرد نخست این بود که برنامه هنگام اجرای بازی، تصویر را مشاهده کند، متن قابل دیدن را تشخیص دهد، ترجمه کند و روی تصویر نمایش دهد. رسیدن به کیفیت مدنظر من با اجرای پیوسته مدل‌های بزرگ محلی، روی رایانه عادی با محدودیت تأخیر، حافظه و پردازش روبه‌رو می‌شد. روش‌های محدودتر مبتنی بر OCR ممکن است عملی باشند، اما هدف اولیه من، یک مترجم بلادرنگ عمومی و توانمند، با منابع در دسترس واقع‌بینانه نبود.
رویکرد دوم شامل استخراج گفت‌وگو و منابع بومی‌سازی، ترجمه متن و وارد کردن منابع اصلاح‌شده به بازی بود. در این روش، برای دو بازی به نتیجه عملی رسیدم. Ren’Py نقطه آغاز ساده‌تری بود و Unity پیچیدگی بیشتری داشت. اما موفقیت در دو بازی به معنی داشتن ابزاری عمومی برای بازی‌های تجاری بزرگ یا AAA نبود.
قالب فایل‌ها، بسته‌بندی داده‌ها، ساختار بومی‌سازی و سازوکارهای محافظت در بازی‌ها متفاوت است. ابزار استخراجِ یک جامعه توسعه‌دهندگان ممکن است تنها برای نسخه خاص موتور یا حتی یک بازی ساخته شده باشد. مجوزها و شرایط حقوقی نیز یکسان نیستند: تغییر بازی همیشه غیرقانونی نیست، اما هر نوع استخراج یا توزیع مجدد هم الزاماً مجاز نیست. نمی‌توانستم مسئولانه وعده پشتیبانی همگانی بدهم.
پس پروژه را متوقف کردم. این تصمیم به معنی ناممکن بودن ترجمه بازی نیست؛ به معنی آن بود که گستره پشتیبانی، هزینه نگهداری و عدم قطعیت فراتر از توان من بود. تولید کد بیشتر با AI نمی‌توانست ناهمگونی ساختاری این حوزه را از میان ببرد.
۶. آزمایش به گلوگاه توسعه تبدیل شد
Claude به طراحی آزمون‌های خودکار کمک می‌کرد و Antigravity آن‌ها را پیاده‌سازی و اجرا می‌کرد. مخزن عمومی پروژه از تست‌های مبتنی بر Playwright، سرویس‌های شبیه‌سازی‌شده و دستورهای اجرای مجموعه آزمون‌های کامل، وب و افزونه یاد می‌کند [۵]. پیش‌نویس قدیمی‌تر بیش از ۹۰۰ تست و مدت اجرای حدود ۲۱ دقیقه را گزارش می‌کرد؛ خودم این ارقام را مستقلاً بازتولید نکرده‌ام و آن‌ها را داده اندازه‌گیری‌شده تأییدشده معرفی نمی‌کنم.
آزمون خودکار مفید بود، اما خطاهایی را که هنگام استفاده واقعی می‌دیدم همیشه پیدا نمی‌کرد. گاهی تغییر کوچکی به چند ساعت کدنویسی و آزمایش می‌انجامید. بنابراین به بررسی دستی سرتاسری تکیه کردم: مترجم را اجرا کنم، نتیجه را ببینم، خطا را بازتولید و گزارش کنم و دوباره آزمایش کنم.
گاهی سخت‌ترین بخش، یافتن اشکال نبود؛ توضیح دقیق آن بود. «کار نمی‌کند» تجربه واقعی کاربر است، اما توصیف خوبی برای رفع خطا نیست. یاد گرفتم ورودی، نتیجه مورد انتظار، نتیجه واقعی و مراحل بازتولید را مشخص کنم.
رگرسیون بسیار آزاردهنده بود. گاهی اصلاح یک مشکل، ظاهراً چند مشکل تازه ایجاد می‌کرد. با بزرگ‌تر شدن برنامه، اجزا تنظیمات و وابستگی‌های مشترکی داشتند و اصلاح محلی می‌توانست مسیر دیگری را خراب کند. کار انفرادی این فشار را بیشتر می‌کرد: هم‌زمان توسعه می‌دادم، پژوهش می‌کردم، اشکال‌زدایی انجام می‌دادم، کیفیت ترجمه را می‌سنجیدم و برای انتشار تصمیم می‌گرفتم.
با این همه AI کمک بزرگی بود. پیام خطا را توضیح می‌داد، علت‌های احتمالی را پیشنهاد می‌کرد و کدی را بازنویسی می‌کرد که انجام دستی آن برای من بسیار طولانی‌تر بود. ولی این سرعت، مسئولیت را به سمت راستی‌آزمایی منتقل می‌کرد؛ برنامه سریع‌تر از ظرفیت من برای بررسی آن رشد می‌کرد.
برای ارزیابی مستحکم‌تر، سه سطح آزمون لازم است:
| سطح آزمون | چه چیزی را بررسی می‌کند | چه چیزی را ثابت نمی‌کند |
|---|---|---|
| واحد و یکپارچه‌سازی | تجزیه فایل، رفتار API، تغییر وضعیت، حفظ زمان‌بندی | صحت معنایی ترجمه یا تجربه کاربری |
| آزمایش دستی جریان کاری | سایت واقعی، چینش سند، افزونه، کیفیت خروجی | پوشش همه محیط‌ها و حالت‌ها |
| ارزیابی کیفیت زبان | وفاداری معنا، اصطلاحات، حذف محتوا و طبیعی بودن با داوری انسانی | برتری جهانی یک مدل |
نتایج آزمون خودکار، مشاهده دستی و ارزیابی مدل را باید جداگانه گزارش کرد؛ نه با یک ادعای مبهم که «برنامه کار می‌کند».
۷. تناقض اقتصادی نرم‌افزار هوش مصنوعی رایگان
محدودیت اشتراک و سهمیه علت اصلی شروع پروژه بود؛ می‌خواستم ابزار رایگان باشد. بااین‌حال تقریباً هر لایه هزینه بالقوه‌ای داشت: اعتبار دستیار کدنویسی، استنتاج میزبانی‌شده، دانلود مدل و توان پردازشی، سرویس شخص ثالث، آماده‌سازی انتشار و توزیع در پلتفرم‌ها.
دانلودشدنی بودن مدل، هزینه اجرای آن را از بین نمی‌برد. سهمیه رایگان API معادل ترجمه نامحدود زیرنویس نیست. انتشار نرم‌افزار با مجوز MIT نیز مجوز مدل‌ها و داده‌های ثالث را تغییر نمی‌دهد. اجرای آفلاین تنها وقتی وابستگی به پرداخت به‌ازای درخواست را کاهش می‌دهد که کاربر سخت‌افزار مناسب داشته باشد و مصالحه‌های کارایی را بپذیرد.
این موضوع مرا به طراحی چندموتوره رساند: سرویس‌های آنلاین در صورت تناسب، کلید API متعلق به خود کاربر در موارد پشتیبانی‌شده، و مدل‌های محلی برای کسانی که آن را ترجیح می‌دهند. این یک موازنه است، نه معجزه. برنامه رایگان می‌تواند انتخاب بیشتری به کاربر بدهد، اما محاسبات را رایگان نمی‌کند.
همچنین فهمیدم بعضی دستیارهای AI اهمیت زمینه را درست تشخیص نمی‌دهند. مثلاً یک کلید API موقت در آزمایشی یک‌بارمصرف ممکن بود باعث بحث طولانی شود، گویی راز دائمی سامانه تولیدی است؛ حتی پس از اینکه شرایط را توضیح داده بودم. اعتبارنامه موقت نیز باید ایمن مدیریت شود، ولی بازبین خوب باید ریسک و اولویت واقعی را تشخیص دهد، نه اینکه توصیه عمومی را بی‌تناسب تکرار کند.
۸. چه چیزی وجود دارد و چه ادعایی نمی‌توانم بکنم
مخزن عمومی GitHub ساختار برنامه مبتنی بر JavaScript، کد افزونه مرورگر، اجزای ترجمه رسانه و صفحه، مستندات و پوشه‌های آزمون را نشان می‌دهد [۵]. README قابلیت‌هایی مانند ترجمه متن با چند موتور، ورود و خروج زیرنویس، کار با اسناد، امکانات صوتی، فرهنگ لغت و یکپارچگی مرورگر را توصیف می‌کند. این‌ها ادعاهای مستند درباره پیاده‌سازی هستند، نه اندازه‌گیری مستقل پایداری در همه شرایط.
یک ناسازگاری در وضعیت انتشار نیز باید اصلاح شود: صفحه محصول هنوز برخی روش‌های توزیع را با برچسب «به‌زودی» نشان می‌دهد، در حالی که مخزن درباره دسترسی وب و فرایندهای انتشار توضیح می‌دهد [۴، ۵]. کاربر باید به لینک دانلود واقعاً در دسترس، فایل انتشار و راهنمای نصب فعلی تکیه کند؛ نه وعده انتشار آینده.
تجربه من تنها از نتیجه‌گیری‌های محدود زیر پشتیبانی می‌کند:
- پروژه‌ای قابل‌توجه ساختم و یاد گرفتم چگونه مؤثرتر از چند سیستم AI استفاده کنم.
- در آزمایش‌های غیررسمی، مدل‌های مفیدی برای ترجمه و تشخیص گفتار یافتم، اما بنچمارک کنترل‌شده‌ای منتشر نکرده‌ام.
- استخراج PDF و حفظ قالب اسناد فارسی هنوز دشوار است.
- نمونه‌های اولیه ترجمه بازی در چند مورد موفق شدند، اما پشتیبانی عمومی خارج از محدوده عملی بود.
- رگرسیون، یکپارچه‌سازی، مستندسازی و بررسی مستقل هنوز مسئولیت‌هایی ادامه‌دار هستند.
این تجربه ثابت نمی‌کند که MAKAN Translate بهترین مترجم جهان است، همه قابلیت‌ها بی‌نقص‌اند، یا یکی از دستیارهای هوش مصنوعی به‌صورت عینی از همه بهتر است.
۹. اگر دوباره شروع کنم: یک روش عملی
اگر دوباره MAKAN Translate را آغاز کنم، کار را با جمله «یک مترجم برایم بساز» شروع نخواهم کرد. کوچک‌ترین نتیجه معنادار را تعریف می‌کنم: یک فایل .srt بخواند، متنش را ترجمه کند، زمان‌بندی را نگه دارد، فایل خروجی معتبر بسازد و بتوان آن را همراه ویدئوی واقعی بررسی کرد. بعد سراغ گسترش می‌روم.
به توسعه‌دهندگان مستقل پیشنهاد می‌کنم:
از امکان‌سنجی شروع کنید. پیش از طراحی بر پایه فرض‌ها، وجود مدل، مجوز، نیاز پردازشی، قالب فایل، API بیرونی و هزینه انتشار را بررسی کنید.
نقشه راه بسازید، نه پرامپتی غول‌آسا. اجزای مستقل و معیار پذیرش روشن تعریف کنید. پرامپت خوب کمک می‌کند، اما مرزبندی درست پروژه مهم‌تر است.
تغییرات AI را محدود نگه دارید. هر بار یک قابلیت یا یک اشکال را هدف بگیرید، مشخص کنید چه چیزهایی نباید دست بخورند و مدرک اجرای آزمون‌ها را بخواهید.
آزمون خودکار را با استفاده واقعی ترکیب کنید. سبز شدن تست‌ها جای سند واقعی، مرورگر واقعی، زبان واقعی یا کاربر واقعی را نمی‌گیرد.
نسخه سالم را حفظ کنید. کنترل نسخه و تست رگرسیون زمانی کمک می‌کند که یک اصلاح پیشنهادی مشکل تازه‌ای ایجاد کند.
زمان توقف را بشناسید. قابلیت کوچک و قابل اتکا از ادعای بزرگِ مبتنی بر نمونه اولیه بهتر است.
من از یک استعاره استفاده می‌کنم: هوش مصنوعی عصای موسی نیست؛ نمی‌توان آن را به دریا اشاره داد و انتظار داشت آب شکافته شود. شاید این سیستم‌ها در آینده بسیار خودمختارتر شوند. اما در تجربه من در سال ۲۰۲۶، درک مسئله، انتخاب راهکار عملی و بررسی نتیجه همچنان مسئولیت انسان بود.
۱۰. نتیجه‌گیری: درس اصلی، تجزیه مسئله بود
MAKAN Translate با نیاز یک دوست برای یادگیری لینوکس آغاز شد؛ نیازی که نباید مانع زبانی زیرنویس آن را دشوار می‌کرد. سپس به تجربه‌ای در ترجمه ماشینی، تشخیص گفتار، پردازش سند، افزونه مرورگر، اقتصاد مدل‌ها و مهندسی نرم‌افزار با AI تبدیل شد.
از چیزی که ساخته‌ام خوشحالم و در عین حال از اشکال‌ها، قابلیت‌های ناتمام و ادعاهایی که هنوز نیازمند راستی‌آزمایی‌اند آگاهی دارم. بیشتر از آنکه یاد بگیرم چطور از یک چت‌بات کد بخواهم، یاد گرفتم AI را همکاری قدرتمند ولی ناقص بدانم و نرم‌افزار را در جهان واقعی محک بزنم.
مهم‌ترین درس، «مهندسی پرامپت» نبود؛ یک اصل قدیمی برنامه‌نویسی بود که در عصر AI اهمیت تازه‌ای پیدا کرده است: مسئله دشوار را به مسائل کوچک‌تر تقسیم کن، یکی را حل کن، آزمایشش کن و تنها بعد سراغ بعدی برو.
AI می‌تواند تولید کد را بسیار سریع‌تر کند، اما نیاز به دانستن اینکه چه چیزی بسازیم، چرا بسازیم و آیا واقعاً کار می‌کند را از بین نمی‌برد.
——————————————————————————————
یادداشت روش‌شناسی و شواهد
این نوشته یک مطالعه موردی تأملی از تجربه یک توسعه‌دهنده است که با کمک ویراستاری AI و بر پایه روایت من از پروژه تهیه شده است. ترتیب آزمایش‌ها، خاطرات مربوط به زمان و هزینه، مشاهدات کیفیت مدل‌ها و دشواری‌های آزمایش دستی، خودگزارش‌دهی هستند و در قالب مطالعه کنترل‌شده ثبت نشده‌اند. وب‌سایت عمومی و مخزن GitHub در ۲۲ اکتبر ۲۰۲۶ برای توصیف محصول، ساختار پروژه و مستندات توسعه بررسی شدند. برای این مقاله هیچ بنچمارک مستقل، ممیزی امنیتی، گواهی نصب، مطالعه کمی رگرسیون یا بازتولید شمار تست‌های گزارش‌شده انجام نشده است. AI در ساختاردهی، نگارش پیش‌نویس، بررسی فنی و ویرایش کمک کرده است؛ تجربه‌ها و قضاوت‌های روایت‌شده از من است.
منابع
[۱] NLLB Team و همکاران (۲۰۲۲). No Language Left Behind: Scaling Human-Centered Machine Translation. https://arxiv.org/abs/2207.04672
[۲] Google (۱۵ ژانویه ۲۰۲۶). TranslateGemma: A new family of open translation models. https://blog.google/innovation-and-ai/technology/developers-tools/translategemma/
[۳] OpenAI. Whisper: README and model documentation. https://github.com/openai/whisper
[۴] MAKAN LAB. صفحه MAKAN Translate. https://makanlab.tech/translate/ (دسترسی در ۲۲ اکتبر ۲۰۲۶).
[۵] Makan. مخزن عمومی و README پروژه MAKAN Translate. https://github.com/makan20042002/translator (دسترسی در ۲۲ اکتبر ۲۰۲۶).
——————————————————————————————
یادداشت نویسنده: MAKAN Translate پروژه‌ای مستقل و در حال توسعه است. قابلیت‌ها، دسترسی به مدل‌ها، محدودیت‌ها و وضعیت انتشار ممکن است پس از تاریخ این مقاله تغییر کنند. برای اطلاع از وضعیت کنونی به مخزن و وب‌سایت مراجعه کنید.