كيف تكتب وثيقة نطاق لوكيل ذكاء اصطناعي

نُشر في أغسطس 2026.

TL;DR: وثيقة النطاق هي ما يحوّل عبارة “أريد وكيل ذكاء اصطناعي لعملي” إلى رقم يمكنك عرضه وعميل يمكنه الموافقة عليه. تحتاج إلى ستة أجزاء: المُحفّز، والمدخلات، والمخرجات، والأدوات التي يلمسها، وما هو مستثنى صراحة، وقائمة اختبارات قبول مكتوبة. اكتبها قبل أن تعرض رسوم البناء، لا بعدها. أنا أسعّرها كتسليم تدقيق ثابت بين 500 و1000 دولار، منفصل عن البناء.

[منظور المشغّل] أدير أكثر من 30 وكيلاً في بيئة الإنتاج عبر علامة استشارية وPickleland، منشأة للبيكل بول في Pflugerville بولاية تكساس، وقد حددت نطاق بناء وكلاء لعملاء بناءً على هذه الخبرة. السبب الأكثر شيوعاً في فشل مشروع وكيل ليس الكود — بل أن لا أحد كتب ما يعنيه “الانتهاء” قبل إرسال الفاتورة. وثيقة النطاق تحل ذلك في جلسة واحدة. إنها التسليم الأقل بريقاً الذي أنتجه، والتسليم الذي يوفر أكبر قدر من الجدال.

جدول المحتويات

لماذا وثيقة نطاق، لا رسالة عرض

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

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

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

الأشياء الستة التي تحتاجها وثيقة النطاق

1. المُحفّز. ما الذي يبدأ تشغيل الوكيل — إرسال نموذج، وقت مجدول، بريد إلكتروني وارد، webhook من أداة أخرى. سمّ المُحفّز الدقيق، لا فئة المُحفّز. “يعمل عند إرسال نموذج عميل محتمل” هو نطاق. “يتعامل مع العملاء المحتملين الواردين” ليس كذلك.

2. المدخلات. ما البيانات التي يستقبلها الوكيل ومن أين تأتي. اذكر الحقول، لا المصدر فقط — “الاسم، البريد الإلكتروني، حجم الشركة، وحقل النص الحر من إرسال Typeform”، لا “بيانات النموذج”.

3. المخرجات. ما الذي ينتجه الوكيل وإلى أين يذهب. نفس القاعدة: سمّ الوجهة والصيغة. “ينشر رداً مسودة في قناة #leads على Slack للموافقة البشرية” هو نطاق. “يرد على العملاء المحتملين” ليس كذلك.

4. الأدوات والتكاملات التي يلمسها. كل API أو قاعدة بيانات أو منصة يستدعيها الوكيل. هنا أيضاً تكتب أي شيء لا تدمجه صراحةً — العميل الذي يفترض أن نظام إدارة علاقات العملاء (CRM) الخاص به مشمول لأنه ذكره مرة واحدة في مكالمة الاستكشاف هو المصدر الأكثر شيوعاً لزحف النطاق الذي رأيته.

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

6. قائمة اختبارات القبول. القائمة الفعلية للحالات التي يجب أن يجتازها الوكيل النهائي قبل استحقاق الدفعة النهائية. ليس “يعمل بشكل جيد” — بل حالات محددة وقابلة للتحقق: “يصنّف بشكل صحيح 9 من أصل 10 عملاء محتملين نموذجيين من مجموعة البيانات المقدمة”، “ينشر بنجاح في قناة Slack المرتبطة دون تدخل يدوي”، “يتعامل مع إرسال مشوّه (حقل بريد إلكتروني مفقود) دون تعطل”. هذا هو أهم قسم في الوثيقة على الإطلاق، لأنه القسم الذي يمكن للطرفين الرجوع إليه لاحقاً دون إعادة الجدال حول ما كان مقصوداً.

النموذج

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

AGENT SCOPE DOCUMENT — [Client name] / [Project name]
Date: [date]

1. TRIGGER
   [What starts this agent running]

2. INPUTS
   [Exact data fields and their source]

3. OUTPUTS
   [What the agent produces, in what format, sent where]

4. TOOLS & INTEGRATIONS
   Included: [every API/platform/database touched]
   Explicitly excluded: [anything adjacent that is NOT built]

5. EXCLUSIONS
   [What this agent will not do, even if related]

6. ACCEPTANCE TESTS
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   ...

BUILD FEE: $[amount], due [payment terms]
MAINTENANCE RETAINER: $[amount]/month, starting [date]
CHANGE REQUESTS: priced separately, quoted before work starts

Signed: _______________  Date: _______

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

كيف أدير المكالمة التي تنتج هذه الوثيقة

أسعّر جلسة تحديد النطاق نفسها كتدقيق ثابت بين 500 و1000 دولار، منفصل عن رسوم البناء — لا يُدمج فيها أبداً، حتى عندما يمضي العميل قدماً. لسببين: يمنع ذلك مرحلة تحديد النطاق من أن تصبح عمل مبيعات غير مدفوع، ويجعل العميل يأخذ المكالمة على محمل الجد بدلاً من معاملتها كاستشارة مجانية.

المكالمة نفسها تستغرق 30 إلى 45 دقيقة، منظمة حول الأقسام الستة أعلاه بالترتيب. لا أدع المحادثة تنجرف إلى “ما الذي يمكن لوكيل ذكاء اصطناعي فعله نظرياً لعملك” — تلك محادثة مختلفة وأكثر تكلفة، وهي التي تنتج وثائق لا يستطيع أحد تسعيرها. أطلب المُحفّز أولاً، لأن العميل الذي لا يستطيع تسمية ما يبدأ العملية عادةً لا يملك سير عمل مستقراً بما يكفي للأتمتة بعد — وهذا يستحق الكشف عنه قبل أن يلتزم أي منكما ببناء.

أرسل الموجّه، لا الصفحة الفارغة

لا أكتب المسودة الأولى للوثيقة يدوياً. آخذ ملاحظات المكالمة — غالباً مجرد فقرة فوضوية من النقاط — وألصقها في Claude:

Here are my raw notes from a scoping call for an AI agent build. Turn them
into a scope document with exactly these six sections: Trigger, Inputs,
Outputs, Tools & Integrations, Exclusions, Acceptance Tests. For each
section, flag anything the notes don't specify clearly enough to build
against, rather than guessing or filling the gap yourself. The acceptance
tests need to be specific and checkable — reject vague criteria like
"works correctly" and either sharpen them into a concrete test case or
flag them for me to clarify with the client.

[paste raw notes]

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

أخطاء شائعة ما زلت أراها

كتابة قسم الاستثناءات في النهاية، أو تخطّيه. قسم الاستثناءات هو القسم الذي يعامله معظم الناس على أنه اختياري. إنه القسم الذي يمنع أكبر عدد من النزاعات. اكتبه قبل اختبارات القبول، لا بعدها.

اختبارات قبول تصف السلوك بدلاً من النتائج. “يجب أن يفهم الوكيل نبرة العميل” هو سلوك. “رد الوكيل المسودة يُعتمد دون تعديلات في 7 من أصل 10 حالات نموذجية” هو نتيجة. النتائج فقط قابلة للتحقق.

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

السماح للعميل بكتابة النطاق. وصف العميل لما يريده بكلماته الخاصة هو مدخل للوثيقة، لا الوثيقة نفسها. لغته عادةً تكون على شكل ميزات (“أريده أن يتعامل مع عملائي المحتملين”)، لا على شكل اختبارات. ترجمة ذلك إلى معايير قبول قابلة للتحقق هي القيمة الفعلية لجلسة تحديد النطاق — ولهذا السبب هي تسليم مدفوع، لا نموذجاً يملأه العميل بنفسه.

الأدوات التي أستخدمها لإدارة هذا

Claude يصيغ الوثيقة من ملاحظات المكالمة الخام باستخدام الموجّه أعلاه، ويبلّغ عن الفجوات بدلاً من التخمين.

Notion هو المكان الذي تعيش فيه وثيقة النطاق النهائية، مشتركة مع العميل قبل تحصيل أي دفعة مقدمة — نفس المكان الذي أحتفظ فيه بباقي السجل الورقي للمشروع.

Airtable يتتبع أي المشاريع في مرحلة تحديد النطاق مقابل الموقّعة مقابل قيد البناء، صف واحد لكل عميل، بحيث لا تبقى وثيقة نطاق دون توقيع لأسابيع دون أن يلاحظ أحد.

الأسئلة الشائعة

ما الطول الذي يجب أن تكون عليه وثيقة النطاق؟

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

ماذا لو أراد العميل تغيير النطاق بعد التوقيع؟

هذا طلب تغيير، يُسعّر بشكل منفصل ويُعرض قبل بدء العمل — اكتب هذا الشرط في الوثيقة نفسها، كما في النموذج أعلاه. وثيقة نطاق يمكن توسيعها بصمت بعد التوقيع ليست وثيقة نطاق فعلياً.

هل أحتاج إلى وثيقة نطاق لأتمتة صغيرة جداً؟

نعم، فقط نسخة قصيرة. القيمة ليست في الطول — بل في وجود قائمة اختبارات قبول مكتوبة قبل بدء البناء، بحيث يكون “الانتهاء” قائمة تحقق بدلاً من شعور. شهدت مشاريع صغيرة حُدد نطاقها بشكل غير رسمي استغرقت وقتاً أطول من مشاريع كبيرة حُدد نطاقها بشكل صحيح، لهذا السبب بالضبط.

من يملك وثيقة النطاق نفسها — هل هي جزء من التسليم؟

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

الخطوات التالية: دورتي في الذكاء الاصطناعي للمبتدئين تغطي بناء الوكلاء التي تصفها وثيقة نطاق كهذه. برنامج cowork مخصص للمشغّلين الذين يريدون بيئة منظمة لممارسة تحديد النطاق وبناء هذا النوع من العمل. إذا كنت تفضّل أن تُكتب لك وثيقة النطاق، احجز جلسة 30 دقيقة.