Топ-10 промптов для поиска и исправления ошибок

<p>ИИ не заменяет отладчик, тесты и внимательный код-ревью, но может ускорить рутинные шаги: структурировать симптомы, найти противоречия в логах, предложить гипотезы и аккуратный патч. Главный принцип: просить не «почини всё», а «помоги воспроизвести, локализовать и предложить минимальное изменение». Ниже — 10 промптов для практической отладки с акцентом на воспроизводимость, логи и проверяемые исправления.</p><h2>Как пользоваться подборкой</h2><p>Перед отправкой промпта удалите секреты: токены, пароли, персональные данные, внутренние URL. Вставляйте только нужный фрагмент кода, версию языка, окружение, команду запуска, ожидаемый и фактический результат. Ответ ИИ всегда требует проверки человеком: модель может ошибаться, не видеть скрытый контекст и уверенно предлагать неверный патч.</p><h2>Таблица выбора промпта</h2><table><thead><tr><th>Ситуация</th><th>Берите</th><th>Цель</th></tr></thead><tbody><tr><td>Баг плавающий</td><td>Промпт 1</td><td>Собрать сценарий воспроизведения</td></tr><tr><td>Много логов</td><td>Промпт 2</td><td>Выделить сигналы и временную линию</td></tr><tr><td>Непонятен виновник</td><td>Промпт 3</td><td>Построить гипотезы</td></tr><tr><td>Нужен маленький патч</td><td>Промпт 4</td><td>Исправить без переписывания</td></tr><tr><td>Падает тест</td><td>Промпт 5</td><td>Разобрать причину и ожидания</td></tr><tr><td>Регресс после релиза</td><td>Промпт 6</td><td>Сравнить изменения</td></tr><tr><td>Проблема в API</td><td>Промпт 7</td><td>Проверить контракт и данные</td></tr><tr><td>Медленно работает</td><td>Промпт 8</td><td>Найти узкое место</td></tr><tr><td>Ошибка в конкурентности</td><td>Промпт 9</td><td>Проверить гонки и порядок событий</td></tr><tr><td>Нужен безопасный план</td><td>Промпт 10</td><td>Подготовить проверку и откат</td></tr></tbody></table><h2>10 промптов для отладки</h2><h3>Промпт 1</h3><p><strong>Когда использовать:</strong> баг не удаётся стабильно повторить или описание от пользователя слишком размытое.</p><blockquote>Ты инженер по отладке. Помоги превратить описание бага в воспроизводимый сценарий. Контекст: <code>{{проект}}</code>. Окружение: <code>{{OS, браузер, версия приложения}}</code>. Симптом: <code>{{что происходит}}</code>. Ожидание: <code>{{что должно быть}}</code>. Известные шаги: <code>{{шаги}}</code>. Составь минимальный сценарий воспроизведения, список недостающих данных и варианты проверки.</blockquote><p><strong>Переменные:</strong> <code>{{проект}}</code>, <code>{{OS}}</code>, <code>{{симптом}}</code>, <code>{{шаги}}</code>. <strong>Ожидаемый вывод:</strong> нумерованные шаги, предпосылки, входные данные, что записать в лог. <strong>Проверка качества:</strong> сценарий может повторить другой разработчик. <strong>Частый провал:</strong> модель додумывает шаги; помечайте неизвестное как неизвестное.</p><h3>Промпт 2</h3><p><strong>Когда использовать:</strong> есть длинный лог, но непонятно, где первичная ошибка, а где последствия.</p><blockquote>Проанализируй логи как SRE. Не исправляй код. Найди первую значимую ошибку, связанные события и возможные причины. Логи: <code>{{логи}}</code>. Временная зона: <code>{{timezone}}</code>. Ожидаемый результат: таблица времени, события, уровня риска, гипотезы и следующей проверки.</blockquote><p><strong>Переменные:</strong> <code>{{логи}}</code>, <code>{{timezone}}</code>, <code>{{сервис}}</code>. <strong>Ожидаемый вывод:</strong> временная линия и 3–5 проверяемых гипотез. <strong>Проверка качества:</strong> каждая гипотеза ссылается на строку лога. <strong>Частый провал:</strong> ИИ путает причину и следствие, если логи обрезаны.</p><h3>Промпт 3</h3><p><strong>Когда использовать:</strong> ошибка есть, но область поиска слишком широкая.</p><blockquote>Сузь область отладки. Дано: код <code>{{фрагмент}}</code>, ошибка <code>{{stacktrace}}</code>, последние изменения <code>{{изменения}}</code>. Составь дерево гипотез: наиболее вероятная причина, почему она вероятна, как быстро подтвердить или опровергнуть, какой файл смотреть следующим.</blockquote><p><strong>Переменные:</strong> <code>{{фрагмент}}</code>, <code>{{stacktrace}}</code>, <code>{{изменения}}</code>. <strong>Ожидаемый вывод:</strong> приоритетный список гипотез. <strong>Проверка качества:</strong> есть дешёвые проверки до правки кода. <strong>Частый провал:</strong> модель предлагает рефакторинг вместо диагностики.</p><h3>Промпт 4</h3><p><strong>Когда использовать:</strong> причина понятна, нужен минимальный патч.</p><blockquote>Предложи минимальное исправление без переписывания архитектуры. Код: <code>{{код}}</code>. Ошибка: <code>{{ошибка}}</code>. Ограничения: <code>{{нельзя менять API, зависимости, схему}}</code>. Верни только: краткое объяснение, патч в формате diff, риски и тесты, которые нужно запустить.</blockquote><p><strong>Переменные:</strong> <code>{{код}}</code>, <code>{{ошибка}}</code>, <code>{{ограничения}}</code>. <strong>Ожидаемый вывод:</strong> маленький diff и список тестов. <strong>Проверка качества:</strong> патч меняет минимум строк и не ломает публичный контракт. <strong>Частый провал:</strong> ИИ чинит симптом, не закрывая первопричину.</p><h3>Промпт 5</h3><p><strong>Когда использовать:</strong> тест падает после изменения, а сообщение об ошибке неочевидно.</p><blockquote>Разбери падение теста. Тест: <code>{{тест}}</code>. Код под тестом: <code>{{код}}</code>. Ошибка запуска: <code>{{вывод}}</code>. Определи, что именно проверяет тест, где расходятся ожидание и факт, и предложи: исправить код, исправить тест или уточнить фикстуры.</blockquote><p><strong>Переменные:</strong> <code>{{тест}}</code>, <code>{{код}}</code>, <code>{{вывод}}</code>. <strong>Ожидаемый вывод:</strong> диагноз, вариант исправления, дополнительный тест на регрессию. <strong>Проверка качества:</strong> вывод не сводится к «обновите snapshot» без причины. <strong>Частый провал:</strong> модель принимает ошибочный тест за истину.</p><h3>Промпт 6</h3><p><strong>Когда использовать:</strong> баг появился после конкретного релиза или merge.</p><blockquote>Помоги найти регрессию. До изменения работало: <code>{{старое_поведение}}</code>. После изменения: <code>{{новое_поведение}}</code>. Diff или список коммитов: <code>{{diff}}</code>. Выдели изменения, которые могли повлиять на симптом, предложи порядок проверки и минимальный rollback-кандидат.</blockquote><p><strong>Переменные:</strong> <code>{{старое_поведение}}</code>, <code>{{новое_поведение}}</code>, <code>{{diff}}</code>. <strong>Ожидаемый вывод:</strong> подозрительные изменения по приоритету. <strong>Проверка качества:</strong> есть связь между diff и симптомом. <strong>Частый провал:</strong> слишком общий совет «сделайте git bisect» без конкретных ориентиров.</p><h3>Промпт 7</h3><p><strong>Когда использовать:</strong> ошибка возникает на границе сервисов, API, вебхуков или очередей.</p><blockquote>Проверь контракт данных. Клиент отправляет: <code>{{request}}</code>. Сервер отвечает: <code>{{response}}</code>. Документация или схема: <code>{{schema}}</code>. Ошибка: <code>{{error}}</code>. Найди несоответствия типов, обязательных полей, форматов дат, кодов ответа и предложи минимальное исправление на стороне клиента или сервера.</blockquote><p><strong>Переменные:</strong> <code>{{request}}</code>, <code>{{response}}</code>, <code>{{schema}}</code>, <code>{{error}}</code>. <strong>Ожидаемый вывод:</strong> таблица несоответствий и патч-идея. <strong>Проверка качества:</strong> каждое несоответствие подтверждено примером данных. <strong>Частый провал:</strong> модель игнорирует версию API.</p><h3>Промпт 8</h3><p><strong>Когда использовать:</strong> функционально всё работает, но стало медленно.</p><blockquote>Проанализируй возможную причину деградации производительности. Код: <code>{{код}}</code>. Метрики: <code>{{latency, CPU, память, DB queries}}</code>. Нагрузка: <code>{{RPS, размер данных}}</code>. Не предлагай оптимизацию вслепую: сначала укажи, какие измерения нужны, затем вероятные узкие места и минимальные изменения.</blockquote><p><strong>Переменные:</strong> <code>{{код}}</code>, <code>{{метрики}}</code>, <code>{{нагрузка}}</code>. <strong>Ожидаемый вывод:</strong> план измерений, гипотезы, дешёвые оптимизации. <strong>Проверка качества:</strong> есть метрика до и после. <strong>Частый провал:</strong> преждевременная микрооптимизация без профилирования.</p><h3>Промпт 9</h3><p><strong>Когда использовать:</strong> ошибка проявляется при параллельных запросах, очередях, кэшах или фоновых задачах.</p><blockquote>Проверь код на гонки и проблемы порядка выполнения. Код: <code>{{код}}</code>. Сценарий: <code>{{параллельные действия}}</code>. Симптом: <code>{{симптом}}</code>. Опиши возможные interleaving-сценарии, общие состояния, места без блокировок или идемпотентности, и предложи минимальную защиту.</blockquote><p><strong>Переменные:</strong> <code>{{код}}</code>, <code>{{параллельные действия}}</code>, <code>{{симптом}}</code>. <strong>Ожидаемый вывод:</strong> сценарии гонки и защитные меры. <strong>Проверка качества:</strong> предложен тест, который повышает шанс поймать проблему. <strong>Частый провал:</strong> модель предлагает lock там, где нужна идемпотентность или транзакция.</p><h3>Промпт 10</h3><p><strong>Когда использовать:</strong> исправление готово, но нужно безопасно выпустить его в продакшен.</p><blockquote>Составь план безопасного исправления. Баг: <code>{{описание}}</code>. Патч: <code>{{diff}}</code>. Риски: <code>{{риски}}</code>. Окружение: <code>{{prod/stage}}</code>. Дай чеклист проверки, smoke-тесты, метрики наблюдения, план отката и критерии, когда считать инцидент закрытым.</blockquote><p><strong>Переменные:</strong> <code>{{описание}}</code>, <code>{{diff}}</code>, <code>{{риски}}</code>, <code>{{окружение}}</code>. <strong>Ожидаемый вывод:</strong> релизный чеклист и rollback-план. <strong>Проверка качества:</strong> есть измеримые критерии успеха. <strong>Частый провал:</strong> план не учитывает миграции, кэш и фоновые задачи.</p><h2>Как формулировать запрос точнее</h2><ul><li>Просите ИИ отделять факты от предположений.</li><li>Требуйте минимальный diff, а не «улучшенную версию всего файла».</li><li>Добавляйте версии библиотек, команды запуска и полный текст ошибки.</li><li>Просите указать, какие данные нужны для уверенного вывода.</li></ul><h2>Чеклист перед запуском исправления</h2><ol><li>Баг воспроизводится хотя бы в одном контролируемом сценарии.</li><li>Есть лог или тест, подтверждающий первопричину.</li><li>Патч минимален и проходит локальные проверки.</li><li>Добавлен регрессионный тест или понятная ручная проверка.</li><li>Подготовлены мониторинг, критерии успеха и откат.</li></ol><h2>FAQ</h2><p><strong>Можно ли вставлять в промпт весь репозиторий?</strong> Обычно нет. Лучше дать минимальный фрагмент, структуру файлов и конкретную ошибку: так меньше шума и ниже риск утечки данных.</p><p><strong>Что делать, если ИИ предлагает неверный код?</strong> Попросите объяснить допущения, сократить патч и указать тесты. Не применяйте изменения без ревью и запуска проверок.</p><p><strong>Нужно ли доверять диагнозу по логам?</strong> Нет. Логи помогают строить гипотезы, но вывод зависит от полноты данных, порядка событий и качества модели.</p><h2>Источники и ограничения</h2><p>Полезные справочные материалы по принципам промптинга: <a href="https://help.openai.com/en/articles/10032626-prompt-engineering-best--practices-for-chatgpt">OpenAI: best practices</a>, <a href="https://zapier.com/blog/ai-prompt-templates/">Zapier: prompt templates</a>, <a href="https://help.zapier.com/hc/en-us/articles/36532133250317-How-to-prompt-AI-in-Zapier-products">Zapier: how to prompt AI</a>. Эта подборка — практические шаблоны, а не гарантия исправления. Вывод ИИ требует человеческой проверки и зависит от модели, настроек, контекста и входных данных.</p>