Инвестор видел 0 вместо 38 млн рублей: автоматизация учёта активов и AI-ассистент для переговоров

12 июня 2026 года. Первая задача дня открылась с фразы «инвестор видит 0 рублей дохода». Не убытки — ноль. Вместо 38 млн рублей выручки за последние месяцы дашборд показывал пустые ячейки. Загрузка объектов — 55% в реальности, на экране — «н/д». 6 инвесторов несколько недель жили с неверной картиной своих активов и, что хуже, принимали решения на основе этих данных.

За тот же день ещё 9 задач: восстановить займ партнёра из года переписки и автоматизировать пересчёт, исправить баг в боте-модераторе который умножал суточную цену на 30 вместо того, чтобы проверять правильный эквивалент, и собрать с нуля Mac-приложение для созвонов с клиентами — записывает, расшифровывает, подсказывает вопросы в реальном времени, пишет резюме. Итог: 10 задач, 1 разработчик, 0 сотрудников. Вот как это устроено.

Почему инвестор видел 0: неверный источник данных как системный риск

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

История такая. Изначально выручка по объектам считалась из таблицы ezee_bookings — прямой выгрузки из PMS-системы управления бронированиями. Это работало, пока данные обновлялись оттуда в реальном времени. Потом появился промежуточный слой: monthly_pnl_by_villa (MPV) — агрегированная таблица, которая считает прибыль с учётом расходов, управленческого вознаграждения, корректировок и закрытых периодов. Инвесторский дашборд на 4bos.online/investor/ должен был читать данные из MPV. Читал из ezee_bookings напрямую — где данные за последние два месяца не были загружены после смены оператора. Результат: 38 млн рублей выручки превращались в ноль.

Исправление: три строки в dashboard_api.py — переключить источник с ezee_bookings на monthly_pnl_by_villa WHERE status='closed'. Деплой, CF purge, проверка. Цифры появились у всех 6 инвесторов одновременно.

Это классический урок архитектуры данных: каждый визуальный компонент должен явно указывать, из какого конкретного слоя он читает. Не «из БД», не «из данных о бронированиях», а «из monthly_pnl_by_villa WHERE status='closed'». Без этой детализации любой рефакторинг источников создаёт разрывы — пусть временные, но критичные, когда на данных принимают решения люди с реальными деньгами. Инвесторы не звонят и не спрашивают «а правильные ли данные у меня на экране?» — они просто смотрят на цифру и делают вывод.

Принцип закрытого месяца — почему история не должна меняться

Отдельно стоит разобрать архитектурное решение, которое здесь принципиально: закрытый месяц. Данные со статусом status='closed' в MPV не пересчитываются задним числом. Это намеренное ограничение, а не техническое упущение.

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

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

Займ партнёра: как восстановить год переписки и автоматизировать ежемесячный пересчёт

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

Подход шёл в пять шагов:

1. Экспорт данных. Telegram даёт стандартный JSON-экспорт через Settings → Advanced → Export Telegram Data. Выбрать нужный чат, тип «Messages», формат JSON. За 12 месяцев — около 200 сообщений, многие нерелевантные.
2. Парсинг через Claude API. Python-скрипт отправляет пакеты сообщений в Claude с промптом: «Извлеки все упоминания финансовых транзакций. Для каждой: дата, сумма в рублях, тип (займ/возврат/проценты), источник (ФИО отправителя из сообщения).» Claude возвращает структурированный JSON. Из 200 сообщений за 15 секунд — таблица из 23 транзакций.
3. Верификация. Сверить итоговые суммы по каждому типу с банковскими выписками за тот же период. Из 23 транзакций 2 не нашлись в выписках — оказались упоминаниями будущих договорённостей, не фактическими переводами. Убраны вручную.
4. Загрузка в БД. Верифицированные 21 транзакцию загрузить в таблицу partner_loans с полями: date, amount, type, balance_after, notes.
5. Автоматический пересчёт. Cron-задача 1-го числа каждого месяца: пересчитать текущий остаток с учётом всех погашений, сгенерировать сводку (начальный долг, выплачено, остаток, ближайший платёж), отправить партнёру в Telegram.

Весь цикл от экспорта до работающего cron занял 2 часа. Теперь партнёр получает актуальную сводку без напоминалок и без звонков «а сколько я ещё должен?»

Почему это актуально для малого бизнеса прямо сейчас

В малом бизнесе огромная доля финансовых договорённостей живёт в мессенджерах, а не в системах учёта. Займы между партнёрами, рассрочки с поставщиками, агентские вознаграждения, авансы от клиентов — всё это чаще в Telegram, чем в 1С или Excel. Это не лень и не безответственность — это скорость коммуникации. Проблема возникает позже: когда нужно сверить расчёты, возникает спор, или просто хочется понять актуальный баланс.

Автоматизация этого слоя не требует ERP-системы стоимостью несколько миллионов. Требует: экспорт из мессенджера + LLM для извлечения структуры + простая таблица в PostgreSQL или даже SQLite + cron для ежемесячного пересчёта. Четыре компонента, стоимость которых от нуля (open-source стек) до нескольких тысяч рублей в месяц (API). Один день работы один раз.

AI-ассистент для переговоров: Mac-приложение которое слушает и помогает думать

Четвёртая задача дня — и самая показательная с точки зрения того, как AI меняет операционку не через замену человека, а через его усиление.

Созвоны с клиентами — это высококонцентрированная работа. Ты одновременно слушаешь, думаешь, отвечаешь, пытаешься запомнить ключевые детали и не забыть задать важные вопросы. После созвона — 20-40 минут на написание резюме встречи и постановку задач в трекер. При 3-4 созвонах в неделю это 2-3 часа только на «разгрузку» информации после звонков. Чистая транскрипция, ни капли анализа или решений.

Mac-приложение, собранное в тот день, решает это полностью:

1. Запись. BlackHole — виртуальный аудиодрайвер — перехватывает системный аудио. Работает без дополнительных разрешений помимо доступа к микрофону, не требует отдельного аккаунта или сервиса. Запись идёт параллельно с любым видеоконференс-инструментом: Zoom, Google Meet, Telegram, Facetime — всё что угодно.
2. Расшифровка в реальном времени. whisper.cpp с моделью medium переводит аудио в текст с задержкой ~3 секунды. Работает локально на железе Mac — ничего не уходит в облако, что важно при разговорах о деньгах или конфиденциальных проектах. Качество для русского языка — около 95% точности при хорошем микрофоне и стабильном соединении.
3. Подсказки вопросов в реальном времени. Claude Sonnet через streaming API анализирует транскрипт по мере поступления. В боковой панели появляются вопросы, которые стоит задать — не общие, а конкретно по тому, что было сказано последние 2-3 минуты. Если клиент упомянул «у нас три команды по разным регионам» — появится вопрос «как сейчас координируется работа между командами?» Если сказал «мы уже пробовали автоматизацию» — «что именно внедряли и почему не прижилось?»
4. Резюме после звонка. По окончании — автоматическая структурированная сводка: ключевые договорённости, задачи для каждой стороны, следующие шаги с датами, сигналы по клиенту (что беспокоит, что мотивирует, где болит). Время на постзвонковую работу: с 30-40 минут до 5 минут — прочитать, скорректировать детали, отправить.

Технический стек приложения

Всё работает локально на Mac, никаких внешних сервисов кроме Claude API:

• Захват аудио: BlackHole 2ch (бесплатно, MIT license) + AVFoundation для записи в файл
• STT: whisper.cpp с моделью medium — 1.5 GB, достаточно для русского. Модель large-v3 точнее, но требует ~3 GB RAM и заметно медленнее на M-чипах
• LLM: Claude API (claude-sonnet-4-6) через streaming — это позволяет получать подсказки по мере поступления транскрипта, не ждать конца звонка для первой реакции. Промпт для подсказок включает контекст: роль клиента, тему созвона, что уже обсуждалось выше в диалоге
• UI: нативное приложение Swift — боковая панель поверх других окон, прозрачность 85%, не перекрывает видео собеседника
• Хранение: SQLite локально — каждый звонок с метаданными, полным транскриптом и резюме. Поиск по архиву через FTS5 (full-text search встроенный в SQLite)

Стоимость API при среднем созвоне 45 минут: около 15-20 рублей на Claude API за полное резюме плюс подсказки в процессе. При 3-4 звонках в неделю — 200-300 рублей в месяц.

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

Баг в боте-модераторе: формула «× 30» и почему логические ошибки не ловятся тестами

Бот-модератор проверял объявления об аренде на соответствие ценовым критериям перед публикацией. Логика простая на бумаге: если суточная цена объявления выходит за допустимый диапазон — объявление помечается как неподходящее и не публикуется. На практике бот обрабатывал два типа объявлений: с суточной ценой и с месячной ценой. Для сравнения нужно было приводить к одному знаменателю.

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

Результат: объявление с суточной ценой 500 000 рублей проходило модерацию как «в норме», потому что 500 000 × 30 = 15 000 000, и это число укладывалось в допустимый диапазон месячных цен (10-20 млн). Дорогие объявления, которые бот должен был блокировать, проходили без ограничений.

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

Исправление в два шага: добавить явный флаг типа цены в структуру объявления (price_type: 'daily' | 'monthly'), не угадывать из контекста. И написать набор acceptance-тестов с реальными кейсами из продакшена — 15 примеров объявлений разных типов с ожидаемым статусом модерации. Такие тесты поймали бы этот баг до выхода в прод.

Урок для систем с автоматической классификацией

Баги типа «неверная бизнес-логика при технически правильном коде» — самые трудноловимые именно потому, что все инструменты качества говорят «всё хорошо». Код работает. Тесты зелёные. Coverage 90%. Система молча делает не то. Единственная устойчивая защита — регулярный аудит выходных данных на здравый смысл. В случае с модератором: еженедельная выборка из 30 объявлений, которые прошли и не прошли проверку, с ручной верификацией правильности решения. Если всё хорошо — 15 минут. Если плохо — находишь баг до того, как он стал проблемой для пользователей.

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

Как выглядит рабочий день без команды: 10 задач за 8 часов

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

Структура 12 июня выглядела так:

• 08:30 — дайджест от AI-агента: что произошло за ночь, какие алерты, новые входящие сообщения. Читается за 5 минут.
• 09:00 — диагностика и исправление источника данных для инвесторов (30 минут кода, 3 часа диагностики накануне вечером)
• 09:45 — восстановление займа партнёра из переписки (2 часа: экспорт, парсинг, верификация, скрипт пересчёта, деплой cron)
• 12:00 — отладка бота-модератора (1.5 часа: воспроизвести баг, найти причину, исправить, написать 15 acceptance-тестов)
• 14:00 — первый боевой созвон с новым Mac-приложением (45 минут)
• 15:00 — доработка приложения по итогам первого живого теста: скорректировать промпт для подсказок, добавить горячую клавишу паузы (1 час)
• 16:30 — 5 мелких задач: обновить /llms.txt, поправить schema.org на одной странице, запустить Cloudflare CF purge, проверить мониторинг, ответить на DM в Telegram

Без автоматизации ровно те же 10 задач потребовали бы команду. Отдельный человек для коммуникации с инвесторами и обновления их дашбордов. Финансовый аналитик для займа и расчётов. Разработчик для бага в боте. Ассистент для документации звонков. Это 3-4 человека с зарплатами от 100 000 до 200 000 рублей каждый в месяц. Автоматизация не заменяет людей полностью — но сдвигает точку, где без людей не обойтись, в сторону значительно большего масштаба бизнеса.

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

Архитектура данных для малого бизнеса: три слоя которые меняют управляемость

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

Слой 1: агрегированные финансовые таблицы с явными источниками

Не читать данные из сырых транзакционных таблиц для построения любого дашборда или отчёта. Всегда иметь промежуточный слой агрегации: месячный P&L по продукту, объекту, клиенту, направлению. В этом слое — все расчёты, корректировки, вычисления. Дашборды только читают оттуда.

Это защищает от ситуации «инвестор видит 0» — потому что есть одна таблица-истина, все отчёты смотрят в неё, любое изменение источника меняет поведение сразу везде. Инструменты: PostgreSQL + Python-скрипты для агрегации + cron. Для малого бизнеса с несколькими объектами или продуктами этого достаточно без dbt или сложного data warehouse.

Слой 2: автоматические отчёты с принципом «push, не pull»

Каждый регулярный отчёт — еженедельный для команды, ежемесячный для инвесторов, квартальный для партнёров — должен приходить сам, а не ждать когда его запросят. Инвестор не должен писать «а где мои цифры» — должен получать их 1-го числа в Telegram.

Это изменяет отношения с получателями данных. Когда отчёт приходит автоматически — ты управляешь ожиданиями и темпом коммуникации. Когда его нужно запрашивать — получатель чувствует, что данные скрываются или система ненадёжна. Инструменты: cron + Telegram Bot API + шаблонизатор на Python. Написать один раз, настроить расписание, забыть.

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

Переписка, договоры в PDF, звонки, голосовые заметки — огромный массив данных, который обычно «живёт в голове» или в чатах и не используется для принятия решений. Claude API позволяет структурировать этот слой с минимальным кодом: извлечь транзакции из переписки за год, превратить запись звонка в список задач и договорённостей, найти паттерны в 50 клиентских диалогах.

Стоимость: Claude Sonnet API при 10-15 запросах в день объёмом до 5 000 токенов — около 1 500-2 000 рублей в месяц. Это меньше, чем один час работы ассистента. Для большинства задач малого бизнеса — достаточно.

Что взять из этого кейса

Несколько конкретных вещей, применимых прямо сейчас:

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

Если у вас есть финансовые договорённости в мессенджерах: Потратьте один день на структуризацию. Экспорт Telegram → Claude для парсинга транзакций → верификация с банком → автоматический ежемесячный пересчёт в cron. Весь цикл — 4-8 часов один раз. Сэкономит несколько часов в месяц и устранит потенциальные споры о суммах.

Если вы проводите 3+ созвона в неделю: Whisper локально + Claude API для резюме звонков окупается за первую неделю. 200-300 рублей в месяц на API вместо 2-3 часов ручной документации. Бонус: подсказки вопросов в реальном времени меняют качество диалога, а не только экономят время после.

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

Все описанные системы — промпты для парсинга переписки, скрипт пересчёта займов с cron, архитектура Mac-приложения для звонков, шаблоны cron-отчётов для инвесторов — работают у меня в продакшене прямо сейчас. Полный набор артефактов, обновления по мере появления новых задач — в клубе «Solar — внутрянка». Ниже — ссылка.

Подробный разбор финансовой архитектуры для малого бизнеса — в статье «Как автоматизировать финансовый учёт: с чего начать».

— Solar OS.