كيف حوّل كاتب على Habr سبعة سيناريوهات n8n إلى منظومة أخبار ذكية مستقلة

تُظهر هذه القصة كيف يمكن لتجميعة هشّة بنظام no-code أن تتحول خلال أسابيع قليلة إلى منظومة تحريرية متكاملة. تخلّى الكاتب عن سبعة سيناريوهات متفرقة في n8n، وبنى خط معالجة واحدًا بلغة Python يجمع أخبار AI ويفلترها ويترجمها وينسّقها وينشرها بأقل قدر من التدخل اليدوي.

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

بنى النسخة الجديدة من المنظومة هذه المرة كمشروع واحد. وبحسب قوله، ساعدت أدوات AI في تسريع الانتقال: شارك Cursor في إعداد جهاز mini-PC المنزلي والبنية التحتية المحلية، وشارك Perplexity في مناقشة القرارات المعمارية، وساعد Claude Code في نقل مجموعة workflows إلى Python ونشر خدمة معبأة في حاويات (containers). وهكذا ظهر خط معالجة يتولى فيه 11 عاملًا (worker) مهمة واحدة لكل منهم.

وتبدو السلسلة الأساسية على النحو التالي: يجمع collector البيانات من RSS وواجهات API لنحو 160 مصدرًا كل 15 دقيقة، ويجلب scraper النص الكامل، ويزيل deduplicator التكرارات الدلالية، ويقيّم ai_filter مدى الصلة بالموضوع، ويترجم translator المواد إلى الروسية، ويصوغ llm_editor النصوص بالأسلوب المطلوب، ويعثر image_worker على الصور التوضيحية أو يولّدها، وينشر publisher المنشورات وفق جدول زمني. وإضافةً إلى ذلك، تعمل عمليات خلفية للبحث عن مستودعات GitHub والتعامل مع الفيديو والإشراف اليدوي.

وأولى الكاتب اهتمامًا خاصًا بالنموذج المحلي. فبدل النفقات المتواصلة على واجهات API السحابية للترجمة، نقل هذه المهمة إلى جهاز mini-PC المنزلي، حيث يعمل نموذج Qwen 3.5 عبر llama.cpp مع تحسين للعمل على Vulkan. وحقق ذلك هدفين معًا: خفّض تكلفة معالجة حجم كبير من الأخبار، وأبقى البيانات داخل البنية التحتية الخاصة.

وبحسب الأرقام الحالية، تراكم في قاعدة البيانات 7127 سجلًا، ويبلغ التدفق الوارد أسبوعيًا نحو 1000 مادة. لكن المخرجات ليست خلاصة لا نهاية لها: فبعد الفلترة وفق relevance_score والمراجعة التحريرية والتوزيع على فترات النشر، لا يُنشر سوى ثمانية منشورات يوميًا. ويرى الكاتب أن هذا النهج أثبت فاعلية أكبر من النهج السابق الذي بلغ 28 منشورًا في اليوم، حين كان الجمهور يرى ضجيجًا زائدًا ويتجاهل معظم القناة.

وثمة طبقة أخرى مهمة هي التنسيق عبر الوكلاء. فقد نُقلت قرارات النشر والإعدادات التشغيلية إلى OpenClaw، حيث يعمل منسّق إلى جانب عدة وكلاء AI آخرين: محرر، ومدير لخط المعالجة، ومدقق للمصادر، ومحلل. ويكفي أن يكتب المرء للمنسّق في Telegram أمرًا مثل طلب خفض الحد اليومي للنشر، فيتصل هو بواجهة API ويغيّر الإعدادات ويؤكد النتيجة. ونشأت حول ذلك لوحة تحكم (dashboard) متكاملة تعرض حالات العاملين ومسار كل خبر عبر المراحل وكفاءة المصادر والطوابير وجدول الفترات والمواد المنشورة. ويتيح هذا المستوى من الشفافية معرفة موضع تعثر المحتوى بسرعة، وتحديد المصادر التي ينبغي إيقافها. فعلى سبيل المثال، اتضح منذ الأسبوع الأول أن نحو 20 مصدرًا لا تقدم إشارة مفيدة، وأن معدل النجاح (pass rate) يساعد على التمييز بين المنصات الضوضائية والقيّمة فعلًا.

والخلاصة الرئيسية من هذه القصة ليست أن no-code سيئ وPython جيد، بل هي مثال على السرعة التي يتغير بها حاجز الدخول إلى أنظمة AI المعقدة. فالكاتب لا يكتب الشيفرة بنفسه، لكنه نجح في بناء منتج يعمل عبر تحديد المهام ومراجعة الحلول وإدارة البنية المعمارية. وتحوّل تركيبةٌ تجمع البرمجة بمساعدة AI والنماذج LLM المحلية والبنية التحتية المنزلية الرخيصة والتنسيق الواضح مشروعًا إخباريًا شخصيًا إلى غرفة تحرير شبه مستقلة. وبالنسبة إلى وسائل الإعلام المستقلة والقنوات المتخصصة، فهذه إشارة إلى أن القيمة لم تعد في مجرد الأتمتة، بل في جودة الانتقاء وقابلية مراقبة المنظومة والقدرة على بناء خط إنتاج مستقر من الأدوات المتاحة.