Claude code review в 2026: как проверить diff до правки

Проверь границы работы и разреши только понятные изменения. После правки сравни обещанный результат с реальным через Git.

Что такое diff и зачем просить Claude Code показать его до правки?

Claude Code работает с файлами, тестами, командной строкой и GitHub. Поэтому запрос «сделай страницу» может закончиться несколькими правками: изменениями в компонентах, стилях, настройках и тестах.

Я разделяю здесь две вещи:

• Предложение агента. Claude изучил задачу и подготовил план или изменение.
• Принятый результат. Правка действительно записана в файлы проекта.

Diff нужен на границе между ними. Diff и список файлов вместе отвечают на два разных вопроса: «Что изменится?» и «Где именно это произойдёт?» Подробнее о безопасном допуске агента к проекту читай в инструкции по доступу Claude Code.

Peter Bloem разделяет работу с кодом на выполнение и проверку в статье AI coding without the vibes.

Я бы строил работу так:

1. Сначала дай задачу.
2. Попроси изучить проект без правок.
3. Получи план и список файлов.
4. Попроси показать предполагаемый diff.
5. Проверь каждое существенное изменение.
6. Подтверди только то, что понимаешь.
7. После записи снова посмотри общий diff.

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

Как настроить Claude Code, чтобы он не менял файлы сразу?

У Claude Code есть режимы контроля, которые полезно сравнить через claude code settings:

Plan Mode нужен перед diff. В отдельном разборе Plan Mode в Claude Code показано, как он отделяет исследование от редактирования. Он показывает намерение: какие части проекта агент собирается трогать и в каком порядке. Diff показывает уже конкретное содержимое изменения.

Сначала проверь общую стратегию. Если задача про цвет кнопки, а в плане появились маршруты, база данных и авторизация, остановись. Проблема возникла не в строках. Claude неправильно понял границы.

После плана можно попросить предполагаемый diff. Не выдавай ответ «план хороший» за разрешение. Я бы прямо написал: «План принят. Теперь покажи ожидаемые изменения и дождись отдельного подтверждения». Если нужен практический разбор такой схемы, пройди практикум по вайб-кодингу, где работу с агентом разбирают маленькими проверяемыми шагами.

Как записать правило «сначала покажи изменения» в CLAUDE.md?

Файл CLAUDE.md передаёт Claude постоянные правила проекта, которые он учитывает при работе с кодом. Это удобное место для постоянного порядка действий. Не придётся каждый раз заново объяснять, что сначала нужен план, а потом правка.

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

Перед изменением файлов:

1. Сначала изучи задачу и текущую структуру проекта без правок.
2. Опиши план действий короткими пунктами.
3. Назови конкретные файлы, которые собираешься изменить.
4. Отдельно перечисли файлы и папки, которые менять нельзя.
5. Покажи предполагаемые изменения по каждому файлу.
6. Объясни существенные изменения и возможные побочные эффекты.
7. Жди моего явного подтверждения.
8. После подтверждения меняй только согласованные файлы.
9. После правки покажи итоговый diff и список изменённых файлов.
10. Не считай зелёные тесты заменой проверки diff.

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

Как запретить Claude Code менять файлы без разрешения?

Базовая модель Claude Code по умолчанию консервативная: чтение доступно, изменения требуют разрешения.

В инженерной статье Anthropic David Dworken и Oliver Weller-Davies пишут, что Claude Code использует модель разрешений: по умолчанию он работает в режиме чтения и запрашивает разрешение перед изменением файлов или запуском команд. Источник: Beyond permission prompts: making Claude Code more secure and autonomous

Запрос разрешения не равен ревью. Если агент показал десять мелких действий подряд, легко начать нажимать approve автоматически. Anthropic отдельно называет это approval fatigue, усталостью от подтверждений.

Проверяй перед каждым существенным действием:

1. Тот ли файл меняется.
2. Относится ли изменение к текущей задаче.
3. Нет ли удаления существующей логики.
4. Не появились ли секреты, токены или .env.
5. Не запускается ли команда с опасным побочным эффектом.
6. Понимаешь ли ты, что произойдёт после подтверждения.

Sandbox тоже не отвечает на вопрос, правильно ли Claude понял задачу. В разборе безопасного допуска Claude Code к проекту разобраны технические границы доступа. Ошибка внутри разрешённой области всё равно останется ошибкой.

Как ограничить область файлов, которые может менять агент?

Не отправляй агенту расплывчатую просьбу вроде «приведи проект в порядок». Для новичка такая формулировка почти приглашает к перестройке половины проекта.

Конкретная формулировка выглядит так:

• задача: добавить подпись под кнопкой;
• можно менять: src/components/PriceCard.tsx, src/styles/pricing.css;
• нельзя менять: маршруты, базу данных, авторизацию, зависимости;
• результат: одна подпись на экране тарифов;
• проверка: показать план, список файлов и diff до записи.

Если Claude просит добавить третий файл, которого не было в плане, не соглашайся автоматически. Спроси, зачем он нужен. Иногда новый файл действительно необходим. Объяснение должно появиться до принятия, до любых последствий.

Широкую задачу разбивай на смысловые блоки:

1. Изучить текущий экран.
2. Изменить компонент.
3. Проверить отображение.
4. Отдельно изменить стили.
5. Снова проверить diff.

Так проще вернуть один шаг, чем искать ошибку в огромном результате. Checkpoint помогает откатить правки Claude, но не покрывает ручные изменения и bash-команды. Поэтому я бы всё равно держал работу под Git.

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

Как по шагам попросить Claude Code показать план и diff?

1. Проверь режим подтверждений.

   Убедись, что auto-accept выключен и интерфейс показывает ручное подтверждение. Если статус непонятен, не поручай агенту большую задачу.

   Проверь также состояние рабочей папки:

   bash

   Скопировать

   git status

   Не начинай работу вслепую, если там уже есть ручные изменения и непонятен Контекст рабочей папки. Фраза claude code context может встретиться в поиске, но это не название штатной команды. Иначе потом будет трудно отделить результат Claude от своей работы.

2. Попроси изучить задачу.

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

   Запрос на предварительное изучениеСкопировать промпт

   Изучи задачу и текущий проект без изменения файлов.
   
   Задача: добавить подпись под кнопкой на экране тарифов.
   
   Сначала:
   1. Опиши, как устроен нужный экран.
   2. Покажи общий план решения.
   3. Назови конкретные файлы, которые могут потребоваться.
   4. Перечисли файлы и области, которые менять не нужно.
   5. Укажи возможные побочные эффекты.
   
   Не редактируй файлы и дождись моего подтверждения плана.

3. Проверь план и файлы.

   Сверь ответ с исходной задачей. В списке должны быть конкретные пути, вместо расплывчатых формулировок вроде «несколько компонентов» или «конфигурация проекта».

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

4. Попроси показать diff.

   После принятия плана попроси описать предполагаемые изменения по каждому согласованному файлу и дождаться отдельного разрешения на запись.

   Запрос на ожидаемый diffСкопировать промпт

   План понятен. До любой записи в файлы покажи предполагаемые изменения.
   
   Для каждого согласованного файла укажи:
   - какие строки или блоки добавятся;
   - какие строки или блоки изменятся;
   - что будет удалено;
   - зачем нужно изменение;
   - какие побочные эффекты возможны.
   
   Не применяй правки. Дождись моего отдельного подтверждения.

   Это текстовый запрос к агенту. Универсальной Git-командой он не служит. Я не выдаю его за подтверждённую команду Claude Code, которая строит полный diff до записи.

5. Проверь общий Git diff.

   Если изменения уже появились, используй claude code commands как поисковую фразу для этого сценария: посмотри список файлов и содержимое diff в терминале.

   bash

   Скопировать

   git status --short
   git diff

   Проверяй новые файлы отдельно через git status --short и список в Source Control редактора, потому что обычный вызов git diff предназначен для diff уже отслеживаемого состояния.

6. Подтверди понятные изменения.

   Разреши только тот шаг, который совпадает с планом и diff. Если появился неожиданный файл, лишняя зависимость или удаление, останови действие и попроси объяснение.

   Проверь, можешь ли ты пересказать подтверждаемое изменение своими словами. Формулировка «агент сказал, что так правильно» для проверки не подходит.

7. Проверь итог после тестов.

   Запусти подходящие тесты или проверку сборки, а затем снова посмотри git status и git diff.

   bash

   Скопировать

   git status --short
   git diff

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

Что ломается, когда Claude Code меняет несколько файлов сразу?

В одном файле inline diff обычно читается нормально. Когда Claude меняет несколько файлов, просмотр распадается между терминалом, редактором и Git. Принять часть изменений становится трудно.

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

Дальше читай diff в два прохода:

1. Сначала общий масштаб: файлы, добавленные зависимости, конфигурация, удаления.
2. Потом смысловые блоки: компонент, стили, данные, тесты.

Большой diff теряет практическую проверяемость: пользователь может технически открыть его, но это не значит, что он внимательно прочитает все изменения. Усталость превращает ревью в прокрутку.

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

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

Что делать, если auto-accept не выключается или общий diff не виден?

В Issue #2372 Claude Code пользователь сообщил, что после команды переключения интерфейс продолжал показывать автоматическое принятие. Перезапуск в описанном сценарии тоже не вернул ожидаемый режим.

Действуй по запасному маршруту:

1. Посмотри на явный статус режима в интерфейсе.
2. Не запускай крупную задачу, пока статус неясен.
3. Проверь рабочую папку через git status --short.
4. Посмотри содержимое через git diff.
5. Отдельно найди новые файлы.
6. Повтори проверку после первого изменения.

git status --short
git diff
git diff --stat

git diff показывает изменения отслеживаемых файлов. Новый файл может остаться за пределами этого вывода, пока Git его не отслеживает. Смотри такие файлы в Source Control или открывай их отдельно.

Если общего diff в Claude Code нет, отсутствие preview само по себе ничего не доказывает. Для нескольких файлов обязательна проверка через Git. Если и там нет ожидаемого результата, проверь неотслеживаемые файлы и ручные изменения в редакторе.

Вопросы и ответы