Как я делаю своего голосового AI-ассистента: роботы пишут код и работают, когда я отдыхаю

В этой статье я открою капот своей системы, которая по голосовухе в телеграме сразу делает новые фичи на живых проектах. С появлением LLM я безоговорочно верил в то, что голос станет следующим важным интерфейсом — и вот наконец технологии всех частей достаточно созрели, чтобы собрать своего персонального AI-ассистента, который и код из бара напишет и в пробке за рулем кофеек на маркетплейсе закажет.

Поговорим про целеполагание, архитектуру, ASR, TTS, таск-трекинг, ai-агентов, написание кода ллмками, авто-комиты и пошагово пройдемся по моему end-to-end пайплайну, который себя блестяще показал и выглядит как что-то из фильмов про будущее, которое уже наступило.

Если сходу хочется понять, про что речь, то быстро и кратко вот так:

TL;DR

• Вход: голосовуха/текст в TG

• Таск-трекер: хранит все как «единицу смысла» + логи/статусы/артефакты

• ASR: GigaAM на CPU, OGG → WAV

• Refine: Gemini Flash 2.5 чистит транскриб в техтекст

• Executor (тулинг-сервер): запуск Claude Code/Codex/OpenRouter/Playwright/другие тулы

• GitHub: если проект под гитом, то делает автокоммиты в ветку autobot/YYYY-MM-DD

• Результат: упаковка итогов LLM в аудио/текст

• Выход: короткий емкий ответ или голосовуха в ответ (SileroTTS)

И живое демо всегда лучше слов (собрал максимально простой e2e пример, чтобы выжать максимум из доступных проклятых 8мб gif здесь):

Но сначала немного вступления — это важно для понимания.

Зачем

В мире разработки есть огромное количество задач, которые совершенно не выглядят как рокетсаенс. Добавить валидацию на формочку, переложить один jsonчик в другой, накидать драфт презы, ну и вот это вот все. Таких задач много как во всех беклогах мира, так и в головах всех живущих интересную жизнь людей.

Иногда такие задачи небольшие, а иногда они объемные — понятные, несложные, но их много и всеми надо заниматься — их надо описать, декомпозировать, распределить, проверить, ну и так далее, а времени на них решительно нет.

А как бы хорошо все это наговорить куда-то, чтобы на выходе вжух и все само?

Почему голос это новый важный UI

Голос — это очень мощный способ передачи информации, главный плюс которого — самое низкое энергопотребление и одновременно самая высокая плотность запаковки информации. Писать — сложнА, гораздо проще выдернуть кого-то на звонок и вывалить ему весь поток сознания и считать дело сделанным. Люди от того горят, а ллмка — нет.

Это — ключевое.

Я люблю консоль (она же cli, она же терминал) большой любовью. Консоль и консольный способ мышления — это лучший способ дела делать и проекты. Мы уже прекрасно видим, как хорошо ллмки пишут код, как хорошо работают с многошаговостью, но когда вышли именно полноценные cli-интерфейсы с мощными моделями за ними — Claude Code, Codex и другие — я понял, что время магии настало.

Когда твоя «консолька» в состоянии не просто сама нагрепать нужную функцию, ее использование, а понять смысл и переписать под поставленную задачу — нужно было только сделать доступ до такой возможности 24/7. Чтобы можно было обращаться к ней на прогулке, в баре, в лесу возле костра, да где угодно.

Я про бар написал не случайно. У меня есть ai-агентик по описанию данных в БД, который и табличку с данными опишет, и персуху в них поищет. Рассказываю после работы о нем коллеге и дальше вопрос:

— А MS SQL поддерживаете?

— У нас только Postgre… погоди-ка…

…….

— Да, у нас есть 🤙

Конечно, с одной голосовухи оно ожидаемо не завелось, но примерно 70% работы тогда было сделано голосом с телефона — и это очень круто.

Архитектура проекта

Когда я говорю «голос как важный интерфейс» я НЕ хочу делать его единственным интерфейсом. Я хочу его с��возным. Интерфейс должен быть максимально сквозным, что подразумевает безотрывность от производства вне зависимости ни от чего. Я хочу начать на одном устройстве и продолжить на ходу на другом, потом вернуться, переключиться на большой экран, чтобы на нем разобрать подходящие под него задачи и продолжить работать с высоким КПД.

Поэтому нужен свой таск-трекер, который будет хранилищем и логосборщиком всего процесса, а в качестве входной точки — то, чем мы и так пользуемся на всех устройствах — это телеграм. И да, там еще удобно кидать боту голосовухи и это станет главной фичей.

Пока не очень понятно, но лучше всего начать с флоу того, как едет байтик смысла по системе: я кидаю в бота голосовуху, она летит в таск-трекер, там транскрибируется, подчищается ллмкой (расскажу дал��ше зачем) и создает единицу смысла — задачу. Дальше задачу надо где-то выполнить, забрать результат обратно, подправить и кинуть в ответ в бота.

Таск-трекер

Здесь все очень базово, есть проекты, есть задачи в этих проектах, у каждой задачи есть статус и история ее выполнения. Когда в нашей жизни появляются «проектЫ», сразу появляется роутинг, то есть требование по одной голосовухе определить к какому проекту она относится.

Сначала я думал сделать автоопределение, ну ведь эпоха ллмок же — пусть все само, но походив с идеей буквально день, я понял что у меня нет СДВГ, и потому я предпочитаю концентрированно работать над чем-то одним минимально продолжительное время. Поэтому завел «служебную фразу», которая переключает проект. Сначала я хотел сделать прям по слову «проект», но решил расширить — я хочу иметь возможность переключать не только проекты, но и режим работы (текст или аудио — про это позже) и потенциально еще другие вещи, поэтому неким «споттерным словом» стало слово «Настройки». Идти в полноценный список интентов я пока не хочу, но легкий понятный классификатор на входе повышает детерминируемость всей цепочки.

Здесь просто быстрая регулярка поверх транскрибации — если первое слово это «настройки», то дальше мы вытаскиваем нужные слова, где каждое слово отвечает за настройку, и если вытащили что-то по слову «��роект», то делаем некий sticky-project на 3 часа на него. То есть, как только проект нашелся и зафиксировался, то все последующее попадает именно в него. Если я вдруг забыл установить проект, то задача попадает в «неразобранное» и уже потом на десктопе ее можно переназначить — сквозные интерфейсы огонь, ну.

Но здесь есть нюанс. Вот у меня проект с названием ebench (бенчмарк ит-мероприятий). Вот мои попытки попасть именно в него:

Да, скрывание проектов сделал одной голосовухой специально для скриншотов под хабр — ну кайф же.

Результат в задаче: исходное аудио, транскрибация, рефайн, история и итоговый результат. И да, про бд в браузере — это я не поехавший, сейчас реально в браузерах есть встроенные sql-style базы помимо localstorage. Итоговый скриншот задачи для залипания:

Транскрибация

Чтобы попадать в название проекта всегда вне зависимости от результата транскрибации, я сделал полировку через ллм: вот тебе транскрибация, вот названия заведенных проектов, верни корректный. Идеально, за пару недель без промахов.

В качестве транскрибатора я взял GigaAM, отличная модель, которая очень недурно работает даже без GPU и на первых субъективных тестах показала лучшее понимание технических терминов и полностью устроила по скорости и памяти. На радарах была также T-One (я даже делал их сравнение), но ее я думаю погонять на исторических логах попозже.

Да, маленькое отступление про умные колонки с ассистентами: они всегда слушают весь поток, но локально на устройстве держат только короткий кольцевой буфер последних секунд и гоняют по нему легкий детектор wake-word (оно же «споттерное слово» — как правило, имя ассистента). Задетектили — колонка проснулась и перешла в другой режим; не поймали — буфер просто перезаписывается дальше.

Ловить споттер-слова это прям наука и в моем случае такого нет — здесь готовое конкретное аудио, с которым можно работать как с завершенным. И да, у меня совершенно нет требования к реалтайму (я подожду из бара 10 секунд, ок), поэтому CPU-режим вполне ок даже вот такое: тг голосовуху присылает в OGG, а GigaAM работает с WAV 16kHz mono, поэтому сначала это все надо конвертнуть через ffmpeg.

Правда, завелось все не совсем сходу: на относительно небольших голосовухах вылезло Too long wav file, use ‘transcribe_longform’ method, поэтому я просто решил разбивать на чанки по 15 секунд и потом их склеивать.

Но в любом случае, вся связка работает на удивление быстро.

Мне не нравилось, что робот постоянно присылал текстовые отбивки, и потому я сократил количество сообщений до минимума, а в качестве статуса принятия задачи в очередь сделал вот это, каждый раз угарно:

И да, если я прислал текст, то этап транскрибации просто пропускается, а дальше все точно такое же.

Дальше для текста делается «рефайн», то есть подчищение текста в нечто более осмысленное, этот этап нужен, чтобы сгладить косяки и артефакты транскрибации. За главного — Gemini-Flash-2.5, справляется на ура. В целом, сюда же можно заложить исправление более разговорного стиля в более технический или убирать неизбежные эмоции от кодонаписания с LLM — с этим я экспериментирую.

Тулер или execution-сервер

Ок, вот мы положили задачку в нашу базку, и теперь нам надо с ней что-то сделать. Я уже промышленно освоил Claude Code и Codex со всеми их хаками и «бестпрактисами» и в полном восторге, поэтому фактически здесь все сводится к тому, чтобы просто их запустить, прокинуть задачу как промпт и перехватить выход. И да, нужен, собственно, доступ к коду.

Или не только к коду? Не только к коду! Моя главная боль — написание кода, я хочу накидывать голосовухи, которые реально закрывают задачи на проектах, но иногда код не нужен — когда нужно собрать материал, почелленджить идею, выбрать робот-пылесос или просто завести задачу. Я хочу расширять функционал и целюсь прям в гиперперсонализированного помощника под себя. Поэтому для проектов я завел инструменты (тулы) в самом широком смысле и их можно настроить индивидуально. Когда задача отрабатывает, дальше по надобности вызывается нужный тул.

Вот так:

Это самая замароченная часть, я решил ее вот как: у меня есть уже много лет арендуемый bare metal (без GPU), то есть мощный серверок без виртуализаций, который мне и нужен только под эксперименты. Как только на нем нарабатывается что-то толковое, то оно уезжает в отдельный прод уже по всей науке.

Итак: поставил кодогенераторы, прокинул им авторизацию, завёл отдельных ubuntu-юзеров, под которыми они работают. Сделал одну большую папку с правами, внутри структура как / + project_slug. Для веб-проектов иногда хочется смотреть результат сразу по ссылке, поэтому вывесил наружу под basic auth несколько поддоменов вида sandbox-X: nginx мапит их на заведенные project_slug (типа /bigdir/habr_rust) — и оно открывается сразу в вебе: либо отдает статику, либо проксит в поднятый внутри сервинг через node/uvicorn/gunicorn/whatever.

Защитой от rm -rf тут являются ограничения доступа ubuntu-юзеров, понимание что это sandbox-окружение и постоянный коммитинг в гит. Но конфиги кодогенераторов я все равно прописал, на примере Claude Code:

{
  "permissions": {
    "allow": [
      "Edit",
      "Write",
      "Bash(ls)",
      "Bash(cat)",
      "Bash(git *)",
      "Bash(npm *)",
      "Bash(npx *)",
      "Bash(node *)"
    ]
  }
}

Есть тут над чем поработать по -ops части, но пока все работает недурно и надо понимать, что это исключительно мой закрытый сетап по�� меня самого.

Тулер — это отдельный сервис на той самой bare metal отдельной машине, который принимает в себя payload (+bearer-headers), в котором содержится вся информация: что надо вызвать и что туда прокинуть, а также много логики как с этим всем дальше жить.

Выбор тула делается на стороне таск-трекера — сначала я хотел это сложно и каскадно, но по факту у каждого проекта за редким исключением есть дефолтный тул, поэтому все упростилось до инструкции к полному перекладыванию этого на LLM: кидай в дефолт, если явно не прошу другое (например, тесты через Playwright-обвязку).

По факту тулер запускает процесс с тулом и сразу возвращает его PID, а бэк (таск-трекер) начинает поллинг статуса каждые 5 секунд, stdout/stderr копятся на тулере. Параллельно тулер может прислать POST-callback с результатом — страховка на случай если поллинг отвалится.

Если тулер находит .git, то он сразу коммит в репу по вот таким правилам: создается ветка вида auto/YYYY-MM-DD — все автоматические коммиты за день идут только в нее. Это такая «спецстоянка» кодогенерашек. Пока что первая строка инструкции становится комментом коммита, но тут большое поле для экспериментов. После каждой голосовухи тулер делает git add & git commit & git push в эту спец ветку, а затем у меня есть возможность отсмотреть код каждого коммита на большом экране и по готовности все нужное мержить.

Результат

Хотя кодогенераторы запромчены так, чтобы выдавать минимально достаточный ответ, он все равно бывает объемным. Поэтому здесь снова в дело вступает ужиматор в виде еще одного запроса к LLM, который компактизует все в какой-то удобный мне ответ.

Удобство зависит от текущего режима — если текст, то его должно быть поменьше, но в нем можно прям мелкие детальки передать. Если аудио, то там лучше магистрально объяснить что произошло, но его и послушать можно подольше.

Текст:

Да, бот тоже в ответ может кидать голосовухи! В качестве Text2Speech я взял SileroTTS — просто потому что оно хорошо работает с русским языком и генерирует аудио молниеносносно. Да, на выходе механический голос и коверкание слов, но зато все быстро и на CPU. Итог обратно конвертится в ogg и улетает обратно в TG.

Пример голоса, вполне недурно:

Да, здесь уже самое время добавить про «вайб-кодинг» и кодогенерацию как таковую. Я чаще встречаю скорее полярные мнения — либо «это СКОРО всех нас заменит», либо «вы вообще видели ЭТОТ КОД?» и чаще отношение какое-то вот такое:

Правда — не «где-то посередине», а очень зависит от типа решаемых задач и поставленной цели. Не всем проектам это подойдет — да, но я для себя вижу бешеное повышение продуктивности там, где оно уместно и бесконечно верю в то, что AI-кодогенерация может быть эффективной, если сохранять инженерный подход: продумывать фичу и ее архитектуру, гонять бенчи, писать тесты, критерии приемки и ревью. Чем глубже знания автора, чем ширше его технологическая насмотренность, и чем больше скучных штук вокруг сгенерированного кода — тем лучше результат.

Поэтому на карточке задачи — все необходимое для дальнейшего анализа (сырые данные, сжатые, время работы и тд), которые пока просто копятся, пока я набивают опыт. И да, это все данные, чтобы попозже посчитать то самое «повышение продуктивности».

Итог обновляется реалтайм (не знаю зачем, но прикольно) по SSE (Server-Sent Events), фронт: Vue 3 + Pinia + Tailwind, но, честно говоря, я ни строчки его не видел.

Финал

Надеюсь вам было интересно. Я сознательно хотел сделать все сам: во-первых, как пруф того, что голос — это уже не будущее, а настоящее. Одно дело верить, другое — реальный код писать через голосовухи. Во-вторых, эта штука дает полный контроль — что хочу, то и делаю, сейчас оно прицеплено к моему гитхабу, но легко переделывается на корпоративный, выходит новый SOTA-cli — два часа, и он у меня. Да, эта штука не универсальна, но она туда и не метит, а ее главное отличие от Clawdbot и прочих — в том, что она работает здесь и сейчас, решая мои конкретные задачи.

Эта система — production-ready в том забавном смысле, что я пользуюсь ей сам один уже пару недель и это просто вау-опыт. Да, есть косяки, да, не все удачно работает, но я набиваю опыт работы в таком режиме, а все остальное всегда можно замерить и улучшить. Благо что в процессе появляется много интересных фишечек, которые так хочется внедрить и мини-трюков, которые попробовать.

Из планов — вложенные задачи, умение цеплять вообще любые инструменты (в том числе llm-browser-use, который я с момента статьи про них — раз и два — неплохо прокачал под конкретный маркетплейс и свои хотелки от него). Кинул голосовуху — сервисок пошел и сделал все, что нужно, а уж допилить его проблем никаких.

Я очень люблю ИИ-агентов и то, что с их помощью можно делать. И голос — это шикарный важный интерфейс к этим агентам, и могу точно сказать, что писать код через голосовухи в чатике — это бесконечно круто.

What a time to be alive.

Спасибо!

Мой крафтовый тг-канальчик Agentic World (подписывайтесь!) и другие статьи:

• Когда лопнет пузырь AI?

• От LangChain к LangGraph: детально разбираемся с фреймворками и всей Lang-экосистемой