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

За последний год в приёмке сайтов появилась новая сцена. Работа сдана, заказчик прогоняет сайт через ИИ-агента — своего или стороннего специалиста «на проверку» — и присылает список замечаний на сорок пунктов. Подрядчик правит, отправляет обратно. Новый прогон — новый список, тоже на сорок пунктов, только пункты другие. И так по кругу, пока у кого-то не кончится терпение.
Мы сами прогоняем каждый проект через несколько ИИ-агентов и собственных проверочных сценариев ещё до сдачи — это часть нашего процесса, и она находит реальные вещи. Поэтому вопрос не в том, полезен ли ИИ-аудит. Полезен. Вопрос в том, почему полученный таким способом список замечаний не заканчивается никогда — и что с этим делать обеим сторонам.
Список бесконечен по устройству инструмента, а не по качеству сайта
Языковая модель — генератор текста, а не измерительный прибор. Когда ей говорят «найди недочёты на этом сайте», задание фактически звучит как «сгенерируй список недочётов». Пустой ответ выглядит для модели как невыполненная работа, поэтому она его почти никогда не выдаёт: если крупных проблем нет — в список поедут мелкие, если нет и мелких — поедут вкусовые.
К этому добавляются ещё четыре свойства, из-за которых поток замечаний не иссякает:
- У «хорошо» нет верхней границы. Всегда можно добавить ещё одну микроразметку, ещё один атрибут alt, ещё одно правило кэширования. Сайт нельзя закончить — его можно только сдать в согласованном объёме.
- Агент не знает, о чём договаривались. У него нет технического задания, макета и протокола решений, поэтому он сравнивает сайт не с договорённостями, а с абстрактным «как принято». Сознательное решение заказчика выглядит для него ошибкой.
- Лучшие практики противоречат друг другу. Скорость против аналитики и шрифтов, доступность против дизайнерских решений, подробная разметка против чистоты кода. Любой выбор в этом конфликте даёт повод для замечания — и противоположный выбор тоже.
- Каждый прогон случаен. Тот же промт на том же сайте завтра даст другой набор пунктов. Не потому что сайт изменился, а потому что так работает генерация.
Пока приёмка сформулирована как «нет замечаний», её нельзя пройти: замечания генерируются быстрее, чем исправляются.
Что в этих отчётах правда
Отмахнуться от ИИ-аудита нельзя: всё машинно-проверяемое он ловит быстро и дёшево — битые ссылки, неправильные коды ответов, отсутствующие метатеги, ошибки структурированной разметки, тяжёлые изображения, недоезжающие до почты формы. Такие пункты стоит проверять и исправлять, кто бы их ни прислал.
Проблема в том, что настоящие дефекты приходят вперемешку с остальным. Мы разбираем входящий список по трём корзинам — обычно в течение суток после получения:
- A — дефект против договорённостей. Сайт не соответствует тому, что зафиксировано в задании. Правим в рамках гарантии, со сроком.
- B — улучшение сверх согласованного объёма. Не ошибка, а предложение, иногда хорошее. Оценивается как отдельная работа со сроком и ценой.
- C — ложное срабатывание. Пункт неверен фактически или неприменим к этому проекту. Опровергается замером или ссылкой на принятое решение.
Корзина C у российских проектов особенно заметна, потому что большинство агентов обучены на западной практике. Типичное: требование cookie-баннера в формулировках GDPR там, где сайт работает по 152-ФЗ с политикой обработки персональных данных; совет убрать Яндекс.Метрику ради скорости; сообщение об отсутствии разметки Organization на странице, где стоит более точная LocalBusiness; замер скорости с зарубежного узла, выданный за опыт пользователя из России. Отдельная категория — замечания по вкусу: цвет кнопки, длина заголовка, «текст недостаточно вовлекающий».
Практический вред тут не в самих ложных пунктах, а в том, что среди них тонут настоящие. Когда в списке сорок позиций и тридцать из них шум, три действительно важные читаются последними — или не читаются вовсе.
Как сделать список конечным
Спорить с каждым пунктом бесполезно: это та же бесконечная игра, только с другой стороны стола. Работает единственное — заранее согласованная граница приёмки. Что для этого нужно, по убыванию эффекта:
- Приёмочные критерии, согласованные до старта, а не после сдачи. Измеримые пороги вместо оценок: показатели скорости на мобильном не ниже оговорённых, критических ошибок доступности — ноль, все формы доходят до почты и в CRM, метатеги, canonical, robots и карта сайта по чек-листу, редиректы со старых адресов по карте, юридические страницы по 152-ФЗ. Всё, что в списке, — обязательство подрядчика. Всё, что вне списка, — отдельная работа.
- Отчёт о собственной проверке отдаётся вместе с сайтом. Мы показываем результат своих прогонов: найдено столько-то, исправлено столько-то, вне объёма столько-то с обоснованием, сознательно не делаем — с причиной. После этого сторонний отчёт либо повторяет уже раскрытое, либо приносит что-то новое — и это уже предметный разговор, а не защита.
- Замечание принимается в формате дефекта: адрес страницы, устройство и браузер, что ожидалось по заданию, что получилось фактически, воспроизводимое доказательство — скриншот или замер. Полезно указывать инструмент и промт: по промту сразу видно, проверяли по критериям или генерировали список.
- Одно окно обратной связи: один сводный список в оговорённый срок вместо писем по одному пункту в течение месяца. Плюс шкала критичности, чтобы отсутствие alt у декоративной иконки не лежало в одном списке с неотправляющейся формой.
Если вы проверяете подрядчика с помощью ИИ
Это разумно, и мы не против: собственная проверка — нормальная часть приёмки. Несколько приёмов, которые заметно повышают её КПД:
- Смените промт. Вместо «найди все недостатки» — «проверь по списку критериев ниже, по каждому дай вердикт: соответствует, не соответствует, не применимо; пустой список несоответствий — допустимый результат». Одно это изменение убирает большую часть шума.
- Дайте агенту контекст: техническое задание, состав работ, что в объём не входило. Без этого он проверяет ваш сайт против воображаемого.
- Требуйте доказательство по каждому пункту. Замечание без адреса страницы и способа воспроизведения — гипотеза, а не дефект.
- Разделяйте зоны ответственности. Техника и соответствие заданию — к подрядчику. Смысл, тексты и приоритеты — ваша зона. Вкусовые вещи обсуждаются, но дефектами не являются.
- Доверяйте машине там, где она сильна. Коды ответов, битые ссылки, скорость, разметка — здесь агент почти не ошибается. Оценка стратегии, текстов и оправданности решений даётся ему хуже: вашего бизнеса он не знает.
Коротко
ИИ-аудит — хороший инструмент и плохой судья. Он отвечает на вопрос «что ещё можно было бы сделать» и не отвечает на вопрос «сделано ли то, о чём договорились». Второй вопрос закрывают приёмочные критерии, о которых стороны условились до начала работ.
Мы закладываем такие критерии в проект на старте и отдаём отчёт о собственных проверках вместе с сайтом. Для обеих сторон это дешевле, чем переписка без конца после запуска.