التقنية · July 21, 2026 · 8 دقائق قراءة

هندسة الأوامر لمهندسي البرمجيات: الأوامر بوصفها مراجعة كود بالمقلوب

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

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

الأوامر هي مراجعة كود بالمقلوب

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

مثال مطبّق

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

## TASK
Write an async fetchUser(id) client method in TypeScript.

## CONSTRAINTS
- Modern async/await fetch — no deprecated request libraries
- Retry on 5xx and network errors only, never on 4xx
- Exponential backoff with jitter, max 3 attempts, 5s per-attempt timeout

## TESTS IT MUST PASS
- Returns parsed JSON on 200
- Throws immediately on 404 (no retry)
- Gives up after 3 failed attempts

## OUTPUT
Code first, then one line on any assumption you made.

• جيد: يقيّد الطلب، ويسلّم النموذج اختباراته، ويقرأ المخرجات، ويلتقط الكود المهجور أو غير الآمن، ويتحقق بتشغيل سريع.
• ضعيف: يلصق 'اكتب دالة جلب مع إعادة محاولات'، ويقبل أول دالة تبدو معقولة، ويشحنها وبها خطأ 4xx كما هو.

ممارسات فضلى تُحدث فرقًا فعليًا

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

أنماط الفشل الشائعة

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

كيف نقيّمه

لا يمكنك قياس أيٍّ من هذا باختبار قصير عن صياغة الأوامر، ولا تتعلم شيئًا بمنع الذكاء الاصطناعي في المقابلة. تضع المرشّح في مهمة هندسية واقعية بالأدوات التي سيستخدمها فعلًا وتراقب كيف يوجّه ويقرأ ويصحّح — وهو تمامًا ما يفعله تقييم AI Sandbox، وكيف تُسجَّل الطلاقة في الذكاء الاصطناعي بوصفها ركيزة. اطّلع على ما يغطّيه أيضًا تقييم مهندس البرمجيات القوي، ولماذا تُعدّ هذه الطريقة الصادقة لاختبار العمل في التوظيف المتمحور حول الذكاء الاصطناعي، أو شاهد كيف يُركَّب تقييم مضبوط حسب الدور.

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