Habr يصف إطار AI لـ Claude مع Clean Architecture ودورة TDD

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

كيفية بناء التدفق

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

يكتب المؤلف أنه اختبر هذه العملية عملياً على مدى 3.5 أشهر: مرّت حوالي 4000 حدث تعديل عبرها، 1500 اختبار، حوالي 350 فحص نهائي شامل، وحوالي 25000 سطر من كود الإنتاج، دون احتساب طبقة الاختبار. العنصر الأساسي للنظام هو أمر /continue. وهو ينظر إلى قائمة القصص وملف progress.md، ويحدد في أي مرحلة توقفت التنمية، ويدفع المهمة قدماً دون اختيار يدوي للإجراء التالي.

التطوير الموجه بالاختبار والبوابات

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

• المقابلات وتوسيع متطلبات القصة
• توليد خطة الاختبار وحالاته قبل بدء التنفيذ
• دورة أحمر-أخضر-إعادة هيكلة لحالات الاستخدام والمحولات واختبارات القبول
• بوابات الجودة مع فحص صرامة الاختبارات والعمارة والتغطية
• تعديل بعد كل خطوة وفترة راحة إلزامية للمراجعة من قبل الإنسان

"لن تصل بعيداً مع مجرد أوامر بسيطة."

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

نوافذ بيئة التطوير المتكاملة المتوازية

الجانب العملي لهذا النهج ليس أقل أهمية من العمارة نفسها. قد يستغرق تشغيل واحد من /continue من 5 إلى 20 دقيقة، وفي الاختبارات الثقيلة—حتى 40 دقيقة أو حتى ساعة. لتجنب الانتظار في خيط واحد، يقترح المؤلف استنساخ مستودع العرض التوضيحي عدة مرات أو استخدام أشجار العمل وتشغيل قصص مختلفة بالتوازي في بيئات تطوير متكاملة منفصلة. في عمليته الخاصة، يتم فتح ما يصل إلى ستة نوافذ في وقت واحد، حيث تكون أربع أو خمس مشغولة بعمل الوكيل، بينما تُستخدم الباقية للمراجعة وإعادة الهيكلة والديون التقنية. للحالات غير القياسية، هناك أوامر إضافية جنباً إلى جنب مع التدفق الرئيسي. نشر المؤلف مستودعين للدخول: عرض توضيحي لـ كانبان على جافا + ريأكت وقالب إطار عمل فارغ.

/task مطلوب لتصحيح الأخطاء والبنية التحتية والمهام الطويلة التي لا تندرج تحت قصة بطقس تطوير موجه بالاختبار كامل. /prompt-update خاص لتحسين الإطار ذاته إذا تعثر النموذج على مشكلة متكررة مرة أخرى. ومع ذلك، يعترف المؤلف مباشرة بالقيود: نمت الحل من مكدس ويب معين، وهو مصمم خصيصاً للعمارة النظيفة والقبول والاختبار، ويستهلك العديد من الرموز، ولا يجعل التطوير مستقلاً تماماً. إذا لم يتم اكتشاف خطأ في المراجعة، فسوف يذهب بهدوء إلى الإنتاج.

ماذا يعني هذا

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