نظام إدارة محتوى مصمم لوكلاء الذكاء الاصطناعي

إليك اختباراً جديراً بالتجربة على أي نظام لإدارة المحتوى (CMS) في عام 2026: اطلب من وكيل ذكاء اصطناعي تحديث صفحة الأسعار بعشر لغات مختلفة، ثم احسب عدد عمليات الدمج المخصصة التي يحتاجها قبل أن يبدأ عمله. بالنسبة لمعظم الأنظمة المستضافة، ستكون الإجابة هي الحاجة إلى عميل واجهة برمجة التطبيقات (API)، وبيانات اعتماد، ومخطط لا يمكنه رؤيته، وبيئة اختبار معزولة تأمل ألا يتجاوزها. أما بالنسبة لمستودع مليء بملفات MDX، فالإجابة هي صفر. يمتلك الوكيل بالفعل كل ما يحتاجه: إمكانيات القراءة، والبحث، والتحرير، والمقارنة.

يتبنى Scribe هذا النهج بالكامل. فهو نظام إدارة محتوى يعتمد في بنيته الأساسية على المهام التي يبرع فيها وكلاء الذكاء الاصطناعي بالفعل.

القراءة: كل شيء عبارة عن ملف

لا يحتاج وكيل الذكاء الاصطناعي الذي يستكشف مشروع Scribe إلى أية وثائق لمعرفة طريقه. تُعرّف أنواع المحتوى كمخططات Zod في ملف تكوين واحد، مما يجعل بنية كل مستند قابلة للقراءة ككود برمجي. المستندات عبارة عن ملفات MDX حيث يمثل اسم الملف المعرّف الخاص به (slug). تُحفظ الترجمات في قاعدة بيانات SQLite مجاورة لها. لا يوجد أي شيء مخفي خلف لوحة تحكم إدارية؛ المستودع هو النظام بأكمله، وإجراء بحث شامل داخل content/ يشمل كل زاوية فيه حقاً.

الكتابة: حواجز أمان بدلاً من الثقة المطلقة

تكمن المشكلة مع وكلاء الذكاء الاصطناعي في أنهم قد يكتبون أحياناً محتوى يحتوي على أخطاء خفية. يقدم Scribe الحل ذاته المتبع مع البشر، ولكنه يُطبق بصرامة أكبر:

• المخططات تضبط كل مستند. يجب أن يتوافق الجزء التمهيدي (frontmatter) مع مخطط Zod الخاص بنوع المحتوى. أي حقل وهمي أو حقل مطلوب مفقود سيؤدي إلى فشل أمر scribe validate بدلاً من التأثير على بيئة الإنتاج.
• يجب أن تكون النصوص قابلة للتجميع. يُجمع كل نص MDX في وقت التحقق، مما يضمن اكتشاف أي مكون غير صالح أو خطأ في الصياغة قبل بدء عملية البناء.
• الروابط لا تتعطل في صمت. تشير رموز العلاقات المضمنة إلى المستندات حسب النوع والمعرّف، ويُظهر النظام أخطاء تحقق لأي رمز يشير إلى مستند غير موجود. لا يمكن لوكيل الذكاء الاصطناعي إدراج رابط داخلي معطل وتجاوز أداة التحقق.
• الحذف عملية مدروسة وليست عشوائية. يقوم أمر scribe delete بحساب السلسلة الكاملة للمراجع أولاً، وتُوقف الحواجز العملية إذا لزم الأمر. يرى الوكيل الذي يحذف صفحة ما العناصر الأخرى المتأثرة بدقة.

النتيجة هي أن السماح لوكيل الذكاء الاصطناعي بتحرير المحتوى لم يعد أمراً مقلقاً. يتمثل الفشل في التعديل الخاطئ بظهور سطر أحمر في واجهة سطر الأوامر (CLI)، تماماً مثل فشل أي اختبار برمجي.

المراجعة: المقارنة هي الواجهة

نظراً لأن كل تغيير يُسجل كالتزام (commit)، يصل عمل الوكيل بنفس الطريقة التي يراجع بها فريقك العمل عادة: كطلب سحب (pull request). لا يوجد سجل تدقيق منفصل للتحقق منه ولا يوجد سجل لنظام إدارة المحتوى يجب مطابقته مع git. تسجل اللقطات الإنجليزية المصدر الذي استُخدمت منه كل ترجمة، لذلك حتى المحتوى المترجم بواسطة الذكاء الاصطناعي يمتلك مسار منشأ قابل للمراجعة: لقد جاء هذا النص الفرنسي من ذلك النص الإنجليزي باستخدام هذا النموذج في هذا التاريخ.

تكمل مساحة العمل المحلية الدورة للبشر. يمكنك تصفح ما عدّله الوكيل، والبحث عبر كل مستند، ومعاينة النصوص مع الروابط والصور المفعلة، والتحقق من تغطية الترجمة بلمحة سريعة. الوكلاء يحررون الملفات والبشر يتحققون منها في مساحة العمل.

تقديم المحتوى للذكاء الاصطناعي وليس به فقط

الخصائص ذاتها التي تجعل من السهل على وكلاء الذكاء الاصطناعي الكتابة في Scribe، تجعل قراءة موقعك سهلة لأنظمة الذكاء الاصطناعي. يقوم أمر scribe export-static بكتابة نسخ MDX عادية لكل صفحة، وحسب كل لغة، في دليل ثابت: نصوص نظيفة وخفيفة التنسيق تتعامل معها زواحف النماذج اللغوية الكبيرة ومحركات الإجابة بشكل أفضل بكثير من صفحات HTML المعروضة. محتواك مقروء بوضوح للذكاء الاصطناعي في كلا طرفي مسار العمل.

هذا ليس مجرد افتراض

هذا الموقع هو خير مثال عملي. تم تنفيذ عملية توحيد سجل التغييرات، وإعادة هيكلة الوثائق، ومعظم عمليات صيانة المحتوى التي تقرأها بواسطة وكلاء ذكاء اصطناعي يعملون في المستودع، وتم التحقق من صحتها بواسطة scribe validate، وراجعها عنصر بشري من خلال فحص الفروق (diffs). لقد صُمم النموذج القائم على git للفرق؛ وتبيّن أنه بالضبط ما يحتاجه وكلاء الذكاء الاصطناعي أيضاً.

إذا كنت تبني موقعاً سيساعد وكلاء الذكاء الاصطناعي في صيانته، فابدأ بـ دليل البدء وكلّف أحدهم بمهمة. ستبدو بيئة العمل مألوفة جداً بالنسبة له.