День, когда система работала пока я спал: автоматизация бизнеса на Бали в действии

Проснулся. Потянулся за телефоном. Открыл дашборд — и вместо списка проблем увидел спокойные зелёные метки. Система сама починила сломанный коннектор Facebook, сама очистила мёртвые Telegram-группы и сама записала всё в логи. Никто меня не будил, никакого пожара не было. Просто система работала, пока я спал. Именно к этому я и шёл последние полтора года, выстраивая автоматизацию бизнеса на Бали шаг за шагом. 13 апреля 2026 года стал одним из тех дней, который я запомню надолго — не потому что было много сделано вручную, а потому что почти ничего не пришлось делать вручную вообще. Эта статья — детальный разбор каждой задачи дня: что произошло, как работает технически, и что вы можете взять из этого для своего бизнеса. Watchdog, который следит за сервисами и самостоятельно их перезапускает. Система очистки Telegram-групп от «зомби»-подписчиков. GPT-4o Vision, которая научилась правильно распознавать категории расходов по фотографии чека. Удалённый рабочий стол через TigerVNC для авторизации в Facebook. И кроличья нора в каталоге вилл, которая утащила меня на несколько часов глубокой отладки. День насыщенный, хотя по ощущению — лёгкий. Потому что большую часть работы сделала система.

Watchdog починил Facebook-коннектор сам: как работает self-healing в реальном бизнесе

Начну с того, что произошло ночью — пока я крепко спал. Один из ключевых каналов коммуникации в моей системе — это связка с Facebook Messenger. Через неё идут входящие запросы от потенциальных арендаторов вилл, уведомления, иногда переписка с партнёрами. Канал важный, и когда он падает — это потери реальных лидов.

Около трёх ночи Facebook-коннектор потерял авторизацию. Это стандартная история: токен истёк, сессия слетела, что-то поменялось на стороне Facebook. Раньше я бы узнал об этом утром из сообщения в Telegram: «Юра, заявки не приходят». Или не узнал бы вообще — пока кто-то не заметил бы, что ответа на сообщение нет уже сутки.

Как устроен watchdog-сервис: механизм детекции и рестарта

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

Поэтому мой watchdog проверяет не наличие процесса, а его осмысленную активность. Для каждого коннектора у меня есть два ключевых счётчика: количество ошибок за последние 30 минут и количество успешных операций за тот же период. Если в течение получаса накопилось 5 и более ошибок при нулевом прогрессе — это однозначный признак того, что сервис завис или сломан.

Именно это и произошло ночью. Watchdog зафиксировал: 5 ошибок подключения к Facebook API, 0 успешных операций за 30 минут. Порог сработал. Система выполнила рестарт коннектора, подождала 60 секунд, проверила статус снова. Всё зелёное. Записала в лог: «03:17 — Facebook Messenger connector restarted, reason: 5 errors / 0 progress in 30 min. Status after restart: OK». И пошла дальше обходить остальные сервисы.

Почему это меняет игру: сравнение с ручным мониторингом

Раньше, до watchdog, у меня была одна схема: я просыпался, заходил в дашборд, смотрел на статусы, вручную перезапускал то, что упало. Это занимало от 15 до 45 минут каждое утро — в зависимости от того, сколько всего успело сломаться за ночь. Плюс была постоянная тревожность: а вдруг что-то упало посреди дня, когда я занят другим? Нужно периодически заглядывать, проверять, убеждаться.

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

Для бизнеса это конкретные деньги. Один пропущенный лид с Facebook — это потенциально несколько тысяч долларов в выручке для виллы. Несколько часов простоя в пик сезона — реальные потери. Watchdog, который за несколько секунд делает то, что я делал бы через несколько часов, — это не просто удобство. Это страховой полис на самовосстановление инфраструктуры.

Как внедрить watchdog в свой бизнес: практические рекомендации

Если вы работаете с несколькими интеграциями и ботами, вот минимальный набор для собственного watchdog. Первое: определите «сигнал здоровья» для каждого сервиса — это не «процесс запущен», а конкретное действие, которое сервис должен делать. Для мессенджер-коннектора — получать и отправлять сообщения. Для финансового бота — записывать транзакции. Для SEO-агента — генерировать отчёты. Второе: установите пороги аномалии: X ошибок при Y успехах за Z минут — что-то не так. Третье: пропишите автоматический ответ: рестарт, алерт, эскалация. Четвёртое: логируйте всё. Лог watchdog — это история болезней вашей системы, по которой потом можно выявлять паттерны.

Очистка мёртвых Telegram-групп: как автоматизация рассылки повысила эффективность на 40%

Второй сюрприз утра — уже приятный. Пока я пил кофе, Telegram-бот-рассыльщик закончил еженедельный аудит своей базы групп и отчитался о результатах. Из 103 активных групп в базе 39 оказались фактически мёртвыми. Бот отключил их автоматически и прислал мне сводку.

39 из 103 — это почти 38% базы. Больше трети всех «активных» групп на самом деле не давали никакого результата уже неделю и более. Это не просто балласт — это активная нагрузка на систему. Каждая отправка в мёртвую группу — это потраченный запрос к Telegram API, задержка в очереди, лишние попытки повторной отправки, которые тоже ничего не дают.

Почему Telegram-группы умирают: три основные причины

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

Вторая причина — полный бан аккаунта. Telegram иногда ограничивает или блокирует аккаунты, которые ведут активную рассылку. Я использую несколько аккаунтов для равномерной нагрузки, но некоторые периодически попадают под ограничения. Группы, привязанные к заблокированному аккаунту, автоматически становятся недоступными для рассылки.

Третья причина — запрет на публикацию медиа. Некоторые группы переводят настройки на «только текст» или вводят дополнительные ограничения для участников. Мои рассылки обычно содержат фотографии объектов и форматированный текст, поэтому в таких группах они просто не проходят.

Алгоритм автоматической очистки: логика принятия решения

Критерий отключения простой и понятный: если за последние 7 дней в группу было сделано 3 и более попыток отправки, и ни одна не прошла успешно — группа помечается как «мёртвая» и переводится в статус «отключена». В базу данных пишется запись с причиной: «auto: 3+ ошибок, 0 успехов за 7 дней».

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

После очистки в базе осталось 64 активные группы из 103. Успешность рассылок сразу выросла — теперь каждая отправка идёт в аудиторию, которая реально получает сообщения. Время обработки очереди сократилось примерно на треть. Метрика «доставлено / отправлено» поднялась с 62% до практически 100% по активным группам.

Урок для всех, кто делает Telegram-рассылки

Если вы используете Telegram для массовых рассылок — не ленитесь делать регулярный аудит базы. База групп живёт и дышит: группы появляются, умирают, меняются правила. База, которую вы собрали полгода назад, сегодня может быть на 30–40% мёртвой. Это не просто потеря охвата — это активный расход ресурсов на бесполезные попытки. Автоматизируйте аудит: раз в неделю пробегитесь по статистике доставки, отключите группы с нулевым успехом за последние 7 дней. Ваша система станет быстрее, точнее и дешевле.

GPT Vision учится читать чеки: как я научил AI правильно классифицировать расходы

Третья задача дня была не экстренной, но важной для долгосрочной цели — полностью убрать ручной труд из учёта финансов. У меня уже несколько месяцев работает система распознавания чеков через GPT-4o Vision: я фоткаю чек на телефон, отправляю в Telegram, бот распознаёт и записывает в базу. Но была одна стабильная проблема: слишком много чеков улетало в категорию «нераспознанное».

Разбирая логи, я обнаружил интересный паттерн. GPT смотрела на фотографию чека, видела слова «payment», «transfer», «bill», «счёт», «invoice» — и честно сообщала: «расходная операция, категория неизвестна». Потому что эти слова действительно ни о чём не говорят. «Payment» — это может быть и обед, и аренда, и электричество. GPT была права, что не угадывала категорию по таким общим словам. Но результат был бесполезным.

Проблема пустых слов и как с ней бороться

Решение состояло из двух частей. Первая — добавить в промпт явный «чёрный список» пустых слов. Я перечислил все слова, которые не несут информации о категории: payment, transfer, bill, invoice, receipt, счёт, чек, оплата, платёж и так далее. Инструкция для GPT стала конкретнее: «Если на чеке есть только эти слова без дополнительного контекста, ищи другие признаки категории — название заведения, тип товара, специфические термины».

Вторая часть — добавить в промпт словари синонимов по каждой категории расходов. Теперь у GPT есть явные списки: что означает «электричество» (PLN, listrik, Perusahaan Listrik, kWh, meter listrik — это балийские и индонезийские термины в счетах за электричество), что означает «вода» (PDAM, air, Perusahaan Daerah Air Minum), что означает «транспорт» (Grab, Gojek, ojek, taxi, bensin, BBM — топливо по-индонезийски), что означает «церемонии» (offerings, canang, sesajen, upacara, banten — типичные слова в чеках за балийские ритуальные принадлежности).

Результат: от «bill» до «обед» в одном шаге

Тестирую сразу же. Фотографирую чек из местной столовой — варунга, где обедаю. На чеке написано: «Nasi campur — 35.000 IDR, Es teh — 8.000 IDR, Total: 43.000 IDR». Раньше GPT выдавала бы «расходная операция, категория: нераспознанное». Теперь в словаре есть: nasi — рис, makan — еда, warung — столовая, mie — лапша. Бот написал: «Обед, 43.000 IDR (~$2.70)». Правильно, без моего вмешательства.

Второй тест — счёт за электричество. На чеке: «PLN Prepaid — 500.000 IDR». В словаре: PLN = электричество. Бот: «Электричество, 500.000 IDR (~$31)». Третий тест — чек из Grab. «Grab Car — 75.000 IDR». Бот: «Транспорт, 75.000 IDR (~$4.70)». Все три — правильно.

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

GPT Vision для финансов: советы по промпт-инжинирингу

Если вы строите похожую систему распознавания чеков через GPT Vision, вот что работает у меня. Во-первых, всегда добавляйте локальный контекст: для Бали это индонезийские слова, для Таиланда — тайские, для России — русскоязычные сокращения из чеков ОФД. Общие промпты дают общие результаты. Во-вторых, стройте словари инкрементально: каждый раз, когда GPT не распознаёт категорию, смотрите на чек и добавляйте соответствующие слова в словарь. Через месяц такой работы система знает 90% ваших типичных расходов. В-третьих, явно перечисляйте пустые слова — это резко снижает количество ложных срабатываний. GPT гораздо лучше работает, когда ей говорят «не обращай внимания на Х» явно, а не рассчитывают на интуицию.

Договор аренды задним числом: когда лучший ход — не лезть руками

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

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

Работа с двуязычным юридическим документом

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

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

Главный принцип: иногда лучший ход — это не лезть

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

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

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

VNC-доступ к серверу: как настроить удалённый рабочий стол за шесть шагов

После обеда пришла задача, которую я откладывал несколько дней. Facebook-коннектор watchdog перезапустил ночью — хорошо. Но причина потери авторизации никуда не делась: токен устаревает и его нужно периодически обновлять вручную, войдя в аккаунт через браузер. Для этого нужен браузер на сервере.

Задача на первый взгляд простая: войти в Facebook через браузер на сервере. Но сервер у меня headless — без монитора и графического интерфейса. Всё управление через SSH в командной строке. Чтобы открыть браузер с графическим интерфейсом, нужен виртуальный дисплей. А чтобы получить к нему удалённый доступ — VNC-сервер.

Архитектура решения: TigerVNC + noVNC

Я выбрал связку TigerVNC (VNC-сервер) + noVNC (веб-клиент для подключения через браузер без установки VNC-клиента). Это позволяет открыть удалённый рабочий стол прямо в браузере на ноутбуке, не устанавливая никакого дополнительного ПО.

Шесть шагов, которые я задокументировал для следующего раза. Первый: установить TigerVNC-сервер на сервер. Второй: создать файл конфигурации и задать пароль VNC. Третий: запустить виртуальный дисплей Xvfb (X virtual framebuffer) — программный монитор. Четвёртый: запустить TigerVNC, подключённый к виртуальному дисплею. Пятый: открыть порт в файрволе временно — только на время сеанса логина, только для моего IP-адреса. Шестой: подключиться через noVNC, открыть браузер, войти в Facebook, закрыть порт обратно.

Безопасность: принцип минимального открытия

Момент с файрволом — ключевой с точки зрения безопасности. Открытый VNC-порт — это приглашение для атак брутфорсом. Поэтому мой подход: порт открывается только на время активного использования и только для конкретного IP-адреса. После завершения сеанса — порт закрывается немедленно. В скрипте это выглядит так: открыть порт, выполнить нужные действия, закрыть порт. Всё в одном runbook.

Результат: вся процедура авторизации в Facebook через сервер занимает около 10 минут. Из них 8 минут — это ожидание загрузки страниц и прохождение двухфакторной аутентификации. Полезная работа — две минуты. Зато теперь у меня есть готовый задокументированный runbook: в следующий раз не нужно вспоминать последовательность шагов из головы — просто открываешь документ и следуешь инструкции.

Ценность документации: runbook как актив бизнеса

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

Runbook по VNC занял 15 минут на написание. В следующий раз сэкономит 30–40 минут ковыряния в памяти и документации. Три использования — и документация полностью окупилась. Плюс это можно передать помощнику или агенту: «сделай шаги 1–6 по этому документу» — и они сделают без вопросов.

Кроличья нора в каталоге вилл: как один баг привёл к четырёхчасовому рефакторингу

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

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

Баг первый: тумблер, который переключал только половину флагов

Открыл код. Тумблер «включить» в мини-приложении Telegram устанавливал флаг `is_active = true` в таблице объектов. Но логика отображения в каталоге проверяла два флага: `is_active` И `is_published`. Тумблер менял только первый. Второй оставался в значении `false` по умолчанию. Итого: вилла «включена» по одному критерию, но скрыта по другому. Пользователь видит, что нажал кнопку, но вилла не появляется. Классический баг несогласованного состояния.

Починил: тумблер теперь устанавливает оба флага одновременно. Но попутно обнаружил, что у восьми других вилл в базе такая же ситуация: `is_active = true`, `is_published = false` — застряли в промежуточном состоянии из-за того же бага. Одним SQL-запросом починил всех восьмерых: `UPDATE villas SET is_published = true WHERE is_active = true AND is_published = false`. Восемь застрявших вилл сразу появились в каталоге.

Баг второй: Telegram блокирует браузерные диалоги

Второй баг был в операции удаления. Код использовал стандартный браузерный `confirm()` — диалог «вы уверены?» перед удалением объекта. Проблема: Telegram WebApp блокирует нативные браузерные диалоги. Пользователь нажимал «удалить» — ничего не происходило. Никакого сообщения об ошибке, просто тишина.

Заменил на кастомный диалог через Telegram Web App API — `window.Telegram.WebApp.showConfirm()`. Теперь Telegram показывает свой нативный диалог подтверждения, который корректно обрабатывается внутри mini app. Это тонкий момент, о котором легко забыть: разрабатывая Telegram mini app, нельзя полагаться на стандартные браузерные API — они либо не работают, либо работают неожиданно.

Дубль с 385 транзакциями: как я чуть не потерял данные

Но самое интересное ждало впереди. Разбирая структуру базы данных каталога, я обнаружил аномалию: один из моих объектов — небольшой гостевой дом на восемь комнат — существовал в базе в виде семи разных объявлений. Семь! Включая полный дубликат с 385 финансовыми транзакциями.

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

385 транзакций — это реальные данные, которые нельзя потерять. Это история платежей, расходов, доходов. Удалить дубль напрямую — значит потерять всё это. Нужна аккуратная операция слияния.

Слияние данных: скрипт для правильной структуры

Я потратил около двух часов на правильное слияние. Алгоритм: определить «главную» запись (ту, с которой связаны финансовые транзакции), перевести все связанные записи других таблиц на главный ID, обновить метаданные из лучшей версии среди дублей, удалить дубликаты. Параллельно привёл структуру к правильному виду: восемь комнат попарно по типам (четыре стандартных, четыре делюкс), правильные категории, актуальные цены.

Дополнительно подтянул 36 фотографий из Google Drive через сервисный аккаунт — у объекта не было ни одной фотографии в базе, только ссылки на внешние альбомы. Написал скрипт, который обходит папку в Google Drive, скачивает фотографии, оптимизирует под веб (сжатие, правильные размеры, WebP-формат) и загружает в хранилище с правильной привязкой к объекту. Alt-теги для каждой фотографии: «Villa [название], комната [тип], [основная особенность]» — для SEO и доступности.

Скрипт написан переиспользуемым: теперь для следующего отеля с фотографиями в Google Drive нужно только передать ID папки и ID объекта. Весь процесс займёт пять минут вместо двух часов. Это и есть правильный подход к работе с кодом: делать сложную задачу один раз хорошо, чтобы в следующий раз она занимала минуты.

Принципы вместо инструкций: философия управления AI-агентами

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

Я понял, что это один в один описывает то, к чему я прихожу в работе с AI-агентами. Первые несколько месяцев я писал детальные промпты для каждой задачи: «сделай шаг 1, потом шаг 2, потом проверь условие А, если нет — сделай Б». Это работало, но плохо масштабировалось. Каждая новая задача требовала нового промпта. Когда задача немного менялась — промпт устаревал и нужно было переписывать.

От инструкций к принципам: как это выглядит на практике

Постепенно я перешёл к другому подходу. Вместо «сделай шаг 1, потом шаг 2» — «цель такая-то, ограничения такие-то, принципы принятия решений такие-то». Агент сам выбирает, какие шаги сделать, чтобы достичь цели в рамках ограничений.

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

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

Почему модели становятся умнее и что это означает для автоматизации

Есть ещё один важный аргумент в пользу принципов, а не инструкций. Языковые модели становятся значительно умнее каждые несколько месяцев. То, что GPT-4 делала неловко год назад, GPT-4o делает изящно сегодня. Та же динамика с Claude, Gemini, другими моделями.

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

Весь 13 апреля мои агенты не задавали мне вопросов «что делать». Watchdog не спросил: «рестартовать ли Facebook коннектор?» — он просто рестартовал по своему принципу. Рассыльщик не спросил: «отключить ли группу с тремя ошибками?» — он отключил по своему принципу. GPT Vision не спросила: «это электричество или что-то другое?» — она нашла PLN в словаре и решила сама.

Практика передачи принципов: три вопроса для построения автономного агента

Когда я создаю нового агента или переписываю существующего, я задаю три вопроса. Первый: какова цель этого агента в терминах результата, а не действий? Не «агент должен делать X», а «агент должен обеспечивать Y». Второй: какие границы никогда нельзя переступать? Это может быть «никогда не удаляй данные без подтверждения» или «никогда не отправляй сообщение незнакомому контакту». Третий: что считается успехом и что считается проблемой, требующей эскалации? Чёткие критерии на уровне принципов позволяют агенту самостоятельно оценивать свои действия.

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

Главный сдвиг: из исполнителя — в архитектора системы

Вечером, закрывая ноутбук, я думал о том, чем день 13 апреля отличается от того, каким был мой рабочий день полтора года назад. Тогда я решал задачи: писал тексты, анализировал данные, договаривался с подрядчиками, вёл учёт. Сейчас я проектирую системы, которые решают задачи за меня.

Звучит как банальность, но ощущается очень конкретно. Watchdog, который починил Facebook ночью, — это не просто автоматизация одной задачи. Это система, которая работает каждые пять минут, каждый день, каждую ночь, пока я занят другим или сплю. Аудит Telegram-групп, который очистил 39 мёртвых записей, — это не разовое действие. Это еженедельный процесс, который будет работать и через месяц, и через год.

Каждый час, потраченный на улучшение системы, даёт мультипликативный эффект. Правильно настроенный watchdog будет спасать сервисы от зависаний следующие годы. Словарь категорий для GPT Vision будет правильно классифицировать чеки ещё тысячи раз. Runbook по VNC сэкономит час работы в следующий раз, и в следующий следующий тоже.

Это и есть главный сдвиг, к которому я шёл. Я перестаю быть исполнителем и становлюсь владельцем принципов. Моя задача — не решать задачи, а создавать условия, в которых система решает их сама. Если хорошо настроить — система починится, очистится, распознает правильное слово в чеке.

А вы своим ботам инструкции выдаёте или принципы? 🌴

Заключение: день, который работал сам

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

За один день: watchdog самостоятельно детектировал и починил сломанный Facebook-коннектор в три ночи — без будильника, без моего участия. Алгоритм аудита очистил 39 мёртвых Telegram-групп из 103, подняв эффективность рассылок с 62% до практически 100%. GPT-4o Vision научилась правильно читать балийские чеки благодаря локализованным словарям — один шаг к полностью автономному финансовому учёту. VNC-доступ через TigerVNC и noVNC позволил войти в Facebook через браузер на сервере, а задокументированный runbook делает повтор этой операции тривиальным. Рефакторинг каталога вилл устранил два системных бага, починил восемь застрявших объектов и распутал дубль с 385 финансовыми транзакциями.

Все эти задачи объединяет одно: я не решал их вручную от начала до конца. Я либо настраивал систему, которая решила их сама, либо работал в паре с AI-агентом, который взял на себя рутину. Мой вклад — принципы, границы, архитектурные решения. Система — всё остальное.

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

Напишите мне в Telegram — расскажите, что сейчас занимает больше всего вашего времени в бизнесе. Вероятно, это именно то, что стоит автоматизировать первым.

День, когда система работала пока я спал: автоматизация бизнеса на Бали — day-log 13 апреля