ИИ полезен на ревью, когда ищет конкретные регрессии в изменении. Слабый результат — список общих советов о читаемости. Сильный — воспроизводимый сценарий, в котором новый код нарушает ожидаемое поведение. Чтобы получить такой результат, ограничьте область проверки и дайте модели контекст, необходимый для понимания контракта.
Подготовьте пакет ревью
Пакет включает цель изменения, базовую и текущую ревизии, diff, релевантные тесты и правила проекта. Если меняется API, приложите контракт. Если исправляется ошибка, приложите воспроизведение. Одного diff иногда недостаточно: смысл вызова определяется соседней функцией, которая не менялась. Разрешите модели запросить такой файл, сохраняя границы задачи.
Зафиксируйте, что проверяется: правильность логики, обработка ошибок, совместимость и значимые риски производительности. Стиль обсуждайте там, где он мешает сопровождению или нарушает явное правило. Для замечания нужны условия возникновения и последствия. Подозрение без проверки должно оставаться вопросом, а не превращаться в найденный дефект.
Рабочий порядок
- Прочитайте задачу и перескажите ожидаемое изменение поведения.
- Просмотрите изменённые файлы и выделите границы функции.
- Проверьте изменённые пути данных, включая ранние выходы и ошибки.
- Для возможного дефекта найдите вызывающий код и ограничения.
- Сформулируйте минимальный пример воспроизведения или тест.
- Отбросьте замечание, если оно основано только на неподтверждённом предположении.
Документация git diff помогает выбрать объекты сравнения. Убедитесь, что diff относится к заявленным ревизиям. После новых коммитов старые номера строк и выводы могут устареть, поэтому финальные комментарии нужно сверить с актуальным состоянием.
Пример замечания
В учебном изменении проверка количества заменена с «меньше одного» на «меньше нуля». Теперь нулевой заказ проходит в сохранение. Замечание: «При quantity=0 новая проверка не отклоняет запрос, хотя правило требует минимум одну единицу; создаётся пустой заказ». Это конкретнее, чем «улучшите валидацию». Значения приведены для иллюстрации.
Следующий шаг — проверить, нет ли другой валидации перед этим участком. Если внешний слой исключает ноль и функция недоступна другим путём, критичность может быть иной. Ревьюер учитывает реальные вызовы. Если гарантия отсутствует в предоставленном контексте, задайте вопрос вместо категоричного утверждения.
Промпт
Проверь pull request на реальные регрессии. Для замечания укажи изменённый участок, входные условия, нарушенный контракт и наблюдаемое последствие. Проверь вызывающий код перед выводом. Не сообщай о проблеме без конкретного сценария. Отдельно перечисли непроверенные риски и недостающий контекст. Не публикуй комментарии и не меняй код.Оцените найденное
Отделяйте серьёзность последствий от уверенности. Высокий ущерб при сомнительной предпосылке требует дополнительной проверки. Для производительности запросите размеры входа или сравните алгоритмическое поведение. Фраза «это может быть медленно» редко помогает автору выбрать исправление. Если речь о запросе к базе, покажите, при каких объёмах и связях возникает проблема.
Предложенный моделью тест должен падать по заявленной причине и проверять контракт. Тест, повторяющий реализацию, может подтвердить ту же ошибку. Для сложного случая сравните поведение до и после изменения на одном наборе данных. Если запуск невозможен, укажите статический характер проверки и точный участок, который требует исполнения.
Сгруппируйте повторные проявления одной причины. Не размещайте пять одинаковых комментариев. В итоговом сообщении укажите проверенную область и ограничения, например недоступный интеграционный сервис. Отсутствие найденных дефектов означает результат выполненной проверки, а не гарантию отсутствия любых ошибок.
После исправления
Повторно проверьте исходный сценарий и один соседний. Изменение валидации количества должно сохранить допустимые значения, а исправление обработки ошибки — успешный путь. Сверьте комментарий с новой ревизией и закройте его только после проверки. Не требуйте переписывать весь модуль, если локальное исправление надёжно возвращает контракт.
Частые вопросы
Нужно ли принимать все замечания модели?
Нет. Полезность определяется воспроизводимостью и связью с контрактом. Уверенный тон и длинное объяснение не заменяют проверки предпосылок.
Можно ли поручить ИИ одобрение PR?
Это зависит от правил команды. Для начала используйте модель как дополнительного проверяющего с явной ответственностью человека за принятие изменения.
Что делать с большим diff?
Разделите его по функциональным изменениям и отдельно проверьте взаимодействие частей. Механическое деление по количеству строк может разорвать важные зависимости.
Гайд подготовлен для Tarasov Code — проекта Ильи Тарасова и TarasovWeb.