Ситуация
К концу апреля Jarvis уже был не красивой идеей, а живой системой. Он работал с Telegram, заметками, напоминаниями, почтой, календарём и голосовыми сообщениями. Отдельные проверки показывали зелёный статус, основные процессы запускались, а значит со стороны всё выглядело вполне благополучно.
Но у меня накопилось неприятное ощущение: система работает, а доверия к ней не становится больше.
Причина была не в одном большом сбое. Наоборот, тревожили мелочи, которые возникали в разных местах и в разное время. Иногда напоминание отвечало слишком долго. Иногда в журналах оставались старые ошибки, хотя текущая проверка была зелёной. Несколько механизмов могли отвечать за похожие действия. Было всё труднее понять, где находится актуальная настройка, а где лежит след прежней версии.
Первым порывом было начать чинить то, что попадалось на глаза. Но для живого личного ИИ это опасный путь. Быстрое исправление одного симптома может задеть другой рабочий сценарий, доступ к личным данным или привычный маршрут в Telegram. Поэтому я остановил исправления и сначала провёл отдельную ревизию системы — только чтение, наблюдение и сбор фактов.
Что собрали
Я разложил Jarvis не по папкам и названиям программ, а по тому, как он живёт. Отдельно посмотрел на маршруты сообщений, расписания, доступ к внешним сервисам, память, фоновые процессы, голос, резервные сценарии и наблюдение за состоянием.
Важным правилом было ничего не менять во время проверки. Я не перезапускал сервисы, не исправлял права доступа, не чистил очереди и не заменял настройки, даже когда причина выглядела очевидной. Сначала нужно было понять всю картину и зафиксировать исходное состояние.
Так появилась карта из двенадцати слабых мест. Среди них были повторяющиеся ошибки доступа, расхождения в правилах маршрутизации, лишний шум от фоновых проверок, устаревшие диагностические следы и ситуация, когда последний зелёный статус скрывал хронические сбои в истории.
Самым полезным результатом стал не список проблем, а связи между ними. Например, медленная работа напоминаний могла выглядеть как отдельная неисправность. Но рядом обнаруживались старая очередь, другой владелец служебного файла и несколько поколений одного и того же механизма. Чинить только последнюю ошибку в журнале было бы почти бессмысленно.
Как это работает
Для такой ревизии я использовал простую последовательность.
Сначала зафиксировал фактическое состояние: что сейчас запущено, какие процессы отвечают за основные функции и где система сама объявляет источник истины. Затем составил перечень зависимостей: кто создаёт событие, кто его принимает, кто сообщает результат и где остаётся история.
После этого я сравнил три слоя:
- что система считает правильной конфигурацией;
- что реально запущено сейчас;
- какие повторяющиеся ошибки сохранились в истории.
Это сравнение оказалось важнее отдельного теста «работает или нет». Функция может сработать сегодня и всё равно оставаться ненадёжной, если два процесса борются за одну задачу, доступ зависит от случайного владельца файла, а наблюдение видит только последний успешный запуск.
Дальше каждому наблюдению я добавил четыре характеристики: насколько часто оно возникает, что может затронуть, насколько уверенно понятна причина и насколько опасно исправлять её вслепую. Благодаря этому список перестал быть свалкой ошибок и превратился в порядок действий.
В начало попали проверки, которые уменьшают риск следующих изменений: понятный снимок состояния, сверка маршрутов и отдельная диагностика доступов. Только после них — исправления. А зоны с личными данными, учётными записями и широкими правами получили прямую пометку: не трогать без отдельного плана и возможности вернуться назад.
Что изменилось
Главное изменение произошло ещё до первого исправления. Я перестал смотреть на зелёный статус как на доказательство надёжности.
Зелёный статус отвечает на узкий вопрос: «сработала ли эта проверка сейчас?» Но он не показывает, сколько раз тот же механизм падал вчера, не существует ли рядом второй владелец того же действия и не сохранился ли старый путь, который иногда перехватывает работу.
После ревизии у меня появился не набор срочных советов, а безопасная последовательность стабилизации. Сначала — наблюдение и сверка источников истины. Затем — точечные исправления с проверкой результата. После этого — упрощение расписаний и старых механизмов. И лишь в конце — изменения в самых чувствительных областях.
Это немного медленнее, чем чинить первую найденную ошибку. Зато каждое следующее действие опирается на факты и не требует угадывать, какую часть системы мы случайно заденем.
Где это полезно
Такой подход нужен не только для Jarvis. Он полезен любой личной системе, которая выросла из нескольких удачных автоматизаций в постоянного помощника.
Если ИИ уже умеет читать почту, работать с календарём, отправлять сообщения или менять данные, вопрос «он сейчас отвечает?» становится слишком простым. Гораздо важнее спросить:
- понятно ли, какой механизм отвечает за каждое действие;
- совпадает ли реальная работа с заявленными правилами;
- видны ли повторяющиеся ошибки, а не только последний результат;
- отделена ли проверка от исправления;
- известен ли порядок безопасных изменений;
- есть ли области, которые нельзя трогать без отдельного решения;
- можно ли доказать, что после исправления стало лучше, а не просто иначе.
Эти вопросы особенно важны, когда система касается личных данных. Чем ближе ИИ подходит к реальным действиям от вашего имени, тем меньше пользы от героического «быстро починил» и тем выше ценность спокойной диагностики.
Ограничения
Ревизия не заменяет исправления. Она может показать вероятную причину и правильный порядок действий, но часть выводов всё равно нужно подтверждать контролируемой проверкой после изменения.
Ещё одна опасность — превратить аудит в бесконечное описание системы. Мне было важно остановиться там, где фактов уже достаточно для решения: что проверять первым, что можно исправлять точечно, а что требует отдельной защиты.
И наконец, не каждую старую ошибку нужно немедленно устранять. Если механизм больше не участвует в работе, иногда правильнее сначала доказать это, а затем аккуратно убрать его, чем оживлять старую часть системы только ради чистого журнала.
Итог
Я начинал эту ревизию с простого сомнения: почему Jarvis работает, а уверенности в нём всё равно не хватает. Ответ оказался не в одном сломанном компоненте. Надёжность терялась между текущим состоянием, историей сбоев, несколькими источниками истины и слишком быстрым желанием что-нибудь исправить.
Поэтому теперь перед серьёзной стабилизацией я разделяю два шага. Сначала получаю честную карту системы без изменений. Затем исправляю проблемы в порядке, который уменьшает риск следующего шага.
Для личного ИИ это один из главных признаков зрелости: он должен не только работать сегодня, но и позволять понять, почему ему можно доверять завтра.