# Claude Code: 10 шагов проверки результата после каждой правки

> [Claude Code](/guides/claude-code-zhurnal-resheniy-dlya-proekta) работает с файлами проекта через терминал. Показываю цикл: задача, план, правка, diff, проверка и фиксация результата.

Источник: https://vibeceh.ru/guides/claude-code-rabochij-protokol-proverki-rezultata-posle-kazhdoj-pravki
Автор: Сергей Мазур · опубликовано 2026-08-20

Claude Code - инструмент для работы с файлами проекта через терминал. В запросе Claude Code ты ставишь задачу, смотришь план, разрешаешь правку, проверяешь diff, запускаешь команду и только потом переходишь к следующей задаче. Для этого сценария проверка Claude Code помогает оценить изменения и diff до перехода к следующему шагу. Ответ Claude не равен подтверждённому результату: ответственность за проверку команд и изменений остаётся у тебя.

## Что такое Claude Code и зачем он нужен?

Claude Code работает с файлами проекта через терминал: читает код, предлагает изменения, редактирует файлы и запускает команды. В обычном чате ты сам переносишь ответ в проект, а Claude Code работает с файлами проекта из терминала. Сам факт внесённой правки ничего не доказывает. После каждого изменения нужен [diff](/guides/claude-code-prosit-agenta-pokazat-diff-do-pravki) и проверка, связанная с задачей.

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

Claude Code работает ближе к проекту. Ты запускаешь его в рабочей папке. Он получает доступ к файлам этой папки и может выполнять разрешённые действия. Поэтому запрос «добавь кнопку» превращается не только в текстовый ответ. Claude ищет нужное место, меняет файл и предлагает команду для проверки. Оценивай инструменты Claude Code по действиям: какие файлы они затрагивают и как ты проверяешь результат.

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

- Claude внёс изменение.
- Результат изменения подтверждён проверкой.

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

В документации Anthropic отдельно подчёркивается, что перед подтверждением предложенного кода и команд нужно проверить их безопасность.

Если Claude написал «готово», это только сообщение о завершении хода. Доказательством будут изменённые файлы, diff, команда, вывод и ручная проверка главного сценария.

## Как работать с Claude Code в терминале и использовать claude code tools?

открой терминал в папке проекта, проверь, что Claude Code установлен, выполни `claude` и убедись, что запустилась сессия именно из нужного каталога. Для диагностики используй `claude --version` и `claude doctor`. Перед запуском проверь, что выбранная оболочка поддерживает команды проекта: Bash, Zsh, PowerShell или CMD.

Терминал - окно, в котором ты вводишь команды. Рабочая папка - каталог, с файлами которого сейчас работаешь. Claude Code смотрит на текущий каталог. Запускай его из каталога проекта и перед началом проверь, что находишься в нужной папке.

Минимальная последовательность такая:

1. Открой папку проекта.
2. Запусти в ней терминал.
3. Проверь установку.
4. Запусти Claude Code.
5. Убедись, что Claude видит правильный проект.

Для установки официальная документация перечисляет native installer, Homebrew, WinGet и пакетные менеджеры. Точный способ зависит от системы. В фактуре нет универсального синтаксиса для каждой из них, поэтому я не подставляю команды наугад.

После установки выполни:

```bash
claude --version
claude doctor
```

Первая команда проверяет доступность Claude Code и показывает версию. Вторая запускает диагностику. Если одна из команд не находится, сначала исправь установку. Не переходи к разбору проекта, пока базовый запуск не работает.

Затем открой Claude Code:

```bash
claude
```

Смотри не только на появившийся интерфейс. Проверь текущую папку до запуска:

```bash
pwd
ls
```

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

Если Claude Code запущен не там, где лежит проект, он может не подхватить нужные инструкции и начать искать файлы в неправильной области. Перед сессией проверь текущий каталог и после запуска выполни `/memory`.

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

## Как использовать Claude Code для правок с проверкой результата?

работай по циклу «папка проекта → Claude Code → план при сложной задаче → одна небольшая правка → `/diff` → точная команда проверки → запись результата». Не переходи дальше после слов «готово». Для каждой правки отдельно фиксируй изменённые файлы, команду, вывод и статус `PASS`, `FAIL` или `NOT RUN`.

![Кот показывает карточки с этапами правки, diff и командой проверки.](https://s3.regru.cloud/crossmark/statejnik/images/guides/claude-code-rabochij-protokol-proverki-rezultata-posle-kazhdoj-pravki/kadr-1.webp)

Запусти терминал в каталоге проекта и проверь текущий путь.

Выполни:

   ```bash
   pwd
   ls
   ```

Если рядом нет ожидаемых файлов, не запускай правку. Сначала найди нужную копию проекта.

Выполни команду:

   ```bash
   claude
   ```

Для первого проекта запусти инициализацию:

   ```text
   /init
   ```

`/init` создаёт `CLAUDE.md`. В него попадают найденные команды сборки, тестирования и правила проекта. Этот файл загружается в начале каждой сессии, поэтому туда удобно вынести короткие правила проверки.

Если правка затронет несколько файлов или ты не знаешь структуру проекта, используй plan mode:

   ```bash
   claude --permission-mode plan
   ```

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

Не пиши «приведи проект в порядок» или «почини всё». Укажи файл, действие, ограничение и команду проверки. Задачи Claude Code должны оставаться отдельными задачами с понятным результатом и проверкой, а не расплывчатым списком пожеланий.

   

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

После правки выполни внутри Claude Code:

   ```text
   /diff
   ```

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

Выполни:

   ```bash
   git status
   git diff
   ```

`git status` показывает область изменений. `git diff` показывает содержимое изменений. Если список файлов не совпадает с задачей, остановись до запуска следующей правки.

Выбери команду, связанную с конкретным изменением. Для примера из промпта это:

   ```bash
   npm test -- Table.test.tsx
   ```

Не называй результат успешным, пока не увидел фактический вывод команды. Если команда не запускалась, запиши `NOT RUN`, а не `PASS`.

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

Минимальная строка журнала выглядит так:

   ```text
   - time: YYYY-MM-DD HH:MM
     file: src/components/Table.tsx
     action: добавлен статус строки
     check: npm test -- Table.test.tsx
     result: PASS
   ```

В журнале также храни найденные проблемы, номер попытки и решение: продолжать, откатить или остановиться. Для сохранения всей переписки сессии используй:

   ```text
   /export session-log.txt
   ```

Независимую задачу запускай после `/clear`. Старый контекст не должен случайно влиять на новую правку.

На этом месте я останавливаюсь, если Claude несколько раз чинит одну и ту же ошибку. Сначала снова смотрю diff. Затем проверяю, не меняется ли причина проблемы на каждой попытке. Автоматическая проверка не должна превращаться в бесконечное «попробуй ещё раз».

Практикум полезен именно на этом переходе: там рабочий цикл собирается руками, от постановки задачи до проверки результата, превращая заметки в рабочий процесс. [https://vibeceh.ru/#buy](https://vibeceh.ru/#buy)

## Что Claude Code может изменить без твоего подтверждения?

уровень самостоятельности задаёт permission mode. В `default` Claude останавливается перед изменениями и командами. `acceptEdits` автоматически принимает правки файлов и обычные файловые команды. `plan` сначала анализирует проект. `bypassPermissions` снимает проверки и подходит только для изолированных контейнеров или виртуальных машин.

![Мужчина закрывает лицо рядом с режимами разрешений Claude Code и красным крестом.](https://s3.regru.cloud/crossmark/statejnik/images/guides/claude-code-rabochij-protokol-proverki-rezultata-posle-kazhdoj-pravki/kadr-2.webp)

Уровень автоматического принятия действий определяет различия между режимами:

| Режим | Что происходит |
|---|---|
| `default` | Claude читает файлы и останавливается перед изменениями и командами |
| `acceptEdits` | Правки файлов и обычные файловые команды принимаются автоматически |
| `plan` | Claude изучает проект и предлагает план без изменения файлов до подтверждения |
| `bypassPermissions` | Проверки разрешений обходятся; режим предназначен только для изолированных сред |

Для обучения я бы оставил `default`. Ты видишь предлагаемую команду и решаешь, запускать её или нет. Это медленнее, но помогает заметить `rm`, изменение не того файла или действие за пределами задачи.

`acceptEdits` удобен, когда diff проверяется после серии правок. Но автоматическое принятие не отменяет просмотр результата. Оно только убирает остановку перед изменением файла.

`plan` подходит до работы с несколькими файлами. Claude сначала читает проект и формулирует порядок действий. Пока план не подтверждён, файлы не меняются.

`bypassPermissions` я бы не брал для обычной папки с рабочим проектом. При таком режиме цена случайной команды выше, а новичку сложнее увидеть момент, где агент ушёл в сторону.

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

## Как проверить изменения через Git: claude code review до следующей правки?

используй `git status`, чтобы увидеть изменённые и новые файлы, а `git diff`, чтобы прочитать содержимое правок. `/diff` показывает изменения внутри Claude Code, checkpoint и `/rewind` помогают вернуть состояния сессии, но Git остаётся отдельным уровнем контроля. Команды `rm`, `mv` и `cp` через Bash checkpointing не отслеживает.

Перед задачей полезно посмотреть исходное состояние:

```bash
git status
```

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

Затем открой diff:

```bash
git diff
```

Читай не только добавленные строки. Смотри на удалённые условия, изменённые импорты, переименования и правки рядом с целевым местом.

В Claude Code есть собственный просмотр:

```text
/diff
```

Он показывает общий незакоммиченный diff и изменения по отдельным ходам Claude. Это удобно для быстрой проверки внутри сессии.

Checkpoint работает иначе. Claude Code создаёт контрольные точки до изменений. Через `/rewind` можно восстановить код, разговор или оба состояния:

```text
/rewind
```

Но checkpoint не заменяет Git. Если файл изменён через Bash-команду вроде `rm`, `mv` или `cp`, checkpointing такое изменение не отслеживает.

Я разделяю роли так:

| Инструмент | Роль |
|---|---|
| `/diff` | Быстро понять, что сделал Claude |
| `git diff` | Проверить содержимое изменений на уровне проекта |
| `git status` | Проверить область изменений |
| `/rewind` | Вернуть код или состояние разговора |
| Git | Хранить историю изменений и иметь более надёжную точку отката |

Если правка опасная, сначала сохрани рабочее состояние в Git. Не принимай незнакомый diff только потому, что команда проверки завершилась без ошибки.

## Как проверить код после каждой правки?

после каждой правки проверь список файлов, прочитай diff, запусти конкретную команду, сохрани фактический вывод, оцени покрытую область и вручную пройди главный сценарий. Итог пометь как `PASS`, `FAIL` или `NOT RUN`. Слово Claude «готово» без команды, вывода или ручного результата не считается доказательством.

Верификация не включается надёжно сама по себе. Просьба «проверь всё» может остаться обычной фразой в промпте. Я задаю проверке форму заранее.

Чек-лист после одной правки:

1. Какие файлы изменились?
2. Нет ли неожиданных файлов?
3. Что именно изменилось в `git diff`?
4. Какая команда проверяет эту правку?
5. Какой фактический вывод дала команда?
6. Какую область покрыла проверка?
7. Пройден ли главный пользовательский сценарий вручную?
8. Какой итог: `PASS`, `FAIL` или `NOT RUN`?

Команда должна быть конкретной. Для одного теста это может быть `npm test -- имя-файла`, для типов - `tsc`, для Python - `pytest`. Универсальной команды для любого проекта нет. Бери команды из проекта и из `CLAUDE.md`.

Попроси Claude показать доказательства:

Для важных изменений одной автоматической команды мало. Unit-тест проверяет отдельную часть. End-to-end-тест проходит заранее описанный путь. Ручная проверка отвечает на другой вопрос: работает ли главный сценарий глазами и руками пользователя.

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

```text
- time: YYYY-MM-DD HH:MM
  file: src/components/Table.tsx
  action: добавлен статус строки
  check: npm test -- Table.test.tsx
  result: PASS
  manual_flow: PASS
  attempt: 1
```

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

После `Edit` или `Write` hook может возвращать ошибки типов в контекст Claude. Это механический способ не оставлять проверку только в памяти модели. Но hook зависит от настроек проекта и конкретной команды. В базовом протоколе достаточно запускать известную команду вручную и сохранять вывод.

## Почему короткая проверка лучше полного прогона проекта?

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

После каждого действия в сессии остаются прочитанные файлы, результаты команд и сообщения. Токен в запросе или выводе занимает место в [контексте](/guides/kontekst-perepechatat-kod-i-ponyat-izmeneniya), который Claude может использовать на следующем ходу. Это удобно, пока в нём остаются нужные детали.

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

Поэтому для небольшой правки я начинаю с узкой команды:

```bash
npm test -- Table.test.tsx
```

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

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

## Что делать, если тесты прошли, а сценарий сломан?

зелёные тесты подтверждают только проверенную область. Они не гарантируют, что главный пользовательский путь работает целиком. Если автоматические тесты прошли, отдельно пройди реальный сценарий вручную, запиши его результат и сравни с целью правки. Для важной функции не принимай `PASS`, пока оба сигнала не совпали.

![Собака смотрит на чек-лист, где автоматическая проверка прошла, а главный сценарий сломан.](https://s3.regru.cloud/crossmark/statejnik/images/guides/claude-code-rabochij-protokol-proverki-rezultata-posle-kazhdoj-pravki/kadr-3.webp)

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

Разделяй результаты в журнале:

```text
automatic_checks: PASS
main_user_flow: FAIL
overall_result: FAIL
```

Unit-, end-to-end-тесты и автоматические проверки не гарантируют обнаружение редкой регрессии. Проверка может быть зелёной, если сценарий не описан, данные слишком простые или тесты и реализация опираются на одно неверное предположение.

Главный сценарий нужно пройти отдельно. Нажми те кнопки, введи те данные и посмотри тот результат, ради которого делалась правка. Если путь невозможно пройти вручную, запиши это как `NOT RUN`, а не как `PASS`.

## Что делать, если Claude потерял контекст или пошёл не туда?

начни новую независимую задачу с `/clear`, длинную текущую сессию сожми через `/compact`, а состав загруженного контекста проверь командой `/context`. Для точной области используй `@` перед файлами. Если Claude сделал не ту правку, открой `/rewind` и отдельно проверь Git.

В сессию постепенно накапливаются:

- прочитанные файлы;
- вывод тестов;
- логи;
- старые обсуждения;
- предыдущие исправления.

При сжатии ранние детали могут исчезнуть или сохраниться неточно. Поэтому постоянные правила держи в `CLAUDE.md`, а не только в переписке.

Перед запуском проверь инструкции проекта:

```text
/memory
```

Файл `CLAUDE.md` ищется от текущей рабочей папки вверх по дереву. Если Claude запущен из другой копии проекта, нужный файл не подхватится.

Для новой задачи:

```text
/clear
```

Для длинной текущей задачи:

```text
/compact
```

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

```text
/context
```

Если потерялась конкретная договорённость, не пересказывай весь проект. Укажи нужные файлы через `@` и повтори только правило, которое влияет на следующую правку:

Если Claude пошёл не туда, используй:

```text
/rewind
```

Команда открывает меню восстановления. Можно вернуть код, разговор или оба состояния. Но изменения через Bash-команды `rm`, `mv` и `cp` checkpointing не отслеживает, поэтому после них проверяй Git.

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

Открой терминал в каталоге проекта, проверь установку командами `claude --version` и `claude doctor`, затем выполни `claude`. Перед первой правкой проверь текущую папку через `pwd` и `ls`, чтобы Claude Code работал с нужной копией проекта. После запуска попроси показать найденные инструкции и команды проверки, а при несоответствии останови работу.

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

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

Используй Claude Code для работы с файлами проекта через терминал и проверки небольших изменений. Сначала выбери нужную рабочую папку, затем поставь ограниченную задачу с запретами и командой проверки. Для сложной правки сначала запусти plan mode, а после изменения проверь diff, Git, вывод команды и главный сценарий.

Начни с четырёх команд: `claude --version`, `claude doctor`, `claude` и `/init`. После этого проверь рабочую папку, возьми одну небольшую правку и пройди полный цикл проверки. Сравни список файлов, прочитай diff, запусти связанную команду, сохрани вывод и вручную проверь главный сценарий. Такой порядок связывает инструкции проекта, изменения и результат.

Полезная инструкция для первой правки должна содержать цель, файл, действие, запреты, команду проверки и формат отчёта. Попроси показать изменённые файлы, полный diff, exit code, ключевые строки вывода и непроверенную область. Пример: «измени только @src/components/Table.tsx, запусти npm test -- Table.test.tsx и покажи результат».

Хороший prompt для правки не просит «починить всё». Он ограничивает область, называет ожидаемый результат, перечисляет запреты и требует доказательства: список файлов, diff, команду, вывод, exit code, покрытую область и статус `PASS`, `FAIL` или `NOT RUN`. Такой формат облегчает повторную проверку и не маскирует пропущенный шаг.

Для базового рабочего цикла нужны `claude`, `claude --version`, `claude doctor`, `/init`, `/diff`, `/memory`, `/context`, `/compact`, `/clear`, `/rewind` и `/export`. Одни команды запускают и диагностируют сессию, другие показывают изменения, управляют контекстом, возвращают состояние или сохраняют журнал. Выбирай только те, которые поддерживает текущая версия Claude Code.

- [Getting started - Claude Code Docs](https://code.claude.com/docs/en/getting-started)
- [Memory - Claude Code Docs](https://code.claude.com/docs/en/memory)
- [Common workflows - Claude Code Docs](https://code.claude.com/docs/en/common-workflows)
- [Permission modes - Claude Code Docs](https://code.claude.com/docs/en/permission-modes)
- [Security - Claude Code Docs](https://docs.anthropic.com/en/docs/claude-code/security)
- [Commands - Claude Code Docs](https://code.claude.com/docs/en/commands)
- [Checkpointing - Claude Code Docs](https://code.claude.com/docs/en/checkpointing)
- [Claude Code power user tips](https://support.claude.com/en/articles/14554000-claude-code-power-user-tips)
- [Maximizing the value of your Claude Code sessions](https://claude.com/blog/maximizing-the-value-of-your-claude-code-sessions)
- [I was babysitting Claude Code all day](https://www.reddit.com/r/ClaudeAI/comments/1u22laf/i-was-babysitting-claude-code-all-day-broken/)
- [An update on recent Claude Code quality reports](https://www.anthropic.com/engineering/april-23-postmortem)