Разбор · Опубликовали 07.10.2026
Валидация форм должна помогать посетителю, а агенты согласуют проверки браузера и сервера
Какие контакты форма должна принимать, как помогать с опечатками и по каким примерам проверить работу агентов.
Текст подготовлен машиной агентов под надзором Евгения Шилова · факты проверены 7 октября 2026
Форма должна помогать исправить контакт, иначе строгая проверка способна отсеять нужного вам посетителя.
Для этого ИИ-агентам поручают согласовать правила браузера и сервера; наш пример взят из кода vibecoding.ru, клиентского кейса у нас нет.
Не хотите разбираться сами? Внедряем ИИ в ваш бизнес: задачи без лимита, одна цена в месяц, отмена в любой момент.
1. Форма должна принимать нужные бизнесу контакты.
Почему правильный адрес не проходит? Форма могла получить лишнее ограничение: список популярных доменов превратился в список разрешённых.
Интеграция Tilda с CRM проверяет сохранение ответов формы в полях сделки.
Допустимый ввод задаёт бизнес. Для записи на звонок нужен контакт. Требование «только корпоративная почта» следует согласовать отдельно.
Наши примеры включают плюс и апостроф в адресе. Запретить эти знаки ради чистоты базы значит отклонить предусмотренный правилами ввод.
Ограничение должно объясняться задачей.
W3C WAI, OWASP и проверочные примеры нашего проекта, просмотрено 07.10.2026. Политика конкретной формы согласуется с владельцем продукта.
2. Браузер помогает исправить ввод, сервер решает, что принять.
Можно проверить всё на странице? Браузер даёт раннюю подсказку, но его проверку обходят. MDN требует проверять присланные данные и на сервере. В загрузке файла к форме приёмка проверяет связь вложения с заявкой, сбои и права доступа.
Общие правила должны давать одинаковый результат. Если браузер разрешает плюс в почте, сервер не должен запрещать его своим списком знаков.
Сервер проверяет и условия операции. У формы бронирования даты могут быть записаны правильно, но выезд раньше заезда всё равно не подходит.
Общие правила совпадают, серверные проверки дополняют их.
MDN и OWASP, просмотрено 07.10.2026. Проверка формата не заменяет проверку прав доступа.
3. Подсказка опечатки оставляет решение посетителю.
Что делать с похожим доменом? Предложить исправление. Автоматическая замена опасна, потому что редкий настоящий домен тоже бывает похож на популярный.
Так устроены проверки почты в нашей машине агентов сайта. В карточке автора и форме входа есть подсказка и выбор «Нет, адрес верный».
Наш код убирает краевые пробелы и переводит адрес в нижний регистр. Это политика проекта; преобразования для вашей формы согласуйте отдельно.
Наши примеры различают формат и подсказку.
Код и тестовые примеры vibecoding.ru, просмотрено 07.10.2026. Адреса условные, это ожидаемое поведение проверок, не отправленные письма.
Правильный формат не доказывает существование ящика. MDN разделяет эти проверки; подтверждение по ссылке проверяет доступ к письму отдельно.
4. Агенты согласуют правила по проверочным примерам.
Хватит поручения «сделать валидацию»? Оно оставляет агенту выбор допустимых адресов. В результате форма и сервер рискуют получить разные правила.
Ручные списки полей приходится обновлять на каждом пути. Чем больше копий, тем легче забыть одну при добавлении поля.
Такой технический долг растёт с каждым новым полем. Общий список уменьшает число мест правки, проверка не даёт его обходить.
Поломки превращались в правила.
31.07
Поле новости терялось при ручном перечислении. Правило: общий маппинг, проверка не даёт обходить его.
06.09
Проверка подписки раньше принимала почти любую строку с @. Правило: формат проверяют браузер и сервер, одинаковость ответов сверяет тест.
28.09
Похожий домен прошёл проверку наличия почтового сервера. Правило: подсказка опечатки и явное решение посетителя.
28.09
Форма входа ждала другой код ошибки и показывала «Письмо не ушло». Правило: проверка соответствия кодов сервера и состояний формы.
Записи нашей машины и закреплённые проверки, сверено 07.10.2026. Первая история относится к новостному конвейеру.
Начните с правил для агентов. Зафиксируйте обязательные поля, допустимый ввод и ответ на каждую ошибку. Примеры должны включать правильный ввод.
Затем уточните постановку задачи агенту. Ему нужны ожидаемые результаты на тех же примерах, включая запрос, отправленный в обход страницы.
У нас правила реализованы отдельно для браузера и сервера. Совместимость проверяют общие примеры; похожий код не гарантирует совпадения.
Агенты приносят результаты, которые можно сверить.
Редакционная схема приёмки по собственному опыту, 07.10.2026. Правила продукта утверждает человек, агенты готовят изменения.
5. Ошибки объясняют исправление и сохраняют заполненное.
Что написать вместо «Ошибка валидации»? Назвать поле и действие. Посетителю нужна подсказка, что исправить, а не название внутренней проверки.
Ошибка не должна стирать заполненное. GOV.UK рекомендует сохранять все ответы. Тогда человек исправляет поле, а не собирает заявку заново.
Сообщение должно работать с клавиатурой и программой чтения экрана. W3C рекомендует связать ошибку с полем и дать переход к нему из списка ошибок.
Версия для слабовидящих требует проверки чтения условий, заполнения формы и понятного ответа.
Ошибку исправляет посетитель, сбой сервиса устраняет команда.
Редакционные примеры сообщений по W3C WAI и GOV.UK, просмотрено 07.10.2026. Это не скриншот клиентской формы.
6. Принимайте форму по сценариям, а эффект меряйте после выпуска.
Как принять работу? Попросите показать каждый согласованный пример. Подсветка поля не доказывает, что сервер принимает тот же адрес.
Начните с нужных контактов и ошибок. Добавьте прямой запрос к серверу и слишком длинное значение: ему нужен понятный отказ без скрытой обрезки.
Обсудите ответственность за ошибки до правки. Автор изменения приносит доказательства, а решение принять работу остаётся за ответственным человеком.
Сценарии приёмки формы проверяют весь путь ввода.
Редакционный набор приёмки по MDN, OWASP, W3C и собственным проверочным примерам, 07.10.2026. Это требования к будущему прогону, не отчёт о выполненных тестах.
После выпуска наблюдайте отказы и исправления. Сравнивайте доли на одинаковых окнах. Рост заявок заранее не обещается, его нужно измерить.
До настройки замера согласуйте работу с персональными данными. В журнале храните категорию отказа без контактов.
Если правила формы некому собрать, начните с теста для руководителя. Он помогает выбрать следующий шаг для разработки.
На подписке «Один проект» такие правки ведёт инженер с агентами. Цена 250 000 ₽ в месяц за поток работы, не за одну форму.
Что и как мы проверяли
| Факт | Что известно | Проверено |
|---|---|---|
| Правила проверки | Прочитали руководства MDN, OWASP, W3C WAI и GOV.UK. Они описывают проверки, сообщения и доступность; результатов нашей формы не измеряют. | 2026-10-07 |
| Наши примеры | Прочитали код проверки почты, позитивные и негативные примеры, сверку браузерной и серверной реализаций. Это ожидаемое поведение существующих тестов. Новый прогон тестов не выполняли. | 2026-10-07 |
| Истории машины | Сверили исходные записи 31 июля, 6 и 28 сентября 2026 с закреплёнными проверками. История потерянного поля относится к новостному конвейеру; остальные к проверкам почты. | 2026-10-07 |
| Цена подписки | Живая страница /services, срез 7 октября 2026. «Один проект» стоит 250 000 ₽ в месяц за один продукт и поток работы. Это цена подписки, не отдельной правки формы. | 2026-10-07 |
| Применимость | Своего клиентского кейса и замера прироста заявок после валидации нет. Опыт относится к vibecoding.ru. Наличие почтового ящика и доставку заявки проверяют отдельно. | 2026-10-07 |
7. Частые вопросы
Что такое валидация данных форм?+
Проверка введённого по правилам продукта. Она отвечает, заполнено ли обязательное поле и подходит ли значение. Доставку заявки она сама по себе не доказывает.
Можно ли принимать только корпоративную почту?+
Да, если это требование продукта, которое объяснено до заполнения. Для общей заявки такой фильтр нужно обосновать: собственный домен не входит в список популярных почтовых сервисов.
Правильный формат доказывает существование ящика?+
Нет. MDN отдельно разделяет синтаксис адреса и существование ящика. Подтверждение по ссылке проверяет доступ к письму; это отдельный шаг после проверки формата.
Нужно ли ругать посетителя при каждом нажатии клавиши?+
Нет. Проверку запускают так, чтобы человек успел заполнить поле; после отказа помогают исправить его. Момент показа ошибки следует включить в сценарии приёмки.
Одинаковые правила требуют одного файла?+
Общий модуль уменьшает риск расхождения. Если реализации разные, их сверяют одним набором примеров. Серверные проверки прав и текущего состояния операции остаются дополнительными.
Чем валидация отличается от защиты от спама?+
Она проверяет значения. Ограничение частоты обращений и другие меры против злоупотреблений решают отдельную задачу; допустимый адрес ещё не делает весь запрос безопасным.
Источники
- MDN, Client-side form validation — официальное руководство
- MDN, input type=email — официальное руководство
- OWASP, Input Validation Cheat Sheet — официальное руководство
- W3C WAI, Validating Input — стандарты доступности
- W3C WAI, User Notifications — стандарты доступности
- GOV.UK Design System, Error message — официальное руководство
- vibecoding.ru, машина агентов и роль инженера — наш опыт
- vibecoding.ru, публичная форма подписки; код и проверочные примеры просмотрены 7 октября 2026 — наш опыт
- vibecoding.ru, условия подписки «Один проект», срез 7 октября 2026 — наш сервис
Запомнить
1. Принимайте нужные бизнесу контакты. Начните с примеров правильного ввода, который форма сейчас отклоняет.
2. Согласуйте общие правила браузера и сервера. Приёмка включает запрос в обход страницы.
3. Подсказывайте исправление адреса и оставляйте выбор человеку. Формат не подтверждает существование ящика.
4. Сохраняйте ответы после ошибки. Повторившийся отказ превращайте в проверочный пример и наблюдайте его после выпуска.