Коротко
Почему пересказ ошибки ломает починку?
Типичный диалог, который я вижу на обучениях, выглядит так. Человек пишет агенту: не работает, выдаёт ошибку. Агент отвечает предположением. Человек пробует, снова не работает. И так по кругу минут сорок.
Причина в потере информации. Сообщение об ошибке содержит три слоя: что именно не получилось, в каком месте и на каком шаге. При пересказе выживает только первый, да и тот в размытом виде.
Сравни две формулировки.
Пересказ: «Он говорит, что не может открыть файл».
Оригинал: сообщение, в котором названы конкретный файл, тип отказа и место, где всё оборвалось. Второе агент читает как адрес, первое - как жалобу.
Аналогия из бизнеса. Это как разница между «клиент недоволен» и записью разговора. По первому можно построить десять гипотез, по второму - принять решение.
Что именно копировать в чат?
Правило, которое я даю ученикам, сознательно тупое: выдели последние строки и вставь как есть.
Почему именно так:
- Причина чаще в конце. Верх сообщения показывает, где всё оборвалось, низ - почему.
- Служебные строки нужны. Пути к файлам, номера строк, названия компонентов - это адрес поломки.
- Форматирование значимо. Отступы и порядок строк показывают, что откуда вызвано.
- Лишнее агенту не мешает. Он читает быстро и отбрасывает шум сам, а вот дописать выброшенное не может.
Бывает, что вывод на сотни строк. Тогда берётся конец: последние тридцать строк плюс первая строка с названием ошибки. Этого хватает в подавляющем большинстве случаев, а если не хватит, агент попросит остальное.
Отдельно про скриншоты. Картинка работает, если текст на ней читается целиком. Но копировать текстом надёжнее: агент не ошибётся в символе, а ты не обрежешь нужную строку.
Секреты, которые уезжают вместе с ошибкой
Об этом почти никто не думает, а зря. Сообщение об ошибке часто печатает то, с чем работала программа, включая содержимое настроек.
Как выглядит опасное место: длинная строка из случайных букв и цифр, иногда с адресом сервера внутри. Это и есть ключ.
Что делать перед вставкой:
Пробеги текст глазами
Ищи длинные бессмысленные последовательности символов и адреса с логином и паролем внутри.
Замени их на слово СЕКРЕТ
Именно заменить, а не удалить: агенту важно видеть, что там что-то было, а что именно, ему знать незачем.
Проверь адреса подключения
Строки вида «имя пользователя, пароль, адрес базы» маскируются целиком.
Вставляй
Смысл сообщения сохранён, ключ остался у тебя.
Если ключ всё-таки уехал в переписку, лечение одно: отозвать его и выпустить новый. Про то, почему ИИ-агенту вообще запрещают читать файл с настройками, я разбирал в материале про доступ агента к почте и серверу.
Как описать, что происходило перед ошибкой?
Текст ошибки говорит, что сломалось. Он не говорит, что ты пытался сделать, а без этого агент чинит не ту задачу.
Шаблон, который стоит выучить наизусть:
- Что делал. «Нажал кнопку отправки формы на странице заявок».
- Что ожидал. «Заявка сохраняется, появляется сообщение об успехе».
- Что получил. «Страница перезагрузилась, заявки нет, в консоли такая ошибка».
Плюс два уточнения, которые решают половину случаев:
- Когда это началось. «Работало вчера, сегодня нет» - сильнейший сигнал: значит, дело в последнем изменении.
- Воспроизводится ли. «Каждый раз» и «иногда» - это разные диагнозы. Второе почти всегда про связь, лимиты или гонку.
Мой рабочий приём: перед тем как писать агенту, я формулирую эти три строки вслух. Треть проблем к концу третьей строки решается без него: становится видно, что я сам делал не то.
Про формулировки задач в целом есть отдельный разбор - канон промпта для агента.
Три типа сообщений и что они значат
| Тип | Как выглядит | Что делать | Чего не делать |
|---|---|---|---|
| Код сломан | конкретный файл, строка, название функции | принести текст агенту, он правит | не переписывать всё заново |
| Связь оборвалась | «прервано», «превышено время ожидания» | сохранить работу, повторить, разбить задачу | не менять код, он тут ни при чём |
| Окружение не подходит | требуется версия, нет прав, нет компонента | проверить версию программы, права, обходной путь | не заставлять агента чинить чужую программу |
Второй и третий типы люди чинят как первый, и от этого ломают то, что работало.
Пример из практики. Работа с презентацией обрывается сообщением, что текущая версия программы не поддерживает нужную возможность. Никакая правка кода это не лечит: либо обновляется программа, либо берётся обходной путь через другой формат файла. Час, потраченный на «почини это», уходит впустую.
Второй пример того же класса: длинная операция обрывается на середине с сообщением о прерванном ответе. Диагноз обычно скучный - перегрузка сервиса или лимит. Лечение тоже скучное: сохранить, повторить, разбить задачу на части поменьше.
Когда починка идёт по кругу
Три сигнала, что пора остановиться и сменить подход:
Сигнал первый: правки накапливаются. После каждой попытки в проекте становится больше кода, а результат тот же. Это верный признак, что причина не найдена.
Сигнал второй: объяснения меняются. Сначала дело было в одном, потом в другом, потом в третьем. Агент перебирает гипотезы, потому что данных мало.
Сигнал третий: ты перестал понимать, что происходит. Это не твоя вина, это накопленная сложность.
Что делать:
- Откатись к последнему рабочему состоянию. Как это делается словами, разбирал в материале про откат изменений агента.
- Начни новый чат. Длинный разговор с десятью неудачными гипотезами мешает, а не помогает. Про это есть отдельный материал про гигиену контекстного окна.
- Опиши задачу заново. С нуля, тремя строками, с полным текстом ошибки.
- Попроси сначала диагноз, потом правку. «Не чини, объясни, что происходит и почему» - отдельный шаг, который экономит часы.
Что делать, если объяснение непонятно?
Отдельная беда непрограммиста: агент отвечает технически, человек не понимает, стесняется переспросить и делает наугад.
Рабочие формулировки, которые я даю на занятиях:
- «Объясни по-человечески, как для гуманитария.» Простая и на удивление рабочая.
- «Разъясни подробно, но простым языком, текст не сокращай.» Ключевое здесь - запрет сокращать. Иначе получишь короткий и такой же непонятный ответ.
- «Не понимаю твой вопрос. Предложи сам вариант на основе того, что знаешь о проекте, и объясни, почему именно такой.» Снимает тупик, когда агент спрашивает про то, о чём ты не имеешь мнения.
- «Что случится, если я ничего не буду делать?» Отделяет настоящую проблему от косметической.
Отдельно стоит помнить: непонятное объяснение - не повод соглашаться. Принимать работу, которую не понимаешь, - отдельный навык, про него есть разбор про приёмку без технического бэкграунда.
Частые вопросы
Частые вопросы
Главный вывод
Ошибка тут человеческая и понятная: сообщение выглядит страшно и хочется пересказать его понятными словами. Именно этот перевод и убивает диагностику.
Практический минимум на каждый день: копируй конец сообщения целиком, маскируй длинные наборы символов, добавляй три строки про то, что делал и чего ждал. Дальше проси сначала диагноз, потом правку.
Открой последнюю переписку, где ты чинил что-то с агентом. Приносил ли ты туда текст ошибки или пересказывал его своими словами?
Источники
- Error message - обзорная статья о сообщениях об ошибках, Википедия
- Stack trace - обзорная статья о трассировке вызовов и о том, что в ней содержится, Википедия
- Debugging - обзорная статья о поиске и устранении ошибок, Википедия
- Claude Code - раздел документации о диагностике проблем
- Claude Code - раздел документации о безопасности и работе с чувствительными данными
