Это личный инженерный эксперимент, а не медицинский инструмент. Система помогает фиксировать наблюдения и готовить вопросы специалисту, но не ставит диагнозы и не заменяет врача или психолога.
Личные примеры в статье основаны на моих наблюдениях, но отдельные формулировки и детали я обобщил, чтобы не публиковать дневник дословно.
Через четыре месяца ежедневных записей я попросил агента проанализировать прошедший месяц. Ответ выглядел убедительно: связный текст, аккуратные формулировки, похожие на настоящие выводы.
Проблема была в том, что агент не прочитал большую часть моих записей. Файлы лежали рядом, на том же диске, но в анализ попали лишь случайные фрагменты. Остальное модель достроила сама, и сделала это так гладко, что я почти ничего не заметил.
Именно тогда я понял главное: в персональном дневнике память и доступ к данным важнее самой модели. Можно взять самую сильную LLM, но если она не прочитала источник, её выводам нельзя доверять.
А до этого вечера система работала так. В 21:00 телефон коротко вибрирует. Бот спрашивает, как я спал, сколько было энергии, что происходило на работе, была ли тренировка и что сильнее всего повлияло на день.
Я не открываю отдельное приложение и не двигаю слайдеры. Зажимаю кнопку записи в Telegram и секунд сорок говорю как есть:
Спал около семи часов. Утром была силовая, но после обеда энергия резко упала. На работе два релиза, поесть нормально не успел. Настроение в целом нормальное, раздражительность выше обычного.
На полке в другой комнате старый ноутбук распознаёт речь и передаёт текст агенту. Тот сохраняет исходник, заполняет служебные поля, делает коммит и присылает короткую сводку. Если не хватает важного, задаёт один вопрос.
Так я впервые продержался с дневником не три дня и не три недели, а несколько месяцев.
Сначала мне казалось, что я строю ещё одного AI-ассистента. В итоге оказалось, что я решаю две более прозаичные задачи:
Сделать ежедневную запись настолько простой, чтобы её было легче сделать, чем отложить;
Хранить историю так, чтобы любой вывод можно было проверить по исходным записям.
Дальше расскажу, как старый Xiaomi Mi Gaming Laptop стал домашним AI-сервером, что в итоге заработало и почему даже сильная модель начинает додумывать факты, если не дать ей нужные записи.
Если коротко, вот цифры за четыре месяца:
Срок использования | 4 месяца, ~120 дневных записей |
|---|---|
Непрерывный uptime | 35 дней без перезапуска |
Стоимость мая | $1.91 (период экспериментов с моделями) |
Первые 13 дней июня | $0.44 на flash-модели |
Скорость распознавания | 22 секунды аудио → 2,17 секунды транскрипции |
Железо | GTX 1060 6 GB, 16 GB RAM, Ubuntu 24.04 |
Но самым неожиданным результатом оказались не стоимость и не железо. Самой сложной задачей оказалось заставить модель читать нужные записи.
Почему все мои предыдущие дневники умирали
Я пробовал бумажные блокноты, заметки в телефоне, Notion и приложения-трекеры. Сценарий всегда был одинаковым.
Первые дни интересно. Потом однажды нет сил заполнять форму. На следующий день возникает долг уже за два дня. Через неделю дневник начинает напоминать не об осознанности, а о невыполненной обязанности.
Проблема была не в отсутствии нужных полей. Наоборот, полей всегда было слишком много. Между мыслью «сегодня я почему-то выжат» и сохранённым наблюдением стояли приложение, форма, категории, шкалы и необходимость писать связный текст.
Telegram уже открыт у меня десятки раз в день. Голосовое не требует формулировать идеальную запись. Поэтому главный интерфейс моей системы — не дашборд и не чат с красивым аватаром, а обычная кнопка записи.
Через месяц интерес к новой игрушке прошёл. Остался короткий ритуал: напоминание, сорок секунд речи, подтверждение. Именно тогда я понял, что дневник прижился.
Старый игровой ноутбук получил вторую работу
В 2019 году я купил Xiaomi Mi Gaming Laptop. Внутри:
Компонент | Конфигурация |
|---|---|
CPU | Intel Core i7-8750H, 6 ядер / 12 потоков |
GPU | GTX 1060 Mobile, 6 GB VRAM |
RAM | 16 GB |
OS | Ubuntu 24.04 LTS |
С 2021 года я почти перестал играть, и несколько лет ноутбук стоял без дела. В начале 2026 года я решил не покупать отдельный сервер под очередной AI-эксперимент, а использовать то, что уже есть.
Забавно, что самая дорогая часть этой системы несколько лет пылилась на полке. Я ожидал, что главным ограничением окажется GTX 1060. В итоге самым сложным оказался не GPU, а доступ модели к нужным данным.
Для домашнего сервера игровой ноутбук оказался неожиданно удобным: работает достаточно тихо для домашнего офиса, батарея переживает короткие отключения питания, а старая видеокарта всё ещё хорошо ускоряет распознавание речи. Полноценным ИБП это не считается: батарея не защищает роутер и не заменяет контролируемое завершение работы.
Первую версию я строил на OpenClaw, но платформа оказалась шире, чем мне нужно: я использовал небольшую её часть, а настраивать приходилось систему целиком. Следующую версию собрал на Hermes Agent от Nous Research — открытом фреймворке, который принимает сообщения, вызывает модели и запускает инструменты. Не путайте его с семейством моделей Hermes-3 той же компании.
Оказалось, что одной модели недостаточно
В системе нет одной модели, которая делает всё. Задачи разделены:
Telegram (доступ только по allowlist)
|
v
Hermes Gateway на Ubuntu
|-- faster-whisper: локальное распознавание речи
|-- DeepSeek: приводит текст к единому формату
|-- vision-модель: разбирает скриншоты
|-- journal skill: создаёт и обновляет записи
|-- reflection skill: готовит сводки
`-- расписание: напоминает в 21:00
|
v
Markdown vault
|-- Obsidian для чтения и графиков
`-- Git -> приватный репозиторий
Hermes связывает все части между собой. Голос распознаёт Whisper, текст приводит к единому формату недорогая модель DeepSeek через API, картинки разбирает отдельная vision-модель, а окончательная версия истории хранится в файлах. Отдельного HTTP-сервиса между Hermes и Whisper нет: faster-whisper установлен как voice-зависимость в Python-окружение Hermes и вызывается самим gateway. Голосовое проходит через Telegram, но распознаётся уже на ноутбуке и не уходит ещё одному облачному сервису.
Проверенная на 7 июня 2026 года конфигурация распознавания:
faster-whisper 1.2.1;модель
medium(multilingual);CUDA 12.2;
compute_type: int8_float32;GTX 1060 с 6 GB VRAM.
Одно тестовое голосовое длительностью 22 секунды распозналось за 2,17 секунды, то есть примерно в десять раз быстрее реального времени. Это не полноценный тест производительности: результат зависит от аудио, языка и нагрузки на ноутбук. Для дневника мне было важнее другое: ждать приходится несколько секунд, а не минуту.
GPU при этом не обязателен. Faster Whisper работает и на CPU, только медленнее. Смысл моей конфигурации не в том, что всем нужна GTX 1060, а в том, что старое железо может закрыть конкретную локальную задачу. Пытаться разместить на 6 GB VRAM качественную большую LLM я не стал.
На ту же дату процесс Hermes работал без перезапуска 35 дней, занимал около 5,7 ГБ памяти и накопил 6 часов 27 минут процессорного времени. Это просто замер на конкретную дату, но его достаточно, чтобы понять: для такой нагрузки старого ноутбука хватает.
Запись должна пережить модель
Каждый день хранится в обычном файле:
wellbeing-journal/
daily/
2026/
06/
2026-06-07.md
weekly/
reflections/
attachments/
_system/
scales.md
schema.md
Пример служебных полей в начале файла, или YAML frontmatter:
---
date: 2026-06-07
sleep_hours: 7
energy: 4
mood: 4
stress: 2
tags: [work, strength-training, poor-sleep]
needs_review: false
---
Ниже находятся аккуратная сводка и отдельный раздел Raw с исходным текстом. Исходник нельзя заменять пересказом модели: анализ можно сделать заново, а потерянный текст уже не восстановить.
Повторное сообщение за тот же день обновляет файл с этой датой, а не создаёт 2026-06-07-final-2.md. Перед коммитом программа проверяет структуру записи. Данные из скриншотов получают пометки source: ocr и needs_review: true: их нужно подтвердить вручную.
Шкалы настроения, энергии и стресса описаны в _system/scales.md. Без якорей моя сегодняшняя «энергия 4» и «энергия 4» через месяц могут означать разные состояния. Система не должна угадывать значение по тону, если я назвал его сам.
Git здесь хранит историю исправлений и служит резервной копией. Если Whisper неправильно распознал упражнение, я могу открыть исходную расшифровку и увидеть, когда появилась правка.
Если завтра я заменю Hermes или DeepSeek, сами записи останутся обычными Markdown-файлами. Для меня в этом и состоит их долговечность: данные не зависят от памяти одной модели или формата одного сервиса.
Где проходят границы приватности
Приватный репозиторий GitHub — это ограничение доступа, а не сквозное шифрование. Telegram видит сообщения, DeepSeek получает отправленный ему текст, модель для изображений видит картинки, а GitHub хранит копию дневника. Поэтому называть систему полностью локальной или полностью приватной было бы неправильно.
Агент не помнит ваш архив
Вернусь к тому вечеру, с которого начал. Записей накопилось много, я попросил агента проанализировать месяц и получил связный, уверенный ответ. Модель не читала архив, но отвечала так, будто читала.
Ответ выглядел правдоподобно по понятной причине: он опирался на настоящую структуру дневника. Знакомые теги, привычные формулировки, та же интонация, что и в моих записях. Внешне это не отличалось от честного разбора. Поэтому принять его за правду было очень легко: ничто в тексте не сигнализировало, что под выводами почти нет данных.
Конкретный пример. Среди прочего агент написал: «падение энергии во второй половине месяца связано с нагрузкой на работе — спады приходятся на дни релизов». Звучало логично и совпадало с моим ощущением, поэтому я почти кивнул. Но решил проверить и открыл записи за те даты вручную. Выяснилось, что в дни с самой низкой энергией я писал про сон по пять-шесть часов, а половина этих записей вообще не попала в анализ: модель прочитала несколько файлов из начала месяца и достроила остальное. Поле sleep_hours в выводе не фигурировало ни разу. Вывод про работу был не ложным, он был построен на неполных данных: реальный сигнал про сон просто не дошёл до модели, потому что нужные файлы не были прочитаны.
Это не баг конкретной модели, а инженерная проблема. Память разговоров, история сессий и Markdown-файлы на диске — три разные вещи. Файлы лежали рядом с агентом, но это не значит, что он их прочитал. На вопрос «что происходило со мной в июне?» модель берёт случайно доступные фрагменты и достраивает пробелы — так она и устроена. Для личной истории это особенно опасно: правдоподобную генерацию легко принять за воспоминание системы.
Поэтому правило теперь жёсткое:
Любой вывод по истории должен ссылаться на конкретные прочитанные записи. Нет источника — нет вывода.
Поэтому перед месячным разбором я отдельно собираю данные:
скрипт выбирает дневные записи за нужные даты;
парсит YAML и считает покрытие метрик;
добавляет недельные сводки;
складывает всё нужное в один компактный файл;
только после этого модель ищет повторения и формулирует гипотезы.
В начале анализа я указываю период, количество прочитанных файлов и полноту данных. Например:
Период: 2026-05-01 — 2026-05-31
Прочитано daily-файлов: 27/31
Сон: данные за 24/31 дней
Энергия: данные за 27/31 дней
Тренировки: 11 записей
Фраза «средний сон — 7,2 часа» бесполезна без количества заполненных дней. Если среднее рассчитано по двум дням из тридцати, делать по нему выводы нельзя.
Пока архив небольшой, мне хватает дат, тегов, полнотекстового поиска и недельных сводок. Векторная база сама по себе не сделает ответы надёжными: всё равно придётся показывать, из каких записей взялся вывод. Семантический поиск понадобится, когда обычный перестанет находить одно и то же событие, описанное разными словами.
Что дневник действительно помог заметить
Самые полезные находки оказались не сенсационными. Я многое из этого и так «знал», но не видел повторяемость.
Первая связка: поздний сериал, короткий сон, тяжёлое утро и слабая тренировка. Один такой день ничего не доказывает. Когда одинаковая последовательность повторяется несколько раз и рядом лежат датированные записи, торговаться с собой становится сложнее.
Вторая связка оказалась неожиданнее. После приёма мелатонина мне было трудно просыпаться, и первая половина дня проходила в заторможенном состоянии. По памяти это выглядело как несколько случайных плохих утр. В журнале повторение стало заметно.
Это не медицинский вывод и не рекомендация другим. Это личная корреляция, которую можно обсудить со специалистом.
Ещё один полезный эпизод начался с фразы: «стресса не чувствую, но всё бесит». Раньше я бы записал просто «плохой день». В истории было видно другое: несколько ночей с прерывистым сном, низкая энергия, нормальная оценка стресса и высокая раздражительность.
В сводке появилась формулировка: «после недосыпа у тебя меньше терпения». Ничего нового модель не открыла. Она просто помогла разделить два состояния, которые я раньше смешивал.
Иногда месячная сводка делает обратное: не подтверждает драматичное ощущение. Плохая пятница может запомниться как «вся неделя была ужасной», хотя три предыдущих дня в записях были нормальными. Для меня это не менее ценно, чем поиск негативных паттернов.
Что ломалось и чему это научило
1. Большая платформа не обязательно лучше
Первая система на OpenClaw поддерживала гораздо больше интеграций, чем мне требовалось: в реальности нужны были один Telegram-канал, одна модель и один ежедневный сценарий. Для моего узкого сценария её возможности оказались избыточными, а чинить всё равно приходилось систему целиком. После перехода на Hermes схема стала меньше и понятнее лично мне.
2. Более крупная модель Whisper не решила мою проблему
Повторяющиеся ошибки в именах упражнений и сервисов лучше исправил небольшой словарь подтверждённых замен, чем попытка везде использовать более тяжёлую модель.
Услышано | Каноничный термин | Контекст |
|---|---|---|
“хэви” | Hevy(приложение для учета тренировок) | тренировка |
“язио” | YAZIO(приложение для учета ккал) | питание |
Замены применяются только в подходящем контексте, а исходная расшифровка сохраняется.
3. OCR нельзя считать фактом
Модель может перепутать на скриншоте 60 и 80 килограммов или потерять десятичную точку. Поэтому оригинал хранится рядом, распознанные цифры помечаются для проверки, а подтверждаю их я.
4. Пустое значение лучше выдуманного
Если я не назвал вес или длительность сна, поле остаётся пустым. Ноль испортил бы график, а догадка модели — доверие к архиву.
5. Один вопрос лучше анкеты
Если данных не хватает, бот задаёт одно компактное уточнение. Цель системы — сохранить привычку, а не добиться идеального заполнения любой ценой.
6. Автоматический коммит нужно проверять
Перед коммитом программа проверяет структуру записи и ищет случайно попавшие в неё ключи доступа. Если отправить изменения на GitHub не удалось, файл всё равно остаётся на ноутбуке.
Сколько это стоит
Вот реальные расходы на текстовую модель за два месяца. Это стоимость работы всего агента, а не только вечерних записей: сюда входят эксперименты, периодические проверки, задачи по расписанию, работа с инструментами, уточнения и месячные разборы. Поэтому дневник сам по себе стоил бы дешевле.
Май 2026: я ещё экспериментировал с моделями, поэтому основная часть запросов шла через deepseek-v4-pro. Итого за месяц — $1.91: 880 запросов к pro и 159 к flash, 30,5 миллиона учтённых токенов у pro и ещё 8,6 миллиона у flash.
Май 2026 года: период экспериментов с двумя моделями обошёлся в $1.91.
За первые 13 дней июня 2026 года я полностью перешёл на deepseek-v4-flash: 508 запросов, 26,3 миллиона токенов и $0.44 расходов. Если нагрузка останется похожей, полный месяц будет стоить примерно доллар. Понятно, что это грубый расчёт по первым 13 дням, но порядок цифр уже виден.
Первые 13 дней июня 2026 года после перехода на flash: $0.44.
Слой | Реальная стоимость |
|---|---|
faster-whisper локально | без API-платы; электричество отдельно |
Текстовый API | около $1–2/мес для всего агента при моей текущей нагрузке |
Обработка изображений | отдельный бюджет, использую несколько раз в месяц |
Git / Obsidian | $0 (приватный репозиторий на GitHub Free и локальный Obsidian) |
У другого пользователя сумма будет иной: она зависит от объёма переданного текста, выбранной модели, количества обращений к инструментам и частоты запросов.
Ежедневные записи обрабатывает недорогая модель. Более сильную можно подключать только для редкого месячного разбора. Но качество разбора всё равно зависит прежде всего от того, какие записи ему передали.
Почему я не отдал всё готовому ассистенту с памятью
Память готового ассистента и личный архив решают разные задачи. Ассистент может запоминать полезный контекст между разговорами, но мне нужны конкретные датированные записи, которые можно прочитать, проверить и перенести в другую систему.
Я не хочу зависеть от того, можно ли выгрузить внутреннюю память сервиса целиком и увидеть, что именно там сохранено. Для дневника мне важнее иметь возможность открыть записи за март и проверить ответ по исходным файлам.
Markdown-файл открывается любым редактором без учётной записи. Git-репозиторий клонируется одной командой. Схему можно изменить скриптом. Модель можно заменить, не теряя ни одной записи.
Вот что меня удивило больше всего. Я строил систему вокруг локальной LLM, GPU-ускорения и автономного агента, а самым надёжным её элементом оказалась обычная папка с текстовыми файлами по датам. Whisper можно поменять, DeepSeek заменить, Hermes переписать, ноутбук выбросить — переживёт всё это именно папка. Модели приходят и устаревают каждые несколько месяцев, а текстовый файл с датой в имени переживёт их все.
Самая надёжная технология во всей системе оказалась самой старой: обычный текстовый файл.
Что осталось после четырёх месяцев
Дневник не сделал меня автоматически здоровее и дисциплинированнее. Я всё ещё могу лечь поздно, пропустить запись или проигнорировать очевидную связь между недосыпом и тяжёлым днём.
Он сделал другое: последствия решений стали видимыми.
Из проекта я вынес несколько правил:
постоянство важнее полноты: тридцать неидеальных записей полезнее семи идеальных;
простые правила важнее умной модели: один файл на день, единая структура, пустое значение вместо догадок и ссылки на исходные записи;
сырой ввод нужно хранить отдельно от интерпретации;
корреляция в дневнике — повод наблюдать и задать вопрос, а не ставить себе диагноз;
история должна храниться в понятных файлах, которые можно проверить и перенести в другую систему.
Старый ноутбук не стал Джарвисом. Он стал внимательным интерфейсом к моим собственным записям.
Это оказалось полезнее обещаний, что AI однажды поймёт меня лучше меня самого. Пока он просто возвращает мне мои же записи и показывает, где они начинают повторяться.
Мне интересно, на каком объёме личного Markdown-архива вы бы перестали полагаться на даты, теги и обычный поиск и добавили семантический. И как при этом показывали бы, из каких записей модель сделала каждый вывод?
Дополнительные материалы
Подробную установку, месячный разбор и расчёт стоимости я вынес в серию из трёх статей, чтобы не превращать этот текст в длинный мануал.