ИИ-помощник для сайта на WordPress: как доверить ему правки и не сломать сайт

Содержание

• Что нужно сайту до первой правки
• Сервер, копия и git: три места, которые расходятся
• Как выглядит одна безопасная правка
• Слово «ок» - отдельный шаг
• Превью, в котором ничего нельзя сломать
• Раз в месяц: что устарело на сайте
• Что ИИ-помощник для сайта не решает сам
• С чего начать, если у вас этого нет

ИИ-помощник для сайта может править живой сайт, если у него нет пути к необратимому действию без вашего «да». Для этого нужны шесть вещей: копия сайта под версионным контролем, сверка сервера с этой копией перед выкладкой, бэкап и пробный прогон перед записью, ваше явное «ОК» на всё, что видят клиенты, превью, из которого ничего не уходит наружу, и проверка актуальности раз в месяц. По этим правилам ИИ-помощник вместе с программистами правит сайт на WordPress у строительной фирмы, где я веду CRM.

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

Что нужно сайту до первой правки

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

Поэтому первое условие скучное. Рабочая копия темы лежит под версионным контролем (git), и правки сначала готовятся в ней, на живой сайт они попадают позже. Git хранит историю: какой файл когда меняли и что именно изменилось. Копия нужна сразу для двух вещей. Видно, что меняют программисты. И любую правку помощника можно посмотреть глазами до выкладки, пока ничего не сломано.

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

Сервер, копия и git: три места, которые расходятся

Когда сайтом занимаются несколько человек, сервер почти никогда не равен git. Часть файлов уже лежит на сервере, но в git не попала, потому что кто-то поправил их на месте. Часть, наоборот, закоммичена, но не выложена. Если выкладывать из копии поверх сервера без сверки, можно затереть чужую работу, причём молча.

В команде для этого сделана проверка только на чтение. Она снимает контрольные суммы файлов на сервере и сравнивает их с рабочей копией и с последней версией в git. Файлы раскладываются по группам, и у каждой группы свой ответ на вопрос «что делать»:

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

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

Второй приём - пометки. Каждую правку помощника в коде отмечают маркером или комментарием с датой, и в README ведут таблицу: файл, что сделано, зачем. Пометки решают задачу «пропала правка». Если после выкладки программистов строка исчезла, значит, файл вернули к прежней версии, и правку надо применить заново. Без пометок такую пропажу замечают через месяц по жалобе клиента.

Как выглядит одна безопасная правка

Файлы выкладывают копированием, а тексты, цены и подписи лежат в базе, поэтому их меняют скриптами, которые запускаются на сервере. У скриптов один порядок, и он не зависит от размера правки:

1. Выгрузка текущих значений. Только чтение, ничего не меняется.
2. План «было - стало». Для каждой замены записано старое значение и контрольная сумма, чтобы потом можно было проверить, что менялось именно оно.
3. Пробный прогон. Скрипт проходит весь план, но ничего не пишет, и печатает, что сделал бы. Вывод читают целиком: строки с ошибками значат, что часть замен будет пропущена.
4. Ваше «ОК». Подробнее о нём ниже.
5. Бэкап. Прежние значения сохраняются в файл с датой в названии, на каждый запуск - свой путь.
6. Запись. Перед каждой заменой скрипт сверяет, что в базе стоит именно то старое значение, которое ожидалось. Не совпало - запись пропускается и попадает в список ошибок. Форсировать не надо: выгружают данные заново и пересобирают план.
7. Сброс кэша. Иначе посетитель увидит старую страницу, а вы будете думать, что правка не сработала.
8. Проверка живых страниц. Смотрят несколько адресов в обход кэша, например с произвольным параметром в конце ссылки: изменённую страницу и по одной типовой из разных разделов.
9. Отчёт владельцу: сколько записей изменено, где лежит бэкап, что проверено, что осталось.

Две ловушки не видны, пока на них не наступишь. Если запустить скрипт второй раз с тем же путём бэкапа, он запишет туда уже новые значения и сотрёт единственную копию старых. Поэтому путь бэкапа новый на каждый запуск. Вторая касается любых резервных копий: их не кладут в папку, которую отдаёт веб-сервер. Копия файла настроек с паролем базы рядом с рабочим файлом может открыться по прямой ссылке, так что место копиям - закрытая папка вне сайта.

Слово «ок» - отдельный шаг

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

Правило выросло из настоящей ошибки: ответ на уточняющий вопрос однажды приняли за команду выкладывать, и правку пришлось откатывать. С тех пор ответ на вопрос о деталях командой не считается, слово «запускаем» должно прозвучать отдельно.

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

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

Превью, в котором ничего нельзя сломать

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

У превью две защиты. Всё, кроме просмотра страниц, заблокировано: форму из превью отправить нельзя, поэтому тестовая заявка не уйдёт в CRM. А счётчики аналитики вырезаны, чтобы проверки не попадали в статистику посещений. К любой странице можно добавить параметр и открыть её без правок, чтобы сравнить «до» и «после».

Раз в месяц: что устарело на сайте

Помощнику поручают и поиск: раз в месяц он запускает проверку актуальности, которая ходит по сайту только на чтение. В отчёте несколько разделов:

• сроки акций, которые уже прошли, и сезонные подписи, которые уже не по сезону;
• скидка в заголовках разделов, которая не совпадает с реальной скидкой в каталоге;
• цена в заголовке главной, которая отстала от каталога;
• новые упоминания скидок и цен в статьях, добавленные после прошлой проверки;
• стаж компании, написанный в годах («N лет»): такая цифра устаревает сама;
• пустые разделы каталога.

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

Из этих проверок выросла договорённость, которая сильно сокращает работу: в статьях нет процентов и сроков акций, есть ссылка на страницу акций. При смене скидки тогда меняется одна страница, статьи трогать не нужно. Подробнее об этой ловушке - в статье про старые цены на сайте.

Что ИИ-помощник для сайта не решает сам

Короткий список того, что остаётся за человеком, как бы хорошо помощник ни работал:

• цены, скидки, условия акций;
• момент запуска всего, что видят клиенты;
• откат на живом сайте;
• что делать с находками проверки: пустые разделы, расхождения со сметой.

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

С чего начать, если у вас этого нет

Не нужно строить всё сразу. Минимальный набор на первую неделю:

1. Сделайте бэкап базы и файлов и проверьте, что из него можно восстановить сайт. В справке WordPress советуют держать копии в разных местах и не меньше трёх.
2. Попросите подрядчика или программиста завести git для темы и положить туда то, что сейчас лежит на сервере.
3. Договоритесь устно и запишите: ничего, что видят клиенты, не меняется без вашего «ок», и откат тоже только с вашего ведома.
4. Попросите вести список правок: файл, что изменено, дата.

Остальное добавляется по мере того, как помощник получает всё больше задач. Моя работа начинается там, где заявка уходит с формы: как она попадает в Битрикс24 и кто за неё отвечает. Это интеграции, а посмотреть, где заявки теряются уже внутри портала, можно на бесплатном разборе. Как ИИ работает внутри самого Битрикс24 - в статье про бота по базе знаний и распознавание паспорта. А раз в неделю состояние сайта удобно смотреть по короткому осмотру за полчаса.