Codex Review помогает проверить изменения кода перед отправкой: выберите нужную разницу в Git, запустите /review, затем проверьте каждый найденный риск по файлу и воспроизводимому сценарию. Нужны проект в Git и понятная граница изменений. Ревью сообщает замечания и само по себе не исправляет рабочие файлы. Такой порядок описан в официальной документации OpenAI по Code review.
Какие изменения стоит передать на проверку
Сначала решите, что именно изменилось. Codex предлагает проверку незакоммиченных файлов, разницы с базовой веткой или отдельного коммита. В приложении есть панель, где можно смотреть незастейдженные, застейдженные изменения, ветку или последний ход помощника. Это разные наборы файлов; проверять случайно выбранный набор опасно, если часть правок осталась за его пределами. Официальный список областей ревью различает эти режимы.
- Незакоммиченные изменения: проверяйте рабочую папку до фиксации результата.
- Разница с базовой веткой: проверяйте всю ветку перед объединением.
- Один коммит: проверяйте конкретную порцию изменений.
- Последний ход помощника: смотрите, что внесено именно этим ходом; это не весь проект.
Практическое правило выбора: для завершённой задачи берите ветку или весь набор незакоммиченных изменений; для ответа на замечание после маленькой правки берите узкую область, но затем ещё раз проверьте общий итог. Если работаете с несколькими репозиториями, уточните нужный репозиторий в панели. OpenAI предупреждает, что обзор показывает состояние Git, включая ваши собственные правки и чужие незакоммиченные изменения, а не только то, что написал Codex. Источник.
План работает, когда в нём есть практика, а быстрее всего она приходит с первым проектом. На бесплатном вебинаре его собирают за один вечер.
Начать с практикиКак запустить Codex Review в приложении
Откройте проект, который находится внутри Git-репозитория. В Codex откройте панель изменений, чтобы понять размер и состав разницы. Затем введите /review и выберите проверку относительно базовой ветки либо незакоммиченных изменений. Укажите в сообщении область и критерии, например: «Проверь изменённую обработку заказа на потерю данных и ошибки при повторном запросе; укажи файл, строку и сценарий». Официальная инструкция описывает этот запуск и уточняет, что команда доступна в Git-проекте.
- Убедитесь, что открыта правильная папка проекта и нужная ветка.
- Откройте разницу и найдите файлы, которые реально должны попасть в проверку.
- Выберите область
/review: базовая ветка или незакоммиченные изменения. - Сформулируйте конкретные риски и ожидаемое поведение, особенно для платежей, данных и прав доступа.
- Получите замечания и проверьте каждое по исходному коду и тестам.
Если удобнее терминал, интерактивная команда /review открывает готовые варианты проверки, а codex review запускает неинтерактивную проверку. У codex review есть цели --uncommitted, --base и --commit; выбирайте одну цель либо задайте собственные инструкции. Эти варианты перечислены в официальном справочнике команд OpenAI. Для большинства задач достаточно приложения: оно позволяет сразу открыть замечание в контексте строки.
Правило ревью: замечание Codex является гипотезой об ошибке. Принимайте его только после проверки затронутого пути и условий, при которых ошибка проявляется.
Чтобы двигаться дальше, полезно один раз увидеть весь путь: от идеи, описанной словами, до работающего проекта. Именно это показывают на бесплатном эфире по вайбкодингу, без опыта в программировании.
Увидеть путь целикомКак понять, полезно ли найденное замечание
Для каждого вывода пройдите короткий фильтр: указан ли конкретный файл и строка, есть ли сценарий ошибки, достижим ли этот сценарий в текущем коде, какое требование нарушено и чем это можно проверить. Если Codex пишет «возможная проблема» без входных условий, попросите показать путь выполнения и минимальный пример. Если вывод опирается на старую версию файла, обновите область ревью и проверьте свежую разницу.
Это второй практический элемент: триаж результата. Критичные замечания о потере данных, доступе и неверных расчётах проверяйте первыми. После них идут ошибки пользовательского пути и совместимости. Стиль и переименование оставьте напоследок. Не превращайте каждый совет в правку: изменение должно устранять подтверждённую проблему и не расширять задачу.
Сравните замечание с тестами и с реальным поведением. Например, если сказано, что повторный запрос создаст дубли, воспроизведите два одинаковых вызова на тестовых данных и проверьте число записей. Если найдено нарушение доступа, проверьте обычную и ограниченную роль на тестовом окружении. Проверка гипотезы важнее уверенного тона ответа.
По теме: Codex и GitHub: безопасная работа с репозиторием и PR
Как внести исправление и повторить проверку
После подтверждения ошибки исправьте минимальный участок, добавьте проверку для сценария и откройте новую разницу. Попросите Codex проверить именно внесённое исправление, затем пересмотрите итог ветки. По документации OpenAI результат ревью можно обсудить в том же чате; если попросить Codex применить исправления, работают обычные разрешения рабочего пространства. Сам запуск ревью рабочее дерево не меняет.
Когда изменение касается конфигурации или запуска, дополните обзор профильной проверкой: тестом, сборкой, ручным проходом интерфейса либо проверкой конфигурации. Ревью может не увидеть проблему, которая возникает только в рабочем окружении. В разборе проверки изменений через Claude Code показан похожий этап проверки перед объединением, но команды и интерфейс другого инструмента переносить в Codex буквально не нужно.
Какие границы у Codex Review
Команда /review не появляется, если открытый проект не находится в Git-репозитории. В этом случае сначала определите источник кода и способ сравнения изменений; не создавайте репозиторий лишь ради формального запуска проверки. Официальная документация прямо указывает условие Git-проекта. Если нужно изучить присланный файл без Git, можно попросить обычный анализ кода с явным описанием критериев и ограничений, но это уже не тот же режим обзора разницы.
Ревью разницы не заменяет проверку всей системы. Неизменённый файл может содержать старую ошибку, а новая ошибка может проявиться только на реальном сервере, в данных или в интеграции. Если задача касается безопасности всего репозитория, отделите её от обычного обзора изменений: статья о Codex Security объясняет отдельный инструмент и его область. Для обычной правки кода достаточно зафиксировать границы ревью, перепроверить находки и запустить подходящие тесты.
Частые вопросы
Codex Review сам изменяет файлы?
Нет. По описанию OpenAI, режим /review сообщает приоритетные замечания без изменения рабочего дерева. Исправление становится отдельным действием.
Что выбрать: проверку ветки или незакоммиченных изменений?
Если задача уже оформлена веткой, сравните её с базовой. Если правки ещё лежат в рабочей папке, выберите незакоммиченные изменения. Сначала посмотрите, какие файлы реально вошли в выбранную разницу.
Почему /review не появляется?
Проверьте, открыт ли проект внутри Git-репозитория. Это условие команды в официальной справке.
Можно ли доверять отсутствию замечаний?
Нет. Пустой результат означает, что ревью не сообщило о проблеме в выбранной области. Он не подтверждает работу всех сценариев; запустите тесты и проверьте критичные пути отдельно.
Проверка изменений становится полезнее, когда у вас есть маленький рабочий проект. На бесплатном вебинаре покажем, как собрать такой проект с ИИ и проверить его перед публикацией.
Записаться на вебинар