10 задач за один рабочий день без сотрудников: разбор реального дня с AI-инфраструктурой

26 мая начался с того, что меня поймали на ошибке. Клиент из Петербурга — медицинская клиника с несколькими врачами — написал утром: «В твоём отчёте 17 постов за неделю, а реально вышло 8». Он был абсолютно прав. Расхождение ровно вдвое, и это не неточность округления — это системный баг в коде сборщика отчётов.

Пока я разбирался с причиной, в очередь встали ещё 9 задач: фидбэк по промптам двух ботов, партнёрская презентация из 13 слайдов, обновление модератора в WhatsApp-группах на Бали, оптимизация голосовой диктовки на Mac, синхронизация контекста между локальным и серверным ассистентом, починка документации для интеграции с X (Twitter), и подготовка к большому пивоту — с 1 июня передаю операционку 16 вилл внешней управляющей компании.

К вечеру всё было закрыто. Без единого сотрудника, без совещаний, без «перешли коллеге». Я строю инфраструктуру из AI-агентов, скриптов и ботов, которая закрывает задачи параллельно с моим вниманием, а иногда — вместо него. В этой статье разберу каждую из 10 задач дня: что пошло не так, как чинилось, и что это говорит о принципах автоматизации, которые реально работают.

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

Баг в счётчике постов: когда карусель стала 9 постами

Бот для медицинской клиники раз в неделю автоматически собирает отчёт: сколько постов вышло в Telegram-канале за прошедшую неделю, какой охват, просмотры, реакции. Клиент получает его в понедельник утром без участия менеджера. Это был один из первых ботов, которых я запустил для этого проекта, и он работал без сбоев несколько месяцев подряд.

На этот раз отчёт показал 17 постов. Реально вышло 8. Клиент это заметил — и написал об этом в тот же день. Не каждый будет перепроверять автоматику, и я это ценю: это значит, что клиент относится к данным серьёзно.

Причина оказалась простой, но неочевидной. В Telegram каждый элемент альбома — карусели из нескольких изображений — хранится как отдельное сообщение с уникальным message_id. Когда бот считал посты по количеству ID в канале, он считал каждую карточку карусели отдельным постом. Две карусели за неделю по 4-5 карточек — и у нас уже +9 фантомных постов в отчёте. Бот работал правильно по своей внутренней логике, но сама логика была неверной.

Решение: бот теперь группирует сообщения по media_group_id — параметру, который Telegram присваивает всем карточкам одного альбома. Одинаковый media_group_id означает один пост, независимо от числа карточек. Патч — около 20 минут кода. Перевыпустил отчёт с правильными цифрами, завёл задачу на деплой к следующему понедельнику.

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

Как предотвращать похожие баги

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

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

Фидбэк клиента: 15 минут, чтобы изменить поведение двух ботов

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

• WhatsApp убрать из постов — у клиники нет публичного WhatsApp, только административный чат для внутренних нужд
• Номер телефона — только мобильный, без городского
• Формат описания врачей должен быть единым для всех специалистов

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

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

Для сравнения: в классической компании тот же список фидбэка прошёл бы путь — письмо менеджеру, задача разработчику, спринт, деплой, тестирование. Минимум 2-3 недели. Здесь — 15 минут утром, и к следующей публикации всё работает по-новому.

Принцип модульных промптов

Скорость этого изменения напрямую зависит от того, как организованы инструкции для ботов. Каждый смысловой блок — отдельная секция или файл: «Контакты клиники», «Формат описания врача», «Тональность ответа». Когда меняется одно — не нужно переписывать всё остальное. Если инструкции для бота — единая простыня в 5000 символов, каждое изменение превращается в хирургическую операцию. Модульная структура решает это.

Презентация, которую бот отправил сам

В середине дня пришёл запрос: «Есть ли у нас презентация для партнёров?». По плану я готовил её к четверговому созвону — через два дня.

Собрал презентацию в marp (markdown → PDF, светлый минималистичный стиль), 13 слайдов. Выгрузил на сайт под нечитаемым URL — не в публичный листинг, но доступным по прямой ссылке из Telegram или браузера. Добавил ссылку и краткое описание в бриф-файл серверного ассистента.

Через несколько минут в чате клиента кто-то написал боту: «Есть ли у вас презентация для партнёров?»

Бот прочитал бриф, нашёл ссылку на PDF, отправил её с пояснением: «Открывается прямо в Telegram-превью, можно пересылать». Я не нажал ни одной кнопки.

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

Статичный промпт против динамического брифа

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

Модератор WhatsApp: с 5 минут до 90 секунд

Группы в WhatsApp для риелторов на Бали работают по простому правилу: в каждом объявлении об аренде или продаже обязательно должна быть цена. Без цены объявление создаёт лишние вопросы у потенциальных клиентов и снижает качество группы как информационного источника.

Модератор отслеживает новые публикации. Если цены нет — отправляет автору напоминание. Льготный период был 5 минут: можно было опубликовать без цены и исправить редактированием. Проблема — за последнюю неделю 4 нарушения. Люди публиковали без цен, получали напоминание и игнорировали или не успевали исправить.

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

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

Принцип измеримых критериев изменений

Я не менял настройки «потому что так кажется правильным». Было конкретное число — 4 нарушения за неделю. После изменения будет другое число. Если оно не улучшится — буду искать другую причину: может, дело не в длине окна, а в формулировке напоминания или в другом факторе. Автоматизация без метрик — автопилот без альтиметра.

Диктовка: с 25 секунд до 6

Голосовой ввод на Mac через локальный Whisper-large — один из ключевых инструментов скорости в моём рабочем дне. Зажимаю правый Cmd, говорю, отпускаю — текст вставляется в активное окно. Диктовать в 3-4 раза быстрее, чем печатать, и особенно удобно для длинных сообщений и голосовых заметок.

Проблема: длинные записи — от 30 секунд речи — обрабатывались 20-25 секунд после нажатия. 25 секунд ожидания после каждой диктовки выбивает из потока. При 40-60 использованиях в день это 15-20 минут суммарного ожидания — несколько часов потерянного внимания в неделю.

Причина: после транскрипции Whisper текст чистила дополнительная языковая модель — убирала слова-паразиты, исправляла пунктуацию, нормализовала.

Решение: выключил этап постобработки. Голый Whisper-large без дополнительной чистки. Время обработки: 25 секунд → 6. В четыре раза быстрее.

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

Второе улучшение: keep-warm пинг каждые 8 минут — Whisper не выгружается из памяти. Раньше после 10 минут простоя первый запрос загружал модель заново, ещё 8-10 секунд задержки, причём неожиданной, в середине мысли.

Compound effect в оптимизации

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

Когда документация врёт: починка индексов публикации X

Одна из задач дня выглядела мелкой, но могла стоить дорого. Интеграция с X (Twitter) и зеркало потока Threads → X были добавлены в инфраструктуру публикаций ещё 19 мая. Но когда автоматический бот-публикатор искал список активных каналов для нового поста — X не появлялся в списке.

Запись выпала из индекса горячих каналов — документа, который бот читает при каждом цикле публикации. Бот честно публиковал контент везде, кроме X — и молчал об этом. Никаких ошибок в логах: запись отсутствовала, бот просто её не видел и не знал, что должен искать.

Исправление: вернул запись в индекс. Дополнительно добавил проверку — при изменении списка каналов автоматически выводить diff с предыдущей версией. Так пропажа будет заметна сразу, а не через неделю.

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

Синхронизация контекста: бот видит то же, что вижу я

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

Результат: ассистент иногда говорил клиенту что-то устаревшее или не знал о последнем решении. Клиент получал немного разные ответы от меня и от бота — что путает и снижает доверие к системе.

Решение: rsync каждые 15 минут синхронизирует папки клиентов с локального Mac на сервер. То, что вижу я в Finder — через 15 минут видит и ассистент. Задержка минимальна, изменения передаются инкрементально.

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

Если у вас несколько компонентов, которые должны знать об одних и тех же фактах — спросите себя: как часто они синхронизируются? Если ответ «вручную, когда вспомню» — у вас гарантированный рассинхрон. 15-минутный rsync или webhook при изменении файла решают это автоматически и навсегда.

796 сообщений и подготовка к пивоту

К вечеру занялся задачей, которую откладывал несколько недель: аудитом собственной инфраструктуры перед большим изменением в операционке.

Контекст: управляю портфелем недвижимости на Бали — 16 активных вилл (lifetime-портфель 65 объектов). Вся операционка держится на инфраструктуре AI-агентов: booking-боты, динамическое ценообразование, коммуникация с персоналом, финансовые отчёты для инвесторов. С 1 июня операционка переходит к местной управляющей компании. Я освобождаю руки под другие направления: контент, обучение агентов, b2b-автоматизации для клиентов.

Перед пивотом нужно понять: какая часть инфраструктуры реально нужна после передачи вилл, а какая — шум для задач, которых больше не будет?

Через Telethon (Python-библиотека для Telegram API) выгрузил 796 сообщений из своих рабочих чатов за последние 14 дней. Разложил по папкам по типам: отчёты ботов, утренние дайджесты, инфра-алерты, задачи команде. Каждому файлу присвоил метку: apply (оставить и развивать), noise (выключить), later (не сейчас, но не удалять).

Дальше — неделя ручного маркинга. После этого станет видно, что из этих 796 сообщений реально влияло на решения, а что создавало только информационный трафик без полезного действия. Компоненты с высоким apply-рейтингом — оставляю и развиваю. Генераторы noise — выключаю, не «поставлю на паузу», а именно выключаю.

Принцип регулярного аудита автоматизации

Инфраструктура имеет тенденцию обрастать «историческими» компонентами. Бот, который три года назад решал реальную задачу, продолжает работать после того, как задача изменилась или исчезла. Он потребляет ресурсы, генерирует сообщения и создаёт иллюзию активности — при этом не влияя ни на что значимое. Периодический аудит — раз в квартал или перед крупным изменением — позволяет обнаружить и убрать этот балласт до того, как он начнёт мешать.

Метод с 796 сообщениями — не единственный способ. Более простой вариант: раз в квартал пройтись по списку всех активных скриптов и ботов и задать вопрос по каждому: «Если этот компонент завтра выключится — я это замечу?» Если ответ «нет, наверное не замечу» — это кандидат на деактивацию или глубокий ревью. Хорошая инфраструктура должна быть компактной: лучше 10 компонентов, которые вы понимаете, чем 50, которые работают «где-то там».

Что один рабочий день говорит об автоматизации бизнеса

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

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

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

Это не означает, что всё всегда работает идеально. Баг в счётчике постов жил несколько недель до того, как его поймали. Запись X выпала из индекса и потерялась на 7 дней. Рассинхрон между ассистентом и локальными папками существовал месяцами. Инфраструктура не защищает от ошибок — она делает их стоимость ниже: обнаружение быстрее, исправление дешевле, повторное возникновение маловероятнее.

Если вы думаете о том, чтобы строить бизнес с минимальным штатом — начните с инвентаризации. Запишите 5 задач, которые вы делаете вручную каждый день. Спросите: почему именно я делаю это именно сейчас? Если ответа нет — это кандидат на автоматизацию. Первый бот не изменит жизнь мгновенно. Но он покажет принцип — и начнёт накапливать отдачу с первого запуска. Про то, как Telegram становится операционной системой для такого бизнеса, читайте здесь. А о том, как устроена система мониторинга, которая не даёт ботам ломаться незаметно, — здесь.