منتجك لم يعد للبشر فقط: لماذا يجب أن تفكر بوكلاء الذكاء الاصطناعي؟

تخيّل أن مطورًا يريد إضافة نظام دفع إلى تطبيقه.

في السابق، كان يفتح موقع التوثيق، ويبحث عن طريقة الربط، ثم يقرأ الأمثلة ويكتب الكود بنفسه.

اليوم، قد يفتح Cursor أو Claude Code ويكتب جملة واحدة:

"أضف نظام الدفع إلى تطبيقي باستخدام Stripe."

بعدها يبدأ وكيل الذكاء الاصطناعي بالبحث عن المعلومات اللازمة وكتابة الكود.

لكن ماذا يحدث إذا لم يجد توثيقًا واضحًا أو استخدم معلومات قديمة؟

قد يكتب كودًا يبدو صحيحًا، لكنه لا يعمل عند تشغيل التطبيق، أو يستخدم طريقة قديمة لم تعد مدعومة.

وهنا تظهر مشكلة جديدة يجب أن ينتبه لها أصحاب المنتجات التقنية:

لم يعد الإنسان هو القارئ الوحيد لتوثيق منتجك. أصبح وكيل الذكاء الاصطناعي قارئًا آخر، وقد يكون أول من يتعامل معه.

لهذا أعتقد أن أدوات المطورين يجب أن تبدأ بتجهيز منتجاتها للذكاء الاصطناعي، وليس فقط للمستخدمين التقليديين.

وهناك ثلاث خطوات تساعد على تحقيق ذلك: توثيق سهل القراءة، وقواعد واضحة للوكلاء، وواجهة MCP عند الحاجة.

1. اجعل توثيقك مفهومًا للبشر والذكاء الاصطناعي

مواقع التوثيق التقليدية صُممت للبشر.

تحتوي على قوائم جانبية، وأزرار، وتبويبات للتنقل بين لغات البرمجة، وأمثلة تفاعلية.

هذه العناصر مفيدة للمطور، لكنها قد تجعل استخراج المعلومات أصعب على وكيل الذكاء الاصطناعي.

لنفترض أن الوكيل يريد معرفة طريقة إنشاء مستخدم جديد في خدمتك.

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

الحل ليس بناء موقع توثيق منفصل للذكاء الاصطناعي.

الحل هو توفير المحتوى نفسه بصيغة بسيطة ومنظمة، يسهل على الإنسان والوكيل قراءتها.

وهذا يساعد على:

• تقليل الأخطاء الناتجة عن استخدام معلومات قديمة.
• تسريع عملية ربط منتجك بالتطبيقات الأخرى.
• تحسين جودة الكود الذي تكتبه أدوات الذكاء الاصطناعي.
• تقليل طلبات الدعم الناتجة عن استخدام طرق غير صحيحة.

كلما كان توثيقك واضحًا، زادت فرصة أن يستخدم المطور منتجك بنجاح من المحاولة الأولى.

2. ابدأ بملف llms.txt

من أبسط الطرق لتجهيز التوثيق ملف يسمى llms.txt.

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

تضع هذا الملف في جذر موقعك، مثل:

https://example.com/llms.txt

ويحتوي عادةً على تعريف مختصر بالمنتج وروابط إلى الصفحات المهمة، مثل دليل البدء، والمصادقة، وواجهات API، وأمثلة الاستخدام.

على سبيل المثال:

# My API
An API for managing online payments.
## Documentation
- [Getting Started](/docs/start.md)
- [Authentication](/docs/auth.md)
- [Create Payment](/docs/payments.md)
- [Webhooks](/docs/webhooks.md)

من المفيد أيضًا توفير صفحات التوثيق بصيغة Markdown (.md)، لأنها تعرض المحتوى مباشرة دون عناصر الواجهة غير الضرورية.

شركة Stripe مثال جيد على ذلك؛ فهي توفر صفحات توثيق بصيغة Markdown، إلى جانب موارد مخصصة لاستخدام منتجاتها مع أدوات الذكاء الاصطناعي.

يمكنك الاطلاع عليها هنا: Stripe – Building with LLMs

لكن هناك نقطة مهمة: llms.txt ليس معيارًا تلتزم به جميع أدوات الذكاء الاصطناعي تلقائيًا، ولا يضمن أن أي وكيل سيقرأه.

هو طريقة إضافية لتنظيم المعلومات وتسهيل الوصول إليها للأدوات التي تدعمه.

نصيحتي: ابدأ بصفحات التوثيق الأساسية، وتأكد من تحديثها باستمرار. توثيق مختصر وصحيح أفضل من مئات الصفحات القديمة.

3. أعطِ وكيل الذكاء الاصطناعي قواعد واضحة

التوثيق يشرح للوكيل كيف يستخدم منتجك.

أما القواعد، فتوضح له كيف ينبغي أن يتصرف أثناء استخدامه.

يمكنك كتابة هذه القواعد داخل ملف مثل AGENTS.md في مشروعك، أو توفير تعليمات مخصصة عند اتصال الوكيل بخادم MCP.

على سبيل المثال، إذا كنت تطور منصة لإدارة قواعد البيانات، فقد تكتب قواعد مثل:

• اقرأ التوثيق الحالي قبل إنشاء أي استعلام.
• لا تحذف الجداول أو البيانات دون تأكيد المستخدم.
• لا تعرض كلمات المرور أو مفاتيح API.
• استخدم صلاحيات محدودة عند تنفيذ العمليات.
• إذا لم تكن متأكدًا من العملية، اسأل المستخدم أولًا.

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

وتستخدم مشاريع وأدوات معروفة هذا الأسلوب.

على سبيل المثال، يمكن لملف AGENTS.md توجيه الوكيل لقراءة التوثيق الموجود داخل المشروع بدل الاعتماد على معلومات قديمة عن إصدار مختلف من Next.js.

والفكرة نفسها مفيدة عند التعامل مع قواعد البيانات أو خدمات الاستضافة أو أنظمة الدفع.

لكن هل تكفي هذه القواعد لحماية منتجك؟

لا، وهنا يجب أن نفرّق بين توجيه الذكاء الاصطناعي وتأمين النظام نفسه.

4. قواعد الذكاء الاصطناعي ليست بديلًا عن الأمان

قد تكتب للوكيل: "لا تحذف بيانات المستخدمين دون إذن."

لكن هذا لا يمنع شخصًا من إرسال طلب حذف مباشرة إلى API، دون استخدام وكيل أصلًا.

وحتى الوكلاء أنفسهم قد يخطئون أو يتأثرون بتعليمات خبيثة موجودة في البيانات التي يقرؤونها.

تُعرف هذه المشكلة باسم Prompt Injection أو «حقن التعليمات».

على سبيل المثال، قد تحتوي تذكرة دعم على تعليمات خفية تطلب من الوكيل قراءة معلومات خاصة وإرسالها إلى جهة خارجية.

إذا كان الوكيل يمتلك صلاحيات واسعة، فقد يؤدي اتباع تلك التعليمات إلى تسريب البيانات.

وهذا ليس مجرد احتمال نظري.

في عام 2025، عرض باحثون مثالًا لهجوم يستهدف وكيلًا متصلًا بقاعدة بيانات عبر Supabase MCP، حيث استُخدم محتوى غير موثوق لمحاولة دفع الوكيل إلى كشف معلومات خاصة.

يمكن قراءة تفاصيل التجربة في بحث General Analysis.

لذلك يجب أن نتعامل مع قواعد الوكلاء باعتبارها وسيلة لتقليل الأخطاء، وليست حاجزًا أمنيًا يمكن الاعتماد عليه وحده.

القاعدة الأهم: صمّم نظامك بحيث تبقى البيانات محمية، حتى لو تجاهل الوكيل جميع التعليمات.

5. وفّر خادم MCP إذا كان منتجك يحتاج إليه

بعد تجهيز التوثيق والقواعد، تأتي الخطوة الأكثر فائدة للمنتجات التي تقدم عمليات يمكن تنفيذها برمجيًا.

وهي توفير خادم MCP.

اختصار MCP يعني Model Context Protocol، وهو بروتوكول يتيح لوكلاء الذكاء الاصطناعي الاتصال بالأدوات والخدمات بطريقة موحدة.

بمعنى أبسط، بدل أن يقرأ الوكيل توثيق API ويحاول كتابة كل طلب بنفسه، يمكنك توفير أدوات جاهزة له لتنفيذ مهام محددة.

لنفترض أنك تبني منصة لإدارة الفواتير.

يمكن أن توفر أدوات مثل:

• list_invoices — عرض الفواتير.
• get_invoice — جلب تفاصيل فاتورة.
• create_draft_invoice — إنشاء مسودة فاتورة.
• search_customers — البحث عن عميل.

عندما يطلب المستخدم من وكيله إنشاء مسودة فاتورة، يستطيع استدعاء الأداة المناسبة مباشرة.

خادمك هو الذي يتحقق من البيانات وينفذ العملية وفق القواعد والصلاحيات المحددة.

وهذا يقلل اعتماد الوكيل على تخمين طريقة بناء طلبات HTTP أو اختيار المعاملات المناسبة.

وتقدم شركات مثل Stripe وGitHub وVercel وNeon خوادم MCP تساعد المطورين على استخدام خدماتها من داخل أدوات الذكاء الاصطناعي.

يمكنك التعرف على البروتوكول من موقع MCP الرسمي.

هل يحتاج كل منتج إلى MCP؟

ليس بالضرورة.

إذا كان منتجك مجرد مكتبة برمجية بسيطة، فقد يكون التوثيق الواضح والأمثلة العملية كافيين.

أما إذا كان يقدم API لإدارة المشاريع أو البيانات أو المدفوعات أو الاستضافة، فقد يكون MCP إضافة مفيدة جدًا.

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

6. كيف تحمي منتجك عند استخدام MCP؟

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

يمكن تقسيم الحماية إلى ثلاث طبقات رئيسية.

الطبقة الأولى: تعليمات الوكيل

توضح ما ينبغي فعله وما يجب تجنبه، وتساعد على تقليل الأخطاء غير المقصودة.

لكنها ليست ضمانًا أمنيًا.

الطبقة الثانية: خادم MCP

يحدد الأدوات التي يستطيع الوكيل الوصول إليها، ويتحقق من المدخلات، ويطبّق حدود الاستخدام المناسبة.

فمثلًا، إذا كان الوكيل يحتاج إلى قراءة الفواتير فقط، فلا داعي لإتاحة أداة لحذف العملاء أو تصدير جميع البيانات.

الطبقة الثالثة: الخادم الأساسي وAPI

هذه أهم طبقة.

يجب أن يتحقق خادمك من صلاحية كل طلب، بغض النظر عن مصدره.

ولذلك أنصح بالآتي:

• استخدم OAuth أو آليات مصادقة مناسبة مع صلاحيات محددة.
• لا تمنح الوكلاء مفاتيح إدارية بصلاحيات كاملة.
• تحقق من ملكية المستخدم للبيانات التي يريد الوصول إليها.
• ضع حدودًا لعدد الطلبات لمنع الاستهلاك غير الطبيعي.
• اطلب موافقة صريحة قبل العمليات الحساسة، مثل حذف البيانات أو تنفيذ المدفوعات.
• احتفظ بسجل للعمليات لتسهيل المراجعة واكتشاف المشكلات.

ولا تعتمد على طلب التأكيد داخل المحادثة وحده. ينبغي فرض التحقق من الصلاحيات والموافقات اللازمة داخل النظام نفسه أيضًا.

بهذه الطريقة، حتى إذا أخطأ الوكيل، تبقى قدرته على إحداث الضرر محدودة.

7. لا تجعل منتجك صعب الاستخدام مع الذكاء الاصطناعي

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

قد تكون بعض هذه القيود مبررة لحماية المعلومات الخاصة أو الحد من الاستهلاك غير المصرح به.

لكن إخفاء التوثيق العام بالكامل قد يجعل تجربة المطور أصعب.

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

الأفضل هو إتاحة التوثيق العام بشكل منظم، مع إبقاء البيانات الحساسة والعمليات الخاصة خلف مصادقة وصلاحيات حقيقية.

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

من أين تبدأ؟

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

ابدأ بثلاث خطوات:

1. حسّن التوثيق: وفّر ملف llms.txt وصفحات Markdown واضحة ومحدّثة.
2. اكتب قواعد للوكلاء: استخدم AGENTS.md أو تعليمات مناسبة لتوضيح أفضل الممارسات.
3. فكّر في MCP: حدّد العمليات المتكررة التي يمكن تحويلها إلى أدوات آمنة ومحدودة الصلاحيات.

يمكنك تنفيذ هذه الخطوات تدريجيًا، حسب احتياجات منتجك ومستخدميه.

الخلاصة

طريقة تطوير البرمجيات تتغير.

المطور لم يعد مضطرًا إلى كتابة كل سطر بنفسه، وأصبح بإمكانه الاعتماد على وكيل ذكاء اصطناعي للبحث عن المعلومات وكتابة الكود وتنفيذ بعض العمليات.

وهذا يغيّر أيضًا طريقة تصميم المنتجات الموجهة للمطورين.

لم يعد كافيًا أن يكون لديك API جيد وتوثيق واضح للبشر فقط.

من المفيد أن يكون منتجك سهل الفهم والاستخدام من قبل أدوات الذكاء الاصطناعي، مع قواعد واضحة وصلاحيات مدروسة.

منتجك القادم قد يستخدمه مطور من خلال وكيل ذكاء اصطناعي دون أن يفتح موقع التوثيق بنفسه. فهل منتجك جاهز لذلك؟

المصادر

• llms.txt – المقترح والتوثيق
• Stripe – بناء التطبيقات باستخدام LLMs
• MCP – الموقع والتوثيق الرسمي
• AGENTS.md – الموقع الرسمي
• OWASP – مخاطر حقن التعليمات
• General Analysis – دراسة هجوم على Supabase MCP
• Simon Willison – The Lethal Trifecta