مطوّر يعلّم Claude Code وCodex تعديل عمليات الأعمال في Bitrix24 عبر ملفات .bpt

تعيش عملية الأعمال في Bitrix24 أطول مما يتذكر مؤلفوها. ما زال يجب اعتماد الطلب، وتعيين المسؤول، وإرسال الإشعار. لكن المخطط يتحول عبر السنين إلى شجرة تحمل كتلها أسماء مثل «الشرط» و«الإشعار»، ولتغيير المسار لا بد من تخمين نوايا الآخرين. لقد صارت الشبكات العصبية تحلل المستودعات البرمجية منذ زمن، أما هنا فكل شيء يتم يدويًا. قرر مؤلف المشروع إصلاح ذلك فزوّد وكلاء الذكاء الاصطناعي بأدوات حقيقية.

ماذا يحصل الوكيل عليه

طلب «أصلح عملية الأعمال» لا يفيد النموذج بشيء، فهو لا يعرف كيف يخزّن Bitrix القالب. ولا تنفع لقطة الشاشة للمخطط أيضًا، إذ لا تظهر فيها خصائص الكتل ولا التعابير ولا الروابط بين الإجراءات.

لذلك يحتوي المستودع على مهارة واحدة: ملف يحدد ترتيب العمل، وأربعة مراجع (بنية القالب، التعابير، أنواع الإجراءات، البوابة)، وسكربتات Python. تقوم هذه السكربتات بفك ضغط الملف وعرض الشجرة والبحث عن العقد والتحقق من الروابط. ملف .bpt المُصدَّر هو تسلسل PHP فوق zlib، وليس XML ولا JSON. ولا يمكن استبدال الاسم الروسي مباشرة في النص، لأن طول السلسلة مسجَّل بالبايتات وسيتلف الملف. يتم التعديل عبر البنية: تحميل، ثم تغيير الخاصية، ثم إعادة التجميع.

هناك وضعان. في الوضع الملفي يعمل الوكيل على ملف التصدير، ويبقى الاستيراد إلى البوابة خطوة منفصلة، وهذا يناسب السحابة أيضًا إذا كانت البوابة تسمح بالتصدير والاستيراد. في الوضع الثاني توفر وحدة مدفوعة للنسخة المحلية (Box) بوابة: يقرأ الوكيل العملية عبر العميل bpagent.py، ويجد الفرع ويرسل التعديل. لا يُستخدم MCP هنا، ولا يوجد نموذج مدمج في الوحدة.

كيف يبدو العمل

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

وعمليًا عثر الوكيل على روابط URL غير صحيحة ومشكلات في الموظفين المعيّنين. ويقرّ المؤلف بأمانة بأنه لا توجد قياسات دقيقة للوقت الموفَّر، وبأنه لم ينشئ عملية من الصفر بهذه الطريقة.

أمان الكتابة

تعيد القراءة الشجرة مع تجزئة (hash) للإصدار. وتتطلب الكتابة هذه التجزئة في الترويسة If-Match وإلا يرفض الخادم. وقبل الحفظ تتحقق البوابة من الأنواع والصلاحيات والأحجام، وتشغّل المدقق وتأخذ لقطة. وتتم الكتابة عبر الدالة القياسية CBPWorkflowTemplateLoader::update()، دون SQL مباشر. ويمكن تقييد مفتاح الوصول بصلاحيات القراءة والكتابة والإنشاء والتشغيل، وبقوالب محددة. أما تعديل PHP المضمّن (CodeActivity) فيتطلب صلاحية منفصلة هي templates:write_code، لأنه شيفرة تُنفَّذ على خادم البوابة.

القيود

يتحقق المدقق من البنية فقط. فقد يكون الرابط الموجود إلى ثابت موجود صحيحًا شكليًا وخاطئًا معنويًا. والكتابة مغلقة أمام NodeWorkflowActivity. وفي الإصدار 0.3.1 لا يوجد قفل ذري إزاء الحفظ المتزامن من المحرر المرئي، لذا اتفقوا على من يعدّل العملية حاليًا. وأمر آخر: حتى عند تثبيت Bitrix على خادمكم الخاص، يغادر محتوى القوالب إلى وكيل خارجي ويخضع لشروط أداة الذكاء الاصطناعي التي تستخدمونها. والوحدة حاليًا قيد المراجعة في Marketplace التابع لـ 1C-Bitrix.

ما العمل

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