تاریخ انتشار: ۱۰ نوامبر ۲۰۲۶
WeTV پلاتفرم بین‌المللی جاری‌سازی ویدیو Tencent است. این سرویس مجموعه‌های درام، انیمه، و نمایش‌های گوناگون را به بینندگان در آسیای جنوب شرقی و دیگر بازارهای جهانی ارائه می‌دهد. برای سایتی که حول ویدیو ساخته شده است، عملکرد تعیین می‌کند که آیا بینندگان می‌مانند، آیا موتورهای جستجو محتوا را نشان می‌دهند، و آیا بازپخش روان احساس می‌شود.
تیم مهندسی وب WeTV کدی را که به اهداف عملکردی خود نرسد، ارسال نمی‌کند. For a long time, holding that line meant a developer had to stop what they were doing, open Chrome, and profile the page by hand every time a build failed the check. ردیابی و رفع یک رگرسیون حدود چهار ساعت طول کشید.
امروزه، یک عامل کدنویسی هوش مصنوعی این کار را به‌عنوان بخشی از خط لوله CI/CD انجام می‌دهد. با Chrome DevTools برای عامل‌ها، عامل صفحه را در مرورگر زنده بازرسی می‌کند. با راهنمای وب نوین، اصلاحاتی را می‌نویسد که از استانداردهای فعلی پلاتفرم وب پیروی می‌کنند. اکنون گردش کار ۹۰٪ از آزمایش‌های عملکرد ناموفق را به‌طور خودکار تشخیص می‌دهد و حل می‌کند، و زمان بین بررسی ناموفق تا اصلاح تأییدشده از چهار ساعت به ۳۰ دقیقه کاهش یافته است—ازجمله ساخت کامل و ارزیابی دستی.
چالش: توسعه‌دهنده‌ای که بین ویرایشگر و مرورگر گیر کرده است
مهندسان WeTV قبلاً از ابزارهای کدنویسی هوش مصنوعی در IDE خود استفاده می‌کردند. آن ابزارها می‌توانستند کد بنویسند، اما نمی‌توانستند ببینند که کد پس‌از اجرا در مرورگر چه کاری انجام می‌دهد. بنابراین کار به دو بخش تقسیم شد. مهندسان کد را در ویرایشگر می‌نویسند، سپس برای استقرار، بازرسی، و درستی‌سنجی آن به Chrome می‌روند. هر اصلاح به‌معنای تکرار دوباره آن حلقه به‌صورت دستی بود.
این تقسیم‌بندی بیشترین آسیب را به دروازه انتشار وارد کرد. خط لوله CI/CD در WeTV ردگیری‌های عملکرد را در هر نسخه اجرا می‌کند و «تغییر چیدمان تجمعی» (CLS) را روی ۰٫۱ یا کمتر نگه می‌دارد. وقتی ساخت از آن خط عبور می‌کرد، خط لوله آن را پرچم‌گذاری می‌کرد، اما پیدا کردن علت هنوز دستی بود. مهندس باید Chrome DevTools را باز می‌کرد، ردیابی را ضبط می‌کرد، عنصری را که جابه‌جا شده بود پیدا می‌کرد، آن یافته را به ویرایشگر برمی‌گرداند، اصلاحیه‌ای می‌نوشت، و دوباره بررسی را اجرا می‌کرد. یک رگرسیون CLS حدود چهار ساعت زمان مهندسی هزینه داشت.
تیم به عاملی نیاز داشت که بتواند هر دو بخش کار را انجام دهد: صفحه درحال اجرا را بررسی کند و سپس کد را براساس استانداردی شناخته‌شده اصلاح کند.
راه‌حل: متصل کردن عامل به مرورگر و استانداردهای وب
WeTV درستی‌سنجی عملکرد را به جریان درخواست ادغام (MR) خود منتقل کرد. وقتی توسعه‌دهنده‌ای درخواست ادغام باز می‌کند، خط لوله CI/CD محیطی را راه‌اندازی می‌کند که در آن عامل کدنویسی هوش مصنوعی به‌صورت محلی با دو قابلیتی اجرا می‌شود که ابزارهای IDE تیم فاقد آن بودند:
- Chrome DevTools برای عامل‌ها: یک سرور «پروتکل بافتار مدل» (MCP) را اجرا می‌کند و عامل را به یک نمونه Chrome زنده متصل می‌کند. این عامل می‌تواند ردگیری‌های عملکرد را (در میان سایر ویژگی‌های Chrome DevTools) ضبط کند و بررسی کند که کد پیش‌رو واقعاً چگونه رندر می‌شود، همان‌طور که یک توسعه‌دهنده در DevTools انجام می‌دهد.
- راهنمای وب نوین: مهارتی برای عامل که حاوی روال‌های مطلوب پلاتفرم وب و داده‌های سازگاری مرورگر است. این ابزار عامل را از الگوهای قدیمی دور می‌کند و به‌سمت اصلاحاتی که براساس ویژگی‌های پلاتفرم وب مدرن ساخته شده‌اند هدایت می‌کند.
DevTools برای عامل‌ها به عامل می‌گوید چه چیزی خراب شده است. «راهنمای وب نوین» نحوه رفع مشکل را شکل می‌دهد.
مثال واقعی: تغییر چیدمان در صفحه بازپخش قسمت
درطول یک درخواست ادغام، نماینده ابزار performance_start_trace را در صفحه بازپخش قسمت در رایانه اجرا کرد. ردیابی CLS را ۰٫۳۹ ثبت کرد که تقریباً چهار برابر حد ۰٫۱ است.
به عامل بگویید قبل‌از ویرایش کردن، عیب‌یابی کند
WeTV به نماینده اجازه بداهه‌گویی نمی‌دهد. پیام‌واره‌ای که گردش کار را هدایت می‌کند به آن می‌گوید که قبل‌از دست زدن به هر کدی، مشکل را تشخیص دهد و یافته‌هایش را با «راهنمای وب نوین» مطابقت دهد، به‌جای اینکه به هر چیزی که مدل به‌طور پیش‌فرض تولید می‌کند تکیه کند.
در اینجا نمونه‌ای از پیام‌واره‌ای که تیم WeTV استفاده کرده است آورده شده است:
Context:
"The CLS (Cumulative Layout Shift) of this page needs inspection. Diagnose
first, then modify the code, do not guess."
Mandatory Execution Steps:
1. Performance Trace: Use Chrome DevTools for agents to run performance traces
on both Desktop and Mobile views.
2. Identify Culprits: Use CLSCulprits insight to pinpoint the exact DOM elements
causing shifts (capture class/id, timing, and score).
3. Use web best practices for performance and CSS to optimize CLS.
4. Multi-Agent Parallelism: Enable parallel agents for efficiency:
- Agent A: Investigate Player/Main Layout SSR placeholders.
- Agent B: Investigate Sidebar Ads, VIP buttons, Tabs, and late-injected
lists.
- Agent C: Investigate Fonts and other minor factors.
Constraint: Each agent modifies only files within its scope to prevent
conflicts.
5. Root Cause Confirmation: Confirm the root cause before applying fixes.
Prioritize reserving space over changing interaction semantics just to fix
CLS.
6. Verification: After modification, re-test CLS via equivalent CSS injection
or local build. Target: CLS < 0.1.
دو بخش از این پیام‌واره بیشترین اهمیت را دارند. «ابتدا تشخیص دهید، سپس کد را اصلاح کنید»
مانع از وصله کردن علائم توسط نماینده می‌شود. مرحله ۲ به عامل اشاره می‌کند که از
performance_analyze_insight با insightName: 'CLSCulprits' استفاده کند، بنابراین
عنصر، زمان‌بندی، و امتیاز دقیق را به‌جای یک سوءظن کلی گزارش می‌کند.
در ویدیو زیر، وقتی پیام‌واره اجرا می‌شود، عامل راهنمای مربوطه را در «راهنمای وب نوین» جستجو می‌کند تا اصلاحات را با ویژگی‌های وب نوین مرتبط با CLS پیاده‌سازی کند و از Chrome DevTools برای عامل‌ها استفاده می‌کند تا نمونه مرورگر Chrome را باز کند و رد عملکرد را ضبط کند.
این ترکیب از عیب‌یابی زمان اجرا و راهنمایی ساختاریافته، اصلاحات خودکار را برای تغییرات پیچیده چیدمان امکان‌پذیر می‌کند. در اینجا نمونه‌ای از مشکلی که توسط گردش کار خودکار برطرف شده است آورده شده است.
یافتن علت ریشه‌ای
ردیابی به پخش‌کننده ویدیو اشاره کرد. WeTV پخش‌کننده را در سرور ارائه می‌کند، اما محفظه پخش‌کننده هیچ ارتفاعی برای آن رزرو نکرده است. وقتی کارخواه صفحه را هیدراته کرد، ارتفاع محفظه افزایش یافت و محتوای اطراف آن جابه‌جا شد.
اعمال اصلاح مبتنی بر استانداردها
راه‌حل این است که فضا را درطول پردازش سمت سرور رزرو کنید تا محفظه قبل‌از هیدراتاسیون ارتفاع مناسب را داشته باشد. در زیر نمونه‌ای از اصلاحیه‌ای که عامل با ارجاع به راهنمای css-layout در «راهنمای وب نوین» نوشته است آورده شده است:
.play__block--player .play__aside--left {
inline-size: 100%;
block-size: auto;
aspect-ratio: 16/9;
}
پس‌از اینکه عامل CSS را اعمال کرد، خط لوله صفحه را بازسازی کرد و عامل همان ردیابی را دوباره اجرا کرد. فقط وقتی CLS به زیر ۰٫۱ رسید، وصله به مرحله بازبینی انسانی رفت.
تأثیر: نسخه‌های پخش سریع‌تر و چیدمان‌های پایدار
WeTV با افزودن Chrome DevTools برای عامل‌ها و «راهنمای وب نوین» به گردش کار CI/CD خود، به بهبودهای قابل‌اندازه‌گیری در کارایی مهندسی و پایداری چیدمان دست یافت:
- ۸۷٪ کاهش در زمان اشکال‌زدایی و حل‌وفصل سرتاسری (از ۴ ساعت به ۳۰ دقیقه).
- ۹۰٪ از همه پسرفتهای عملکردی تکرارشونده به‌طور خودکار تشخیص داده می‌شوند و حل‌وفصل می‌شوند.
مهندسان دیگر نیمی از روز کاری را برای نمایه‌سازی ازدست نمی‌دهند. وقتی ساخت از آستانه عبور می‌کند، عامل ردگیری را می‌خواند، اصلاحیه‌ای می‌نویسد، آن را آزمایش می‌کند، و وصله تأییدشده را به بازبین انسانی تحویل می‌دهد. افراد همچنان تصمیم نهایی را می‌گیرند، اما آن‌ها از اصلاحیه‌ای شروع می‌کنند که قبلاً از بررسی ناموفق عبور کرده است.
چون پسرفتهای CLS در درخواست ادغام اصلاح می‌شوند، به مرحله تولید نمی‌رسند. این کار باعث می‌شود صفحه‌ها زیر هدف ۰٫۱ باقی بمانند، از رؤیت‌پذیری جستجوی WeTV محافظت می‌کند، و دلیل رایج برای مسدود کردن انتشار در اواخر چرخه را برطرف می‌کند.
درس‌هایی برای تیم شما
راه‌اندازی WeTV مختص پشته آن است، اما الگوی پشت آن به اکثر تیم‌هایی که انتشارها را براساس عملکرد محدود می‌کنند منتقل می‌شود:
- عامل را در جایی که خطا رخ می‌دهد اجرا کنید. WeTV عامل را از درخواست ادغام راه‌اندازی می‌کند، بنابراین هیچ‌کس متوجه بررسی ناموفق نمی‌شود و جلسه را به‌صورت دستی شروع می‌کند.
- عامل را وادار کنید قبل‌از ویرایش کردن، عیب‌یابی کند. Asking for a trace and a named culprit first produces fixes that target the actual element instead of a guess.
- داده‌های زمان اجرا را با استاندارد جفت کنید. ردیابی به عامل می‌گوید کدام عنصر حرکت کرده است. «راهنمای وب نوین» به آن می‌گوید کدام اصلاح از رویه فعلی پلاتفرم پیروی می‌کند.
- درخواست مدرک کنید. اجرای مجدد همان ردیابی‌ای که ناموفق بود، مدرک نماینده برای کار کردن اصلاحیه است. P2ER از همین اصل در قانون درستی‌سنجی تجربی اجباری خود پیروی می‌کند.
- انسان را در حلقه نگه دارید. عامل بررسی را انجام می‌دهد و مهندس وصله‌ای را که قبلاً بررسی را گذرانده است مرور می‌کند.
بازخورد و طرح‌های آینده
WeTV متوجه شد که جفت کردن دورسنجی زمان اجرای زنده از Chrome DevTools برای عامل‌ها با قوانین استانداردشده در «راهنمای وب نوین» باعث شد تحلیل عملکرد دستی از فرایند انتشار حذف شود، درحالی‌که تغییرات کد عامل با استانداردهای فعلی پلاتفرم وب مطابقت داشت.
«نتایج هم ازنظر سرعت و هم ازنظر کیفیت بسیار مؤثر بوده است. بینش‌های تحلیلی تشخیصی ارائه‌شده توسط Chrome DevTools برای عامل‌ها و «راهنمای وب نوین» مراجع قابل‌اعتمادی برای رفع مشکلات پیچیده چیدمان دراختیار ما قرار داد. ما پس‌از هر اصلاح، درستی‌سنجی دقیقی انجام می‌دهیم و نرخ موفقیت و پایداری فعلی اطمینان ما را به انتشار به‌طور قابل‌توجهی بهبود بخشیده است.»
—یانگجی ژنگ، مدیر مهندسی، WeTV (Tencent)
در مرحله بعد، تیم مهندسی WeTV قصد دارد Chrome DevTools برای عامل‌ها و «راهنمای وب نوین» را در آزمایش سرتاسری برای نسخه‌های کد آتی ارائه دهد.
منابع
برای راه‌اندازی گردش کار مشابه، این منابع را کاوش کنید: