تدريب تطوير البرمجيات بالذكاء الاصطناعي
الجزء الأول – أساسيات هندسة التسخير
ستتعلم:
- لماذا لا تتسع مجالسة محرر الذكاء الاصطناعي
- هندسة التسخير: البشر يوجّهون والوكلاء ينفّذون
- تهيئة مستودع باستخدام واجهة سطر أوامر CodeFactory
- اكتشاف الحزمة ومستويات المخاطر والحدود المعمارية
- كتابة CLAUDE.md بصفتها مستوى التحكم في الوكيل
- إصدار المطالبات والحراس كشيفرة
- خطافات ما قبل الإيداع، وبوابات سياسة المخاطر، والملفات المحمية
الجزء الثاني – التطوير الآلي في GitHub Actions
ستتعلم:
- وكلاء فرز المشكلات والتخطيط والتنفيذ
- وكلاء مراجعة للقراءة فقط مع أحكام منظمة
- حلقات المعالجة والاستعادة التلقائية للملفات المحمية
- خطوط أنابيب CI ذات بوابات مخاطر بانضباط SHA
- العناية بالتوثيق ومقاييس التسخير الأسبوعية
- تشغيل الحلقة الكاملة من المشكلة ← PR ← الدمج مباشرة
- تكييف التسخيرات مع قاعدة الشيفرة الخاصة بك
اعرض خبرتكمع شهادتنا!
توقف عن مجالسة محرر الذكاء الاصطناعي
يستخدم معظم المطورين اليوم الذكاء الاصطناعي بطريقة خاطئة. يجلسون في Cursor أو Copilot Chat، يقبلون اقتراحًا، يمررون، يقبلون آخر، يتراجعون، يعيدون المحاولة، يلصقون خطأً في الدردشة، ويعتبرون اليوم مكتملًا. يبدو الأمر منتجًا، لكنه عمل يدوي مرتديًا زي الذكاء الاصطناعي. لا يزال الإنسان هو عنق الزجاجة. لا يزال الوكيل يخمّن. لا شيء قابل للتكرار، ولا شيء قابل للمراجعة، ولا شيء يتسع لأكثر من مطور واحد وفرع واحد.
يقلب هذا التدريب النموذج. سيتعلم فريقك نقل البرمجة بالذكاء الاصطناعي من المحرر إلى GitHub Actions، حيث يعمل الوكلاء في منفذي تشغيل مؤقتين، محميين بمطالبات محددة الإصدار وبوابات جودة آلية. يفتح المطور مشكلة، ويراجع طلب سحب، وينقر على الدمج. كل ما بينهما — الفرز، التخطيط، التنفيذ، مراجعة الشيفرة، المعالجة — يحدث تلقائيًا، على بنية تحتية CI قياسية.
مجموعة أدوات تسخير CodeFactory
ندرّس على أساس CodeFactory
، واجهة سطر أوامر مفتوحة المصدر تقوم بتهيئة تسخير أمان للوكيل كامل في أي مستودع موجود. أمر واحد — codefactory init — ويكتسب مستودعك 16 تسخيرًا وأكثر من 14 سير عمل من GitHub Actions مصممة لحزمتك:
- عقد مخاطر (
harness.config.json) يصنّف كل ملف ضمن Tier 1 أو 2 أو 3 ويفرض المستوى الصحيح من التدقيق - تعليمات الوكيل (
CLAUDE.md) التي تصف الاصطلاحات وقواعد التبعيات والملفات المحمية - وكيل فرز المشكلات يقيّم الوضوح وقابلية إعادة الإنتاج والنطاق قبل كتابة أي شيفرة
- مخطط للمشكلات يقرأ قاعدة الشيفرة للقراءة فقط وينشر خطة تنفيذ منظمة
- منفّذ للمشكلات ينشئ فرعًا، ويطبّق التغيير، ويشغّل التحقق الأساسي ويفتح PR
- وكيل مراجعة يعمل بأدوات للقراءة فقط ويصدر حكمًا APPROVE / REQUEST_CHANGES / COMMENT يصنّفه نموذج ثانوي خفيف
- حلقة معالجة تعيد تغذية أحكام المراجعة إلى المنفّذ لما يصل إلى ثلاث دورات إصلاح تلقائي قبل التصعيد إلى إنسان
- سير عمل العناية بالتوثيق واختبارات هيكلية واختبارات دخان التسخير ومقاييس أسبوعية تبقي التسخير نفسه سليمًا
كل شيء موجود في المستودع. لا لوحات تحكم خارجية، ولا حصر للمورّد، ولا حالة خفية. تعديل مطالبة هو طلب سحب عادي.
مثال إنتاجي حقيقي: sport-affiliate
نستعرض QualityUnit/sport-affiliate ، مستودعًا أحاديًا إنتاجيًا حقيقيًا (ثلاثة مواقع Next.js، ومحرك مشترك، وخط بيانات Python) يشغّل تسخير CodeFactory الكامل. ستقرأ ملفات سير العمل الفعلية والمطالبات وسكربتات الحماية التي تدفعه:
- 15 سير عمل GitHub Actions يُنسّقون حلقة المشكلة ← PR ← الدمج الكاملة
- أربع مطالبات مخصصة في
.codefactory/prompts/(issue-triage.md،issue-planner.md،issue-implementer.md،review-agent.md) - سكربتات حماية TypeScript (
scripts/*-guard.ts) تفحص كل تشغيل وكيل مسبقًا وتقرر ما إذا كان ينبغي أن يبدأ أصلًا - خط أنابيب CI على أربع مراحل سريع الفشل يتخطى عمليات بناء Next.js الكاملة (25 دقيقة لكل منها) لصالح فحص الأنواع + lint + اختبارات هيكلية
- انضباط SHA: كل مهمة لاحقة تسحب الـ SHA المطابق الذي أبلغت عنه بوابة المخاطر حتى لا يتمكن وكيل من إجراء دفع تنافسي في منتصف خط الأنابيب
- ملفات محمية (
.github/workflows/*،harness.config.json،CLAUDE.md، ملفات القفل، تكوينات النشر) يتم استعادتها تلقائيًا إذا لمسها وكيل - مطالبة المراجعة محمّلة من
origin/main— وليس من فرع PR — بحيث لا يمكن لطلبات السحب التي يكتبها الوكلاء العبث بمراجعها الخاص
تبدو تجربة المطور من البداية إلى النهاية كما يلي: يفتح إنسان مشكلة. يضع وكيل الفرز عليها تسميات، ويطرح أسئلة توضيحية إذا لزم الأمر، ويسلّمها إلى المخطط. ينشر المخطط خطة تنفيذ كتعليق. ينشئ المنفّذ issue-N، ويطبّق التغيير، ويشغّل بوابات الجودة ويفتح PR. يراجع وكيل المراجعة. إذا طُلبت تغييرات، يتم إرسال المنفّذ مرة أخرى في وضع إصلاح المراجعة — حتى ثلاث دورات — قبل التصعيد إلى إنسان. نقاط التلامس البشرية الوحيدة هي فتح المشكلة والموافقة على الدمج النهائي.
ما الذي سيأخذه فريقك معه
بنهاية التدريب سيتمكن مطوروك من تهيئة هذا الإعداد بالضبط في مستودعاتهم الخاصة، وكتابة وضبط مطالبات الوكلاء الخاصة بهم، وتعريف مستويات مخاطر تتناسب مع هندستهم، وقياس ما إذا كان التسخير يعمل فعلًا من خلال مقاييس Mean-Time-To-Harness وSLO. سيغادرون بتسخير يعمل على أحد مستودعاتك الحقيقية — وليس مثالًا تجريبيًا.
انضم إلى الدفعة القادمة
احجز مكانك اليوم!
المستقبل لن ينتظر — اتصل بنا الآن واحجز تدريبك في تطوير البرمجيات بالذكاء الاصطناعي لتبدأ في أتمتة سير عمل الهندسة لديك.