Сайт как рабочий контур: почему pimenov.ai уже не просто портфолио

Когда я запускал pimenov.ai, задача была понятная: личный сайт специалиста. Портфолио, статьи, услуги, контакты. Место, куда можно отправить человека после знакомства или поста в соцсетях.

Три месяца спустя я ловлю себя на мысли, что называть это «сайтом» уже неточно. Потому что сайт начал делать работу.

Он хранит материалы, связывает темы через граф, отдаёт данные поиску, кормит агентов контекстом, принимает черновики из Notion, живёт в Directus, проходит rebuild по крону, проверяется Codex и собирает обратную связь из аналитики.

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

Витрина показывает прошлое, контур делает работу

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

Рабочий контур устроен иначе. Он участвует в процессе:

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

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

Поиск превратил набор страниц в корпус

Первый серьёзный сдвиг случился, когда на сайте появился поиск. До этого pimenov.ai был набором страниц, которые можно листать. После поиска он стал корпусом, который можно спрашивать.

Разница принципиальная. Человек приходит с темой: «Codex», «Notion», «агенты», «граф». Поиск даёт ему вход в массив материалов, а не заставляет листать архив.

Для меня это тоже изменило ощущение. Я начал видеть собственный сайт как библиотеку, в которой удобно находить собственные мысли. А значит, стало понятно, каких мыслей не хватает.

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

Граф показал то, чего не хватает

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

Но самое ценное оказалось в другом. Граф показал пробелы:

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

Сайт начал вести себя как редактор. Он подсказывает, где контент провисает. Подробнее о том, как граф помогает планировать, я писал в «Когда статей мало: как собрать смысловой маршрут к рабочему контуру».

Какую проблему это решает для автора: вместо гадания «о чём писать дальше» вы видите конкретные дыры в своём корпусе.

Notion и Directus разделили мышление и производство

Отдельный архитектурный слой — разделение ролей между инструментами.

Notion остаётся редакционным мозгом. Здесь удобно думать, писать, править, держать черновики, работать с агентом, быстро менять текст. Это среда, которая подстраивается под человека.

Directus — производственный слой. Структурированные данные, статусы, поля, API, возможность масштабироваться на несколько сайтов с единым источником.

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

Какую проблему это решает для бизнеса: контент перестаёт зависеть от одного инструмента. Notion может обслуживать несколько сайтов через Directus, и каждый получает свои данные через API.

Codex стал техническим партнёром контура

Codex читает репозиторий, проверяет git status, держит правила проекта, смотрит live-страницы, делает чекпоинты. У сайта появился технический партнёр, который может работать с его внутренностями.

Конечно, это требует осторожности. В контуре есть жёсткие правила: read-only по умолчанию, production только по явному одобрению, секреты не печатать, чужие изменения не откатывать. Подробнее о том, как я собирал эту инфраструктуру (включая боль и грабли), читайте в «Почему и как я снёс pimenov.ru с Тильды и собрал заново с Codex».

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

Когда визитки достаточно, а когда нужен контур

Если у вас пять страниц, один раздел и обновления раз в квартал — обычный сайт справится отлично. Лишние слои только усложнят жизнь.

Контур начинает окупаться, когда:

• у вас больше 15–20 публикаций и читатель теряется;
• вы хотите, чтобы материалы усиливали друг друга;
• рядом с контентом работают агенты, которым нужен структурированный контекст;
• контент обслуживает бизнес-задачу — консультации, продукт, экспертизу;
• вы планируете масштабироваться на несколько площадок с единым источником данных.

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

Что из этого следует

pimenov.ai начинался как личный сайт. Сейчас он постепенно становится системой, которая помогает думать, писать, связывать, проверять и собирать рабочие процессы.

Кажется, именно так будут устроены сильные экспертные сайты дальше. Не красивые страницы с текстом, а живые контуры, в которых человек, контент и ИИ работают вместе.

По теме

Статья: Почему и как я снёс pimenov.ru с Тильды и собрал заново с Codex на своей системе

Блог: Один промпт, который заставляет Codex перепроверять себя — и реально улучшает результат

База знаний: Graphify — превращаем папку с файлами в граф знаний для ИИ-агентов

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov