7 промптов для ревью кода и отладки

ИИ хорош в pattern matching: он отлично ловит копипасту, забытые проверки на null, классические n+1 запросы и race conditions, которые видны только опытному глазу после третьего ревью. Хуже — с архитектурными решениями и со специфичным для проекта контекстом, потому что про него модель ничего не знает.

Внутри — 7 промптов под типовые задачи разработчика. Первые три (полное ревью PR, поиск конкретного бага, генерация тестов) покрывают 80% повседневной работы. Дальше — рефакторинг, производительность, security-аудит и объяснение чужого кода. Промпты не привязаны к языку и работают в любом из перечисленных AI-coding инструментов.

Гигиена прежде всего: не отправляйте в публичные модели код с API-ключами, паролями или персональными данными клиентов. Для чувствительных проектов используйте корпоративные планы (Cursor Business, Copilot Enterprise, Cody Enterprise) с гарантией не-обучения, или self-hosted Aider с локальной моделью. На обычном персональном аккаунте всё, что вы вставили, потенциально может попасть в обучающую выборку.

🔍 Полное ревью pull request

Ты — старший инженер с опытом ревью на [ЯЗЫК] в проектах уровня [WEB-СЕРВИС / БИБЛИОТЕКА / МОБИЛЬНОЕ_ПРИЛОЖЕНИЕ].
Сделай ревью кода ниже. Проверь:
1) Корректность — есть ли баги, edge cases, забытые проверки на null/empty.
2) Безопасность — инъекции, утечки данных, небезопасные дефолты.
3) Читабельность — нейминг, длина функций, непонятные места.
4) Тесты — что не покрыто и стоит покрыть.
Формат ответа: для каждой проблемы — файл:строка, тяжесть (blocker/major/minor/nit), 1 фраза описания, предложенная правка кодом. Сначала blocker'ы, потом остальное.
Не пиши «всё отлично» в конце — если проблем нет, так и напиши кратко. Не предлагай переписать архитектуру — только то, что в диффе.

Код:
```
[ВСТАВЬ_ДИФФ]
```

💡 Примечание

Без явного запрета модель обожает писать «в целом код хороший, но...» и предлагать переписать половину репозитория. Запрет на архитектурные предложения удерживает её в рамках того, что реально находится в диффе.

🐛 Поиск конкретного бага

Поведение в проде: [ОПИСАНИЕ_СИМПТОМА — например: при нажатии «оплатить» иногда заказ создаётся дважды].
Воспроизводится: [как часто, при каких условиях].
Стек: [язык / фреймворк / БД / очередь].
Релевантный код:
```
[ВСТАВЬ_КОД]
```

Задача: предположи 3–5 наиболее вероятных причин в порядке убывания вероятности. Для каждой — короткое объяснение почему именно она и какой минимальный эксперимент её проверит (один лог, один запрос в БД, одна команда).
Не предлагай добавить мониторинг или Sentry — это не решение, это способ узнать, что бага случилась снова.
Если данных мало — задай 2–3 уточняющих вопроса в конце.

💡 Примечание

Запрет на «добавьте Sentry» — потому что это типичный капитуляционный ответ модели. Просьба про дешёвые эксперименты (один лог, один запрос) удерживает в режиме «найди причину», а не «давайте проведём недельный аудит».

🧪 Генерация unit-тестов

Напиши unit-тесты для функции ниже на [ЯЗЫК + ТЕСТОВЫЙ_ФРЕЙМВОРК — например, Python+pytest, JavaScript+jest, Go+testing].
Покрой:
1) Happy path — типичный успешный сценарий.
2) Граничные значения — пустой ввод, минимум, максимум, крайние типы.
3) Ошибки — что должно бросать исключения / возвращать ошибку.
4) Side effects (если функция меняет состояние или дёргает внешние сервисы) — через моки.
Формат: каждый тест — отдельная функция с говорящим именем вида `test_<что_проверяем>_<при_каких_условиях>_<ожидание>`. Никаких комментариев типа «// arrange // act // assert» — это видно из структуры.

Функция:
```
[ВСТАВЬ_ФУНКЦИЮ]
```

💡 Примечание

Шаблон имён тестов задаёт читаемость на годы вперёд: через полгода никто не вспомнит, что делал `test_user_1`, а `test_create_user_with_existing_email_raises_conflict` — понятно сразу. Запрет на комментарии arrange/act/assert потому что это шум.

♻️ Рефакторинг функции

Сделай рефакторинг функции ниже. Цель — повысить читабельность без изменения внешнего поведения.
Что можно: разбить на 2–4 функции по одной ответственности, переименовать неговорящие переменные, убрать дублирование, вынести магические числа в константы.
Что нельзя: менять сигнатуру (имя, параметры, возвращаемый тип), менять API/БД-вызовы, добавлять зависимости.
После — короткий список «что изменено и почему» (3–5 буллетов, без воды).

Код:
```
[ВСТАВЬ_КОД]
```

💡 Примечание

Запрет на изменение сигнатуры критичен — без него модель часто переименовывает параметры или меняет тип возврата, и весь вызывающий код придётся править. Список изменений в конце удобен для PR description.

⚡ Поиск проблем производительности

Профиль нагрузки: [QPS / число пользователей / тип данных].
Стек хранения: [БД + кэш + очередь].
Что тормозит: [конкретный endpoint / запрос / страница] — [время ответа сейчас vs целевое].
Код пути:
```
[ВСТАВЬ_КОД]
```

Задача: найди 3–5 потенциальных узких мест с оценкой влияния (low/medium/high) и стоимости фикса (low/medium/high).
Приоритет: high impact + low cost. Для каждого — конкретный патч или инструкция (добавить индекс на колонку X, кэшировать результат Y, заменить N+1 на JOIN, перенести Z в фоновую задачу).
Не предлагай переписать на другой ЯП или другую БД — нас интересует, что можно сделать на текущем стеке.

💡 Примечание

Запрет на «перепишите на другом стеке» убирает типичный эскапизм модели. Оценка impact/cost критична: иначе можно неделю оптимизировать запрос, который даёт 5% прироста, пока рядом висит индекс на день с 10-кратным ускорением. Сначала — high impact + low cost, дальше по убыванию.

🛡️ Аудит безопасности по OWASP

Проведи security-ревью кода ниже по OWASP Top 10 для [ВЕБ-ПРИЛОЖЕНИЯ / API / МОБИЛЬНОГО_КЛИЕНТА].
Особое внимание:
1) Инъекции (SQL, NoSQL, command, LDAP).
2) Авторизация — IDOR, отсутствие проверок прав.
3) Аутентификация — слабые токены, отсутствие rate-limiting.
4) Чувствительные данные — логирование секретов, небезопасное хранение.
5) SSRF / XXE / десериализация.
Формат: только реально найденные проблемы. Для каждой — класс уязвимости (по OWASP), CVSS оценка ориентировочно, файл:строка, патч.
Если уязвимостей не нашёл — напиши «нет находок», не придумывай теоретические риски.

Код:
```
[ВСТАВЬ_КОД]
```

💡 Примечание

Запрет «не придумывай теоретические риски» — лекарство от типичной болезни security-ревью: модель любит писать «потенциально уязвимо к timing-атакам», когда никаких тайминг-зависимостей в коде нет. Ложные находки забивают backlog и обесценивают реальные.

📚 Объяснение чужого кода

Я разбираюсь в [ЯЗЫК + ПРЕДМЕТНАЯ_ОБЛАСТЬ] на уровне [junior / middle / smb с другим стеком — нужное оставить].
Объясни код ниже так, чтобы я мог его поддерживать. Структура:
1) Что эта функция/модуль делает (1 предложение).
2) Где это вызывается и зачем (если видно из контекста).
3) Разбор по блокам — что в каждом куске и почему именно так.
4) Подводные камни — что легко сломать при правке.
Не пересказывай код построчно («функция объявляет переменную x...»). Это бесполезно. Объясняй смысл и намерение.

Код:
```
[ВСТАВЬ_КОД]
```

💡 Примечание

Без явного запрета 80% LLM-объяснений превращаются в построчный пересказ синтаксиса — это нечитаемо и не помогает разобраться. Уровень пользователя в первой строке (junior / middle / другой стек) задаёт глубину объяснения: junior'у нужна теория, middle с другим стеком — параллели с тем, что он уже знает.