Создать приложение с помощью Codex можно без привычки писать код каждый день. Но начать лучше не с просьбы «сделай мне полноценную CRM», а с небольшой задачи, результат которой легко проверить. Например, со списка заявок: добавить обращение, изменить статус и найти клиента по имени.
В этой инструкции разберём учебный проект: простой инструмент учёта обращений. Такой пример позволяет пройти весь путь от идеи до работающей версии, не подключая сразу оплату, реальные персональные данные и сложные интеграции.
Что делает Codex, а что остаётся за вами
Codex помогает работать с кодом проекта: разбираться в структуре, вносить изменения и выполнять доступные проверки. Но фраза «готово» сама по себе не доказывает, что приложение соответствует задаче. Вам по-прежнему нужно определить, кто пользуется инструментом, какие действия обязательны и что считается правильным результатом.
Для начала выберите удобный способ работы. В актуальной документации описаны настольное приложение, Codex CLI и расширение для редактора. Расположение элементов интерфейса может меняться, поэтому установку и вход лучше сверять с официальной инструкцией OpenAI. Здесь сосредоточимся на самой разработке, а не на конкретной версии меню.
Шаг 1. Сформулируйте одну полезную функцию
Запишите, какую ручную работу должно заменить приложение. Не «автоматизировать продажи», а «хранить обращения в одном месте и показывать, кому ещё не ответили». Вторую формулировку легче превратить в интерфейс и проверить.
Для первой версии достаточно пяти полей: имя клиента, контакт, комментарий, дата и статус. Статусы можно ограничить тремя: «Новая», «В работе», «Закрыта». Отчёты, роли сотрудников и интеграцию с мессенджером пока оставьте за пределами задачи.
Первая версия должна решать одну понятную задачу целиком. Десять наполовину работающих функций не заменяют один надёжный сценарий.
Шаг 2. Подготовьте отдельную папку проекта
Не начинайте эксперименты в папке с единственной рабочей копией сайта или клиентской базой. Создайте отдельный каталог. Для существующего проекта сначала сделайте резервную копию, а при использовании Git сохраните понятную исходную точку. Не включайте в неё пароли и файлы с секретами.
Откройте нужную папку в выбранном инструменте. Если проект уже существует, попросите объяснить, как он запускается и где находится нужная функция. Если папка пустая, сначала согласуйте минимальный набор технологий. Нет смысла подключать сервер, базу данных и систему очередей только ради учебного списка обращений.
Шаг 3. Дайте первое задание
Вот пример запроса для учебного прототипа. Его можно адаптировать под список задач, записи на услуги или каталог оборудования.
Нужно учебное веб-приложение для учёта заявок.
Пользователь один, авторизация пока не нужна.
Функции: добавить заявку, изменить статус, найти по имени.
Поля: имя, контакт, комментарий, дата, статус.
Используй только вымышленные данные.
Сначала предложи простой вариант реализации и объясни,
где будут храниться записи. До согласования код не меняй.
Оплата, рассылки и внешние интеграции в первую версию не входят.На этом этапе важно понять способ хранения данных. Если записи остаются только в памяти, они исчезнут после перезапуска. Если используется хранилище браузера, это ещё не общая база для нескольких сотрудников и не резервная копия. Попросите явно описать ограничения выбранного решения.
Шаг 4. Реализуйте один сценарий от начала до конца
После согласования плана переходите к разработке. Начните с добавления и отображения записи. Затем проверьте сохранение, редактирование статуса и поиск. Так проще понять, на каком этапе появилась ошибка.
Реализуй согласованный первый этап: добавление заявки
и отображение в списке. Обязательные поля: имя и контакт.
Не разрешай сохранять пустую заявку.
Проверь корректный ввод и ошибки валидации.
В конце укажи команду запуска и что именно проверено.Если Codex предлагает дополнительные возможности, отделяйте необходимые исправления от идей на будущее. Переключатель тем, экспорт в Excel и сложный дашборд не должны мешать завершению основного сценария.
Шаг 5. Проверьте приложение сами
Откройте работающую версию и пройдите путь обычного пользователя. Не ограничивайтесь красивым первым экраном.
- Добавьте запись с корректными данными и убедитесь, что она появилась один раз.
- Попробуйте отправить пустую форму и проверьте понятность сообщения.
- Введите длинное имя и комментарий: текст не должен ломать интерфейс.
- Измените статус и обновите страницу, если сохранение предусмотрено заданием.
- Проверьте поиск, включая запрос без результатов.
- Откройте приложение на узком экране.
Сообщение об ошибке передавайте полностью, вместе с действием, которое к нему привело. Запрос «ничего не работает» даёт мало информации. Лучше: «После изменения статуса и обновления страницы статус снова становится “Новая”».
Шаг 6. Отделите прототип от рабочего продукта
Перед использованием в бизнесе потребуется отдельная проверка хранения данных, прав доступа, резервного копирования и восстановления. Если приложение доступно из интернета, отсутствие авторизации уже не учебное упрощение, а риск.
Публикацию также лучше выделить в самостоятельный этап. Сначала рабочая локальная версия, затем тестовое размещение и только потом перенос в эксплуатацию. Не передавайте ИИ рабочие пароли в тексте задания: используйте предусмотренные средой способы подключения и выдавайте только необходимые разрешения.
С чего продолжить
После первого работающего сценария сохраните результат и составьте короткий список следующих задач. За один подход меняйте одну область поведения. Для этого пригодится инструкция как ставить задачи Codex без переписывания всего проекта. Постоянные договорённости о проекте можно вынести в AGENTS.md.
Главный ориентир прост: не количество созданных файлов, а проверенный сценарий, которым действительно можно пользоваться. Если нужен не учебный прототип, а инструмент для бизнеса, обсудим задачу: что стоит автоматизировать и с какой функции разумно начать.