Промпт для глубокого код-ревью с помощью AI

Код-ревью — одна из самых ценных, но и самых времязатратных практик в разработке. Один разработчик тратит в среднем 4–6 часов в неделю на ревью чужого кода. AI-ассистенты не заменяют ревью от коллег, но могут стать мощным «первым фильтром», который ловит типичные проблемы до того, как код попадёт к человеку.

Хороший код-ревью промпт — это не просто «проверь мой код». Это чёткое техническое задание с контекстом, критериями и форматом вывода.

Задача

Промпт выполняет комплексный анализ кода по пяти направлениям:

1. Баги и логические ошибки — off-by-one, null/undefined, race conditions
2. Безопасность — инъекции, утечки данных, проблемы аутентификации
3. Производительность — лишние аллокации, N+1 запросы, неэффективные алгоритмы
4. Читаемость и поддержка — именование, сложность, дублирование
5. Граничные случаи — пустые входы, переполнения, крайние значения

Результат выдаётся в структурированном формате с указанием строк, уровня критичности и конкретных рекомендаций.

Для кого

• Разработчики — получить второе мнение до отправки PR
• Тимлиды — ускорить первичный проход по merge-запросам
• Соло-разработчики — компенсировать отсутствие команды для ревью
• Джуниоры — учиться на разборе собственного кода

Промпт

<role>
Ты — Senior Software Engineer с 15-летним опытом. Специализация: 
code review, архитектура, безопасность приложений. Ты проводишь 
ревью как строгий, но конструктивный наставник.
</role>

<task>
Проведи глубокий код-ревью предоставленного кода. Проанализируй 
каждый из пяти аспектов. По каждой найденной проблеме дай:
- Номер строки (или диапазон строк)
- Уровень серьёзности: 🔴 critical, 🟠 warning, 🔵 suggestion
- Описание проблемы (1-2 предложения)
- Исправленный фрагмент кода
</task>

<aspects>
1. БАГИ: логические ошибки, off-by-one, null/undefined, 
   необработанные исключения, race conditions
2. БЕЗОПАСНОСТЬ: SQL/NoSQL-инъекции, XSS, CSRF, утечки секретов, 
   небезопасная десериализация, проблемы авторизации
3. ПРОИЗВОДИТЕЛЬНОСТЬ: N+1 запросы, лишние аллокации, 
   неоптимальные алгоритмы, утечки памяти, блокирующие операции
4. ЧИТАЕМОСТЬ: именование, цикломатическая сложность, дублирование,
   мёртвый код, нарушение принципов SOLID
5. ГРАНИЧНЫЕ СЛУЧАИ: пустые массивы/строки, нулевые значения, 
   отрицательные числа, Unicode, большие объёмы данных
</aspects>

<format>
Выведи результат в следующей структуре:

## Резюме
Общая оценка: [1-10]/10
Количество проблем: 🔴 X | 🟠 Y | 🔵 Z

## Найденные проблемы

### 🔴 [Категория] Краткое описание
**Строки:** XX-YY
**Проблема:** описание
**Исправление:**

исправленный код

[повторить для каждой проблемы]

## Что сделано хорошо
- пункт 1
- пункт 2

## Рекомендации по архитектуре
[если применимо — предложения по структурным улучшениям]
</format>

<context>
Язык: {ЯЗЫК_ПРОГРАММИРОВАНИЯ}
Фреймворк: {ФРЕЙМВОРК}
Назначение кода: {КРАТКОЕ_ОПИСАНИЕ}
</context>

<code>
{ВСТАВЬТЕ_КОД_СЮДА}
</code>

Как работает промпт

graph TD
    A[Вставляете код + контекст] --> B[AI принимает роль Senior Engineer]
    B --> C{Анализ по 5 аспектам}
    C --> D[Баги и логика]
    C --> E[Безопасность]
    C --> F[Производительность]
    C --> G[Читаемость]
    C --> H[Граничные случаи]
    D --> I[Структурированный отчёт]
    E --> I
    F --> I
    G --> I
    H --> I
    I --> J[Резюме + оценка + рекомендации]

Пример результата

Допустим, вы передали функцию на Python для обработки пользовательских данных:

def process_users(db, user_ids):
    results = []
    for uid in user_ids:
        user = db.query(f"SELECT * FROM users WHERE id = {uid}")
        if user['status'] == 'active':
            user['discount'] = calculate_discount(user)
            results.append(user)
    return results

AI выдаст отчёт примерно такого вида:

Резюме Общая оценка: 3/10 Количество проблем: 🔴 2 | 🟠 2 | 🔵 1

🔴 [Безопасность] SQL-инъекция через форматирование строки

Строки: 4 Проблема: Значение uid подставляется напрямую в SQL-запрос через f-строку. Атакующий может передать "1 OR 1=1" и получить все записи. Исправление:

user = db.query("SELECT * FROM users WHERE id = %s", (uid,))

🔴 [Баги] Нет обработки случая, когда пользователь не найден

Строки: 5 Проблема: Если db.query() вернёт None для несуществующего uid, обращение к user['status'] вызовет TypeError. Исправление:

user = db.query("SELECT * FROM users WHERE id = %s", (uid,))
if user and user['status'] == 'active':

🟠 [Производительность] N+1 проблема — запрос в цикле

Строки: 3-4 Проблема: Каждый uid генерирует отдельный запрос к БД. При 1000 пользователей — 1000 запросов. Исправление:

users = db.query("SELECT * FROM users WHERE id IN %s AND status = 'active'", (tuple(user_ids),))

🟠 [Читаемость] Мутация входного словаря

Строки: 6 Проблема: user['discount'] = ... изменяет объект, полученный из БД. Это может вызвать побочные эффекты если словарь переиспользуется. Исправление:

enriched = {**user, 'discount': calculate_discount(user)}
results.append(enriched)

🔵 [Читаемость] Неинформативное имя переменной

Строки: 3 Проблема: Переменная uid неконсистентна — в другом месте кода вероятно используется user_id. Исправление: Переименовать uid → user_id для единообразия.

Что сделано хорошо:

• Понятная структура функции
• Фильтрация по статусу до вычисления скидки

Вариации и настройки

Настройка порога серьёзности

Добавьте в промпт фильтр:

<filter>
Выводи только проблемы уровня 🔴 critical и 🟠 warning.
Пропускай 🔵 suggestion — я хочу сосредоточиться на критичном.
</filter>

Мультифайловое ревью

Для ревью нескольких файлов используйте XML-теги для разделения:

<file path="src/auth/login.py">
код файла 1
</file>

<file path="src/auth/middleware.py">
код файла 2
</file>

Сравнение моделей для код-ревью

Оптимальная стратегия — использовать быструю модель (Sonnet, GPT-4.1-mini) для первичного прохода и мощную (Opus, GPT-4.1) для критичных компонентов.

Советы по улучшению

1. Давайте контекст, а не просто код. Промпт с заполненной секцией <context> находит на 30–40% больше семантических ошибок, чем промпт с голым кодом. Укажите язык, фреймворк, версию, назначение модуля.

2. Используйте XML-теги. Исследования Anthropic подтверждают: Claude лучше всего воспринимает структуру через XML-теги, а не через Markdown-заголовки или нумерованные списки. Это повышает точность следования инструкциям.

3. Разбивайте большие файлы. Качество ревью падает на файлах свыше 500 строк. Если файл больше — разбейте на логические блоки и ревьюйте по частям.

4. Добавьте примеры хорошего ревью. Техника few-shot: вставьте 1–2 примера ожидаемого формата ответа перед кодом. Модель будет точнее следовать вашему стилю отчёта.

5. Итерируйте. После первого прохода задайте уточняющие вопросы: «Есть ли в этом коде потенциальные проблемы с конкурентным доступом?» или «Как этот код поведёт себя при 10 000 одновременных запросов?»

6. Сохраняйте системный промпт. Если вы регулярно проводите ревью в одном проекте — сохраните промпт как системное сообщение (system prompt) в API или как сниппет в IDE. Это обеспечит единообразие проверок.