После правки ИИ-агента проверьте, какие файлы изменились, совпадают ли изменения с задачей и работает ли сайт в тестовой версии. Даже если агенту поручили исправить одну кнопку, он мог затронуть соседний блок, расчёт цены или настройки публикации. Ниже — порядок проверки для владельца небольшого бизнеса: что попросить у разработчика или агента, что посмотреть самому и в какой момент остановить публикацию.
Как задать границы правки до работы агента?
Опишите ошибку через действие посетителя. Например: «На странице заказа кнопка отправки не реагирует после выбора услуги». Добавьте ожидаемый результат: после нажатия посетитель видит подтверждение, а заказ появляется там, где его обрабатывает команда. Так агенту проще проверить результат, а вам — заметить, если он решил заодно переделать форму.
Следом задайте рамки: не добавлять пакеты, не менять версии зависимостей, не переименовывать файлы и не трогать другие страницы без согласования. Попросите сначала назвать предполагаемую причину и файлы, которые потребуют правки. Если для исправления нужен ещё один файл, агент должен объяснить зачем. Такие ограничения помогают удержать задачу в пределах исходной ошибки; похожие правила приведены в материале «Ошибки Claude Code в продакшене: 12 ловушек и правки».
Если агент уже внёс изменения, всё равно запишите исходную задачу одним предложением. С ней вы будете сверять каждый файл: «Помогает ли эта правка починить кнопку отправки?»
Где увидеть все изменения, в том числе лишние?
Попросите показать список изменённых файлов и разницу между прежним и новым кодом. Если проект хранится в Git, разработчик может начать с подготовки отката перед публикацией правок Claude Code: сохранить прежнюю рабочую версию, а затем открыть сравнение. Для просмотра подходят команды git status --short и git diff. Первая покажет изменённые и новые файлы, вторая — правки в уже отслеживаемых файлах. Новые файлы нужно открыть отдельно: одного git diff для их проверки недостаточно.
Без доступа к коду попросите короткий отчёт: названия файлов, что изменилось в каждом и зачем. Формулировка «исправил форму» слишком общая. Полезный ответ выглядит конкретнее: «Изменил обработчик кнопки на странице заказа; настройки публикации и остальные страницы не трогал». Затем попросите показать сравнение файлов или передайте его человеку, который отвечает за сайт.
Особое внимание — файлам настроек, спискам зависимостей и общим компонентам сайта. Изменение общего меню затронет больше страниц, чем правка одной кнопки. Если такой файл появился в списке без ясной причины, приостановите публикацию и попросите объяснить связь с ошибкой.
Что проверить самому, если вы не читаете код?
Откройте тестовую версию сайта и повторите действие, которое раньше приводило к ошибке. Затем пройдите соседний сценарий: измените выбор услуги, вернитесь на предыдущий шаг, снова отправьте форму. Смотрите на результат глазами посетителя. Кнопка может нажиматься, но подтверждение не появится или заказ не дойдёт до команды.
Проверьте и то, что должно было остаться прежним. Если агент правил форму заказа, откройте страницу на телефоне, посмотрите соседнюю форму и проверьте цену перед отправкой. Для сайта с ценами в белорусских рублях пригодится отдельная проверка расчёта цен в BYN после вайбкодинга: внешний вид страницы не покажет ошибку в сумме.
Запишите для каждого действия ожидаемый и фактический результат. Например: «Выбрал услугу, нажал кнопку, увидел подтверждение; заказ появился в рабочем списке». Если рабочий список вам недоступен, попросите ответственного человека подтвердить получение тестового заказа. Скриншот подтверждения на сайте сам по себе этого не доказывает.
Когда можно публиковать исправление?
Публикуйте правку после трёх проверок: понятен список изменённых файлов, исходная ошибка больше не повторяется, а соседние действия работают как прежде. Перед публикацией сохраните способ вернуть предыдущую версию и проверьте, кто сможет это сделать. Если агент добавил зависимость, поменял настройки сайта или затронул файлы за пределами задачи, сначала нужен разбор этих изменений.
После публикации повторите основной сценарий уже на рабочем сайте. Тестовая версия иногда отличается настройками, поэтому одного успешного прогона до публикации мало. Если заказы или сообщения отправляются реальным людям, заранее согласуйте безопасный способ проверки с тем, кто обрабатывает обращения.
Для частых небольших правок пригодится одинаковый список проверок перед каждым выпуском. Его можно оформить как скилл Claude Code для проверки сайта перед публикацией, но решение о выпуске оставьте человеку: агент способен подготовить отчёт, а владелец сайта проверяет, соответствует ли результат задаче.
Какие ошибки чаще всего пропускают при проверке?
- Смотрят только на исправленную кнопку. Исправление проверяйте вместе со следующим шагом посетителя: отправился ли заказ и увидел ли его сотрудник.
- Читают объяснение агента вместо списка файлов. Сверьте его рассказ с фактическими изменениями и отдельно откройте новые файлы.
- Принимают успешный тест за разрешение на публикацию. Сначала проверьте соседние действия и подготовьте возврат прежней версии.
- Просят агента «заодно улучшить сайт». Отделите дополнительные идеи от исправления ошибки и согласуйте их как другую задачу.
Откройте список изменённых файлов и отметьте каждый файл, связь которого с исходной ошибкой пока не ясна. Это первая проверка перед публикацией.
