Как писать промпты для Codex: шаблон задания и 12 примеров

Коротко: из чего состоит хорошее задание для Codex

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

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

Нужен ли Codex идеальный и очень длинный промпт

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

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

Цель: сделай первый экран страницы курса понятнее для нового посетителя.

Контекст: используй существующие тексты программы и визуальный стиль сайта. Главный результат курса должен быть понятен без прокрутки.

Ограничения: не меняй другие страницы, цены и даты. Не добавляй новые библиотеки.

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

Четыре блока рабочего промпта

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

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

• Цель: какое изменение или готовый результат требуется.
• Контекст: какие файлы, папки, документы, примеры, ошибки или данные относятся к задаче.
• Ограничения: что нельзя менять, какие правила, требования и границы соблюдать.
• Готово, когда: какое поведение должно работать и какие проверки нужно выполнить.

Универсальный шаблон задания для Codex

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

Цель:
[Какой результат нужно получить? Что должно измениться для пользователя?]

Контекст:
[Какая папка, файлы, документы, ссылки, примеры, данные или ошибки относятся к задаче?]

Ограничения:
[Что нельзя менять? Какие требования, правила или границы соблюдать?]

Готово, когда:
[Что должно работать? Какие проверки выполнить? Что я смогу увидеть или использовать?]

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

После изменений:
Перечисли, что изменено, какие проверки выполнены и какие риски остались.

Когда сначала просить план, а не изменения

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

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

Пока ничего не меняй. Изучи относящиеся к задаче части проекта и предложи план.

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

К реализации переходи после моего подтверждения.

Примеры 1–3: страницы, формы и мобильная версия

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

ПРИМЕР 1 — УЛУЧШИТЬ СТРАНИЦУ
Цель: упростить структуру страницы услуги и сделать основной следующий шаг заметнее.
Контекст: используй существующие тексты и компоненты этой страницы.
Ограничения: не меняй цены, юридические формулировки и другие страницы.
Готово, когда: заголовок, преимущества и кнопка читаются без путаницы на компьютере и телефоне; сборка проходит.

ПРИМЕР 2 — ДОБАВИТЬ ФОРМУ
Цель: добавить короткую форму интереса к курсу с полями «имя» и «Telegram».
Контекст: форма должна стоять после программы курса и использовать текущий стиль.
Ограничения: пока не подключай внешнюю отправку и не имитируй успешную заявку. Добавь понятную подпись, что форма является предварительной.
Готово, когда: поля доступны с клавиатуры, подписи понятны, мобильная версия не ломается.

ПРИМЕР 3 — ИСПРАВИТЬ МОБИЛЬНУЮ ВЕРСИЮ
Цель: убрать горизонтальную прокрутку на экранах шириной 360 пикселей.
Контекст: проблема видна на странице курса; сначала найди элемент, который выходит за экран.
Ограничения: не уменьшай весь интерфейс масштабированием и не меняй десктопную компоновку без необходимости.
Готово, когда: страница помещается по ширине на 360 пикселях, текст остаётся читаемым, основные кнопки доступны.

Примеры 4–6: диагностика, SEO и ссылки

В диагностической задаче не просите сразу «починить всё». Сначала отделите поиск причины от реализации. Так вы сможете проверить логику решения и не разрешать лишние изменения.

ПРИМЕР 4 — НАЙТИ ПРИЧИНУ ОШИБКИ
Цель: определить, почему страница возвращает ошибку после отправки формы.
Контекст: используй сообщение ошибки, журналы и код формы. Сначала воспроизведи проблему, если это безопасно.
Ограничения: пока ничего не меняй и не очищай данные.
Готово, когда: названа подтверждённая или наиболее вероятная причина, приведены доказательства и предложен минимальный план исправления.

ПРИМЕР 5 — ПРОВЕРИТЬ SEO
Цель: проверить индексируемые страницы на отсутствующие title, description, canonical и H1.
Контекст: используй текущие маршруты, sitemap и шаблоны страниц.
Ограничения: не придумывай новые тексты и не меняй код на этапе аудита.
Готово, когда: есть таблица «URL — проблема — влияние — рекомендуемое исправление» и отдельный список страниц без ошибок.

ПРИМЕР 6 — НАЙТИ НЕРАБОТАЮЩИЕ ССЫЛКИ
Цель: найти внутренние ссылки, ведущие на несуществующие страницы.
Контекст: проверь все публичные страницы и навигационные компоненты.
Ограничения: не переходи по внешним ссылкам, которые требуют входа, и ничего не исправляй до отчёта.
Готово, когда: перечислены исходная страница, текст ссылки, целевой URL и полученный статус.

Примеры 7–9: калькулятор и рабочие инструменты

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

ПРИМЕР 7 — КАЛЬКУЛЯТОР
Цель: собрать калькулятор стоимости консультации по заданной формуле.
Контекст: пользователь выбирает длительность и количество участников. Формула и три контрольных расчёта приложены в calculator-rules.md.
Ограничения: не добавляй оплату и не сохраняй персональные данные.
Готово, когда: три контрольных примера совпадают, отрицательные значения не принимаются, результат понятен на телефоне.

ПРИМЕР 8 — ПРЕВРАТИТЬ ТАБЛИЦУ В ИНСТРУМЕНТ
Цель: сделать локальную страницу для фильтрации списка заявок из CSV.
Контекст: пример файла приложен; нужны фильтры по статусу, источнику и дате.
Ограничения: данные не должны отправляться во внешние сервисы. Не изменяй исходный CSV.
Готово, когда: файл загружается локально, фильтры работают на контрольном наборе, результат можно экспортировать в новый CSV.

ПРИМЕР 9 — СОБРАТЬ ЧЕК-ЛИСТ ПРОЦЕССА
Цель: превратить инструкцию публикации статьи в интерактивный чек-лист.
Контекст: шаги находятся в publication-checklist.md.
Ограничения: хранить состояние только на устройстве пользователя, без аккаунтов и базы данных.
Готово, когда: пункты можно отмечать, прогресс сохраняется после обновления страницы, есть кнопка безопасного сброса.

Примеры 10–12: тесты, ревью и документация

Эти задания помогают не только создавать новое, но и контролировать качество. Чем важнее проект, тем полезнее заранее назвать обязательные проверки и попросить Codex сообщить, что он не смог проверить.

ПРИМЕР 10 — ДОБАВИТЬ ТЕСТЫ
Цель: добавить проверки для существующей функции расчёта скидки.
Контекст: поведение описано в документации, функция уже используется в заказах.
Ограничения: не меняй саму бизнес-логику. Если тест выявит расхождение, сначала сообщи о нём.
Готово, когда: покрыты обычные, граничные и ошибочные входные данные; все существующие проверки проходят.

ПРИМЕР 11 — ПРОВЕСТИ РЕВЬЮ
Цель: проверить текущие незакоммиченные изменения перед публикацией.
Контекст: сравни изменения с задачей и правилами проекта.
Ограничения: ничего не исправляй автоматически. Сначала перечисли только конкретные проблемы.
Готово, когда: для каждой проблемы указаны место, влияние, способ воспроизведения и минимальное исправление; если проблем нет, перечислены выполненные проверки.

ПРИМЕР 12 — ОБНОВИТЬ ДОКУМЕНТАЦИЮ
Цель: привести инструкцию запуска проекта в соответствие с текущим состоянием.
Контекст: проверь package scripts, переменные окружения и реальный порядок запуска.
Ограничения: не публикуй секреты и не описывай команды, которые не проверены.
Готово, когда: новый человек может пройти инструкцию с чистого окружения, а все команды и имена файлов существуют.

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

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

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

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

Что писать в промпте, а что переносить в AGENTS.md

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

Если вы третий раз повторяете одну и ту же инструкцию, это сигнал закрепить её. Но не переносите в AGENTS.md временную задачу или длинную историю проекта. Короткие и точные правила полезнее энциклопедии, которая каждый раз занимает контекст.

Как исправить неудачный результат без нового чата

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

Фраза «сделай лучше» заставляет Codex снова угадывать. Полезная обратная связь отделяет то, что нужно сохранить, от того, что нужно изменить.

Оставь:
[Что уже сделано правильно]

Исправь:
[Конкретное расхождение с задачей]

Не меняй:
[Что должно остаться без изменений]

Новая версия готова, когда:
[Как я проверю исправление]

После изменения повтори относящиеся к задаче проверки и сообщи результат.

Как проверить результат Codex

Завершение работы — не сообщение «готово», а проверяемое состояние. Попросите Codex перечислить изменённые файлы, выполненные проверки и оставшиеся риски. Затем самостоятельно пройдите главный пользовательский сценарий.

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

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

Семь частых ошибок в заданиях для Codex

Большинство проблем возникает не из-за русского языка или отсутствия технических терминов. Причина — слишком широкий масштаб, неизвестные границы или отсутствие способа принять работу.

• Описывать тему вместо результата: «поработай над SEO».
• Диктовать случайный способ реализации, не объясняя нужное поведение.
• Не указывать, что нельзя менять.
• Передавать весь проект без подсказки, какой контекст важен.
• Просить сразу реализовать неясную и рискованную идею.
• Использовать слова «красиво», «современно» и «удобно» без примера или критерия.
• Принимать результат без собственных контрольных проверок.

Чек-лист перед отправкой промпта

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

1. Я описал наблюдаемый результат, а не только общую тему.
2. Я передал контекст, который действительно влияет на решение.
3. Я обозначил, что нельзя менять и где нужно остановиться для подтверждения.
4. Я написал, как проверить готовность.
5. Для сложной задачи я попросил сначала составить план.
6. Я понимаю, что проверю самостоятельно после работы Codex.
7. Постоянные правила проекта вынесены из разового промпта.