Claude code review — команда Claude Code для разбора текущего diff или выбранного PR на ошибки корректности. Разработчик задаёт область и уровень проверки, получает замечания, сверяет их с исходниками и тестами, затем передаёт решение ревьюеру. Это отдельный шаг проверки изменений внутри рабочего сеанса; общий маршрут от issue до PR описывает другая статья о работе ИИ-агента с репозиторием.
Роль команды
Официальная справка Claude Code описывает `/code-review` как проверку текущего diff, ветки, файла или PR на ошибки корректности. Замечание команды — повод открыть участок кода и проверить сценарий, а решение о приёмке остаётся за человеком.
Когда правка уже лежит в рабочем дереве, команда помогает собрать возможные ошибки до отправки результата коллегам. Она смотрит на изменение и окружающий код, формулирует замечания к логике, пограничным случаям и поведению. Объём анализа зависит от выбранного уровня усилия и доступного контекста. Проверка даёт дополнительный взгляд на diff; качество подтверждает ручная приёмка. Отсутствие замечаний говорит лишь о результате конкретного запуска с конкретным входом.
Здесь интересует именно локальный интерфейс команды. В обзоре Claude Code для команды полезно смотреть организацию совместной работы, а материал о жизненном цикле issue, ветки и PR охватывает более широкий путь. Для нашей задачи нужны другие контрольные точки: выбрать diff, понять цель правки, получить адресные замечания, проверить их и повторить профильные тесты. Публикация комментариев в PR составляет отдельное действие с отдельным решением.
Важно различать локальную `/code-review` и управляемый сервис Code Review для GitHub PR. Официальная документация описывает оба сценария на одной странице, но их запуск и размещение результата различаются. Локальная команда показывает вывод в сеансе Claude Code; публикацию замечаний запрашивают отдельным параметром. Встроенный обзор изменения удобен как часть ручного ревью, когда исходники доступны разработчику и у команды есть собственные критерии приёмки.
Границы diff
Перед запуском разработчик записывает цель изменения обычными словами: какое поведение должно появиться, какое должно сохраниться и какие файлы ожидаются в diff. Затем он открывает собственный список изменённых файлов и сравнивает его с задачей. Если в рабочем дереве лежат посторонние правки, их отделяют до проверки. Так замечания относятся к понятной области, а ревьюер позже сможет связать вывод команды с конкретной ревизией.
По официальному справочнику команд, вызов без цели проверяет изменения ветки относительно upstream вместе с правками рабочего дерева. Допустимы и другие цели: путь к файлу, ветка, диапазон ревизий либо номер PR. Выбор цели меняет вход анализа, поэтому его фиксируют в заметке к проверке. При работе с PR отдельно убедитесь, что локальные права позволяют читать нужный репозиторий и его содержимое.
Разработчику полезно подготовить ожидаемые риски, особенно если правка затрагивает публичный интерфейс, обработку ошибок или работу с данными. Этот список служит эталоном для оценки замечаний: команда могла обнаружить новый риск, но могла пропустить известный. Сверка по эталону удерживает внимание на задаче и помогает оценивать содержание замечаний. В тестовом репозитории можно заранее подобрать изменение с понятной ошибкой и проверить, насколько объяснение связано с реальным кодом.
Сохраните цель правки, выбранный diff и список проверяемых сценариев рядом с результатом. Ревьюер должен видеть, какую именно версию кода анализировали.
Запуск проверки
Команду вводят в сеансе Claude Code из репозитория, где находится выбранное изменение. Базовый вызов — `/code-review`; уровень можно указать словом, например `/code-review high`. Для отдельного PR к команде добавляют его номер после уровня. В документации также есть другие виды цели, поэтому перед запуском проверьте синтаксис под нужный объект. Ввод происходит в интерфейсе Claude Code.
- Откройте тестовую ветку и зафиксируйте текущий diff. Отделите файлы, которые относятся к другой задаче, и сохраните базовую ревизию для сверки.
- Выберите цель проверки: текущий diff либо разрешённый PR. Запишите уровень усилия и цель так, чтобы коллега смог повторить тот же запуск.
- Вызовите `/code-review` в сеансе Claude Code. Ожидайте список замечаний, связанных с изменением; форму вывода сверяйте с доступным интерфейсом.
- Для каждого замечания откройте файл и конкретный участок. Проверьте заявленный сценарий, существующие тесты и ожидаемое поведение задачи.
- Исправляйте подтверждённые проблемы через обычный маршрут разработки. После правки просмотрите новый diff и повторите относящиеся к задаче тесты.
Параметр `--fix` в справочнике применяет найденные изменения к рабочему дереву. В описанном пилоте разработчик сначала оценивает замечания и сам выбирает правку. Параметр `--comment` публикует вывод в PR или запросе на слияние; его используют лишь по явному решению ответственного за публикацию. Оба действия затрагивают код либо внешнюю площадку, поэтому их отделяют от чтения результата.
Протокол будущего пилота полезно строить вокруг самого вопроса: помогает ли команда найти ошибку в diff и достаточно ли доказательств для человека. В него входят цель вызова, найденный путь, суть риска и результат ручной проверки. Этот набор пригодится для сравнения с обычным ревью команды без обещаний, что любая категория ошибок будет обнаружена.
Нужен маршрут проверки diff для вашей команды?
Разбор замечаний
Хорошее замечание объясняет, какой вход приводит к проблеме, где это видно в коде и какое поведение нарушается. Разработчик открывает названный файл и проверяет цепочку вызовов. Для полного сравнения набора файлов или результатов тестов используют парсер либо скрипт. Языковая модель формулирует гипотезу о причине и возможном исправлении, а человек сверяет её с исходниками и требованиями. Вопрос о полезности пункта решается по воспроизводимому поведению.
| Сигнал | Проверка команды | Решение |
|---|---|---|
| Путь и участок | Открыть файл в выбранной ревизии, сверить строки и контекст | Принять либо отклонить замечание |
| Описание ошибки | Сопоставить вход, ветвление и ожидаемый результат | Назначить исправление при подтверждении |
| Предложенная правка | Прочитать новый diff и проверить соседние вызовы | Передать на ревью после тестов |
| Пустой отчёт | Сверить эталонные риски и покрытие тестами | Продолжить ручную приёмку |
Ложный сигнал также стоит фиксировать кратко: он показывает, какие предположения модель сделала о проекте. При спорном замечании полезно спросить коллегу, который владеет изменённым модулем, и сопоставить ответ с контрактом функции. Принятие замечания без такой проверки может привести к лишней правке. Отклонение требует понятного основания, особенно когда речь идёт об обработке данных или доступе. Такая запись делает итог ревью проверяемым для следующего участника.
Если команда предложила исправление, оцените и само изменение, и возможные побочные эффекты. Тест на исходную ошибку должен воспроизводить ожидаемый результат после правки. Дополнительные проверки охватывают соседние ветви, которые могла задеть замена условия или типа. Затем человек открывает обновлённый diff целиком и сверяет его с исходным заданием. Результат работы модели служит входом для инженерного решения.
Критерии приёмки
Пилот на тестовом репозитории можно считать подготовленным, когда известны права доступа, цель проверки, эталонные ошибки и набор тестов. После предлагаемого запуска команда сможет оценить, какие замечания подтвердились, какие оказались лишними и где понадобился дополнительный контекст. Эти критерии предназначены для будущей проверки. Для сравнения запусков сохраняйте ревизию и выбранный уровень усилия; иначе разные входы дадут результаты, которые трудно сопоставить.
Финальное решение принимает назначенный ревьюер. Он читает diff, проверяет ответы на важные замечания и смотрит на результаты профильных тестов. При работе с закрытым кодом доступ к репозиторию и действиям публикации проверяют средства среды и сервера, а текст запроса к модели лишь описывает намерение. Если команда получает отказ в чтении или публикации, сначала разбирают назначенные полномочия. Расширять доступ ради удобства отдельного запуска стоит лишь после решения владельца.
Расходы на такой маршрут зависят от выбранного режима, объёма изменений, состава репозитория и частоты проверок. Тариф и условия доступа проверяют на актуальной странице поставщика; бюджет команды обсуждают вместе с затратами на ручное ревью и тесты. Для внедрения в общий процесс полезно заранее решить, кто запускает команду, кто рассматривает замечания и кто имеет право публиковать их. Эти роли можно описать в проекте ИИ-агента для разработки с учётом правил команды.
Признаком готовности служит журнал решений по замечаниям и понятный итог: принята правка, запрошено исправление либо нужен дополнительный тест. Даже качественный отчёт команды оставляет ответственность у разработчика и ревьюера. Повторный запуск после изменения кода дополняет проверку, но предыдущий вывод относится к прежнему diff. Сопоставление версий помогает увидеть, закрыт ли исходный риск и появились ли новые вопросы.