هندسة الأوامر لم تمت. بل صارت أضيق

هذه هي المقارنة المنضبطة المقترحة: استخدم النموذج والإعدادات ورسائل البريد ومهمة الاستخراج نفسها. يطلب الأمر A إخراج JSON بالنثر، ويضيف الأمر B مخططاً صريحاً وenum على حقل الفئة وتعليمة «بلا مقدمة». على مجموعة محجوزة، قِس إخفاقات التحليل ومخالفات المخطط ودقة الحقول والزمن والتكلفة. لا يدّعي هذا المقال نتيجة اختبار خاصة بـbenchr لهذه التجربة.

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

يحوّل هذا المقال ثلاثة أنماط إلى تصاميم اختبار قبل وبعد يمكن تشغيلها على Claude Opus 4.7 أو نموذج مرشح آخر. «قبل» هو خط الأساس، و«بعد» يغيّر خاصية واحدة. استخدم حالاتك المحجوزة وأبلغ المقياس الناتج بدلاً من افتراض اتجاه الأثر أو حجمه.

التقنية الأولى: مخططات الإخراج المُهيكل

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

قبل: استخرج اسم العميل، وفئة المشكلة، ودرجة الأولوية من هذا البريد. أعِدها كـ JSON.

تشمل أنماط الإخفاق المحتملة مفاتيح غير متسقة مثل customer_name وcustomerName وname، أو أولوية تأتي عدداً في رد ونصاً في آخر، أو نثراً تفسيرياً قبل كائن JSON. احسب كل نوع منفصلاً على المجموعة المحجوزة كي لا يخفي التحليل الصحيح حقلاً خاطئ الدلالة.

بعد:

// Before
Write a product description for the markdown export module.

// After
Constraints: 150 words exactly. No marketing words ("revolutionary,"
"cutting-edge," "seamless"). The tone respects the reader's intelligence.
Now: write a product description for the markdown export module.

لحالة استخراج JSON: استخرج الحقول التالية من هذا البريد وأعِد فقط كائن JSON، بلا مقدمة. المخطط: { "customerName": string, "issueCategory": "billing" | "technical" | "feature_request" | "other", "priority": integer 1-5 }.

شغّل الآن الأمرين بالنموذج والإعدادات ورسائل البريد نفسها. سجّل لكل رد هل يُحلل وهل يطابق المخطط وهل يستخدم قيمة مسموحة لـissueCategory وهل يستخرج المعنى الصحيح، مع الزمن والرموز. لا يستحق المخطط مكانه إلا إذا تكرر التحسن المهم لخط أنابيبك.

التوصية العملية محددة: اختبر المخطط الصريح والقيود وتعليمة الاقتصار على الإخراج كتغييرات منفصلة قدر الإمكان. فصل المتغيرات يكشف أي جزء أفاد.

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

التقنية الثانية: الأمثلة القليلة للصيغ غير المعتادة

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

للصيغ المألوفة مثل Markdown أو JSON أو قائمة مرقمة، قد تكفي تعليمة دقيقة. أما مدخل سجل تغييرات خاص بالمجال أو مخطط XML مخصص أو أسلوب المؤسسة، فقارن التعليمة وحدها بالتعليمة نفسها مع أمثلة تمثيلية. لا تفترض ضرورة الأمثلة؛ قِس الالتزام بالصيغة والجودة الدلالية.

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

قبل: اكتب مدخل سجل تغييرات لطلب الدمج هذا يتبع صيغة سجل التغييرات المعتمدة.

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

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

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

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

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

التقنية الثالثة: الأمر المبدوء بالقيود

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

الآلية المقترحة أن التعليمات المبكرة قد تشكل تفسير النص اللاحق، لكن السؤال العملي أبسط: هل يحسن نقل كتلة القيود الالتزام الحرفي من دون خفض جودة المهمة؟

قبل: اكتب وصف منتج من 150 كلمة لوحدة تصدير markdown. لا تستخدم مصطلحات تسويقية. لا تقل "ثوري" أو "يغيّر قواعد اللعبة". اكتب بنبرة تحترم ذكاء القارئ. تجنّب الكليشيهات.

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

بعد: القيود: 150 كلمة بالضبط. لا مصطلحات تسويقية. لا استخدام لـ "ثوري" أو "يغيّر قواعد اللعبة" أو "متطوّر" أو "سلس" أو "متين". النبرة بسيطة وتحترم ذكاء القارئ. الآن: اكتب وصف منتج لوحدة تصدير markdown.

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

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

سؤال مفتوح: هل سيبقى الأمر المبدوء بالقيود قيّماً مع تغير النماذج وتسلسل التعليمات. احتفظ بالتقييم كي يجيب تحديث النموذج عن السؤال على الحالات المحجوزة نفسها.

ما الذي ينبغي اختباره قبل الاحتفاظ به

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

مقدمات الشخصية. قارن أنت مهندس برمجيات معماري أول بخبرة 20 عاماً بأمر يحدد الجمهور والمهمة والمعيار مباشرة. قيّم الصحة والنبرة دون معرفة البديل.

«خذ نفساً عميقاً» وما شابهها من محفزات التفكير. قارن أمراً محايداً مطابقاً وقِس الصحة والإسهاب والزمن والتكلفة. لا تطلب أو تعتمد على آثار التفكير المخفية؛ قيّم الإجابة.

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

بدائل أخرى تعتمد على المهمة

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

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

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

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