Сначала попросите разработчика или ИИ-агента обновить библиотеки на копии сайта, затем проверьте сборку и путь клиента от открытия страницы до отправки заявки или заказа. Рабочий сайт пока не трогайте. В этой статье разберём, какую копию подготовить, какие проверки поручить агенту и что проверить самому без знания кода. В конце у вас будет понятное условие публикации: обновление выходит на сайт только после проверки нужных функций.
Как подготовить копию сайта, чтобы проверка имела смысл?
Начните с вопроса: совпадает ли копия с рабочим сайтом по коду и способу запуска? Если разработчик собрал её давно, успешная проверка мало что скажет о текущей версии. Попросите взять актуальный код, установить библиотеки из файла фиксации версий и записать, с какой версии началась работа. Для проекта на npm таким файлом обычно служит package-lock.json, а команда npm ci устанавливает зависимости по нему без подбора новых версий.
Копия должна открываться отдельно от рабочего сайта. Проверьте, что тестовая форма не отправляет обращения в рабочую очередь, а тестовый заказ нельзя принять за настоящий. Для проверки оплаты заранее согласуйте с разработчиком безопасный тестовый сценарий. Если его нет, не проводите платёж ради проверки библиотеки: отметьте оплату как непроверенный участок и решите, можно ли публиковать правку без него.
Перед началом попросите сохранить рабочую версию и описать способ возврата к ней. Практичная формулировка задачи: «Сделайте отдельную копию текущего сайта. Обновите зависимости только в ней. Покажите список изменённых файлов и способ вернуть прежнюю версию». Так у проверки появляются границы, а у публикации — путь назад.
Что поручить Claude Code при обновлении зависимостей?
Дайте агенту узкую задачу: найти библиотеку, которую требуется обновить, объяснить причину и показать изменения до публикации. Если пакет «не прошёл проверку», попросите указать точное сообщение инструмента. По одной общей фразе нельзя понять, проблема ли это в известной уязвимости, несовместимых версиях или неудачной сборке.
Для проекта на npm запрос разработчику или агенту можно сформулировать так: «На отдельной ветке проверь зависимости. Обнови только пакеты, которые нужны для этой задачи. Не меняй рабочий сайт. После обновления выполни доступные в проекте тесты и сборку, затем покажи изменения в package.json и package-lock.json». Если проект использует другой менеджер пакетов, разработчик подставит его команды и файл фиксации версий.
Попросите агента отдельно записать, какие команды он запускал и чем они завершились. В русскоязычном руководстве по Claude Code описаны сценарии, где агент сам запускает тесты и делает коммит (GitHub, claude-code-handbook-ru). Но коммит означает лишь, что изменения сохранены в истории кода. Он не подтверждает, что посетитель сможет отправить форму на вашем сайте.
Если после обновления изменился большой список библиотек, остановите публикацию и попросите объяснить каждую группу изменений. Иногда пакет подтягивает связанные зависимости, поэтому длинный список сам по себе не доказывает ошибку. Вам нужен ответ по существу: какая библиотека вызвала изменения, прошла ли сборка и какие функции сайта ещё предстоит проверить вручную.
Как проверить копию сайта без технических знаний?
Проверяйте действия клиента, от которых зависит работа бизнеса. Для сайта с заявками откройте страницу услуги, заполните форму и убедитесь, что обращение попало туда, где его ждёт сотрудник. Для магазина пройдите путь от карточки товара до оформления заказа. Если на сайте есть личный кабинет, проверьте вход под тестовой учётной записью. Список нужен короткий и привязанный к вашему сайту.
Откройте копию с телефона и с компьютера. После обновления библиотек страница порой загружается, но кнопка не реагирует или блок перекрывает форму. Проверьте страницу с товарами или услугами, затем повторите главное действие клиента. Если после правок страница перестала открываться, пригодится отдельная инструкция о том, как проверить доступность сайта после правок Claude Code.
Зафиксируйте результат простыми словами: «Форма на странице услуги отправилась, заявка появилась в тестовом списке» или «Кнопка отправки на телефоне не сработала». Скриншот и адрес страницы помогут разработчику воспроизвести сбой. Если агент сообщил об успешных автоматических тестах, всё равно пройдите пользовательский сценарий: тесты проверяют только те ситуации, которые кто-то в них предусмотрел.
Отдельно посмотрите на скорость привычных страниц. Сравните копию с рабочим сайтом на одном устройстве и при похожем подключении. Если разница заметна, запишите, какая страница и какое действие тормозит. Дальше разработчик сможет найти причину замедления сайта после правок Claude Code, вместо того чтобы угадывать её по общему сообщению «сайт стал медленнее».
Что делать, если пакет не прошёл проверку или сайт сломался?
Сначала сохраните текст ошибки и остановите публикацию. Попросите разработчика показать команду, на которой возник сбой, и файл, который она упоминает. Сообщение «проверка зависимостей не пройдена» слишком общее: дальнейшие действия зависят от причины.
- Если установка не проходит, проверьте, совпадают ли файл фиксации версий и список зависимостей проекта. Разработчик исправляет несоответствие на копии и повторяет установку.
- Если сборка падает после обновления, попросите определить пакет, после которого началась ошибка. Затем верните прежнюю версию этого пакета на копии или исправьте код и повторите сборку.
- Если инструмент сообщает о проблемной зависимости, попросите назвать пакет и доступное исправление. Не запускайте автоматическое исправление сразу для всего проекта: сначала посмотрите, какие версии и файлы оно меняет.
- Если сборка проходит, но не работает форма или заказ, передайте разработчику страницу, действие и текст ошибки. После исправления пройдите тот же путь ещё раз.
Не публикуйте обновление с пометкой «разберёмся после запуска», если сбой затрагивает основной путь клиента. Когда исправление готово, повторите проверки на копии. После публикации откройте уже рабочий сайт и ещё раз проверьте ключевое действие: копия и рабочая среда могут отличаться настройками.
Какие ошибки чаще всего мешают такой проверке?
- Проверять старую копию. Перед обновлением возьмите актуальный код рабочего сайта.
- Поручать агенту «обновить всё». Укажите конкретный пакет или проблему и запросите список изменений.
- Считать успешную сборку проверкой сайта. Пройдите форму, заказ или другой главный путь клиента вручную.
- Смешивать тестовые и рабочие обращения. До проверки убедитесь, что сотрудники отличат их друг от друга.
- Забывать о возврате прежней версии. Согласуйте его до публикации, пока рабочий сайт не затронут.
Откройте список библиотек вашего сайта и запишите одно действие клиента, которое обязательно проверите на копии после ближайшего обновления.
