تاريخ النشر: 10 نوفمبر 2026
WeTV هي منصة بث فيديوهات عالمية تابعة لشركة Tencent. وتقدّم للمشاهدين في جنوب شرق آسيا والأسواق العالمية الأخرى مسلسلات درامية وأنمي وبرامج منوعات. بالنسبة إلى المواقع الإلكترونية التي تركّز على الفيديو، يحدّد الأداء ما إذا كان المشاهدون سيواصلون المشاهدة، وما إذا كانت محركات البحث ستعرض المحتوى، وما إذا كان التشغيل سلسًا.
لا يطرح فريق هندسة الويب في WeTV أي رمز برمجي لا يحقّق أهداف الأداء. لفترة طويلة، كان الالتزام بهذا الحدّ يعني أنّه على المطوّر التوقف عن عمله وفتح Chrome وتحليل الصفحة يدويًا في كل مرة يفشل فيها الإصدار في اجتياز عملية التحقّق. استغرق تتبُّع إحدى حالات التراجع وإصلاحها حوالي أربع ساعات.
واليوم، يتولّى وكيل الترميز المستند إلى الذكاء الاصطناعي هذه المهمة كجزء من مسار التكامل المستمر/النشر المستمر. باستخدام أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء، يفحص الوكيل الصفحة في متصفّح مباشر. باستخدام إرشادات الويب الحديث، يكتب Gemini الإصلاحات التي تتّبع معايير منصة الويب الحالية. يتمكّن سير العمل الآن من تشخيص وحلّ %90 من اختبارات الأداء التي تعذّر إجراؤها تلقائيًا، وانخفض الوقت المستغرَق من عملية تحقّق تعذّر إجراؤها إلى إصلاح تم التحقّق منه من أربع ساعات إلى 30 دقيقة، بما في ذلك عملية الإنشاء الكاملة والتقييم اليدوي.
التحدي: مطوّر عالق بين المحرّر والمتصفّح
كان مهندسو WeTV يستخدمون أدوات الترميز المستندة إلى الذكاء الاصطناعي في بيئة التطوير المتكاملة (IDE). كانت هذه الأدوات قادرة على كتابة الرموز البرمجية، ولكن لم يكن بإمكانها معرفة ما تفعله هذه الرموز بعد تشغيلها في المتصفّح. لذلك تم تقسيم العمل إلى قسمين. يكتب المهندسون الرموز البرمجية في المحرّر، ثم ينتقلون إلى Chrome لنشرها وفحصها والتحقّق منها. كل إصلاح يعني الالتفاف حول تلك الحلقة مرة أخرى يدويًا.
كان الانقسام أكثر ضررًا عند بوابة الإطلاق. يُجري مسار CI/CD في WeTV عمليات تتبُّع للأداء في كل إصدار، ويحافظ على قيمة "متغيّرات التصميم التراكمية" (CLS) عند 0.1 أو أقل. وعندما يتجاوز إصدار هذا الحدّ، كان المسار يضع علامة عليه، ولكن العثور على السبب كان لا يزال يتم يدويًا. كان على المهندس فتح "أدوات مطوري البرامج في Chrome" وتسجيل تتبُّع والعثور على العنصر الذي تم نقله وإرسال هذه النتيجة إلى المحرّر وكتابة إصلاح وتشغيل عملية التحقّق مرة أخرى. استغرق تراجع CLS واحد حوالي أربع ساعات من وقت الهندسة.
احتاج الفريق إلى وكيل يمكنه التعامل مع كلا الجزأين من المهمة: النظر إلى الصفحة قيد التشغيل، ثم إصلاح الرمز وفقًا لمعيار معروف.
الحلّ: ربط الوكيل بالمتصفّح ومعايير الويب
نقلت WeTV عملية التحقّق من الأداء إلى مسار طلب الدمج (MR). عندما يفتح المطوّر طلب دمج، يبدأ مسار CI/CD بيئة يتم فيها تشغيل وكيل الترميز المستند إلى الذكاء الاصطناعي محليًا مع ميزتَين لم تتوفّرا في أدوات بيئة التطوير المتكاملة (IDE) لدى الفريق:
- أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء: يشغّل هذا الخيار خادم "بروتوكول سياق النموذج" (MCP) ويربط الوكيل بمثيل Chrome نشط. يمكن للوكيل تسجيل تتبُّعات الأداء (من بين ميزات "أدوات مطوّري البرامج في Chrome" الأخرى) والتحقّق من كيفية عرض رمز الواجهة الأمامية فعليًا، بالطريقة نفسها التي يتّبعها المطوّر في "أدوات مطوّري البرامج".
- إرشادات الويب الحديث: مهارة وكيل تتضمّن أفضل الممارسات المتعلّقة بمنصات الويب وبيانات التوافق مع المتصفّحات. فهي توجّه الوكيل بعيدًا عن الأنماط القديمة ونحو الإصلاحات المستندة إلى ميزات النظام الأساسي الحديث للويب.
تُخبر "أدوات مطوّري البرامج" المخصّصة للوكلاء الوكيل بما تعطّل. وتحدّد إرشادات الويب الحديث طريقة حلّ المشكلة.
مثال من العالم الواقعي: تغيُّر في التصميم على صفحة تشغيل الحلقة
أثناء أحد طلبات الدمج، شغّل الوكيل أداة performance_start_trace على
صفحة تشغيل الحلقة على الكمبيوتر المكتبي. سجّل التتبُّع قيمة CLS تبلغ 0.39، أي ما يقرب من أربعة
أضعاف الحد الأقصى البالغ 0.1.
اطلب من الوكيل تشخيص المشكلة قبل إجراء التعديلات
لا يسمح 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.
هناك جزأين من هذا الطلب يحملان معظم الوزن. يمنع مبدأ "التشخيص أولاً، ثم تعديل الرمز" الوكيل من معالجة الأعراض فقط. توجّه الخطوة 2 الوكيل لاستخدام
performance_analyze_insight مع insightName: 'CLSCulprits'، فيُبلغ عن
العنصر والتوقيت والنتيجة بدقة بدلاً من مجرد شك عام.
في الفيديو التالي، عند تنفيذ الطلب، يبحث الوكيل عن الدليل ذي الصلة في إرشادات الويب الحديث لتطبيق الإصلاحات باستخدام ميزات الويب الحديثة ذات الصلة بمتغيّر التصميم التراكمي (CLS)، ويستخدم "أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء" لفتح نسخة من متصفّح Chrome وتسجيل تتبُّع الأداء.
يتيح هذا المزيج من بيانات التشخيص أثناء التشغيل والإرشادات المنظَّمة إجراء إصلاحات تلقائية لتغييرات التنسيق المعقّدة. في ما يلي مثال على مشكلة تم حلّها من خلال سير العمل المبرمَج.
العثور على السبب الأساسي
أشار التتبّع إلى مشغّل الفيديو. يعرض WeTV المشغّل على الخادم، ولكن حاوية المشغّل لم تحتفظ بأي ارتفاع له. وعندما أجرى العميل عملية ترطيب الصفحة، زاد ارتفاع الحاوية وتغيّر موضع المحتوى المحيط بها.
تطبيق إصلاح مستند إلى المعايير
ويتمثّل الحلّ في حجز المساحة أثناء العرض من جهة الخادم، ليكون ارتفاع الحاوية مناسبًا قبل عملية تحويل صفحة الويب الثابتة إلى صفحة ديناميكية. في ما يلي مثال على إصلاح كتبه الوكيل بالرجوع إلى دليل css-layout ضمن "إرشادات الويب الحديث":
.play__block--player .play__aside--left {
inline-size: 100%;
block-size: auto;
aspect-ratio: 16/9;
}
بعد أن طبّق الوكيل CSS، أعاد المسار إنشاء الصفحة وشغّل الوكيل عملية التتبُّع نفسها مرة أخرى. وعندما انخفضت قيمة CLS إلى أقل من 0.1، تم نقل رمز التصحيح إلى المراجعة اليدوية.
التأثير: إصدارات أسرع وتنسيقات ثابتة
حقّق تطبيق WeTV تحسينات قابلة للقياس في كفاءة الهندسة واستقرار التنسيق عند إضافة "أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء" و"إرشادات الويب الحديث" إلى سير عمل CI/CD:
- انخفاض بنسبة %87 في الوقت المستغرَق لتصحيح الأخطاء وحلّ المشاكل من البداية إلى النهاية (من 4 ساعات إلى 30 دقيقة)
- يتم تشخيص وحلّ %90 من جميع حالات تراجع الأداء المتكررة تلقائيًا.
لم يعُد المهندسون يخسرون نصف يوم عمل في إنشاء الملفات الشخصية. وعندما يتجاوز الإصدار الحدّ المسموح به، يقرأ الوكيل بيانات التتبُّع ويكتب إصلاحًا ويختبره، ثم يسلّم التصحيح الذي تم التحقّق منه إلى مُراجع بشري. لا يزال المستخدمون يتخذون القرار النهائي، ولكنّهم يبدأون من إصلاح اجتاز الاختبار الذي تعذّر إكماله.
بما أنّه يتم إصلاح حالات تراجع متغيّرات CLS ضمن طلب الدمج، لا تصل هذه الحالات إلى مرحلة الإنتاج. يساعد ذلك في إبقاء الصفحات أقل من الهدف البالغ 0.1، ويحمي ظهور WeTV في نتائج البحث، ويزيل سببًا شائعًا لحظر الإصدار في وقت متأخر من الدورة.
دروس لفريقك
يُعدّ إعداد WeTV خاصًا بمجموعة برامجها، ولكن النمط الكامن وراءه ينتقل إلى معظم الفِرق التي تضع شروطًا للإصدارات بناءً على الأداء:
- شغِّل الوكيل في المكان الذي يحدث فيه الخطأ. يُشغّل WeTV الوكيل من طلب الدمج، لذلك لا يتعين على أي شخص ملاحظة فشل التحقق وبدء جلسة يدويًا.
- اطلب من الوكيل تشخيص المشكلة قبل تعديلها. يؤدي طلب تتبع ومذنب مسمى أولاً إلى إنتاج إصلاحات تستهدف العنصر الفعلي بدلاً من التخمين.
- إقران بيانات وقت التشغيل بمعيار يخبر التتبع الوكيل بالعنصر الذي تم نقله. توضّح إرشادات الويب الحديثة الحلّ الذي يتّبع الممارسات الحالية للمنصة.
- اطلب دليلاً. إنّ إعادة تشغيل عملية التتبّع نفسها التي تعذّر إجراؤها هي دليل موظف الدعم على أنّ عملية الإصلاح تعمل. يتبع P2ER المبدأ نفسه في قاعدة التحقق التجريبي الإلزامية.
- الاستعانة بالمشاركة البشرية: يُجري الوكيل التحقيق، ويراجع المهندس رمزًا برمجيًا تصحيحيًا اجتاز عملية التحقّق.
الملاحظات والخطط المستقبلية
تبيّن لشركة WeTV أنّ الجمع بين بيانات القياس عن بُعد المباشرة لوقت التشغيل من "أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء" والقواعد الموحّدة في "إرشادات الويب الحديث" قد أدى إلى استبعاد تحليل الأداء اليدوي من عملية الإصدار، مع الحفاظ على توافق تغييرات الرموز البرمجية التي يجريها الوكيل مع معايير منصة الويب الحالية.
"كانت النتائج فعّالة للغاية من حيث السرعة والجودة. وقد قدّمت لنا إحصاءات بيانات التشخيص التي توفّرها "أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء" و"إرشادات الويب الحديث" مراجع موثوقة لحلّ المشاكل المعقّدة في التنسيق. ونُجري عمليات تحقّق صارمة بعد كل إصلاح، وقد أدّى معدّل النجاح الحالي والاستقرار إلى تحسين ثقتنا في الإصدارات بشكل كبير".
—يانغجي تشنغ، رئيس قسم الهندسة في WeTV (Tencent)
بعد ذلك، يخطّط فريق الهندسة في WeTV لاستخدام "أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء" و"إرشادات الويب الحديث" في الاختبارات الشاملة لإصدارات الرموز البرمجية القادمة.
الموارد
لإعداد سير عمل مشابه، يمكنك الاطّلاع على هذه المراجع: