Claude Code Review: как проверить изменения перед merge

Claude Code Review бывает автоматическим сервисом Anthropic или ручным ревью в обычной сессии. Ниже второй вариант: вы задаёте базу сравнения, запрещаете правки, получаете доказательные замечания, перепроверяете diff и тесты, а исправления выполняете отдельно.

Чем ревью отличается от просьбы исправить код

Ревью ищет подтверждаемые дефекты, а не переписывает решение по вкусу модели. Сервис Anthropic Code Review проверяет логику, безопасность, регрессии и пограничные случаи, но не одобряет и не блокирует pull request автоматически (документация).

• Ревью читает изменения и соседний код, но не меняет файлы.
• Замечание содержит файл, строку, сценарий сбоя и способ проверки.
• Предложение улучшить стиль отделяется от ошибки поведения.
• Исправление начинается только после подтверждения замечания человеком или тестом.
• Решение о merge учитывает CI, ручную проверку и правила проекта, а не только ответ модели.

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

Сначала настройте безопасный процесс Claude и Git: база сравнения и состав изменений должны быть понятны до ревью.

Сначала зафиксируйте базу и область diff

Claude должен знать, что сравнивать. Не просите проверить «весь проект», если решение касается нескольких файлов. Перед запуском обновите сведения об удалённой ветке, убедитесь, что рабочая папка понятна, и посмотрите статистику diff. Команда с origin/main подходит только когда основной веткой действительно является main; в другом проекте замените её на фактическую базу.

git fetch origin
git status --short
git diff --stat origin/main...HEAD
git diff --name-only origin/main...HEAD
git log --oneline origin/main..HEAD

В списке должны остаться только файлы текущей задачи. Чужие изменения, сгенерированные файлы и черновики отделите до ревью. В GitHub проверяйте вкладку Files changed и привязывайте замечания к строкам (официальная инструкция).

Дайте Claude контракт ревью

Первый практический элемент, контракт из семи полей. Он ограничивает область, формат результата и право на изменение файлов. Запустите Claude Code в режиме планирования, чтобы модель могла читать проект и выполнять разрешённые проверки, но не редактировала исходники. Plan mode предназначен именно для анализа до изменений (Anthropic, permission modes).

claude --permission-mode plan
Цель: проверить ветку перед merge в origin/main.
Область: только diff origin/main...HEAD и непосредственно вызываемый им код.
Контекст: задача PR, критерии готовности и команды тестов перечислены ниже.
Искать: ошибки поведения, регрессии, пропущенные граничные случаи, риски безопасности.
Не делать: не менять файлы, не создавать коммиты, не отправлять данные и не запускать деплой.
Формат: важность, файл:строка, сценарий сбоя, доказательство, способ проверки.
Отсев: не сообщать о стиле, если он не нарушает явное правило проекта.

Добавьте критерии именно этой задачи. Для формы это обязательные поля, повторная отправка и ошибка сети. Для API это авторизация, схема ответа и поведение при тайм-ауте. Для миграции это совместимость назад, повторный запуск и безопасный откат. Без критериев Claude может найти правдоподобные замечания, не связанные с результатом PR.

Если команда использует CLAUDE.md, положите туда общие правила проекта, а не описание одной проверки. Управляемый сервис Anthropic Code Review дополнительно поддерживает REVIEW.md для правил именно ревью (официальная настройка Review). В ручной сессии те же ограничения можно вставить непосредственно в контракт.

По теме: Cowork или Claude Code: что выбрать для работы в 2026

Разделите замечания и автоматические правки

После ответа не просите «исправить всё». Сначала перенесите замечания в таблицу решений. Это второй практический элемент: каждое замечание получает статус, доказательство и владельца решения.

• Подтверждено: сценарий воспроизводится тестом, трассировкой или чтением полного пути выполнения.
• Отклонено: предположение противоречит фактическому коду, контракту или среде.
• Нужно уточнить: не хватает бизнес-правила, данных или решения владельца системы.
• Не относится к PR: проблема существовала до текущего diff и оформляется отдельно.
• Улучшение: не ломает поведение и не должно задерживать merge без явного критерия.

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

Перепроверьте diff и тесты независимо

Не принимайте сообщение Claude о прошедших тестах как единственное доказательство. Выполните принятые в проекте команды сами или посмотрите их полный вывод в CI. Сначала проверьте узкий тест изменённого модуля, затем общий набор, который защищает соседние функции.

1. Откройте строку замечания и прочитайте функцию целиком, включая вызывающий и вызываемый код.
2. Сформулируйте минимальный вход, который должен вызвать ошибку.
3. Запустите существующий тест или добавьте временную воспроизводящую проверку без изменения production-кода.
4. Сравните фактический результат с контрактом задачи, а не с ожиданием модели.
5. Проверьте git diff после ревью: аналитическая сессия не должна была менять файлы.
6. Запустите линтер, тесты, сборку и основной пользовательский сценарий.
7. Зафиксируйте решение по замечанию до начала исправлений.

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

По теме: Claude Code на VPS: безопасная установка и работа по SSH

Отдельно проверьте чувствительные участки

Код из pull request может содержать вредоносные инструкции в комментариях, документации или данных теста. Anthropic предупреждает о prompt injection и рекомендует ограничивать разрешения, особенно команды загрузки данных и сетевой доступ (документация безопасности Claude Code). Не разрешайте ревьюеру выполнять неизвестные скрипты только потому, что они находятся в репозитории.

• Авторизация и роли: проверяйте отказ по умолчанию, владение объектом и обход через прямой URL или API.
• Секреты и логи: ищите токены, пароли, персональные данные и полные тела запросов в diff и выводе ошибок.
• Входные данные: проверяйте валидацию, кодировку, размер, путь к файлу и передачу в shell, SQL или шаблон.
• Миграции: оценивайте повторный запуск, блокировки, старую версию приложения и способ восстановления.
• Зависимости и CI: читайте изменения lock-файлов, install-скриптов, workflow и разрешений GitHub Actions.
• Платежи и необратимые действия: требуйте отдельного человеческого ревью, тестового контура и подтверждённого отката.

Для постоянных ограничений используйте правила permissions и sandbox. Их настройка разобрана в статье о правах Claude Code. Даже в изоляции не передавайте модели production-секреты и персональные данные без утверждённого процесса.

Исправляйте подтверждённое в отдельной сессии

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

git status --short
git diff origin/main...HEAD
<команда узкого теста>
<команда полного набора тестов>
git diff --check

Не объединяйте пять замечаний в одну команду исправления. Маленькие независимые изменения легче проверить и откатить. Если исправление меняет публичный контракт, схему данных или права, верните его владельцу системы до merge, даже когда тесты проходят.

Права интеграции проверьте по разбору Claude и GitHub. Комментарий, push и merge требуют решения ответственного человека.

По теме: DeepSeek в Claude Code: подключение и проверка в 2026

Финальный чек-лист перед merge

• База и диапазон diff проверены, посторонних файлов нет.
• Ревью не изменило рабочую папку и не отправило данные наружу.
• Каждое блокирующее замечание подтверждено кодом, тестом или воспроизводимым сценарием.
• Отклонённые замечания имеют записанную причину, а не просто помечены как шум.
• Чувствительные файлы просмотрены человеком отдельно.
• Узкие и общие тесты, линтер, сборка и CI завершились ожидаемо.
• После исправлений просмотрен новый diff и повторно проверены затронутые сценарии.
• Откат, миграция и наблюдение после выпуска определены для рискованного изменения.
• Merge подтверждает ответственный человек, а не автоматический комментарий модели.

Частые вопросы

Может ли Claude Code сам одобрить pull request?

Официальный Claude Code Review публикует замечания и нейтральный результат проверки, но сам не одобряет и не блокирует PR. Решение о merge остаётся в вашем процессе и правилах защиты ветки.

Нужно ли давать Claude весь репозиторий?

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

Можно ли сразу попросить исправить все замечания?

Не следует. Сначала подтвердите каждый пункт и отделите ошибку от улучшения. Затем исправляйте по одному независимому сценарию с отдельным тестом и просмотром diff.

Заменяет ли AI-review специалиста по безопасности?

Нет. Модель помогает найти кандидатов, но не знает все активы, угрозы и внешние настройки. Чувствительные изменения требуют профильного человеческого ревью и проверки в безопасной среде.