Как личный AI-инструмент становится продуктом за один день

14 мая 2026 года начался в 08:35 с сообщения: у клиента из Санкт-Петербурга на новом сервере не поднялся PostgreSQL. Скрипт развёртывания писал конфигурацию в не ту директорию — деталь, которую легко пропустить при переносе с одного дистрибутива на другой. Час на диагностику, две минуты на правку. К обеду ещё 4 похожих бага в том же скрипте — закрыты последовательно. Стандартный рабочий день, если бы не то, что случилось параллельно.

С 13:40 до 17:15 я построил для себя AI-копилот для деловых звонков — с нуля до полноценного рабочего инструмента. К 21:30 этот инструмент уже лежал на витрине 4bos.ru в числе 15 IT-продуктов с описанием, страницей и строкой в sitemap. Всё за один день.

Этот паттерн повторяется у меня не первый раз. Инструмент рождается из личного раздражения — «мне надо для себя». Работает. Оказывается, нужен не только мне. Становится продуктом. Сейчас таких инструментов накопилось больше 15. В этой статье — разбор одного конкретного дня: как работает копилот, почему он вышел из личного в публичное и что это говорит о логике продуктовой разработки с AI-командой.

За этот день я провёл 4 параллельные линии работы: клиентская инфраструктура в Санкт-Петербурге, GEO-SEO обновления на 13 страницах вилл, AI-копилот для звонков с нуля до полного workflow, и витрина 15 IT-продуктов вечером. Всё это — один человек и AI-команда. Без офисных сотрудников, без менеджеров проекта, без совещаний о том, кто что делает. Это не героизм — это просто другая операционная модель.

Утро с чужим багом: PostgreSQL не стартует в 8 утра

«Сервер не поднимается» — это не абстракция, это конкретная боль клиента, чей бизнес остановился в 8:35 утра. PostgreSQL не стартовал потому, что скрипт развёртывания клал файл postgresql.conf в директорию, которую новый дистрибутив не читал. Ошибка в одной строке конфигурации.

Диагностика заняла около часа: подключение к серверу по SSH, просмотр логов systemd (journalctl -xeu postgresql), трассировка того, что именно читает PostgreSQL при старте, сравнение ожидаемого и фактического пути. Найти причину — 80% работы. Починить — 20%. Две строки в скрипте, перезапуск, тест подключения — сервис поднялся.

К обеду добавились ещё 4 бага в том же скрипте развёртывания — все похожей природы: предположения о путях, которые работали на одном дистрибутиве и ломались на другом. Это распространённый класс ошибок при переносе инфраструктуры. Скрипт писали под один Linux-образ, разворачивают на другом — пути к data/, pg_hba.conf, сокетам отличаются. Каждый такой баг — минута исправления, если знаешь где смотреть.

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

Параллельно с клиентской задачей успел продвинуть ещё несколько направлений: GEO-SEO обновления на villa-страницах, Wikidata-сущности для наших проектов, правки email-классификатора. И ближе к часу дня появилось время заняться тем, что откладывал несколько недель.

Откуда берётся задача: 30 звонков в неделю и транскрипт как стена текста

У меня около 30 деловых созвонов в неделю. Клиенты, партнёры, подрядчики, инвесторы по виллам на Бали. После каждого звонка Otter или Granola выдают аккуратный транскрипт — стена текста на 5–15 тысяч слов. Перечитывать её нет времени. К пятнице уже не помнишь, что обещал в понедельник тому самому партнёру.

Стандартная проблема — стандартное решение: взять готовый транскрибатор, настроить summary. Я попробовал несколько инструментов. Проблема в том, что они знают только этот звонок. Они не знают, что три недели назад этот же человек просил другое, что между вами была переписка о третьем, что в прошлый раз вы договорились вернуться к вопросу именно сегодня.

Контекст — это не только транскрипт. Это история отношений. Готовые инструменты не имеют доступа к вашим перепискам, вашим заметкам, вашей истории договорённостей. Они видят один звонок в вакууме.

Вторая проблема — стиль. Когда транскрибатор предлагает summary или следующие шаги, это всегда обобщённый, нейтральный текст. Не мой стиль. Не мои формулировки. Вставить это в задачу или переслать команде — значит ещё раз переписывать своими словами.

AI-копилот, который я начал строить 14 мая, должен был решить именно это: знать контекст, говорить моим языком, работать в реальном времени и фиксировать итог туда, где его потом найдёшь без поиска.

Что умеет AI-копилот для деловых звонков

К вечеру 14 мая копилот работал в 4 режимах. Каждый режим — отдельная фаза взаимодействия с инструментом.

Брифинг до звонка

Горячая клавиша (Hammerspoon, настраивается под любое сочетание) запускает скрипт, который ищет в истории переписки имя или Telegram-хендл контрагента, собирает последние 20–30 сообщений и генерирует сводку: о чём говорили в прошлый раз, что было обещано, что осталось открытым. Это занимает 15–30 секунд. Запрос на генерацию сводки использует Claude claude-sonnet-4-6 с промптом, настроенным под деловой контекст и формат «кто, что, когда». Сводка приходит в Telegram прямо перед тем, как я принимаю звонок.

Разница по сравнению с «открыть историю чата вручную» — в агрегации. Если человек писал в разные каналы (Telegram, WhatsApp, email), копилот собирает всё в одну сводку. Не нужно вспоминать, где именно шёл разговор о конкретном вопросе. Для 40+ постоянных контрагентов это экономит 10–15 минут подготовки к каждому созвону.

Реальное время: транскрипт и реплики

Во время звонка BlackHole захватывает системный аудиопоток. ffmpeg пишет его в WAV-файл. whisper.cpp (локально на Mac) транскрибирует с задержкой 3–5 секунд. Текст стримится в Telegram — я вижу что говорю я и что говорит собеседник почти в реальном времени. Ничего не теряется, даже если соединение прерывается: запись продолжается локально.

Параллельно — реплики. Модель обучена на корпусе из 17 моих прошлых деловых звонков: стиль, типичные формулировки, то как я обычно обрабатываю возражения или задаю уточняющие вопросы. Когда в разговоре появляется триггер — вопрос, на который стоит ответить аккуратно, момент, когда нужно уточнить детали — копилот предлагает реплику в моём стиле через sendMessageDraft. Я вижу предложение, принимаю или игнорирую.

Listen-режим для обучений и вебинаров

Отдельный режим — когда я не говорю, а слушаю. Вебинар, обучение, стратегическая сессия с командой. В listen-режиме копилот только транскрибирует и периодически выделяет ключевые тезисы — без предложения реплик, без активного участия. Выход — структурированный конспект, а не стена текста. Режим активируется другой горячей клавишей.

Структурный итог после звонка

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

От идеи до прототипа за 4 часа: что реально нужно для сборки

В 13:40 я начал с Phase 0: аудиозахват. BlackHole — виртуальный аудиодрайвер для macOS, бесплатный, позволяет захватывать системный аудиопоток. RecordCall — утилита, которая использует BlackHole как источник. ffmpeg для конвертации потока в формат, который понимает whisper.cpp. Настройка заняла около 40 минут вместе с тестами захвата.

Почему whisper.cpp локально, а не облачный Whisper? Облачный вариант нестабилен при загруженном сервере: задержки, таймауты, потеря фрагментов. Локальная транскрипция стабильна и работает без интернета — критично для звонков с нестабильным соединением.

В 14:45 — Phase 0.5: персона и стиль. Я собрал корпус из 17 деловых звонков за последние несколько месяцев. Не весь транскрипт — только мои реплики. Из них составил чеклист стилевых характеристик: как я начинаю разговор, как перехожу к делу, как реагирую на неожиданные вопросы, какие слова-маркеры использую. Этот чеклист стал системным промптом для модуля реплик.

В 16:10 — listen-режим. Отключил генерацию реплик, оставил только транскрипцию и тезисы. Нужно было для созвона-обучения на вечер.

В 16:25 — Phase 2: брифинг из переписки. Подключил Telethon к своей Telegram-сессии. Написал поисковый запрос: по имени или хендлу — достать последние сообщения из всех чатов. Это заняло около часа, потому что нужно было аккуратно обработать случаи, когда один человек пишет с разных аккаунтов или в разные чаты.

В 16:35–17:15 — финальная интеграция: stream-режим, sendMessageDraft для подсказок, авто-классификация типа звонка, сохранение итога в папку Clients/.

Итоговый стек: BlackHole (аудио), ffmpeg (конвертация), whisper.cpp локально (транскрипция), Claude claude-sonnet-4-6 API (реплики + итог), Telethon (доступ к истории переписки + канал доставки), Hammerspoon (горячие клавиши). Всё опенсорс, кроме Claude API. Стоимость API на 30 звонков в неделю — около $15–20 в месяц.

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

Почему личные инструменты превращаются в продукты

Когда делаешь что-то для себя, у тебя нет времени делать это плохо. Ты сам будешь этим пользоваться каждый день. Нет UX-буфера между разработчиком и пользователем — это один и тот же человек. Результат: личные инструменты, как правило, хорошо отшлифованы по функциональной части, даже если выглядят неказисто снаружи.

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

Третий фактор — скорость проверки. Инструмент работает или не работает сразу. Нет нужды в фокус-группах, A/B-тестах, интервью с пользователями. Тест занимает первый же созвон. Если что-то сломалось — ты это мгновенно замечаешь и чинишь.

Четвёртый фактор — низкая стоимость ошибки. Личный инструмент никому не обещан. Если он перестал работать на два дня — страдаешь только ты, а не чужой бизнес. Это позволяет двигаться быстро и смело: добавлять фичи без страховочных сеток, итерировать прямо в продакшне.

Проблема с личными инструментами одна: они не выходят наружу. Остаются в папке на компьютере, в репозитории без документации, в голове у автора. Чтобы стать продуктом, нужен ещё один шаг: описать что это, кому нужно, как работает, сколько стоит.

Раньше этот шаг был дорогим: нужен копирайтер, дизайнер, разработчик для страницы. Сейчас — нет. Это и есть ключевое изменение: упаковка перестала быть узким местом. О том, как не повторить типичных ошибок при масштабировании таких инструментов, написал отдельно: 5 ошибок AI-автоматизации в бизнесе.

15 инструментов, которые начинались как «мне надо для себя»

Копилот для звонков — не первый такой случай. За последние несколько месяцев в той же логике появилось ещё около 15 инструментов. Вот несколько показательных примеров с реальными цифрами использования.

Локальная диктовка на Mac. Облачные сервисы транскрипции стоят $80–100 в год и требуют постоянного интернета. Развернул whisper.cpp локально — работает офлайн, транскрипция занимает 30 секунд, стоит $0 в месяц. Пользуюсь каждый день для голосовых заметок. Инструмент запущен в феврале 2026, на момент написания статьи — 90+ дней активного использования.

Переводчик WhatsApp-чатов с балийскими сотрудниками. Управляю примерно 16 активными виллами на Бали (lifetime-портфель 65 объектов). Сотрудники пишут на индонезийском и балийском. Бот переводит входящие сообщения в реальном времени и помогает формулировать ответы с правильным культурным контекстом — не просто перевод, а адаптация под нормы общения в Индонезии.

Синхронизация Stories из Telegram в Instagram и ВК. Жена ведёт блог о жизни на Бали. Публикует в Telegram. Бот подхватывает Stories и кросспостит на другие платформы автоматически — без ручного переоформления. Экономия: 40–60 минут в день. Этот же инструмент сейчас используют 3 других блогера помимо нас.

Финансовый бот для семьи. Парсит банковские выписки из нескольких счетов, классифицирует расходы по категориям, строит месячный отчёт. Обслуживает 8 человек включая меня и жену. Запущен в марте 2026, уже 2+ месяца в работе без сбоев.

Рассыльный парк аккаунтов. Для лидогенерации и охватных рассылок — управляемый пул Telegram-аккаунтов с ротацией, контролем лимитов и мониторингом банов. Обслуживает несколько направлений параллельно.

Дашборд инвесторов. Доступен на 4bos.online. Агрегирует данные из PMS (система управления бронированиями), рассчитывает P&L по каждой вилле, показывает инвестору его долю и выплаты в реальном времени. Начинался как «мне надо видеть цифры по каждому объекту».

Email-классификатор с 3-уровневым приоритетом. Анализирует входящую почту, расставляет приоритеты (срочно / важно / информационно), дедуплицирует цепочки. Запущен 14 мая 2026 — в тот же день, что и копилот для звонков.

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

Вечером: витрина из 15 продуктов вместо одного кейса про виллы

До 14 мая на 4bos.ru в разделе «Проекты» лежал один кейс — про управление виллами на Бали. Хороший кейс, но узкий: создавал впечатление, что я делаю только одно. В 19:00 начал переделку.

Задача: из списка инструментов и проектов собрать публичную витрину. 15 продуктов в 5 категориях. Для каждого — страница с ответами на 5 вопросов: что делает, кому подходит, как работает, как ставим, сколько стоит.

Как это делается с AI-командой: я формулирую для каждого продукта позиционирование — чем он отличается от готовых аналогов и кому конкретно нужен. Тексты, вёрстку и sitemap команда собирает по моим заметкам и архитектурным документам. Я не пишу ни строчки HTML.

К 21:30 — 15 страниц продуктов, обновлённый индекс, sitemap отправлен в поисковые системы через IndexNow. Весь процесс занял 2,5 часа. Это и есть то, что изменилось с появлением AI-команды: упаковка перестала быть узким местом. Раньше между «инструмент готов» и «инструмент на витрине» стояла работа на несколько дней — копирайтер, верстальщик, согласования. Сейчас этот шаг стоит несколько часов.

Итог дня: что это значит для логики продуктовой разработки

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

Это важное смещение. Раньше предприниматель, у которого есть идея, упирался в ресурсы: нет программиста, нет копирайтера, нет времени делать страницу. Сейчас всё это перестаёт быть барьером. Барьером остаётся только одно — качество идеи и глубина понимания проблемы.

Когда я строил копилот для звонков, я не думал о том, как это продать. Я думал о том, что у меня 30 созвонов в неделю и я устал терять контекст. Инструмент решил мою проблему. Оказалось, что это не только моя проблема.

Следующий шаг для любого, кто хочет двигаться по этой логике: начать вести список личных раздражителей. Вещей, которые вы делаете руками или тратите на них больше времени, чем хотите. Вероятно, среди них уже есть 2–3 кандидата в инструмент. Не нужно сразу думать о масштабировании и монетизации. Нужно просто сделать так, чтобы это работало для вас.

Для любого, кто думает о автоматизации бизнеса с нуля, эта логика особенно важна: начинать не с продукта для рынка, а с инструмента для себя. Потом смотреть, нужен ли он ещё кому-то. Потом упаковывать.

Витрина из 15 продуктов — на 4bos.ru, в разделе «Продукты». Там же — страница по каждому: что делает, кому подходит, как запустить. Если узнаёте в каком-то свою проблему — напишите, обсудим конкретику.

Юрий Солар, основатель Solar Property и 4bos.ru: «Самое неожиданное в этой модели — не скорость сборки инструментов, а то, что исчезает страх выпускать. Раньше между готово и на сайте стояли недели работы и мысль а вдруг никому не нужно. Сейчас выпустить занимает часы. И страх пропадает — потому что цена ошибки стала маленькой, а скорость проверки гипотезы — большой».

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

Об инструментах, которые умеют чинить себя сами и не требуют ручного вмешательства, — в статье про self-healing боты и как строить системы, которые восстанавливаются без вас.