Часто хочется использовать автоматизацию, но текущие возможности кажутся ограниченными. Часто бывает так, что в одном скрипте есть нужный функционал, который хотелось бы использовать в контексте другого скрипта.
Похоже, это связано с тем, как сейчас устроены и работают автоматизации. Мне бы хотелось видеть разделение на триггеры и действия.
Примеры триггеров:
При создании/обновлении темы
При создании/обновлении поста
При изменении настройки сайта
При закрытии темы
При получении пользователем значка
и т. д.
Примеры действий:
Создать баннерную тему
Закрыть тему
Ответить на тему
Создать тему
Добавить тег к теме
Выполнить вызов LLM
Отправить сообщение в Slack
и т. д.
Такая структура позволила бы:
Назначать несколько действий после одного триггера (например: при создании темы → выполнить вызов LLM → добавить тег к посту → ответить на тему)
Использовать данные полезной нагрузки триггера (и последующие данные, доступные из действий — например, ответ от LLM) динамически внутри действий
В конечном счёте, я считаю, что у автоматизации большой потенциал, но каждый скрипт изолирован таким образом, что его очень сложно адаптировать под индивидуальные нужды. Сейчас каждый скрипт предполагает, что доступные действия подойдут всем.
Мне очень нравится это предложение! Оно, похоже, решает большинство (если не все) проблем, с которыми сейчас сталкиваются автоматизации.
Кроме того, оно кажется гораздо более масштабируемым для новых триггеров и действий. Представляю, как это откроет возможности для лёгкого добавления дополнительных триггеров — например, theme_created или theme_updated — без необходимости беспокоиться о том, как они будут взаимодействовать с уже существующими скриптами. Новые триггеры сразу же получат доступ ко всем существующим действиям (уведомления в Slack, личные сообщения, вызовы LLM и т. д.). То же самое касается создания дополнительных действий, таких как assign_badge, add_to_group, add_to_logs_and_screening и так далее.
О, и «Dry run» (проверка без выполнения) и «Execution logs» (журналы выполнения) тоже на высоте — такой уровень наблюдаемости за тем, как на самом деле выполняются процессы, просто спасение.
Всего пара слов: помимо триггера, фильтра и действия, возможность добавлять задержки была бы очень ценной.
(Пример: онбординг/напоминания — отправлять сообщение через неделю после вступления в сообщество, затем через два месяца; или если участник не публиковал посты и не читал контент в течение x дней после вступления — выполнять какое-то действие… Конечно, это нужно не каждому сообществу, но для активного сообщества поддержки, как наше, это было бы очень полезно!)
Хотя это всё ещё находится на концептуальной стадии, я продолжу brainstorming по этой теме
Что касается условий, я задумывался о том, насколько гибкими они могут быть. Было бы здорово реализовать что-то вроде скриншота, где пользователь имеет полный контроль над созданием критериев. Это позволит пользователям выбирать данные из trigger_context, определять способ их оценки и задавать значения, с которыми они сравниваются, а также выбирать между логикой AND / OR.
Это откроет возможности для более сложных сценариев, сохраняя при этом простоту и интуитивную понятность, например:
если {{category}} входит в {{выбранное пользователем значение}}И
если {{tag}} не равен {{выбранному пользователем значению}}
На скриншоте также показано, что делать после проверки условия, но это, вероятно, применимо только к разветвлённым пайплайнам. Для линейного пайплайна, который покрывает большинство случаев, процесс, скорее всего, просто завершится.
