После нескольких дней расследования я перезагрузил компьютер и получил нужный результат: все восемь отслеживаемых устройств присутствовали в системе без ошибок. Распознавание лица и считыватель отпечатка снова работали — это я проверил сам. Но до этого были неудачные установки Windows, временные улучшения и гипотезы, которые звучали убедительнее, чем позволяли журналы.
Я разбирался с проблемой вместе с ChatGPT и Grok. Постепенно стало понятно: полезен не только ответ модели, но и организация работы вокруг него. Пришлось сохранять исходные данные, разделять вопросы между агентами, проверять выводы и решать, какие изменения вообще допустимы на моём компьютере.
В этой статье я рассказываю о своём опыте: что помогло восстановить функции и что я изменил бы в следующем расследовании. Это история одного ремонта, а не готовый рецепт для любого похожего сбоя.
Что перестало работать и чего я хотел добиться
В начале расследования семь устройств показывали Code 31 — Windows сообщала, что не может загрузить необходимые драйверы. Среди затронутых направлений были биометрия, устройства ввода и системные устройства. Позднее набор проблемных устройств менялся. В финале мы проверяли восемь конкретных устройств, поэтому исходные семь и финальные восемь нельзя считать одной неизменной группой.
Моя цель была практической: вернуть обычные функции ноутбука, сохранив файлы и установленные программы. Я не специалист по внутреннему устройству Windows. Мне нужен был процесс, в котором можно понять смысл следующего действия и его риск, даже если самостоятельно разобрать установочный журнал я не могу.
Одинаковый код ошибки подталкивал искать общую причину. Однако он сам по себе её не доказывал. За похожими сообщениями могли стоять разные проблемы: пакет драйвера, доступ к системному объекту или состояние отдельного устройства. Поэтому вопрос «как исправить Windows» постепенно пришлось заменить несколькими более узкими вопросами.
Я также разделил два результата, которые легко смешать: завершение ремонтной установки и восстановление устройств. Установка могла пройти успешно, а нужная функция — остаться неработающей. Для завершения основной задачи мне требовались и нормальное состояние выбранных устройств после перезагрузки, и проверка функций руками. Такой критерий оказался полезнее общего сообщения «всё исправлено».
Как я организовал работу ChatGPT и Grok
ChatGPT был основным местом постановки задач и сведения результатов. Grok работал над той же проблемой; его материалы позже вошли в общую историю. Я оставался владельцем задачи: задавал цель, предоставлял журналы, уточнял ограничения и принимал решения о вмешательствах в систему.
Когда материалов стало много, одного большого разговора оказалось недостаточно. Я разделял работу по вопросам. Один участник разбирал неудачные установки, другой — состояние устройств, третий проверял условия предложенного эксперимента. Отдельная роль была у критика: искать слабое место в объяснении и основания, по которым следующий шаг может не дать ответа.
Такое разделение помогает, только если задания действительно различаются. Несколько агентов, пересказывающих одну сводку, могут одновременно прийти к одинаковому ошибочному выводу. Поэтому я стал больше ценить ответы, в которых появлялась конкретная строка журнала, новое противоречие или проверяемое условие, чем ответы с большим количеством уверенных рекомендаций.
Для передачи задачи полезен короткий набор: что мы хотим выяснить, какие действия допустимы, где лежат источники, что уже наблюдали и какой вопрос остался открытым. Получатель должен понимать и предел прежнего вывода. Например, фраза «установка завершилась» не означает, что после неё заработала биометрия.
Ответ агента я тоже начал читать по этой логике. Где находится основание вывода? Относится ли оно к нужной попытке? Что действительно проверено, а что предлагается проверить? Если два ответа расходились, следующим полезным действием часто была сверка одного события, а не ещё одно широкое исследование.
На схеме ниже показаны роли и передача результатов, а отдельно — найденные сведения о запусках Grok. Это разные уровни описания. Предусмотренная роль ещё не доказывает отдельный запуск агента. Для меня главное в этой организации — возможность проверить путь от источника до решения, которое касается моего компьютера.
Почему расследованию понадобилась собственная память
В длинной переписке легко потерять важную оговорку. Сначала появляется подробное наблюдение, затем его короткий пересказ. Через несколько передач остаётся только «эту гипотезу проверили». Уже непонятно, что именно проверяли, удалось ли выполнить условие и к какой попытке относится результат.
Поэтому проектная папка стала внешней памятью расследования. В ней хранились исходные журналы, снимки состояния, отчёты и планы. Карта проекта помогала найти нужный материал. Реестр сбоев связывал наблюдения с конкретными операциями и попытками. Датированный статус показывал, где мы находимся сейчас.
Эти документы выполняли разные задачи. Сводка помогала ориентироваться, но основанием вывода оставался первичный журнал. Если в реестре уже было объяснение ошибки, его всё равно нужно было проверить по указанному источнику и условиям. Иначе старое предположение могло незаметно стать правилом для новой ситуации.
Особенно важно оказалось записывать результаты неудобных проверок. «Не помогло» — слишком коротко. Действие могло не изменить нужное условие, наблюдение могло закончиться раньше отказа, а временное улучшение — исчезнуть после отката. Такие записи нужны следующему участнику, чтобы он не повторял прежний опыт под новым названием.
При передаче контекста я хотел сохранять простую цепочку: наблюдение, версия объяснения, проверка, результат и следующий вопрос. Если новое наблюдение противоречит версии, обновляется версия, а не история задним числом. Схема ниже показывает этот процесс и места, где пересказ может оторваться от исходного события.
В итоге папка помогала не только помнить больше, но и ограничивать повторную работу. Новый агент мог найти уже разобранный вопрос. Я мог проверить, почему мы отказались от прежней идеи. А подготовка статьи стала возможной без необходимости восстанавливать всю историю исключительно по памяти участников.
У этой памяти есть цена: её тоже нужно поддерживать. После нового результата старая сводка может перестать описывать текущее состояние, хотя каждое предложение в ней когда-то было верным. Поэтому дата и принадлежность к попытке важны не меньше самого вывода. Я бы не требовал перечитывать всю папку перед каждым вопросом. Лучше дать участнику актуальную навигацию и точные источники для его задачи, сохранив возможность проверить более ранние версии. Тогда объём накопленных материалов помогает, а не мешает продолжению работы.
Где мы застряли и что изменило ход работы
В истории были два связанных направления: ремонтная установка Windows и восстановление устройств. Они влияли на общий ход работы, но успешное продвижение в одном не гарантировало успеха в другом. Временная шкала ниже помогает увидеть эту последовательность без подробного перечисления команд и каждой строки журнала.
Первый показательный эпизод связан с проверкой подозреваемого фильтра. Мы хотели понять, не мешает ли определённый компонент установке. Но в одной из ранних попыток наблюдение закончилось до нужного момента копирования файла. Такая попытка не могла опровергнуть гипотезу: интересующее событие просто не попало в наблюдение.
В другой попытке отказ копирования сохранился при отсутствии установленного подозреваемого фильтра. Это уже ослабляло узкую версию, что сбой возникает только из-за его загрузки. Разница кажется небольшой, но для следующего решения она существенна: отсутствие ответа и свидетельство против версии — разные результаты.
Разбор установок также показал, что отказы доступа встречались в разных операциях. Один эпизод относился к копированию файла, другой — к изменению состояния установщика при подготовке отката. Объединить их в одну доказанную причину только по похожему сообщению было нельзя. Пришлось сохранять отдельные истории попыток.
Позже ремонтная установка завершилась после изменения прав доступа для системной учётной записи. Это было важным продвижением, но ошибки устройств остались. Здесь особенно пригодился исходный критерий завершения: сообщение об успешной установке ещё не позволяло закрыть весь ремонт.
Второй эпизод был более точным. В трассе выбранного датчика обнаружился отказ доступа при обращении к корню системного диска. Рядом по времени фиксировалась ошибка запуска устройства. Вместо общего предположения «что-то с правами» появился конкретный запрос, который можно было связать с проверкой.
После временного изменения доступа для Local Service и перезапуска выбранного устройства интересующий запрос завершился успешно, а ошибка запуска в этом тесте исчезла. Затем исходные права восстановили; позднее Code 31 вернулся. Такая последовательность дала более сильное основание связывать доступ с этим конкретным отказом.
Следующие действия были адресными: для выбранного устройства сохранили согласованное изменение доступа, другие проблемы разбирали отдельно. В конце потребовалась перезагрузка и повторная проверка. Дерево гипотез ниже сохраняет различия между подтверждённым локальным эффектом, ослабленной версией и вопросами, для которых ещё нет достаточного ответа.
Для меня эти эпизоды изменили представление о полезном ходе расследования. Продвижение — это не обязательно ещё одна попытка ремонта. Иногда оно состоит в том, что широкая версия стала уже: теперь известно, при какой операции возник отказ и какое условие влияет на него. Иногда нужно признать, что опыт не ответил на вопрос. Такое признание сохраняет время следующих участников и не позволяет построить дальнейший план на результате, которого у нас фактически нет.
Как я ограничивал риск следующих действий
Журнал может подсказать направление, но он не выдаёт разрешение менять систему. Я отделял анализ от вмешательства: чтение материалов и подготовка отчётов могли продолжаться, а для изменения прав, установки или другого системного действия нужен был понятный план и моё решение.
План должен объяснять, что изменится, зачем это нужно, как будет проверен эффект и как вернуть исходное состояние. Для меня это был способ сделать предложение агента обозримым. Без таких пунктов трудно отличить диагностический тест от ремонта и понять, какой результат оправдает продолжение работы.
В расследовании использовался premortem — разбор плана так, будто он уже закончился неудачей. По-русски его смысл можно передать просто: заранее выяснить, почему следующий шаг может сорваться. Это помогает увидеть проблему до выполнения, когда ещё можно изменить план или условия проверки.
Например, установка может закончиться откатом, а нужный журнал окажется перезаписан. Наблюдение может начаться слишком поздно. Изменение сразу нескольких условий может дать улучшение, но лишить нас возможности понять, какое из них повлияло. Критик должен обнаружить такие слабые места до того, как результат начнут интерпретировать.
Условия остановки тоже нужны заранее. Если нужное событие не записано, нельзя считать проверку завершённой. Если эффект оказался временным, его нельзя описывать как устойчивое исправление. Если вместо узкого теста предлагается всё более широкое вмешательство, план требует нового решения, а не автоматического продолжения по инерции.
При этом контроль не означал остановку всей работы после каждого сомнения. Можно было сохранять материалы, уточнять хронологию и проверять противоречия, пока системное действие ожидало решения. Я хотел удерживать риск конкретного шага, сохраняя возможность двигаться в анализе.
Из этого опыта я вынес простое правило: чем серьёзнее изменение, тем яснее должен быть ожидаемый результат. Команда, которую агент умеет написать, ещё не становится разумным следующим действием. Нужна связь с наблюдением и понятный способ проверить, что произошло после её выполнения.
Особенно внимательно я относился бы к предложению исправить сразу всё. Когда меняются несколько условий, успешный результат ещё не показывает вклад каждого из них. Это не запрещает комплексный ремонт, если именно он нужен владельцу. Но цель такого шага следует назвать заранее: восстановить работоспособность или проверить конкретное объяснение. От этого зависит и последующая запись. В первом случае можно честно сообщить о результате всей последовательности; во втором нужен опыт, который действительно позволяет отличить одну версию от другой.
Чем закончился ремонт
Перед финальной перезагрузкой в контрольном наборе оставались четыре устройства с ошибками и четыре без ошибок. После перезагрузки все восемь присутствовали и показывали Code 0. Смена загрузки была подтверждена отдельно, поэтому это был действительно новый контроль после перезапуска системы.
Затем я проверил то, ради чего в том числе начинал работу: распознавание лица и считыватель отпечатка. Обе функции заработали. Для владельца компьютера это важное дополнение к состоянию диспетчера устройств. Статус без ошибки полезен, но сам по себе не заменяет проверку привычного действия.
Во время ремонтной установки мы также проверяли сохранность данных и программ. Совпали хеши 12 выбранных файлов из Documents; сохранились все 174 записи приложений в проверяемом наборе реестра. Это конкретные проверки сохранения, а не утверждение, что испытаны все файлы и функции каждой программы.
Основную задачу я счёл решённой по восстановленным функциям и финальному состоянию выбранных устройств. Однако единую первопричину всех установочных отказов и ошибок устройств мы не доказали. Осталось неизвестным и происхождение исходного состояния прав доступа. Локальная проверка показала влияние доступа на конкретный отказ, но не объяснила всю историю системы.
Перезагрузка была частью последовательности после нескольких действий. Приписывать ей одной весь результат было бы слишком сильным выводом. Поэтому для статьи я сохраняю две отдельные формулировки: нужные функции восстановлены; полное причинное объяснение осталось незавершённым. Дальнейшее исследование этой причины — уже отдельная цель, а не обязательное условие пользоваться исправленным компьютером.
Сколько работы удалось посчитать
При подготовке статьи захотелось понять масштаб работы: сколько было агентов, вызовов, токенов и расходов. Ответ получился частичным. Сохранённые отчёты описывают ход расследования, но по их числу или размеру папки нельзя восстановить полный расход модели.
В материалах Grok нашлись сведения о 25 дочерних запусках: 23 завершились, два были отменены. По времени жизни таких запусков максимум пять пересекались. Это показатель перекрытия записанных интервалов, а не доказательство пяти одновременных обращений к модели и не полный максимум всего проекта.
Отдельный исторический счётчик Grok за 25–27 сентября содержит 118 сохранённых ходов и 825 вызовов модели. В нём учтено 172 880 176 токенов: 172 063 857 входных и 816 319 выходных. Значительная часть входа отмечена как кэшированная; это учитывается внутри входного объёма и не прибавляется к общему числу ещё раз.
В том же счётчике есть стоимость, которая после перевода его единиц составляет примерно 66,79 доллара. Я описываю её именно как значение сохранённого счётчика. Это не подтверждённая сумма оплаты всего ремонта и не расчёт по публичному тарифу для аналогичной работы.
Есть существенные пробелы: отсутствует полный учёт ChatGPT и части более поздней работы, а включение дочерних запусков в родительский счётчик не установлено. Поэтому суммировать эти данные между собой или объявлять стоимость всего проекта нельзя. Дашборд ниже показывает измеренные величины вместе с границами их покрытия.
Для следующего проекта полезнее начать учёт заранее: сохранять период, модель, источник счётчика и связь родительских и дочерних запусков. Большое число токенов само по себе не говорит ни о качестве анализа, ни о количестве новых знаний. Оценивать пользу работы всё равно приходится по тому, какой вопрос она помогла разрешить.
Что я сделал бы иначе в следующий раз
Я снова использовал бы ИИ для разбора сложной технической проблемы. Но раньше организовал бы работу вокруг нескольких простых правил. Их ценность для меня в том, что они помогают управлять расследованием без необходимости самому стать специалистом по каждому компоненту Windows.
Сразу записал бы критерий завершения. Какие функции должны работать? Какое состояние проверяем после перезагрузки? Что нужно сохранить? Тогда промежуточный успех не заменит пользовательскую цель, а дополнительные исследования не будут бесконечно отодвигать момент, когда основной ремонт уже закончен.
Раньше создал бы карту источников и короткий журнал решений. Для каждого значимого шага достаточно сохранить вопрос, основание, действие и результат. Хорошая запись должна позволять другому участнику найти исходное событие, а мне — понять, почему мы выбрали этот шаг и что он изменил.
Давал бы агентам более узкие задания. Например, найти первое место конкретного отказа в определённой попытке, проверить условия одного теста или найти противоречие в предложенном объяснении. Такой результат проще проверить и передать дальше, чем очередной общий обзор всех возможных причин.
Раньше подключал бы критика к плану. Особенно перед шагами, которые меняют систему или затрудняют откат. Полезно заранее спросить, что эксперимент действительно различает, успеет ли наблюдение поймать нужный момент и какой результат заставит нас отказаться от версии.
Не объединял бы похожие ошибки без связи между событиями. Одинаковый код не делает отказы в разных операциях одной причиной. Общая версия может оставаться рабочей гипотезой, но отдельные попытки и источники нужно сохранять до появления доказательства, которое их связывает.
Считал бы устойчивый результат отдельно от временного эффекта. Улучшение после узкого изменения полезно для понимания, но нуждается в проверке после отката или перезагрузки — в зависимости от цели опыта. А восстановленную функцию стоит испытать руками, даже если системный статус уже выглядит нормально.
Вёл бы расход с начала работы. Для этого нужны исходные счётчики и понятные границы учёта. Попытка восстановить стоимость потом по количеству файлов или ответов даёт видимость точности. Лучше иметь неполную, но честно обозначенную цифру, чем красивую сумму с неизвестным происхождением.
Эти правила можно перенести и на задачу меньшего размера. Я начал бы с короткой записи о симптоме и нужном результате, затем попросил бы агента предложить следующую проверку с объяснением её смысла. После выполнения сохранил бы наблюдение и сверил его с ожиданием. Если вопрос остаётся открытым, следующему участнику передаётся именно этот вопрос вместе с источником. Такой порядок не требует большой команды с самого начала и даёт основу для расширения работы, когда материалов действительно становится больше.
В этом ремонте ChatGPT и Grok помогли читать большой объём материалов, формулировать проверки и сопоставлять результаты. На мне оставались цель, ограничения, решения о допустимом риске и проверка работы ноутбука. Именно такая организация оказалась для меня полезной: каждый следующий шаг должен был опираться на наблюдение и давать результат, который можно проверить.
