С появлением нейросетей реализовывать идеи в разработке стало гораздо проще. Идеи практически любого масштаба, надо сказать. Хочу рассказать о довольно крупномасштабной.
Дисклеймер: этот пост — про вайб-кодинг, поэтому в нём не будет приведено ни единой строки кода. Я просто показываю идею, не детали реализации.
История у идеи довольно долгая, и началось всё с… психотерапии. Да, вот так неожиданно: в рамках починки ментального состояния понадобилось мне вести дневник эмоций. После пары дней записывания в блокнот было решено, что не положено мне, разработчику всего и вся, не попытаться перенести это в цифровой вид — а поскольку формат существующих сервисов меня не устроил, я закатал рукава и вспомнил всё, что знаю о Kotlin.
Первая версия честно писалась вручную, без всякого использования нейросетей, да и могли они тогда существенно меньше. Выглядела она непритязательно, выполняла базовый минимум функций и хранила все данные в локальных файлах на устройстве, поскольку и денег, и сил на отдельный бэкенд было жаль; и около двух лет это решение работало и устраивало, пока не начало катастрофически тормозить из-за обилия ежедневных записей.
Назрела явная необходимость всё же выделить работу с данными в отдельный бэкенд. Знаний в мобильной разработке с тех пор не прибавилось, а вот нейросети сильно выросли в возможностях, появились и возмужали агентные среды разработки, и вот в один прекрасный вечер (на самом деле, несколько вечеров, конечно) была собрана новая версия — с наконец-то более-менее приятным дизайном (на который ушло больше всего токенов), а также с бэкендом. Поскольку ведение дневника происходит по вечерам, а я не большой любитель ночевать вне дома, сервер был поднят локально на рабочем ноутбуке, выпущен смотреть в локальную сеть, и стало совсем красиво.
Однако, на волне успеха с вайбкодингом руки чесались сделать что-то ещё этакое. Да и сервер на ноутбуке несколько ограничивал — всё же рабочий ПК это не сервер.
Спустя несколько минут вздохов о том, что вот бы было у меня железо, на котором можно домашний сервер поднять, и не забивать им рабочий компьютер, я внезапно осознал, что железо-то есть! Не совсем форматное, но есть. И железом оказался старый телефон с разбитым экраном. Несмотря на солидный возраст, он всё же был флагманом в свои бородатые года, и аппаратная начинка там до сих пор вполне способна крутить даже довольно сложные и нагруженные штуки. А разбитый экран — экран серверу, собственно, ни к чему.
Таким образом, изначальная конфигурация плана «воскрешение» сложилась. Решил даже вложиться: прикупил USB-хаб для подключения в локальную сеть по Ethernet — выбор остановился на TP-Link UH6120C. Добрался рутировать аппарат, поставил самый свежий ROM (умельцы не забросили разработку и доступен даже Android 14) и настроил контроль перезаряда — взрывов из-за вздувшейся батареи нам не нужно, и прожить без замены батареи хотелось бы подольше. Подключил хаб, пересобрал ядро с драйверами под его чип, и телефон встроился в локалку как влитой.
Но останавливаться на достигнутом было уже поздно — глаза у меня загорелись. Теперь в наличии есть устройство с процессором, оперативной памятью, микрофоном и динамиком, постоянно находящееся во включённом состоянии на одном и том же месте в доме; что это напоминает?
Правильно, умная колонка. С бюджетом в 3.5 тысячи на хаб, без которого в теории несложно было обойтись, и несколько вечеров времени на вайбкодинг собственно ИИ-ассистента и всего сопутствующего.
Структура вышла такая: центральный HTTP-сервер на Go, который обеспечивает интерфейс между всеми проектами, Android-приложение ассистента, Vosk для распознавания речи и SileroTTS для её синтеза. С последним пришлось повозиться, поскольку официально Android не поддерживается, но вместе с нейросетью и это было побеждено. Задержки ввода-вывода минимальные, измеряются миллисекундами, на сервер к API LLM ходит дольше.
Ну и, конечно, изначальный проект, с которого всё начиналось — сервер локальной апишки для «домашних» приложений, количество коих тоже разрослось пропорционально свободному времени.
Следующим этапом намереваюсь поднять там же OpenClaw либо самописный аналог и, вероятно, какой-то RAG для дома.
Мораль истории заключается в следующем: вайбкодинг — это не плохо. Даже каноничный вариант сгенерировал-запустил-получил ошибку-вставил ошибку в агента-перезапустил генерацию, от которого все плюются: небезопасно! Плохая архитектура! Невозможно поддерживать!
Да, да и да. И поэтому в продакшен я ничего из-под пера ИИ не потащу без пристального ревью никогда. Но есть сферы, где всё это не имеет значения, и сервисы для личного пользования — отличный пример. Этот код никогда не будет читать никто, кроме меня, у этих сервисов никогда не будет больше одного пользователя, и ничего из этого не будет доступно извне из интернета. И всем требованиям, которые предъявляются к этому коду, вполне соответствует тот, без сомнения, ужас, что мне понагенерировала нейросеть. Всему своё место, и на мой взгляд, место вайбкодинга — в подобных проектах.
Изначально запись была опубликована мной же в личном блоге — там не очень активно, но возможно, ещё будут апдейты по проекту.
Комментарии (20)
ArtyomOchkin
24.04.2026 13:27Спасибо за идею, но вот кода не хватает. Можете, пожалуйста, поподробнее, вы написали локального ИИ ассистента а-ля умная колонка с помощью другого ИИ? И если да, то можно или про архитектуру решения чуть подробнее, или просто в спойлере основной промпт показать, что в основе лежит? Спасибо.
1024rk Автор
24.04.2026 13:27Да, весь код полностью - вайбкодинг (использовал модель GLM-5), изначально был простенький промпт-формулировка идеи "хочу голосового ассистента на отдельном постоянно включённом телефоне", дальше уточняли технологический стек и детали архитектуры - выбирал из предложенных самой нейросетью
Полное описание архитектуры, которое было отправлено на вход кодинг-модели:
Спецификация системы: три бэкенда для Xperia XZ1
Общая архитектура
Система состоит из трёх независимых компонентов, работающих на одном устройстве (Xperia XZ1) и взаимодействующих через HTTP API:
Основной бэкенд умного дома (Central Hub) — ядро системы. Отвечает за: · Управление умными устройствами (свет, розетки, датчики и так далее). · Хранение состояния и истории. · Предоставление API для модулей и внешних клиентов. · Логику автоматизации (правила, сценарии). · Обработку текстовых команд (от голосового ассистента или других интерфейсов).
Модуль голосового ассистента (Voice Module) — обеспечивает голосовой интерфейс: · Постоянное прослушивание микрофона, детекция ключевой фразы. · Распознавание речи (Vosk) и синтез речи (TTS). · Отправка распознанного текста в основной бэкенд. · Озвучивание ответов. · Управление аудиоресурсами через аудиоарбитр.
Модуль RKHomeHub — существующий (или новый) локальный сервер для Android‑приложений: · Предоставляет API для мобильных приложений (чтение/запись локальных данных). · Работает независимо от основного бэкенда, но может интегрироваться через основной бэкенд (опционально).
Дополнительный компонент: Аудиоарбитр — встроен в Voice Module или вынесен отдельно, управляет доступом к микрофону и динамику, реализует приоритетную очередь для разных источников (Voice Module, будущие модули OpenClaw, нотифаер и тому подобное).
Основной бэкенд умного дома (Central Hub)
2.1. Назначение
Центральный сервер, который управляет всей умной домашней инфраструктурой: устройствами, автоматизациями, сценариями. Взаимодействует с модулями и внешними клиентами (мобильные приложения, веб‑интерфейс).
2.2. Функциональные требования
Управление устройствами:
· Регистрация устройств (ID, тип, имя, метаданные, состояние). · Обновление состояния устройства (вручную или через датчики). · Выполнение команд над устройствами (включить/выключить, установить значение, запустить сценарий). · Поддержка разных типов устройств: свет, розетки, термостаты, датчики (температура, влажность, движение, дверь/окно), камеры, медиа‑плееры.
Автоматизация и сценарии:
· Создание правил «если‑то» (триггеры: время, состояние устройства, событие; действия: команды устройствам, уведомления, вызов вебхуков). · Периодические задачи (cron‑подобные). · Хранение и выполнение сценариев (последовательности действий).
Голосовой интерфейс (через Voice Module):
· Приём текстовых команд (POST /api/voice/command). · Распознавание намерений (intent parsing) для преобразования естественного языка в команды устройствам. · Поддержка контекстных диалогов (сессий) — опционально. · Ответ в виде текста для озвучивания.
API для модулей и внешних клиентов:
· REST API (JSON) для всех операций. · WebSocket для реального времени (уведомления об изменениях состояний). · Аутентификация (API‑ключи или JWT) для безопасности.
Хранение данных:
· SQLite (или другая встраиваемая БД) для устройств, правил, истории событий. · Конфигурация в YAML/JSON.
Логирование и мониторинг:
· Запись всех команд, событий, ошибок. · Ротация логов (размер, время).
2.3. Примеры API (для спецификации)
Метод Эндпоинт Описание POST /api/devices/register Регистрация нового устройства GET /api/devices Список всех устройств GET /api/devices/{id} Состояние устройства POST /api/devices/{id}/command Отправить команду устройству POST /api/rules Создать правило автоматизации POST /api/voice/command Отправить текстовую команду (от ассистента) GET /api/status Статус бэкенда
2.4. Требования к производительности
· Низкое потребление RAM (< 200 МБ в простое). · Быстрый отклик на команды (< 500 мс). · Работа 24/7 без перезагрузок.
Модуль голосового ассистента (Voice Module)
3.1. Назначение
Обеспечивает голосовое управление умным домом через микрофон и динамик телефона.
3.2. Функциональные требования
Аудиозахват и детекция ключевой фразы:
· Постоянное прослушивание микрофона. · Обнаружение ключевой фразы (например, «Окей сервер» или «Слушай») без отправки звука в сеть. · После активации — захват последующей речи до паузы (таймаут тишины) или явной команды окончания.
Распознавание речи (STT):
· Локальное распознавание через Vosk (русский язык, компактная модель). · Возврат текста для отправки в основной бэкенд.
Синтез речи (TTS):
· Преобразование текстового ответа от бэкенда в речь. · Использование системного TTS Android (через termux‑tts‑speak или нативное API). · Возможность настройки голоса, скорости, громкости.
Интеграция с основным бэкендом:
· Отправка распознанного текста по HTTP в Central Hub. · Получение ответа (текст для озвучивания или команда «ничего не говорить»). · Озвучивание ответа.
Аудиоарбитр (встроенный):
· Управление доступом к микрофону и динамику. · Приоритетная очередь (приоритеты: 1 — системные модули, 2 — голосовой ассистент, 3 — уведомления). · Поддержка будущих модулей (OpenClaw, нотифаер и др.), которые могут запрашивать аудио через API арбитра. · При конфликте — сохранение контекста прерванного диалога (если нужно).
Управление состоянием:
· Запуск и остановка по требованию (может работать постоянно). · Возможность временно отключать микрофон (например, по API).
3.3. API модуля (для внешних модулей)
Модуль предоставляет HTTP API (например, порт 8082) для других модулей:
Метод Эндпоинт Описание POST /audio/request Запрос на захват аудио (с указанием приоритета, режима) POST /audio/release Освобождение аудиоресурсов POST /tts/speak Воспроизвести текст через динамик (однонаправленное уведомление)
3.4. Конфигурация
· Ключевая фраза (настраивается). · Путь к модели Vosk. · URL основного бэкенда. · Параметры TTS. · Порт для API арбитра.
Модуль RKHomeHub
4.1. Назначение
Локальный сервер для обслуживания нескольких Android‑приложений на других устройствах (например, приложение для управления умным домом, дашборд). Хранит данные, специфичные для этих приложений, и предоставляет к ним API.
4.2. Функциональные требования
Локальное хранилище данных:
· Регистрация клиентов (Android‑приложений) с уникальными ID. · Хранение произвольных JSON‑данных для каждого клиента (ключ‑значение). · Поддержка синхронизации данных между клиентами (опционально). · Автоматическая очистка устаревших данных.
API для Android‑приложений:
· CRUD операции над данными (чтение, запись, удаление, обновление). · Поддержка подписок на изменения (WebSocket или long polling). · Аутентификация по токену (простому, без сложной безопасности, так как локальная сеть).
Независимость от основного бэкенда:
· Может работать без Central Hub. · При наличии Central Hub — может интегрироваться через него (например, публиковать свои данные как устройства умного дома).
Минимальное потребление ресурсов:
· RAM < 50 МБ. · Хранение данных в SQLite или плоских файлах.
4.3. Пример API
Метод Эндпоинт Описание POST /api/client/register Регистрация нового клиента GET /api/data/{client_id}/{key} Получить значение POST /api/data/{client_id} Сохранить/обновить значение DELETE /api/data/{client_id}/{key} Удалить ключ GET /api/status Статус
Взаимодействие между компонентами
flowchart TD subgraph Xperia XZ1 A[Central Hub<br>умный дом] B[Voice Module] C[RKHomeHub] D[Будущие модули<br>OpenClaw, Notifier] end subgraph Внешние устройства E[Android-приложения] F[Пользовательский голос] end F -->|голос| B B -->|текст команды| A A -->|текст ответа| B B -->|озвучка| F A <-->|опционально| C E <-->|API| C D <-->|аудио запросы| B D <-->|команды/статус| AПравила взаимодействия:
· Voice Module отправляет текстовые команды в Central Hub (POST /api/voice/command). · Central Hub обрабатывает команды, управляет устройствами, возвращает ответ. · Voice Module озвучивает ответ. · RKHomeHub работает независимо, его клиенты — Android‑приложения. · Будущие модули (OpenClaw, нотифаер) регистрируются в Central Hub и могут запрашивать аудио через Voice Module (через API арбитра).
Общие требования к реализации
Платформа:
· Xperia XZ1 (Android 8+, ARM64, 4 ГБ RAM). · Root (Magisk), ACC для контроля заряда. · Termux с поддержкой termux‑api, termux‑tts‑speak, termux‑microphone‑record. · Автозапуск всех трёх бэкендов при загрузке (через Termux:Boot).
Языки и технологии (на усмотрение агента):
· Central Hub: предпочтительно Go (высокая производительность, малый размер). · Voice Module: Python (быстрая разработка, готовые биндинги Vosk) или Go (с обёртками). · RKHomeHub: Go (лёгкий, простой).
Коммуникация:
· HTTP/JSON между компонентами (локальный порт, например 8080 для Central Hub, 8081 для Voice Module API, 8082 для RKHomeHub). · WebSocket для событий реального времени (опционально).
Конфигурация:
· Единый конфигурационный файл (YAML) для всех компонентов, либо отдельные файлы. · Параметры: IP‑адреса, порты, пути к моделям, URL внешних API.
Логирование:
· Каждый компонент пишет логи в отдельный файл в /sdcard/logs/. · Ротация: размер 10 МБ, хранить 5 файлов.
Документация для агента:
· Инструкция по сборке (если требуется компиляция). · Инструкция по развёртыванию на телефоне. · Примеры API‑запросов.
Критерии успешной реализации
Central Hub запускается и отвечает на API‑запросы. Можно зарегистрировать тестовое устройство, отправить команду, получить ответ.
Voice Module активируется по ключевой фразе, распознаёт тестовую команду («включи свет»), отправляет в Central Hub, получает ответ и озвучивает его.
Аудиоарбитр корректно обрабатывает конфликтные запросы (например, одновременный запрос от Voice Module и симулированного модуля с более высоким приоритетом).
RKHomeHub позволяет Android‑приложению (симулированному) сохранить и прочитать данные.
Все три компонента работают одновременно без взаимных блокировок и утечек памяти в течение 24 часов.
Управление через ADB/SSH возможно (логи, рестарт).
Дальнейшее расширение (не требуется сейчас, но для спецификации)
· Добавление веб‑интерфейса для управления умным домом. · Поддержка MQTT для интеграции с внешними платформами. · Графический интерфейс на телефоне (через нативное приложение) — но из‑за разбитого экрана не актуально. · Локальный LLM (например, через llama.cpp) для обработки команд без интернета.
Итог для агента: Агент должен создать три независимых проекта (каждый в своей директории) с полным исходным кодом, конфигурациями, скриптами развёртывания и инструкцией. Основной бэкенд (Central Hub) и RKHomeHub — на Go, Voice Module — на Python или Go. Взаимодействие через локальный HTTP. Всё должно работать на Xperia XZ1 под управлением Termux.
JDJ
я не понял зачем телефону USB hub для подключения к сети, у него нет wifI? Подскажите по опыту VOSK, нормально распознаёт речь? RU модель у меня работает только если чётко выговаривать прямо в микрофон. а разговорную речь не очень распознаёт у меня.
1024rk Автор
Wifi есть, но по Ethernet и быстрее и удобнее, это с запасом на дальнейшие эксперименты
Vosk полная модель работает без нареканий с разговорной речью, а для того чтобы не приходилось говорить прямо в микрофон пришлось подкрутить софтверное усиление микрофона
JDJ
полная модель, ясно, я меня просто мобильная на ~40мб.