Личный сайт в эпоху AI-агентов: как запустить и развивать его без хаоса

Личный сайт легко представить как разовую задачу: купить домен, выбрать шаблон, написать «обо мне», добавить контакты — и наконец-то поставить галочку.

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

С появлением AI-агентов проблема не исчезла. Сайт стало проще быстро собрать, написать для него тексты и даже развернуть на сервере. Но скорость не гарантирует, что он окажется полезным, узнаваемым и живым. За вечер агент способен предложить структуру, сгенерировать блоки и составить план публикаций. С той же скоростью он может наполнить сайт общими словами, выдуманными кейсами и разделами, которые никто не будет поддерживать.

Поэтому для меня личный сайт — не «страница о себе» и не демонстрация того, что AI умеет писать код. Это рабочая площадка, где постепенно собираются проекты, мысли, доказательства опыта и поводы начать разговор.

AI здесь не заменяет автора. Он помогает превратить живой опыт в материал, проверить повторяющиеся вещи и поддерживать ритм обновлений. Но цель сайта, факты, интонация и решение о публикации остаются за человеком.

Коротко

• Сначала нужно определить роль сайта: что посетитель должен понять и сделать, а не выбирать шаблон.
• Лучшая основа для статьи или кейса часто появляется не в пустом документе, а в голосовой заметке после работы, встречи или мысли в дороге.
• Агент может расшифровать запись, выделить структуру, подготовить черновик и проверить материал, но не должен придумывать факты и публиковать без подтверждения.
• Первую версию сайта стоит ограничить несколькими рабочими сценариями: понять, чем я занимаюсь, увидеть результаты, прочитать материалы и связаться.
• Для собственного сайта я рекомендую Nuxt: он даёт серверный рендеринг, хорошую основу для SEO, Markdown-контент и возможность добавлять формы и интеграции без смены платформы.
• Сайт лучше размещать на контролируемом VPS или выделенном сервере, а обновления проводить по понятному, проверяемому процессу.

Сайт — не визитка, а собственная площадка

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

Сайт не отменяет эти каналы. Он связывает их между собой.

В коротком посте я могу оставить одну мысль и привести человека к подробной статье. В описании проекта — показать не только красивый скриншот, но и задачу, ход решения, ограничения и результат. На странице услуг — объяснить, в каком формате начинается работа. В контактах — предложить простой путь к разговору.

Поэтому до дизайна и кода я бы зафиксировал роль сайта одной фразой. Например:

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

Это не рекламный слоган, а критерий для следующих решений.

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

Без этой опоры личный сайт быстро превращается в склад блоков: проекты, навыки, сертификаты, отзывы, блог, восемь иконок, анимация и ссылка на мессенджер. Формально всё на месте, но человеку по-прежнему непонятно, зачем он сюда пришёл.

Распределить роли: автор, агент и работающая система

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

Я разделяю ответственность так:

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

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

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

Начинать статью можно с голосовой заметки

Самая трудная часть регулярных обновлений сайта часто не техническая. Нужно сесть перед пустым документом и собрать мысли в связный текст. После рабочего дня, встречи или сложного проекта на это обычно не хватает времени — хотя именно тогда в голове есть живые детали.

Поэтому я считаю голосовую заметку хорошей стартовой точкой.

Можно открыть диктофон и за несколько минут проговорить:

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

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

Дальше появляется понятный маршрут:

рабочее событие или мысль → голосовая заметка → расшифровка → структура от агента → проверка фактов автором → черновик → техническая проверка → публикация.

Расшифровка — не готовая статья. В ней будут повторы, обрывки фраз, оговорки и мысли, которые хорошо звучат в разговоре, но не обязаны попадать в публичный текст. Это сырьё с реальным материалом, а не попытка AI заполнить тишину общими фразами.

Промпт: из голосовой расшифровки в план и черновик

Я дам тебе расшифровку моей голосовой заметки для личного сайта.

Твоя задача:
1. Выделить главную мысль, целевую аудиторию и практическую пользу.
2. Отделить подтверждённые факты от личных оценок,
   предположений и мест, которые нужно уточнить.
3. Предложить 4–6 информативных заголовков без кликбейта.
4. Собрать подробный план статьи.
5. Подготовить черновик от первого лица, сохраняя мою интонацию.

Ограничения:
- Не выдумывай факты, кейсы, цифры, клиентов или результаты.
- Не заменяй конкретику общими рекламными формулировками.
- Не публикуй и не меняй файлы.
- Если материала недостаточно, сначала задай точные вопросы.

Формат ответа:
1. Главная мысль.
2. Что требует уточнения.
3. Варианты заголовка.
4. План.
5. Черновик.

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

Сначала бриф, потом страницы

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

Кому-то нужно собирать заявки на услуги. Кому-то — показывать опыт, чтобы проще проходить собеседования и начинать партнёрства. Кому-то важнее регулярно публиковать материалы и строить вокруг них профессиональное сообщество.

Прежде чем открывать редактор или давать агенту команду «сделай сайт», я бы ответил на несколько вопросов:

1. Для кого сайт?
2. Что этот человек должен понять за первую минуту?
3. Какое действие для него главное: написать, оставить заявку, изучить проекты, прочитать материал, записаться на обучение?
4. Какие доказательства у меня уже есть: проекты, отзывы, заметки, выступления, продукты?
5. Что сознательно не входит в первую версию?

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

Промпт: интервью для брифа сайта

Помоги мне подготовить бриф для личного сайта.

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

Правила:
- Не предлагай дизайн и технологии, пока не собран смысловой бриф.
- Не придумывай опыт, отзывы, результаты или позиционирование вместо меня.
- Если я отвечаю расплывчато, задай уточняющий вопрос с примером выбора.

В финале подготовь:
1. Цель сайта в одной фразе.
2. Портреты основных посетителей.
3. Три–пять ключевых сценариев.
4. Состав первой версии.
5. Список недостающих материалов.
6. Риски и открытые вопросы.

Такой промпт полезен не только в разговоре с агентом. Он заставляет сформулировать то, что обычно остаётся в голове, а потом превращается в противоречивые пожелания к дизайну.

Первая версия должна работать, а не казаться полной

Есть соблазн сначала сделать «полный» сайт: собрать все проекты за десять лет, написать большую биографию, найти идеальные фотографии, придумать страницу для каждой услуги, перенести старые тексты и ещё добавить несколько функций на будущее.

Так сайт начинает выглядеть серьёзно — и долго не выходит к людям.

Я бы запускал первую версию, когда она честно и понятно решает несколько главных сценариев:

Для старта обычно достаточно главной, проектов, заметок и контактов. Услуги, обучение, музыка, стихи или другие разделы стоит добавлять не потому, что «так бывает у личных сайтов», а когда они поддерживают реальную часть моей работы.

Вместо двадцати поверхностных карточек лучше показать три проекта, о которых можно рассказать по существу. Вместо биографии на пять экранов — несколько точных абзацев. Вместо блока «скоро здесь будет блог» — одна содержательная заметка, у которой есть авторская мысль.

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

Промпт: карта первой версии сайта

На основе моего утверждённого брифа предложи первую версию личного сайта.

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

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

Не выдумывай кейсы, статистику и отзывы.
В конце составь короткий список задач на первую неделю.

Содержание появляется раньше финального дизайна

Иногда работу строят так: сначала дизайн, потом вёрстка, потом настройка, а в конце кто-то срочно заполняет страницы текстами. Обычно это видно: заголовки получаются общими, карточки — одинаковыми, а раздел «обо мне» состоит из слов «опытный», «креативный» и «ответственный».

Я бы собрал хотя бы черновое содержание до финального интерфейса. Не идеальные тексты, а ясные ответы на вопросы:

Тогда интерфейс помогает содержанию, а не заставляет его подстраиваться под случайный шаблон.

AI здесь хорошо работает как редактор и исследователь. Он может заметить повторы, предложить порядок, показать места без фактов и подготовить несколько вариантов заголовка. Но я не поручал бы ему самостоятельно «писать позиционирование»: результат почти наверняка окажется гладким, но слишком похожим на сотни других сайтов.

Технологии: почему я рекомендую Nuxt

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

Для личного сайта я смотрю на выбор прагматично. Технология должна помогать:

1. быстро и надёжно отдавать страницу посетителю;
2. удобно публиковать и обновлять материалы;
3. давать хорошую базу для поисковой видимости;
4. не превращать небольшую правку в отдельный технический проект;
5. позволять постепенно добавлять формы и интеграции, когда они действительно понадобятся.

Для таких задач я рекомендую Nuxt.

Nuxt построен на Vue и может рендерить страницы на сервере. Это значит, что посетитель и поисковый робот получают готовый HTML, а не пустую страницу, которую браузер должен сначала собрать из JavaScript. Для личного сайта это помогает скорости первого отображения и создаёт нормальную основу для SEO.

Ещё несколько практических причин:

• статьи, проекты и другие материалы удобно хранить в Markdown рядом с кодом;
• метаданные страницы — title, description, Open Graph, canonical URL и structured data — можно держать в одном понятном процессе;
• sitemap можно генерировать автоматически;
• публичные страницы, формы и серверные API находятся в одном проекте;
• сначала можно сделать спокойный контентный сайт, а затем добавить заявки, интеграции или небольшую админку без переезда на другую платформу.

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

Markdown тоже не решает всё сам. Он хорош, когда у сайта есть понятный процесс редактуры: материал можно написать, увидеть diff, проверить ссылку и сохранить историю изменений. Если автору удобнее работать только в визуальном редакторе и он не хочет иметь дело с Git, нужно сразу предусмотреть другой безопасный путь публикации.

Где размещать сайт: контролируемый VPS или выделенный сервер

Сайт лучше размещать в инфраструктуре, которой я могу управлять. На практике для личного сайта обычно достаточно надёжного VPS — выделенного виртуального сервера. Для более требовательной системы или при особых требованиях можно использовать физический выделенный сервер.

Дело не в том, чтобы любой личный сайт обязательно жил на большой машине. Дело в контроле:

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

При этом собственный сервер требует дисциплины. Нужно следить за обновлениями системы, резервными копиями, TLS-сертификатами, журналами, доступами и состоянием приложения. Если эти обязанности никто не берёт на себя, «свой сервер» быстро превращается не в свободу, а в забытый ящик с паролями.

Я бы придерживался простого правила:

Сервер должен применять подготовленную версию сайта. В полночь не стоит дописывать на нём код и исправлять текст напрямую.

Нормальный путь обновления выглядит так:

изменение в исходном коде или контенте → проверка → зафиксированная версия → публикация именно этой версии → health-check → проверка публичной страницы.

Так проще ответить на важные вопросы: какая версия сейчас работает, что именно изменилось, открывается ли новый маршрут и куда вернуться, если после публикации что-то пошло не так.

Настроить AI-агента как участника проекта

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

Его можно назвать PROJECT_CONTEXT.md, CLAUDE.md или иначе — название не главное. Важно содержание:

# Контекст личного сайта

## Цель
Помогать посетителю понять, чем я занимаюсь, увидеть реальные работы
и выбрать следующий шаг: написать, обсудить проект или прочитать материал.

## Аудитория
[Кто обычно приходит на сайт и зачем.]

## Стек
Nuxt, серверный рендеринг, Markdown для статей и проектов,
VPS или выделенный сервер для production.

## Контент
- Пишем от первого лица.
- Не выдумываем факты, клиентов, цифры и результаты.
- Голосовые расшифровки — это исходный материал, не готовая публикация.
- Автор подтверждает финальный текст перед публикацией.

## Правила изменений
- Сначала исследование и план, затем минимальное изменение.
- Не менять production, доступы, секреты и инфраструктуру без отдельной команды.
- Не расширять задачу «заодно».
- После работы вернуть список изменённых файлов, проверки, риски и открытые вопросы.

## Публикация
- Перед публикацией проверить ссылки, метаданные, мобильное отображение
  и основной пользовательский сценарий.
- Публикация — отдельное подтверждённое действие.

Рядом с контекстом полезно вести два разных списка: текущий план и журнал принятых решений. План отвечает на вопрос «что делать дальше», а журнал — «почему когда-то выбрали именно этот путь». Не стоит превращать старые решения в автоматический приказ продолжать работу: сначала их нужно сверить с реальным состоянием сайта.

Промпт: безопасная работа агента в существующем сайте

Ты работаешь с существующим личным сайтом.

Перед любыми изменениями:
1. Прочитай контекст проекта и правила публикации.
2. Проверь текущую ветку и наличие незакоммиченных изменений.
3. Установи фактическое состояние по коду, контенту и нужному runtime,
   а не только по старой документации.
4. Сначала предложи минимальный план и перечисли риски.

Во время работы:
- Не выдумывай факты для публичных материалов.
- Не публикуй сайт, не меняй production, секреты, доступы
  или инфраструктуру без отдельной команды.
- Не расширяй scope до соседних улучшений «заодно».
- Сохраняй авторский голос; спорные места помечай вопросами.

Готовность:
- список изменённых файлов;
- результат релевантных проверок;
- проверенные пользовательские сценарии;
- оставшиеся риски и действия, которые требуют решения автора.

Такой договор делает поведение агента предсказуемым. Он не обязан быть «универсальным исполнителем, который разберётся со всем». Ему нужны ясная цель, границы и форма результата.

Готовые промпты для регулярных обновлений

После запуска главная задача — не потерять ритм. Я бы не строил контент-план на год вперёд и не обещал публиковать по три материала в неделю. Гораздо полезнее завести простой повторяемый процесс и наполнять его реальными поводами.

Промпт: новая заметка или кейс из рабочих материалов

Помоги подготовить новую публикацию для личного сайта.

Вот исходные материалы: [вставить голосовую расшифровку, тезисы,
заметки, ссылки на подтверждённые материалы].

Сначала:
1. Сформулируй, какую проблему читателя может закрыть публикация.
2. Отдели подтверждённые факты от непроверенных утверждений.
3. Покажи, чего не хватает для честного кейса или статьи.
4. Предложи 4–6 заголовков и рекомендуемый формат:
   заметка, разбор, кейс, инструкция или FAQ.

Только после этого подготовь структуру и черновик от первого лица.

Не добавляй несуществующие цифры, клиентов, отзывы или результаты.
Не публикуй материал и не меняй файлы.

Промпт: аудит страницы перед публикацией

Проведи read-only аудит страницы личного сайта перед публикацией.

Проверь:
- понятна ли цель страницы в первом экране;
- соответствует ли текст заявленной аудитории;
- есть ли неподтверждённые обещания, числа или факты;
- title, description, canonical URL, Open Graph и заголовки;
- ссылки и понятность призыва к действию;
- доступность: смысловые заголовки, alt-тексты, контраст, клавиатурная навигация;
- отображение на мобильном и desktop;
- нет ли лишнего усложнения или отвлекающих элементов.

Не меняй файлы. Верни таблицу:
приоритет | проблема | доказательство | рекомендуемое минимальное изменение.
Отдельно перечисли, что уже выглядит готовым к публикации.

Промпт: еженедельный редакторский обзор

Помоги провести еженедельный обзор личного сайта.

Я дам тебе список событий недели: завершённые задачи, вопросы клиентов,
голосовые заметки, черновики, новые проекты и изменения услуг.

Твоя задача:
1. Найти один-два реалистичных повода для обновления сайта.
2. Для каждого предложить формат: заметка, кейс, обновление проекта,
   FAQ или изменение страницы услуги.
3. Объяснить пользу для посетителя.
4. Указать, какие факты или материалы нужно подтвердить.
5. Составить небольшой план на следующую неделю.

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

Цикл обновлений: не ждать большой темы

Сильный материал часто начинается не с идеи «надо написать статью», а с повторяющегося рабочего момента.

Я дважды объяснил один подход в переписке. Завершил часть проекта. Получил вопрос, на который сайт пока не отвечает. Поменял формат работы. Разобрался с ошибкой, которая может быть полезна другим. Всё это поводы для обновления.

Я бы использовал такой короткий цикл:

1. Заметить повод. Сохранить его голосовой заметкой, тезисом или ссылкой.
2. Собрать исходный материал. Расшифровать запись, приложить факты, скриншоты, документы или ссылки.
3. Дать агенту структуру. Попросить выделить пользу, вопросы и возможный формат.
4. Проверить содержание. Убрать конфиденциальное, подтвердить факты, вернуть собственную интонацию.
5. Проверить техническую часть. Ссылки, метаданные, мобильное отображение, форму связи, если она затронута.
6. Опубликовать отдельным решением. Не считать публикацию побочным эффектом редактуры.
7. Сохранить вывод. Если появился новый процесс, ограничение или полезный вопрос — обновить контекст сайта или checklist.

Тогда блог перестаёт быть обязанностью «вести контент» и становится способом не терять накопленный опыт.

Сила проверки должна соответствовать цене ошибки

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

Это не бюрократия, а способ не тратить час на проверку одной запятой и не публиковать важное изменение со словами «вроде работает».

Особенно важно не давать AI-агенту больше полномочий, чем ему действительно нужны. Для подготовки черновика не нужен доступ к production. Для аудита SEO не нужны секреты. Для проверки страницы часто достаточно read-only доступа и списка маршрутов.

Если ошибка повторилась, я бы не ограничивался новой формулировкой промпта. Лучше оставить защиту: checklist, тест, правило в проектном контексте или короткую инструкцию по проверке. Тогда следующий человек или агент начинает не с той же ошибки, а с опыта, который уже стал частью процесса.

Что можно сделать в первую неделю

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

У кого-то первый сайт будет состоять из одной сильной страницы и контактов. У кого-то сразу появятся проекты и несколько заметок. Это нормально. Важнее не количество разделов, а наличие публичного маршрута: человек открывает ссылку, понимает предложение, видит подтверждения и знает, что делать дальше.

Личный сайт становится сильнее от накопления доверия

AI сделал производство текста и кода быстрым. Поэтому особенно заметной становится разница между просто заполненным сайтом и сайтом, в котором есть живой опыт.

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

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

Но главный актив всё равно не стек и не количество агентов. Это ясный голос автора, реальные факты и привычка возвращаться к сайту с новым содержанием.

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

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