ابزارهای برنامه نویسی هوش مصنوعی برای ورود به گردش کار در سطح دسکتاپ رقابت می کنند

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

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

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

مزایای خاص در سه مکان منعکس شده است.

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

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

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

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

سوء تفاهمی که واقعاً شایسته هوشیاری است، درک این موج تغییرات به عنوان امتداد «جنگ مدل» است. جنبه رقابتی حیاتی‌تر در گردش کار front-end تبدیل شده است: چه کسی می‌تواند اجرای محلی، کنترل مرورگر، حافظه زمینه و پیوندهای پخش را به طور پایدار در اختیار بگیرد. شکاف پارامتر به سرعت بسته می شود و هنگامی که پیوند اجرا تشکیل شد، هزینه مهاجرت بیشتر و بیشتر می شود.

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