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

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

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

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

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

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

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

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

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

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

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

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

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

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

claude --version
claude doctor

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

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

claude

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

pwd
ls

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

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

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

1. Открой правильную папку.

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

   Выполни:

   bash

   Скопировать

   pwd
   ls

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

2. Запусти Claude Code.

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

   bash

   Скопировать

   claude

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

   Скопировать

   /init

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

3. Включи план для сложной задачи.

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

   bash

   Скопировать

   claude --permission-mode plan

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

4. Опиши одну небольшую правку.

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

   Точная задача на одну правкуСкопировать промпт

   Измени только @src/components/Table.tsx.
   Сначала прочитай @src/components/Table.test.tsx.
   Добавь отображение статуса строки в существующей таблице.
   Не меняй структуру данных и остальные компоненты.
   После правки запусти:
   npm test -- Table.test.tsx
   Покажи изменённые файлы, точную команду, ключевые строки вывода и exit code.
   Если проверка не запускалась, напиши NOT RUN.

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

5. Посмотри diff.

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

   Скопировать

   /diff

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

6. Проверь состояние Git.

   Выполни:

   bash

   Скопировать

   git status
   git diff

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

7. Запусти точную проверку.

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

   bash

   Скопировать

   npm test -- Table.test.tsx

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

8. Проверь главный сценарий.

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

9. Запиши результат.

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

   Скопировать

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

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

   Скопировать

   /export session-log.txt

10. Начни следующую задачу отдельно.

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

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

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

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

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

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

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

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

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

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

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

git status

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

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

git diff

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

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

/diff

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

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

/rewind

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

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

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

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

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

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

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

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

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

Покажи:
1. список изменённых файлов;
2. команду проверки целиком;
3. exit code;
4. ключевые строки stdout и stderr;
5. что именно проверено;
6. что не проверено;
7. итоговый статус: PASS, FAIL или NOT RUN.

Не называй правку успешной без фактического вывода команды.

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

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

- 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 может использовать на следующем ходу. Это удобно, пока в нём остаются нужные детали.

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

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

npm test -- Table.test.tsx

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

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

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

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

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

automatic_checks: PASS
main_user_flow: FAIL
overall_result: FAIL

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

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

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

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

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

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

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

/memory

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

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

/clear

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

/compact

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

/context

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

Работаем только с @src/components/Table.tsx и @src/components/Table.test.tsx.
Цель: добавить отображение статуса строки.
Не меняй другие файлы.
Сначала покажи план из трёх шагов.
После подтверждения внеси правку и запусти:
npm test -- Table.test.tsx

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

/rewind

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

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