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

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

Это пошаговое руководство, а не реконструкция личной разработки. URL сохранён, но редакционный формат изменён: для прежнего подробного рассказа не хватает проверяемой цепочки исходников. Поэтому здесь нет утверждений о сроке сборки, числе прошедших тестов, последовательности коммитов, серверном релизе, трафике или заявках. Официальные страницы и публичная главная сайта проверены 2 ноября 2026 года; практические действия ниже описывают рекомендуемый процесс, а не уже выполненную нами сборку.

Что действительно есть в доступных доказательствах

В существующем опубликованном материале о сравнении Claude Code и Codex сохранён отдельный эксперимент со строительной компанией: одинаковая исходная задача, исследование, концепции, сборка и повторная работа над дизайном. Там же есть авторское упоминание, что личный сайт создавался с Codex. Упоминание подтверждает наличие такого рассказа, но не даёт основания достроить всю историю личного сайта.

Нельзя переносить сроки, субъективный вердикт и проблемы того эксперимента на presnyakovpavel.ru. Это другой объект наблюдения. Тем более нельзя превращать перечисленные в старом черновике коммиты и тестовые итоги в подтверждённые факты без соответствующих журналов и исходников.

Архивный ролик Claude Code и Codex в отдельном эксперименте указан в неизменяемом исходном материале. Текущая загрузка YouTube при повторной проверке была ограничена, поэтому доступность воспроизведения заново не подтверждена. Кадр в обложке проверен визуально по существующему локальному файлу: на нём Павел за ноутбуком, а не две страницы сайта. Он используется только с этой точной подписью.

Что можно увидеть на публичном сайте

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

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

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

Шаг 1. Опишите цель и границы задачи

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

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

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

Шаг 2. Соберите проверенный пакет материалов

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

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

Полезная таблица: утверждение / источник / дата / разрешённая формулировка / вопрос владельцу. До вёрстки разрешите противоречия между материалами. Иначе агент может выбрать более эффектную версию и незаметно изменить само предложение бизнеса.

Шаг 3. Попросите исследование без изменения проекта

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

Изучи существующий проект только для чтения. Опиши, где находятся страницы, общий шаблон, стили, данные и формы. Перечисли команды проверки, найденные в проекте, не выдумывай отсутствующие. Зафиксируй публичные URL и пользовательские изменения, которые нужно сохранить. Ничего не редактируй, не устанавливай зависимости и не обращайся к серверу. В конце предложи минимальный план для [цель].

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

Шаг 4. Зафиксируйте маршруты и содержание

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

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

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

Шаг 5. Выберите визуальное направление

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

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

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

Шаг 6. Реализуйте один локальный фрагмент

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

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

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

Шаг 7. Разделите доступ и разрешение на действие

Возможность выполнить команду не означает, что владелец разрешил её последствия. Чтение репозитория, локальная правка, установка зависимости, отправка формы, изменение сервера и публикация — действия с разными рисками. Указывайте разрешённый этап прямо.

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

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

Шаг 8. Проверьте тексты и интерфейс

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

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

Визуальная приёмка проводится на мобильном и большом экране: переносы, меню, контраст, подписи, размер элементов и отсутствие перекрытий. Здесь не заявляется, что такой аудит presnyakovpavel.ru уже выполнен. Это процедура для вашей сборки, а не перенесённый из черновика отчёт.

Шаг 9. Проверьте формы без реальных заявок

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

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

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

Шаг 10. Проверьте техническую готовность и SEO

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

Проверьте H1, title, description, основной URL, внутренние ссылки, изображения и доступность публичных страниц. Для существующего сайта обратите внимание на сохранность старых адресов. Если меняете маршрут, нужен отдельно согласованный переход, а не случайная новая ссылка.

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

Шаг 11. Отделите готовность от публикации

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

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

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

Как фиксировать доказательства собственного проекта

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

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

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

Многоразовый чеклист приёмки сайта

  • Цель, аудитория и основное действие согласованы.
  • Все обещания, изображения и отзывы имеют основания.
  • Существующие URL сохранены или переходы отдельно утверждены.
  • Нет случайных изменений за пределами задачи.
  • Тексты проверены независимо от оформления.
  • Мобильные и большие экраны просмотрены в реальной сборке.
  • Формы проверены безопасно, ошибки отличаются от подтверждённого успеха.
  • Персональные сведения и секреты не попали в публичные данные.
  • Проверки выполнены, а невыполненные честно перечислены.
  • Метаданные, ссылки и правила публичности проверены.
  • Снимки и результаты относятся именно к принимаемой версии.
  • Публикация и способ возврата согласованы отдельно.

Вывод: сайт создаётся через проверяемые этапы

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

Сохранённый URL этой статьи теперь ведёт к руководству без неподтверждённой личной истории. Публичный сайт используется как пример структуры, архивный эксперимент — только в своей исходной области. Продолжить можно в центре Codex, разделе Skills и гайде по Codex. Дата проверки официальных источников — 2 ноября 2026 года.