AI может ускорить ревью и подготовку рефакторинга, но не заменяет инженера, тесты и знание контекста продукта. Ниже — 10 прикладных промптов для ситуаций, где важно не просто «сделать код красивее», а сохранить поведение, увидеть риски и получить проверяемый план изменений.
Как пользоваться подборкой
Перед отправкой промпта дайте модели минимальный контекст: язык, версию фреймворка, цель изменения, ограничения, фрагмент кода и связанные тесты. Просите не переписывать всё сразу, а сначала перечислять риски, предположения и вопросы. Вывод модели требует человеческого ревью и зависит от модели, полноты входных данных и качества самого кода.
Таблица выбора промпта
| Задача | Подходящий промпт | Главный результат |
|---|---|---|
| Быстрое ревью PR | 1 | Список замечаний по приоритету |
| Архитектурные риски | 2 | Границы модулей и зависимости |
| Безопасный рефакторинг | 3, 4 | План маленьких шагов |
| Читаемость | 5, 6 | Упрощение имён и ветвлений |
| Безопасность и регрессии | 7, 8, 9 | Угрозы, тесты, edge cases |
| Финальная проверка | 10 | Чеклист перед merge |
Промпты для ревью
Промпт 1
Когда использовать: перед первым проходом по pull request. Переменные: {language}, {diff}, {goal}. Ожидаемый вывод: замечания с приоритетами, рисками и предложениями. Проверка качества: каждое замечание ссылается на конкретный фрагмент. Частая ошибка: модель спорит о стиле вместо влияния на поведение.
Ты опытный ревьюер {language}. Проверь diff: {diff}. Цель изменения: {goal}. Раздели вывод на Critical, Major, Minor. Для каждого пункта укажи риск, почему это важно, минимальное исправление и вопрос автору, если контекста не хватает. Не придумывай требования.
Промпт 2
Когда использовать: если изменение затрагивает слои, модули или публичные интерфейсы. Переменные: {architecture}, {code}, {constraints}. Ожидаемый вывод: карта зависимостей и архитектурные запахи. Проверка качества: рекомендации не требуют полной переписи. Частая ошибка: модель предлагает абстракции без измеримой пользы.
Оцени архитектуру фрагмента: {code}. Контекст системы: {architecture}. Ограничения: {constraints}. Найди нарушения границ ответственности, лишние зависимости, скрытые сайд-эффекты и точки роста сложности. Предложи 3 варианта: минимальный, умеренный, долгосрочный.
Промпт 3
Когда использовать: перед рефакторингом устаревшего или хрупкого кода. Переменные: {code}, {tests}, {risk_tolerance}. Ожидаемый вывод: последовательность безопасных шагов. Проверка качества: каждый шаг можно закоммитить отдельно. Частая ошибка: модель сразу выдаёт большой переписанный блок.
Составь план безопасного рефакторинга для {code}. Имеющиеся тесты: {tests}. Допустимый риск: {risk_tolerance}. Не меняй поведение. Дай шаги малыми коммитами: что изменить, какие тесты запустить, как откатить, какой сигнал покажет регрессию.
Промпт 4
Когда использовать: когда нужно отделить чистую логику от ввода-вывода. Переменные: {code}, {side_effects}, {framework}. Ожидаемый вывод: план выделения функций и адаптеров. Проверка качества: публичный контракт остаётся прежним. Частая ошибка: модель игнорирует транзакции, кэш или порядок вызовов.
Проанализируй {code} во фреймворке {framework}. Сайд-эффекты: {side_effects}. Предложи, как отделить бизнес-логику от I/O без изменения внешнего поведения. Укажи новые функции, их входы и выходы, места для моков и тестов.
Промпт 5
Когда использовать: если код работает, но его тяжело читать. Переменные: {code}, {team_style}. Ожидаемый вывод: предложения по именам, структуре и удалению шума. Проверка качества: улучшение понятно без знания вкусов автора. Частая ошибка: косметические правки маскируются под рефакторинг.
Улучши читаемость {code} с учётом стиля команды: {team_style}. Не меняй алгоритм. Предложи переименования, разбиение длинных выражений, удаление дублирования и комментарии только там, где код сам себя не объясняет. Верни список изменений и обновлённый фрагмент.
Промпт 6
Когда использовать: при сложных условиях, вложенных if или switch. Переменные: {code}, {domain_rules}. Ожидаемый вывод: упрощённая логика с сохранением правил. Проверка качества: все ветки исходного поведения перечислены. Частая ошибка: модель теряет пограничное условие.
Разбери условную логику в {code}. Доменные правила: {domain_rules}. Сначала составь таблицу веток и исходов, затем предложи упрощение: guard clauses, таблица решений или полиморфизм. Отметь, какие случаи требуют тестов перед изменением.
Промпт 7
Когда использовать: для поиска уязвимостей в изменённом коде. Переменные: {code}, {threat_model}, {data_sources}. Ожидаемый вывод: потенциальные угрозы и способы проверки. Проверка качества: нет голословных обвинений без сценария атаки. Частая ошибка: модель путает теоретический риск с реальной эксплуатацией.
Проведи security review кода: {code}. Модель угроз: {threat_model}. Источники данных: {data_sources}. Найди риски инъекций, утечек, ошибок авторизации, небезопасной сериализации и логирования секретов. Для каждого риска дай сценарий, вероятность, влияние и безопасное исправление.
Промпт 8
Когда использовать: когда нужен набор тестов перед изменениями. Переменные: {code}, {test_framework}, {known_bugs}. Ожидаемый вывод: список тест-кейсов и приоритетов. Проверка качества: тесты проверяют поведение, а не реализацию. Частая ошибка: модель генерирует тесты, которые повторяют текущие ошибки.
Для {code} предложи тесты в стиле {test_framework}. Известные баги: {known_bugs}. Сначала опиши наблюдаемое поведение и инварианты, затем happy path, edge cases, ошибки входных данных и регрессионные тесты. Не опирайся на приватные методы, если можно тестировать публичный контракт.
Промпт 9
Когда использовать: при работе с производительностью без преждевременной оптимизации. Переменные: {code}, {load_profile}, {metrics}. Ожидаемый вывод: гипотезы, измерения и осторожные улучшения. Проверка качества: есть план бенчмарка до изменения. Частая ошибка: модель предлагает микрооптимизации без данных.
Оцени производительность {code}. Профиль нагрузки: {load_profile}. Доступные метрики: {metrics}. Не делай выводов без измерений. Назови вероятные узкие места, как их подтвердить, какие изменения безопасны, а какие требуют нагрузочного теста.
Промпт 10
Когда использовать: перед merge после правок. Переменные: {diff}, {tests_run}, {release_context}. Ожидаемый вывод: финальный список блокеров и остаточных рисков. Проверка качества: модель явно говорит, где ей не хватает данных. Частая ошибка: финальная проверка превращается в формальное «всё хорошо».
Сделай финальное ревью перед merge. Diff: {diff}. Запущенные тесты: {tests_run}. Контекст релиза: {release_context}. Проверь поведение, обратную совместимость, миграции, конфиги, логи, observability и план отката. Верни: блокеры, желательные улучшения, остаточные риски, вопросы к человеку.
Как встроить в рабочий процесс
Лучше использовать эти промпты не вместо code review, а как предварительный слой. Автор может прогнать промпты 3, 5 и 8 до открытия PR, ревьюер — 1, 2 и 7 во время проверки, тимлид — 10 перед рискованным merge. Если вывод модели противоречит тестам, документации или доменным правилам, приоритет остаётся за проверяемыми источниками и решением команды.
Чеклист запуска
- Укажите язык, версии библиотек и цель изменения.
- Добавьте diff, а не только итоговый файл, если нужен обзор PR.
- Попросите модель разделять факты, предположения и вопросы.
- Не применяйте патчи без локального запуска тестов и ручного ревью.
- Фиксируйте спорные решения в комментариях PR или ADR.
FAQ
Можно ли доверять найденным ошибкам? Нет без проверки. AI помогает заметить риск, но может ошибиться, пропустить контекст или предложить неверное исправление.
Что отправлять модели: весь проект или фрагмент? Начинайте с diff, интерфейсов, тестов и краткого описания архитектуры. Весь проект редко нужен и повышает шум.
Нужно ли просить модель сразу переписать код? Обычно нет. Безопаснее сначала получить план, риски и тесты, а затем менять код маленькими шагами.
Источники и ограничения
При подготовке учитывались общие рекомендации по формулированию запросов и проверке результатов: OpenAI prompt engineering best practices, Zapier AI prompt templates, Zapier guide to prompting. Это не универсальный стандарт ревью: качество ответа зависит от модели, входных данных, контекста проекта и формулировки задачи. Любой AI-вывод требует человеческой проверки, тестирования и оценки безопасности.