رحلة مهمة في a2

على طاولة العمل — 10

تبدأ المهمة غالباً بجملة قصيرة: «رتّب هذه البيانات».

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

أريد أن أفكر في رحلة مهمة داخل a2 من خلال تقسيم هذه القرارات إلى أجزاء صغيرة يمكن تتبعها.

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

من الطلب إلى قاعدة واضحة

لكل سجل في المدخل النموذجي رمز واسم وحقل لن يُستخدم:

{
  "code": "A1",
  "name": "  First item  ",
  "ignored": "discard"
}

التحويل المطلوب صغير: يصبح code هو id، ويصبح name هو label. تُزال الفراغات من بداية الاسم ونهايته. ولا تُدرج الحقول الأخرى في المخرج.

لكن القاعدة لا تنتهي هنا. الحفاظ على كل السجلات وعدم إنتاج سجلات مشكلات في هذا المثال جزء من العقد أيضاً.

تضيّق هذه التفاصيل المساحة التي تتركها كلمة «رتّب» مفتوحة. تحدد التغييرات المسموح بها وتلك التي ينبغي ألا تحدث.

أول جزء مهم هو هذا العقد، قبل البيانات نفسها.

إدخال البيانات

قد تُرفض المهمة قبل أن تصل إلى النموذج.

في مسار البيانات في a2، يجب أن تكون للمدخل المحلي البنية المتوقعة. لا تُقبل مفاتيح JSON المكررة أو القيم العددية غير الصالحة. وحجم المدخل محدود أيضاً.

لا تحل هذه الفحوص معنى المهمة. إنها تجيب عن سؤال أبسط: هل نملك بيانات نستطيع قراءتها من دون التباس؟

مثلاً، قد يؤدي قبول اسم حقل مكتوب مرتين في الكائن نفسه بصمت إلى إبهام القيمة المعتمدة، قبل أن يبدأ التحويل أصلاً.

لذلك يُعد قبول المدخل خطوة في العمل أيضاً. وجود الملف لا يعني أنه جاهز للمعالجة.

بأي مسار سننجز العمل؟

لا تسلك كل مهمة في a2 المسار نفسه.

إذا كانت هناك مهارة سبق التحقق منها ويتطابق عقدها تماماً مع هذا التحويل، تستطيع data apply تشغيلها مباشرة. لا يُستدعى النموذج في هذا المسار.

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

إنتاج حل بواسطة نموذج وتعلّم مهارة جديدة مساران منفصلان.

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

حتى إن تشابهت الملفات الناتجة، تختلف أسس هذه المسارات وتكاليفها.

مواجهة المخرج

التحويل المتوقع للسجل الأول في المثال هو:

{
  "id": "A1",
  "label": "First item"
}

يُحوّل السجل الثاني بالقواعد نفسها. ويحمل المخرج الكامل حقل rows للسجلات المحولة وحقل issues للمشكلات.

هنا فحصان منفصلان.

الأول: هل للمخرج البنية المتوقعة؟ والثاني: هل يطابق نتيجة متوقعة أُعدت بصورة مستقلة؟

في ملفات أمثلة a2، تُحفظ الإجابة المتوقعة منفصلة. لا يتلقى النموذج الذي يحل المهمة الإجابة المرجعية. ويُجرى التحقق خارجياً على النتيجة المنتجة.

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

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

وصل مهمة بأخرى

قد نريد مطابقة السجلات المحولة مع ملف آخر لاحقاً.

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

يشغّل مسار data pipeline في a2 خططاً متتابعة يعدّها المستدعي. ويمكن نقل حقل rows أو issues من الخطوة السابقة إلى مدخلات محددة. ولا يحدث تحويل ضمني للحقول أثناء هذا الربط.

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

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

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

السجل الذي يبقى في النهاية

لا أرى أن بقاء البيانات المحولة وحدها في النهاية كافٍ.

أي مهارة استُخدمت؟ أي فحص أُجري؟ هل اكتمل التشغيل، أم أنتج نتيجة غير صالحة، أم توقف عند حد؟

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

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

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

الرحلة التي أريد تتبعها في a2 هي: يتحول الطلب إلى قاعدة، ويُختار مسار تنفيذ مناسب، ويُفحص المخرج، ويبقى سجل مقروء.

كي نستطيع، عندما تأتي المهمة التالية، العودة إلى الملف السابق وطرح السؤال:

ما الذي حققناه هنا بالضبط، وتحت أي شروط يمكننا الوثوق به مجدداً؟

---

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

صفحة مشروع a2 · المقال السابق: متى ينبغي أن يتوقف الوكيل؟