8 промтов для отладки и поиска багов в коде: реальные примеры от разработчика
Каждый день я пишу код, и каждый день я сталкиваюсь с багами. Неважно, работаю ли я с Python, JavaScript, Go или SQL — ошибки всегда находят способ пробраться в продакшен. За годы практики я выработал систему промтов, которая помогает мне находить и исправлять баги в 2-3 раза быстрее. Сегодня делюсь восемью рабочими шаблонами, которые я использую ежедневно.
Введение: почему промты для отладки — это не магия, а инструмент
Многие разработчики думают, что AI-промты для отладки — это просто «найди ошибку в коде». На деле, хороший промт — это точная инструкция, которая учитывает контекст, тип ошибки, среду выполнения и ожидаемое поведение. Без этого AI выдаёт общие советы, которые бесполезны в конкретной ситуации.
Я протестировал десятки подходов: от простых запросов до многоуровневых промтов с примерами. Лучшие результаты дают шаблоны, которые имитируют работу опытного код-ревьюера: они задают уточняющие вопросы, проверяют граничные случаи и требуют объяснения логики.
Промт 1: Универсальный детектив для любого бага
Этот промт — моя базовая рабочая лошадка. Он подходит для 80% случаев, когда я не знаю, в чём проблема.
Шаблон:
Ты — опытный разработчик с 10-летним стажем. Проанализируй следующий код. Я ожидаю, что он [опиши ожидаемое поведение], но получаю [опиши фактическое поведение].
Код:
```[язык]
[вставь код]
Контекст:
- Язык: [язык]
- Среда: [ОС, версия интерпретатора/компилятора]
- Входные данные: [пример данных, на которых баг воспроизводится]
- Ошибка: [текст ошибки, если есть]
Задача:
1. Найди корневую причину бага
2. Объясни, почему код работает не так, как ожидается
3. Предложи исправленный код
4. Объясни, почему твоё решение работает
5. Укажи, какие побочные эффекты может иметь исправление
**Реальный пример:**
Я использовал этот промт для отладки бага в Python-скрипте, который парсил JSON из API. Ожидалось, что скрипт вернёт список из 10 элементов, но возвращал 9. Промт помог найти, что один элемент имел нестандартную структуру (вложенный null), которую мой код обрабатывал некорректно.
## Промт 2: Кросс-языковой анализ для миграции кода
Когда я переношу код с одного языка на другой (например, с Python на Go), баги возникают из-за различий в семантике языков. Этот промт спасает.
**Шаблон:**
Я мигрирую код с [язык_источник] на [язык_цель]. Вот оригинальный код:
[вставь код на языке-источнике]
А вот мой перевод:
[вставь код на языке-цели]
Проверь:
1. Корректность семантики: эквивалентны ли конструкции?
2. Управление памятью: есть ли утечки?
3. Обработка ошибок: правильно ли я перенёс исключения?
4. Производительность: не ввёл ли я узкие места?
5. Тестовые кейсы: какие граничные случаи я упустил?
**Реальный пример:**
При миграции парсера логов с Python на Rust я пропустил, что в Rust строки — это UTF-8, а не байтовые массивы, как я предполагал. Промт указал на это, и я избежал бага с кракозябрами в продакшене.
## Промт 3: Анализ логов и трассировка ошибок
Логи — это первое, что я смотрю при баге. Но когда логов много (сотни строк), читать их вручную — терять время.
**Шаблон:**
Вот логи моего приложения за период [время]. Приложение [название/тип] работало в [среда]. Ожидаемое поведение: [опиши]. Фактическое: [опиши ошибку].
Логи:
[вставь логи]
Задача:
1. Найди временную метку, когда произошёл сбой
2. Определи цепочку событий, приведших к ошибке
3. Укажи, какие строки логов критичны для анализа
4. Предложи гипотезу о корневой причине
5. Если есть stack trace — укажи, в каком файле и строке произошла ошибка
**Реальный пример:**
В production-окружении микросервис начал падать раз в час. Логи занимали 500 строк. Промт нашёл, что ошибка возникала при обработке запросов с определённым user-agent (старый браузер), который не передавал заголовок Content-Type. Исправление заняло 5 минут.
## Промт 4: Тестирование гипотез и A/B сравнение
Когда у меня есть две версии кода (старая с багом и новая), я не хочу гадать, какая правильная.
**Шаблон:**
У меня есть две версии кода. Версия А (старая, с багом):
[вставь код А]
Версия B (новая, исправленная):
[вставь код B]
Контекст: [опиши, что делает код]
Ожидаемый результат: [опиши]
Сравни:
1. В чём различие между версиями?
2. Какая версия ближе к ожидаемому результату?
3. Есть ли в версии B новые баги?
4. Какие тестовые случаи нужно проверить?
5. Дай рекомендацию: какую версию использовать и почему?
**Реальный пример:**
Я оптимизировал SQL-запрос, и новая версия начала выдавать дубликаты. Промт показал, что я забыл DISTINCT, и новая версия была хуже старой. Вернул старую, но понял, что нужно другое решение.
## Промт 5: Поиск race condition и проблем многопоточности
Гонки данных — это самые коварные баги. Они воспроизводятся нестабильно и трудно отлавливаются.
**Шаблон:**
Вот код, который выполняется в многопоточной среде:
[вставь код]
Платформа: [язык, фреймворк, среда]
Проблема: [опиши: падения, некорректные данные, зависания]
Задача:
1. Найди возможные race condition
2. Определи, какие разделяемые ресурсы используются
3. Укажи, где нужны блокировки (mutex, semaphore) или атомарные операции
4. Предложи исправленный код с синхронизацией
5. Оцени, не приведёт ли исправление к дедлокам
**Реальный пример:**
В Go-приложении, которое обрабатывало веб-сокеты, я использовал общую map для хранения соединений. Без мьютекса два горутины одновременно писали в map, вызывая panic. Промт предложил использовать sync.RWMutex — проблема исчезла.
## Промт 6: Декомпозиция сложной ошибки
Иногда ошибка — это симптом десяти разных проблем. Один промт не справится.
**Шаблон:**
Я столкнулся с ошибкой, которая проявляется только при определённых условиях. Вот всё, что я знаю:
- Ожидаемое поведение: [опиши]
- Фактическое поведение: [опиши]
- Условия воспроизведения: [опиши]
- Код (упрощённый): [вставь код]
- Логи: [вставь логи]
- Ошибка: [текст ошибки]
Задача:
1. Раздели проблему на подпроблемы
2. Для каждой подпроблемы предложи способ изоляции (тест, логирование, breakpoint)
3. Определи приоритет: какую подпроблему решать первой
4. Предложи план пошаговой отладки
**Реальный пример:**
В REST API ошибка «500 Internal Server Error» возникала только при нагрузке >100 RPS. Промт помог разбить проблему: (1) утечка соединений к БД, (2) нехватка воркеров в пуле, (3) медленный эндпоинт. Решили по приоритету: сначала утечка, потом пул.
## Промт 7: Проверка безопасности и уязвимостей
Безопасность — это тоже отладка, только ищешь не баги, а дыры.
**Шаблон:**
Вот код, который обрабатывает пользовательский ввод:
[вставь код]
Контекст: [веб-приложение, API, CLI и т.д.]
Задача:
1. Найди потенциальные уязвимости (SQL injection, XSS, CSRF, path traversal, command injection)
2. Укажи конкретные строки кода, где есть риск
3. Предложи исправления (экранирование, валидация, prepared statements)
4. Проверь, что исправления не ломают функциональность
5. Дай рекомендацию по тестированию безопасности
**Реальный пример:**
В Python-приложении я использовал eval() для парсинга математических выражений от пользователей. Промт указал, что это command injection. Заменил eval() на ast.literal_eval() — безопасно.
## Промт 8: Оптимизация после отладки
Когда баг исправлен, я проверяю, не ухудшилась ли производительность.
**Шаблон:**
Вот код ДО исправления бага:
[вставь код А]
Вот код ПОСЛЕ исправления:
[вставь код Б]
Измерения производительности (если есть):
- Время выполнения А: [данные]
- Время выполнения Б: [данные]
- Потребление памяти А: [данные]
- Потребление памяти Б: [данные]
Задача:
1. Сравни производительность двух версий
2. Если версия Б медленнее, найди узкие места
3. Предложи оптимизации, не нарушающие исправление бага
4. Оцени, стоит ли оптимизировать (trade-off: читаемость vs скорость)
```
Реальный пример:
После исправления бага с race condition (добавил мьютекс) время выполнения выросло на 40%. Промт предложил заменить мьютекс на atomic operations — прирост всего 5%.
Заключение: как использовать промты в реальной работе
Эти 8 промтов — не панацея, а инструмент. Я использую их каждый день, но всегда помню: AI — это ассистент, а не замена опыту. Лучшие результаты даёт комбинация:
1. Чёткое описание проблемы (контекст, данные, ожидания)
2. Итеративный подход (уточняющие вопросы)
3. Проверка ответа (AI может ошибаться)
Начните с Промта 1 — он покрывает большинство случаев. Освоив его, переходите к специализированным. И помните: хороший промт экономит часы, плохой — добавляет минуты.
P.S. Если вы работаете с подключением внешних API (например, Telegram, Stripe, Google Analytics), помните, что ошибки часто возникают на стыке систем. ASI Biont поддерживает подключение к этим сервисам через API — подробнее на asibiont.com/courses. Но это уже тема для отдельной статьи.
Комментарии