Когда использовать
Перед мёржем PR, когда нет второго инженера на ревью или хочется «свежий взгляд». Роль — придирчивый senior. Результат: находки с severity (blocker/major/minor), привязкой к файлу:строке и вердиктом «мёржить / правки».
Промт (бери и вставляй)
Ты — придирчивый senior-инженер на код-ревью. Проверь дифф ниже.
ДИФФ: «<ВСТАВЬ>»
Пройди по чек-листу и для каждой находки укажи severity (blocker/major/minor) и файл:строку:
1. Корректность и краевые случаи. 2. Безопасность (инъекции, секреты, авторизация).
3. Производительность. 4. Читаемость/конвенции. 5. Тесты (что не покрыто).
В конце — вердикт: можно мёржить / нужны правки (список).
Пример заполнения
В <ВСТАВЬ> — git diff с новым эндпоинтом логина (принимает email+пароль, делает SQL-запрос строкой, кладёт пароль в лог при ошибке).
Ожидаемый ответ ИИ: [BLOCKER] auth.ts:42 — SQL собирается конкатенацией → инъекция, используйте параметры; [BLOCKER] auth.ts:55 — пароль пишется в лог, убрать; [MAJOR] нет ограничения попыток (brute-force); [MINOR] auth.ts:30 — магическое число, вынести в константу; тесты — не покрыт кейс неверного пароля. Вердикт: правки обязательны, два блокера.
Вариации
- Фокус. «Смотри только безопасность» или «только производительность» — глубже по одной оси.
- С контекстом. Добавьте рядом затрагиваемые функции — меньше «не вижу, что делает X».
- Архитектурное ревью. «Оцени не строки, а решение: правильный ли подход выбран».
Про-советы
- ИИ-ревью дополняет, но не заменяет линтер/тесты/CI: оно ловит логику и дизайн, а форматирование и типы лучше отдать инструментам.
- Severity дисциплинирует: без него модель валит всё в одну кучу. Требуйте приоритеты, чините блокеры первыми.
- Модель: для ревью берите сильнейшую (Opus/GPT-4-класс) с большим контекстом; на больших диффах режьте по модулям, иначе пропустит детали.