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

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

ساخت ابزارهای سفارشی با هوش مصنوعی ساده است، اما زنده نگه داشتن آن‌ها چالشی است که اکثر کاربران در آن شکست می‌خورند. شین (Shin)، توسعه‌دهنده e-Shikumi-Labo، سیستمی را برای نگهداری افزونه‌های کروم معرفی کرده است که در برابر تغییرات اجتناب‌ناپذیر رابط‌های کاربری (UI) مقاوم هستند. این رویکرد، بخش پایانی از یک سری چهارگانه با عنوان «تفکر سیستماتیک» است که بر ساخت و نگهداری مستقل ابزارها با کمک هوش مصنوعی تمرکز دارد.

بیشتر استخراج‌کننده‌های داده (Scrapers) ساخته‌شده با هوش مصنوعی، لحظه‌ای که پلتفرمی مثل گوگل یک کلاس CSS را تغییر می‌دهد، از کار می‌افتند. این وضعیت چرخه‌ای از استیصال ایجاد می‌کند؛ ابزاری که یک روز عالی کار می‌کرد، روز بعد ناپدید می‌شود. برای کسانی که از ابزارهایی مثل Chat Saver for Gemini استفاده می‌کنند، این یک باگ نیست، بلکه واقعیت بنیادین استخراج داده از مدل شیء سند (DOM) — که شبیه به نقشه‌ی ساختاری یک صفحه وب است — به‌جای استفاده از یک API پایدار است.

محدودیت‌های فنی استخراج وب

شین بر یک محدودیت فنی حیاتی تأکید می‌کند: «شما نمی‌توانید چیزی را که روی صفحه نیست، استخراج کنید.» او در حین توسعه سعی داشت زمان دقیق ارسال هر پیام در Gemini را ثبت کند. اما تحلیل دقیق ساختار صفحه نشان داد که بر خلاف انتظار، زمان دقیق هر پیام (Timestamp) در کدهای HTML وجود ندارد.

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

تغییرات مشخصات به عنوان «سرنوشت»

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

برای حل این مشکل، شین الگویی به نام «تجزیه مجزا» (Isolated Parsing) را پیشنهاد می‌دهد. در این روش، منطق ارتباطی (که توسط content.js مدیریت می‌شود) از منطق استخراج داده (که در یک فایل مجزای parser.js قرار دارد) جدا می‌شود. این جداسازی باعث می‌شود که تغییر در ظاهر سایت، کل سیستم را مختل نکند و تنها یک بخش کوچک نیاز به اصلاح داشته باشد.

جزئیات: مکانیزم بازیابی

بر اساس بررسی‌های فنی، با انتقال فرآیند تجزیه به parser.js، کاربر تنها نیاز دارد هنگام تغییر طراحی Gemini، گزینه‌های CSS (Selectors) را اصلاح کند. فرآیند بازیابی از یک حلقه‌ی سه‌مرحله‌ای دقیق پیروی می‌کند:

• بررسی تغییرات: باز کردن Gemini در کروم و فشردن کلید F12 (یا راست‌کلیک و انتخاب Inspect) برای باز کردن DevTools جهت بررسی ساختار جدید HTML در بخش‌های مربوط به پرامپت و پاسخ.
• کپچر کردن DOM: کپی کردن عناصر HTML به‌روزرسانی‌شده برای نواحی هدف.
• تعمیر با هوش مصنوعی: دادن کد فعلی parser.js و HTML جدید به یک مدل هوش مصنوعی.

به عنوان مثال، می‌توان از این پرامپت برای تعمیر استفاده کرد: «فایل parser.js به دلیل به‌روزرسانی رابط کاربری Gemini از کار افتاده است. من کد فعلی parser.js را به همراه آخرین عناصر HTML برای بخش پرامپت و بخش پاسخ ضمیمه کرده‌ام. بر اساس این اطلاعات، لطفاً بخش‌های Selector را اصلاح کن.»

این متد نیاز به بازنویسی دستی کد توسط کاربر را حذف می‌کند. با ارائه تفاوت‌های دقیق (Delta) — یعنی کد قدیمی و HTML جدید — به هوش مصنوعی، اسکریپت اصلاح‌شده در عرض چند ثانیه تولید می‌شود.

بازتعریف خوداتکایی

این تغییر رویکرد، نقش انسان را از یک «کدنویس» به یک «معمار سیستم» تبدیل می‌کند. هدف ساخت ابزاری نیست که هرگز نشکند، بلکه ابزاری است که «قابل تعمیر» باشد. شین مسیر این خوداتکایی را در چهار مرحله تعریف می‌کند:

۱. ساخت: استفاده از هوش مصنوعی برای خلق ابزارها بدون نیاز به درک کامل و عمیق سینتکس کد.
۲. گسترش: تطبیق مکانیزم‌ها برای حل چالش‌های تجاری خاص، مانند بهبود خوانایی داده‌ها.
۳. مدیریت ریسک: شناسایی کدهای خطرناک تولیدشده توسط هوش مصنوعی (مثلاً کدهایی که ریسک بن شدن حساب کاربری را افزایش می‌دهند) و اصلاح آن‌ها.
۴. نگهداری: ایجاد ساختاری که شکست را پیش‌بینی کرده و از هوش مصنوعی برای ترمیم مداوم آن استفاده می‌کند.

درک نقشه‌ی سیستم — یعنی ورودی (استخراج از صفحه) $
ightarrow$ پردازش (فیلتر تکراری‌ها) $
ightarrow$ خروجی (ارسال به GAS) — بسیار ارزشمندتر از حفظ کردن دستورات جاوااسکریپت است. تا زمانی که این نقشه‌ی ساختاری شفاف باشد، کاربر می‌تواند کدهای خطرناک را شناسایی کرده و دستورات دقیقی برای تعمیر صادر کند.

برای کسانی که می‌خواهند این روش را پیاده کنند، Chat Saver for Gemini در دو نسخه ارائه شده است:

• نسخه Lite (رایگان و بازمتن در گیت‌هاب): یک ابزار بدون نیاز به تنظیمات (Zero-setup) که با یک کلیک داده‌ها را به فرمت Markdown محلی صادر می‌کند و مخصوص کاربران Obsidian طراحی شده است.
• نسخه Pro (از طریق Gumroad): یک پکیج کامل همگام‌سازی خودکار که دارای قابلیت تشخیص تغییرات پس‌زمینه (MutationObserver) است و خروجی دوگانه در گوگل درایو (فایل .md) و گوگل شیتس ارائه می‌دهد.

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

گام بعدی شما

• اگر افزونه‌ای دارید که از کار افتاده، ابتدا با F12 ساختار HTML جدید را بررسی کنید.
• منطق استخراج داده را از منطق اجرایی کد جدا کنید تا تعمیرات آینده سریع‌تر شود.
• هنگام درخواست تعمیر کد از AI، حتماً هر دو مورد «کد قدیمی» و «HTML جدید» را ارسال کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.