Codex делает сайты: как не перепутать прототип с рабочим продуктом
Если попросить Codex “сделай сайт”, самая опасная часть задачи начинается не в коде. Опасность в другом: человек видит красивый прототип, пересылает ссылку коллегам, а потом выясняется, что команда уже обсуждает его как рабочий продукт. У ссылки появился статус, у страницы появилась аудитория, а доступ, данные и секреты никто не проверил.
Раздел Sites в документации Codex полезен именно как управленческая рамка. Он говорит не только о том, что Codex может создать и развернуть сайт. Он разделяет проект, сохраненную версию, деплой, аудиторию доступа, runtime values и проверку перед публикацией. Для владельца проекта это важнее, чем технический восторг от “сайт появился по промпту”.
Почему рабочая ссылка еще не означает рабочий продукт
Сайт легко спутать с продуктом. Особенно если он родился из prompt: “собери лендинг”, “сделай интерактивную страницу”, “покажи демо игры”, “подними внутренний кабинет”. В обычной работе это звучит как просьба сделать макет. Но в Sites у Codex появляется еще одна возможность: не только собрать сайт, но и сохранить версию или развернуть ее как production URL.
Поэтому правильный вопрос к Codex не “можешь ли ты сделать сайт?”. Правильный вопрос: “что это сейчас: прототип, версия-кандидат или рабочий продукт?”. Только после этого стоит спрашивать, кто должен увидеть сайт и что должно быть проверено до публикации. Это переводит Sites из игрушки для быстрого прототипа в рабочий контур выпуска.
Что официально означает Sites в Codex
В документации OpenAI Sites описан как способ для Codex создавать, сохранять, деплоить и инспектировать сайты, веб-приложения и игры, размещенные на хостинге OpenAI. Важная деталь: deployment URL считается production deployment. Если нужно сначала посмотреть результат, надо просить Codex сохранить версию без деплоя.
У Sites есть два разных шага. Первый — сохранить версию: Codex собирает deployable site и связывает эту версию с исходным Git commit. Второй — деплоить версию: Codex публикует сохраненную версию и возвращает production URL. Для управления проектом это не мелкая техническая разница, а граница ответственности.
Еще один важный слой — форма сайта. Документация предлагает заранее сказать Codex, что именно нужно: простой сайт без постоянного состояния, проект с сохраненными записями, сайт с файлами, внутренний инструмент для пользователей workspace или публичный проект с аутентификацией. Иначе можно попросить “страницу”, а получить архитектуру, которая не соответствует данным и аудитории.
Что дать Codex на вход перед созданием сайта
Хороший вход для Codex должен быть похож не на вдохновляющий brief, а на маленькое задание на выпуск. В нем нужно назвать поведение продукта, аудиторию и границу публикации.
Например:
Сделай демонстрационный сайт для внутреннего обсуждения новой услуги. Нужна одна публично выглядящая страница, но пока без production deployment. Сохрани версию-кандидат, покажи URL для проверки в рабочем контуре, перечисли, какие данные сайт хранит, и отдельно скажи, нужен ли D1 или R2. Доступ пока только owner/admins. Перед деплоем дай чеклист проверки.
Такой вход помогает Codex не просто “рисовать страницу”, а вернуть управляемый артефакт. В нем есть цель, аудитория, ограничение доступа, требование к данным и запрет на преждевременную публикацию.
Если сайт должен что-то помнить, это тоже надо назвать прямо. Временный выбор темы или закрытый баннер не требует durable storage. А записи пользователей, прогресс, игровые результаты, файлы или searchable metadata уже меняют архитектуру. Codex должен объяснить, нужен ли D1, R2 или их связка, а человек должен понять, зачем это хранение появляется.
Какие артефакты должен вернуть Codex
После такой задачи хороший результат Codex — не только ссылка на сайт. Минимальный набор артефактов должен выглядеть так:
- сохраненная версия или объяснение, почему версия еще не готова;
- production deployment URL только если человек явно просил деплой;
- краткое описание site shape: без состояния, D1, R2, D1 плюс R2, workspace identity или authentication-enabled проект;
- режим доступа: owner/admins, workspace или custom;
- список runtime values и секретов, которые должны быть настроены через Sites panel, а не сохранены в исходниках;
- чеклист проверки перед тем, как ссылку можно отправлять другим людям.
Именно этот набор делает Sites пригодным для владельца проекта. Ссылка без карты доступа и проверки — это не результат, а риск.
Как понять: это прототип, версия-кандидат или продукт
Главная дисциплина Sites — не нажимать “выпустить” раньше времени. В статье про Codex это можно сформулировать как таблицу принятия решения.
| Ситуация | Что просить у Codex | Почему |
|---|---|---|
| Нужно посмотреть макет или демо | Оставить как прототип или сохранить версию без деплоя | Это еще не продукт, а материал для обсуждения |
| Нужно показать рабочей группе | Сохранить версию-кандидат и ограничить доступ | Сначала проверяется аудитория, содержание и данные |
| Сайт должен стать рабочим продуктом | Деплоить конкретную принятую версию | Публикуется не “последний результат”, а выбранный кандидат |
| Нужно хранить записи, файлы или прогресс | Сначала описать D1/R2 и данные | Хранение данных меняет ответственность |
| Нужно поменять секреты или runtime values | Обновить значения в Sites panel и redeploy approved version | Секреты не должны жить в .openai/hosting.json или исходниках |
Эта таблица полезна не только технической команде. Она нужна редактору, продуктологу, консультанту и владельцу внутреннего инструмента: кто видит сайт, какая версия считается принятой, какие данные остаются после просмотра.
Как проверить доступ, данные и секреты без программирования
Непрограммист может проверить Sites-пакет по простому списку.
Сначала надо спросить: “Это сохраненная версия или production deployment?”. Если Codex вернул production URL, нужно понять, был ли такой выпуск явно запрошен. Если нет, задача ушла дальше, чем нужно.
Затем проверяется аудитория. Для раннего просмотра нормальный режим — owner/admins или узкий custom-доступ. Workspace-wide доступ уже означает, что сайт увидит широкий круг людей внутри организации. Это может быть нормально, но это должно быть решением, а не побочным эффектом.
Третий пункт — данные. Если сайт что-то сохраняет, Codex должен объяснить, где это хранится и зачем. Если в задаче нет постоянных записей, прогресса, файлов или метаданных, durable storage может быть лишним.
Четвертый пункт — секреты. Документация прямо разделяет hosted environment values и файлы проекта: runtime values и секреты настраиваются через Sites panel, а не кладутся в .openai/hosting.json. Для человека это проверяется простым вопросом: “Покажи, какие ключи нужны, где они настроены и не попали ли значения в исходники”.
Что остается человеческим решением
Codex может собрать сайт, сохранить версию, подготовить deployment и объяснить конфигурацию. Но он не должен решать за человека, когда прототип становится публичным выпуском.
Человеческими остаются четыре решения.
Первое — аудитория. Кто должен увидеть сайт сейчас: только владелец, администраторы, вся рабочая область или конкретная группа.
Второе — момент публикации. Сохраненная версия может быть хорошим кандидатом, но production URL появляется только тогда, когда человек готов делиться результатом.
Третье — данные. Если сайт что-то запоминает, владелец проекта должен принять ответственность за то, какие данные сохраняются и зачем.
Четвертое — секреты и окружение. Codex может подсказать, какие переменные нужны, но человек должен убедиться, что значения настроены в правильном месте и не попали в исходники.
Хорошая задача для Sites звучит не “сделай мне сайт”. Хорошая задача звучит так: “сделай версию-кандидат, не деплой без подтверждения, покажи аудиторию доступа, объясни данные и дай чеклист перед публикацией”. Тогда Codex становится не только генератором страницы, а помощником в контролируемом выпуске веб-проекта.
