Ревью кода командой /review

Агент, который только что написал код, плохо его ревьюит: в его контексте вся история рассуждений, и он видит то, что хотел написать. Команда /review решает это так же, как в команде людей, — отдельным ревьюером. В уроке — режимы ревью, свои критерии и порядок работы с находками.

Как устроен /review

/review запускает отдельного ревьюера. Он читает выбранный дифф и возвращает приоритизированный список конкретных замечаний. Рабочее дерево при этом не меняется — ревьюер ничего не правит. В CLI результат появляется отдельным ходом в переписке. По справочнику команд ревьюер в первую очередь смотрит на изменения поведения и недостающие тесты.

В CLI четыре режима:

В расширении для IDE и в ChatGPT desktop app доступны первые два режима. В IDE команда появляется, только если открытый проект — git-репозиторий.

Когда запускать

Перед коммитом — Review uncommitted changes. Дешёвая проверка, которая ловит забытый dd(), отладочный вывод и очевидные ошибки.

Перед MR — Review against a base branch с main. Ревьюер видит ветку целиком, как её увидит коллега. Так ловится то, что не заметно по отдельным коммитам: метод, добавленный на первом шаге и ставший ненужным на пятом.

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

По умолчанию ревью идёт в текущем чате. В расширении для IDE его можно выносить в отдельный чат настройкой "chatgpt.reviewDelivery": "detached", в desktop app есть такая же настройка в разделе Code review.

Свои критерии

Режим Custom review instructions принимает текст. Он полезен, когда вы знаете, где риск:

Проверь только миграции и модели: обратная совместимость схемы,
откат миграций, индексы под новые запросы, mass assignment
($fillable / $guarded) у изменённых моделей.

Другие полезные фокусы: безопасность (SQL, вывод без экранирования в Twig через |raw, проверка прав в AJAX-обработчиках), производительность (N+1 в новых запросах), изменения поведения в рефакторинге — их там быть не должно.

Командные критерии не стоит каждый раз набирать руками. Руководство OpenAI по лучшим практикам предлагает завести code_review.md и сослаться на него из AGENTS.md — тогда Codex учитывает его при ревью:

## Ревью
При ревью кода следуй docs/code_review.md.

# Критерии ревью

## Блокирующие
- SQL — только через query builder или с биндингами; конкатенация с вводом пользователя — P0.
- Пользовательские данные в Twig выводятся без |raw; |raw — только с обоснованием.
- AJAX-обработчики компонентов проверяют права, а не только наличие сессии.
- Миграции обратимы: метод down() реализован.

## Важные
- Новая бизнес-логика покрыта тестом.
- Новые зависимости упомянуты в описании MR.

## Не комментировать
- Форматирование и стиль — это проверяет линтер в CI.

Последний раздел важен. В документации по правилам ревью OpenAI советует оставлять форматирование, линт и другие механические проверки CI, а в правилах держать то, что машинно не проверить.

Отдельная модель для ревью

По умолчанию ревью идёт на модели текущей сессии. Ключ review_model задаёт другую — например, более сильную для ревью, если для рутины вы выбрали быструю:

review_model = "gpt-6.1-sol"

Название модели — на октябрь 2026; актуальный список — в /model и в документации по моделям.

codex review в скриптах

Та же проверка есть в неинтерактивном виде — для git-хуков, скриптов и CI:

codex review --uncommitted        # staged, unstaged и новые файлы
codex review --base main          # ветка против main
codex review --commit a1b2c3d     # один коммит
codex review "Проверь только безопасность AJAX-обработчиков"

Цели взаимоисключающие: выбирается одна из --uncommitted, --base, --commit или текст инструкции (- читает инструкцию из stdin). Как встроить автоматическое ревью в GitLab CI — тема курса по автоматизации: «Автоматическое ревью merge request».

Работа с находками

Находка ревьюера — гипотеза, а не приговор. Порядок такой.

1. Проверьте каждую. Откройте место и поймите, реальна ли проблема. Документация Codex по ревью советует сверять находку с актуальным диффом, ожидаемым поведением и тестами, прежде чем решать, что её надо чинить.
2. Отсейте ложные. Если ревьюер ошибся из-за неочевидного контекста («этот метод вызывается только из консольной команды»), это кандидат на строку в AGENTS.md: в следующий раз ревьюер будет знать.
3. Чините выборочно. Не «исправь всё», а «исправь находки 1 и 3, вторую не трогай — это намеренно». Исправления вносит уже основной агент, по обычным правилам песочницы и одобрений.
4. Повторите ревью после исправлений.

Ревью в GitLab и GitHub

Кроме локального /review, у Codex есть облачное ревью pull request в GitHub и merge request в GitLab (интеграция с GitLab — в бете): по комментарию @codex review или автоматически. Там правила пишутся в разделе ## Code Review Rules в AGENTS.md: общие — в корневом файле, правила отдельного модуля — во вложенном, рядом с его кодом. Codex применяет корневой и все вложенные файлы, которые покрывают изменённый файл. Подключение — задача тимлида, оно разобрано в курсе для тимлидов: «Codex как ревьюер в GitLab и GitHub».