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

النموذج نفسه، البريد نفسه، مهمة الاستخراج نفسها. الأمر الأول: استخرج اسم العميل، وفئة المشكلة، ودرجة الأولوية من هذا البريد. أعِدها كـ JSON. الأمر الثاني: الطلب نفسه مع مخطط JSON صريح، وenum على حقل الفئة، وتعليمة "بلا مقدمة". عبر أكثر من ألف نداء، أنتج الأمر الأول إخفاقات تحليل في نحو 12% من الردود. وأنتج الثاني إخفاقات تحليل في 0.3%. لم يتغيّر شيء في النموذج بين التشغيلين، فقط الأمر.

امتُصّ معظم صندوق أدوات أوامر حقبة 2023 في النماذج الحدّية، ومعظم ما فعله المهندسون المدرَّبون قبل عامين يحدث تلقائياً الآن. ما زالت مجموعة صغيرة من التقنيات تُحدث فرقاً في 2026، بما في ذلك كل ما تغطيه نظرة Anthropic العامة لهندسة الأوامر ودليل OpenAI المكافئ لهندسة الأوامر. تلك المجموعة أضيق مما كانت، لكنها لا تزال تستحق مكانها.

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

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

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

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

ينجح ذلك في معظم الأحيان. نمط الإخفاق أن مفاتيح JSON غير متسقة عبر النداءات. أحياناً customer_name، وأحياناً customerName، وأحياناً مجرد name. وتنحرف صيغة درجة الأولوية. أحياناً عدد صحيح، وأحياناً نص، وأحياناً مغلّفة بنثر تفسيري قبل أن يبدأ كائن JSON أصلاً. عبر 1,000 نداء، تبلغ إخفاقات التحليل لاحقاً نحو 12%.

بعد:

// 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 }.

النموذج نفسه، البريد نفسه، تهبط إخفاقات التحليل إلى نحو 0.3%. وحده enum على issueCategory يقلّص الانحراف كثيراً. يلتزم النموذج بإحدى القيم الأربع المسموحة بدلاً من اختراع خامسة. وتعليمة بلا مقدمة تقتل فقرات التقديم الثرثارة التي كانت تغلّف نصف الردود.

الدرس محدد: اكتب المخطط، والقيود، وما لا ينبغي للنموذج إخراجه. لا شيء من هذا جديد، وما زال يعمل.

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

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

كانت الأمثلة القليلة (few-shot) التقنية الرائجة في 2023. والسردية منذ ذلك الحين أن النماذج لم تعد تحتاج أمثلة. يصمد ذلك للصيغ الشائعة. وللصيغ غير المعتادة ينهار.

إن كانت الصيغة شيئاً رآه النموذج مليون مرة (Markdown، JSON، قائمة مرقّمة، بريد مُهيكل)، فلا حاجة لأمثلة. النموذج يعرفها أصلاً. أما الصيغ الخاصة بالمجال فقصة أخرى: نوع معيّن من مدخلات سجل التغييرات، أو مخطط XML مخصص، أو أسلوب كتابة بإيقاعه الخاص. هناك، الأمثلة لا تزال جوهرية، وإخراج النموذج بدونها أسوأ بكثير.

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

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

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

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

النموذج نفسه، و95%+ من المخرجات صالحة للاستخدام كما هي. تبلغ بادئة الأمثلة القليلة نحو 200 رمز، تكلّف لا شيء تقريباً، وتحمل معرفة الصيغة التي يفتقر إليها النموذج فطرياً. في جلسات العمل هذه هي التقنية التي يُلجأ إليها أكثر من غيرها.

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

الافتراض المعقول مع دخول 2026 أن هندسة الأوامر امتُصّت بالكامل في الإعدادات الافتراضية للنماذج. تقنية مخطط الإخراج المُهيكل تدفع ضد ذلك الافتراض. يُبلَّغ عن الارتفاع من JSON Schema بقيود enum بمقدار 30-40× على معدل إخفاق التحليل، حتى على Claude Opus 4.7 (النموذج نفسه الموثّق في توثيق Claude API من Anthropic). إنها تقنية قديمة تسجّل رقماً حقيقياً.

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

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

السبب الذي يجعلها تهم: ينتج النموذج الرموز من اليسار لليمين، فما يظهر باكراً في الأمر يُعلِم ما يأتي بعده. القيود المدفونة في النهاية تصل بعد أن يكون النموذج قد كوّن معظم فهمه للمهمة. ضعها أولاً فتشكّل ذلك الفهم من البداية.

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

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

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

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

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

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

ما الذي عَفا عليه الزمن

ثلاث تقنيات اختفت فعلاً في 2026. توقّف عن استخدامها.

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

"خذ نفساً عميقاً" وما شابهها من محفّزات سلسلة التفكير. تفكّر النماذج خطوة بخطوة الآن دون أن يُطلب منها. ينتج الأمر المجرّد نتائج مكافئة في الاختبار.

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

الفئة التي أصبحت اختيارية جزئياً

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

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

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

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