تصور کنید ساعت‌ها وقت صرف نوشتن رزومه و شخصی‌سازی نامه‌های پوششی کنید، اما هرگز پاسخی نگیرید چون آن شغل از أساس وجود نداشته است. اگر امروز به دنبال دورکاری هستید، باید بدانید بسیاری از آگهی‌های منتشر شده صرفاً برای جمع‌آوری داده‌های شما، پر کردن ویترین شرکت‌ها یا حتی ایجاد تصور کاذب از رشد شرکت هستند. این پدیده به «شغل‌های شبح» یا Ghost Jobs معروف است؛ آگهی‌هایی که یا قبلاً پر شده‌اند، یا هرگز باز نشده‌اند و یا صرفاً برای جمع‌آوری رزومه‌ها ایجاد شده‌اند.
یک توسعه‌دهنده به‌تنهایی پلتفرم Remoty.work را راه‌اندازی کرده است؛ یک تخته شغلی که به هر آگهی دورکاری یک نمره (از A تا F) اختصاص می‌دهد تا مشخص شود کدام آگهی‌ها واقعاً در حال استخدام هستند و کدام‌یک «شبح» هستند. هدف این ابزار شکستن چرخه‌ای است که در آن سایت‌های کاریابی به‌طور بی‌پایان آگهی‌های مرده را از یکدیگر کپی (Scrape) می‌کنند، بدون اینکه هیچ‌کدام آن‌ها را راستی‌آزمایی کنند. توسعه‌دهنده این ابزار را ساخت تا به جای شکایت در شبکه اجتماعی X، مشکل را با کدنویسی حل کند. هدف نهایی پاسخ به یک پرسش بنیادین است: «آیا واقعاً کسی قرار است رزومه‌ی من را بخواند؟»
چالش مهندسی و مشکل بنیادین
از دیدگاه مهندسی، تخته‌های شغلی فعلی به عنوان یک حلقه بی‌پایان استخراج داده عمل می‌کنند. سایت A داده‌ها را از سایت B می‌گیرد و سایت B پیش‌تر آن‌ها را از سایت C استخراج کرده است. این زنجیره باعث می‌شود یک آگهی منقضی‌شده در ده‌ها سایت مختلف تکثیر و منتشر شود. از آنجا که هیچ‌کدام از این سایت‌ها صحت آگهی را تأیید نمی‌کنند، هیچ سیگنالی برای تشخیص «واقعی بودن» وجود ندارد و نویز به قدری زیاد می‌شود که تمام سایت‌ها مشابه یکدیگر به نظر می‌رسند. Remoty.work به جای اینکه صرفاً یک تخته شغلی دیگر باشد، به عنوان یک «لایه تأیید» روی این حلقه طراحی شده است.
معماری فنی و زیرساخت
توسعه‌دهنده از یک استک فنی «به‌دوره عمدی ساده» (Deliberately Boring Stack) استفاده کرده است. تمام سیستم روی یک سرور مجازی (VPS) واحد اجرا می‌شود که میزبان پایگاه‌داده Postgres، اسکرپرهای جمع‌آوری داده و کارهای مربوط به امتیازدهی است و همگی طبق یک زمان‌بندی نظارت می‌شوند. بخش Frontend نیز با استفاده از Astro 5 (که ترکیبی از صفحات استاتیک و On-demand است) روی Cloudflare Pages میزبانی شده است.
یک چالش زیرساختی خاص در مورد اتصال بین لبه (Edge) و پایگاه‌داده وجود داشت. از آنجا که لبه‌های Cloudflare نمی‌توانند یک اتصال TCP خام به پایگاه‌داده Postgres (که برای امنیت فقط روی localhost سرور VPS باز است) برقرار کنند، توسعه‌دهنده یک «پل HTTP» کوچک، احراز هویت‌شده و فقط‌خواندنی پیاده کرد. این راهکار اجازه می‌دهد صفحات پویا بدون دسترسی مستقیم و خطرناک به دیتابیس، با سرور ارتباط برقرار کرده و داده‌ها را دریافت کنند.
جزئیات عملیاتی سیستم
- ورودی داده‌ها (Ingestion): اسکرپرهای زمان‌بندی‌شده اطلاعات را از تخته‌های شغلی منبع و فیدهای ATS (سیستم‌های ردیابی متقاضیان) شرکت‌ها استخراج کرده و در Postgres ذخیره می‌کنند.
- حذف تکرار (Deduplication): هر آگهی خام توسط یک اثر انگشت منحصربه‌فرد (ترکیبی از عنوان + نام شرکت + URL نرمال‌سازی شده) شناسایی می‌شود. این کار باعث می‌شود یک شغل که در ۵ سایت مختلف بازنشر شده، به جای ۵ ردیف، در یک ردیف تجمیع شود و فقط یک شمارنده بازنشر (
repost_count) داشته باشد. - جستجو و پرداخت: برای قابلیت جستجو از Pagefind و برای مدیریت پرداخت‌ها و چک‌اوت از Whop استفاده شده است.
- اتوماسیون: سیستم از یک GitHub Actions Runner میزبانی‌شده (Self-hosted) استفاده می‌کند، به این معنا که سرور خودش فرآیندهای ساخت و به‌روزرسانی را مدیریت می‌کند.
مکانیزم امتیازدهی و نقش هوش مصنوعی
پلتفرم یک امتیاز «ریسک شبح» بین ۰ و ۱ محاسبه می‌کند که سپس به نمرات انسانی A تا F تبدیل می‌شود. آستانه‌های تعیین نمره به این شرح است: A (کمتر از ۰.۱۵)، B (کمتر از ۰.۳۵)، C (کمتر از ۰.۵۵)، D (کمتر از ۰.۷۵) و نمره F برای هر چیزی بالاتر از این مقادیر.
این امتیاز از پنج سیگنال مشخص استخراج می‌شود:
۱. تعداد بازنشر: اگر شغلی در بیش از ۶ تخته شغلی دیده شود، ریسک ۰.۳۰ افزایش می‌یابد. این نشان‌دهنده یک «قیف جذب کلی» است و نه یک جایگاه شغلی مشخص.
۲. عمر آگهی: آگهی‌هایی که بیش از ۴۵ روز «باز» مانده‌اند، ۰.۲۵ به امتیاز ریسک اضافه می‌کنند.
۳. شفافیت حقوق: فرصت‌های واقعی معمولاً حقوق را ذکر می‌کنند؛ نبود مبلغ حقوق ۰.۱۵ به ریسک اضافه می‌کند.
۴. کیفیت توصیف: یک امتیاز (بین ۰ تا ۱) که توسط LLM تولید می‌شود و بر اساس کیفیت متن توصیفات شغلی، تا ۰.۱۵ ریسک ایجاد می‌کند.
۵. احساسات شرکت: سیستم سیگنال‌های «شکایت» را از r/recruitinghell و تاپیک‌های مربوط به استخدام رصد می‌کند. احساسات منفی تا ۰.۱۵ ریسک اضافه می‌کند.
برای این تحلیل‌ها از مدل DeepSeek به عنوان هسته LLM استفاده شده است تا توصیفات نامنظم شغلی و گفتگوهای مربوط به شرکت‌ها را طبقه‌بندی و خلاصه کند. DeepSeek به‌جای مدل‌های کلاس GPT-4 انتخاب شد زیرا پردازش هزاران آگهی هر شب با مدل‌های گران‌قیمت، اقتصاد واحد (Unit Economics) پروژه را پیش از آنکه کاربر جذب کند، نابود می‌کرد.
کشف «آگهی‌های جذب لید» و اصلاح انسانی
یک کشف حیاتی این بود که برخی لیست‌ها اصلاً شغل نیستند، بلکه «آگهی‌های جذب لید» (Lead-gen ads) برای شبکه‌های تأییدشده استعدادیابی هستند. این پلتفرم‌ها صدها جایگاه شغلی را پست می‌کنند تا بانک کاندیداهای خود را بزرگ کنند. توسعه‌دهنده برای تست این موضوع شخصاً اپلای کرد و در ایمیل‌های رد درخواست، آن‌ها اعتراف کردند که برای هر نقش، تعداد کاندیداهای بیش از حد دارند. این موارد اکنون به جای دریافت نمره، صراحتاً با برچسب «Ad — Not Hiring» (آگهی — استخدام نمی‌کند) علامت‌گذاری می‌شوند، زیرا معمولاً هیچ‌چیزی در متن آگهی این حقیقت را فاش نمی‌کند.
برای تضمین دقت، یک فرآیند «انسان در حلقه» (Human in the Loop) برقرار است. وقتی سیستم رفتار غیرعادی شناسایی می‌کند، سازنده شخصاً برای آن شغل اپلای می‌کند. اگر سیستم اشتباه کرده باشد، او برچسب را اصلاح کرده و دلیل خطا را به مدل بازمی‌گرداند تا دقت دفعات آینده افزایش یابد.
پست‌مورتم: چه چیزهایی اشتباه پیش رفت؟
در طول توسعه، چندین شکست فنی رخ داد که درس‌های مهمی داشت:
- مشکل اسلش انتهایی (Trailing Slash): نبود یک اسلش در انتهای URLهای صفحات شغلی باعث شد کلیک‌ها به صفحه اصلی هدایت شوند. این موضوع تنها زمانی کشف شد که تحلیل‌ها نشان داد یک URL خاص، دومین صفحه پربازدید است اما عنوان صفحه اصلی را نمایش می‌دهد.
- جهنم کدگذاری (Encoding Hell): اسکرپرها کاراکترهای HTML (مانند &) را به صورت خام ذخیره می‌کردند و موتور قالب‌ساز دوباره آن‌ها را Escape می‌کرد، در نتیجه عناوینی مثل «Q&A» به شکل نادرستی نمایش داده می‌شدند.
- بهینه‌سازی بیش از حد SEO: توسعه‌دهنده حدود ۹ هزار صفحه کلیدواژه‌ای برنامه‌ریزی شده ساخت. اما گوگل تقریباً هیچ‌کدام را ایندکس نکرد. این ثابت کرد که سقف رشد، «بودجه خزش» (Crawl Budget) گوگل است و نه حجم محتوا. این منجر به توقف تولید انبوه صفحات شد.
- توهم عامل (Agent Hallucination): یک عامل ارتباطی (Outreach Agent) گزارش داد که ۶ ایمیل برای اسپانسرها فرستاده است، در حالی که در واقعیت هیچ ایمیلی ارسال نشده بود. این منجر به وضع یک قانون جدید شد: هر اقدام عامل هوشمند باید با یک «اثر جانبی واقعی» (Side Effect) در دنیای بیرون تأیید شود تا قابل اعتماد باشد.
برای کسانی که در حوزه توسعه کاربردی فعالیت می‌کنند، این پروژه نشان‌دهنده تغییر رویکرد به سمت «لایه‌های تأیید» روی داده‌های تجمیع‌شده است. با اولویت دادن به قانون «آیا این اتفاق واقعاً افتاده است؟» به جای اتوماسیون خام، این ابزار مشکلی از جنس «اعتمادسازی» را حل می‌کند که تخته‌های شغلی استاندارد نادیده می‌گیرند.
اگر شما هم از «سیاه-چاله» اپلای‌های دورکاری خسته شده‌اید، می‌توانید سیستم امتیازدهی Remoty.work را امتحان کنید تا ببینید آیا شرکت هدف شما واقعاً در حال استخدام است یا خیر.
گام بعدی شما
- اگر به دنبال موقعیت شغلی هستید، Remoty.work را برای بررسی اعتبار شرکت‌های هدف خود امتحان کنید.
- در هنگام بررسی آگهی‌ها، به تعداد سایت‌هایی که یک پست را بازنشر کرده‌اند توجه کنید؛ بازنشر زیاد معمولاً نشانه ریسک است.
- برای توسعه‌دهندگان، بررسی معماری «پل HTTP» برای اتصال Cloudflare Edge به Postgres یک الگو برای پروژه‌های مشابه است.
اما تأثیر این رویکرد بر تغییر رفتار شرکت‌ها در جذب نیرو، ابعاد پیچیده‌تری دارد — به تحلیل ما درباره آینده بازار کار در عصر عامل‌های هوشمند مراجعه کنید.
گفتگو