Промпт «Senior code reviewer» — находит баги, узкие места, edge cases

Большинство ревью кода от LLM тонут в стилистических придирках и пропускают реальные баги. Этот промпт заставляет модель сортировать находки по серьёзности, выдавать только то, что выживет строгое ревью тимлида, и цитировать точные номера строк, чтобы вы могли быстро проверить каждую находку.

Категория: codingРекомендуется для: claude / chatgpt / cursor

prompt

Ты — senior staff engineer, ревьюишь диф ниже. Твоя цель — поймать то, что реально выживет строгое ревью тимлида, а не линтер-шум.

Правила ревью:
1. Сортируй каждую находку в одну из категорий: BLOCKER, MAJOR, MINOR, NIT.
2. По умолчанию выдавай только BLOCKER и MAJOR. Подавляй MINOR и NIT, если я явно их не запрашиваю.
3. Для каждой находки цитируй точный путь к файлу + диапазон номеров строк. Затем объясни: (а) что не так, (б) режим отказа в проде, (в) предложенное исправление.
4. Если ты уверен в реальности проблемы меньше чем на 80%, помечай находку [low-confidence] и объясни, какой дополнительный контекст позволил бы её верифицировать.
5. Заверши одним абзацем общего резюме: ship-it / ship-with-followups / do-not-ship.

НЕ комментируй:
- Предпочтения по именованию, если они активно не вводят в заблуждение.
- Форматирование/пробелы, если используется форматтер.
- Гипотетические оптимизации, которые ты не можешь привязать к измеренному hot path.
- Паттерны, которые в кодовой базе уже используются в других местах (это стилистическая согласованность, а не баг).

Диф для ревью:

[вставьте сюда ваш unified diff или содержимое файлов]

Когда это использовать

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

Советы по моделям

claude: Claude (Sonnet 4.6 или Opus 4.7) обычно даёт самую вдумчивую сортировку. Вставляйте диф в кодовый блок; длинный контекст хорошо тянет ревью целых PR.
chatgpt: GPT-5 / GPT-4o склонны агрессивнее флагировать стиль. Правило «подавлять MINOR и NIT» выше держит его в рамках.
cursor: В Cursor сохраните это как запись .cursorrules или вставьте в composer. Хорошо сочетается с @file-ссылками.

Пример вывода

BLOCKER: src/auth/session.ts:42-58
  - что: Сравнение сессионного токена через ===, без constant-time compare.
  - режим отказа: Уязвимо к timing-атаке при удалённом логине.
  - исправление: Переключиться на crypto.timingSafeEqual() над парой буферов.

MAJOR: src/auth/session.ts:73 [low-confidence]
  - что: Refresh-токен пишется в localStorage.
  - режим отказа: Риск XSS-эксфильтрации, если на страницу попадает несанированный пользовательский контент.
  - исправление: Перенести в httpOnly cookie, если клиенту не нужно читать токен. (low-confidence: не видно, как фронт потребляет этот токен.)

Резюме: ship-with-followups. Constant-time исправление обязательно до мерджа; место хранения — follow-up issue, который стоит завести независимо от этого PR.

Как это работает

Почему большинство ИИ-ревью кода бесполезны

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

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

Связка с вашим CI

Запускайте этот промпт как шаг «второго мнения» в вашем PR-workflow — а не как gating-проверку. Модели всё ещё галлюцинируют, особенно на межфайловых инвариантах и на коде, зависящем от соглашений фреймворка, которые вы не вставили. Используйте вывод как список вещей для проверки, а не как список проблем для механического исправления.

Если хотите запихнуть в CI, выводите находки как JSON (модифицируйте промпт: «верни JSON-массив с полями severity, path, lineStart, lineEnd, what, fix, confidence»). Затем постите BLOCKER/MAJOR в PR одним комментарием с явным заголовком «AI assist — verify before acting».

Адаптация промпта под вашу команду

Добавьте раздел «Контекст кодовой базы» над дифом — вставьте 5–10 строк, описывающих ваш стек, конвенции тестов и неочевидные инварианты (например, «все записи в БД идут через src/db/withTx, никогда через raw client»). Без этого модели промахиваются по специфичным конвенциям кодовой базы.

Если у команды есть известные слабые места (race conditions в job runner, N+1 запросы в конкретном сервисе), добавьте строку «Особенно следи за: …». Модель повысит вес этих классов багов и с большей вероятностью отметит их, когда они есть.

Часто задаваемые вопросы

›Можно ли использовать это на закрытом коде?

Да, но сначала проверьте политику работодателя. Сам промпт безвреден; важно, разрешено ли вам вставлять ваш код в используемую модель. Корпоративные планы Claude и ChatGPT обычно не тренируются на ваших входах; потребительские планы — могут.

›Зачем подавлять MINOR и NIT находки?

Потому что на практике они создают усталость от ревью. После третьей заметки «рассмотри извлечение этого в функцию» вы перестаёте читать. Подавление держит сигнал BLOCKER/MAJOR острым. Включайте обратно через «show all findings including MINOR and NIT», когда хотите глубокое ревью.

›Какой длины может быть диф?

Claude Sonnet/Opus и GPT-5 спокойно тянут 50К+ токенов дифа. Для очень больших PR разделите ревью по директориям (сначала src/auth, потом src/billing), чтобы модель думала о каждой подсистеме изолированно.

›А что насчёт ревью по безопасности?

Этот промпт ловит очевидные проблемы крипто/хранения/SSRF, но не заменяет ревью безопасности на коде авторизации или платежей. Для таких путей запускайте этот промпт и отдельный security-review промпт (опубликуем отдельно).

›Можно ли ревьюить несколько файлов сразу?

Да — вставляйте диф со всеми файлами. Он разумно справляется с межфайловыми инвариантами в одной вставке; для проблем, охватывающих несколько PR (например, «согласовано ли это с тем, как фича-флаги гейтятся в других местах?»), включайте несколько репрезентативных выдержек из тех файлов.

›Стоит ли доверять [low-confidence] находкам?

Относитесь к ним как к «изучить до действий». Около половины low-confidence находок реальны, но модель не смогла их проверить; другая половина — неверное прочтение. Флаг — это честный сигнал, а не повод игнорировать находку.

›Почему нужно указывать режим отказа?

Потому что «это неправильно» бесполезно без «это упадёт на unicode-вводе». Строка режима отказа сообщает приоритет: исправление, предотвращающее edge case 1-на-миллион, — это не то же, что предотвращающее ежедневный prod-инцидент.

›Как использовать это конкретно в Cursor?

Сохраните тело промпта в .cursorrules в корне репозитория или вставьте в composer с @file-ссылками на файлы под ревью. Cursor будет держать правила активными для этого проекта.