مشروع احترافي
OstimGPT
روبوت محادثة قائم على Retrieval-Augmented Generation ومستضاف محليًا، يجيب عن الأسئلة من مصادر الجامعة.
مشروع احترافي
Student Application Management System
SAMS منصة رقمية لطلبات التقديم الطلابية تدعم ملفات المتقدمين ومسارات المراجعة الداخلية وإدارة حالة الطلب والتقارير وتهيئة اللغة المدعومة بنماذج ذكاء اصطناعي مستضافة محليًا. وضمن فريق التطوير بنيت واجهات الملف الشخصي، ولوحة ملاحظات داخلية للمراجعين، ومزامنة بين حقول النموذج والطلبات المقدَّمة، ونقطة API لحالة الطلب، ولوحة تقارير قابلة للتهيئة.
الانتقال إلى قسم
نظرة عامة
Student Application Management System منصة رقمية لمعالجة طلبات التقديم الطلابية من طرف إلى طرف: يبني المتقدم ملفًا شخصيًا ويقدّم طلبه، ويراجع الموظفون تلك الطلبات ويسجّلون ملاحظات داخلية وينقلونها بين الحالات ويصدرون تقارير عن النتيجة.
ساهمت في هذه المنصة ضمن فريق التطوير في الجامعة. وتركّز عملي على الواجهات التي يستخدمها المتقدمون والمراجعون فعليًا، وعلى إبقاء البيانات المقدَّمة متسقة مع النماذج التي أنتجتها، وعلى واجهات الحالة والتقارير المبنية فوق ذلك.
السياق
طلبات التقديم الطلابية عملية إدارية متكررة وكبيرة الحجم، ولها جمهوران متمايزان: المتقدمون الذين يستخدمون النظام مرة أو مرتين ويحتاجونه واضحًا بذاته، والمراجعون الداخليون الذين يستخدمونه باستمرار ويحتاجونه فعّالًا.
والمنصة التي تخدم الجمهورين ينبغي أن تُصمَّم لهما معًا. وقد وقع كثير من عملي على جانب المراجِع، حيث يتكرر العناء الصغير مئات المرات.
المشكلة
عملية تقديم تُدار عبر نماذج وجداول ورسائل بريد غير مترابطة تفقد سياقها. فلا يرى المراجعون سبب اتخاذ قرار ما، ولا يرى المتقدمون أين وصل طلبهم، ويصبح إصدار التقارير إعادة بناء للصورة يدويًا.
- أن يحصل المتقدمون والمراجعون الداخليون على واجهات مختلفة فوق الطلب نفسه.
- أن يعيش سياق المراجِع — الملاحظات وحالة المراجعة — مع الطلب لا خارجه.
- أن تبقى البيانات المقدَّمة متسقة مع حقول النموذج التي أنتجتها، حتى مع تغيّر النماذج.
- أن تكون حالة الطلب متاحة برمجيًا لبقية أجزاء النظام.
- أن تكون التقارير قابلة للتهيئة لا مجموعة ثابتة من الشاشات المعرَّفة مسبقًا.
دوري في المشروع
دوري في المشروع
طوّرت واجهة صفحة الملف الشخصي وصفحة ملف المتقدم، وبنيت لوحة ملاحظات داخلية للمراجعين. نفّذت مزامنة تلقائية بين حقول النموذج والطلبات المقدَّمة، ووسّعت نماذج البيانات بحقول متعلقة بالمراجعة. طوّرت نقطة API لحالة الطلب، وأنشأت لوحة تقارير قابلة للتهيئة. كما ساعدت في نقل تهيئة اللغة في المنصة إلى خدمة منفصلة مدعومة بنماذج مستضافة محليًا.
سياق الفريق
سياق الفريق
هذه منصة جامعية يبنيها ويصونها فريق تطوير البرمجيات في مكتب تنسيق التحول الرقمي. كنت مساهمًا في ذلك الفريق لا مالكًا للمنصة. والميزات الموصوفة هنا هي التي طوّرتها شخصيًا؛ أما المنصة ككل — بنيتها ووحداتها الأخرى وتشغيلها — فعمل مشترك للفريق، طُوّر في دورات Sprint بمراجعة شيفرة تعاونية.
المسؤوليات
واجهات المتقدم والمراجِع
- تطوير واجهة صفحة الملف الشخصي.
- تطوير صفحة ملف المتقدم.
- بناء لوحة ملاحظات داخلية للمراجعين.
اتساق البيانات والنماذج
- تنفيذ مزامنة تلقائية بين حقول النموذج والطلبات المقدَّمة.
- توسيع نماذج الطلبات بحقول متعلقة بالمراجعة.
واجهات API والتقارير
- تطوير نقطة API لحالة الطلب.
- إنشاء لوحة تقارير قابلة للتهيئة.
التهيئة المدعومة بالذكاء الاصطناعي
- المساعدة في نقل تهيئة اللغة إلى خدمة منفصلة تستخدم نماذج مستضافة محليًا.
المنهج التقني
تبع العمل دورة حياة الطلب نفسها: منح المتقدم ملفًا متماسكًا، ومنح المراجِع السياق اللازم للقرار، وإبقاء البيانات الأساسية متسقة مع تغيير الطرفين لها، ثم إتاحة الحالة والتقارير فوق هذا الأساس.
- بناء صفحة الملف الشخصي وصفحة ملف المتقدم بحيث يُعرض الطلب سجلًا واحدًا متماسكًا لا مجموعة إجابات على نموذج.
- إضافة لوحة ملاحظات داخلية ليُسجَّل تعليل المراجِع على الطلب نفسه بدل البريد الإلكتروني.
- توسيع نماذج الطلبات بحقول متعلقة بالمراجعة، ليكون لحالة المراجعة موضع لائق في نموذج البيانات.
- مزامنة حقول النموذج والطلبات تلقائيًا، حتى لا يؤدي تغيير النموذج إلى فقدان التزامن مع البيانات التي يجمعها دون إشعار.
- إتاحة نقطة API لحالة الطلب لتقرأ بقية أجزاء النظام الحالة دون النفاذ إلى داخليات المنصة.
- بناء لوحة تقارير قابلة للتهيئة ليصوغ الموظفون التقرير بأنفسهم بدل طلب تقرير جديد.
- نقل تهيئة اللغة إلى خدمة منفصلة مدعومة بنماذج مستضافة محليًا.
البنية التقنية
ينشئ المتقدم ملفًا شخصيًا ويقدّم طلبه. ويُخزَّن الطلب في نماذج تحمل بيانات الطلب وحقول المراجعة معًا، وتبقى متوافقة مع تعريف النموذج عبر مزامنة تلقائية. ويعمل المراجعون من خلال صفحة ملف المتقدم ولوحة الملاحظات الداخلية. وتُتاح حالة الطلب عبر نقطة API، وتقرأ لوحة تقارير قابلة للتهيئة عبر الطلبات. أما تهيئة اللغة فتتولاها خدمة منفصلة مدعومة بنماذج مستضافة محليًا.
- المتقدم: ينشئ ملفًا شخصيًا ويقدّم طلبه عبر واجهة الملف.
- المزامنة: تبقى حقول النموذج وسجلات الطلبات متوافقة تلقائيًا.
- التخزين: تُحفظ الطلبات في نماذج موسَّعة بحقول متعلقة بالمراجعة.
- المراجعة: يفتح الموظفون صفحة ملف المتقدم ويسجّلون تعليلهم في لوحة الملاحظات الداخلية.
- الحالة: تُتاح حالة الطلب عبر نقطة API مخصّصة لبقية المستهلكين.
- التقارير: تقرأ لوحة قابلة للتهيئة عبر الطلبات لإنتاج التقارير.
- اللغة: تقدّم التهيئةَ خدمةٌ منفصلة مدعومة بنماذج مستضافة محليًا.
الميزات
صفحة ملف المتقدم
الطلب معروضًا سجلًا واحدًا متماسكًا لا مجموعة إجابات على نموذج.
لوحة الملاحظات الداخلية
تعليل المراجِع مسجَّل على الطلب نفسه، حيث سيجده المراجِع التالي.
مزامنة النموذج والطلبات
تبقى حقول النموذج والبيانات المقدَّمة متوافقة تلقائيًا مع تغيّر النماذج.
نموذج بيانات واعٍ بالمراجعة
نماذج طلبات موسَّعة بحقول متعلقة بالمراجعة، تمنح حالة المراجعة موضعًا حقيقيًا.
واجهة API لحالة الطلب
نقطة طرفية مخصّصة تتيح لبقية أجزاء النظام قراءة الحالة مباشرة.
لوحة تقارير قابلة للتهيئة
يصوغ الموظفون التقرير الذي يحتاجونه بدل طلب شاشة ثابتة جديدة.
التحديات
تتغير النماذج مع الوقت، والبيانات المقدَّمة وفق تعريف نموذج أقدم تنحرف عن التعريف الحالي.
نفّذت مزامنة تلقائية بين حقول النموذج والطلبات، فأصبح النظام هو من يصون هذه العلاقة لا من يتذكّر تحديثها.
لم يكن لحالة المراجعة — الملاحظات والقرارات والسياق — موضع منظّم تعيش فيه، ما يدفعها إلى البريد والقنوات الجانبية حيث تكفّ عن كونها جزءًا من السجل.
وسّعت نماذج الطلبات بحقول متعلقة بالمراجعة وبنيت فوقها لوحة الملاحظات الداخلية، فصار سياق المراجِع مخزَّنًا مع الطلب الذي يخصّه.
التقارير الثابتة تُنشئ طابورًا: كل سؤال جديد يصبح طلب تطوير.
بنيت لوحة التقارير قابلة للتهيئة، فصار بوسع الموظفين الإجابة عن أسئلة جديدة دون انتظار تغيير في الشيفرة.
القرارات والمفاضلات
| القرار | البديل المطروح | المبرر |
|---|---|---|
| توسيع نماذج الطلبات القائمة بحقول متعلقة بالمراجعة. | الاحتفاظ بحالة المراجعة في مخزن منفصل بجوار الطلبات. | إبقاء حالة المراجعة مع الطلب يعني أن سجلًا واحدًا يروي القصة كاملة ولا يمكن أن يفقد تزامنه. صحيح أن ذلك يوسّع نموذج الطلب، وهو الثمن المقبول. |
| جعل التقارير قابلة للتهيئة بدل شحن تقارير ثابتة. | مجموعة من شاشات التقارير المعرَّفة مسبقًا. | التقارير القابلة للتهيئة عمل أكبر في البداية لكنها تزيل اعتمادًا متكررًا على المطورين مع كل سؤال جديد. التقارير الثابتة أسرع في البناء وأبطأ في التعايش معها. |
| نقل تهيئة اللغة إلى خدمة منفصلة مدعومة بنماذج مستضافة محليًا. | إبقاء تهيئة اللغة داخل التطبيق الرئيسي. | يُبقي الفصلُ السلوكَ المدعوم بالنماذج خارج نواة التطبيق ويتيح تغييره باستقلال. وهو يضيف حدًا خدميًا يجب تشغيله، وتلك كانت المقايضة المقبولة. |
النتيجة
صار للمتقدمين عرض قائم على الملف الشخصي لطلبهم، وللمراجعين صفحة ملف متقدم مع لوحة ملاحظات داخلية تُبقي تعليلهم مرتبطًا بسجل الطلب.
وتبقى البيانات المقدَّمة متوافقة مع النماذج التي أنتجتها عبر المزامنة التلقائية، ولحالة المراجعة موضع محدد في نموذج الطلب.
وحالة الطلب متاحة عبر نقطة API مخصّصة، ويستطيع الموظفون صياغة تقاريرهم بأنفسهم عبر لوحة التقارير القابلة للتهيئة.
الدروس المستفادة
- الواجهات التي تُستخدم يوميًا والواجهات التي تُستخدم مرة واحدة تستحقان عناية تصميمية مختلفة. فعناء المراجِع يتراكم على نحو لا يتراكم به عناء المتقدم.
- موضع الحالة هو ما يحدد بقاءها. ومنح ملاحظات المراجعة موضعًا حقيقيًا في نموذج البيانات هو ما يمنعها من الانتهاء في البريد.
- المزامنة بين تعريف النموذج والبيانات التي يجمعها ميزة صحّة لا ميزة راحة — والفشل فيها صامت، وهذا ما يجعله أسوأ.
- قابلية التهيئة تستحق ثمنها حين يكون البديل طابورًا دائمًا من طلبات التقارير.
- العمل داخل قاعدة شيفرة لفريق قائم يعني قراءة شيفرة أكثر بكثير مما تكتب، ومراجعة الشيفرة هي حيث يحدث معظم التعلّم.
حزمة التقنيات
Backend
الواجهة الأمامية
الذكاء الاصطناعي والاسترجاع
الممارسات
لقطات الشاشة
ستُضاف لقطات الشاشة لاحقًا
لنتحدث عن مشروعك
هل لديك مشروع برمجي أو ذكاء اصطناعي أو RAG أو تطبيق ويب؟ لنتحدث عمّا تحتاجه ونحدد المنهج التقني المناسب.