Community

سير العمل: النصف المفقود من أتمتة المباني المدعومة بالذكاء الاصطناعي

المساعد الذي يتقن صياغة Axon تمامًا سيظل يبني لك قاعدة Spark معطوبة. لا لأنه عاجز عن كتابة الشيفرة — بل لأن أحدًا لم يخبره بالإجراء. ثلاثة وعشرون ملف markdown تعالج ذلك، وهي بحاجة إليك.

Alper Üzmezler· Sep 19, 2026 · 11 دقيقة قراءة

هذا إخفاق لا علاقة له بالذكاء إطلاقًا.

اطلب من مساعد ذكاء اصطناعي جيّد التأسيس إنشاء قاعدة Spark في SkySpark. إنه يعرف Axon. ولديه مكتبة الدوال مفهرسة. يكتب لك شيفرة نظيفة وصحيحة نحويًا — ثم يسلّمك سجلًا واحدًا.

قاعدة Spark العاملة تحتاج اثنين: سجل func يحمل منطق الاكتشاف، وسجل sparkRule يضبط كيف وأين تنطبق القاعدة. ويجب أن يتوافق أحدهما مع الآخر. أغفِل الثاني ولن يظهر أي خطأ — ستكون لديك ببساطة قاعدة لا تُطلَق أبدًا، في موقع كنت تظن أنه مراقَب.

لا قدر من معرفة الصياغة يمنع ذلك. إنها ليست مشكلة لغة. إنها مشكلة إجراء، والإجراء هو النصف الذي ظللنا نتركه خارج الحساب.

ما هو سير العمل فعليًا

سير العمل هو ملف markdown. هذه هي الحيلة كلها.

يحمل قليلًا من الـ frontmatter كي يمكن فهرسته، ثم نصًا عاديًا وجداول تصف كيفية إنجاز شيء واحد على نحو صحيح:

---
title: Create Spark Rule
description: Step-by-step guide for creating a Spark rule with func and sparkRule records
category: fault-detection
tags: [spark, rule, fault, automation]
version: 1.0
---

يحمّل كلا خادمي MCP كل ملف .md في مجلد workflows/ عند الإقلاع، ويعرضهما عبر بروتوكول سياق النموذج (Model Context Protocol) كموارد قابلة للقراءة تحت معرّف workflow://. ولا حاجة لإخبار المساعد بوجودها — إذ يستطيع سردها والبحث فيها وسحب النص الكامل عند الطلب، في منتصف المهمة.

خادم Fantom MCP يراقب ذلك المجلد. أسقِط فيه ملفًا جديدًا، فيصبح متاحًا دون إعادة بناء ودون إعادة تشغيل.

يصل سؤال — فيبحث المساعد عن الإجراء أولًا listWorkflows اكتشاف منخفض الكلفة المعرّف · العنوان · الوسوم searchWorkflows كلمات مفتاحية + دلالي درجة الملاءمة workflow:// قراءة النص الكامل مورد MCP عمل موجَّه كلا السجلّين، بالترتيب الصحيح سير العمل هو ملف markdown. إضافة واحد إلى workflows/ تجعله حيًّا — إذ يراقب Fantom MCP المجلد، فلا إعادة بناء ولا إعادة تشغيل. عتبة المساهمة هي: "هل تستطيع تدوين كيف تفعلها؟".

الفهرسان اليوم

خادم Fantom MCP — 13 سير عمل، تغطي جانب البناء والصيانة:

ai-coding-loop · api-migration-reference · connector-workflow · create-pod · create-skyspark-extension · explore-code-relations · haxall-basics · haxall-coding-standards · haxall-methods-workflow · skyspark-4x-migration · unit-testing · use-fanr · xeto-spec-guide

خادم Axon MCP — 10 سير عمل، تغطي جانب التحليلات والعمليات:

app-creation · axon-func-update · axon-lang-information · curRule-computed-points · html-email-skyspark · job-status-check · recform-template-design · spark-rule-creation · task-subscriber-permissions · visualytik-mcp-authoring

ثلاثة وعشرون ملفًا. هذه هي كامل الذاكرة الإجرائية المرمَّزة لسلسلة الأدوات هذه في الوقت الحالي — وهي أبعد ما تكون عن الكفاية.

كيف يبدو السير الجيد

المثال الرائد هو ai-coding-loop، الذي يعلّم المساعد كيف يغيّر الشيفرة دون أن يترك الفهرس يتعفّن من تحته. تمتد الذاكرة البنيوية للخادم عبر أكثر من 240 مشروعًا وأكثر من 156 ألف دالة؛ وأي تعديل لا يُعاد فهرسته يجعل كل بحث لاحق خاطئًا على نحو خفيّ.

1 · التوجّه askCodebase · getCallers 2 · التغيير أنت تحرّر — الخادم لا يكتب أبدًا 3 · إعادة الفهرسة reindexChangedFiles(paths) 4 · التحقق إعادة بحث · فحص الأثر أكثر من 240 مشروعًا أكثر من 156 ألف دالة

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

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

يحمل ذلك الملف أيضًا سطرًا يستحق الاقتباس: "تم التحقق منه حيًّا في 2026-06-10 مقابل sedonaWebEditor." سير عمل يحمل تاريخ تحقق هو سير عمل يمكنك الوثوق به أو إحالته إلى التقاعد. أما الذي بلا تاريخ فهو مجرد إشاعة.

لماذا يمثّل هذا عنق الزجاجة

الميل الغريزي هو افتراض أن النماذج الأفضل ستسدّ هذه الفجوة. لكنها لا تفعل، ويستحق الأمر أن نكون دقيقين في السبب.

ضعف النموذج في هذا المجال ليس في الاستدلال، ولم يعد في الصياغة إلى حد كبير — فالفهارس المؤسَّسة تتكفل بالصياغة. الضعف هو أن المعرفة الإجرائية في أتمتة المباني لم تُدوَّن قط في صورة يستطيع أي شيء تنفيذها. إنها تعيش في رؤوس بضعة آلاف من الممارسين حول العالم، وتنتقل بالتلمذة المهنية: تتعلم أن قاعدة Spark تحتاج سجلّين لأن مهندسًا أقدم رآك تُطلِق واحدة لم تعمل.

آلية النقل تلك لا تتوسّع، ولا تصمد أمام انتقال الناس بين الوظائف. كل مُكامِل يعيد اشتقاق الإجراءات نفسها بمفرده. وتضيع الظهيرة ذاتها، بالتوازي، في عشرات الشركات.

سير العمل هو تلك اللحظة من التلمذة، مكتوبة مرة واحدة، ومنفَّذة من كل مساعد في كل مشروع من بعدها.

لماذا يجب أن يكون المجتمع هو الفاعل

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

من يملكون هذه المعرفة لا يكتبون خوادم في معظمهم. المهندس الذي يعرف الترتيب الصحيح لتشغيل وحدة سطحية، أو أي نمط curRule يصمد فعليًا على النقاط المحسوبة، هو شخص تحكّم — لا مطوّر TypeScript. ولو كانت المساهمة تتطلب طلب سحب على محرك فهرسة، لبقيت معرفته حيث هي.

لكنها لا تتطلب ذلك. سير العمل هو ملف markdown. frontmatter، وعنوان، والخطوات بالترتيب، والمطبّات. إن كنت تستطيع تدوين كيف تفعلها، فأنت تستطيع المساهمة بواحد.

ممارِس يكتب كيف يفعلها فعليًا — ملف ‎.md مُراجَع · ذو إصدار مُختبَر على مشروع حقيقي، ومؤرَّخ كل مساعد في كل مشروع، من ذلك الحين فصاعدًا يُكتب مرة واحدة يُفحص مرة واحدة

الاقتصاديات في صالحنا بشكل مبالغ فيه. كتابة سير عمل تستغرق ظهيرة واحدة. ثم يوفّر ظهيرة على كل مهندس كان سيعيد اشتقاقه — عبر كل شركة، وإلى ما لا نهاية. قليلة هي المواضع في البرمجيات التي تكون فيها الرافعة بهذا الميل الشديد.

والمجال أصغر من أن يتحمّل التشظّي. أتمتة المباني ليست تطوير ويب؛ لا يوجد جيش من المساهمين في الطريق. وإن ظل من يعرفون Sedona وHaxall وAxon وXeto يحتفظون بإجراءاتهم لأنفسهم، فسيظل الجميع يدفعون الرسوم الدراسية ذاتها. ثلاثة وعشرون ملفًا هي ما تمكّنت حفنة منا من إنجازه. مئتا ملف، مراجَعة ومؤرَّخة، ستغيّر ما يستطيع القادم الجديد فعله في أسبوعه الأول.

المخاطر بصراحة

فهرس سير العمل ليس جيدًا تلقائيًا، والتظاهر بغير ذلك سيهيّئ هذا المشروع للفشل.

سير عمل خاطئ أسوأ من غياب سير العمل. يتّبعه المساعد بثقة فينتج نتيجة خاطئة بثقة. غياب الإجراء يُنتج ترددًا على الأقل؛ أما الإجراء السيئ فيُنتج تشغيلًا سيئًا. المراجعة هنا أهم منها في معظم التوثيق.

سير العمل يتقادم بصمت. غيّر SkySpark 4.0 صيغة الامتدادات وأبطل إجراءات حقيقية بين ليلة وضحاها. وسير العمل لا يلاحظ أنه شاخ. ومن هنا جاء version: في الـ frontmatter، والأفضل: تاريخ تحقق صريح، والمشروع الذي جرى فحصه عليه آخر مرة.

انضباط النطاق. سير عمل يحاول شرح كل شيء لا يعلّم شيئًا. الجيد منها يؤدي مهمة واحدة — أنشئ هذا الشيء، رحّل ذاك الشيء، أبقِ الفهرس محدَّثًا.

لا شيء من هذا يناقض المقاربة. بل يدعو إلى جعل المراجعة والتأريخ وإعادة التحقق جزءًا منها من البداية، لا إضافة مُلصَقة عند الملف المئتين.

تعال وابنِ الفهرس معنا

كلا الخادمين متاحان المصدر، ومجلدات سير العمل هي أسهل نقطة انطلاق ممكنة:

  • FantomMcpServer — workflows/، 13 ملفًا، البناء والصيانة
  • AxonMcpServer — workflows/، 10 ملفات، التحليلات والعمليات

الفجوات ليست خفية. لا يوجد سير عمل لاصطلاحات تسمية نقاط BACnet، ولا لتشغيل تتابع محطة مبرّدات، ولا لنصف دزينة من قرارات وسم Haystack التي يعيد كل مشروع التقاضي بشأنها.

إن كنت تعرف أحد تلك الإجراءات — تعرفه حقًا، بما في ذلك أين يخطئ — فذاك سير عمل، ولم يدوّنه أحد حتى الآن.

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


المزيد عن كيفية عمل هذه الخوادم: خادم Axon MCP · ذكاء الشيفرة عبر اللغات · أسطول Sidecar وRLM.