ИИ не заменяет отладчик, тесты и внимательный код-ревью, но может ускорить рутинные шаги: структурировать симптомы, найти противоречия в логах, предложить гипотезы и аккуратный патч. Главный принцип: просить не «почини всё», а «помоги воспроизвести, локализовать и предложить минимальное изменение». Ниже — 10 промптов для практической отладки с акцентом на воспроизводимость, логи и проверяемые исправления.
Как пользоваться подборкой
Перед отправкой промпта удалите секреты: токены, пароли, персональные данные, внутренние URL. Вставляйте только нужный фрагмент кода, версию языка, окружение, команду запуска, ожидаемый и фактический результат. Ответ ИИ всегда требует проверки человеком: модель может ошибаться, не видеть скрытый контекст и уверенно предлагать неверный патч.
Таблица выбора промпта
| Ситуация | Берите | Цель |
|---|---|---|
| Баг плавающий | Промпт 1 | Собрать сценарий воспроизведения |
| Много логов | Промпт 2 | Выделить сигналы и временную линию |
| Непонятен виновник | Промпт 3 | Построить гипотезы |
| Нужен маленький патч | Промпт 4 | Исправить без переписывания |
| Падает тест | Промпт 5 | Разобрать причину и ожидания |
| Регресс после релиза | Промпт 6 | Сравнить изменения |
| Проблема в API | Промпт 7 | Проверить контракт и данные |
| Медленно работает | Промпт 8 | Найти узкое место |
| Ошибка в конкурентности | Промпт 9 | Проверить гонки и порядок событий |
| Нужен безопасный план | Промпт 10 | Подготовить проверку и откат |
10 промптов для отладки
Промпт 1
Когда использовать: баг не удаётся стабильно повторить или описание от пользователя слишком размытое.
Ты инженер по отладке. Помоги превратить описание бага в воспроизводимый сценарий. Контекст:
{{проект}}. Окружение:{{OS, браузер, версия приложения}}. Симптом:{{что происходит}}. Ожидание:{{что должно быть}}. Известные шаги:{{шаги}}. Составь минимальный сценарий воспроизведения, список недостающих данных и варианты проверки.
Переменные: {{проект}}, {{OS}}, {{симптом}}, {{шаги}}. Ожидаемый вывод: нумерованные шаги, предпосылки, входные данные, что записать в лог. Проверка качества: сценарий может повторить другой разработчик. Частый провал: модель додумывает шаги; помечайте неизвестное как неизвестное.
Промпт 2
Когда использовать: есть длинный лог, но непонятно, где первичная ошибка, а где последствия.
Проанализируй логи как SRE. Не исправляй код. Найди первую значимую ошибку, связанные события и возможные причины. Логи:
{{логи}}. Временная зона:{{timezone}}. Ожидаемый результат: таблица времени, события, уровня риска, гипотезы и следующей проверки.
Переменные: {{логи}}, {{timezone}}, {{сервис}}. Ожидаемый вывод: временная линия и 3–5 проверяемых гипотез. Проверка качества: каждая гипотеза ссылается на строку лога. Частый провал: ИИ путает причину и следствие, если логи обрезаны.
Промпт 3
Когда использовать: ошибка есть, но область поиска слишком широкая.
Сузь область отладки. Дано: код
{{фрагмент}}, ошибка{{stacktrace}}, последние изменения{{изменения}}. Составь дерево гипотез: наиболее вероятная причина, почему она вероятна, как быстро подтвердить или опровергнуть, какой файл смотреть следующим.
Переменные: {{фрагмент}}, {{stacktrace}}, {{изменения}}. Ожидаемый вывод: приоритетный список гипотез. Проверка качества: есть дешёвые проверки до правки кода. Частый провал: модель предлагает рефакторинг вместо диагностики.
Промпт 4
Когда использовать: причина понятна, нужен минимальный патч.
Предложи минимальное исправление без переписывания архитектуры. Код:
{{код}}. Ошибка:{{ошибка}}. Ограничения:{{нельзя менять API, зависимости, схему}}. Верни только: краткое объяснение, патч в формате diff, риски и тесты, которые нужно запустить.
Переменные: {{код}}, {{ошибка}}, {{ограничения}}. Ожидаемый вывод: маленький diff и список тестов. Проверка качества: патч меняет минимум строк и не ломает публичный контракт. Частый провал: ИИ чинит симптом, не закрывая первопричину.
Промпт 5
Когда использовать: тест падает после изменения, а сообщение об ошибке неочевидно.
Разбери падение теста. Тест:
{{тест}}. Код под тестом:{{код}}. Ошибка запуска:{{вывод}}. Определи, что именно проверяет тест, где расходятся ожидание и факт, и предложи: исправить код, исправить тест или уточнить фикстуры.
Переменные: {{тест}}, {{код}}, {{вывод}}. Ожидаемый вывод: диагноз, вариант исправления, дополнительный тест на регрессию. Проверка качества: вывод не сводится к «обновите snapshot» без причины. Частый провал: модель принимает ошибочный тест за истину.
Промпт 6
Когда использовать: баг появился после конкретного релиза или merge.
Помоги найти регрессию. До изменения работало:
{{старое_поведение}}. После изменения:{{новое_поведение}}. Diff или список коммитов:{{diff}}. Выдели изменения, которые могли повлиять на симптом, предложи порядок проверки и минимальный rollback-кандидат.
Переменные: {{старое_поведение}}, {{новое_поведение}}, {{diff}}. Ожидаемый вывод: подозрительные изменения по приоритету. Проверка качества: есть связь между diff и симптомом. Частый провал: слишком общий совет «сделайте git bisect» без конкретных ориентиров.
Промпт 7
Когда использовать: ошибка возникает на границе сервисов, API, вебхуков или очередей.
Проверь контракт данных. Клиент отправляет:
{{request}}. Сервер отвечает:{{response}}. Документация или схема:{{schema}}. Ошибка:{{error}}. Найди несоответствия типов, обязательных полей, форматов дат, кодов ответа и предложи минимальное исправление на стороне клиента или сервера.
Переменные: {{request}}, {{response}}, {{schema}}, {{error}}. Ожидаемый вывод: таблица несоответствий и патч-идея. Проверка качества: каждое несоответствие подтверждено примером данных. Частый провал: модель игнорирует версию API.
Промпт 8
Когда использовать: функционально всё работает, но стало медленно.
Проанализируй возможную причину деградации производительности. Код:
{{код}}. Метрики:{{latency, CPU, память, DB queries}}. Нагрузка:{{RPS, размер данных}}. Не предлагай оптимизацию вслепую: сначала укажи, какие измерения нужны, затем вероятные узкие места и минимальные изменения.
Переменные: {{код}}, {{метрики}}, {{нагрузка}}. Ожидаемый вывод: план измерений, гипотезы, дешёвые оптимизации. Проверка качества: есть метрика до и после. Частый провал: преждевременная микрооптимизация без профилирования.
Промпт 9
Когда использовать: ошибка проявляется при параллельных запросах, очередях, кэшах или фоновых задачах.
Проверь код на гонки и проблемы порядка выполнения. Код:
{{код}}. Сценарий:{{параллельные действия}}. Симптом:{{симптом}}. Опиши возможные interleaving-сценарии, общие состояния, места без блокировок или идемпотентности, и предложи минимальную защиту.
Переменные: {{код}}, {{параллельные действия}}, {{симптом}}. Ожидаемый вывод: сценарии гонки и защитные меры. Проверка качества: предложен тест, который повышает шанс поймать проблему. Частый провал: модель предлагает lock там, где нужна идемпотентность или транзакция.
Промпт 10
Когда использовать: исправление готово, но нужно безопасно выпустить его в продакшен.
Составь план безопасного исправления. Баг:
{{описание}}. Патч:{{diff}}. Риски:{{риски}}. Окружение:{{prod/stage}}. Дай чеклист проверки, smoke-тесты, метрики наблюдения, план отката и критерии, когда считать инцидент закрытым.
Переменные: {{описание}}, {{diff}}, {{риски}}, {{окружение}}. Ожидаемый вывод: релизный чеклист и rollback-план. Проверка качества: есть измеримые критерии успеха. Частый провал: план не учитывает миграции, кэш и фоновые задачи.
Как формулировать запрос точнее
- Просите ИИ отделять факты от предположений.
- Требуйте минимальный diff, а не «улучшенную версию всего файла».
- Добавляйте версии библиотек, команды запуска и полный текст ошибки.
- Просите указать, какие данные нужны для уверенного вывода.
Чеклист перед запуском исправления
- Баг воспроизводится хотя бы в одном контролируемом сценарии.
- Есть лог или тест, подтверждающий первопричину.
- Патч минимален и проходит локальные проверки.
- Добавлен регрессионный тест или понятная ручная проверка.
- Подготовлены мониторинг, критерии успеха и откат.
FAQ
Можно ли вставлять в промпт весь репозиторий? Обычно нет. Лучше дать минимальный фрагмент, структуру файлов и конкретную ошибку: так меньше шума и ниже риск утечки данных.
Что делать, если ИИ предлагает неверный код? Попросите объяснить допущения, сократить патч и указать тесты. Не применяйте изменения без ревью и запуска проверок.
Нужно ли доверять диагнозу по логам? Нет. Логи помогают строить гипотезы, но вывод зависит от полноты данных, порядка событий и качества модели.
Источники и ограничения
Полезные справочные материалы по принципам промптинга: OpenAI: best practices, Zapier: prompt templates, Zapier: how to prompt AI. Эта подборка — практические шаблоны, а не гарантия исправления. Вывод ИИ требует человеческой проверки и зависит от модели, настроек, контекста и входных данных.