أسئلة مقابلة هندسة الهارنس: 22 سؤالًا مع إجابات لمهندس الذكاء الاصطناعي

كيف تستعد

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

الأساسيات

1. ما هو هارنس الوكيل؟

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

2. ما الفرق بين هندسة الهارنس وهندسة الأوامر وهندسة السياق؟

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

3. اذكر الأنظمة الفرعية الخمسة للهارنس.

التعليمات (AGENTS.md وCLAUDE.md وskills والوثائق)، والأدوات (shell والاختبارات والمدقق والمتصفح وMCP)، والبيئة (التبعيات وبيئة التشغيل وDocker وworktree)، والحالة (PROGRESS.md وقائمة الميزات والقرارات)، والتغذية الراجعة (make check وE2E والخطافات والمُقيِّم). وغياب أي نظام فرعي لا يؤدي إلى «أداء أسوأ قليلًا»، بل إلى فئة منهجية من الإخفاقات.

4. لماذا لا يحل استبدال النموذج بنموذج أقوى المشكلة غالبًا؟

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

التشخيص

5. خرق الوكيل قاعدة مكتوبة في CLAUDE.md. ماذا تفعل؟

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

6. كيف تعرف من العَرَض أي نظام فرعي معطّل؟

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

7. من أي نظام فرعي تبدأ ببناء الهارنس، ولماذا؟

من التغذية الراجعة. فما لم يوجد أمر يجيب آليًا عن سؤال «هل يعمل؟»، لا يمكن قياس أثر أي تغيير آخر. ثم عادةً تأتي التعليمات والحالة والبيئة والأدوات، لكن الترتيب تجريبي ويعتمد على الجزء الأكثر تعطلًا.

8. كيف تقيس مساهمة مكوّن معين في الهارنس؟

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

التعليمات والسياق

9. كيف يُبنى AGENTS.md جيد؟

كموجّه (router) لا كتاب مدرسي: ما هو المشروع، وكيف يُشغَّل، وكيف يُتحقَّق منه، وتعريف الإنجاز، وقائمة قصيرة من القيود الإلزامية. والتفاصيل في وثائق منفصلة تُربط بشروط مثل «اقرأ هذا عندما تتعلق المهمة بالدفع». ويجب أن يحدد الملف ثوابت («البيانات تُتحقَّق منها عند الحدود») لا أن يملي التنفيذ والمكتبات سطرًا بسطر.

10. ما فائدة الوكلاء الفرعيين؟

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

11. ما هو دَين الهارنس (harness debt)؟

هو الفجوة المتراكمة بين الهارنس والواقع: قواعد قديمة، وأوامر لم تعد تعمل، ووثائق تصف وحدات لم تعد موجودة. يشبه الدين التقني، يتراكم بصمت، ويُسدَّد بإخفاقات الوكيل. ويحتاج الهارنس إلى مراجعة دورية، لا إلى إعداد لمرة واحدة.

الحالة والجلسات

12. كيف تتعامل مع «فقدان الذاكرة» بين الجلسات؟

بحفظ الحالة في المستودع: PROGRESS.md (الحالة الراهنة، والمنجَز، والعوائق، والخطوات التالية)، وDECISIONS.md (القرار والسبب والخيارات المرفوضة)، وقائمة الميزات بحالاتها، وكثرة الـ commits. وتُحدَّد في التعليمات بداية الجلسة: قراءة ملف التقدم، ثم تشغيل سكربت فحص البيئة، ثم اختيار الميزة النشطة.

13. ما الغرض من قاعدة WIP=1؟

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

14. ما هو اختبار البدء البارد (cold start)؟

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

التحقق

15. لماذا لا تثبت اختبارات الوحدة الخضراء أن الميزة تعمل؟

لأن اختبار الوحدة يعزل الوحدة ويحاكي الاعتماديات، فلا يرى نقاط الالتقاء: عدم تطابق الواجهات، وانتشار الحالة (المخطط تغيّر والذاكرة المؤقتة قديمة)، وتسرب الموارد، ومشكلات الإعدادات والبيئة. والعيوب التي تلتقطها اختبارات الوحدة هي مجموعة جزئية من تلك التي تلتقطها اختبارات التكامل، وهذه بدورها مجموعة جزئية من تلك التي تلتقطها E2E.

16. ما هي فجوة التحقق (verification gap) وكيف تحسبها؟

هي نسبة المهام التي أعلن فيها الوكيل الاكتمال دون أن يؤكده تحقق مستقل. خذ 10 مهام متتالية، وسجّل عن كل واحدة الحقيقتين. يوفر هذا المقياس خط أساس: بعد تحسين الهارنس، تُعاد حسابه على مجموعة مهام مشابهة.

17. كيف تكتب تعريف الإنجاز (Definition of Done) للوكيل؟

في AGENTS.md، كقائمة بنود قابلة للتحقق: أوامر التحقق تنتهي برمز 0، وتوجد اختبارات E2E تغطي السيناريو، والترحيلات تُطبَّق، والتقدم محدَّث. ومن المفيد أيضًا ذكر ما لا يُعد إنجازًا صراحةً، مثل «يبدو صحيحًا»، أو «اختبارات الوحدة تنجح»، أو «يعمل عندي محليًا».

18. لماذا لا يُسمح للوكيل بوضع علامة «اكتمل» بنفسه؟

لأن النماذج تميل إلى المبالغة في تقييم عملها، ولأن التقييم الذاتي يتم في السياق نفسه الذي اتُّخذ فيه القرار. يجب أن يضع سكربت التحقق حالة «passing» بناءً على نتائج التشغيل، ويسجل هاش الـ commit كدليل.

19. كيف تُعد مُقيِّمًا مستقلًا؟

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

20. كيف تجعل قاعدة معمارية قابلة للتنفيذ؟

على ثلاثة مستويات: حارس grep (سريع، بالبحث عن نمط)، وقاعدة مدقق تفهم رسم الاستيراد (import-linter وdependency-cruiser)، واختبار معماري في CI. وتُدرج جميعها في make check، وتفشل برمز خروج غير صفري، وتطبع WHY وFIX ليصلح الوكيل المخالفة بنفسه. ومحفّز إضافة فحص جديد عادةً أن يتكرر التعليق نفسه في المراجعة للمرة الثانية.

العمل المستقل

21. ما الذي تحتاجه لترك الوكيل يعمل ساعات؟

هدف واضح، ومؤشر تقدم أحادي الاتجاه (مثل عدد الميزات في حالة passing)، وميزانية زمن ومحاولات لكل ميزة، وتراجع تلقائي عند أي تراجع، وقائمة بما يحتاج إلى إنسان: الترحيلات، والبنية التحتية، والأموال. وأيضًا العزل: صندوق رمل أو git worktree مستقل، حتى لا يؤثر الخطأ في بيئة العمل الفعلية.

22. متى لا تكفي حلقة وكيل واحدة، وكيف تصمم مخطط الأدوار؟

عندما يبدأ المنفِّذ بمراجعة نفسه ويتعثر. عندها تُقسَّم المهمة إلى أدوار: التنفيذ، والمراجعة، والاختبار، والدمج. تتلقى المراجعة سياقًا نظيفًا ومعايير، ويُدمَج الكود عندما تكون المراجعة pass. وعند فشل المراجعة تعود الميزة إلى التنفيذ، وبعد عدة إخفاقات تُعاد من البداية بسياق نظيف، وغالبًا ما يعني ذلك أن المشكلة في فهم المهمة وليس في الشيفرة.

الخلاصة

أقوى ما يُقنع في مقابلة هندسة الهارنس هو الإجابات القابلة للتحقق: أي ملفات، وأي أوامر، وأي مؤشر. احتفظ في ذهنك بالأنظمة الفرعية الخمسة، وفجوة التحقق، ومبدأ «الإنجاز يحكم به السكربت». وتجتمع كل هذه الموضوعات في دورة هندسة الهارنس ضمن هارنس واحد متكامل على مشروع حقيقي.