Второй Telegram-бот не должен стоить как первый
Второй похожий бот обычно делают копипастой первого, а к четвёртому одну и ту же правку приходится вносить четыре раза. Показываю, как сценарий диалога переехал в базу: новый бот заводится без разработки, а тексты и кнопки меняет администратор.
В 2025 году я делал серию Telegram-ботов для AI-генерации изображений и видео: похожие, но с разными сценариями диалога, тарифами и наборами кнопок. Второй бот в такой серии обычно делается копипастой первого, а к четвёртому у тебя четыре расползшиеся копии одной логики - и каждую правку приходится вносить четыре раза.
Вместо четырёх ботов я сделал один движок. Принцип не мой и старше меня: то, что часто меняется, должно жить в данных.
Как это делается обычно - и где ломается
Стандартный путь: сценарий диалога зашивается прямо в воркфлоу n8n или в код бота. Пользователь нажал "Старт" - ветка, выбрал стиль - ветка, оплатил - ещё ветка. Пока бот один и сценарий короткий, всё отлично.
Ломается это в двух местах. Первое - тираж: новый бот означает копию воркфлоу, и с этого момента любую правку нужно вносить во все копии. Второе - правки сценария: поменять текст шага или добавить вопрос может только тот, кто умеет редактировать воркфлоу. Каждая мелочь превращается в задачу разработчику.
Решение: конечный автомат, сценарий - в базе
Я собрал один движок на Directus и n8n. В основе конечный автомат: бот в любой момент знает, на каком этапе диалога стоит пользователь и в какие этапы его можно перевести дальше. Устроено так:
- Сценарий диалога - это данные, а не код. В базе лежат две таблицы, этапы и переходы: у этапа - текст сообщения, кнопки и действие (например, запустить генерацию картинки), у перехода - из какого этапа в какой и по какому событию. Всё это видно и правится в обычной админке.
- Состояние пользователя - тоже данные. У каждого пользователя хранится текущий этап диалога.
- n8n - универсальный исполнитель. Один набор воркфлоу на все боты: пришло сообщение - читаем текущее состояние пользователя - выполняем действие этапа - переводим по подходящему переходу - отвечаем.
Движок при этом не знает ничего про конкретного бота - ни текстов, ни кнопок. Он умеет одно: проиграть тот сценарий, который описан в базе. Поэтому вся серия ботов работает на одном исполнителе.
Что это дало
Главный результат: новый бот заводится записями в базе, без переписывания воркфлоу. Завести этапы, тексты, кнопки и переходы - и бот работает. Движок получился переиспользуемым: запуск следующего бота сводится к работе с данными.
Побочные эффекты оказались не менее ценными:
- Правки сценария перестали быть задачей разработчика. Поменять текст шага или добавить кнопку можно прямо в админке Directus.
- Стало видно, что происходит с человеком. По каждому пользователю в базе написано, на каком он этапе и как сюда попал. Жалобу "бот меня потерял" разбираем по базе, а не восстанавливаем путь по логам.
- Логика перестала расползаться. Исправление бага в исполнителе автоматически чинит все боты сразу - копий больше нет.
- Появилась воронка бесплатно. Раз состояние каждого пользователя лежит в базе, вопрос "сколько людей дошло до оплаты и где отваливаются" закрывается одним запросом к базе, без отдельного проекта по аналитике.
Границы подхода
Конечный автомат нужен не всегда. Если бот - это три линейных шага и он один, автомат избыточен: вы потратите время на движок, который не окупится. Прямолинейный воркфлоу будет дешевле.
Для свободного диалога автомата мало: когда пользователь пишет что угодно, нужна LLM. Но и здесь автомат помогает - агент со свободным диалогом хорошо живёт поверх каркаса, который держит оплату, лимиты и обязательные шаги. LLM отвечает за разговор, автомат - за то, чтобы бот не потерял пользователя и деньги.
Точка окупаемости подхода - второй похожий бот или первый сценарий, который придётся часто править. У меня оба условия сработали.
Что это даёт вам в месяц
Посчитайте на своих цифрах. Правка общей логики раз в неделю при четырёх копиях бота - это четыре задачи разработчику вместо одной. Тексты и кнопки после этого правит администратор: при ставке 40 000 - 80 000 рублей в месяц это его обычная работа, а не релиз. Если бот собирает заявки, каждый застрявший на этапе - это заявка за 3 000 - 15 000 рублей, и теперь видно, на каком именно.
Похожая задача?
У вас уже есть бот и на подходе второй, или каждая правка сценария упирается в разработчика. Опишите задачу - посчитаю, во что обойдётся движок и на каком боте он окупится.
Новые разборы - на почту
Разборы задач автоматизации: что автоматизировать, сколько это стоит и что даёт в цифрах. Одно письмо на статью, без рекламы чужих продуктов.
