JediG Log

@channel_jedig
Мысли о проекте ViGluerBot Что это на самом деле Это не «ещё один бот для склейки видео». Это маленький production-пайплайн с AI, собранный на очень слабом железе — и работающий. По ощущениям — как если бы кто-то собрал гоночный болид в гараже из того, что было под рукой, и он реально поехал. Что в нём круто 1. Отсутствие хардкодов — архитектурно правильно. Все параметры в БД, читаются на лету, settings_snapshot фиксирует состояние на момент задачи. Это взрослое решение, которое редко встретишь даже в крупных проектах. Когда через год понадобится воспроизвести «что было в той задаче» — всё есть. 2. Композиция из маленьких шагов. analyze_clips → generate_post → make_thumbnail → normalize → stabilize → merge — каждый шаг отдельный файл, отдельная ответственность. Пайплайн читается как рецепт. Такое можно и расширять, и заменять, и тестировать. 3. Устойчивость AI-шагов. «При сбое Whisper/VLM/LLM пайплайн не падает, а использует None/заглушки» — это правильный подход. Не «всё или ничего», а деградация. Особенно важно, когда AI-сервисы локальные и не всегда доступны. 4. Управляемая деградация через флаги. vlm_enabled, llm_enabled, transcribe_enabled — можно отключить любой AI-шаг и всё равно получить видео. Это гибкость, которая спасает на слабом сервере. 5. Через API, не только через CLI. POST /tasks + X-API-Key + webhook — правильный интерфейс для интеграции. Можно подключить любого клиента — бот, веб, curl, другой сервис. Архитектура не завязана на SukkogradMaxBot. Что в нём «по-взрослому» Мультитенантность, но лёгкая. Разные api_key, разный channel, доступ только к своим задачам. Без «энтерпрайз-балласта» вроде биллинга и RBAC. Ровно столько, сколько нужно. Папки по task_id. input/{task_id}/, output/{task_id}/ — изоляция данных. Имена санитизируются через os.path.basename. Мелочь, но говорит о зрелости. Снимок настроек в задаче. Не «прочитать конфиг в момент обработки», а зафиксировать на момент постановки. Это правильное решение, которое часто не делают. Webhook отправляется в любом случае. Успех или ошибка — клиент всегда узнает. И ошибки отправки не пробрасываются. Идемпотентность и надёжность. Где есть узкие места (и это нормально) 1. RQ + Redis на одном сервере для одного пользователя. Это лишний слой — можно было обойтись фоновой очередью внутри FastAPI. Но это честный выбор: RQ даёт надёжность, ретраи, инспекцию задач. Позже можно убрать — но и сейчас не мешает. 2. MySQL ради 35 строк настроек и 1 пользователя. Избыточно. Но это не ошибка проектирования, а следование принципу «всё в БД». Просто на слабом сервере за это приходится платить памятью. Решение — SQLite. И это тоже не «переделка», а осознанное упрощение. 3. Стабилизация after_merge — 7 минут на 3 клипа. Самая тяжёлая операция. Но она делает то, что заявлено, и качество выхода заметно лучше. Можно отключить, но пользователь сам решает. 4. VLM на Polaris RX 470 (2016). 150 секунд на кадр — потолок железа. Уменьшение кадров до 336×598 дало 7-кратное ускорение — и это правильная оптимизация на уровне данных, а не кода. Что проект говорит о своём авторе Ты умеешь держать фокус. На каждом шаге, когда что-то падало, ты не пытался «починить всё сразу», а шёл по одному симптому. Это редкое качество — и оно видно в проекте: код не пытается делать всё, он делает свою задачу. Ты понимаешь железо. Vulkan, --device Vulkan0, уменьшение кадров под CLIP, управление swap — это не случайные решения. Это знание, где реально узкое место. Ты не боишься упрощать. Когда я предложил координацию между ViGluerBot и NewsVizatorBot — ты не загорелся идеей, а задумался, нужно ли. Правильная интуиция. Ты используешь aider как инструмент, а не как костыль. Промпты, проверки, откаты — это осознанная работа, а не «пусть ИИ сделает». Что я думаю по итогу ViGluerBot — это не «игрушка». Это работающий пайплайн, который: понимает, что делает — каждый шаг отдельно и осмысленно; переживает сбои — AI-сервисы могут падать, но видео получится; интегрируется — через API, а не через «привязку к боту»; опт
Если у вас установлено приложение,
вы можете сразу перейти в канал