Кейс VozniNet · разработка с помощью ИИ
От требований редактора – к проверяемому инструменту
Для подготовки публикаций мы разработали программу, которая проверяет HTML-фрагмент до добавления в запись WordPress. ИИ помог при создании кода, а готовый инструмент выполняет проверку по заданным правилам – без обращения к нейросети и без отправки текста на сервер.
01 · Суть разработки
Что именно мы создали
Это небольшая внутренняя программа для повторяющейся редакционной задачи. Её границы заданы заранее: проверять только те требования, которые можно описать чёткими условиями.
Находить формальные несоответствия в коде записи.
Поле для кода, кнопки управления и отчёт по правилам.
Вставленный материал не отправляется на сервер.
Программа сообщает о замечании, но не переписывает код.
02 · Исходная задача
Проверять до публикации, а не после неё
В запись WordPress можно добавить собственную разметку – заголовки, изображения, внутренние ссылки, раскрывающиеся ответы и другие блоки. Перед публикацией редактору нужно сверить код с требованиями сайта.
Например, убедиться, что в записи ровно один маркер разделения анонса и полного текста, у изображений заполнены необходимые атрибуты, а ссылки-якоря ведут к существующим элементам.
Одни и те же условия приходится держать в памяти при каждой публикации.
Повторный id, пустой alt или пропущенный блок легко не заметить при чтении.
Она оценивает смысл и подачу, а не все формальные свойства кода.
Автоматизировать только то, что описывается точным и повторяемым правилом.
03 · Логика программы
Восемь правил – восемь понятных результатов
Каждое требование превратили в отдельное условие, сопоставили с сообщением в отчёте и подготовили для него проверочный пример.
Один маркер разделения
Программа ищет маркер разделения анонса WordPress и проверяет, что он встречается ровно один раз. При отсутствии или повторе показывает найденное количество.
Без второго H1
Главный заголовок записи задаётся отдельно в WordPress. Поэтому инструмент считает элементы H1 внутри фрагмента и отмечает их наличие.
Атрибуты изображений
Для каждого изображения проверяются src, alt и title. Если картинок нет, результат предлагает ручную проверку – отсутствие изображений может быть уместным.
Наличие атрибутов не подтверждает, что файл открывается или описание точно передаёт его содержание.
Только внутренние адреса
Разрешены адреса VozniNet, относительные пути и переходы к разделам текущего материала. Адреса других сайтов отмечаются как несоответствие.
Программа проверяет запись адреса, но не открывает страницу и не подтверждает её доступность.
Уникальные id и рабочие якоря
Инструмент находит повторяющиеся значения id и сверяет ссылки вида #razdel с существующими элементами.
Это помогает заметить разрыв между ссылкой в тексте, оглавлением или кнопкой перехода и нужным разделом.
Понятная последовательность заголовков
В принятой структуре H2 обозначает основные разделы, H3 – подразделы. Проверка отмечает H3 до первого H2 и уровни глубже H3.
Смысл разделов и точность формулировок остаются предметом редакторской оценки.
Вопросы перед финальным обращением
Инструмент ищет раздел частых вопросов, раскрывающиеся блоки и ссылку на страницу контактов, а затем проверяет их порядок.
Это правило для принятой структуры VozniNet, а не распознавание любых форм призыва к действию.
Без отдельных таблиц стилей и сценариев
В коде записи программа отмечает отдельные элементы style и script, а также подключённую таблицу стилей. В этой вёрстке оформление задано встроенными атрибутами HTML.
04 · Разработка с ИИ
ИИ ускорил работу над кодом, но не получил роль исполнителя проверки
Сначала редакционные требования перевели в проверяемые условия. Для каждого правила определили три возможных состояния: соблюдено, требуется ручной просмотр или найдено несоответствие.
Затем ИИ помог подготовить структуру проверок и первоначальный вариант кода. Поведение инструмента сопоставили с требованиями, уточнили пограничные случаи и проверили на отдельных вариантах разметки.
Где используется ИИ
05 · Рабочий процесс
Как редактор проверяет фрагмент
Всё собрано в одном HTML-файле: поле для кода, кнопки проверки, показа примера и очистки, а также область отчёта.
Исходный код остаётся в окне браузера.
Программа последовательно применяет восемь групп условий.
Каждое правило получает отдельное пояснение.
Редактор сам решает, как устранить замечание.
После изменений можно запустить проверку ещё раз.
Код не меняется автоматически. Инструмент не сохраняет его в отдельном хранилище, а найденные замечания и решения по исправлению остаются под контролем автора.
06 · Проверка результата
Проверили верный пример и девять намеренных ошибок
Цель испытаний – проверить именно реализованные условия на подготовленных фрагментах, а не заявить поддержку всех возможных вариантов HTML.
Контрольный пример
Все 8 правил пройдены
Корректный фрагмент получил ожидаемые положительные результаты.
Ошибки, включённые в испытания
07 · Границы автоматизации
Что проверяет программа – и что остаётся человеку
Разделение ответственности не ограничивает пользу инструмента, а делает его результат понятным. Формальное правило можно проверить автоматически; качество публикации требует редакторского решения.
Автоматическая сверка
- Количество маркеров разделения.
- Наличие H1 во фрагменте.
- Атрибуты src, alt и title у изображений.
- Адреса ссылок и переходы-якоря.
- Повторяющиеся id и порядок заголовков.
- Положение вопросов и заключительной ссылки.
- Отдельные элементы style и script.
Редакторская проверка
- Смысл, точность и убедительность текста.
- Соответствие изображения содержанию.
- Доступность самого файла изображения.
- Фактическая работа ссылок и доступность страниц.
- Скорость загрузки и отображение на устройствах.
- Вид страницы после вставки в тему WordPress.
08 · Результат разработки
Предварительная проверка с объяснимым итогом
Получился автономный инструмент для проверки HTML перед публикацией в WordPress. Он принимает код в окне браузера, последовательно проверяет восемь групп правил и объясняет результат, не изменяя исходный фрагмент.
Повторяющиеся требования стали явными: их можно обсуждать, уточнять и проверять отдельно. Если появятся новые условия к изображениям, ссылкам или структуре материалов, набор правил можно развивать.
Логика отчёта
09 · Применение подхода
Когда разработка программы с помощью ИИ оправдана
В первую очередь – когда повторяющаяся операция уже описывается правилами, а цена ошибки понятна и контролируема.
Проверка публикаций
Обязательные поля, структура документа, оформление записей и типовые требования.
Карточки товаров
Наличие характеристик, единый формат сведений и контроль заполнения полей.
Сборка отчётов
Повторяемая обработка данных с заранее оговорёнными условиями и форматом результата.
Контроль структуры
Проверка обязательных разделов, порядка блоков и типовых условий перед передачей дальше.
Что важно определить до начала разработки
Что именно поступает в программу?
Какие условия можно выразить точно?
В каких случаях нужен человек?
Чем опасен неверный автоматический вывод?
Если у команды есть повторяющаяся операция, её можно описать и оценить вместе с разработчиком. Для начала достаточно сформулировать, что сейчас делают вручную, какие условия соблюдают и каким должен быть итог.
11 · Ответы по проекту
Частые вопросы
Коротко о том, что делает инструмент, как использовался ИИ и где остаётся необходимым ручной контроль.
Может ли ИИ сам проверять код во время работы программы?
Программа исправляет HTML автоматически?
Проверяет ли инструмент, что ссылка или изображение открываются?
Нужно ли после проверки просматривать страницу WordPress?
Можно ли настроить подобные правила под другой сайт?
Обсудим вашу задачу
Нужно проверить повторяющийся процесс в вашем проекте?
Опишите, что команда регулярно делает вручную, какие требования важно соблюдать и где чаще всего возникают ошибки. Мы оценим задачу и предложим подходящий формат разработки – от небольшой автономной программы до отдельного решения для сайта.
Расскажите о задаче и желаемом результате.