Промпты для code review: как искать баги, уязвимости и архитектурные проблемы

Что такое code review через ИИ

Code review через ИИ — это проверка кода с помощью модели, которая анализирует фрагменты, файлы, diff или целый модуль и ищет проблемы:

Плохой промпт выглядит так:

Проверь код.

Проблема: неясно, что именно проверять. ИИ может ограничиться поверхностными замечаниями: «улучшить читаемость», «добавить комментарии», «вынести в функцию». Это не code review, а общий обзор.

Сильный промпт выглядит иначе:

Проведи code review PHP-кода.

Контекст:
проект работает без фреймворков, использует MariaDB, собственный роутер, server-side rendering и пользовательский контент. Важны безопасность, права доступа, CSRF, XSS, SQL-инъекции и multi-user изоляция.

Проверь:
- ошибки логики;
- SQL-инъекции;
- XSS;
- CSRF;
- проверку прав пользователя;
- работу с пользовательским вводом;
- обработку ошибок;
- риск поломки существующего поведения;
- дублирование и архитектурные проблемы.

Ограничения:
не переписывай код сразу. Сначала дай список проблем.

Формат ответа:
таблица с колонками: критичность, место в коде, проблема, риск, рекомендация.

Такой промпт направляет ИИ на поиск конкретных проблем, а не на общие советы.

Почему нельзя просить ИИ «просто проверить код»

Код можно проверять по-разному.

Один человек смотрит на стиль.
Другой — на безопасность.
Третий — на производительность.
Четвёртый — на архитектуру.
Пятый — на регрессии и совместимость.

Если не указать фокус проверки, модель сама выберет направление. Часто это приводит к слабому результату.

Слабый промпт:

Посмотри, всё ли нормально.

Что с ним не так:

Для реального проекта такой промпт опасен. Он создаёт иллюзию проверки, но не гарантирует, что важные риски вообще были рассмотрены.

Главный принцип: задавайте фокус ревью

Перед code review нужно решить, что именно вы хотите проверить.

Возможные фокусы:

Можно проверять всё сразу, но для сложного кода лучше делить ревью на этапы.

Пример:

Сначала проведи security review. Не анализируй стиль и архитектуру, если они не создают риск безопасности.

Затем:

Теперь проведи архитектурное ревью этого же модуля. Сфокусируйся на связности, дублировании, размере методов, ответственности классов и риске дальнейшей поддержки.

Такой подход даёт более глубокий результат, чем один общий запрос.

Базовая структура промпта для code review

Рабочий промпт для ревью кода можно строить так:

Контекст проекта:
[стек, архитектура, важные правила]

Код для проверки:
[файл, diff, фрагмент или описание модуля]

Цель ревью:
[что именно нужно проверить]

Проверь:
[список направлений проверки]

Ограничения:
[что нельзя делать]

Формат ответа:
[как оформить результат]

Критерии качества:
[каким должен быть хороший результат ревью]

Эта структура подходит для проверки отдельных файлов, pull request, diff, нового модуля, формы, API-метода, SQL-запроса, миграции или UI-компонента.

1. Контекст проекта

Контекст помогает ИИ понять, какие риски важны именно для вашего проекта.

Плохо:

Проверь этот PHP-код.

Лучше:

Контекст:
PHP 8.4, MariaDB, проект без фреймворков, собственный роутер, server-side HTML, пользовательский контент, авторизация через сессии. Важны CSRF, XSS, SQL-инъекции, права доступа и изоляция данных пользователей.

Контекст может включать:

Для проекта без фреймворков контекст особенно важен. В таких проектах нельзя рассчитывать, что фреймворк автоматически закроет маршрутизацию, CSRF, escaping, middleware, валидацию и работу с правами.

2. Область проверки

ИИ должен понимать, что именно проверяется.

Варианты:

Проверь только этот файл.

Проверь diff последнего изменения.

Проверь модуль авторизации целиком.

Проверь форму создания статьи: view, route, controller, service и SQL.

Проверь API-метод удаления записи.

Если область не ограничить, модель может уйти в общие рассуждения.

Пример:

Область проверки:
только логика сохранения промпта: валидация формы, права пользователя, запись в БД, загрузка обложки и обработка ошибок. Не анализируй дизайн страницы, если он не влияет на безопасность.

Такой промпт экономит время и делает ревью точнее.

3. Цель ревью

Цель объясняет, зачем проводится проверка.

Примеры:

Цель ревью:
найти критичные ошибки перед выкладкой в продакшен.

Цель ревью:
проверить, не нарушает ли изменение multi-user изоляцию.

Цель ревью:
найти уязвимости в обработке пользовательского ввода.

Цель ревью:
оценить, не создаёт ли новый модуль архитектурный долг.

Цель ревью:
проверить pull request на риск регрессий.

Без цели модель может дать слишком широкий ответ. С целью она выбирает правильную глубину.

4. Список проверок

В промпте нужно явно указать, что проверять.

Для backend-кода:

Проверь:
- валидацию входных данных;
- авторизацию;
- права доступа;
- CSRF;
- SQL-инъекции;
- XSS;
- обработку ошибок;
- логирование;
- транзакции;
- работу с файлами;
- риск утечки данных;
- совместимость со старыми данными.

Для frontend-кода:

Проверь:
- обработку состояний загрузки;
- пустые состояния;
- ошибки API;
- XSS при выводе пользовательских данных;
- доступность базовых элементов;
- адаптивность;
- дублирование логики;
- лишние зависимости.

Для SQL и миграций:

Проверь:
- безопасность миграции;
- наличие индексов;
- уникальные ограничения;
- внешние ключи, если они используются в проекте;
- обратную совместимость;
- риск потери данных;
- значения по умолчанию;
- влияние на существующие записи.

Для архитектуры:

Проверь:
- смешение ответственности;
- слишком большие методы;
- дублирование;
- нарушение слоёв;
- прямой доступ к БД из view;
- бизнес-логику в routes;
- сложность дальнейшей поддержки.

Чем точнее список, тем лучше ревью.

5. Критичность проблем

Хороший code review должен разделять проблемы по уровню риска.

Пример шкалы:

Критичность:
- Critical: может привести к взлому, потере данных, обходу прав или падению критичного сценария.
- High: серьёзный баг, риск утечки данных, нарушение бизнес-логики.
- Medium: проблема поддержки, возможная регрессия, слабая обработка ошибок.
- Low: стиль, читаемость, незначительное дублирование.

Если не попросить критичность, ИИ может смешать XSS и переименование переменной в одном списке. Это вредно: важные проблемы теряются среди мелочей.

Хороший промпт:

Раздели найденные проблемы по критичности: Critical, High, Medium, Low. Не смешивай стилистические замечания с уязвимостями.

6. Ограничения для ревью

Ограничения нужны, чтобы ИИ не начал сразу переписывать код.

Пример:

Ограничения:
- не меняй код сразу;
- не переписывай модуль целиком;
- не давай абстрактные советы;
- каждую проблему привязывай к конкретному месту;
- не предлагай новые зависимости без необходимости;
- не меняй архитектуру, если проблема решается точечно.

Для ревью это особенно важно. Сначала нужен анализ. Исправления — вторым этапом.

Плохой промпт:

Проверь и исправь всё.

Лучше:

Сначала проведи ревью и дай список проблем. Не вноси изменения. После этого я выберу, какие проблемы исправлять.

Так вы сохраняете контроль над проектом.

7. Формат ответа

Формат ответа должен помогать быстро принимать решения.

Хороший формат для ревью:

Формат ответа:
таблица с колонками:
1. Критичность.
2. Файл/место.
3. Проблема.
4. Почему это риск.
5. Как исправить.

После таблицы:
- топ-3 проблемы, которые нужно исправить первыми;
- что можно отложить;
- что требует дополнительной проверки.

Такой формат лучше длинного текста. Он помогает отделить критичные риски от косметики.

8. Критерии качества ревью

Критерии качества защищают от поверхностного ответа.

Пример:

Критерии качества:
- каждая проблема должна быть привязана к конкретному месту в коде;
- не должно быть общих советов без примера;
- критичные риски должны быть выше стилистических замечаний;
- если проблема предполагаемая, укажи, что это гипотеза;
- не предлагай переписывать весь модуль без причины.

Полезное ревью должно отвечать на три вопроса:

Если ответ не содержит этих трёх элементов, ревью слабое.

Универсальный промпт для code review

Проведи code review.

Контекст проекта:
[стек, архитектура, важные правила, тип данных, авторизация]

Код для проверки:
[вставить код, diff или указать файлы]

Цель ревью:
[найти баги / уязвимости / архитектурные проблемы / риск регрессий]

Проверь:
- ошибки логики;
- безопасность;
- валидацию входных данных;
- права доступа;
- работу с пользовательскими данными;
- обработку ошибок;
- работу с БД;
- риск регрессий;
- дублирование;
- архитектурные проблемы.

Критичность:
раздели проблемы на Critical, High, Medium, Low.

Ограничения:
- не переписывай код сразу;
- не давай абстрактные советы;
- каждую проблему привязывай к конкретному месту;
- не предлагай новые зависимости без необходимости;
- не смешивай стиль и безопасность.

Формат ответа:
таблица:
1. Критичность.
2. Файл/место.
3. Проблема.
4. Почему это риск.
5. Как исправить.

В конце:
- топ-3 проблемы для исправления в первую очередь;
- что можно отложить;
- какие проверки выполнить вручную.

Этот шаблон можно адаптировать под разные языки и проекты.

Промпт для security review

Security review лучше проводить отдельно. Если смешать безопасность со стилем, важные проблемы могут потеряться.

Проведи security review кода.

Контекст:
[описать проект, стек, авторизацию, работу с БД и пользовательскими данными]

Код:
[вставить код или указать файлы]

Проверь:
- SQL-инъекции;
- XSS;
- CSRF;
- обход авторизации;
- нарушение прав доступа;
- IDOR;
- небезопасную загрузку файлов;
- небезопасную работу с путями;
- утечку чувствительных данных;
- небезопасную обработку ошибок;
- доверие к данным из запроса;
- отсутствие server-side валидации.

Ограничения:
- не анализируй стиль кода, если он не создаёт риск безопасности;
- не предлагай полную замену архитектуры;
- не исправляй код сразу;
- каждую проблему привязывай к конкретному месту.

Формат ответа:
таблица:
1. Критичность.
2. Место.
3. Уязвимость.
4. Возможный сценарий эксплуатации.
5. Рекомендация по исправлению.

В конце:
список проблем, которые нужно исправить до релиза.

Такой промпт подходит для проверки форм, API, админки, загрузки файлов, авторизации и работы с пользовательским контентом.

Промпт для проверки прав доступа

Права доступа часто ломаются незаметно. Особенно в multi-user проектах.

Проверь код на проблемы с правами доступа и multi-user изоляцией.

Контекст:
в проекте каждый пользователь должен видеть и изменять только свои данные. Администраторские действия доступны только пользователям с ролью admin.

Проверь:
- фильтруются ли запросы по текущему user_id;
- нельзя ли изменить чужую запись по id;
- проверяется ли владелец записи перед update/delete;
- нет ли доверия к user_id из формы или GET/POST;
- не выводятся ли чужие данные в списках;
- не доступны ли admin-действия обычному пользователю;
- корректно ли обрабатывается отсутствие записи.

Ограничения:
- не переписывай код сразу;
- не давай общие советы;
- укажи конкретные места риска.

Формат ответа:
таблица:
1. Критичность.
2. Место.
3. Риск.
4. Как пользователь может обойти ограничение.
5. Как исправить.

Такой промпт полезен для личных кабинетов, SaaS, маркетплейсов, блогов с авторами и любых проектов с пользовательскими данными.

Промпт для проверки SQL и работы с БД

Ошибки в SQL могут быть не только в безопасности, но и в логике данных.

Проведи review SQL-запросов и работы с БД.

Контекст:
[описать БД, способ работы с запросами, важные таблицы]

Проверь:
- используются ли prepared statements;
- нет ли конкатенации пользовательского ввода в SQL;
- корректно ли фильтруются данные по user_id;
- есть ли нужные индексы;
- нет ли N+1 запросов;
- корректно ли обрабатываются пустые результаты;
- не теряются ли данные при update;
- нужны ли транзакции;
- нет ли риска дублей;
- корректны ли уникальные ограничения.

Ограничения:
- не меняй схему БД без отдельного обоснования;
- не предлагай индексы без объяснения;
- не переписывай весь слой доступа к данным.

Формат ответа:
таблица:
1. Критичность.
2. Запрос/место.
3. Проблема.
4. Риск.
5. Рекомендация.

Такой промпт хорошо подходит для сервисов, где много фильтров, списков, пользовательских данных и финансовых операций.

Промпт для архитектурного ревью

Архитектурное ревью нужно не для поиска одной ошибки, а для оценки поддерживаемости.

Проведи архитектурное ревью модуля.

Контекст проекта:
[стек, архитектура, правила слоёв]

Модуль:
[описать модуль или указать файлы]

Проверь:
- не смешана ли бизнес-логика с view;
- нет ли слишком больших методов;
- нет ли дублирования;
- соблюдается ли разделение controller/service/repository/view;
- нет ли прямого доступа к БД из неподходящего слоя;
- не нарушает ли модуль текущую архитектуру;
- насколько код будет удобно расширять;
- есть ли риск скрытых побочных эффектов.

Ограничения:
- не предлагай переписать проект с нуля;
- не предлагай фреймворк вместо точечных улучшений;
- не смешивай архитектурные замечания со стилем;
- каждую рекомендацию привязывай к конкретной проблеме.

Формат ответа:
1. Краткий вывод.
2. Таблица проблем.
3. Что исправить сейчас.
4. Что можно отложить.
5. Какой минимальный безопасный рефакторинг возможен.

Такой промпт полезен, когда модуль уже работает, но становится тяжёлым для поддержки.

Промпт для проверки diff перед релизом

Перед релизом лучше проверять не весь проект, а конкретное изменение.

Проверь diff перед релизом.

Контекст:
[описать проект и цель изменения]

Diff:
[вставить diff или список изменённых файлов]

Цель проверки:
найти риски, которые могут сломать существующее поведение после выкладки.

Проверь:
- не изменились ли публичные маршруты;
- не сломана ли обратная совместимость;
- не нарушены ли права доступа;
- не появились ли SQL/XSS/CSRF риски;
- не забыты ли миграции;
- не ломаются ли старые данные;
- не изменён ли формат ответа API;
- не появились ли неочевидные побочные эффекты.

Ограничения:
- не анализируй стиль, если он не влияет на релиз;
- не предлагай крупный рефакторинг;
- сфокусируйся на рисках выкладки.

Формат ответа:
1. Можно ли выкладывать.
2. Блокирующие проблемы.
3. Неблокирующие проблемы.
4. Что проверить вручную.
5. Что откатить или поправить перед релизом.

Такой промпт помогает не смешивать релизную проверку с обычным улучшением кода.

Промпт для ревью формы

Формы — частый источник ошибок: валидация, CSRF, XSS, права, потеря данных, плохая обработка ошибок.

Проведи code review формы.

Контекст:
[описать проект, стек, назначение формы]

Форма:
[описать форму или указать файлы view/controller/service]

Проверь:
- server-side валидацию;
- CSRF-защиту;
- экранирование вывода;
- сохранение введённых значений при ошибке;
- понятные сообщения об ошибках;
- проверку прав доступа;
- защиту от изменения чужих данных;
- обработку пустых и некорректных значений;
- редирект после успешного сохранения;
- flash-сообщения;
- загрузку файлов, если она есть.

Ограничения:
- не меняй UI без необходимости;
- не переписывай форму с нуля;
- не отключай существующую защиту;
- сначала дай список проблем.

Формат ответа:
таблица: критичность, место, проблема, риск, исправление.

Такой промпт подходит для форм регистрации, профиля, статей, промптов, комментариев, заказов и настроек.

Промпт для ревью API

API нужно проверять отдельно, потому что там важны статусы, формат ответа, авторизация и обработка ошибок.

Проведи code review API-метода.

Контекст:
[стек, способ авторизации, формат API]

Endpoint:
[метод и URL]

Код:
[вставить код или указать файлы]

Проверь:
- авторизацию;
- права доступа;
- валидацию входных данных;
- корректные HTTP-статусы;
- формат JSON-ответов;
- обработку ошибок;
- отсутствие утечки внутренних ошибок;
- защиту от изменения чужих данных;
- идемпотентность, если она нужна;
- совместимость с текущим фронтендом.

Ограничения:
- не меняй контракт API без явной необходимости;
- не предлагай новую архитектуру API;
- не переписывай метод полностью, если можно исправить точечно.

Формат ответа:
1. Критичные проблемы.
2. Проблемы среднего уровня.
3. Улучшения.
4. Рекомендованные проверки.

Такой промпт особенно полезен перед подключением frontend-логики.

Промпт для ревью загрузки файлов

Загрузка файлов — зона повышенного риска.

Проведи security review загрузки файлов.

Контекст:
пользователь может загружать изображения. Файлы сохраняются на сервере и потом отображаются на сайте.

Проверь:
- проверку MIME-типа;
- проверку расширения;
- ограничение размера файла;
- генерацию безопасного имени файла;
- запрет выполнения загруженных файлов;
- путь сохранения;
- защиту от path traversal;
- обработку ошибок загрузки;
- удаление старых файлов, если нужно;
- права доступа к файлам;
- вывод загруженного файла на странице.

Ограничения:
- не предлагай хранение в облаке, если задача решается локально;
- не переписывай весь upload-модуль;
- не отключай текущие проверки;
- сначала дай список рисков.

Формат ответа:
таблица: критичность, место, риск, сценарий атаки, исправление.

Такой промпт стоит использовать для аватаров, обложек, галерей, документов и любых пользовательских файлов.

Промпт для проверки frontend-кода

Frontend review — это не только внешний вид. Важно проверить состояния, данные, XSS и UX-ошибки.

Проведи review frontend-кода.

Контекст:
[описать страницу, стек и назначение интерфейса]

Код:
[вставить код или указать файлы]

Проверь:
- обработку loading-состояний;
- обработку ошибок;
- пустые состояния;
- защиту от XSS при выводе пользовательских данных;
- доступность базовых элементов;
- адаптивность;
- дублирование логики;
- слишком сложные компоненты;
- зависимость UI от нестабильных данных;
- не ломает ли код существующие сценарии.

Ограничения:
- не предлагай полный редизайн;
- не добавляй новые библиотеки без необходимости;
- не меняй backend-контракт;
- сначала дай список проблем.

Формат ответа:
таблица: критичность, место, проблема, влияние на пользователя, рекомендация.

Такой промпт подходит для страниц, компонентов, форм, фильтров, таблиц и AJAX-логики.

Как просить ИИ исправить найденные проблемы

После ревью не нужно просить «исправь всё». Лучше выбрать конкретные пункты.

Плохой промпт:

Теперь исправь все проблемы.

Лучше:

Исправь только проблемы с критичностью Critical и High из предыдущего ревью.

Ограничения:
- не трогай проблемы Medium и Low;
- не меняй архитектуру шире необходимого;
- не добавляй зависимости;
- сохрани существующее поведение;
- если нужна миграция, создай отдельный SQL-файл.

После исправлений:
кратко укажи, какие проблемы исправлены, какие файлы изменены и что проверить.

Такой подход снижает риск лишних изменений.

Как проверять ответ ИИ после code review

ИИ может ошибаться. Поэтому результат ревью нужно проверять критически.

Плохие признаки ответа:

Хороший ответ выглядит так:

Critical | app/Services/PostService.php: updatePost()
Проблема: обновление записи выполняется только по post_id, без проверки user_id.
Риск: пользователь может изменить чужую запись, если узнает id.
Рекомендация: добавить проверку владельца записи или включить user_id в WHERE при update.

Такое замечание можно проверить и исправить.

Чеклист хорошего промпта для code review

Перед отправкой промпта проверьте:

Если промпт проходит этот чеклист, ревью будет заметно полезнее.

Частые ошибки в промптах для code review

Ошибка 1. Слишком общий запрос

Плохо:

Проверь код.

Лучше:

Проведи security review формы сохранения статьи: проверь CSRF, XSS, SQL-инъекции, права доступа, валидацию и сохранение пользовательских данных.

Ошибка 2. Нет контекста проекта

Плохо:

Проверь этот контроллер.

Лучше:

Проверь этот контроллер в контексте PHP-проекта без фреймворков, где авторизация работает через сессии, а пользовательские данные должны быть изолированы по user_id.

Ошибка 3. Просить сразу исправить всё

Плохо:

Проверь и исправь.

Лучше:

Сначала проведи ревью и не меняй код. Дай список проблем по критичности. Исправления будут отдельным этапом.

Ошибка 4. Не разделять критичность

Плохо:

Напиши, что не так.

Лучше:

Раздели проблемы на Critical, High, Medium и Low. В начало поставь то, что может привести к взлому, потере данных или поломке критичного сценария.

Ошибка 5. Не требовать конкретики

Плохо:

Дай рекомендации.

Лучше:

Каждую рекомендацию привяжи к конкретному файлу, функции или фрагменту кода. Не давай общие советы без места применения.

Ошибка 6. Смешивать разные виды ревью

Плохо:

Проверь безопасность, архитектуру, дизайн, SEO, скорость и всё остальное.

Лучше:

Сначала проверь только безопасность. Затем отдельным запросом проверим архитектуру.

Ошибка 7. Не учитывать существующую архитектуру

Плохо:

Скажи, как лучше переписать.

Лучше:

Предлагай исправления внутри текущей архитектуры. Не предлагай фреймворк, смену стека или полный переписанный модуль, если проблему можно решить точечно.

FAQ

Можно ли полностью доверять ИИ в code review?

Нет. ИИ полезен как дополнительный проверяющий, но не заменяет разработчика. Он может пропустить проблему, неправильно понять контекст или увидеть риск там, где его нет. Важные выводы нужно проверять вручную.

Что лучше проверять сначала: безопасность или архитектуру?

Перед релизом лучше начинать с безопасности и регрессий. Архитектурные улучшения можно делать отдельно, если они не блокируют запуск.

Нужно ли давать ИИ весь проект?

Не всегда. Часто лучше дать конкретный файл, diff или модуль. Если контекста не хватает, можно попросить сначала определить связанные файлы, а не проверять всё сразу.

Почему ИИ даёт слишком общие советы?

Обычно потому, что промпт слишком общий. Нужно указать стек, область проверки, список рисков, критичность и формат ответа.

Можно ли просить ИИ сразу исправить найденные проблемы?

Можно, но безопаснее сначала получить список проблем. Затем выбрать критичные и дать отдельный промпт на исправление. Это снижает риск лишних изменений.

Какой формат ответа лучше для code review?

Лучше всего таблица: критичность, место, проблема, риск, рекомендация. После таблицы — список приоритетных исправлений и ручных проверок.

Итог

Code review через ИИ полезен только тогда, когда задача поставлена точно. Команда «проверь код» слишком размыта: она не задаёт фокус, критерии риска и формат результата.

Сильный промпт для code review должен включать контекст проекта, область проверки, цель ревью, список рисков, шкалу критичности, ограничения и понятный формат ответа. Отдельно важно запретить автоматические правки на первом этапе и требовать привязку каждой проблемы к конкретному месту в коде.

ИИ может ускорить ревью, найти неочевидные проблемы и помочь структурировать исправления. Но финальное решение остаётся за разработчиком: каждую критичную рекомендацию нужно проверять на реальном коде, данных и сценариях проекта.