موجّهات نظام Claude: كيفية تحديد حدود النبرة للتوثيق التقني

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

هناك أيضًا تغيير حالي في سلوك النموذج يستحق الذكر. اعتبارًا من سبتمبر 2026، تشير وثائق إلغاء الاعتماد الخاصة بـ Anthropic إلى أن temperature وtop_p وtop_k أصبحت غير مدعومة (deprecated) لـ Claude Opus 4.7 والإصدارات الأحدث وClaude Mythos Preview، مع التوصية باستخدام الموجّهات بدلاً من ذلك للتحكم في السلوك. هذا يجعل تعليمات الأسلوب الصريحة على مستوى النظام أكثر أهمية من الوصفات القديمة التي حاولت تشكيل النبرة بشكل أساسي من خلال معاملات أخذ العينات. راجع إرشادات Anthropic لإلغاء اعتماد النماذج وواجهات برمجة التطبيقات.

ما الذي يجب أن تتحكم فيه "حدود النبرة" فعليًا؟

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

على سبيل المثال، قد يُطلب من مساعد توثيق موجه للمطورين الكتابة بنبرة احترافية ومحايدة، وشرح المصطلحات غير المألوفة عند الاستخدام الأول، وتفضيل الجمل المباشرة على لغة التسويق، والتمييز بين الحقائق المؤكدة والفرضيات، واستخدام العناوين وكتل التعليمات البرمجية فقط عندما تحسن التنقل.

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

هل يجب أن تعيش قواعد النبرة في موجّه النظام أم موجّه المستخدم؟

ضع القواعد الدائمة في موجّه النظام والتعليمات الخاصة بالمهمة في موجّه المستخدم. موجّه النظام هو المكان المناسب للقواعد مثل "اكتب لمطوري البرمجيات"، و"تجنب الادعاءات التسويقية"، و"اذكر عدم اليقين بدلاً من التخمين"، و"استخدم نثرًا تقنيًا موجزًا". يجب أن تصف رسالة المستخدم المهمة الحالية: على سبيل المثال، "اكتب دليل ترحيل من الإصدار 4 إلى الإصدار 5 باستخدام ملاحظات الإصدار هذه."

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

نمط بسيط لموجّه النظام

<role>
أنت كاتب توثيق تقني.
</role>

<audience>
اكتب لمطوري البرمجيات ومديري الأنظمة.
افترض معرفة تقنية عامة، لكن اشرح المصطلحات الخاصة بالمنتج عند الاستخدام الأول.
</audience>

<tone>
استخدم نبرة احترافية ومحايدة ومباشرة.
فضل اللغة الملموسة على المبالغة أو الادعاءات الترويجية.
تجنب المصطلحات العامية والحشو والرموز التعبيرية واليقين المبالغ فيه.
حافظ على جمل قصيرة بشكل معقول وفقرات مركزة.
</tone>

<accuracy>
لا تخترع أوامر أو ميزات أو إصدارات أو معايير أداء أو سلوكيات.
ميز بين الحقائق المؤكدة والفرضيات أو التوصيات.
إذا كانت المعلومات المطلوبة مفقودة، اذكر ما هو غير معروف.
</accuracy>

<format>
استخدم عناوين وصفية.
استخدم القوائم فقط للخطوات أو الفحوصات المنفصلة حقًا.
استخدم كتل التعليمات البرمجية للأوامر والأكواد.
لا تضف خاتمة تكرر المقال فقط.
</format>

يعمل هذا لأن كل قسم له وظيفة واحدة. توصي Anthropic بشكل خاص بعلامات XML متسقة ووصفية للموجّهات المعقدة حتى يتمكن النموذج من التمييز بين التعليمات والسياق والأمثلة والمدخلات بشكل أكثر موثوقية.

إلى أي مدى يجب أن تكون قواعد النبرة محددة؟

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

القاعدة الأقوى تصف سلوكًا قابلًا للملاحظة:

عادةً ما تكون التعليمات الإيجابية أسهل في التشغيل من قواعد المنع فقط. بدلاً من القول فقط "لا تبدو ترويجيًا"، أضف البديل المرغوب: "صف الفوائد بمصطلحات ملموسة مرتبطة بنتائج المستخدم."

كيف تمنع قواعد النبرة من الإضرار بالدقة التقنية؟

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

أضف حدود دقة مثل:

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

بالنسبة للتوثيق التقني، غالبًا ما تكون هذه القاعدة أكثر قيمة من تعليم عام لـ "تجنب الهلوسة"، لأنها تحدد السلوك المتوقع عندما تكون الأدلة مفقودة.

هل يجب أن تحدد الإسهاب في موجّه النظام؟

نعم، إذا كانت طول وكثافة المستند مهمة. تشير إرشادات الموجّه الحالية لـ Anthropic إلى أن نماذج Claude الحديثة تختلف في أسلوب التواصل الافتراضي والإسهاب. تنصح الوثائق تحديدًا بالمطالبة صراحةً بالإيجاز عند الحاجة بدلاً من افتراض أن الجهد أو إعدادات النموذج الأخرى ستتحكم في طول الإجابة المرئية بشكل متسق.

يمكن لحدود التوثيق العملية أن تحدد الكثافة بدلاً من عدد كلمات ثابت:

ابدأ بالمعلومات اللازمة للتصرف.
استخدم شرحًا كافيًا لجعل التعليمات آمنة وغير غامضة.
لا تكرار نفس التوصية في المقدمة والجسم والخاتمة.
للإصلاحات البسيطة، فضل الأقسام القصيرة.
لمواضيع البنية أو الترحيل، اشرح المقايضات والمتطلبات المسبقة بمزيد من العمق.

هذا يتوسع بشكل أفضل من تعليم شامل "اكتب دائمًا 1,000 كلمة".

كم عدد الأمثلة التي يجب أن تتضمنها؟

استخدم الأمثلة عندما تترك قواعد النثر مجالًا للتفسير. تصف Anthropic الأمثلة بأنها واحدة من أكثر الطرق موثوقية لتوجيه التنسيق والنبرة والهيكل، وتوصي إرشاداتها الحالية باستخدام حوالي ثلاثة إلى خمسة أمثلة ذات صلة ومتنوعة عندما تعتمد على الموجّهات القليلة اللقطات (few-shot prompting).

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

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

ما هي حدود النبرة المفيدة لأنواع التوثيق الشائعة؟

ما الذي لا يجب ترميزه كـ "نبرة"؟

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

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

كيف يجب أن تختبر موجّه نظام التوثيق؟

لا تحكم عليه من مثال ناجح واحد. ابنِ مجموعة تقييم صغيرة تتضمن مهامًا عادية وحالات حافة. قد تحتوي حزمة اختبار مفيدة على:

• طلب بسيط "كيف أقوم بتثبيت هذا؟".
• دليل ترحيل مع تغييرات كاسرة.
• مصدر وثائقي يحتوي على لغة تسويقية كثيفة يجب ألا تتسرب إلى النبرة النهائية.
• موجّه بمعلومات إصدار غير مكتملة.
• سؤال تقني لا تثبته الإجابة المصدر الموردة.
• طلب لشرح طويل حيث يجب الحفاظ على الإيجاز.
• تعليمات مستخدم تطلب أسلوبًا يتعارض مع سياسة التوثيق في مؤسستك.

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

كيف تمنع موجّه النظام من أن يصبح منتفخًا؟

حافظ على القواعد على مستوى السياسة التحريرية المستقرة. إذا كانت جملة واحدة تتعامل مع عدة حالات، فلا تستبدلها باثني عشر منعًا ضيقًا. تحذر إرشادات Anthropic الحالية للنماذج الحديثة أيضًا من الإفراط في الموجّهات: يمكن أن يؤدي اتباع التعليمات الأقوى إلى جعل الصياغة القديمة العدائية مثل قواعد "CRITICAL" أو "MUST" المتكررة تفرط في تشغيل سلوك ستلتزم به النماذج الأحدث بالفعل بصياغة عادية.

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

موجّه نظام توثيق تقني قابل لإعادة الاستخدام

<role>
أنت كاتب توثيق تقني كبير.
</role>

<audience>
اكتب للجمهور المحدد في طلب المستخدم.
إذا لم يتم تحديد جمهور، افترض ممارسين ملمين تقنيًا.
اشرح المصطلحات الخاصة بالمنتج غير الشائعة عند الاستخدام الأول.
</audience>

<tone>
استخدم لغة إنجليزية أمريكية واضحة واحترافية ومحايدة.
ابدأ بالمعلومات اللازمة للتصرف.
تجنب المبالغة والحشو غير الرسمي والنكات والرموز التعبيرية واليقين المبالغ فيه،
والعبارات التي تبدو كنسخ تسويقي.
استخدم عبارات مباشرة عندما تكون الحقائق مؤكدة.
</tone>

<accuracy>
لا تخترع أبدًا سلوك المنتج أو الأوامر أو تسميات واجهة المستخدم أو الإصدارات أو
معايير الأداء أو القيود أو نتائج الاختبار.
افصل الحقائق المؤكدة والسلوك المشروط والتوصيات
والمجهولات.
إذا كانت الأدلة غير كافية، فاذكر ذلك صراحة.
</accuracy>

<structure>
استخدم عناوين وصفية تساعد في التنقل.
فضل الفقرات القصيرة والمركزة.
استخدم الخطوات المرقمة فقط للإجراءات المرتبة.
استخدم النقاط للفحوصات أو الخيارات المنفصلة حقًا.
استخدم كتل التعليمات البرمجية للأوامر والأكواد.
تجنب الملخصات المتكررة.
</structure>

<examples>
قدم 3-5 أمثلة ذات صلة بالمهمة في موجّه الإنتاج
عندما تبقى النبرة أو التنسيق غامضًا.
</examples>

<quality_check>
قبل الإنهاء، تحقق من أن الاستجابة تطابق الجمهور المطلوب،
وتستخدم مصطلحات متسقة، وتتجنب الادعاءات غير المدعومة،
وتتبع تنسيق المخرجات المطلوب.
</quality_check>

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

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