Представьте: вы открываете пул-реквест, пробегаете глазами дифф, ставите approve — и через день ловите инцидент на проде из-за гонки данных. Знакомо? Код-ревью — узкое место, где усталость и человеческий фактор решают исход. LLM уже умеют быть вторым ревьюером: не заменяют человека, но подсвечивают edge-кейсы, которые легко пропустить.
В этой подборке — 12 промтов для ChatGPT и Claude, проверенных на реальных проектах. Они разбиты по уровням: от базовой проверки диффа до экспертного анализа безопасности и обратной совместимости API. Каждый промт — с примером кода и ожидаемым результатом. Вы сможете адаптировать их под свой стек и этап ревью.
Важно: LLM не знает контекста вашего проекта, поэтому в промты нужно вставлять не только дифф, но и смежные файлы, схемы данных, версии зависимостей. Чем точнее вход, тем полезнее выход. И помните: AI-ревью — это вспомогательный инструмент, финальное решение принимает человек.
Базовые промты: быстрый скрининг диффа
Эти промты подходят для ежедневного использования, когда нужно быстро отсеять очевидные проблемы и не тратить время на ручной анализ мелочей.
1. Проверка на edge-кейсы в изменениях
Задача: Найти граничные условия, которые не учтены в новом коде.
Промт:
Ты — опытный ревьюер. Проанализируй дифф ниже. Найди все возможные edge-кейсы, которые не обработаны: пустые значения, null, отрицательные числа, выход за границы массива, переполнение, конкурентный доступ. Для каждого укажи строку и предложи исправление.
Дифф:
Пример результата:
Для кода:
def calculate_discount(price, discount_percent):
return price * (1 - discount_percent / 100)
LLM выдаст:
- Строка 2: Если
discount_percent> 100, итоговая цена станет отрицательной. Добавьте проверкуif discount_percent < 0 or discount_percent > 100: raise ValueError. - Строка 2: Если
priceотрицательный — результат тоже отрицательный. Нужна валидация. - Строка 2: Деление на 100 может привести к потере точности для больших чисел — используйте Decimal.
Стек: любой. Этап: перед мержем.
2. Оценка читаемости и стиля
Задача: Привести код к единому стилю и улучшить понятность.
Промт:
Проверь дифф на соответствие PEP 8 (или вашему стайлгайду). Найди:
- слишком длинные функции (>20 строк);
- неинформативные имена переменных;
- отсутствие docstring для публичных методов;
- магические числа.
Предложи рефакторинг с сохранением логики.
Дифф:
Пример результата: LLM укажет, что функция process_data длиной 45 строк нарушает принцип единственной ответственности, и предложит разбить её на validate_input, transform, save_result. Также заметит магическое число 86400 и посоветует заменить на SECONDS_IN_DAY.
Стек: Python, но адаптируется под любой язык. Этап: перед ревью человеком.
Продвинутые промты: глубокий анализ логики
Здесь LLM подключается к анализу алгоритмов, потоков данных и потенциальных регрессий.
3. Поиск гонок данных и проблем конкурентности
Задача: Обнаружить состояния гонки в многопоточном или асинхронном коде.
Промт:
Проанализируй дифф на предмет гонок данных. Обрати внимание на:
- общие изменяемые переменные без блокировок;
- асинхронные вызовы без await;
- использование неатомарных операций (например, i += 1) в конкурентной среде.
Для каждой находки опиши сценарий, при котором возникнет баг, и предложи решение.
Дифф:
Пример результата:
Код:
counter = 0
async def increment():
global counter
counter += 1
LLM ответит: «В асинхронной функции increment операция counter += 1 не атомарна. При одновременном вызове из нескольких задач возможна потеря обновлений. Используйте asyncio.Lock или itertools.count с блокировкой».
Стек: Python (asyncio), Go, Java. Этап: перед мержем в многопоточные модули.
4. Проверка обработки ошибок и исключений
Задача: Убедиться, что все исключительные ситуации обработаны и не приводят к падению.
Промт:
Проверь, что в диффе:
- все внешние вызовы (API, БД, файловая система) обёрнуты в try-except;
- исключения не проглатываются молча;
- логирование ошибок содержит контекст;
- нет «голых» except.
Укажи строки с проблемами и предложи исправления.
Дифф:
Пример результата: LLM найдёт except: pass и посоветует заменить на except SpecificError as e: logger.error(f"Failed to fetch user {user_id}: {e}").
Стек: любой. Этап: перед мержем.
5. Анализ влияния на производительность
Задача: Оценить, не замедлит ли изменение критический путь.
Промт:
Оцени алгоритмическую сложность изменённых функций. Найди:
- вложенные циклы по большим коллекциям;
- лишние запросы к БД внутри циклов (N+1);
- отсутствие индексов для новых запросов;
- избыточное копирование данных.
Предложи оптимизации.
Дифф:
Пример результата: Для кода с for user in users: orders = db.query(f"SELECT * FROM orders WHERE user_id = {user.id}") LLM укажет на проблему N+1 и предложит использовать JOIN или предзагрузку.
Стек: SQL, ORM. Этап: перед мержем в горячие пути.
Экспертные промты: безопасность и совместимость
Эти промты требуют от LLM глубокого понимания контекста и часто используются для критических модулей.
6. Аудит безопасности (SQL-инъекции, XSS, утечки)
Задача: Найти уязвимости в изменениях.
Промт:
Ты — эксперт по безопасности. Проверь дифф на:
- SQL-инъекции (конкатенация строк в запросах);
- XSS (неэкранированный вывод);
- небезопасное хранение секретов;
- отсутствие CSRF-защиты;
- небезопасные десериализации.
Для каждой уязвимости приведи CWE и предложи исправление.
Дифф:
Пример результата: LLM найдёт query = f"SELECT * FROM users WHERE name = '{name}'" и укажет на CWE-89, предложив параметризованный запрос.
Стек: веб-приложения. Этап: перед мержем в публичные эндпоинты.
7. Проверка обратной совместимости API
Задача: Убедиться, что изменения не сломают существующих клиентов.
Промт:
Сравни старую и новую версии API (сигнатуры методов, форматы запросов/ответов). Найди:
- удалённые или переименованные поля;
- изменения типов данных;
- новые обязательные параметры;
- изменение кодов ошибок.
Предложи стратегию миграции без breaking changes.
Старый код:
Новый код:
**Пример результата:** LLM обнаружит, что поле `user_name` переименовано в `username`, и посоветует добавить алиас для обратной совместимости или версионирование эндпоинта.
**Стек:** REST, gRPC. **Этап:** перед мержем в публичное API.
### 8. Анализ покрытия тестами и их качества
**Задача:** Оценить, достаточно ли тестов для нового кода.
**Промт:**
Проанализируй дифф и связанные тесты. Определи:
- все ли новые ветки логики покрыты;
- есть ли тесты на edge-кейсы;
- используются ли моки для внешних зависимостей;
- нет ли ложно-положительных тестов.
Предложи дополнительные тест-кейсы.
Дифф:
**Пример результата:** LLM заметит, что не покрыт случай с пустым списком на входе, и предложит добавить тест.
**Стек:** pytest, JUnit. **Этап:** перед мержем.
### 9. Проверка соответствия бизнес-требованиям
**Задача:** Убедиться, что код реализует именно то, что нужно.
**Промт:**
У нас есть требование: [текст]. Проверь, что дифф полностью его реализует, и нет ли лишней функциональности. Укажи несоответствия.
Дифф:
**Пример результата:** LLM может найти, что требование «округление до двух знаков» не выполнено — в коде используется `round(x, 3)`.
**Стек:** любой. **Этап:** перед мержем фичи.
### 10. Оценка влияния на смежные модули (регрессия)
**Задача:** Предсказать, что может сломаться в других частях системы.
**Промт:**
Ниже — дифф и список модулей, которые его импортируют. Проанализируй, какие изменения могут вызвать регрессию. Обрати внимание на изменение сигнатур, поведения функций, форматов данных.
Дифф:
Модули-потребители:
Пример результата: LLM предупредит, что изменение возвращаемого типа с list на tuple может сломать код, который делает append.
Стек: любой. Этап: перед мержем в общие библиотеки.
11. Поиск мёртвого кода и неиспользуемых зависимостей
Задача: Очистить дифф от лишнего.
Промт:
Найди в диффе:
- неиспользуемые импорты;
- мёртвые ветки кода;
- закомментированные блоки;
- временные отладочные принты.
Предложи удалить.
Дифф:
Пример результата: LLM укажет на import pdb и pdb.set_trace(), забытые в коде.
Стек: любой. Этап: перед мержем.
12. Сравнение с альтернативными реализациями
Задача: Получить свежий взгляд на решение.
Промт:
Предложи 2-3 альтернативных способа реализации той же функциональности. Сравни их по читаемости, производительности и поддерживаемости с текущим вариантом.
Дифф:
Пример результата: LLM может предложить использовать functools.lru_cache вместо ручного кеширования, или переписать рекурсию на цикл.
Стек: любой. Этап: перед мержем сложных алгоритмов.
Как встроить промты в процесс ревью
Не пытайтесь прогнать все 12 промтов для каждого пул-реквеста — это займёт время и создаст шум. Выберите 3-4 базовых для ежедневного использования, а экспертные подключайте для критических изменений.
Автоматизируйте запуск через CI: например, при создании PR отправляйте дифф в LLM через API и публикуйте комментарии. Но помните о ложных срабатываниях — AI иногда видит проблемы там, где их нет. Настройте фильтрацию по уверенности, если API позволяет.
Ещё один нюанс: LLM не знает вашей кодовой базы. Передавайте в промт не только дифф, но и смежные файлы, схемы БД, конфиги. Чем больше контекста, тем точнее анализ. И всегда проверяйте предложенные исправления — AI может предложить синтаксически верное, но логически неверное решение.
Подборка из 12 промтов — это не догма. Комбинируйте их, адаптируйте под свой стек и этап ревью. Например, для Python добавьте проверку на изменяемые аргументы по умолчанию, для Go — на игнорирование ошибок. Экспериментируйте и делитесь своими находками.
AI-ревью не заменяет человека, но делает ревью быстрее и качественнее. Используйте LLM как второго ревьюера, чтобы ловить баги до мержа и спать спокойно. А если хотите глубже погрузиться в тему AI для разработчиков, изучите наши Нейрохакинг и когнитивная оптимизация — там разбираем практические сценарии.