طلب ميزة - تقسيم الأتمتة إلى مشغلات وإجراءات

أهلاً!

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

يبدو أن هذا يتعلق إلى حد كبير بالطريقة التي تعمل بها الأتمتة حاليًا ويتم إعدادها. أود أن أرى الأشياء مقسمة إلى مشغلات وإجراءات.

  • مشغلات مثال:
  • عند إنشاء/تحديث موضوع
  • عند إنشاء/تحديث منشور
  • عند تغيير إعدادات الموقع
  • عند إغلاق موضوع
  • عند حصول مستخدم على شارة
  • إلخ.
  • إجراءات مثال:
  • إنشاء موضوع لافتة
  • إغلاق موضوع
  • الرد على موضوع
  • إنشاء موضوع
  • وضع علامة على موضوع
  • تشغيل استدعاء LLM
  • إرسال رسالة Slack
  • إلخ.

هذا الإعداد سيسمح ببعض الأشياء:

  • تعيين إجراءات متعددة بعد مشغل (على سبيل المثال، عند إنشاء موضوع > تشغيل استدعاء LLM > وضع علامة على المنشور > الرد على الموضوع)
  • السماح ببيانات حمولة المشغل (والبيانات اللاحقة المتاحة من الإجراءات - على سبيل المثال، استجابة استدعاء LLM) لاستخدامها ديناميكيًا ضمن الإجراءات

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

5 إعجابات

لقد بدأت في استكشاف هذه الفكرة مع مساعدي الشخصي جارفيس:

ما رأيك؟ لديه حتى عرض توضيحي تفاعلي.

أجد سلسلة المشغل ← المرشح ← الإجراء ← الإجراء هذه جذابة للغاية. إنها تجعل الأتمتة أكثر مرونة ووضوحًا.

4 إعجابات

أعجبني هذا الاقتراح كثيراً! يبدو أنه يحل معظم (إن لم يكن كل) نقاط الألم التي تعاني منها الأتمتة حاليًا.

كما أنه يبدو أكثر قابلية للتوسع للمشغلات (Triggers) والإجراءات (Actions) الجديدة. أتخيل أن هذا سيفتح الباب لإضافة مشغلات إضافية بسهولة - مثل theme_created أو theme_updated - دون الحاجة للقلق بشأن كيفية تفاعلها مع البرامج النصية الموجودة مسبقًا. ستحصل المشغلات الجديدة على إمكانية الوصول الفوري إلى كل إجراء موجود (إشعارات Slack، الرسائل الخاصة، استدعاءات LLM، إلخ). وينطبق الشيء نفسه على إنشاء إجراءات إضافية مثل assign_badge أو add_to_group أو add_to_logs_and_screening وما إلى ذلك.

أوه، و"التشغيل التجريبي" (Dry run) و"سجلات التنفيذ" (Execution logs) دقيقة أيضًا - إن الحصول على هذا المستوى من الرؤية لكيفية عمل الأشياء فعليًا هو منقذ للحياة تمامًا.

3 إعجابات

أدخل بسرعة: بالإضافة إلى المشغل/المرشح/الإجراء، سيكون من الثمين أن نتمكن من إضافة تأخيرات.

(مثال: الإعداد/التنبيهات، إرسال رسالة بعد أسبوع من الانضمام إلى المجتمع، ثم بعد شهرين، أو إذا لم ينشر العضو أو يقرأ إلخ عددًا معينًا من الأيام بعد الانضمام، افعل شيئًا ما… بالتأكيد ليس شيئًا سيستخدمه أي مجتمع، ولكن بالنسبة لمجتمع الدعم النشط مثل مجتمعنا، سيكون كذلك!)

إعجابَين (2)

بينما لا يزال هذا في المرحلة المفاهيمية، سأستمر في العصف الذهني بشأنه :smiley:

فيما يتعلق بالشروط، كنت أتساءل عن مقدار المرونة التي يمكن بناؤها بالفعل. سيكون من الرائع تطبيق شيء مثل لقطة الشاشة، حيث يتمتع المستخدم بالتحكم الكامل في كيفية إنشاء المعايير. السماح للمستخدمين بتحديد البيانات من trigger_context، وتحديد كيفية تقييمها، وتعيين ما يتم تقييمها مقابله - مع السماح لهم أيضًا بالاختيار بين منطق AND / OR.

سيؤدي ذلك إلى فتح سيناريوهات أكثر تعقيدًا، مع الحفاظ على سهولة الفهم والبديهية مثل:

  • if {{category}} is one of {{user selected value}} AND
  • if {{tag}} is not {{user selected value}}

تتضمن لقطة الشاشة أيضًا ما يجب فعله بعد التحقق من الشرط، ولكن هذا من المحتمل أن ينطبق فقط على خطوط الأنابيب المتفرعة - بالنسبة لخط أنابيب خطي، والذي يغطي معظم الحالات، فمن المحتمل أن ينتهي ببساطة

إعجابَين (2)