Задача
В Weomo сайты пишут роботы. Точнее, агенты: программы на больших языковых моделях. Они получают задачу и выполняют её сами: читают проект, пишут код и тексты, запускают проверки, не дожидаясь указаний. Человек ставит задачи, принимает решения и отвечает за вкус. Собственный сайт студии живёт на том же конвейере: это не демо, а рабочая среда.
Контекст
Как проверить, что студия вправду работает с языковыми моделями? Со стороны — почти никак: рынок обещает AI-разработку из каждой презентации, и слова «мы используем нейросети» ничего не стоят. Поэтому собственный сайт студии держится на том же конвейере, что и проекты клиентов. Как устроен этот сайт, так студия и работает.
Труд здесь разделён так:
flowchart TD
owner["Человек:<br/>ставит задачи, калибрует вкус,<br/>принимает решения"]
agents["Агенты:<br/>пишут код, тексты и тесты"]
pipeline["Конвейер:<br/>проверяет и публикует"]
site["Живой сайт:<br/>38 страниц, 0 ошибок валидации"]
owner -- "задача" --> agents
agents -- "правка" --> pipeline
pipeline -- "сборка зелёная" --> site
site -. "следующая задача" .-> owner
classDef default fill:noneЧто сделали
Тексты
Тексты сайта пишет агент по письменному канону студии, ничего не сочиняя от себя. Канон собрали из интервью с владельцем: 54 ответа шести раундов о голосе, ритме и словах, которые звучат фальшиво. Формулировки берутся из исследовательских отчётов, а не выдумываются на ходу. Готовый текст проходит словарный аудит: псевдо-слова и жаргон отсеивает морфологический страж, канцелярит и следы сгенерированной прозы вычитывают по письменному канону студии. Ритм машине не по силам, его вычитывают глаза.
Проверки
Каждая правка проходит сборку с валидаторами. Система сверяет внутренние ссылки с живыми страницами, а фронтматтер каждого документа — с контрактом, и не выпускает сборку с ошибкой. Машиночитаемая карта сайта сверяется с фактической структурой сайта. Сборка с ошибкой не публикуется: битая ссылка не может дожить до посетителя.
А часть проверок следит за самим этим кейсом. Числа в разделе «Метрики» сверяет тест с фактической сборкой: напишем 37 страниц вместо 38 — прогон упадёт. Соврать о себе тихо не выйдет.
| Что проверяется | Как | Что ловит |
|---|---|---|
| Внутренние ссылки | Сверка с живыми страницами на сборке | Битая ссылка не доживает до посетителя |
| Фронтматтер документов | Контракт каждого MDX-файла | Ошибка поля останавливает выпуск |
| Карта llms.txt | Сверка с фактической структурой сайта | Дрейф карты от реальных разделов |
| Числа «Метрик» | Отдельный тест против фактической сборки | 37 страниц вместо 38 роняет прогон |
| Тексты | письменный канон студии и словарный аудит | Канцелярит и следы сгенерированной прозы |
Публикация
И публикация не ручная. Нажать кнопку — вроде и всё, что осталось человеку. Релиз в GitHub запускает конвейер. Тот собирает Docker-образ, выкладывает в реестр, развёртывает на сервере и проверяет, что сайт отвечает. Если сайт не отвечает, конвейер сам возвращает прежнюю версию. И из ручного в релизе не осталось ничего.
Платформа
Под конвейер собрана платформа. Страницы генерируются заранее и отдаются готовыми: рендера с нуля при каждом заходе нет. А сервер остался только для того, что по-настоящему интерактивно: форма заявки и поиск, потому что считать на лету больше нечего. Контент лежит в MDX-файлах с жёстким контрактом. Из него собираются страницы и llms.txt, машиночитаемая карта сайта для роботов AI-поиска. Карта показывает, какие разделы есть и как услуги связаны между собой.
Результат
Сайт живёт циклами: человек описывает задачу, агенты делают правку, конвейер проверяет и публикует. В истории репозитория больше двух тысяч коммитов, каждый цикл аудита записывается в журнал под своим номером. Ручной слежки за ссылками нет: за ними следят валидаторы.
Как проходило по этапам
Этапы те же, что в клиентских проектах, хотя заказчик тут особенный. Сама студия. Всё началось с исследования и оценки: требования выставили себе как клиенту — мгновенный отклик, живые ссылки, структура, читаемая и человеком, и роботом, — а параллельно сняли голос студии, шесть раундов интервью, на которых и вырос письменный канон. Затем проектирование: заранее собранные страницы стали базовым классом платформы, сервер остался для интерактива, а контент лёг в MDX с жёстким контрактом фронтматтера — единый источник данных для страниц и машиночитаемой карты. Разработка свела каркас, валидаторы и генераторы в один конвейер: правка агента проходит проверки и попадает в публикацию без ручных операций. Дальше — запуск и эволюция: сайт развивается циклами аудита, релиз стал рутинной операцией, а не событием.
Стек
Метрики
— Страниц в сборке: 38 (каждая собрана заранее)
— Ошибок валидации: 0 (сборка с ошибкой не публикуется)
— Внешний рендер при заходе: 0 (готовый HTML отдаётся сразу)
— Разделов в машиночитаемой карте llms.txt: 6 (открытым файлом, собирается из коллекций автоматически)
Первую и последнюю строки сверяет с фактической сборкой тест: разница роняет прогон. Остальное проверяется на живом сайте: карту можно открыть и посчитать разделы, страницы — обойти. Историю коммитов и журнал аудита держим в закрытом репозитории, на встрече покажем.
