Что приложить к вопросу
Хороший запрос для отладки содержит язык и версию, небольшой воспроизводимый фрагмент, полный текст ошибки, ожидаемое поведение и то, что происходит на самом деле. Если важны ограничения по библиотекам, производительности или совместимости, укажите их до генерации решения.
Не отправляйте секреты из файлов окружения, токены, приватные ключи и реальные данные пользователей. Перед публикацией лога замените чувствительные значения.
Язык и версия: . Ожидаемое поведение: . Фактическое поведение и полный текст ошибки: . Минимальный код: Сначала назови наиболее вероятную причину. Затем предложи минимальное исправление и тест, который воспроизводит ошибку. Не меняй несвязанные части.
Ищите причину, а не только патч
Просите модель объяснить цепочку от входных данных до сбоя. Если предложенное исправление большое, попросите минимальный вариант и отдельный рефакторинг. Так проще проверить, какая правка действительно решила проблему.
Полезное продолжение
- «Какой самый маленький тест сначала должен падать?»
- «Какие еще причины дают тот же симптом?»
- «Покажи изменение как компактный diff без несвязанных правок».
- «Какие крайние случаи это исправление не покрывает?»
Проводите ревью по критериям
Запрос «проверь код» часто дает длинный список мелочей. Задайте порядок: сначала корректность и безопасность, затем конкурентность и производительность, после этого читаемость. Попросите отделить ошибки от вкусовых предложений.
Проведи ревью кода ниже. Приоритеты: корректность, безопасность, обработка ошибок, затем производительность. Для каждой проблемы укажи сценарий, при котором она проявится, серьезность и минимальную правку. Не выдавай вкусовые предпочтения за ошибки. Код:
Требуйте проверяемые тесты
Укажите тестовый фреймворк и уже принятый стиль. Попросите негативные случаи, границы и проверку прежнего поведения. Сгенерированный тест тоже может быть неверным, поэтому убедитесь, что он падает до исправления и проходит после него.
Напиши тесты для функции ниже на . Покрой обычный случай, пустой ввод, границы и одну ожидаемую ошибку. Не меняй производственный код. Кратко объясни, какой риск проверяет каждый тест. Функция:
Граница ответственности
Чат не запускает код и не видит весь репозиторий. Он может предложить устаревший API, небезопасную команду или правку, которая ломает скрытый контракт. Работайте в отдельной ветке, читайте diff, запускайте линтеры и тесты, проверяйте зависимости по официальной документации.
Откройте режим «Код»
Вставьте минимальный пример и текст ошибки. Не добавляйте секреты из проекта.
Проверить код