# Как принести агенту ошибку, чтобы он её починил с первого раза

Пересказ ошибки своими словами превращает починку в угадывание. Разбираю, что копировать, как замаскировать ключи и какие три строки добавить к тексту.

URL: https://posts.danashkin.ru/guides/kak-prinesti-agentu-oshibku
Обновлено: 2026-09-05

---

## Коротко

**Главное**

- Агент чинит ошибку, которую увидел целиком. Пересказ своими словами превращает точную диагностику в угадывание.
- Копировать надо последние двадцать-тридцать строк сообщения как есть, вместе со служебными деталями, которые кажутся мусором.
- Перед вставкой заменить длинные наборы букв и цифр на слово СЕКРЕТ: ключи доступа любят прятаться в тексте ошибок.
- К тексту добавляются три вещи: что ты делал, что ожидал увидеть, что увидел. Без них агент чинит симптом.
- Часть ошибок вообще не про код: старая версия программы, оборванная связь, права доступа. Их лечат не правкой, а проверкой окружения.

## Почему пересказ ошибки ломает починку?

**Главное**

Потому что в сообщении об ошибке главное - служебные детали, которые человек считает мусором и выбрасывает при пересказе. Именно они называют место и причину, а формулировка «у меня всё сломалось» не называет ничего.

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

Причина в потере информации. Сообщение об ошибке содержит три слоя: что именно не получилось, в каком месте и на каком шаге. При пересказе выживает только первый, да и тот в размытом виде.

Сравни две формулировки.

Пересказ: «Он говорит, что не может открыть файл».

Оригинал: сообщение, в котором названы конкретный файл, тип отказа и место, где всё оборвалось. Второе агент читает как адрес, первое - как жалобу.

Аналогия из бизнеса. Это как разница между «клиент недоволен» и записью разговора. По первому можно построить десять гипотез, по второму - принять решение.

## Что именно копировать в чат?

**Главное**

Последние двадцать-тридцать строк вывода целиком, как есть. Не первую строку, не самую страшную, не ту, которая кажется главной, а последний блок целиком: причина обычно в его конце, а не в начале.

Правило, которое я даю ученикам, сознательно тупое: выдели последние строки и вставь как есть.

Почему именно так:

- **Причина чаще в конце.** Верх сообщения показывает, где всё оборвалось, низ - почему.
- **Служебные строки нужны.** Пути к файлам, номера строк, названия компонентов - это адрес поломки.
- **Форматирование значимо.** Отступы и порядок строк показывают, что откуда вызвано.
- **Лишнее агенту не мешает.** Он читает быстро и отбрасывает шум сам, а вот дописать выброшенное не может.

**Если сообщение огромное**

Бывает, что вывод на сотни строк. Тогда берётся конец: последние тридцать строк плюс первая строка с названием ошибки. Этого хватает в подавляющем большинстве случаев, а если не хватит, агент попросит остальное.

Отдельно про скриншоты. Картинка работает, если текст на ней читается целиком. Но копировать текстом надёжнее: агент не ошибётся в символе, а ты не обрежешь нужную строку.

## Секреты, которые уезжают вместе с ошибкой

**Главное**

В тексте ошибок регулярно оказываются ключи доступа, токены и строки подключения к базе. Перед вставкой длинные наборы букв и цифр заменяются на слово СЕКРЕТ - смысл сообщения от этого не страдает.

Об этом почти никто не думает, а зря. Сообщение об ошибке часто печатает то, с чем работала программа, включая содержимое настроек.

Как выглядит опасное место: длинная строка из случайных букв и цифр, иногда с адресом сервера внутри. Это и есть ключ.

Что делать перед вставкой:

1. **Пробеги текст глазами**

   Ищи длинные бессмысленные последовательности символов и адреса с логином и паролем внутри.

2. **Замени их на слово СЕКРЕТ**

   Именно заменить, а не удалить: агенту важно видеть, что там что-то было, а что именно, ему знать незачем.

3. **Проверь адреса подключения**

   Строки вида «имя пользователя, пароль, адрес базы» маскируются целиком.

4. **Вставляй**

   Смысл сообщения сохранён, ключ остался у тебя.

Если ключ всё-таки уехал в переписку, лечение одно: отозвать его и выпустить новый. Про то, почему [ИИ-агенту](/concepts/ai-agent) вообще запрещают читать файл с настройками, я разбирал в материале про [доступ агента к почте и серверу](/guides/dostup-agenta-k-pochte-i-serveru).

## Как описать, что происходило перед ошибкой?

**Главное**

Тремя предложениями: что ты делал, что ожидал увидеть, что увидел вместо этого. Эти три строки экономят больше времени, чем любая догадка о причине.

Текст ошибки говорит, что сломалось. Он не говорит, что ты пытался сделать, а без этого агент чинит не ту задачу.

Шаблон, который стоит выучить наизусть:

1. **Что делал.** «Нажал кнопку отправки формы на странице заявок».
2. **Что ожидал.** «Заявка сохраняется, появляется сообщение об успехе».
3. **Что получил.** «Страница перезагрузилась, заявки нет, в консоли такая ошибка».

Плюс два уточнения, которые решают половину случаев:

- **Когда это началось.** «Работало вчера, сегодня нет» - сильнейший сигнал: значит, дело в последнем изменении.
- **Воспроизводится ли.** «Каждый раз» и «иногда» - это разные диагнозы. Второе почти всегда про связь, лимиты или гонку.

Мой рабочий приём: перед тем как писать агенту, я формулирую эти три строки вслух. Треть проблем к концу третьей строки решается без него: становится видно, что я сам делал не то.

Про формулировки задач в целом есть отдельный разбор - [канон промпта для агента](/guides/kanon-prompta-dlya-ai-agenta).

## Три типа сообщений и что они значат

**Главное**

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

| Тип | Как выглядит | Что делать | Чего не делать |
|---|---|---|---|
| Код сломан | конкретный файл, строка, название функции | принести текст агенту, он правит | не переписывать всё заново |
| Связь оборвалась | «прервано», «превышено время ожидания» | сохранить работу, повторить, разбить задачу | не менять код, он тут ни при чём |
| Окружение не подходит | требуется версия, нет прав, нет компонента | проверить версию программы, права, обходной путь | не заставлять агента чинить чужую программу |

Второй и третий типы люди чинят как первый, и от этого ломают то, что работало.

Пример из практики. Работа с презентацией обрывается сообщением, что текущая версия программы не поддерживает нужную возможность. Никакая правка кода это не лечит: либо обновляется программа, либо берётся обходной путь через другой формат файла. Час, потраченный на «почини это», уходит впустую.

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

## Когда починка идёт по кругу

**Главное**

Если агент третий раз предлагает разное и ничего не помогает, проблема не в его сообразительности. Обычно это признак того, что чинится симптом, а первопричина лежит на шаг раньше или вообще вне кода.

Три сигнала, что пора остановиться и сменить подход:

**Сигнал первый: правки накапливаются.** После каждой попытки в проекте становится больше кода, а результат тот же. Это верный признак, что причина не найдена.

**Сигнал второй: объяснения меняются.** Сначала дело было в одном, потом в другом, потом в третьем. Агент перебирает гипотезы, потому что данных мало.

**Сигнал третий: ты перестал понимать, что происходит.** Это не твоя вина, это накопленная сложность.

Что делать:

1. **Откатись к последнему рабочему состоянию.** Как это делается словами, разбирал в материале про [откат изменений агента](/guides/kak-otkatit-izmeneniya-agenta).
2. **Начни новый чат.** Длинный разговор с десятью неудачными гипотезами мешает, а не помогает. Про это есть отдельный материал про [гигиену контекстного окна](/guides/gigiena-kontekstnogo-okna).
3. **Опиши задачу заново.** С нуля, тремя строками, с полным текстом ошибки.
4. **Попроси сначала диагноз, потом правку.** «Не чини, объясни, что происходит и почему» - отдельный шаг, который экономит часы.

## Что делать, если объяснение непонятно?

**Главное**

Просить объяснить проще, но не короче. Формулировка «разъясни подробно простым языком, не сокращая» работает лучше, чем «объясни попроще»: во втором случае агент режет текст и теряет смысл.

Отдельная беда непрограммиста: агент отвечает технически, человек не понимает, стесняется переспросить и делает наугад.

Рабочие формулировки, которые я даю на занятиях:

- **«Объясни по-человечески, как для гуманитария.»** Простая и на удивление рабочая.
- **«Разъясни подробно, но простым языком, текст не сокращай.»** Ключевое здесь - запрет сокращать. Иначе получишь короткий и такой же непонятный ответ.
- **«Не понимаю твой вопрос. Предложи сам вариант на основе того, что знаешь о проекте, и объясни, почему именно такой.»** Снимает тупик, когда агент спрашивает про то, о чём ты не имеешь мнения.
- **«Что случится, если я ничего не буду делать?»** Отделяет настоящую проблему от косметической.

Отдельно стоит помнить: непонятное объяснение - не повод соглашаться. Принимать работу, которую не понимаешь, - отдельный навык, про него есть [разбор про приёмку без технического бэкграунда](/guides/kak-proveryat-ai-kod-bez-teh-bekgraunda).

## Частые вопросы

**Главное**

Что спрашивают чаще всего: обязательно ли копировать текст целиком, годится ли скриншот, что делать с ошибками на английском и стоит ли писать про свои догадки.

### Частые вопросы

**Обязательно копировать всё сообщение?**

Последние двадцать-тридцать строк. Если сомневаешься, лучше больше: лишнее агент отбросит, а недостающее восстановить не сможет.

**Скриншот подойдёт вместо текста?**

Подойдёт, если текст на нём читается целиком. Текстом надёжнее: не теряются символы и не обрезается конец.

**Ошибка на английском, я его не знаю. Что делать?**

Вставлять как есть и просить объяснить по-русски. Переводить самому не надо: перевод меняет служебные названия, и адрес поломки теряется.

**Писать ли свои догадки о причине?**

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

## Главный вывод

**Главное**

Качество починки определяется качеством того, что ты принёс. Последние тридцать строк как есть, замаскированные секреты и три строки контекста превращают сорокаминутное угадывание в одну точную правку.

Ошибка тут человеческая и понятная: сообщение выглядит страшно и хочется пересказать его понятными словами. Именно этот перевод и убивает диагностику.

Практический минимум на каждый день: копируй конец сообщения целиком, маскируй длинные наборы символов, добавляй три строки про то, что делал и чего ждал. Дальше проси сначала диагноз, потом правку.

Открой последнюю переписку, где ты чинил что-то с агентом. Приносил ли ты туда текст ошибки или пересказывал его своими словами?

### Источники

- [Error message - обзорная статья о сообщениях об ошибках, Википедия](https://en.wikipedia.org/wiki/Error_message)
- [Stack trace - обзорная статья о трассировке вызовов и о том, что в ней содержится, Википедия](https://en.wikipedia.org/wiki/Stack_trace)
- [Debugging - обзорная статья о поиске и устранении ошибок, Википедия](https://en.wikipedia.org/wiki/Debugging)
- [Claude Code - раздел документации о диагностике проблем](https://code.claude.com/docs/en/troubleshooting)
- [Claude Code - раздел документации о безопасности и работе с чувствительными данными](https://code.claude.com/docs/en/security)